Tűzfal/IDS megkerülés és becsapás

Az Internet úttörőinek szeme előtt egy teljesen nyitott hálózat lebegett, egy univerzális IP címtartománnyal, melyben bárki bárkivel kapcsolatot létesíthet. Itt bármely állomás információt kérhet és adhat bármely állomásnak. Az emberek a munkahelyükről is elérhetik az otthoni rendszereiket, beállíthatják a légkondicionálót, vagy kinyithatják az ajtó egy korán érkezett vendég előtt. Azonban a címtartomány szűkössége és bizonyos biztonsági megfontolások miatt ennek a látomásnak a megvalósítása nehézkessé vált. Az 1990-es évek elején a cégek tűzfalakat kezdtek telepíteni azzal a kifejezett szándékkal hogy az információ szabad áramlását akadályozzák. Nagyméretű hálózatokat kerítettek le az Internetről alkalmazás szűrőkkel, hálózati címfordítókkal és csomagszűrőkkel. Az információ szabad áramát szigorúan szabályozott csatornákba kényszerítették.

A hálózati akadályok, mint például a tűzfalak nagymértékben megnehezítik egy hálózat felderítését. Nehezebbé teszik a hétköznapi hálózati felderítést, mivel éppen ebbőlk a célból tervezik őket. Mindezek ellenére az Nmap számos lehetőséget kínál az ilyen komplex hálózatok megértéséhez és a szűrők működésének ellenőrzéséhez. Arra is lehetőséget biztosít, hogy bizonyos gyengén kivitelezett védelmeket meg tudjunk kerülni. Az egyik legjobb módszer a saját hálózat viselkedésének megértésére, ha megpróbálja legyőzni azt. Helyezze magát a támadó szemszögébe és próbáljon ki néhány technikát ebből a fejezetből a saját hálózata ellen. Indítson el egy FTP ugráló letapogatást, egy üresjárati letapogatást, csomagtöredék alapú támadást vagy próbáljon alagutat létrehozni egy saját proxy kiszolgálón keresztül.

Hogy tovább korlátozzák a hálózati aktivitást, a társaságok egyre gyakrabban ellenőrzik a hálózati forgalmat behatolásérzékelő rendszerekkel (IDS). Az összes nagyobb ilyen rendszer olyan szabálykészlettel érkezik, mely képes érzékelni az Nmap letapogatásait, mivel az ilyen letapogatások általában egy közelgő támadás előjelei. A legtöbb ilyen terméket azóta átalakították behatolás megelőző rendszerré (IPS), mivel képesek blokkolni a gyanúsnak ítélt forgalmat. A hálózati rendszergazdák és az IDS rendszerek szállítóinak nagy bánata, hogy a csomagok egyszerű analizálásával nagyon nehéz felismerni a rossz szándékot. A kellő türelemmel és szakértelemmel rendelkező támadók az Nmap egyes paramétereinek a segítségével könnyen megkerülhetik az IDS rendszereket. Ezalatt a rendszergazdáknak meg kell küzdeniük a rengeteg téves jelzéssel, ahol az ártatlan forgalom könnyen válthat ki riasztást vagy okozhatja a forgalom blokkolását.

Időnként emberek azt javasolják, hogy az Nmap ne biztosítson lehetőséget a tűzfalak megkerülésére, vagy az IDS rendszerek megtévesztésére. Azzal érvelnek, hogy ezeket sokkal inkább fogja egy támadó rossz szándékkal használni, mint egy rendszergazda a biztonság növelésére. Ezzel a logikával az a probléma, hogy a támadók akkor is ezeket a módszereket fogják használni, legfeljebb más eszközt fognak használni, vagy maguk írják bele azokat az Nmap programba. Eközben a rendszergazdák egyre nehezebben fogják tudni ellátni a munkájukat. Sokkal jobb védekezés egy modern, folyamatosan javított FTP kiszolgálót használni, mint egy FTP ugráló letapogatást megvalósító program terjesztését megakadályozni.

Nincs varázsfegyver (vagy Nmap paraméter) a tűzfalak és IDS rendszerek felismerésére és érzékelésére. Ehhez tudás és tapasztalat szükséges. Egy ilyen témájú oktatóanyag meghaladja ennek a leírásnak a kereteit, így csak a kapcsolódó paraméterek felsorolására és működésük rövid leírására szorítkozunk.

-f (csomagok tördelése); --mtu (a megadott MTU érték használata)

Az -f paraméter használatakor a megadott letapogatást (beleértve a visszhang letapogatást is) az Nmap apróra tördelt IP csomagokkal hajtja végre. Az alapötlet az, hogy osszuk el a TCP fejlécet több csomagra, így nehezítve meg a csomagszűrők, behatolás érzékelők és más zavaró eszközök dolgát a tevékenységünk felismerésében. Azonban legyen óvatos! Néhány programnak gondot jelent az ilyen apró csomagok kezelése. A jó öreg Sniffit szaglászóprogram az első töredék vételekor azonnal szegmentációs hibát okoz. Ha egyszer adja meg ezt a paramétert, az Nmap 8 bájtos vagy kisebb darabokra tördeli a csomagokat az IP fejléc után. Így egy 20 bájtos TCP fejlécet 3 csomagra oszt fel, 2 csomag 8 bájtot, egy csomag pedig a maradék 4 bájtot fog szállítani. Természetesen minden darab tartalmaz egy IP fejlécet is. Ha ismét megadja az -f paramétert, akkor 16 bájtos töredékeket fog használni (csökkentve a töredékek számát). De megadhat saját eltolási értéket is az --mtu paraméter használatával. Ne használja egyszerre az -f és az --mtu paramétert. Az eltolás értékének mindig oszthatónak kell lennie nyolccal. Míg egyes csomagszűrőkön és tűzfalakon nem csúsznak át a töredezett csomagok (ilyen például a Linux rendszermag bekapcsolt CONFIG_IP_ALWAYS_DEFRAG paramétere, mely sorba állítja a töredékeket), addig egyes eszközök nem engedhetik meg ezt a teljesítmény csökkenést, így tiltják ezt a lehetőséget. Ismét más rendszerek azért nem engedélyezik ezt, mert a töredékek más-más útvonalon érkezhetnek a hálózatba. Néhány forrásrendszer a rendszermagon belül állítja össze a kimenő csomagtöredékeket. Erre példa a Linux iptables kapcsolatkövetési modulja. Hogy biztos lehessen abban, hogy a kimenő csomagok töredezettek, futtasson a letapogatással együtt egy szaglászót is, mint például a Wireshark. Ha az ön operációs rendszer ilyen problémákat okoz, próbálja ki a --send-eth paramétert, így kikerülheti az IP réteget és nyers ethernet kereteket küldhet el.

-D <csali1 [,csali2][,ME],...> (Letapogatás álcázása csalikkal)

Végrehajt egy letapogatást csalik használatával, így a célpont azt érzékeli, hogy a csaliként megadott állomások is letapogatással próbálkoznak. Így az IDS rendszere egyidőben 5-10 letapogatást is érzékel, de nem tudja eldönteni, melyik a valós IP cím és melyik az ártatlan csali. Bár ezek legyőzhetőek útválasztón keresztüli nyomkövetéssel, a válasz eldobásával és más aktív eljárásokkal, de általánosságban ez egy jó mödszer a saját IP cím elrejtésére.

A csalikat listáját vesszővel kell elválasztani. Kiegészítésként használhatja a ME paramétert a csalik listájában, amely a saját IP címét jelenti. Ha a ME paramétert a hatodik vagy későbbi pozícióban használja, a legtöbb letapogatás érzékelő (mint például a Solaris Scanlogd) valószínűleg egyáltalán nem fogja megjeleníteni az IP címét. Ha nem használja a ME paramétert, az Nmap véletlen pozícióba teszi az IP címét. Használhatja az RND paramétert, így véletlenszerű, nem fenntartott IP címeket generálhat, vagy az RND:<szám> paramétert, így a <szám>-nak megfelelő mennyiségű IP címet kap.

Jegyezze meg, hogy a megadott csaliknak élő állomásoknak kell lenniük, különben véletlenül SYN elárasztásnak teheti ki a célpontokat. Ráadásul eléggé könnyű kitalálni a támadó kilétét, ha az IP címek közül csak egy él a hálózaton. Célszerűbb nevek helyett IP címeket használni (így a csalik hálózatában lévő névszerverek naplóiban nem jelenik meg az Ön IP címe).

A program a csalikat mind a kezdeti visszhang letapogatásnál (az ICMP, SYN, ACK vagy bármi más használatakor) mind a későbbi kapuletapogatásoknál használja. Szintén használja a csalikat a távoli ooperációs rendszer felderítésekor (-O). Nem használ csalikat a változat érzékeléskor és a TCP kapcsolódási letapogatásnál.

Nem érdemes túl sok csalit használni, mivel lelassíthatja a letapogatást és ronthatja a pontosságot. Ezen kívül néhány szolgáltató kiszűri a hamisított csomagokat, bár a legtöbb nem foglalkozik velük egyáltalán.

-S <IP cím> (Hamis forráscím)

Néhány esetben az Nmap nem tudja meghatározni az Ön forráscímét (ilyenkor az Nmap figyelmeztető üzenetet küld). Ilyenkor az -S paraméter után adja meg annak a hálózati illesztőnek az IP címét, amelyen keresztül a csomagokat küldeni szeretné.

Ennek a paraméternek egy másik lehetséges használata, hogy amikor a célponttal elhiteti, hogy valaki más próbálja meg letapogatni. Képzelje el, amikor egy cég azt látja, hogy egy versenytársa próbálja meg letapogatni! Az ilyen használathoz általában szükség van az -e és a -PN paraméterek használatára is. Jegyezze meg, hogy ilyenkor semmilyen választ nem fog kapni (azok a hamisított feladóhoz továbbítódnak), így az Nmap sem tud használható jelentést készíteni.

-e <illesztő> (Megadott illesztő használata)

Megadja, hogy az Nmap melyik illesztőt használja a csomagok küldésére és fogadására. Az Nmap ezt automatikusan is képes érzékelni, de meg is adhatja, ha ez nem történik meg.

--source-port <kapu száma>; -g <portnumber> (A forráskapu számának hamisítása)

Az egyik meglepően elterjedt hiba, hogy a forráskapu alapján bíznak meg egyes hálózati forgalmakban. Könnyű megérteni, miért is van ez így. Egy rendszergazda szeretne beállítani egy új, csillogó tűzfalat. Azonban a beüzemelés után a felhasználók elárasztják a panaszaikkal, mivel a programjaik többé nem működnek. Különösen a névfeloldással lehetnek problémák, mivel a külső hálózatból érkező UDP DNS válaszok többé nem tudnak belépni a belső hálózatba. Az FTP egy másik szokványos példa. Aktív FTP átviteleknél a kiszolgáló megpróbál visszafelé felépíteni egy kapcsolatot az ügyfél által kért fájl átviteléhez.

Ezekre a problémákra léteznek biztonságos megoldások, akár alkalmazásszűrők, akár protokoll feldolgozó tűzfalmodulok formájában. Sajnos vannak könnyebb, de kevésbé biztonságos megoldások is. Felismervén, hogy a DNS válaszok az 53-as kapuról, az aktív FTP kapcsolatok pedig a 20-as kapuról érkeznek, a legtöbb rendszergazda beleesik abba a csapdába, hogy egyszerűen engedélyezi ezekről a kapukról a bejövő forgalmat. Gyakran azt feltételezik, hogy a támadók nem ismerik fel és nem használják ki ezeket a réseket. Máskor úgy gondolják, hogy ez csak ideiglenes lesz, amíg egy biztonságosabb megoldást nem találnak. Aztán elfelejtkeznek róla.

Ám nemcsak a túlterhelt rendszergazdák esnek ebbe a csapdába. Számos termék érkezik ilyen gyenge szabályokkal. Különösen a Microsoft bűnös ebben a körben. A Windows 2000 és Windows XP rendszerekkel szállított IPsec szűrő tartalamaz egy hallgatólagos szabályt, mely beenged minden TCP és UDP forgalmat, mely a 88-as forráskapuról érkezik (Kerberos). Egy másik, jól ismert eset volt a Zone Alarm személyi tűzfalakban a 2.1.25-ös változatig meglévő hiba, mely beengedett minden UDP forgalmat az 53-as (DNS) vagy a 67-es (DHCP) forráskapukról.

Ezeknek a hibáknak a kihasználásához az Nmap a -g és a --source-port paramétereket biztosítja (ezek egyenértékűek). Csak adja meg kapu számát és amennyiben lehetséges, az Nmap ezzel a forráskapuval fogja elküldeni a próbákat. Bizonyos operációs rendszer érzékelési tesztekhez az Nmap más kaput fog használni a helyes működéshez. A DNS kérések végrehajtásakor a --source-port beállításait nem veszi figyelembe, mivel ezeknek a kéréseknek a kezelését az Nmap a rendszer könyvtárain keresztül végzi. A legtöbb TCP letapogatás, beleértve a SYN letapogatást, valamint az UDP letapogatás teljes mértékben támogatja ezt a paramétert.

--data-length <szám> (Véletlen adatok hozzáfűzése az elküldött csomagokhoz)

Normális esetben az Nmap csak minimális méretű csomagokat küld, melyek csak a fejlécet tartalmazzák. Így a TCP csomagjai általában csak 40, az ICMP visszhang kérései pedig csak 28 bájt hosszúak. Ennek a paraméternek a hatására az Nmap a megadott számú véletlen bájtot fűz hozzá a legtöbb elküdött csomaghoz. Az operációs rendszer érzékelésének (-O) próbacsomagjait ez nem érinti, mivel a pontosság miatt itt állandó próbákra van szükség. A legtöbb visszhang és kapuletapogató csomag azonban támogatja ezt a paramétert. Ez egy kicsit lelassítja a letapogatást, viszont kevésbé lesz feltűnő.

--ip-options <S|R [útvonal]|L [útvonal]|T|U ... >; --ip-options <hexa karakterlánc> (Csomagok küldése megadott IP paraméterekkel)

Az IP protokoll leírása felkínál pár paramétert, melyek a csomagok fejlécében használhatók. Nem úgy, mint a széles körben használt TCP paraméterek, az IP paraméterek ritkán láthatók praktikus és biztonsági megfontolások miatt. Valójában az Interneten lévő legtöbb útválasztó blokkolja a veszélyes paramétereket, mint például a forrás nyomkövetést. Néhány esetben a paraméterek hasznosak lehetnek a célpont felé vezető útvonal felderítésében és manipulálásában. Például felhasználhatja az útvonal rögzítése paramétert a célponthoz vezető útvonal felderítéséhez még akkor is, ha a hagyományos traceroute nem jár sikerrel. Vagy ha a csomagokat bizonyos tűzfalak eldobják, megadhat egy másik útvonalat a szigorú és a laza útválasztás paraméterekkel.

Az IP paraméterek megadásának leghatásosabb módja ha az --ip-options után beírja az értékeket. A hexadecimális értékeket mindig \x karakterrek kezdje, majd következik két szám. Bizonyos karaktereket ismételhet is, ha a karakter után egy csillagot ír, majd megadja az ismétlések számát. Például a \x01\x07\x04\x00*36\x01 egy olyan hexadecimális karaktersorozat, mely 36 darab NULL bájtot tartalmaz.

Az Nmap a paraméterek megadásának egy rövidebb módját is felkínálja. Az R, T és U paraméterekkel az útvonal rögzítését, az időbélyeg rögzítését, vagy mindkettőt kérheti. A laza vagy a szigorú útvonalkövetést az L vagy az S paraméter és az IP címek szóközzel elválasztott listájának megadásával kérhet.

Ha szeretné nyomon követni az elküdött és a beérkezett csomagokban lévő beállításokat, adja meg a --packet-trace paramétert. Ha további információkra és példákra kíváncsi az Nmap programban használható IP paraméterekkel kapcsolatban, látogasson el a https://seclists.org/nmap-dev/2006/q3/0052.html címre.

--ttl <érték> (A time-to-live mező beállítása)

Beállítja az IPv4 csomag time-to-live mezőjét a megadott értékre.

--randomize-hosts (Összekeveri a célpontok sorrendjét)

Utasítja az Nmap programot, hogy a letapogatás előtt keverje össze a célpontok csoportjának sorrendjét (maximum 16384 gép). Ez a letapogatást kevésbé nyilvánvalóvá teszi a legtöbb hálózati megfigyelő rendszer számára, különösen ha egy lassú időzítéssel is kombinálja. Ha nagyobb csoportot szeretne megkeverni, állítsa be a PING_GROUP_SZ paramétert az nmap.h fájlban és fordítsa le újra a programot. Egy másik megoldás lehet, ha a célpontok címeit egy lista letapogatással szedi össze (-sL -n -oN <fájlnév>), megkeveri azokat egy Perl parancsfájllal, majd ezt a listát adja át az Nmap programnak az -iL paraméterrel.

--spoof-mac <MAC cím, előtag vagy gyártó name> (MAC cím hamisítása)

Arra utasítja az Nmap programot, hogy az összes elküldött ethernet kerethez a megadott MAC címet használja. Ehhez a paraméterhez automatikusan hozzáadódik a --send-eth paraméter is, így biztosítva, hogy az Nmap valójában ethernet-szintű csomagokat küldjön. A MAC cím több formátumban is megadható. Ha a megadott paraméter egy egyszerű 0, az Nmap egy teljesen véletlen MAC címet választ arra munkamenetre. Ha a megadott karakterlánc páros számú hexadecimális számból áll (a párok elválaszthatók kettősponttal), az Nmap ezt a MAC címet fogja használni. Ha kevesebb, mint 12 számjegyet adott meg, az Nmap a fennmaradó részt véletlen értékekkel tölti fel. Ha a megadott érték nem 0 vagy hexadecimális karakterlánc, az Nmap elvégez egy keresést az nmap-mac-prefixes fájlban, hogy található-e a megadott karakterlánccal megegyező nevű gyártó (ez érzékeny a nagy- és kisbetűkre). Ha talál egyezést, az Nmap a gyártó OUI mezőjét fogja használni (3 bájtos előtag), a fennmaradó 3 bájtot pedig véletlen értékekkel tölti fel. Példák az érvényes --spoof-mac paraméterre: Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2 és Cisco.

--badsum (Csomagok küldése hamis TCP/UDP ellenőrző összeggel)

Az Nmap a csomagokat hamis TCP vagy UDP ellenőrző összeggel fogja elküldeni a célpont felé. Mivel elméletileg minden állomás IP verme az ilyen csomagokat helyesen eldobja, ezért bármilyen válasz tűzfalra vagy IDS rendszerre utal, melyek nem foglalkoznak az ellenőrző összeg vizsgálatával. További részletek erről a technikáról a https://nmap.org/p60-12.txt címen.