Trumpai: Kas nori sustiprinti serverį PHP aplinkai, užtikrina, kad viena spraga neatvertų viso serverio. Atskiriame svetaines, saugiai nustatome PHP ir žiniatinklio serverį, apribojame teises ir prieigas bei dokumentuojame kiekvieną pakeitimą. Taip žala lieka mažesnė, jei vis dėlto kas nors nutinka.
Kodėl sustiprinimas po PHP2Shell tapo svarbesnis
PHP2Shell parodė, kaip greitai spraga pačiame PHP tampa problema visoms serverio svetainėms. Su CVE-2026-109618 ir CVE-2026-109619 užpuolikai gali vykdyti kodą be prisijungimo. Pataisa uždaro šias duris. Sustiprinimas atsako į kitą klausimą: ką gali padaryti tas, kuris vis tiek patenka vidun, per šią ar kitą spragą?
Nesustiprintame serveryje visos svetainės dažnai veikia po tuo pačiu naudotoju, PHP gali vykdyti sistemos komandas, o prieigos duomenys guli skaitomi visiems procesams. Tada įsilaužimas į mažą šalutinę svetainę pasiekia net internetinę parduotuvę. Gerai sustiprinimas šias sritis atskiria. Tai ne vienkartinis veiksmas, o pagrindinė būsena, kuri turi išlikti su kiekviena nauja svetaine ir kiekvienu versijos pakeitimu.
Serverio sustiprinimas PHP aplinkai: ką konkrečiai koreguojame
Izoliacija kiekvienai svetainei
Kiekviena svetainė gauna savo sistemos naudotoją ir savą PHP-FPM baseiną (pool). Su open_basedir ir tinkamomis failų teisėmis programa mato tik savo katalogą. Daugiau rasite puslapyje open_basedir ir izoliacija kiekvienai svetainei.
Saugi PHP konfigūracija
php.ini ir baseino konfigūraciją nustatome taip, kad programos negalėtų pačios perrašyti saugumui svarbių reikšmių. Ištrauka, kaip gali atrodyti FPM baseinas:
; Reikšmes FPM baseine nustatyti fiksuotai, ini_set() jų pakeisti negali
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
Kokias funkcijas papildomai galima užblokuoti, priklauso nuo programos. Nurodymų rasite puslapiuose Saugus php.ini konfigūravimas ir disable_functions tinkamas naudojimas.
Failų teisės ir rašymo prieiga
Žiniatinklio serveris gali rašyti tik ten, kur būtina, pavyzdžiui, įkėlimų aplanke. Įkėlimų kataloguose PHP vykdymas draudžiamas. Programos kodas priklauso kitam naudotojui nei tas, po kuriuo veikia PHP. Principus paaiškina Failų teisės žiniatinklio serveryje.
Prieigos, tarnybos ir žurnalai
SSH tik su raktu, administravimo sąsajos su dviejų veiksnių prisijungimu, nereikalingos tarnybos ir prievadai uždaryti. Žurnalai saugomi ir apsaugomi taip, kad po incidento dar būtų išlikę. Atsargines kopijas tikriname, ar jas galima atkurti.
Žiniatinklio serveris ir saugumo antraštės
Prie sustiprinimo priklauso ir pats žiniatinklio serveris: paslėpti versijų nuorodas, išjungti katalogų sąrašus, užblokuoti prieigą prie konfigūracijos, atsarginių kopijų ir versijų valdymo failų ir papildomai apsaugoti administravimo sritis, pavyzdžiui, leidžiant tik tam tikrus IP. Saugumo antraštės, tokios kaip Content-Security-Policy ar HSTS, naršyklėje saugo jūsų svetainės lankytojus.
Ką dažnai randame inventorizacijos metu
Daug silpnų vietų kartojasi nuo serverio prie serverio. Tipiška: kelios svetainės po bendru naudotoju, viešai pasiekiamos duomenų bazių sąsajos, senos bandomosios diegimo versijos poaplankiuose, užmirštos PHP versijos šalia dabartinės ir atsarginės kopijos, gulinčios žiniatinklio kataloge ir atsisiunčiamos. Dažnai trūksta ir prisijungimų registravimo, arba žurnalai ištrinami po kelių dienų.
Nė vienas iš šių punktų pats savaime nėra įspūdingas. Tačiau kartu jie lemia, ar įsilaužimas lieka apribotas viena svetaine, ar paliečia visą serverį.
Kaip PHP SOS padeda konkrečiai?
- Inventorizacija: Surašome operacinę sistemą, žiniatinklio serverį, PHP versijas, svetaines, naudotojus, atviras tarnybas ir esamas atsargines kopijas.
- Priemonių planas: Gaunate prioritetizuotą sąrašą su sąnaudomis ir galimu poveikiu kiekvienam punktui. Jūs nusprendžiate, kas bus įgyvendinta.
- Įgyvendinimas etapais: Konfigūracijas keičiame pagal susitarimą, po kiekvieno žingsnio išbandome svetaines ir užfiksuojame, kaip kiekvieną pakeitimą galima atšaukti.
- Kontrolė: Po įgyvendinimo tikriname poveikį, pavyzdžiui, ar svetainė tikrai nebegali skaityti svetimų katalogų.
- Perdavimas: Gaunate naujos būsenos dokumentaciją, kurią galės suprasti ir jūsų talpintojas ar agentūra.
Ką gausite ir ko mums reikia
Gaunate sustiprinimo ataskaitą su pradine padėtimi, įgyvendintomis priemonėmis, sąmoningai neišspręstais punktais su pagrindimu ir rekomendacija reguliariai kontrolei. Konfigūracijos failų pakeitimai dokumentuoti taip, kad juos būtų galima atsekti.
Iš jūsų mums reikia:
- root ar administratoriaus prieigos prie serverio, o su skydeliais papildomai ir skydelio prieigos
- programų sąrašo ir jų ypatumų, pavyzdžiui, įkėlimų, sąsajų, cron užduočių
- techninio kontaktinio asmens, galinčio po pakeitimų patvirtinti funkcijas
- priežiūros langų paleidimui iš naujo
- naujausios atsarginės kopijos arba užsakymo ją prieš tai sukurti
Ko neapsiimame
Sustiprinimas serverio nepadaro nepažeidžiamo. Jis sumažina atakos paviršių ir apriboja žalą, bet nepakeičia nei atnaujinimų, nei stebėsenos. Nepataisyta PHP versija lieka pažeidžiama, kad ir kaip gerai būtų nustatyta visa kita. Todėl sustiprinimą siejame su PHP pataisų paslauga ir po to rekomenduojame nuolatinę priežiūrą pagal saugumo priežiūros sutartį.
Bendrame talpinime (shared hosting) daug ko nustatyti negalima, nes konfigūraciją nurodo talpintojas. Tada parodome, kas įmanoma jūsų paketo ribose ir kur prasmingas perėjimas prie savo ar valdomo serverio.
Dažni klausimai
Ką reiškia sustiprinti serverį (hardening)?
Sustiprinimas reiškia išjungti arba apriboti viską, kas eksploatacijai nebūtina. Tai apima nereikalingas tarnybas, per plačias teises, atvirus prievadus ir nesaugius numatytuosius nustatymus. Tikslas, kad viena klaida iš karto neatvertų viso serverio.
Ar sustiprinimas būtų užkirtęs kelią PHP2Shell?
Ne, nuo spragos pačiame PHP padeda tik pataisa. Tačiau sustiprinimas riboja, ką užpuolikas gali pasiekti po sėkmingo įsilaužimo, pavyzdžiui, ar jis gali patekti į kitas svetaines ar prieigos duomenis.
Ar dėl sustiprinimo mano svetainė gali nustoti veikti?
Rizika yra, jei nustatymai keičiami be bandymo. Pakeitimus diegiame etapais, po kiekvieno žingsnio tikriname funkcijas ir užfiksuojame, kaip kiekvieną pakeitimą galima atšaukti.
Kaip dažnai sustiprinimą reikėtų peržiūrėti?
Ne vėliau kaip po didesnių atnaujinimų, PHP versijos pakeitimo ar naujų programų serveryje. Prasminga reguliariai tikrinti vykdant einamąją priežiūrą.