expose_php és Server-fejléc: verziószámok elrejtése

Röviden: A php.ini-ben megadott expose_php = Off hatására eltűnik az X-Powered-By: PHP/… fejléc. Ehhez tartozik a server_tokens off; az Nginxben, valamint a ServerTokens Prod és a ServerSignature Off az Apache-ban. Ettől egyetlen szerver sem lesz biztonságosabb, de az automatizált vizsgálatoktól elvesz egy kész verzióslistát. A saját javítási állapotot ezután a csomagkezelőn és a folyamatokon keresztül ellenőrizze, nem a fejléceken.

A névjegykártya minden válaszban

Aki 2026. október 21. után tudni akarta, hány szerver mutat még régi PHP-verziót, nem sokáig keresgélt. Sok webszerver minden egyes válaszban megnevezi a PHP-verzióját, például X-Powered-By: PHP/8.2.20 formában. Az internetszintű keresőszolgáltatások beolvassák ezeket az adatokat, és a Palo Alto Networks Unit 42 csapata a PHP2Shellhez több mint 22,6 millió kitett, potenciálisan sebezhető példányt számolt.

A támadók számára egy ilyen adat rövidítés. Előválogathatják a célpontokat, ahelyett hogy vakon próbálkoznának. Az üzemeltetők számára viszont haszontalan, mert még a saját javítási állapotot sem bizonyítja: a disztribúciók a javításokat gyakran backportként, új verziószám nélkül szállítják.

Ez a cikk megmutatja, hol árulnak el verzióinformációkat a PHP és a webszerver, és hogyan kapcsolhatja ki az adatokat. Őszintén azt is megmondja, mit ér ez, és mit nem.

Hol bukkannak fel mindenhol verziómegjelölések

A PHP-verzió csak egyike a több helynek. Megéri a teljes körű áttekintés, mert egyetlen elfelejtett hely értéktelenné teszi a többi intézkedést.

A phpinfo() tesztfájlok a támadók számára a legtermékenyebb forrás. Nemcsak a verziót árulják el, hanem a teljes konfigurációt; erről bővebben a phpinfo()-fájlok: miért kell eltűnniük cikkben.

Az expose_php kikapcsolása a php.ini-ben

A PHP kézikönyve szerint az expose_php alapértelmezetten be van kapcsolva, és csak a php.ini-ben módosítható, a poolban nem, .htaccess-szel nem, és futásidőben sem. Az értéket ezért a weboldalakat kiszolgáló minden üzemmód php.ini-jében állítsa be, vagyis Debianon és Ubuntun például a /etc/php/<version>/fpm/ alatt, és adott esetben a /etc/php/<version>/apache2/ alatt.

; A webes SAPI php.ini-je, utána a PHP-FPM-et illetve az Apache-ot újraindítani
expose_php = Off

Ha több PHP-verzió fut párhuzamosan, mindegyiknek szüksége van a bejegyzésre. Az érintett szolgáltatás újraindítása kötelező, mert a PHP a php.ini-t csak induláskor olvassa be.

A Server-fejléc rövidítése az Nginxben és az Apache-ban

Az Nginx alapértelmezetten megnevezi a verzióját a Server fejlécben és a hibaoldalakon. A server_tokens off; esetén csak a terméknév marad. Ezenfelül az alkalmazás által maga beállított X-Powered-By fejléc a fastcgi_hide_header-rel kiszűrhető. Az Nginx dokumentációja szerint az Nginx magától csak a Status és az X-Accel-… fejléceket rejti el, az X-Powered-By-t nem.

# a http-blokkban, minden weboldalra érvényes
server_tokens off;
fastcgi_hide_header X-Powered-By;

Az Apache-ban a ServerTokens a Server fejlécet és egyúttal a hibaoldalak alatti verziósort szabályozza. A beállítás az Apache dokumentációja szerint csak szerverszinten érvényes, nem VirtualHostonként. Mivel a PHP-FPM válaszai a mod_proxy_fcgi-n keresztül más fejléctáblába kerülnek, mint a szerver saját válaszai, az eltávolítást mindkét változatban állítsa be.

# szerverszintű konfiguráció, pl. /etc/apache2/conf-available/security.conf
ServerTokens Prod
ServerSignature Off

# a mod_headers szükséges hozzá
<IfModule mod_headers.c>
    Header unset X-Powered-By
    Header always unset X-Powered-By
</IfModule>

Az újratöltés előtt ellenőrizze a konfigurációt az nginx -t illetve az apachectl configtest paranccsal. Hogyan kapcsolhat be a fejlécekkel aktívan védelmet a látogatók számára, például HSTS-sel vagy Content-Security-Policyvel, azt a Biztonsági fejlécek weboldalakhoz útmutató írja le.

Így ellenőrizze az eredményt kívülről

Az átállás után ellenőrizze egyenként az összes domaint, lehetőleg egy hibaoldalt is. A következő parancsok csak normál kéréseket küldenek a saját weboldalaira:

# A nyitóoldal fejlécei
curl -sI https://www.example.de/ | grep -iE '^(server|x-powered-by):'
# Egy nem létező oldal fejlécei
curl -sI https://www.example.de/gibt-es-nicht-4711 | grep -iE '^(server|x-powered-by):'

Elvárt egy verziószám nélküli Server fejléc és X-Powered-By hiánya. Ha továbbra is PHP-verzió áll ott, többnyire egy másik php.ini aktív, vagy egy szolgáltatást még nem indítottak újra. Ha a szerver előtt CDN áll, ellenőrizze ezenkívül közvetlenül az origin szervert is, ha elérhető.

Mit ér az elrejtés, és mit nem

Őszintén besorolva a verziómegjelölések kikapcsolása kis intézkedés csekély ráfordítással. Csökkenti annak valószínűségét, hogy bizonyos verziókra irányuló célzott keresésekben felbukkanjon, és kevesebb olyan információt ad, amelyet a támadó fáradság nélkül megkap.

Az automatizált támadások ellen viszont nem véd, amelyek a kéréseiket egyszerűen minden elérhető szerverre elküldik. Hogyan zajlanak az ilyen tömeges vizsgálatok, azt a Tömeges vizsgálatok javítatlan PHP után cikk írja le. A PHP2Shell ellen csak a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, illetve egy megerősített backportra való frissítés segít, amelyet az összes PHP-folyamat újraindítása követ.

Egy mellékhatás ezzel szemben kifejezetten hasznos: aki kifelé kikapcsolja a verziómegjelöléseket, annak belül rendesen nyilván kell tartania a verzióit. Egy olyan helyzetben, mint a PHP2Shell, éppen ez az áttekintés dönti el, milyen gyorsan tudja meg, mely szerverek érintettek.

Az elrejtésnek ezért egy alapkeményítés részeként van értelme, nem önálló intézkedésként. Ugyanabba az ellenőrzőlistába tartozik, mint a kikapcsolt hibakimenetek, a törölt tesztfájlok és a zárolt konfigurációs értékek.

Hogyan segít konkrétan a PHP SOS?

• A lelőhelyek felmérése: Az összes domain fejléceit, hibaoldalait és webrootját ellenőrizzük verziómegjelölések és elfelejtett tesztfájlok után.
• A konfiguráció igazítása: Az expose_php, a Server-fejlécek és a fejlécszűrők beállítását minden PHP-verzióban és webszerverben elvégezzük, és a szolgáltatásokat ellenőrzötten újraindítjuk.
• A javítási állapot belső igazolása: A verziókat és csomagállapotokat ott dokumentáljuk, ahová valók, a leltárban, nem a HTTP-fejlécben.
• Beágyazás a keményítésbe: Az intézkedés a PHP-webszerverek szerverkeményítésének része.

Gyakori kérdések

Források

• PHP kézikönyv: alapbeállítások (expose_php)
• Nginx: server_tokens (ngx_http_core_module)
• Apache: ServerTokens és ServerSignature
• OWASP Cheat Sheets