Röviden: Aki PHP-hez akarja keményíteni a szerverét, azt akarja elérni, hogy egyetlen rés ne nyissa meg az egész szervert. Elválasztjuk egymástól a weboldalakat, biztonságosan állítjuk be a PHP-t és a webszervert, korlátozzuk a jogokat és a hozzáféréseket, és dokumentálunk minden változtatást. Így kisebb marad a kár, ha mégis történik valami.
Miért vált fontosabbá a keményítés a PHP2Shell után
A PHP2Shell megmutatta, milyen gyorsan válik egy magában a PHP-ban lévő rés a szerver összes weboldalának problémájává. A CVE-2026-109618 és a CVE-2026-109619 révén a támadók bejelentkezés nélkül futtathatnak kódot. A javítás ezt az ajtót lezárja. A keményítés más kérdésre válaszol: mit tehet az, aki ennek vagy a következő résnek a révén mégis bejut?
Egy nem keményített szerveren gyakran minden weboldal ugyanazon felhasználó alatt fut, a PHP rendszerparancsokat hajthat végre, és a hozzáférési adatok minden folyamat számára olvashatók. Egy apró mellékoldal feltörése ilyenkor elér egészen a webshopig. A jó keményítés szétválasztja ezeket a területeket. Nem egyszeri akció, hanem alapállapot, amelynek minden új weboldalnál és minden verzióváltásnál meg kell maradnia.
Szerver keményítése PHP-hez: mit állítunk be konkrétan
Weboldalankénti elkülönítés
Minden weboldal saját rendszerfelhasználót és saját PHP-FPM-poolt kap. Az open_basedir és a megfelelő fájljogok révén egy alkalmazás csak a saját könyvtárát látja. Többet erről az open_basedir és az oldalankénti elkülönítés oldalon talál.
Biztonságos PHP-konfiguráció
A php.ini-t és a pool-konfigurációt úgy állítjuk be, hogy az alkalmazások a biztonság szempontjából lényeges értékeket ne tudják maguk felülírni. Egy kivonat arról, hogyan nézhet ki ez egy FPM-poolban:
; Értékek rögzítése az FPM-poolban, ini_set()-tel nem módosíthatók
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
Hogy mely függvények tilthatók le ezen felül, az az alkalmazástól függ. Tudnivalók a php.ini biztonságos beállítása és a disable_functions helyes használata oldalon vannak.
Fájljogok és írási hozzáférés
A webszerver csak ott írhat, ahol szükséges, például a feltöltési mappában. A feltöltési könyvtárakban megakadályozzuk a PHP végrehajtását. A programkód más felhasználóhoz tartozik, mint amelyik alatt a PHP fut. Az alapelveket a Fájljogok a webszerveren magyarázza.
Hozzáférések, szolgáltatások és naplók
Az SSH csak kulccsal, a rendszergazdai felületek kétfaktoros bejelentkezéssel, a nem szükséges szolgáltatások és portok zárva. A naplókat úgy őrizzük meg és védjük, hogy egy incidens után is megvannak. A mentéseket visszaállíthatóság szempontjából ellenőrizzük.
Webszerver és biztonsági fejlécek
A webszerver maga is a keményítés része: a verzióadatok elrejtése, a könyvtárlisták kikapcsolása, a konfigurációs, mentési és verziókezelő fájlokhoz való hozzáférés tiltása, és a rendszergazdai területek további védelme, például IP-engedélyezéssel. Az olyan biztonsági fejlécek, mint a Content-Security-Policy vagy a HSTS, a weboldal látogatóit védik a böngészőben.
Mit találunk gyakran az állapotfelmérésnél
Sok sebezhetőség szerverről szerverre ismétlődik. Tipikus a több weboldal egy közös felhasználó alatt, a nyilvánosan elérhető adatbázis-felületek, a régi tesztinstallációk almappákban, az elfelejtett PHP-verziók az aktuális mellett, és a webkönyvtárban fekvő, letölthető mentések. Gyakran ezen kívül hiányzik a bejelentkezések naplózása, vagy a naplókat néhány nap után törlik.
Ezek közül egyik sem látványos önmagában. Együtt viszont eldöntik, hogy egy behatolás egy weboldalra korlátozódik-e, vagy az egész szervert érinti.
Hogyan segít konkrétan a PHP SOS?
- Állapotfelmérés: Felmérjük az operációs rendszert, a webszervert, a PHP-verziókat, a weboldalakat, a felhasználókat, a nyitott szolgáltatásokat és a meglévő mentéseket.
- Intézkedési terv: Prioritási sorrendbe tett listát kap pontonként az ráfordítással és a lehetséges hatásokkal. Ön dönti el, mi valósuljon meg.
- Megvalósítás lépésekben: A konfigurációkat egyeztetés szerint módosítjuk, minden lépés után teszteljük a weboldalakat, és rögzítjük, hogyan vonható vissza az egyes változtatás.
- Ellenőrzés: A megvalósítás után megvizsgáljuk a hatást, például hogy egy weboldal valóban nem tud-e már idegen könyvtárakat olvasni.
- Átadás: Dokumentációt kap az új állapotról, amelyet a tárhelyszolgáltatója vagy az ügynöksége is követni tud.
Mit kap, és mire van szükségünk
Keményítési jelentést kap a kiindulási helyzettel, a megvalósított intézkedésekkel, a tudatosan nyitva hagyott pontokkal indoklással együtt, és javaslattal a rendszeres ellenőrzésre. A konfigurációs fájlok módosításai követhetően dokumentáltak.
Öntől a következőkre van szükségünk:
- root vagy rendszergazdai hozzáférés a szerverhez, paneleknél emellett a panel-hozzáférés
- az alkalmazások listája és sajátosságaik, például feltöltések, interfészek, cron-feladatok
- egy műszaki kapcsolattartó, aki a módosítások után megerősítheti a funkciókat
- karbantartási időablakok az újraindításokhoz
- egy aktuális mentés, vagy megbízás arra, hogy előtte készítsünk egyet
Amit nem ígérünk
A keményítés nem teszi támadhatatlanná a szervert. Csökkenti a támadási felületet és korlátozza a károkat, de sem a frissítéseket, sem a felügyeletet nem pótolja. Egy nem javított PHP-verzió sebezhető marad, bármilyen jól van beállítva a többi. Ezért a keményítést összekapcsoljuk a PHP-javítási szolgáltatással, és utána folyamatos gondozást javasolunk egy biztonsági karbantartási szerződés keretében.
Megosztott tárhelynél sok minden nem állítható, mert a tárhelyszolgáltató adja meg a konfigurációt. Ilyenkor megmutatjuk, mi lehetséges a csomagja keretein belül, és hol lenne értelme saját vagy menedzselt szerverre váltani.
Gyakori kérdések
Mit jelent egy szerver keményítése?
A keményítés azt jelenti, hogy kikapcsolunk vagy korlátozunk mindent, ami az üzemeltetéshez nem szükséges. Ide tartoznak a felesleges szolgáltatások, a túl tág jogok, a nyitott portok és a nem biztonságos alapbeállítások. A cél az, hogy egyetlen hiba ne nyissa meg rögtön az egész szervert.
Megakadályozta volna a keményítés a PHP2Shell-t?
Nem, a magában a PHP-ban lévő rés ellen csak a javítás segít. A keményítés viszont korlátozza, mit érhet el a támadó egy sikeres behatolás után, például hozzáférhet-e más weboldalakhoz vagy hozzáférési adatokhoz.
Tönkremegy a weboldalam a keményítéstől?
A kockázat fennáll, ha teszt nélkül módosítanak beállításokat. A változtatásokat lépésenként hajtjuk végre, minden lépés után ellenőrizzük a funkciókat, és rögzítjük, hogyan vonható vissza az egyes módosítás.
Milyen gyakran kell felülvizsgálni a keményítést?
Legkésőbb nagyobb frissítések, PHP-verzióváltás vagy új alkalmazások a szerveren megjelenése után. Hasznos a rendszeres ellenőrzés a folyamatos karbantartás keretében.