Pe scurt: Cine vrea să-și securizeze serverul pentru PHP face în așa fel încât o singură vulnerabilitate să nu deschidă tot serverul. Separăm site-urile unele de altele, configurăm sigur PHP și serverul web, restrângem drepturile și accesurile și documentăm fiecare modificare. Astfel paguba rămâne mai mică dacă totuși se întâmplă ceva.
De ce securizarea a devenit mai importantă după PHP2Shell
PHP2Shell a arătat cât de repede o vulnerabilitate din PHP însuși devine o problemă pentru toate site-urile de pe un server. Cu CVE-2026-109618 și CVE-2026-109619, atacatorii pot executa cod fără autentificare. Patchul închide această ușă. Securizarea răspunde la o altă întrebare: ce poate face cineva care totuși pătrunde, prin această vulnerabilitate sau prin următoarea?
Pe un server nesecurizat, toate site-urile rulează adesea sub același utilizator, PHP are voie să execute comenzi de sistem, iar datele de acces sunt lizibile pentru toate procesele. O intruziune într-un site secundar mic ajunge atunci până la magazinul online. O securizare bună separă aceste domenii. Nu este o acțiune unică, ci o stare de bază, care trebuie menținută la fiecare site nou și la fiecare schimbare de versiune.
Securizarea serverului pentru PHP: ce adaptăm concret
Izolare pentru fiecare site
Fiecare site primește propriul utilizator de sistem și propriul pool PHP-FPM. Cu open_basedir și cu drepturi de fișiere potrivite, o aplicație vede doar propriul director. Mai multe la open_basedir și izolarea pe site.
Configurație PHP sigură
Setăm php.ini și configurația pool-ului astfel încât aplicațiile să nu poată suprascrie ele însele valorile relevante pentru securitate. Un extras despre cum poate arăta într-un pool FPM:
; valorile se fixează în pool-ul FPM și nu pot fi modificate prin ini_set()
php_admin_flag[expose_php] = off
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[open_basedir] = /var/www/kunde1/:/tmp/
php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[allow_url_include] = off
Ce funcții se mai pot bloca suplimentar depinde de aplicație. Indicații găsiți la Cum configurați sigur php.ini și Cum folosiți corect disable_functions.
Drepturi de fișiere și acces la scriere
Serverul web are voie să scrie doar acolo unde este necesar, de exemplu în dosarul de încărcare. În directoarele de încărcare, execuția PHP este împiedicată. Codul programului aparține altui utilizator decât cel sub care rulează PHP. Principiile le explică Drepturile de fișiere pe serverul web.
Accesuri, servicii și jurnale
SSH doar cu cheie, interfețe de administrare cu autentificare în doi factori, servicii și porturi inutile închise. Logurile sunt păstrate și protejate astfel încât să existe încă după un incident. Verificăm backupurile din punctul de vedere al posibilității de restaurare.
Server web și antete de securitate
Și serverul web însuși face parte din securizare: ascunderea indicațiilor de versiune, dezactivarea listării directoarelor, blocarea accesului la fișiere de configurare, de backup și de versionare și protejarea suplimentară a zonelor de administrare, de exemplu prin acordarea accesului pe IP. Antete de securitate precum Content-Security-Policy sau HSTS protejează vizitatorii site-ului dumneavoastră în browser.
Ce găsim frecvent la inventar
Multe slăbiciuni se repetă de la un server la altul. Tipice sunt mai multe site-uri sub un utilizator comun, interfețe de bază de date accesibile public, instalări de test vechi în subdosare, versiuni PHP uitate lângă cea actuală și backupuri aflate în directorul web și descărcabile. Frecvent lipsește, în plus, orice jurnalizare a autentificărilor sau logurile sunt șterse după câteva zile.
Niciunul dintre aceste puncte nu este spectaculos în sine. Împreună decid însă dacă o intruziune rămâne limitată la un site sau afectează tot serverul.
Cum ajută PHP SOS concret?
- Inventar: Inventariem sistemul de operare, serverul web, versiunile PHP, site-urile, utilizatorii, serviciile deschise și salvările existente.
- Plan de măsuri: Primiți o listă prioritizată, cu efortul și posibilele efecte pentru fiecare punct. Dumneavoastră decideți ce se implementează.
- Implementare în pași: Modificăm configurațiile după înțelegere, testăm site-urile după fiecare pas și consemnăm cum poate fi anulată fiecare modificare.
- Control: După implementare verificăm efectul, de exemplu dacă un site chiar nu mai poate citi directoare străine.
- Predare: Primiți o documentație a noii stări, pe care o pot urmări și furnizorul dumneavoastră de hosting sau agenția.
Ce primiți și de ce avem nevoie
Primiți un raport de securizare cu situația de pornire, măsurile implementate, punctele lăsate deliberat deschise împreună cu motivarea și o recomandare pentru verificarea regulată. Modificările fișierelor de configurare sunt documentate într-un mod ușor de urmărit.
De la dumneavoastră avem nevoie de:
- acces root sau de administrator la server, iar la panouri suplimentar accesul la panou
- o listă a aplicațiilor și a particularităților lor, de exemplu încărcări, interfețe, cronjoburi
- un interlocutor tehnic care poate confirma funcțiile după modificări
- ferestre de mentenanță pentru reporniri
- un backup actual sau mandatul de a crea unul înainte
Ce nu promitem
Securizarea nu face un server inatacabil. Reduce suprafața de atac și limitează daunele, dar nu înlocuiește nici actualizările, nici supravegherea. O versiune PHP fără patch rămâne vulnerabilă, oricât de bine ar fi setat restul. De aceea legăm securizarea de serviciul de patch PHP și recomandăm după aceea o asistență continuă printr-un contract de mentenanță de securitate.
La hostingul partajat, multe lucruri nu pot fi setate, deoarece furnizorul de hosting impune configurația. Atunci arătăm ce este posibil în cadrul pachetului dumneavoastră și unde ar fi utilă trecerea la un server propriu sau administrat.
Întrebări frecvente
Ce înseamnă să securizezi un server?
A securiza înseamnă a opri sau a restrânge tot ce nu este necesar pentru funcționare. Aici intră serviciile de prisos, drepturile prea largi, porturile deschise și setările implicite nesigure. Scopul este ca o singură greșeală să nu deschidă imediat tot serverul.
Ar fi împiedicat securizarea PHP2Shell?
Nu, împotriva unei vulnerabilități din PHP însuși ajută doar patchul. Securizarea limitează însă ce poate atinge un atacator după o intruziune reușită, de exemplu dacă poate accesa alte site-uri sau date de acces.
Se strică site-ul meu din cauza securizării?
Riscul există dacă setările sunt modificate fără test. Aplicăm modificările pas cu pas, verificăm funcțiile după fiecare pas și consemnăm cum poate fi anulată fiecare modificare.
Cât de des ar trebui verificată securizarea?
Cel târziu după actualizări mai mari, după o schimbare a versiunii PHP sau după apariția unor aplicații noi pe server. Este utilă o verificare regulată în cadrul mentenanței curente.