Securizarea site-ului: capabilități, anteturi și module de securitate

Modulul 7: Securitate · Timp de citire: 10 minute

Obiectiv de învățare: După această lecție veți putea securiza (hardening) o site WordPress folosind drepturi de acces, setări și anteturi de securitate, și veți putea evalua corect modulele de securitate.

Concepte-cheie: securizare (hardening), drepturi pentru fișiere (644, 755), DISALLOW_FILE_EDIT, fără PHP în uploads, listare de directoare, ascunderea versiunii, X-Powered-By, anteturi de securitate, fișiere de backup și .git în folderul web, WAF pe server, WAF într-un modul, scanner de malware

Ce înseamnă securizarea (hardening)

Securizarea (hardening) înseamnă: configurarea site-ului astfel încât o greșeală sau o vulnerabilitate să poată provoca mai puține pagube. Nu înlocuiește actualizările și parolele puternice (lecția 7.2 și 7.3), dar reduce consecințele. Gândiți-vă la o casă: actualizările sunt încuietorile, securizarea înseamnă să vă asigurați că un hoț care totuși a intrat nu poate ajunge la seif.

Drepturi pentru fișiere

Fiecare fișier și fiecare folder de pe server are drepturi de acces: cine poate citi, scrie și executa. Acestea sunt scrise sub formă de trei cifre, pentru proprietar, grup și restul lumii. Recomandarea din documentația WordPress:

Ce valoare funcționează pentru wp-config.php depinde de modul în care furnizorul dumneavoastră de găzduire rulează PHP: la majoritatea găzduirilor partajate, PHP rulează sub propriul dumneavoastră utilizator, și atunci 600 este suficient. Încercați și verificați dacă site-ul mai funcționează.

Niciodată 777. Aceasta înseamnă: oricine de pe server poate scrie. Un ghid care spune „setați folderul pe 777 dacă încărcarea nu funcționează” rezolvă problema în mod greșit. La o găzduire de calitate, acest lucru nu este niciodată necesar.

Setări în wp-config.php

Câteva linii care fac o diferență mare (deasupra liniei „stop editing”):

// Niciun fișier nu poate fi editat din panoul de control (Aspect > Editor teme și Module > Editor module).
define( 'DISALLOW_FILE_EDIT', true );

// Mesajele de eroare nu trebuie afișate niciodată pe ecranul vizitatorilor (lecția 5.4).
define( 'WP_DEBUG', false );

Cu DISALLOW_FILE_EDIT dispare editorul cu care puteți modifica din panoul de control fișierele PHP ale temelor și modulelor. Un intrus care preia un cont de administrator nu mai poate introduce din două clicuri cod rău intenționat în temă. Puteți încă instala module; dacă doriți să interziceți și acest lucru (de exemplu la o site pe care o administrați pentru un client), există DISALLOW_FILE_MODS, dar atunci nici actualizările prin panoul de control nu vor mai funcționa.

Fără PHP în uploads, fără listare de directoare

În wp-content/uploads trebuie să existe imagini și documente, niciodată fișiere PHP. Intrușii care pot încărca un fișier printr-o vulnerabilitate încearcă tocmai să plaseze acolo un fișier PHP și să îl acceseze. Blocați acest lucru cu un fișier .htaccess în folderul uploads (la LiteSpeed și Apache):

<Files *.php>
Require all denied
</Files>

Dezactivați și afișarea listei de foldere. Fără index.php sau index.html într-un folder, unele servere web afișează o listă cu toate fișierele („Index of /wp-content/uploads/2026/11”). Aceasta este o vitrină pentru cei care caută copii de siguranță sau documente sensibile. În fișierul .htaccess din folderul dumneavoastră web:

Options -Indexes

Mulți furnizori de găzduire au dezactivat deja acest lucru implicit. Exercițiul din această lecție verifică acest aspect.

Niciun rest în folderul web

Tot ce se află în folderul web poate fi accesat prin web, cu excepția a ceea ce serverul execută sau blochează ca PHP. Sunt periculoase:

• copii ale wp-config.php (wp-config.php.bak, wp-config.old, wp-config.php~ dintr-un editor de text): acestea conțin parola bazei dumneavoastră de date și sunt trimise ca text simplu (lecția 1.3);
• copii de siguranță precum backup.zip, site.tar.gz sau database.sql în folderul web;
• un folder .git lăsat de un dezvoltator, cu care cineva poate descărca tot codul dumneavoastră (și uneori parole);
• debug.log în wp-content (lecția 5.4);
• fișiere vechi de instalare sau testare, precum info.php cu phpinfo().

Păstrați copiile de siguranță în afara folderului web sau în afara serverului, și curățați resturile.

Ascunderea versiunii: un câștig mic

WordPress adaugă implicit în HTML:

<meta name="generator" content="WordPress 7.1.4" />

și același lucru în fluxul RSS. De asemenea, PHP se anunță uneori printr-un antet: X-Powered-By: PHP/8.3.14. A le ascunde este rezonabil, dar nu vă așteptați la prea mult: programele folosite de intruși încearcă pur și simplu o vulnerabilitate, indiferent de versiunea afișată, iar versiunile pot fi adesea deduse și din ?ver= după scripturi. Ascunderea este curățenie, nu securitate. O site care își ascunde versiunea dar nu este actualizată este la fel de vulnerabilă.

Iată cum procedați, într-un modul propriu simplu sau în functions.php din tema dumneavoastră copil (child theme):

remove_action( 'wp_head', 'wp_generator' );
add_filter( 'the_generator', '__return_empty_string' );

Și antetul PHP cu expose_php = Off în setările PHP ale furnizorului dumneavoastră de găzduire (la DirectAdmin în Select PHP version, Options), sau cu Header unset X-Powered-By în .htaccess.

Anteturi de securitate

Cu câteva antete îi spuneți browserului cum să trateze site-ul dumneavoastră. Cele mai importante:

În .htaccess (la LiteSpeed și Apache):

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Testați apoi dacă totul funcționează: conținut încorporat, butoane de plată, un widget de chat. Instrumente externe precum securityheaders.com și internet.nl arată ce trimite site-ul dumneavoastră.

Module de securitate, privite onest

Există multe module de securitate (de exemplu Wordfence, Solid Security, All-In-One Security, Sucuri). Acestea combină adesea: un firewall, un scanner de malware, protecție la autentificare, autentificare în doi pași, notificări și o listă de securizare. Utile, dar cu limite:

• Un firewall într-un modul (WAF) pornește abia când rulează PHP. O solicitare rău intenționată trebuie mai întâi să treacă prin serverul web și PHP înainte ca modulul să o observe. O vulnerabilitate într-un fișier PHP apelat direct, sau un atac care suprasolicită chiar PHP-ul, nu este întotdeauna oprit. Un firewall pe server (de exemplu ModSecurity, Imunify360 sau un firewall al furnizorului dumneavoastră de găzduire) se află mai devreme în lanț și oprește mai mult, fără ca modulul dumneavoastră să facă efortul de calcul. Întrebați furnizorul dumneavoastră de găzduire ce rulează pe server.
• Un scanner descoperă ulterior. Un scanner de malware vă spune că ceva este în neregulă. Este valoros, dar nu previne nimic. Iar un scanner de pe același server cu o site compromisă poate fi el însuși modificat de intrus.
• Nu înlocuiesc actualizările. Un modul cu o vulnerabilitate cunoscută rămâne vulnerabil, chiar și cu un modul de securitate alături. Unele servicii de securitate oferă „patch-uri virtuale” care opresc atacurile cunoscute până când actualizați; util ca soluție temporară, nu ca înlocuitor.
• Sunt și ele un modul. Mai mult cod, mai mult de actualizat, uneori chiar ele au o vulnerabilitate. Iar două module de securitate active simultan intră adesea în conflict.
• Consumă putere de calcul, mai ales scanerele care rulează pe propriul dumneavoastră server.

O alegere rezonabilă: verificați mai întâi ce face deja furnizorul dumneavoastră de găzduire (firewall, scanare de malware, blocarea încercărilor de autentificare). Completați ce lipsește, de obicei autentificarea în doi pași și limitarea încercărilor de autentificare. Un modul de securitate extins este util mai ales la o găzduire care face puțin ea însăși.

Rezumat

• Securizarea (hardening) limitează pagubele unei greșeli sau vulnerabilități; nu înlocuiește actualizările și parolele.
• Foldere 755, fișiere 644, wp-config.php mai strict; niciodată 777.
• Activați DISALLOW_FILE_EDIT, blocați PHP în uploads, dezactivați listarea de directoare și curățați copiile de siguranță, .git și debug.log din folderul web.
• Ascunderea versiunii este curățenie, nu securitate; anteturile de securitate ajută browserul să vă protejeze vizitatorii.
• Un firewall pe server oprește mai mult decât un modul; modulele de securitate sunt o completare, nu un înlocuitor.

Test (quiz)

Exercițiu

Exercițiul A7.4: Ce arată site-ul dumneavoastră tuturor? Introduceți adresa site-ului dumneavoastră. Programul citește pagina principală și fluxul RSS (/feed/) și verifică: nu apare nicio versiune WordPress în eticheta generator din HTML și din flux, antetul X-Powered-By nu afișează nicio versiune PHP, iar site-ul dumneavoastră trimite X-Content-Type-Options: nosniff, o protecție împotriva frame-urilor (X-Frame-Options sau frame-ancestors) și un Referrer-Policy? Lipsa HSTS (lecția 3.1) și a Permissions-Policy este acceptabilă (portocaliu).

Exercițiul A7.4b: Niciun rest în folderul web. Dovediți că este site-ul dumneavoastră proprie (înregistrare TXT sau fișier cu codul exercițiului). Programul solicită apoi o listă scurtă și fixă: folderul /wp-content/uploads/ (fără listare de directoare), /.git/HEAD, /wp-content/debug.log și câteva denumiri frecvente de copii ale wp-config.php. Rezultatul este bun dacă niciunul dintre acestea nu returnează conținut (404 sau 403). Programul nu încearcă nimic altceva și nu modifică nimic.

Lecturi suplimentare

Aceste articole descriu pașii din panourile WebOké; în alte panouri funcționează similar.

• Manual DirectAdmin 11.5: Drepturile fișierelor și directoarelor (chmod)
• Manual DirectAdmin 11.4: Afișarea și editarea fișierelor ascunse precum .htaccess
• Manual DirectAdmin 15.10: Web Application Firewall
• Manual DirectAdmin 15.11: Imunify360: scanarea website-ului pentru malware
• Blocarea fișierelor prin .htaccess, de exemplu plugin-googlemap2-proxy.php
• Securitatea PHP
• Securizarea WordPress (developer.wordpress.org, în engleză): https://developer.wordpress.org/advanced-administration/security/hardening/
• Anteturi de securitate (MDN, în engleză): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#security