Jak zabezpieczyć serwery MySQL/MariaDB

Po atakach na bazy danych MongoDB ostatnio zauważyliśmy również, że serwery MySQL są atakowane przez oprogramowanie ransomware. Nie powinno to dziwić, biorąc pod uwagę coraz powszechniejsze stosowanie chmur publicznych i prywatnych. Prowadzenie źle skonfigurowanej bazy danych w chmurze może stać się poważnym problemem.

W tym poście na blogu podzielimy się z Tobą szeregiem wskazówek dotyczących ochrony i zabezpieczania serwerów MySQL lub MariaDB.

Zrozumienie wektora ataku

Cytując SCMagazine:
„Atak rozpoczyna się od brutalnego wymuszenia hasła roota do bazy danych MySQL. Po zalogowaniu pobierane są bazy danych i tabele MySQL. Atakujący tworzy następnie nową tabelę o nazwie „OSTRZEŻENIE”, która zawiera kontaktowy adres e-mail, adres Bitcoin i żądanie płatności. ”

Na podstawie artykułu wektor ataku rozpoczyna się od odgadnięcia hasła root MySQL metodą brute-force. Atak brute-force polega na tym, że atakujący próbuje wielu haseł lub fraz z nadzieją, że w końcu odgadnie je poprawnie. Oznacza to, że krótkie hasła można zwykle wykryć dość szybko, ale dłuższe hasła mogą zająć dni lub miesiące.

Brute-force to powszechny atak, który przydarzyłby się każdej usłudze. Niestety dla MySQL (i wielu innych DBMS) nie ma gotowej funkcji, która wykrywa i blokuje ataki typu brute-force z określonych adresów podczas uwierzytelniania użytkownika. MySQL rejestruje jednak błędy uwierzytelniania w dzienniku błędów.

Przejrzyj swoją politykę dotyczącą haseł

Przeglądanie polityki haseł MySQL jest zawsze pierwszym krokiem do ochrony serwera. Hasło roota MySQL powinno być wystarczająco silne z kombinacją alfabetów, cyfr i symboli (co utrudnia zapamiętanie) i przechowywane w bezpiecznym miejscu. Zmieniaj hasło regularnie, przynajmniej co kwartał kalendarzowy. Biorąc pod uwagę wektor ataku, jest to najsłabszy punkt, na który atakują hakerzy. Jeśli cenisz swoje dane, nie przeocz tej części.

Wdrożenia MySQL wykonywane przez ClusterControl zawsze będą zgodne z najlepszymi praktykami bezpieczeństwa dostawcy, na przykład podczas GRANT nie będzie definiowany hosta z symbolami wieloznacznymi, a poufne dane logowania przechowywane w pliku konfiguracyjnym są dozwolone tylko dla użytkownika root systemu operacyjnego. Zdecydowanie zalecamy naszym użytkownikom określenie silnego hasła na etapie wdrażania.

W standardowym środowisku produkcyjnym serwery baz danych zwykle znajdują się w warstwie niższego poziomu. Ta warstwa powinna być chroniona i dostępna tylko z wyższej warstwy, takiej jak aplikacja lub system równoważenia obciążenia. Jeśli baza danych znajduje się w tym samym miejscu co aplikacja, możesz nawet zablokować adresy nielokalne i zamiast tego użyć pliku gniazda MySQL (mniej narzutu i bezpieczniej).

Kluczowe znaczenie ma tutaj konfiguracja parametru „bind-address”. Zwróć uwagę, że wiązanie MySQL jest ograniczone do braku, jednego lub wszystkich adresów IP (0.0.0.0) na serwerze. Jeśli nie masz wyboru i potrzebujesz MySQL do nasłuchiwania wszystkich interfejsów sieciowych, ogranicz dostęp do usługi MySQL ze znanych dobrych źródeł. Użyj aplikacji zapory lub grupy bezpieczeństwa, aby umieścić na białej liście dostęp tylko z hostów, które potrzebują bezpośredniego dostępu do bazy danych.

Czasami serwer MySQL musi być wystawiony na sieć publiczną w celach integracyjnych (np. monitorowanie, audyt, tworzenie kopii zapasowych itp.). W porządku, o ile narysujesz wokół niego ramkę. Nie pozwól niechcianym źródłom „zobaczyć” serwera MySQL. Możesz się założyć, ile osób na świecie wie, że 3306 jest domyślnym portem dla usługi MySQL, a po prostu wykonując skanowanie portu w odniesieniu do adresu sieciowego, atakujący może utworzyć listę ujawnionych serwerów MySQL w podsieci w mniej niż minutę. Zaleca się użycie niestandardowego portu MySQL, konfigurując parametr „port” w pliku konfiguracyjnym MySQL, aby zminimalizować ryzyko narażenia.

Przejrzyj zasady dotyczące użytkowników

Ogranicz niektórych użytkowników do posiadania krytycznych praw administracyjnych, w szczególności GRANT, SUPER i PROCESS. Możesz także włączyć super_read_only, jeśli serwer jest podrzędny, dostępny tylko w MySQL 5.7.8 i Percona Server 5.6.21 i nowszych (niestety nie w MariaDB). Po włączeniu serwer nie zezwoli na żadne aktualizacje, poza aktualizacją repozytoriów replikacji, jeśli logi statusu urządzenia podrzędnego są tabelami, nawet dla użytkowników z uprawnieniami SUPER. Usuń domyślną testową bazę danych i wszystkich użytkowników z pustymi hasłami, aby zawęzić zakres penetracji. Jest to jedna z kontroli bezpieczeństwa wykonywana przez ClusterControl, zaimplementowana jako doradca bazy danych.

Dobrym pomysłem jest również ograniczenie liczby połączeń dozwolonych do jednego konta. Możesz to zrobić, ustawiając zmienną max_user_connections w mysqld (domyślnie 0, równa nieograniczonej) lub używając opcji kontroli zasobów w instrukcjach GRANT/CREATE USER/ALTER USER. Instrukcja GRANT obsługuje ograniczanie liczby jednoczesnych połączeń z serwerem za pomocą konta, na przykład:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

Domyślna nazwa użytkownika administratora na serwerze MySQL to „root”. Hakerzy często próbują uzyskać dostęp do jego uprawnień. Aby znacznie utrudnić to zadanie, zmień nazwę „root” na inną. Nazwy użytkowników MySQL mogą mieć do 32 znaków (16 znaków przed MySQL 5.7.8). Możliwe jest użycie dłuższej nazwy użytkownika dla użytkownika superadministratora za pomocą instrukcji RENAME, jak pokazano poniżej:

mysql> RENAME USER root TO new_super_administrator_username;

Na marginesie dla użytkowników ClusterControl, ClusterControl musi znać użytkownika root i hasło MySQL, aby zautomatyzować i zarządzać serwerem bazy danych. Domyślnie będzie szukał „root”. Jeśli zmienisz nazwę użytkownika root na inną, określ „monitored_mysql_root_user={nowy_użytkownik}” w cmon_X.cnf (gdzie X to identyfikator klastra) i uruchom ponownie usługę CMON, aby zastosować zmianę.

Zasady tworzenia kopii zapasowych

Mimo że hakerzy stwierdzili, że odzyskasz swoje dane po zapłaceniu okupu, zwykle tak nie było. Zwiększenie częstotliwości tworzenia kopii zapasowych zwiększyłoby możliwość przywrócenia usuniętych danych. Na przykład zamiast tworzenia pełnej kopii zapasowej raz w tygodniu z codzienną przyrostową kopią zapasową można zaplanować tworzenie pełnej kopii zapasowej raz dziennie z godzinową kopią przyrostową. Możesz to łatwo zrobić dzięki funkcji zarządzania kopiami zapasowymi ClusterControl i przywrócić dane, jeśli coś pójdzie nie tak.

Jeśli masz włączone logi binarne (binlogs), to jeszcze lepiej. Możesz codziennie tworzyć pełną kopię zapasową i tworzyć kopie zapasowe dzienników binarnych. Binlogs są ważne przy odzyskiwaniu do określonego momentu i należy je regularnie tworzyć w ramach procedury tworzenia kopii zapasowych. DBA często pomijają tę prostą metodę, która jest warta każdego centa. Jeśli zostałeś zhakowany, zawsze możesz odzyskać dane do ostatniego punktu, zanim to się stało, pod warunkiem, że hakerzy nie wyczyścili dzienników binarnych. Zwróć uwagę, że czyszczenie dzienników binarnych jest możliwe tylko wtedy, gdy atakujący ma uprawnienia SUPER.

Jeszcze jedną ważną rzeczą jest to, że pliki kopii zapasowej muszą być możliwe do przywrócenia. Od czasu do czasu weryfikuj kopie zapasowe i unikaj przykrych niespodzianek, gdy musisz przywrócić.

Chroń swój serwer WWW/aplikacji

Cóż, jeśli wyizolowałeś swoje serwery MySQL, nadal istnieje szansa, że ​​atakujący uzyskają do nich dostęp za pośrednictwem serwera WWW lub aplikacji. Wstrzykując złośliwy skrypt (np. Cross-Site Scripting, SQL injection) do docelowej strony internetowej, można dostać się do katalogu aplikacji i mieć możliwość odczytania plików aplikacji. Mogą one zawierać poufne informacje, na przykład dane logowania do bazy danych. Patrząc na to, atakujący może po prostu zalogować się do bazy danych, usunąć wszystkie tabele i pozostawić w środku tabelę „okupu”. Nie musi to być użytkownik root MySQL, aby wykupić ofiarę.

Istnieją tysiące sposobów na złamanie zabezpieczeń serwera WWW i nie można w tym celu tak naprawdę zamknąć portu przychodzącego 80 lub 443. Kolejna warstwa ochrony jest wymagana do ochrony serwera WWW przed wstrzyknięciami opartymi na HTTP. Możesz użyć zapory aplikacji internetowych (WAF), takiej jak Apache ModSecurity, NAXSI (WAF dla nginx), WebKnight (WAF dla IIS) lub po prostu uruchomić swoje serwery internetowe w bezpiecznej sieci dostarczania treści (CDN), takiej jak CloudFlare, Akamai lub Amazon CloudFront.

Zawsze bądź na bieżąco

Prawdopodobnie słyszałeś o krytycznym exploitie zero-day MySQL, w którym nieuprzywilejowany użytkownik może zmienić się w superużytkownika? Brzmi przerażająco. Na szczęście wszyscy znani dostawcy zaktualizowali swoje repozytorium, aby uwzględnić poprawkę dotyczącą tego problemu.

Do użytku produkcyjnego zdecydowanie zaleca się zainstalowanie pakietów MySQL/MariaDB z repozytorium dostawcy. Nie polegaj na domyślnym repozytorium systemu operacyjnego, w którym pakiety są zwykle nieaktualne. Jeśli pracujesz w środowisku klastrowym, takim jak Galera Cluster lub nawet MySQL Replication, zawsze masz możliwość załatania systemu przy minimalnym przestoju. Zrób z tego rutynę i spróbuj maksymalnie zautomatyzować procedurę aktualizacji.

ClusterControl obsługuje stopniową aktualizację mniejszej wersji (jeden węzeł na raz) dla MySQL/MariaDB za pomocą jednego kliknięcia. Aktualizacja głównych wersji (np. z MySQL 5.6 do MySQL 5.7) zwykle wymaga odinstalowania istniejących pakietów, a automatyzacja jest ryzykownym zadaniem. W przypadku takiej aktualizacji konieczne jest staranne planowanie i testowanie.

Wniosek

Ransomware to pula złota, w której łatwo zarabiać. Prawdopodobnie w przyszłości zobaczymy więcej naruszeń bezpieczeństwa i lepiej jest podjąć działania, zanim coś się stanie. Hakerzy atakują wiele podatnych na ataki serwerów i jest bardzo prawdopodobne, że atak ten rozprzestrzeni się również na inne technologie baz danych. Ochrona Twoich danych to nieustanne wyzwanie dla administratorów baz danych. Prawdziwym wrogiem nie jest sprawca, ale nasze podejście do ochrony naszych krytycznych zasobów.