# Tűzfal webszerverekhez: csak a szükséges portokat nyissa meg

> Tűzfal webszerverhez: nyitott portok ellenőrzése, csak a 80 és 443 engedélyezése, SSH korlátozása, kimenő kapcsolatok szűkítése nftablesszel és ufw-vel.

Forrás: https://phpsos.de/hu/blog/firewall-fuer-webserver/  
Á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 webszerverek tűzfala bejövően csak a TCP 80-at és 443-at engedi, HTTP/3 esetén ezenkívül az UDP 443-at, az SSH-t pedig csak ismert hálózatokból. Minden mást eldob: az adatbázisok, gyorsítótárak, a PHP-FPM és a kezelőfelületek nem valók az internetre. Először az `ss -tulpn` paranccsal ellenőrizze, mi hallgat, majd építsen egy „eldobás” alapértelmezésű szabályrendszert, és tesztelje az eredményt kívülről. A kimenő kapcsolatok korlátozása ezenkívül mérsékli egy behatolás következményeit.

## Az elfelejtett ajtók a bejárati ajtó mellett

A PHP2Shellnél a tekintet magára a webszerverre irányult, a 80-as és 443-as portokra. Ezeknek nyitva kell lenniük, különben nincs weboldal. Az ilyen rések utáni állapotfelméréseknél azonban gyakran valami más tűnik fel: a bejárati ajtó mellett további ajtók állnak nyitva. Egy adatbázis az összes hálózati interfészen hallgat, egy PHP-FPM-pool a 9000-es porton, egy jelszó nélküli gyorsítótár-szolgáltatás, egy kezelőfelület a beüzemelési fázisból.

Mindegyik ilyen ajtó saját támadási felület saját résekkel. Egy tűzfal, amely csak a szükségeset engedi át, néhány szabállyal lezárja őket. Ez egyike a saját szerver biztosítása leghatékonyabb intézkedéseinek, ahogyan a [Root szerver és vServer saját biztosítása](https://phpsos.de/hu/server/root-server-vserver/) oldal is leírja.

## Mi tartozik a nyitottak közé, és mi nem?

Az alapelv egy engedélyezési lista: minden zárva van, és csak a tudatosan engedélyezett szolgáltatások érhetők el. A következő áttekintés segít a besorolásban.

| Szolgáltatás | Tipikus port | Kívülről elérhető? |
|---|---|---|
| HTTP és HTTPS | TCP 80, TCP 443 | igen |
| HTTP/3 (QUIC) | UDP 443 | csak ha használják |
| SSH | TCP 22 | csak ismert hálózatokból vagy VPN-nel |
| Tárhelypanel | terméktől függően | csak ismert hálózatokból |
| MySQL/MariaDB, PostgreSQL | TCP 3306, TCP 5432 | nem |
| Redis, Memcached | TCP 6379, TCP 11211 | nem |
| PHP-FPM | TCP 9000 vagy Unix-socket | nem, jobb csak socket |
| Levelezőszerver | TCP 25, 465, 587, 993 | csak ha a szerver leveleket fogad vagy biztosít |

Egy szolgáltatásnak, amelynek nem kell kifelé elérhetőnek lennie, ezenkívül csak a `127.0.0.1`-en vagy egy Unix-socketen szabad hallgatnia. Ekkor a tűzfal meghibásodása esetén is elérhetetlen marad. A kezelői hozzáféréshez IP-engedélyezések vagy VPN alkalmasak; részletek az [Adminisztrációs területek elzárása IP-vel, VPN-nel vagy kiegészítő védelemmel](https://phpsos.de/hu/blog/admin-bereiche-abschirmen/) cikkben.

## 1. lépés: megállapítani, mi hallgat

Mielőtt szabályokat írna, szerezzen áttekintést. A következő parancsok csak olvasnak:

```bash
# Az összes hallgató TCP- és UDP-port a folyamattal
sudo ss -tulpn
# Az nftables aktuális szabályrendszere
sudo nft list ruleset
# Az ufw állapota, ha használják
sudo ufw status verbose
```

Az `ss` kimenetében figyeljen a port előtti címre. A `0.0.0.0` vagy a `[::]` azt jelenti: a szolgáltatás az összes interfészen hallgat. A `127.0.0.1` azt jelenti: csak helyben. Jegyezze fel minden szolgáltatásnál, hogy kívülről elérhetőnek kell-e lennie. Ez a lista egyúttal a szerverleltára egy része.

## Tűzfal webszerverhez nftablesszel

Az nftables a Linux aktuális csomagszűrője. A következő szabályrendszer a hivatalos nftables-wiki példájához igazodik, és kiegészít egy csak egy kezelői hálózatból érvényes SSH-engedélyezéssel. A címek dokumentációs példák, és le kell cserélni őket.

```nft
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    set verwaltung_v4 {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.0/28 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        ct state vmap { established : accept, related : accept, invalid : drop }
        iifname lo accept

        # Az IPv6-nak szüksége van a szomszédfelderítésre
        icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        icmp type echo-request limit rate 5/second accept
        icmpv6 type echo-request limit rate 5/second accept

        # Weboldal
        tcp dport { 80, 443 } accept
        # csak HTTP/3 esetén:
        # udp dport 443 accept

        # SSH csak a kezelői hálózatból
        ip saddr @verwaltung_v4 tcp dport 22 accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }
}
```

A szabályrendszert betöltés előtt ellenőrizze az `nft -c -f /etc/nftables.conf` paranccsal. Az első sor, a `flush ruleset`, törli az összes meglévő szabályt, azokat is, amelyeket a Docker vagy a Fail2ban jegyzett be. Azokon a szervereken, amelyeken Docker vagy más, saját szabályokat felállító szolgáltatások futnak, ezért igazítsa a szabályrendszert, ahelyett hogy átalányban lecserélné. Hogyan működik együtt a Fail2ban a tűzfallal, azt a [A Fail2ban beállítása webszerverekhez](https://phpsos.de/hu/blog/fail2ban-fuer-webserver/) írja le.

Aki egyszerűbbet szeret, Ubuntun az `ufw`-t használja. A sorrend fontos: először az SSH-engedélyezés, utána a bekapcsolás.

```bash
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 203.0.113.0/28 to any port 22
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
```

> **Fontos:**
> A tűzfalszabályokat távoli szervereken csak második hozzáférési úttal módosítsa, például a szolgáltatója konzoljával. Egy hibás SSH-szabály különben kizárja Önt.

## Kimenő kapcsolatok: az alulbecsült fele

A legtöbb tűzfal kimenően mindent engedélyez. Egy webszerver számára ez nagyvonalú. Egy behatolás után a támadók a kimenő kapcsolatokat eszközök letöltésére, adatok kiszivárogtatására vagy parancsok fogadására használják. Azok a webszerver- vagy PHP-folyamatok, amelyek váratlan kapcsolatokat építenek fel, ezért figyelmeztető jelnek számítanak.

A kimenő kapcsolatok korlátozása költségesebb, mert minden jogos kapcsolatot ismerni kell: frissítések csomagforrásait, fizetési szolgáltatókat, felületeket, levélküldést, időszervereket. Pragmatikus út, hogy először naplózza a kimenő kapcsolatokat, utána engedélyezési listát alakít ki, és csak ezután tilt. Hogyan ellenőrizze a meglévő kapcsolatokat, azt a [Egy szerver kimenő kapcsolatainak ellenőrzése](https://phpsos.de/hu/blog/ausgehende-verbindungen-pruefen/) írja le; hogy más nyomok mire utalnak még egy behatolásra, az a [Megtámadtak már?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldalon áll.

Végül tesztelje kívülről, egy másik számítógépről és csak a saját rendszerei ellen, mely portok érhetők el ténylegesen. Csak ez a teszt mutatja meg, hogy a Docker, a szolgáltatói tűzfal és a szerverszabályok együtt a kívánt képet adják-e.

## Összegzés: kevés szabály, nagy hatás

Egy webszerver-tűzfalnak nem kell bonyolultnak lennie. A webportok nyitva, a kezelés csak ismert hálózatokból, minden más eldobva: ezekkel az alapszabályokkal az adatbázisok, gyorsítótárak és elfelejtett szolgáltatások eltűnnek az internetről. Ez az egyik legjobb ráfordítás-haszon arányú intézkedés.

A webszerveren vagy magában a PHP-ban lévő rések ellen a tűzfal nem segít, mert éppen ezeknek a portoknak nyitva kell maradniuk. Erőssége abban rejlik, hogy a többi támadási felületet kicsin tartja, és a kimenő kapcsolatok korlátozásával mérsékli egy behatolás következményeit.

A gondozás a döntő. Minden új szolgáltatás, minden konténer és a szolgáltatónál történő minden módosítás eltolhatja a képet. Ezért minden nagyobb módosítás után és rögzített időközönként, például negyedévente, ismételje meg a kívülről végzett ellenőrzést.

## Hogyan segít konkrétan a PHP SOS?

- **A készlet felvétele:** Felmérjük az összes hallgató szolgáltatást, és kívülről ellenőrizzük, mi érhető el ténylegesen.
- **A szabályrendszer felépítése:** Engedélyezési listát készítünk a bejövő és, ahol értelmes, a kimenő kapcsolatokra, a Dockerrel, a Fail2bannel és a szolgáltatói tűzfallal egyeztetve.
- **Biztonságos átállítás:** A módosításokat második hozzáférési úttal és visszaesési tervvel hajtjuk végre.
- **Dokumentálás:** A portokat, engedélyezéseket és az indokokat a [szerverkeményítés](https://phpsos.de/hu/leistungen/server-haertung/) keretében rögzítjük.


## Gyakori kérdések

**Mely portokra van szüksége egy webszervernek?**  
A látogatók számára általában csak a TCP 80 és 443, HTTP/3 esetén ezenkívül az UDP 443. Az SSH-nak és a kezelőfelületeknek csak ismert hálózatokból vagy VPN-en keresztül szabad elérhetőnek lenniük. Az adatbázis-, gyorsítótár- és PHP-FPM-portok nem valók az internetre.

**Véd egy tűzfal a PHP2Shell ellen?**  
Nem. A PHP2Shellt a webszerveren keresztül használják ki, tehát éppen azokon a portokon, amelyeknek nyitva kell lenniük. A tűzfal viszont csökkenti a többi támadási felületet, és a kimenő kapcsolatok korlátozása mérsékelheti egy behatolás következményeit.

**Miért mutat az ufw zártnak olyan portokat, amelyek mégis elérhetők?**  
Ismert eset a Docker-konténerek: a Docker a közzétett portokat közvetlenül a csomagszűrő szabályaiba írja be, az ufw megkerülésével. Ezért a nyitott portokat mindig ellenőrizze kívülről is.

**Elég a tárhelyszolgáltatóm tűzfala?**  
A szolgáltató előtte álló tűzfala jó második réteg. A szerveren lévő tűzfalat azonban nem pótolja, mert a szolgáltatói konfiguráció hibája vagy belső kapcsolatok esetén nem hat. A legjobb, ha mindkettőt ugyanazokkal az alapszabályokkal használja.

## Források

- [nftables-wiki: egyszerű szabályrendszer egy szerverhez](https://wiki.nftables.org/wiki-nftables/index.php/Simple_ruleset_for_a_server)
- [Ubuntu Server: tűzfal (ufw)](https://ubuntu.com/server/docs/how-to/security/firewalls/)
- [BSI IT-Grundschutz (a német Szövetségi Információbiztonsági Hivatal módszertana)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks)