Lühidalt: Kes tahab oma serverit PHP jaoks karastada, hoolitseb selle eest, et üksik turvaauk ei avaks kogu serverit. Eraldame veebisaidid üksteisest, seadistame PHP ja veebiserveri turvaliselt, piirame õigusi ja ligipääse ning dokumenteerime iga muudatuse. Nii jääb kahju väiksemaks, kui midagi siiski juhtub.
Miks karastamine on pärast PHP2Shelli olulisemaks muutunud
PHP2Shell on näidanud, kui kiiresti võib turvaauk PHP-s endas saada probleemiks kõigile serveri veebisaitidele. Turvaaukude CVE-2026-109618 ja CVE-2026-109619 kaudu saavad ründajad koodi käivitada ilma sisselogimata. Paik sulgeb selle ukse. Karastamine vastab teisele küsimusele: mida saab teha see, kes sellest või järgmisest turvaaugust hoolimata sisse pääseb?
Karastamata serveris töötavad sageli kõik veebisaidid sama kasutaja all, PHP tohib käivitada süsteemikäske ja ligipääsuandmed asuvad kõigile protsessidele loetavalt. Sissemurdmine väikesesse kõrvalsaiti ulatub siis kuni e-poeni. Hea karastus eraldab need alad. See ei ole ühekordne tegevus, vaid algseisund, mis peab säilima iga uue veebisaidi ja iga versioonivahetuse korral.
Serveri karastamine PHP jaoks: mida me konkreetselt kohandame
Veebisaitide isolatsioon
Iga veebisait saab oma süsteemikasutaja ja oma PHP-FPM-i kogumi (pool). Valikuga open_basedir ja sobivate failiõigustega näeb rakendus ainult oma kataloogi. Lähemalt lehel open_basedir ja isolatsioon veebisaidi kaupa.
Turvaline PHP seadistus
Seadistame php.ini ja pooli seadistuse nii, et rakendused ei saa turvalisuse seisukohalt olulisi väärtusi ise üle kirjutada. Väljavõte sellest, kuidas see võib FPM-i poolis välja näha:
; Väärtused FPM-i poolis kindlalt ette anda, ini_set() kaudu muudetavad ei ole
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
Milliseid funktsioone saab lisaks keelata, sõltub rakendusest. Näpunäited leiate lehtedelt php.ini turvaline seadistamine ja disable_functions õige kasutamine.
Failiõigused ja kirjutusõigus
Veebiserver tohib kirjutada ainult seal, kus see on vajalik, näiteks üleslaadimiskaustas. Üleslaadimiskataloogides keelatakse PHP käivitamine. Programmikood kuulub teisele kasutajale kui see, mille all PHP töötab. Põhimõtteid selgitab failiõigused veebiserveris.
Ligipääsud, teenused ja protokollid
SSH ainult võtmega, haldusliidesed kahefaktorilise sisselogimisega, mittevajalikud teenused ja pordid suletud. Logisid hoitakse ja kindlustatakse nii, et need on pärast intsidenti veel olemas. Varukoopiate taastatavust kontrollime.
Veebiserver ja turvapäised
Ka veebiserver ise kuulub karastamise juurde: versiooniteabe peitmine, kataloogiloendite väljalülitamine, juurdepääsu blokeerimine seadistus-, varukoopia- ja versioonihaldusfailidele ning haldusalade täiendav kaitse, näiteks IP-lubade kaudu. Turvapäised nagu Content-Security-Policy või HSTS kaitsevad teie veebisaidi külastajaid brauseris.
Mida me inventuuri käigus sageli leiame
Paljud nõrkused kordavad end serverist serverisse. Tüüpilised on mitu veebisaiti ühe ühise kasutaja all, avalikult ligipääsetavad andmebaasi liidesed, vanad testpaigaldused alamkaustades, unustatud PHP versioonid praeguse kõrval ning varukoopiad, mis asuvad veebikataloogis ja on allalaaditavad. Sageli puudub ka igasugune sisselogimiste logimine või logid kustutatakse mõne päeva pärast.
Ükski neist punktidest pole iseenesest märkimisväärne. Koos otsustavad nad aga selle üle, kas sissemurdmine jääb ühe veebisaidi piiresse või mõjutab kogu serverit.
Kuidas PHP SOS konkreetselt aitab?
- Inventuur: Kaardistame operatsioonisüsteemi, veebiserveri, PHP versioonid, veebisaidid, kasutajad, avatud teenused ja olemasolevad varukoopiad.
- Meetmeplaan: Saate prioriseeritud loendi koos iga punkti töömahu ja võimalike mõjudega. Teie otsustate, mida ellu viiakse.
- Elluviimine sammude kaupa: Muudame seadistusi kokkuleppel, testime veebisaite pärast iga sammu ja kirjutame üles, kuidas iga muudatuse saab tagasi võtta.
- Kontroll: Pärast elluviimist kontrollime mõju, näiteks seda, kas veebisait tõesti enam võõraid katalooge lugeda ei saa.
- Üleandmine: Saate uue seisu dokumentatsiooni, millest saavad aru ka teie veebimajutaja või agentuur.
Mida te saate ja mida me vajame
Saate karastusaruande, kus on algseis, rakendatud meetmed, teadlikult lahtiseks jäetud punktid koos põhjendusega ja soovitus regulaarseks kontrolliks. Muudatused seadistusfailides on jälgitavalt dokumenteeritud.
Teilt vajame:
- root- või administraatoriligipääsu serverile, paneelide puhul lisaks paneeliligipääsu
- rakenduste loendit ja nende eripärasid, näiteks üleslaadimised, liidesed, cron-tööd
- tehnilist kontaktisikut, kes saab pärast muudatusi funktsioone kinnitada
- hooldusaknaid taaskäivituste jaoks
- värsket varukoopiat või tellimust see enne luua
Mida me ei luba
Karastamine ei tee serverit rünnakukindlaks. See vähendab ründepinda ja piirab kahju, kuid ei asenda ei uuendusi ega seiret. Paigata PHP versioon jääb haavatavaks, hoolimata sellest, kui hästi ülejäänu on seadistatud. Seetõttu ühendame karastamise PHP paikamisteenusega ja soovitame seejärel pidevat hooldust turvahoolduslepingu kaudu.
Jagatud veebimajutuse puhul ei ole paljut võimalik seadistada, sest seadistuse määrab veebimajutaja. Siis näitame, mis on teie paketi raames võimalik ja kus oleks mõistlik üle minna oma või hallatavale serverile.
Korduma kippuvad küsimused
Mida tähendab serveri karastamine?
Karastamine tähendab kõige välja lülitamist või piiramist, mis tööks vajalik pole. Siia kuuluvad üleliigsed teenused, liiga laiad õigused, avatud pordid ja ebaturvalised vaikesätted. Eesmärk on, et üksik viga ei avaks kohe kogu serverit.
Kas karastamine oleks PHP2Shelli ära hoidnud?
Ei, turvaaugu vastu PHP-s endas aitab ainult paik. Karastamine piirab aga seda, mida ründaja pärast edukat sissemurdmist saavutada võib, näiteks kas ta pääseb ligi teistele veebisaitidele või ligipääsuandmetele.
Kas karastamine rikub mu veebisaidi?
Risk on olemas, kui sätteid muudetakse ilma testimiseta. Rakendame muudatused järk-järgult, kontrollime funktsioone pärast iga sammu ja kirjutame üles, kuidas iga muudatuse saab tagasi võtta.
Kui tihti tuleks karastust üle kontrollida?
Hiljemalt pärast suuremaid uuendusi, PHP versiooni vahetust või uusi rakendusi serveris. Mõistlik on regulaarne kontroll jooksva hoolduse raames.