Întărirea MySQL pentru site-ul dvs. WordPress

Publicat: 2023-01-18

WordPress, cel mai popular CMS, rulează pe MySQL, cea mai populară bază de date de acolo. Petrecerea timpului pentru a vă asigura că instalarea MySQL și instalarea configurației bazei de date WordPress sunt întărite în mod adecvat împotriva vectorilor de atac obișnuiți vă poate ajuta să reduceți riscurile. Acest lucru este valabil mai ales dacă vă gestionați singur serverul MySQL.

Este demn de remarcat faptul că multe instalări WordPress folosesc MariaDB, care este un furk al MySQL. Deoarece ambele funcționează foarte similar, vom folosi MySQL pentru a însemna atât MySQL, cât și MariaDB. Indiferent de versiunea RDMS pe care o executați, consolidarea MySQL vă poate ajuta să minimizați riscurile atacurilor de la hackeri. Cu toate acestea, aceasta nu înlocuiește alte măsuri de securitate, cum ar fi instalarea unui firewall pentru aplicații web, asigurându-vă că aveți cea mai recentă versiune de pluginuri, teme și WordPress și consolidarea WordPress.

Atenție , acest articol vizează MySQL 8.0 care rulează pe Linux (Ubuntu). În timp ce conceptele se vor traduce în alte sisteme de operare și versiuni MySQL/MariaDB, comenzile și căile de fișiere utilizate în aceste exemple pot diferi. Înainte de a face orice modificări la un sistem de producție, este recomandat să testați orice modificări într-un mediu de pregătire sau de pre-producție.

În acest articol, care se adresează în primul rând celor care își gestionează propriul MYSQL, oferim câteva sfaturi și tutoriale despre cum să securizeze MySQL. Chiar și așa, lista extinsă de bune practici prezentată în acest articol merită citită pentru oricine administrează site-uri web WordPress. Securizarea serverului dvs. MySQL este un pas critic în menținerea unui WordPress securizat și pentru a vă proteja de diferite tipuri de atacuri cu forță brută, injecție de malware și alte tipuri de atacuri.

Cuprins

  • Luați în considerare utilizarea unei baze de date ca serviciu (DBaaS
  • Păstrați MySQL la zi
  • Rulați MySQL pe o mașină dedicată
  • Legați MySQL la o adresă IP
  • Limitați utilizarea instrumentelor GUI bazate pe web
  • Rulați demonul MySQL folosind un utilizator dedicat
  • Utilizați scriptul mysql_secure_installation
  • Creați un utilizator dedicat bazei de date WordPress
  • Asigurați-vă că local_infile este dezactivat
  • Dezactivați istoricul comenzilor MySQL
  • Asigurați-vă că mysqld nu este pornit cu argumentul –skip-grant-tables
  • Faceți o copie de rezervă a bazei de date
    • Faceți backup frecvent
    • Verificați frecvent integritatea copiilor de rezervă
    • Stocați-vă copiile de siguranță în siguranță
  • Activarea și aplicarea conexiunilor TLS
    • Schimbați prefixul tabelului
    • Cum să implementezi modificările
    • Păstrarea WordPress în siguranță

Luați în considerare utilizarea unei baze de date ca serviciu (DBaaS)

Baza de date ca serviciu merită luată în considerare dacă nu găzduiți WordPress pe un plan gestionat. Acesta înlocuiește modelul tradițional de instalare locală a MySQL cu un serviciu la care vă conectați. Acest lucru s-ar putea potrivit pentru cazul dvs. de utilizare dacă rulați site-ul dvs. WordPress cu un furnizor de găzduire care oferă servicii de baze de date gestionate. Opțiunile disponibile includ, în general, Amazon RDS, DigitalOcean Managed MySQL și Linode Managed MySQL). La valoarea nominală, aceste servicii pot fi mai costisitoare decât să rulați singur MySQL. Cu toate acestea, ei fac toate sarcinile grele ale bazelor de date de producție. Cele mai multe servicii includ presetări pentru cele mai bune practici de securitate, corecții de securitate în curs și întreținere și copii de rezervă.

Utilizarea unei baze de date ca serviciu (DBaaS) este una dintre cele mai bune opțiuni în ceea ce privește securitatea și fiabilitatea. Deși acest lucru nu este obligatoriu, este totuși un bun de a avea. Cu toate acestea, dacă doriți să gestionați singur MySQL, următoarele este o colecție de sfaturi de întărire de care trebuie să aveți în vedere.

Păstrați MySQL la zi

Așa cum este important să vă asigurați că rulați cea mai recentă versiune de WordPress, este important să mențineți MySQL la zi. La fel ca majoritatea altor software-uri, actualizările pentru serverul MySQL sunt lansate periodic. Aceste actualizări abordează erorile, atenuează vulnerabilitățile și oferă noi funcții. Ar trebui să păstrați MySQL la zi cu cele mai recente corecții de securitate pentru a reduce riscurile de a rula software cu vulnerabilități cunoscute. Rețineți că, odată actualizat, vi se va cere să reporniți „daemonul mysql”. Acesta este un proces care poate implica anumite perioade de nefuncționare. Ca întotdeauna, planificați din timp.

Rulați MySQL pe o mașină dedicată

Multe instalări WordPress rulează MySQL, PHP și un server web (cum ar fi Nginx sau Apache HTTP Server) pe aceeași mașină. Acest lucru nu este optim – atât în ​​ceea ce privește performanța, cât și securitatea. În mod ideal, MySQL ar trebui să ruleze pe un server dedicat pentru a reduce raza de explozie a unui atac. Dacă un atacator reușește să compromită și să escaladeze privilegiile pe serverul web, ar fi mult mai greu pentru acel atacator să se miște lateral și să compromită și serverul MySQL.

Legați MySQL la o adresă IP

Puteți configura MySQL să accepte numai conexiuni TCP/IP de la o anumită interfață IPv4 sau IPv6. Tot ce trebuie să faceți este să setați opțiunea de configurare a adresei de legare la o anumită adresă IP. Acest lucru oferă controale și restricții suplimentare cu privire la modul în care aplicațiile client (în cazul nostru, WordPress) se pot conecta la MySQL. În mod prestabilit, această setare este setată la *, ceea ce înseamnă că MySQL din nou din cutie va asculta pe toate interfețele.

Dacă nu sunt configurate pentru a asculta un anumit IP, toate IP-urile pot fi folosite pentru a vă conecta la MySQL. Această setare este deosebit de importantă dacă rulați MySQL pe aceeași mașină cu un server web pe care îl expuneți la Internet (în acest caz, ar trebui să setați adresa de legătură la 127.0.0.1, astfel încât MySQL să asculte doar pe localhost) .

De exemplu, dacă doriți ca serverul MySQL să accepte doar conexiuni la o anumită adresă IPv4, puteți adăuga o intrare similară cu exemplul de mai jos. Ar trebui să introduceți acest lucru în grupul de opțiuni [mysqld] din fișierul de configurare /etc/mysql/mysql.conf.d/mysqld.cnf al serverului dumneavoastră.

bind-address=192.168.0.24

Rețineți că, odată ce setați acest lucru, va trebui să reconfigurați WordPress pentru a vă conecta la baza de date folosind această adresă IP (cu excepția cazului în care face acest lucru deja), deoarece conexiunile la alte adrese de gazdă a serverului nu ar fi permise.

Limitați utilizarea instrumentelor GUI bazate pe web

Multe instalări WordPress includ instrumente de management grafic front-end bazate pe web. Exemplele comune includ Cpanel, phpMyAdmin sau Adminer. Aceste instrumente facilitează gestionarea MySQL și a altor aspecte ale infrastructurii de bază. În timp ce o interfață grafică bazată pe web vă poate ajuta să vă gestionați bazele de date MySQL, aceste interfețe pot crește suprafața de atac prin adăugarea unui alt vector. În plus, există riscul ca acestea să fie descoperite și abuzate de atacatori pentru a rula interogări SQL distructive sau rău intenționate împotriva bazei de date. Atacurile pot duce chiar la preluarea completă a site-ului dvs. WordPress.

Singurul server sigur este cel care este oprit și deconectat – cu toate acestea, riscul poate fi gestionat. Dezinstalarea sistemelor necritice este o opțiune; cu toate acestea, acestea pot fi, de asemenea, blocate și restricționate pentru a minimiza riscul.

Este posibil să restricționați accesul la aceste instrumente într-o varietate de moduri. Puteți instala phpMyAdmin pentru WordPress de la distanță, minimizând astfel riscul pentru serverul web. Alternativ, ați putea dori, de asemenea, să luați în considerare utilizarea unor instrumente precum MySQL Workbench sau Beekeeper Studio pe mașina dvs. locală și să vă conectați la serverul de baze de date printr-un tunel SSH.

Rulați demonul MySQL folosind un utilizator dedicat

Ca și în cazul altor servicii care rulează pe un server, puteți rula demonul MySQL sub un utilizator dedicat. Când rulați MySQL folosind un utilizator dedicat, puteți defini cu precizie ce permisiuni îi sunt date utilizatorului în cadrul sistemului. Rularea MySQL sub un utilizator dedicat urmează, de asemenea, principiul celui mai mic privilegiu, deoarece aceasta reduce raza de explozie a unei vulnerabilități MySQL. De asemenea, scade posibilitatea de a profita de o configurare greșită, deoarece un utilizator cu restricții nu va putea accesa resurse care nu au legătură cu MySQL (cum ar fi configurațiile și secretele sistemului de operare).

Vestea bună este că instalările prin intermediul managerilor de pachete (cum ar fi apt sau yum) se ocupă de acest pas automat atunci când instalează MySQL. O modalitate rapidă de a verifica dacă MySQL rulează sub un utilizator dedicat este să rulați următoarele pe mașina care rulează demonul MySQL.

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

Dacă MySQL rulează folosind un utilizator dedicat, ar trebui să vă așteptați să vedeți returnată cel puțin o linie din rezultatul ps.

Utilizați scriptul mysql_secure_installation

Pachetul mysql-server vine cu un utilitar de script shell numit mysql_secure_installation. Puteți utiliza acest script pentru a configura un punct de pornire sigur pentru serverul MySQL. Ca atare, ar trebui să-l rulați după o nouă instalare a MySQL. Acest utilitar vă ajută să:

  • Setați o parolă pentru conturile root
  • Eliminați conturile root care sunt accesibile din afara localhost
  • Eliminați conturile de utilizator anonime
  • Eliminați baza de date de testare (care, în mod implicit, poate fi accesată de utilizatori anonimi)

Pentru a invoca mysql_secure_installation, rulați următoarea comandă:

sudo mysql_secure_installation

Odată ce începe procesul de configurare, vi se vor afișa mai multe solicitări care vă vor întreba dacă doriți să activați pluginul de validare a parolei , care este folosit pentru a testa puterea parolelor pe care le alegeți pentru utilizatorii MySQL. Este recomandat să activați acest plugin.

După ce activați pluginul de validare a parolei, scriptul vă va cere să specificați o politică de validare a parolei. Aici, ar trebui să alegeți o politică puternică de parole. Ulterior, vi se va cere să resetați parola utilizatorului root.

Apoi, scriptul vă va solicita să eliminați utilizatorii MySQL anonimi. Acest lucru este important pentru a reduce orice șansă ca atacatorii să obțină acces la serverul bazei de date utilizând un utilizator MySQL anonim.

Următorul prompt vă va întreba dacă doriți să dezactivați autentificarea folosind utilizatorul root atunci când vă autentificați de la distanță pe serverul MySQL. Autentificarea de la distanță folosind utilizatorul root este periculoasă și rareori necesară. În schimb, ar trebui să fie SSH pe MySQL și să utilizați clientul MySQL de pe server pentru a vă autentifica ca utilizator rădăcină sau, de preferință, să utilizați un tunel SSH pentru a redirecționa portul MySQL la distanță la mașina dvs. locală și a vă conecta folosind un client local.

În continuare, vi se va cere să ștergeți bazele de date implicite (dacă există) cu care MySQL este livrat. Aceasta este practica recomandată pentru serverele MySQL de producție.

Ștergeți baza de date implicită

În cele din urmă, veți fi întrebat dacă doriți să reîncărcați tabelele de privilegii pentru toate modificările care au fost aplicate.

Creați un utilizator dedicat bazei de date WordPress

Cele mai bune practici de securitate impun separarea utilizatorilor și privilegiilor în funcție de sarcini sau roluri. Aceasta înseamnă că fiecare aplicație care folosește baza de date ar trebui să aibă propriul utilizator dedicat, cu cantitatea minimă de permisiuni de bază de date MySQL necesare pentru a-și îndeplini sarcina. Ca atare, vă veți asigura că privilegiile utilizatorului nu depășesc ceea ce este necesar.

Această practică ar trebui să se extindă la implementările care rulează mai multe site-uri WordPress - fiecare site WordPress ar trebui să aibă propria sa bază de date dedicată și utilizator MySQL. Acest lucru asigură că în orice moment, doar un utilizator are acces la o bază de date la un moment dat, iar utilizatorii nu pot accesa alte baze de date, evitând accesul neautorizat și încălcarea datelor.

Următoarea instrucțiune SQL (înlocuiți <gazdă> și <parolă> și <bază de date> pentru a se potrivi nevoilor dvs.) poate fi utilizată pentru a crea un utilizator dedicat pentru site-ul dvs. WordPress și pentru a acorda privilegii pentru utilizare regulată. Rețineți că unele pluginuri, teme și actualizări WordPress pot necesita ocazional privilegii suplimentare pentru a funcționa corect (consultați ghidul oficial WordPress despre aceasta pentru mai multe informații)

Asigurați-vă că local_infile este dezactivat

Declarația LOAD DATA vă permite să încărcați fișiere de date în tabelele bazei de date. În anumite condiții, acest lucru poate fi abuzat pentru a citi fișiere de pe serverul MySQL. Ca atare, dacă nu aveți un caz de utilizare specific pentru acest lucru pe site-ul dvs. WordPress, ar trebui să dezactivați această funcție.

Dacă MySQL și serverul web rulează pe aceeași mașină, acesta poate permite unui atacator să folosească instrucțiunea LOAD DATA LOCAL pentru a citi fișiere arbitrare la care procesul serverului web are acces de citire. Aceasta presupune că un atacator are capacitatea de a rula instrucțiuni SQL arbitrare împotriva MySQL. Acesta poate fi cazul unei vulnerabilități de injectare SQL sau prin instalarea unui plugin WordPress rău intenționat. Acesta este încă un motiv pentru a vă păstra serverul web și serverele de baze de date separate.

În mod implicit, local_infile este dezactivat în MySQL 8.0 (obișnuia să fie activat implicit în versiunile anterioare de MySQL). Pentru a împiedica serverul MySQL să accepte instrucțiuni LOAD DATA LOCAL, asigurați-vă că demonul mysqld este pornit cu local_infile dezactivat.

Dezactivați istoricul comenzilor MySQL

Pe Linux, instrucțiunile de jurnalele client MySQL executate interactiv sunt salvate într-un fișier istoric (de obicei situat în $HOME/.mysql_history). Istoricul comenzilor MySQL ar trebui, în mod ideal, să fie dezactivat, deoarece acest lucru reduce probabilitatea de a expune informații sensibile, cum ar fi parolele, cheile de criptare sau alte secrete.

Pentru a verifica dacă fișierele .mysql_history nu există pe sistem, rulați următoarele comenzi:

găsiți /home -name „.mysql_history”
găsiți /root -name „.mysql_history”

Dacă comenzile de mai sus returnează orice rezultat, eliminați orice fișiere .mysql_history. În plus, puteți seta $HOME/.mysql_history ca link simbolic la /dev/null, după cum urmează:

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

Asigurați-vă că mysqld nu este pornit cu argumentul –skip-grant-tables

În cazul în care parola rădăcină a MySQL este greșită, deși nu este metoda preferată, unii administratori MySQL pot recurge la setarea MySQL pentru a începe cu argumentul –skip-grant-tables. La pornirea MySQL cu acest parametru, va evita verificarea tabelelor de grant atunci când un client se conectează sau execută o interogare, permițând efectiv oricui, oriunde (cu condiția să poată ajunge la baza de date prin rețea), să facă orice pe serverul bazei de date.

Pentru a vă asigura că –skip-grant-tables nu este activat, deschideți fișierul de configurare /etc/mysql/mysql.conf.d/mysqld.cnf al serverului și căutați skip-grant-tables. Valoarea fie nu trebuie setată, fie setată la skip-grant-tables = FALSE.

Faceți o copie de rezervă a bazei de date

Copierea de rezervă a bazei de date WordPress este absolut crucială pentru a vă putea recupera prompt după un dezastru sau un atac. Deși există o multitudine de modalități de a face copii de rezervă ale bazei de date WordPress – de la pluginuri și servicii de backup WordPress până la scripturi homegrown care efectuează o descărcare periodică a bazei de date – următoarele sunt câteva sfaturi importante de reținut.

Faceți backup frecvent

Efectuarea de backup-uri regulate este destul de evidentă și se explică de la sine - cu cât faceți mai des copii de siguranță ale bazei de date, cu atât vă va fi mai ușor să vă recuperați după un incident de pierdere de date. În timp ce frecvența copiilor de siguranță va depinde de tipul de site WordPress pe care îl rulați, ca regulă generală, efectuarea zilnică a unei copii de siguranță servește bine la majoritatea cazurilor de utilizare.

Verificați frecvent integritatea copiilor de rezervă

Copiile de rezervă sunt utile numai dacă funcționează. și probabil ați prefera să nu aflați în timp ce vă aflați în mijlocul unui incident care încearcă să recupereze date. Simpla remediere a acestui lucru este să verificați frecvent dacă backup-urile dvs. funcționează efectiv, efectuând restaurări de test din când în când. O modalitate bună de a face acest lucru este să setați un eveniment din calendar la fiecare câteva luni pentru a trece printr-o procedură de restaurare pentru a vă asigura că backup-urile funcționează în continuare conform așteptărilor. În plus, documentarea pașilor de restaurare a bazei de date este, de asemenea, o idee bună - cu cât sunt mai puține presupuneri atunci când răspundeți la un incident, cu atât mai bine.

Stocați-vă copiile de siguranță în siguranță

Nu păstrați niciodată copii de siguranță ale site-ului dvs. WordPress pe serverul dvs. web sau al bazei de date (în special pe serverul dvs. web). Backup-urile sunt un loc grozav pentru atacatori pentru a face scufundări în tomberon. Stocarea copiilor de rezervă într-o locație securizată în afara locației este foarte recomandabilă. Dacă efectuați depozitări periodice de baze de date, luați în considerare stocarea depozitelor de date pe un serviciu de stocare a obiectelor. Acestea pot include Amazon S3, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage etc. A urma această rută poate fi o modalitate excelentă și rentabilă de a stoca copiile de rezervă ale bazei de date. Cu toate acestea, aveți grijă să nu faceți găleata de stocare pe care o utilizați să fie accesibilă publicului.

Activarea și aplicarea conexiunilor TLS

Cu excepția cazului în care rulați MySQL pe aceeași mașină cu serverul dvs. web (care, așa cum am menționat deja mai sus, nu este o practică de securitate ideală), este foarte recomandat să criptați datele între WordPress și MySQL folosind Transport Layer Security (certificat TLS), denumit anterior Secure Socket Layer (certificat SSL).

În mod implicit, când instalați MySQL, acesta va genera automat un certificat autosemnat pentru dvs. Puteți verifica acest lucru rulând următoarele (în mod alternativ, puteți utiliza scriptul mysql_ssl_rsa_setup pentru a genera certificate noi).

Va trebui să copiați peste ca.pem din lista de mai sus (de exemplu, prin SCP) pe serverul care rulează site-ul dvs. WordPress. Odată ce încărcați fișierul ca.pem pe serverul dvs. WordPress, va trebui să mutați certificatul în depozitul de încredere de certificate al sistemului de operare și să actualizați magazinul de încredere pentru certificate, după cum urmează.

Atenție, numele de fișier al certificatului CA trebuie să se încheie cu o extensie de fișier .crt (de exemplu, mysql-ca.crt este valid, dar mysql-ca.pem.crt sau mysql-ca.pem sunt invalide).

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

Apoi, trebuie să configurați WordPress să utilizeze TLS atunci când vă conectați la MySQL, adăugând următoarele în fișierul wp-config.php al instalării WordPress.

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Odată ce actualizați wp-config.php, WordPress va iniția conexiuni la serverul dvs. MySQL folosind TLS.

Apoi, se recomandă să impuneți conexiunile TLS la serverul dvs. MySQL utilizând variabila de sistem require_secure_transport adăugând următoarele în fișierul dvs. /etc/mysql/mysql.conf.d/mysqld.cnf.

require_secure_transport = ON

În cele din urmă, reporniți MySQL pentru ca modificările să intre în vigoare.

systemctl reporniți mysql

Schimbați prefixul tabelului

În mod implicit, toate tabelele WordPress sunt create cu prefixul „wp_”. Acest lucru poate face mai ușor pentru atacatori să reușească anumite atacuri, cum ar fi injecția SQL, deoarece ar cunoaște numele tabelelor bazei de date. Deși acest lucru singur nu te va proteja, este un exercițiu simplu, recomandat de mulți ca cea mai bună practică de securitate WordPress.

Puteți schimba prefixul bazei de date în timpul procesului de instalare sau în orice moment ulterior, deși acesta din urmă este puțin mai complex. Oricum, puteți găsi tutoriale online despre schimbarea prefixului bazei de date WordPress.

Cum să implementezi modificările

Sperăm că acest articol v-a oferit o privire de ansamblu asupra întăririi securității MySQL în contextul rulării unui site web WordPress. Deși nu există niciun fel de gloanțe de argint în securitatea site-ului, cu ceva efort, adoptarea unei abordări stratificate, de apărare în profunzime a securității, va face atacarea site-ului dvs. web mult mai dificilă pentru atacatori.
În timp ce acest ghid prezintă o serie de tehnici de întărire pentru MySQL, MySQL este doar o componentă a ecosistemului WordPress. Ca atare, ar trebui să luați în considerare și alte aspecte ale securității WordPress acoperite în ghidul nostru de consolidare a securității WordPress. Acest lucru, împreună cu măsuri de securitate dovedite, cum ar fi autentificarea cu doi factori WordPress, vă va ajuta să vă asigurați că sunteți cât mai în siguranță.

Dacă vă simțiți că sunteți mult de luat, amintiți-vă că puteți (și probabil ar trebui) să aplicați treptat diferitele tehnici de întărire prezentate în acest ghid.

Păstrarea WordPress în siguranță

Rețineți că atacatorii sunt adesea după ținte slabe, deoarece nu trebuie să depună atât de mult efort în exploatarea site-urilor web slab securizate. A fi cu un pas înaintea poziției de securitate a următorului site web WordPress te face o țintă mai puțin atractivă.