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

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

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

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

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

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

#!/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 í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.

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

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 írja le; hogy más nyomok mire utalnak még egy behatolásra, az a Megtámadtak már? 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 keretében rögzítjük.

Gyakori kérdések

Források

• nftables-wiki: egyszerű szabályrendszer egy szerverhez
• Ubuntu Server: tűzfal (ufw)
• BSI IT-Grundschutz (a német Szövetségi Információbiztonsági Hivatal módszertana)
• CIS Benchmarks