Wzmocnienie MySQL dla Twojej witryny WordPress

WordPress, najpopularniejszy CMS, działa na MySQL, najpopularniejszej bazie danych. Poświęcenie czasu na upewnienie się, że instalacja MySQL i instalacja konfiguracji bazy danych WordPress są odpowiednio zabezpieczone przed typowymi wektorami ataków, może pomóc zmniejszyć ryzyko. Jest to szczególnie prawdziwe, jeśli samodzielnie zarządzasz serwerem MySQL.

Warto zauważyć, że wiele instalacji WordPress korzysta z MariaDB, która jest rozwidleniem MySQL. Ponieważ oba działają bardzo podobnie, będziemy używać MySQL do oznaczania zarówno MySQL, jak i MariaDB. Bez względu na to, z jakiego systemu RDMS korzystasz, wzmocnienie bazy danych MySQL może pomóc zminimalizować ryzyko ataków hakerów. Nie zastępuje to jednak innych środków bezpieczeństwa, takich jak instalacja zapory sieciowej aplikacji internetowej, upewnienie się, że masz najnowszą wersję wtyczek, motywów i WordPressa oraz utwardzanie WordPressa.

W tym artykule, który jest skierowany przede wszystkim do osób zarządzających własnym MYSQL, oferujemy kilka wskazówek i samouczków dotyczących zabezpieczania MySQL. Mimo to obszerna lista najlepszych praktyk przedstawiona w tym artykule jest warta przeczytania dla każdego, kto zarządza witrynami WordPress. Zabezpieczenie serwera MySQL jest kluczowym krokiem w utrzymaniu bezpieczeństwa WordPress i ochronie przed różnymi typami ataków siłowych, wstrzykiwaniem złośliwego oprogramowania i innymi rodzajami ataków.

Spis treści

• Rozważ użycie bazy danych jako usługi (DBaaS
• Aktualizuj MySQL
• Uruchom MySQL na dedykowanej maszynie
• Powiąż MySQL z adresem IP
• Ogranicz korzystanie z internetowych narzędzi GUI
• Uruchom demona MySQL przy użyciu dedykowanego użytkownika
• Użyj skryptu mysql_secure_installation
• Utwórz dedykowanego użytkownika bazy danych WordPress
• Upewnij się, że local_infile jest wyłączone
• Wyłącz historię poleceń MySQL
• Upewnij się, że mysqld nie jest uruchamiany z argumentem –skip-grant-tables
• Wykonaj kopię zapasową bazy danych
• • Rób częste kopie zapasowe
  • Często sprawdzaj integralność kopii zapasowych
  • Bezpiecznie przechowuj kopie zapasowe
• Włącz i wymuszaj połączenia TLS
• • Zmień prefiks tabeli
  • Jak wdrażać zmiany
  • Dbanie o bezpieczeństwo WordPressa

Rozważ użycie bazy danych jako usługi (DBaaS)

Baza danych jako usługa jest warta rozważenia, jeśli nie hostujesz WordPressa w planie zarządzanym. Zastępuje tradycyjny model lokalnej instalacji MySQL usługą, z którą się łączysz. Może to pasować do twojego przypadku użycia, jeśli prowadzisz witrynę WordPress z dostawcą usług hostingowych, który oferuje usługi zarządzanych baz danych. Dostępne opcje na ogół obejmują Amazon RDS, DigitalOcean Managed MySQL i Linode Managed MySQL). Na pierwszy rzut oka usługi te mogą być droższe niż samodzielne uruchamianie MySQL. Jednak wykonują wszystkie ciężkie zadania związane z uruchamianiem baz danych klasy produkcyjnej. Większość usług obejmuje wstępne ustawienia najlepszych praktyk w zakresie bezpieczeństwa, bieżące poprawki i konserwację zabezpieczeń oraz kopie zapasowe.

Korzystanie z bazy danych jako usługi (DBaaS) jest jedną z najlepszych opcji pod względem bezpieczeństwa i niezawodności. Chociaż nie jest to obowiązkowe, nadal warto je mieć. Jeśli jednak chcesz samodzielnie zarządzać MySQL, poniżej znajdziesz zbiór wskazówek dotyczących utwardzania, o których warto pamiętać.

Aktualizuj MySQL

Tak jak ważne jest, aby upewnić się, że korzystasz z najnowszej wersji WordPress, ważne jest, aby aktualizować MySQL. Podobnie jak w przypadku większości innych programów, aktualizacje serwera MySQL są wydawane okresowo. Te aktualizacje usuwają błędy, ograniczają luki w zabezpieczeniach i udostępniają nowe funkcje. Powinieneś aktualizować MySQL za pomocą najnowszych poprawek bezpieczeństwa, aby zmniejszyć ryzyko uruchamiania oprogramowania ze znanymi lukami w zabezpieczeniach. Pamiętaj, że po aktualizacji będziesz musiał ponownie uruchomić „demon mysql”. Jest to proces, który może powodować pewne przestoje. Jak zawsze, planuj z wyprzedzeniem.

Uruchom MySQL na dedykowanej maszynie

Wiele instalacji WordPress obsługuje MySQL, PHP i serwer WWW (taki jak Nginx lub Apache HTTP Server) na tej samej maszynie. Nie jest to optymalne – zarówno pod względem wydajności, jak i bezpieczeństwa. MySQL powinien idealnie działać na dedykowanym serwerze, aby zmniejszyć promień wybuchu ataku. Jeśli atakującemu uda się naruszyć i eskalować uprawnienia na serwerze WWW, będzie mu znacznie trudniej przejść w bok, a także narazić na szwank serwer MySQL.

Powiąż MySQL z adresem IP

Możesz skonfigurować MySQL tak, aby akceptował tylko połączenia TCP/IP z określonego interfejsu IPv4 lub IPv6. Wszystko, co musisz zrobić, to ustawić opcję konfiguracyjną bind-address na konkretny adres IP. Zapewnia to dodatkową kontrolę i ograniczenia dotyczące sposobu, w jaki aplikacje klienckie (w naszym przypadku WordPress) mogą łączyć się z MySQL. Domyślnie to ustawienie jest ustawione na *, co oznacza, że ​​gotowy MySQL będzie nasłuchiwał na wszystkich interfejsach.

Jeśli nie skonfigurowano nasłuchiwania określonego adresu IP, wszystkie adresy IP mogą być używane do łączenia się z MySQL. To ustawienie jest szczególnie ważne, jeśli używasz MySQL na tej samej maszynie, co serwer WWW, który udostępniasz Internetowi (w takim przypadku powinieneś ustawić adres powiązania na 127.0.0.1, aby MySQL nasłuchiwał tylko na hoście lokalnym) .

Na przykład, jeśli chcesz, aby serwer MySQL akceptował tylko połączenia na określonym adresie IPv4, możesz dodać wpis podobny do poniższego przykładu. Powinieneś wprowadzić to w grupie opcji [mysqld] w pliku konfiguracyjnym /etc/mysql/mysql.conf.d/mysqld.cnf twojego serwera.

adres powiązania=192.168.0.24

Pamiętaj, że po ustawieniu tej opcji będziesz musiał ponownie skonfigurować WordPress, aby łączył się z bazą danych przy użyciu tego adresu IP (chyba że już to robi), ponieważ połączenia na innych adresach hostów serwerów nie byłyby dozwolone.

Ogranicz korzystanie z internetowych narzędzi GUI

Wiele instalacji WordPress zawiera graficzne narzędzia do zarządzania oparte na sieci. Typowe przykłady to Cpanel, phpMyAdmin lub Adminer. Te narzędzia ułatwiają zarządzanie MySQL i innymi aspektami podstawowej infrastruktury. Chociaż interfejs graficzny oparty na sieci Web może pomóc w zarządzaniu bazami danych MySQL, interfejsy te mogą zwiększyć powierzchnię ataku, dodając kolejny wektor. Ponadto istnieje ryzyko, że zostaną one wykryte i wykorzystane przez osoby atakujące do wykonywania destrukcyjnych lub złośliwych zapytań SQL w bazie danych. Ataki mogą nawet skutkować całkowitym przejęciem Twojej witryny WordPress.

Jedynym bezpiecznym serwerem jest ten, który jest wyłączony i odłączony od sieci – jednak można zarządzać ryzykiem. Odinstalowanie systemów niekrytycznych to jedna z opcji; jednak można je również zablokować i ograniczyć, aby zminimalizować ryzyko.

Dostęp do tych narzędzi można ograniczyć na różne sposoby. Możesz zdalnie zainstalować phpMyAdmin dla WordPress, minimalizując w ten sposób ryzyko dla serwera WWW. Alternatywnie możesz również rozważyć użycie narzędzi takich jak MySQL Workbench lub Beekeeper Studio na komputerze lokalnym i połączyć się z serwerem bazy danych przez tunel SSH.

Uruchom demona MySQL przy użyciu dedykowanego użytkownika

Podobnie jak w przypadku innych usług działających na serwerze, demona MySQL można uruchomić pod dedykowanym użytkownikiem. Uruchamiając MySQL przy użyciu dedykowanego użytkownika, możesz precyzyjnie określić, jakie uprawnienia ma dany użytkownik w systemie. Uruchamianie MySQL pod dedykowanym użytkownikiem jest również zgodne z zasadą najmniejszych uprawnień, ponieważ zmniejsza to promień wybuchu luki w zabezpieczeniach MySQL. Zmniejsza to również możliwość wykorzystania błędnej konfiguracji, ponieważ ograniczony użytkownik nie będzie mógł uzyskać dostępu do zasobów niezwiązanych z MySQL (takich jak konfiguracje systemu operacyjnego i tajne informacje).

Dobrą wiadomością jest to, że instalacje za pośrednictwem menedżerów pakietów (takich jak apt lub yum) zajmują się tym krokiem automatycznie podczas instalacji MySQL. Szybkim sposobem sprawdzenia, czy MySQL działa pod dedykowanym użytkownikiem, jest uruchomienie następującego na komputerze z uruchomionym demonem MySQL.

ps -ef | egrep „^mysql.*$”

Jeśli MySQL działa przy użyciu dedykowanego użytkownika, powinieneś spodziewać się zwrócenia co najmniej jednej linii z danych wyjściowych ps.

Użyj skryptu mysql_secure_installation

Pakiet mysql-server jest dostarczany z narzędziem skryptowym powłoki o nazwie mysql_secure_installation. Możesz użyć tego skryptu, aby skonfigurować bezpieczny punkt startowy dla serwera MySQL. W związku z tym należy go uruchomić po świeżej instalacji MySQL. To narzędzie pomaga:

• Ustaw hasło dla kont root
• Usuń konta root, które są dostępne z zewnątrz localhost
• Usuń anonimowe konta użytkowników
• Usuń testową bazę danych (do której domyślnie mają dostęp anonimowi użytkownicy)

Aby wywołać mysql_secure_installation, uruchom następujące polecenie:

sudo mysql_secure_installation

Po rozpoczęciu procesu instalacji zostanie wyświetlonych kilka monitów z pytaniem, czy chcesz włączyć wtyczkę sprawdzania poprawności hasła , która służy do testowania siły haseł wybieranych dla użytkowników MySQL. Zaleca się włączenie tej wtyczki.

Po włączeniu wtyczki sprawdzania poprawności hasła skrypt poprosi o określenie zasad sprawdzania poprawności hasła. Tutaj powinieneś wybrać silną politykę haseł. Następnie zostaniesz poproszony o zresetowanie hasła użytkownika root.

Następnie skrypt poprosi o usunięcie anonimowych użytkowników MySQL. Jest to ważne, aby zmniejszyć wszelkie szanse atakującego na uzyskanie dostępu do serwera bazy danych poprzez wykorzystanie anonimowego użytkownika MySQL.

Następny monit zapyta, czy chcesz wyłączyć logowanie przy użyciu użytkownika root podczas zdalnego uwierzytelniania na serwerze MySQL. Zdalne uwierzytelnianie przy użyciu użytkownika root jest niebezpieczne i rzadko wymagane. Zamiast tego powinieneś albo połączyć się przez SSH z MySQL i użyć klienta MySQL na serwerze, aby uwierzytelnić się jako użytkownik root, albo, najlepiej, użyć tunelu SSH, aby przekazać zdalny port MySQL do komputera lokalnego i połączyć się za pomocą lokalnego klienta.

Następnie zostaniesz poproszony o usunięcie domyślnych baz danych (jeśli istnieją), z którymi dostarczany jest MySQL. Jest to zalecana praktyka dla produkcyjnych serwerów MySQL.

Na koniec zostaniesz zapytany, czy chcesz ponownie załadować tabele uprawnień dla wszystkich zastosowanych zmian, aby odniosły one skutek.

Utwórz dedykowanego użytkownika bazy danych WordPress

Najlepsze praktyki w zakresie bezpieczeństwa nakazują segregację użytkowników i uprawnień według obowiązków lub ról. Oznacza to, że każda aplikacja korzystająca z bazy danych powinna mieć własnego dedykowanego użytkownika z minimalną liczbą uprawnień do bazy danych MySQL wymaganych do wykonania jej zadania. W ten sposób zapewnisz, że uprawnienia użytkownika nie wykraczają poza to, co jest wymagane.

Ta praktyka powinna obejmować wdrożenia z wieloma witrynami WordPress — każda witryna WordPress powinna mieć własną dedykowaną bazę danych i użytkownika MySQL. Gwarantuje to, że w danym momencie tylko jeden użytkownik ma dostęp do jednej bazy danych, a użytkownicy nie mogą uzyskiwać dostępu do innych baz danych, co pozwala uniknąć nieautoryzowanego dostępu i naruszeń danych.

Poniższa instrukcja SQL (zastąp <host> i <hasło> oraz <database> w zależności od potrzeb) może zostać wykorzystana do stworzenia dedykowanego użytkownika dla Twojej witryny WordPress i przyznania uprawnień do regularnego użytkowania. Pamiętaj, że niektóre wtyczki, motywy i aktualizacje WordPress mogą czasami wymagać dodatkowych uprawnień do prawidłowego działania (więcej informacji znajdziesz w oficjalnych wskazówkach WordPress na ten temat)

Upewnij się, że local_infile jest wyłączone

Instrukcja LOAD DATA umożliwia ładowanie plików danych do tabel bazy danych. W określonych warunkach może to zostać wykorzystane do odczytu plików z serwera MySQL. W związku z tym, chyba że masz konkretny przypadek użycia w swojej witrynie WordPress, powinieneś wyłączyć tę funkcję.

Jeśli MySQL i serwer WWW działają na tej samej maszynie, atakujący może użyć instrukcji LOAD DATA LOCAL do odczytania dowolnych plików, do których proces serwera WWW ma dostęp do odczytu. Zakłada się, że osoba atakująca ma możliwość uruchamiania dowolnych instrukcji SQL przeciwko MySQL. Może tak być w przypadku luki w zabezpieczeniach SQL Injection lub instalacji złośliwej wtyczki WordPress. Jest to kolejny powód, aby oddzielić serwer WWW i serwery baz danych.

Domyślnie local_infile jest wyłączone w MySQL 8.0 (kiedyś było domyślnie włączone we wcześniejszych wersjach MySQL). Aby uniemożliwić serwerowi MySQL akceptowanie instrukcji LOAD DATA LOCAL, upewnij się, że demon mysqld został uruchomiony z wyłączoną funkcją local_infile.

Wyłącz historię poleceń MySQL

W systemie Linux instrukcje dzienników klienta MySQL wykonywane interaktywnie są zapisywane w pliku historii (zwykle zlokalizowanym w $HOME/.mysql_history). Najlepiej byłoby, gdyby historia poleceń MySQL była wyłączona, ponieważ zmniejsza to prawdopodobieństwo ujawnienia poufnych informacji, takich jak hasła, klucze szyfrowania lub inne tajemnice.

Aby sprawdzić, czy pliki .mysql_history nie istnieją w systemie, uruchom następujące polecenia:

znajdź /home -nazwa „.mysql_history”
znajdź /root -nazwa „.mysql_history”

Jeśli powyższe polecenia zwrócą jakiekolwiek dane wyjściowe, usuń wszystkie pliki .mysql_history. Dodatkowo możesz ustawić $HOME/.mysql_history jako dowiązanie symboliczne do /dev/null w następujący sposób:

ln -s /dev/null $HOME/.mysql_history

Upewnij się, że mysqld nie jest uruchamiany z argumentem –skip-grant-tables

Jeśli hasło roota MySQL zostanie zgubione, chociaż nie jest to preferowana metoda, niektórzy administratorzy MySQL mogą uciekać się do ustawienia MySQL tak, aby zaczynał się od argumentu –skip-grant-tables. Uruchamiając MySQL z tym parametrem, unikniesz sprawdzania swoich tabel grantów, gdy klient łączy się lub uruchamia zapytanie, skutecznie pozwalając każdemu, gdziekolwiek (pod warunkiem, że może połączyć się z bazą danych przez sieć), na zrobienie czegokolwiek na serwerze bazy danych.

Aby upewnić się, że opcja –skip-grant-tables nie jest włączona, otwórz plik konfiguracyjny /etc/mysql/mysql.conf.d/mysqld.cnf serwera i wyszukaj skip-grant-tables. Wartość nie powinna być ustawiona lub ustawiona na skip-grant-tables = FALSE.

Wykonaj kopię zapasową bazy danych

Tworzenie kopii zapasowej bazy danych WordPress jest absolutnie niezbędne, aby móc szybko odzyskać siły po katastrofie lub ataku. Chociaż istnieje mnóstwo sposobów tworzenia kopii zapasowych bazy danych WordPress – od wtyczek i usług do tworzenia kopii zapasowych WordPress po własne skrypty, które okresowo wykonują zrzut bazy danych – poniżej znajduje się kilka istotnych wskazówek, o których należy pamiętać.

Rób częste kopie zapasowe

Regularne tworzenie kopii zapasowych jest dość oczywiste i oczywiste — im częściej tworzysz kopie zapasowe bazy danych, tym łatwiej będzie odzyskać dane po incydencie utraty danych. Chociaż częstotliwość tworzenia kopii zapasowych będzie zależeć od typu witryny WordPress, z reguły codzienne tworzenie kopii zapasowych dobrze służy większości przypadków użycia.

Często sprawdzaj integralność kopii zapasowych

Twoje kopie zapasowe są przydatne tylko wtedy, gdy działają. i prawdopodobnie wolałbyś się o tym nie dowiedzieć, gdy jesteś w środku incydentu próbującego odzyskać dane. Prostym rozwiązaniem tego problemu jest częste sprawdzanie, czy kopie zapasowe faktycznie działają, co jakiś czas przeprowadzając przywracanie testowe. Dobrym sposobem na to jest ustawienie wydarzenia w kalendarzu co kilka miesięcy, aby przejść przez procedurę przywracania, aby upewnić się, że kopie zapasowe nadal działają zgodnie z oczekiwaniami. Ponadto dobrym pomysłem jest dokumentowanie kroków przywracania bazy danych — im mniej zgadywania podczas reagowania na incydent, tym lepiej.

Bezpiecznie przechowuj kopie zapasowe

Nigdy nie przechowuj kopii zapasowych swojej witryny WordPress na serwerze internetowym lub serwerze bazy danych (zwłaszcza na serwerze internetowym). Kopie zapasowe to świetne miejsce, w którym atakujący mogą nurkować w śmietniku. Przechowywanie kopii zapasowych w bezpiecznej lokalizacji poza siedzibą firmy jest wysoce zalecane. Jeśli wykonujesz okresowe zrzuty bazy danych, rozważ przechowywanie zrzutów bazy danych w usłudze obiektowej pamięci masowej. Mogą to być Amazon S3, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage itp. Ta trasa może być świetnym, ekonomicznym sposobem przechowywania kopii zapasowych bazy danych. Zachowaj jednak szczególną ostrożność, aby nie udostępniać publicznie zasobnika, z którego korzystasz.

Włącz i wymuszaj połączenia TLS

O ile nie korzystasz z MySQL na tej samej maszynie, co serwer WWW (co, jak już omówiliśmy powyżej, nie jest idealną praktyką bezpieczeństwa), zdecydowanie zaleca się szyfrowanie danych między WordPress i MySQL przy użyciu Transport Layer Security (certyfikat TLS), dawniej określany jako Secure Socket Layer (certyfikat SSL).

Domyślnie podczas instalacji MySQL automatycznie wygeneruje on dla Ciebie certyfikat z podpisem własnym. Możesz to sprawdzić, uruchamiając następujące czynności (alternatywnie możesz użyć skryptu mysql_ssl_rsa_setup do wygenerowania nowych certyfikatów).

Będziesz musiał skopiować ca.pem z powyższej listy (na przykład przez SCP) na serwer, na którym działa Twoja witryna WordPress. Po przesłaniu pliku ca.pem na serwer WordPress konieczne będzie przeniesienie certyfikatu do magazynu zaufanych certyfikatów systemu operacyjnego i zaktualizowanie magazynu zaufanych certyfikatów w następujący sposób.

sudo mv ca.pem /usr/local/share/ca-certificates/mysql-ca.crt
sudo update-ca-certyfikaty

Następnie musisz skonfigurować WordPress, aby używał TLS podczas łączenia się z MySQL, dodając następujące elementy do pliku wp-config.php instalacji WordPress.

zdefiniuj („MYSQL_CLIENT_FLAGS”, MYSQLI_CLIENT_SSL);

Po zaktualizowaniu wp-config.php WordPress zainicjuje połączenia z serwerem MySQL przy użyciu TLS.

Następnie zaleca się wymuszenie połączeń TLS z serwerem MySQL przy użyciu zmiennej systemowej require_secure_transport poprzez dodanie następującego elementu do pliku /etc/mysql/mysql.conf.d/mysqld.cnf.

require_secure_transport = WŁ

Na koniec uruchom ponownie MySQL, aby zmiany odniosły skutek.

systemctl uruchom ponownie mysql

Zmień prefiks tabeli

Domyślnie wszystkie tabele WordPress są tworzone z prefiksem „wp_”. Może to ułatwić atakującym odniesienie sukcesu w niektórych atakach, takich jak iniekcja SQL, ponieważ znaliby oni nazwy tabel bazy danych. Chociaż samo to cię nie ochroni, jest to proste ćwiczenie, zalecane przez wielu jako najlepsza praktyka bezpieczeństwa WordPress.

Możesz zmienić prefiks bazy danych podczas procesu instalacji lub w dowolnym momencie później, chociaż ten drugi proces jest nieco bardziej złożony. Tak czy inaczej, możesz znaleźć samouczki online dotyczące zmiany prefiksu bazy danych WordPress.

Jak wdrażać zmiany

Mamy nadzieję, że ten artykuł zawiera przegląd wzmacniania zabezpieczeń MySQL w kontekście prowadzenia witryny WordPress. Chociaż nie ma złotego środka w bezpieczeństwie witryn internetowych, przy pewnym wysiłku przyjęcie wielowarstwowego, dogłębnego podejścia do bezpieczeństwa sprawi, że atak na Twoją witrynę będzie znacznie trudniejszy dla atakujących.
Chociaż ten przewodnik przedstawia szereg technik wzmacniania MySQL, MySQL jest tylko jednym z elementów ekosystemu WordPress. W związku z tym powinieneś również wziąć pod uwagę inne aspekty bezpieczeństwa WordPress, omówione w naszym przewodniku zwiększania bezpieczeństwa WordPress. To, w połączeniu ze sprawdzonymi środkami bezpieczeństwa, takimi jak uwierzytelnianie dwuskładnikowe WordPress, pomoże Ci zapewnić maksymalne bezpieczeństwo.

Jeśli masz wrażenie, że to dużo do przyswojenia, pamiętaj, że możesz (i prawdopodobnie powinieneś) stopniowo stosować różne techniki utwardzania omówione w tym przewodniku.

Dbanie o bezpieczeństwo WordPressa

Należy pamiętać, że osoby atakujące często szukają miękkich celów, ponieważ nie muszą wkładać tak dużego wysiłku w wykorzystywanie słabo zabezpieczonych stron internetowych. Bycie o krok przed następną pozycją bezpieczeństwa witryny WordPress sprawia, że ​​jesteś mniej atrakcyjnym celem.