2011-05-29

NAT detektálás és szűrés

Bizonyára másokban is felmerült már, hogy miképp lehet egyszerűen kiszűrni a NAT-os eszközök forgalmát. Általában ezek adminisztratív szemszögből vizsgálva elég nyűgös holmik, amelyekkel akár a RADIUS authentikációt vagy az access switchek port security beállításait (pl. hogy egy portról csak egy MAC címet tanuljon meg a switch) is át lehet verni.

A NAT a külvilág számára nem transzparens, a külső szemlélő számára egyetlen MAC címről  és egyetlen IP-ről érkezik minden NAT mögötti hostról a forgalom, maga a NAT-ot végző host persze lehet, hogy minden biztonsági feltételnek megfelel, a NAT mögötti eszközök azonban általában nem. A NAT-os eszközt sem hálózati szakember szokta konfigurálni, gyakran csak arról van szó, hogy a biztonságra nem túl sokat adó felhasználók -- rosszabb esetben kollégák -- szeretnének egyszerűbben hozzáférni bizonyos erőforrásokhoz, így összekötnek egy SOHO IPv4 NAT routerrel két hálózatot, például a vendégek számára fenntartott internetet subnetet mondjuk valamelyik belső subnettel. Így a SOHO routeren keresztül, ha az tud statikus route-okat (szinte mind ilyen) egyszerre férnek hozzá belső erőforrásokhoz valamint a Facebookkal, Napiszarral, akármivel felturbózott internethez. Máskor az egyetlen MAC címre redukált hozzáférést többszörözik meg egy NAT-os host segítségével, és akkor még nem is beszéltünk olyan gondokról, amikor a NAT-hoz wi-fi is társul. Akárhogy is, azért az ilyesmi előbb-utóbb valakinek feltűnik, rosszabb esetben a SOHO router DHCP szervere "elszabadul", vagy éppen az válik érdekessé, hogy egy-egy host milyen gyanúsan sokat forgalmaz, és akkor derül ki róla, hogy NAT-ol még jó pár egyéb host számára.

A NAT detektálása külön művészet, több módszer létezik rá, egy dolog azonban közös bennük: nagyjából mind megbízhatatlan. Nyolc-kilenc éve jelentek meg a NAT detektálásról az első komolyabb tanulmányok, az egyik sokat hivatkozott publikáció a "Detecting NAT devices using sFlow", melyben a szerző (Peter Phaal) rögtön két módszert is bemutat. Az IP TTL alapú módszer igen egyszerű, abból indul ki, hogy az egyes OS-ek TTL kezdőértéke jól tudható, a mostanában használt Windowsok például 128-as TTL-lel indítják útnak a csomagjaikat, a Linuxok 64-gyel (egyéb default TTL értékek itt), így a hálózatunk topológiájának ismeretében viszonylag egyszerű meghatározni, hogy a topológia adott helyén milyen TTL-eket kellene látnunk a IP fejlécekben. Nyilván, ha ezeknél épp eggyel kevesebbet látunk, az beszédes, és könnyen lehet, hogy egy NAT routeren áthaladva lett a TTL mező értéke eggyel kisebb, mint a normál hostokról származó csomagok TTL mezejének értéke.

A másik módszer az IP ID mező értéke alapján történő statisztika készítése, amivel meg lehet becsülni, hogy mennyi host található egy-egy NAT eszköz mögött. Az IP ID módszer azonban leginkább Windows rendszerekkel működik jól, ugyanis ezeken kiszámítható az IP ID mező kezelése, a rendszer mindig eggyel növeli az értéket. Linuxon sessiononként random a kezdőérték, míg például az OpenBSD alatt minden egyes csomagban random az IP ID értéke. Az IP ID mezőre építő megoldásról egyébként külön értekezik a Columbia Egyetem egyik professzora, Steven M. Bellovin is az "A Technique for Counting NATted Hosts" című munkájában.

További módszer az eszközeinken áthaladó forgalmon végzett passzív OS fingerprinting, ennek lényege, hogy egy adott host nem fog rövid időn belül különféle OS-ekre jellemző tulajdonságokat mutatni, amennyiben mégis így történik, valószínű, hogy NAT-os eszközről van szó. Az OS fingerprinting és az IP ID módszer hátránya, hogy ezek sokkal inkább illenek mondjuk egy auditor eszköztárába, viszonylag erőforrásigényesek, ráadásul nem lehet őket real time szűrésre felhasználni. Ezzel szemben az IP TTL módszer egyszerű, mint az ék, és ha ismerjük a ránk bízott hálózatokat, akár real time szűréseket is be tudunk vezetni, bízva abban, hogy felhasználóink nem birizgálják a TTL kezdőértéket. IOS-ben extended ACL szükséges a TTL-re építő szűréshez, Linux alatt, a Netfilterben pedig külön modul (-m ttl) áll rendelkezésünkre.

Végül vannak természetesen törekvések komplex módszerek kialakítására is, amelyekben a fenti eljárások mindegyikét használják egymással párhuzamosan, hogy megbízhatóbb eredményeket kapjanak, egy ilyenről olvashatunk a "NetFlow Based System for NAT Detection" című szösszenetben.

Nincsenek megjegyzések:

Megjegyzés küldése