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

> expose_php, X-Powered-By és Server-fejléc: hol árulja el a verzióját a PHP és a webszerver, hogyan kapcsolja ki a php.ini-ben, Nginxben, Apache-ban.

Forrás: https://phpsos.de/hu/blog/expose-php-versionsangaben/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

| Lelőhely | Példa | Kikapcsolás módja |
|---|---|---|
| A PHP HTTP-fejléce | `X-Powered-By: PHP/8.3.x` | `expose_php = Off` a php.ini-ben |
| A webszerver HTTP-fejléce | `Server: nginx/1.x` vagy `Server: Apache/2.4.x (Debian)` | `server_tokens off;` illetve `ServerTokens Prod` |
| A webszerver hibaoldalai | verziósor a 404-es vagy 500-as oldalak alatt | ugyanezek a beállítások, az Apache-ban ezenkívül `ServerSignature Off` |
| Az alkalmazás fejlécei | a keretrendszerek saját `X-Powered-By` megjelölései | `fastcgi_hide_header` illetve `Header unset` |
| Fájlok a webrootban | `phpinfo()` tesztfájlok, readme- és changelog-fájlok | törölni vagy zárolni |
| PHP-hibaüzenetek | útvonalak és verziórészletek a böngészőben | `display_errors = Off` |

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](https://phpsos.de/hu/blog/phpinfo-dateien-entfernen/) 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.

```ini
; 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.

```nginx
# 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.

```apache
# 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](https://phpsos.de/hu/ratgeber/sicherheits-header/) ú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:

```bash
# 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ő.

> **Tipp:**
> A PHP-verziót belsőleg mégis tartsa nyilván: a szerverleltárban, a csomagállapottal és az utolsó ellenőrzés dátumával. A javítási állapotot a szerveren keresztül bizonyítsa, ahogyan a [A PHP-verzió és a javítási állapot helyes ellenőrzése](https://phpsos.de/hu/php2shell/php-version-pruefen/) leírja.

## 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](https://phpsos.de/hu/blog/automatisierte-massenscans/) 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](https://phpsos.de/hu/leistungen/server-haertung/) része.


## Gyakori kérdések

**Biztonságossá teszi a szerveremet az expose_php = Off?**  
Nem. A beállítás csak a verziómegjelölést távolítja el a HTTP-fejlécből. Egy sebezhető PHP-verzió sebezhető marad, és az automatizált támadások a kéréseiket gyakran egyébként is kipróbálják minden elérhető szerveren. A támadóktól viszont elvesz egy egyszerű előválogatást, és csökkenti a szerverek keresőmotorjaiban való láthatóságot.

**Beállíthatom az expose_php-t az FPM-poolban vagy .htaccess-szel?**  
A PHP kézikönyve szerint az expose_php csak a php.ini-ben módosítható. Ezért az értéket minden webes SAPI php.ini-jében állítsa be, majd indítsa újra a PHP-FPM-et vagy az Apache-ot.

**Miért látom az X-Powered-By fejlécet az expose_php = Off ellenére?**  
Ilyenkor többnyire maga az alkalmazás vagy egy keretrendszer állítja be a fejlécet, vagy egy másik php.ini az aktív. Távolítsa el a fejlécet ezenkívül a webszerverben is: az Nginxben a fastcgi_hide_header-rel, az Apache-ban a Header unset-tel.

**Hogyan ellenőrzöm a javítási állapotomat, ha a verzió már nem látható?**  
Magán a szerveren keresztül: csomagkezelő, a CVE-számokat tartalmazó csomag-changelog és a PHP-folyamatok indítási ideje. A HTTP-fejlécben szereplő adat egyébként sem volt bizonyíték, mert a disztribúciók a backportokat gyakran új verziószám nélkül telepítik.

## Források

- [PHP kézikönyv: alapbeállítások (expose_php)](https://www.php.net/manual/en/ini.core.php)
- [Nginx: server_tokens (ngx_http_core_module)](https://nginx.org/en/docs/http/ngx_http_core_module.html)
- [Apache: ServerTokens és ServerSignature](https://httpd.apache.org/docs/2.4/mod/core.html)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)