Artykuły dotyczące tematu: MySQL

dodany: 26.06.2013 | tagi: , , , , ,

Red Hat nie potwierdza migracji na MariaDB

0

Po niedawnych informacjach dotyczących migracji Red Hat Enterprise Linux 7 na MariaDB – alternatywną implementację MySQL (zobacz newsa: Red Hat migruje na MariaDB), czas na wiadro zimnej wody. Dotychczasowe doniesienia były oparte na prezentacji Radka Vokala z Red Hat Summit, gdzie rzeczywiście informował o rezygnacji z MySQL.

Jak wyjaśnia Mark Coggin, dyrektor ds. marketingu, firma nie podjęła decyzji z jakiej bazy danych będzie korzystać RHEL7. Prezentację Vokala należy odnieść do Software Collections, zestawu oprogramowania dla developerów, ułatwiającego pracę z róznymi wersjami programów. W jego najnowszej wersji można było znaleźć nie tylko MariaDB, ale także MySQL i PostgreSQL.

Ów zbiór może być prekursorem zmian w nowym wydaniu RHEL. Sam system mógłby używać starszych wersji albo zupełnie innego oprogramowania, ale jednocześnie mieć dostęp do najnowszych wydań baz, kompilatorów czy interpreterów. Być może Red Hat ostatecznie zdecyduje o migracji na MariaDB, ale dowiemy się tego dopiero z pierwszą betą nowego wydania.

dodany: 26.06.2013 | tagi: , , ,

Błąd w MySQL zmienił licencję dokumentacji

1

Dosyć łatwo znaleźć głosy oburzenia na Oracle. Nie inaczej stało się, gdy ewangelista MariaDB odkrył, że dokumentacja man nie jest już na licencji GPL. Tymczasem okazało się, że problem jest zgłoszony na bugtrackerze MySQL i nie jest celową zmianą autorstwa Oracle.

Jak zapewnił Tomas Ulin z Oracle, bug zostanie naprawiony, a kody źródłowe z poprawioną licencją udostępnione. Dodał także, że zgłaszanie błędów zawsze jest dobrym sposobem na komunikację z programistami MySQL. Problem najpewniej wynika z przypadkowego przeniesienia stron man z płatnej edycji Enterprise, która nie jest otwartym oprogramowaniem.

Aktualizacja:

Oracle naprawiło błąd w licencjonowaniu bazy danych MySQL. Przebudowano i wgrano od nowa źródła MySQL 5.5.32, MySQL 5.6.12 i MySQL 5.7.1.

dodany: 17.06.2013 | tagi: , , , ,

Red Hat migruje na MariaDB

0

Jak poinformowano na Red Hat Summit, w nowej, siódmej wersji Red Hat Enterprise Linux użytkownicy i administratorzy nie uświadczą więcej MySQL – jego miejsce zajmie MariaDB, tak jak zdecydowano już w wielu dystrybucjach, między innymi Arch Linuksie.

Tym razem zmiana jest o tyle ważna, że nie dotyczy dystrybucji mniej lub bardziej zarządzanej przez społeczność, tylko produktu, w którym zmiany pozostaną na długie lata. Dodatkowo migracja dotknie różne dystrybucje pochodne, takie jak CentOS i Scientific Linux.

Okaże się, czy Red Hat zapoczątkuje lawinę i ku niezadowoleniu Oracle, właścicieli MySQL, pociągnie za sobą większość dystrybucji. Duża część dokonała migracji przed decyzją amerykańskiego giganta, ale wciąż nie wiadomo czy podobnie uczyni Debian i Ubuntu.

dodany: 19.05.2013 | tagi: , , ,

Ubuntu rozważa rezygnację z MySQL

0

Opisywaliśmy migrację Arch Linuksa i Slackware na MariaDB – podobnie postąpiło OpenSuse, Fedora i wiele innych dystrybucji. Także Ubuntu rozważa rezygnację z MySQL.

Migracja została przedyskutowana na odbywającym się w zeszłym tygodniu (V)Ubuntu Developer Summit. Głównymi zarzutami stawianymi Oracle jest niepublikowanie informacji o lukach bezpieczeństwa, ukrywanie zgłoszeń błędów, brak informacji o poprawkach na liście zmian i opóźnienia w aktualizacjach repozytorium z kodem źródłowym.

Developerzy Ubuntu rozważają pomoc programistom MariaDB w dodaniu pakietów do repozytoriów Debiana, skąd pakiet trafiłby do Ubuntu 13.10, oraz spaczkowanie serwera Percona. Nie podjęto decyzji, która z alternatyw zastąpiłaby MySQL, niemniej postanowiono skorzystać z doświadczeń innych dystrybucji.

Można zatem się spodziewać, że w Ubuntu 13.10 uświadczymy jeszcze MySQL, ale zostanie on zastąpiony do kolejnego wydania z długoterminowym wsparciem – 14.04.

dodany: 09.05.2013 | tagi: , ,

Nowe wydanie phpMyAdmin 4.0.0.0 do zarządzania bazami MySQL

0

Ukazało się nowe wydanie phpMyAdmin, otwartoźródłowego narzędzia do zarządzania bazami i użytkownikami MySQL z poziomu przeglądarki internetowej.

Wersja 4.0.0 zastępuje stary wygląd oparty na tabelkach nowym, wykorzystującym technologię AJAX i Javascript. Panel boczny potrafi teraz wyświetlić strukturę danej bazy danych. Odświeżono także wygląd dokumentacji. Ponadto naprawiono wiele błędów, związanych między innymi z importowaniem danych XML, załatano również 2 luki bezpieczeństwa.

Więcej informacji można znaleźć w pliku ChangeLog w kodzie projektu.

 

dodany: 10.12.2012 | tagi: , ,

Jak tworzyć kopię zapasową bazy danych MySQL

26

Stare, chińskie przysłowie mówi, że ludzie dzielą się na tych, którzy robią backup i tych, którzy będą go robić… Backup standardowych danych nie przysparza na ogół nikomu problemów – jedynie sposób wykonywania kopii zapasowej jest różny. Jedni robią backup ręcznie, a inni korzystają z gotowych narzędzi lub piszą skrypty. Niemniej wszystko sprowadza się do określenia listy plików lub katalogów źródłowych i miejsca docelowego. Co jednak z bazą danych? Twórcy stron www, programiści, czy hobbyści, a nawet uczniowie i studenci, często wykorzystują bazy danych. Najpopularniejszym, wykorzystywanym przez nich silnikiem baz danych, jest zaś MySQL. Robiąc backup swoich danych czy to prywatnych, służbowych, czy danych klienta, trzeba pamiętać też o kopii zapasowej baz danych.

Kopie zapasowe baz danych, podobnie jak kopie zapasowe plików i katalogów, można robić na piechotę. Można logować się po kolei do każdej bazy i ją eksportować. Przy jednej lub kilku bazach danych, jest to wykonalne i nie jest to problemem logistycznym. Po co jednak się męczyć, skoro można użyć automatu? Szczególnie, gdy mamy do zrobienia kopię zapasową kilkunastu czy kilkudziesięciu baz danych?

Opiszemy Wam prosty, łatwy i szybki sposób na robienie kopii zapasowych baz danych MySQL. Należy jednak mieć na uwadze, że nie jest to mechanizm przeznaczony do backupowania olbrzymich baz danych serwisów wystawionych na działanie dużego ruchu.

Narzędzie, którego użyjemy w tym poradniku, to AutoMySQLBackup. Projekt został zainicjowany w 2004 roku  w serwisie SourceForge.net i jest w nim rozwijany po dziś dzień. AutoMySQLBackup jest niezwykle popularnym narzędziem (a właściwie skryptem) – co tydzień pobierany jest ponad 1000 razy i posiada ponad 300 rekomendacji. Narzędzie to zostało docenione nie tylko przez użytkowników baz danych MySQL, ale także przez twórców dystrybucji systemu Linux – AutoMySQLBackup znajdziemy w repozytoriach najpopularniejszych dystrybucji.

AutoMySQLBackup to skrypt, który możemy uruchamiać zarówno na serwerze, jak i lokalnie na komputerze. Skrypt może działać lokalnie (kiedy uruchomimy go na tym samym serwerze, na którym działa baza danych) oraz zdalnie (możemy uruchamiać go na innym serwerze lub na naszym komputerze). Rozwiązanie w którym skrypt działa na tym samym serwerze co baza danych wydaje się być na pierwszy rzut oka niewłaściwe i przeczące sensowi tworzenia kopii zapasowych, ale należy pamiętać, że backup bazy danych ma postać pliku, a ten możemy następnie załączyć do kopii zapasowej plików. Rozwiązanie to zapobiega otwieraniu portów bazy danych MySQL na świat (security by obscurity).

Na potrzeby poradnika założymy, że będziemy uruchamiać AutoMySQLBackup na naszym serwerze, który pracuje pod kontrolą systemu operacyjnego Debian lub Ubuntu – np. tego samego, który jest przedmiotem innej serii naszych poradników.

Pakiet automysqlbackup znajduje się zarówno w repozytoriach stabilnego Debiana oraz Ubuntu LTS, jak i w repozytoriach Debiana Testing oraz aktualnej wersji Ubuntu (12.10).

Instalacja (jako root):

Konfiguracja AutoMySQLBackup odbywa się przez edycję opcji skryptu w pliku /etc/default/automysqlbackup. Przechodzimy zatem do edycji tego pliku przy użyciu preferowanego edytora (my preferujemy vim, edytujemy jako root):

Choć w aktualnej wersji plik konfiguracyjny AutoMySQLBackup to prawie 300 linii, nie ma się co przerażać ani tym bardziej martwić. Nas interesuje raptem kilka opcji. Pierwszą z nich, jest opcja określająca adres serwera bazy danych, którą chcemy backupować. W naszym przypadku, tak jak wcześniej wyjaśniliśmy, jest to localhost (host lokalny).

Skrypt może wykonać kopie zapasowe baz danych, które mu określimy. Domyślna konfiguracja skryptu zawiera jednak pewien „hack”, który polega na sprawdzeniu nazw baz danych na danym serwerze i dołączenie ich wszystkich do kopii zapasowej. Uprzedzając ewentualne pytania o bazę danych o nazwie mysql – ta baza nie jest dołączana do kopii zapasowej.

Jeśli zatem chcemy wykonać kopię zapasową wszystkich baz danych, to pozostawiamy konfigurację jak poniżej:

Gdybyśmy chcieli wykonać kopię zapasową określonych baz danych, konfiguracja wyglądałaby tak (gdzie baza1, baza2 i mojabaza to nazwy baz danych, które mają być dołączone do kopii zapasowej):

Opisana powyżej opcja dotyczy kopii codziennych i cotygodniowych. Kopia comiesięczna zawiera te same bazy danych co kopie codzienne i cotygodniowe oraz bazę danych o nazwie mysql.

Ważnym krokiem jest określenie miejsca docelowego dla kopii zapasowej. Może to być katalog lokalny, skąd następnie pliki będą dołączane do kopii zapasowej plików, ale może to być zdalny katalog, który zamontujemy np. za pomocą SSHFS lub NFS. Wtedy backup bazy danych wędruje od razu na zdalny serwer, a przy tym nie musimy wystawiać portów bazy danych na zewnątrz. Domyślna konfiguracja wskazuje jako miejsce docelowe lokalizację /var/lib/automysqlbackup. My umieścimy naszą kopię zapasową w innym katalogu (/home/backup/mysql):

Ostatnią opcją, która powinna nas zainteresować, jest adres e-mail, który zostanie użyty jako odbiorca powiadomień. Jeżeli na serwerze nie jest zainstalowany POSTFIX, to APT będzie próbował go zainstalować podczas instalacji AutoMySQLBackup.

Uruchomienie mechanizmu tworzenia kopii zapasowej wywoływane jest komendą:

Oczywiście nie trzeba wywoływać tego polecenia ręcznie, codziennie. Podczas instalacji, dodane zostało zadanie crona (/etc/cron.daily/automysqlbackup), które uruchamia się automatycznie raz na dobę.

Po uruchomieniu zadania kopii zapasowej po raz pierwszy, zauważycie, że skrypt utworzył w katalogu docelowym kopii zapasowej nowe podkatalogi:

AutoMySQLBackup  tworzy wewnątrz tych katalogów archiwa kopii zapasowych baz danych:

Archiwum jest skompresowane. Niemniej należy pamiętać, że z każdą kolejną kopią, repozytorium „puchnie”, więc należy zapewnić sobie odpowiednią ilość przestrzeni dyskowej.

Przywracanie kopii zapasowej

Czymże byłaby kopia zapasowa i narzędzie, które ułatwia jej tworzenie, bez możliwości łatwego jej przywrócenia? Przywracanie kopii zapasowej bazy danych, utworzonej przez AutoMySQLBaclup, wymaga jedynie dwóch komend. Najpierw należy rozpakować archiwum kopii, którą chcemy przywrócić (na przykład):

Wynikiem będzie plik test_2012-12-10_13h03m.poniedzialek.sql w katalogu /var/lib/automysqlbackup/daily/test/. Jest to plik zrzutu bazy danych. Teraz należy go przywrócić za pomocą konsoli MySQL lub narzędzia, takiego jak np. PHPMyAdmin:

dodany: 04.12.2012 | tagi: , ,

Problemów MySQL ciąg dalszy

10

Dzisiaj pisaliśmy o dość poważnej luce w zabezpieczeniach MySQL. Niestety nie jest to jedyny „świeży” problem popularnego silnika bazy danych. Haker o pseudonimie Kingscope przedstawił ciekawą metodę szybkiego łamania haseł. W przeciwieństwie do tradycyjnej metody słownikowej, ta pozwala na testowanie nawet 5 tysięcy haseł w ciągu sekundy! Warunkiem skorzystania z tej metody jest posiadanie jakiegokolwiek konta dostępowego do bazy, które nie musi być uprzywilejowane.

Jeśli takowe mamy, to do przyspieszonego „odgadnięcia” hasła bazy, posługujemy się następującym skryptem w Perlu:

Oczywiście jeśli chcemy przetestować powyższy skrypt musimy zmienić nazwę atakowanej bazy, adres IP hosta oraz wprowadzić nasze poświadczenia (nazwa użytkownika oraz hasło).

Powyższy sposób wykorzystuje komendę ‚change_user’, która po zalogowaniu do bazy pozwala w szybki sposób sprawdzić poprawność hasła, nawet w przypadku połączenia sieciowego do bazy. Kingscope do stworzenia listy haseł użył darmowego crakera John The Ripper oraz udokumentował przykładowy atak na czteroznakowe hasło – wynik co najmniej powalający, gdyż jego złamanie zajęło zaledwie 20 sekund, co przekłada się na 100 tysięcy przetestowanych kombinacji.

Oto wynik udokumentowanego ataku:

C:\Users\kingcope\Desktop>C:\Users\kingcope\Desktop\john179\run\john
–incremental –stdout=5 | perl mysqlcrack.pl
Warning: MaxLen = 8 is too large for the current hash type, reduced to 5
words: 16382 time: 0:00:00:02 w/s: 6262 current: citcH
words: 24573 time: 0:00:00:04 w/s: 4916 current: rap
words: 40956 time: 0:00:00:07 w/s: 5498 current: matc3
words: 49147 time: 0:00:00:09 w/s: 5030 current: 4429
words: 65530 time: 0:00:00:12 w/s: 5354 current: ch141
words: 73721 time: 0:00:00:14 w/s: 5021 current: v3n
words: 90104 time: 0:00:00:17 w/s: 5277 current: pun2
[*] Cracked! –> pass
words: 98295 time: 0:00:00:18 w/s: 5434 current: 43gs
Session aborted

Przewagą tej metody, nad dotychczasową słownikową, jest fakt, że w tej drugiej po każdym niepoprawnym podaniu hasła, musimy ponownie połączyć się z bazą danych, natomiast w metodzie opracowanej przez hakera Kingscope sesja nie jest zrywana.
Całe szczęście, że nie można skorzystać z tej metody, bez posiadania konta do bazy, gdyż wtedy byłby naprawdę gorący zero-day dla MySQL.

dodany: 04.12.2012 | tagi: , , ,

Opublikowano luki Zero-day w bazach MySQL

0

Odkryto luki 0-day w oprogramowaniu bazy danych MySQL. Znalazły się tam luki oparte na przepełnieniu bufora stosu, przepełnieniu sterty, podniesieniu uprawnień, odmowaie usługi i zdalnej preautoryzowanej enumeracji użytkownika.

Odkryte luki:

CVE-2012-5611 – MySQL (Linux) przepełnienie bufora stosu

CVE-2012-5612 – MySQL (Linux) przepełnienie sterty

CVE-2012-5613 – MySQL (Linux) podniesienie uprawnień w bazie danych

CVE-2012-5614 – MySQL Denial of Service

CVE-2012-5615 – MySQL zdalna preautoryzowana enumeracja użytkownika

CVE-2012-5612 i CVE-2012-5614 mogą spowodować odmowę usługi (uszkodzenie usługi i awarię). CVE-2012-5615 pozwala atakującemu dowiedzieć się, jakie nazwy istnieją na serwerze MySQL, a jakie nie (odmowa dostępu).

Eric Romang na swoim blogu zamieścił demo wyk0rzystanai luki CVE-2012-5613:

Powyższe demo jest demonstracją opisu sposobu King Cope’a  na podniesienie uprawnień w bazie MySQL z systemem Linux. Luka pozwala na dodanie do bazy danych użytkownika mającego prawa administratora. Do poprawnego wykorzystania exploita atakujący musi już mieć użytkownika w bazie danych z przywilejami FILE. Daje to możliwość stworzenia pliku o uprawnieniach użytkownika mysql. Wtedy atakujący tworzy TRIGGER na jakiekolwiek zdarzenie w bazie. Mając już dostęp do plików (FILE) atakujący może dodać cokolwiek do pliku TRG. Zapisuje tam zapytanie SQL, które uruchamia się jako root@localhost.

Później atakujący powoduje uszkodzenie serwera MySQL i jego przeładowanie dzięki pomocy przepełnienia stosu, tak, żeby plik TRIGGERA został poprawnie wczytany i rozpoznany. Od teraz wykonanie każdego dowolnego zapytania SQL, uruchamiającego TRIGGER, pozwoli na wykonanie zapytania jako root@localhost.

Dzięki temu atakujący może podłączyć się jako nowy użytkownik i wykonać zrzut loginów i zhaszowanych haseł z tabeli mysql.user.

Błędy dotyczą wersji  baz danych MySQL 5 i kolejnych wydań.