Na kratko: Kdor želi strežnik utrditi za PHP, poskrbi, da posamezna ranljivost ne odpre celotnega strežnika. Spletne strani ločimo med seboj, PHP in spletni strežnik varno nastavimo, omejimo pravice in dostope ter dokumentiramo vsako spremembo. Tako je škoda manjša, če se kljub vsemu kaj zgodi.
Zakaj je utrjevanje po PHP2Shell postalo pomembnejše
PHP2Shell je pokazal, kako hitro ranljivost v samem PHP postane težava za vse spletne strani na strežniku. S CVE-2026-109618 in CVE-2026-109619 lahko napadalci izvajajo kodo brez prijave. Popravek ta vrata zapre. Utrjevanje odgovarja na drugo vprašanje: kaj lahko stori nekdo, ki kljub temu pride noter, prek te ali naslednje ranljivosti?
Na neutrjenem strežniku vse spletne strani pogosto tečejo pod istim uporabnikom, PHP sme izvajati sistemske ukaze, dostopni podatki pa so berljivi za vse procese. Vdor v majhno stransko spletno stran potem seže vse do spletne trgovine. Dobro utrjevanje ta območja loči. Ni enkratno dejanje, ampak osnovno stanje, ki ga je treba ohraniti ob vsaki novi spletni strani in vsaki zamenjavi različice.
Utrjevanje strežnika za PHP: kaj konkretno prilagodimo
Izolacija za vsako spletno stran
Vsaka spletna stran dobi lastnega sistemskega uporabnika in lasten pool PHP-FPM. Z open_basedir in ustreznimi pravicami datotek aplikacija vidi samo svojo mapo. Več o tem na strani open_basedir in izolacija za vsako spletno stran.
Varna konfiguracija PHP
php.ini in konfiguracijo poola nastavimo tako, da aplikacije varnostno pomembnih vrednosti ne morejo same prepisati. Izsek, kakršen je lahko v poolu FPM:
; Vrednosti v poolu FPM določiti trdno, ne da bi jih bilo mogoče spremeniti z 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
Katere funkcije je mogoče dodatno blokirati, je odvisno od aplikacije. Napotki so na straneh Varna konfiguracija php.ini in Pravilna uporaba disable_functions.
Pravice datotek in pisalni dostop
Spletni strežnik sme pisati samo tam, kjer je to potrebno, na primer v mapo za nalaganje. V mapah za nalaganje se izvajanje PHP prepreči. Programska koda pripada drugemu uporabniku kot tisti, pod katerim teče PHP. Načela razlaga stran Pravice datotek na spletnem strežniku.
Dostopi, storitve in dnevniki
SSH samo s ključem, skrbniški vmesniki z dvofaktorsko prijavo, nepotrebne storitve in vrata zaprta. Dnevniki se hranijo in zavarujejo tako, da so po incidentu še na voljo. Varnostne kopije preverimo glede obnovljivosti.
Spletni strežnik in varnostne glave
K utrjevanju sodi tudi sam spletni strežnik: skriti podatke o različici, izklopiti izpise map, blokirati dostop do konfiguracijskih datotek, varnostnih kopij in datotek za upravljanje različic ter skrbniška območja dodatno zavarovati, na primer z dovoljenjem po naslovu IP. Varnostne glave, kot sta Content-Security-Policy ali HSTS, obiskovalce vaše spletne strani ščitijo v brskalniku.
Kaj pri popisu pogosto najdemo
Številne šibke točke se od strežnika do strežnika ponavljajo. Značilne so večje število spletnih strani pod skupnim uporabnikom, javno dosegljivi vmesniki podatkovnih zbirk, stare testne namestitve v podmapah, pozabljene različice PHP ob aktualni in varnostne kopije, ki ležijo v spletni mapi in jih je mogoče prenesti. Pogosto manjka tudi vsakršno beleženje prijav ali pa se dnevniki po nekaj dneh izbrišejo.
Nobena od teh točk sama zase ni spektakularna. Skupaj pa odločajo o tem, ali vdor ostane omejen na eno spletno stran ali zadene celoten strežnik.
Kako konkretno pomaga PHP SOS?
- Popis: zabeležimo operacijski sistem, spletni strežnik, različice PHP, spletne strani, uporabnike, odprte storitve in obstoječe varnostne kopije.
- Načrt ukrepov: prejmete prednostni seznam z obsegom dela in možnimi posledicami za vsako točko. Vi odločite, kaj se izvede.
- Izvedba po korakih: konfiguracije spreminjamo po dogovoru, po vsakem koraku preizkusimo spletne strani in zapišemo, kako je vsako spremembo mogoče razveljaviti.
- Kontrola: po izvedbi preverimo učinek, na primer ali spletna stran res ne more več brati tujih map.
- Predaja: prejmete dokumentacijo novega stanja, ki jo lahko razume tudi vaš ponudnik gostovanja ali agencija.
Kaj dobite in kaj potrebujemo
Dobite poročilo o utrjevanju z izhodiščem, izvedenimi ukrepi, zavestno odprtimi točkami z obrazložitvijo in priporočilom za redno kontrolo. Spremembe konfiguracijskih datotek so dokumentirane sledljivo.
Od vas potrebujemo:
- dostop root ali skrbniški dostop do strežnika, pri panelih dodatno dostop do panela
- seznam aplikacij in njihovih posebnosti, na primer nalaganja, vmesniki, cron opravila
- tehnično kontaktno osebo, ki lahko po spremembah potrdi delovanje funkcij
- okna vzdrževanja za ponovne zagone
- aktualno varnostno kopijo ali naročilo, da se pred tem ustvari
Česa ne obljubljamo
Utrjevanje strežnika ne naredi nedotakljivega. Zmanjša napadalno površino in omeji škodo, vendar ne nadomešča posodobitev ali nadzora. Nepopravljena različica PHP ostane ranljiva, ne glede na to, kako dobro je nastavljeno vse ostalo. Zato utrjevanje povezujemo s storitvijo popravljanja PHP in nato priporočamo stalno oskrbo prek varnostne vzdrževalne pogodbe.
Pri shared hostingu veliko stvari ni mogoče nastaviti, ker konfiguracijo določa ponudnik gostovanja. Takrat pokažemo, kaj je mogoče v okviru vašega paketa in kje bi bil smiseln prehod na lasten ali upravljan strežnik.
Pogosta vprašanja
Kaj pomeni utrditi strežnik?
Utrjevanje pomeni izklopiti ali omejiti vse, kar za delovanje ni potrebno. Sem sodijo nepotrebne storitve, preveč obsežne pravice, odprta vrata in nevarne privzete nastavitve. Cilj je, da posamezna napaka ne odpre kar celotnega strežnika.
Ali bi utrjevanje preprečilo PHP2Shell?
Ne, proti ranljivosti v samem PHP pomaga samo popravek. Utrjevanje pa omeji, kaj lahko napadalec doseže po uspešnem vdoru, na primer ali lahko pride do drugih spletnih strani ali dostopnih podatkov.
Ali se zaradi utrjevanja moja spletna stran pokvari?
Tveganje obstaja, če se nastavitve spremenijo brez preizkusa. Spremembe uvajamo po korakih, po vsakem koraku preverimo delovanje in zapišemo, kako je vsako spremembo mogoče razveljaviti.
Kako pogosto naj se utrjevanje pregleda?
Najkasneje po večjih posodobitvah, zamenjavi različice PHP ali novih aplikacijah na strežniku. Smiselna je redna kontrola v okviru tekočega vzdrževanja.