Răspuns scurt
- Protejezi un site WordPress ținând nucleul, temele și plugin-urile actualizate și ștergând tot ce nu folosești.
- Activezi autentificarea în doi pași la wp-admin și limitezi încercările de login pe wp-login.php și xmlrpc.php.
- Setezi permisiunile la 755 pentru directoare și 644 pentru fișiere, niciodată 777, și nu instalezi teme sau plugin-uri „nulled”.
- Faci backup înainte de fiecare actualizare și pui un WAF la nivel de hosting în fața site-ului.
- Permisiuni recomandate
- directoare 755, fișiere 644, wp-config.php 600
- Punctele lovite de brute force
- wp-login.php și xmlrpc.php
- Constanta care blochează editorul din panou
- DISALLOW_FILE_EDIT
- Înainte de orice update
- backup complet, fișiere și bază de date
De unde intră atacatorii într-un WordPress
Scanerele automate caută versiuni de plugin-uri cu vulnerabilități publicate și le exploatează în ore de la anunț, indiferent cât de mic e site-ul. Al doilea drum e wp-login.php, unde boții încearcă liste de parole scurse; xmlrpc.php permite sute de încercări într-o singură cerere. Al treilea e tema piratată, care vine cu cod ascuns ce deschide un shell sau injectează linkuri spam. Permisiunile 777 completează tabloul: orice cont de pe același server poate scrie în fișierele tale.
Ce faci concret, în ordinea impactului
Începi cu actualizările, pentru că ele închid vulnerabilitățile cunoscute. Urmează accesul: parole lungi, 2FA, limitare de login, dezactivarea xmlrpc.php dacă nu folosești aplicația mobilă. Apoi întărești fișierele: permisiuni corecte, DISALLOW_FILE_EDIT în wp-config.php, fără execuție PHP în wp-content/uploads. La final pui un WAF la nivel de hosting, care filtrează cererile rău intenționate înainte să ajungă la PHP, și verifici că backup-ul zilnic se poate restaura.
- Ștergi plugin-urile și temele dezactivate, nu doar le oprești
- Folosești un utilizator diferit de „admin” și PHP pe o versiune suportată
- Verifici săptămânal actualizările de securitate
Ce spune legislația din România
Dacă site-ul are formulare, conturi de client sau magazin, prelucrezi date personale și intri sub art. 32 GDPR, care cere măsuri tehnice adecvate riscului. ANSPDCP a sancționat în România lipsa acestor măsuri, deci un WordPress neactualizat care pierde date de client nu e doar o problemă tehnică. Un magazin care emite facturi prin e-Factura are și obligația de a păstra XML-urile transmise la ANAF, ceea ce face backup-ul o cerință legală.
Măsuri de protecție WordPress și ce blochează fiecare| Măsură | Ce atac oprește | Unde se configurează |
|---|
| Actualizări nucleu, teme, plugin-uri | Exploatarea vulnerabilităților publicate | Panoul WordPress sau WP-CLI |
|---|
| 2FA + limitare de login | Brute force pe wp-login.php | Plugin de autentificare |
|---|
| Dezactivare xmlrpc.php | Încercări în masă printr-o singură cerere | .htaccess sau serverul web |
|---|
| Permisiuni 755/644, DISALLOW_FILE_EDIT | Scriere și editare de fișiere din panou | Sistem de fișiere, wp-config.php |
|---|
| Blocare PHP în uploads | Execuția fișierelor încărcate | .htaccess sau serverul web |
|---|
| WAF la nivel de hosting | SQL injection, XSS, boți | Panoul de hosting |
|---|
Comenzi și configurări
Permisiuni corecte pentru un WordPressfind /var/www/exemplu.ro -type d -exec chmod 755 {} \;
find /var/www/exemplu.ro -type f -exec chmod 644 {} \;
chmod 600 /var/www/exemplu.ro/wp-config.php
wp-config.php: fără editor de fișiere din panoudefine('DISALLOW_FILE_EDIT', true);
define('FORCE_SSL_ADMIN', true);
.htaccess în wp-content/uploads: fără execuție PHP<FilesMatch "\.php$">
Require all denied
</FilesMatch>
Exemple practice
Magazin online din Cluj cu WooCommerce
Un plugin de slider neactualizat de un an a permis încărcarea unui fișier PHP în uploads; site-ul redirecționa clienții spre pagini de pariuri. Restaurarea din backup-ul zilnic, actualizarea și blocarea execuției PHP în uploads au rezolvat incidentul în aceeași zi.
Cabinet de avocatură din București
Utilizatorul „admin” cu o parolă de opt caractere a fost ghicit prin xmlrpc.php. Atacatorul a creat un cont ascuns de administrator și a publicat linkuri spam în articole vechi. 2FA și dezactivarea xmlrpc.php au oprit repetarea.
Greșeli frecvente
- Crezi că certificatul SSL securizează site-ul, deși HTTPS criptează doar transportul și nu protejează de plugin-uri vulnerabile.
- Instalezi teme nulled și le scanezi cu antivirusul de desktop, care nu vede PHP obfuscat.
- Setezi 777 pe wp-content pentru că „așa merge upload-ul”.
- Faci actualizări fără backup și descoperi că nu poți reveni când o temă se rupe.
Cum te ajută 4hosting
- Planurile cPanel includ certificat Let's Encrypt și backup zilnic, deci restaurarea după un incident pornește de la o copie de ieri.
- De la planul cPanel Advanced în sus ai lunar 1 oră de CyberSecurity inclusă; o ceri din panoul de client, secțiunea „Servicii DevOps”, de exemplu pentru un audit al permisiunilor.
- Serviciul WAF & DDoS pune reguli OWASP în fața site-ului și filtrează boții care lovesc wp-login.php.
Întrebări conexe
Ce fac dacă site-ul WordPress a fost deja spart?
Îl scoți temporar offline, schimbi toate parolele, inclusiv la baza de date și la FTP, restaurezi dintr-un backup anterior compromiterii și actualizezi tot înainte să-l repui online. Verifici utilizatorii cu rol de administrator și cron-urile din wp_options. Fără backup curat, cauți fișierele modificate recent.
Am nevoie de un plugin de securitate?
Un singur plugin bun pentru 2FA și limitarea încercărilor de login e suficient, dacă restul măsurilor sunt făcute: actualizări, permisiuni, WAF la hosting. Mai multe plugin-uri de securitate care se suprapun încetinesc site-ul și nu adaugă protecție reală.
Cât de des trebuie să actualizez?
Actualizările de securitate le aplici în ziua în care apar, după un backup. Restul le poți grupa săptămânal. Activezi actualizările automate minore ale nucleului și verifici periodic că plugin-urile pe care le folosești sunt încă întreținute de autori.