Hálózati vizsgálatok 1. - Buta tűzfalak szabályrendszerének vizsgálata

Betörési tesztek során gyakran kerülünk olyan feladat elé, amikor meg kellene állapítani valamely TCP szintű tűzfalról, hogy milyen szabályrendszert alkalmaz.

A TCP szintig figyelő tűzfalak meglehetősen hatékonyak (legalábbis megfelelő hardverrel megtámogatva elképesztő mennyiségű forgalmat tudnak szűrni), és egyszerűen karbantarthatóak, konfigurálhatóak: definiálunk egy szabályrendszert, amely a "megfelelő", "szép" hálózati forgalomra jellemző, és a tűzfalunkra rábízzuk, hogy betartassa a szabályrendszert a rajta áthaladó forgalmon.

Alapvetően IP/PORT/irány -> go-nogo alakú szabályokat szokás definiálni, azonban a legtöbb tűzfal (már a fapados iptables is) jóval összetettebb szűrési módokat is ismer - lehet figyelni pl. egy TCP kapcsolat állapotát, lehet adatmennyiség-forgalmazási határokat definiálni, esetleg az egyszerre nyitva tartott kapcsolatok számát korlátozni: a gyakorlat azonban azt mutatja, hogy a legtöbb tűzfalon megmaradnak a szabályok az egyszerű portát(nem)engedésnél.

Egy jól működtetett informatikai infrastruktúra esetében minden tűzfalra dokumentálva vannak az implementált szabályok - white-box vizsgálatoknál tipikus esetben a tesztelők megkapják az elvárt szabályrendszer listáját és egy UTP-kábelt, amin ellenőrizniük kell, hogy valóban az történik-e a tűzfalon, amit elvárnak. Milyen lehetőségek állnak a tesztelők előtt ekkor?

ACK-scan
Az ACK-scan lényege az, hogy csomagokat küldünk a tűzfal "túloldalán" ülő hosztnak, amelyekben egyedül az ACK bit van bebillentve. Ha célhoz érnek a csomagok, mindenképp RST fog válaszul jönni - a cél nem tud mit kezdeni a csomagjainkkal.

Az igazán érdekes dolog itt az, hogy megérkeznek-e a válasz RST-k: ha igen, a tűzfalunk átengedi a vizsgált portot.

Firewalking
A firewalking az IP TTL-t használja ki: arra való a TTL, hogy a valahonnét valahová tartó csomagok előbb-utóbb lekerüljenek a hálózatról, ha esetleg kör lenne a routerek között, vagy egyéb probléma jönne közbe. A TTL-t a küldő beállítja valami értékre, és minden eszköz, amin áthalad a csomag, eggyel csökkenti az értéket: ha eléri a nullát, a legutolsó eszköz (többnyire) küld a feladónak egy ICMP TTL Exceeded üzenetet, de az eredeti csomagot nem adja tovább.

A legtöbb tűzfal (hiszen valamilyen operációs rendszeren fut, valamilyen TCP/IP stack-implementációval) szintén csökkenti a rajta áthaladó csomag TTL-jét: a vizsgálat során ezt használjuk ki. A folyamat két lépésből áll: első körben megtudjuk, hogy hányadik eszköz a sorban a tűzfal a gépünktől (hányadik hop). A hop-szám ismeretében beállítjuk a tűzfalon átjuttatni kívánt csomagok induláskori TTL-jét hop-számnyira, és elküldjük egy, a tűzfal túloldalán ülő hosztnak minden portjára a csomagjainkat - ha a tűzfalunk eldobja (azaz szűri), nem érkezik válasz, míg az átengedett csomagok esetében visszakapunk egy ICMP TTL Exceeded csomagot.

Válaszüzenetek analízise
Nem önmagában van értelmezve: az előző kettő, illetve tetszőleges, a tűzfalra mutató portscanning során érdemes figyelni azt, hogy milyen válaszok jönnek a tapogató csomagjainkra. Az nmap --reason kapcsolójával megmondja, hogy egy filtered portot azért mutat filtered-nek, mert nem érkezett válasz, vagy esetleg visszajött egy ICMP Administratively Prohibited üzenet.