A SYN letapogatás az alapértelmezett és a legelterjedtebb letapogatás, nem véletlenül. Gyorsan végrehajtható, gyors hálózatokon másodpercenként több ezer kapu lepróbálható anélkül, hogy tolakodó tűzfalak zavarnák a folyamatot. A SYN letapogatás eléggé diszkrét és rejtett, mivel sosem fejeződik be a TCP kapcsolat felépítése. Bármelyik megfelelő TCP veremmel működik, ellentétben a FIN/NULL/Xmas, a Maimon vagy az üresjárati letapogatással, melyek erősen függnek az egyes operációs rendszerek egyedi veremkialakításától. Szintén előnyös, hogy tisztán megkülönböztethetők a nyitott, zárt és szűrt kapuállapotok.

Ezt a technikát gyakran nevezik félig nyitott letapogatásnak is, mivel sosem jön létre egy teljes TCP kapcsolat. Egy SYN csomag elküldésével szimuláljuk egy kapcsolat felépítését és várunk a válaszra. A SYN/ACK válasz jelzi, hogy a kapu fogadja a kapcsolódást (nyitott), az RST (reset) pedig azt, hogy nem. Ha néhány ismétlés után sem érkezik válasz, a kapu szűrt állapotúként lesz jelölve. Szintén ezt a jelölést kapja, ha egy ICMP nem elérhető hibaüzenet (kód 3, típus 1, 2, 3, 9, 10 vagy 13) érkezik.

Ha a SYN letapogatás nem érhető el, akkor a TCP connect() letapogatás válik alapértelmezetté. Ez akkor történik meg, ha a felhasználónak nincs jogosultsága nyers adatcsomagokkal dolgozni, vagy ha a célpont IPv6 címet használ. A nyers csomagok használata helyett az Nmap átadja a célpont címét és a célkapu számát az operációs rendszernek, hogy az építse fel a kapcsolatot a connect() rendszerhívás segítségével. Ugyanezt a magas szintű rendszerhívást használják a böngészők, a P2P kliensek és más hálózati alkalmazások is a kapcsolatok felépítéséhez. Ez része a Berkeley Sockets API néven ismert programozási felületnek. Az Nmap ilyenkor a nyers válaszcsomagok beolvasása helyett ezt a felületet használja az egyes kapcsolatok állapotának lekérdezésére.

Ha a SYN letapogatás elérhető, általában jobb azt választani. Az Nmap sokkal jobban kézben tudja tartani a nyers csomagokat, mint a magasabb szintű connect() rendszerhívást. A SYN letapogatás félig nyitott kapcsolataival ellentétben a rendszerhívás teljesen felépíti a kapcsolatot a célponttal. Ez nem csak tovább tart, de több adatcsomagra is van szükség ugyanannyi információ megszerzéséhez. Ráadásula célpont naplózhatja is a kapcsolódást. Egy rendes behatolás érzékelő még jelezhet is, bár a legtöbb gépen nincs ilyen riasztórendszer. Az átlagos Unix rendszereken a legtöbb szolgáltatás bejegyzést készit a rendszernaplóba a kapcsolatról, amit ráadásként még kiegészíthet egy hibaüzenettel is, ha a kapcsolatot adatküldés nélkül azonnal megszakítjuk. Néhány szánalmas szolgáltatás ilyenkor összeomlik, bár ez nem túl jellemző. Ha egy rendszergazda rengeteg, azonos helyről érkező kapcsolódást lát a rendszernaplóban, azonnal tudni fogja, hogy connect() letapogatás áldozata lett.

Bár a legismertebb Internetes szolgáltatások a TCP protokollt használják, azért az UDP alapú szolgáltatások is széles körben elterjedtek. A három legismertebb a DNS, az SNMP és a DHCP (a használt kapuk: 53, 161/162 és 67/68). Mivel az UDP letapogatás általában lassabb és sokkal bonyolultabb, mint a TCP, néhány biztonsági felülvizsgáló nem is figyel ezekre a kapukra. Ez nagy hiba, mivel eléggé elterjedtek a kihasználható UDP alapú szolgáltatások és a támadók bizonyosan nem hagyják figyelmen kívül ezeket. Szerencsére az Nmap segít leltárba foglalni az UDP kapukat is.

Az UDP letapogatás az -sU paraméterrel indítható. Kombinálható valamilyen TCP letapogatással, mint például a SYN letapogatás (-sS), így egyidőben mindkét protokoll ellenőrizhető.

Az UDP letapogatás úgy működik, hogy egy üres (adat nélküli) UDP fejlécet küldünk minden egyes célkapura. Ha ICMP "Kapu nem elérhető" hiba (3-as típus, 3-as kód) érkezik vissza, a kapu zárt. Más típusú ICMP "nem elérhető" hibák esetén (1, 2, 9, 10 vagy 13) a kapu szűrt. Alkalmanként egy szolgáltatás valamilyen UDP csomagot küldhet vissza, ezzel jelezve, hogy a kapu nyitott. Ha néhány megismételt próba után sem érkezik válasz, a kapu jelölése nyitott|szűrt. Ez azt jelenti, hogy a kapu lehet nyitott, vagy egy csomagszűrő blokkolja az átvitelt. A szolgáltatások verzióletapogatása (-sV) segíthet elkülöníteni a ténylegesen nyitott kapukat a szűrt kapuktól.

Az UDP letapogatás legnagyobb kihívása a gyors végrehajtás. A nyitott és a szűrt kapuk ritkán küldenek vissza valamilyen választ, arra kényszerítve az Nmap programot, hogy az időzítés lejártáig várakozzon, majd megismételje a próbát azt feltételezve, hogy a próba vagy a válasz elveszett. A zárt kapuk gyakran még nagyobb problémát jelentenek. Ezek általában egy ICMP "Kapu nem elérhető" hibaüzenetet küldenek vissza. De az RST csomagokkal ellentétben, melyeket a zárt TCP kapuk küldenek vissza válaszként a SYN vagy a connect() letapogatásra, a legtöbb állomás alapból korlátozza az elküldhető ICMP "Kapu nem elérhető" oüzenetek mennyiségét. A Linux és a Solaris operációs rendszerek különösen szigorúak ebből a szempontból. Például a Linux 2.4.20-as rendszermagja a "Célállomás nem elérhető" üzenetekből csak másodpercenként egyet enged elküldeni (a net/ipv4/icmp.c fájlban).

Az Nmap észleli ezt a korlátozást és képes eléggé lelassítani a próbákat, hogy megelőzze a hálózat elárasztását olyan haszontalan csomagokkal, melyeket a célállomás úgyis eldobna. Sajnos a Linux stílusú, egy csomag/másodperc korlátozás miatt a teljes 65536 UDP port letapogatása több,mint 18 óráig tart. Néhány ötlettel felgyorsítható az UDP letapogatás: több állomás letapogatása párhuzamosan, a legáltalánosabb kapuk letapogatása először, letapogatás tűzfalon belülről és a lassú állomások átugrása a --host-timeout paraméter megadásával.

Az Nmap ennek a három letapogatásnak a segítségével (a --scanflags paraméter segítségével még több lehet, erről bővebben a következő szakaszban) kiaknázza azt a hajszálnyi rést, mely a TCP RFC leírásban található és így tesz különbséget a nyitott és a zárt kapuk között. A 65-dik oldalon ez áll: „ha a célkapu ZÁRT .... egy RST bitet nem tartalmazó bejövő csomagra válaszként egy RST csomagot kell küldeni.” A következő oldalon azt tárgyalja, hogy egy nyitott kapura SYN, RST vagy ACK bit nélküli csomag „valószínűtlen, hogy érkezne, de ha mégis ez történne, a csomagot el kell dobni.”

Ha olyan rendszereket tapogatunk le, amelyek megfelelnek ennek az RFC leírásnak, akkor bármilyen olyan próbacsomag, amely nem tartalmazza a SYN, ACK vagy RST bitet egy RST választ fog kiváltani, ha a célkapu zárt és nem vált ki választ, ha a célkapu nyitott. Amíg ez a három bit nem szerepel, a másik három bit (FIN, PSH, URG) tetszőleges kombinációja használható. Az Nmap ezt három letapogatási típussal használja ki:

Mindhárom letapogatás ugyanúgy viselkedik, az egyetlen különbség a próbacsomagban beállított zászlók között van. Ha válaszként RST csomag érkezik, a kapu besorolása zárt lesz, míg ha nem érkezik válasz, a besorolás nyitott|szűrt. Ha válaszként ICMP "nem elérhető" (kód 3, típus 1, 2, 3, 9, 10 vagy 13) hiba érkezik, a kapu jelölése szűrt lesz.

Ezeknek a letapogatásoknak a legnagyobb előnye, hogy könnyen átcsúsznak egyes nem-állapottartó tűzfalakon és csomagszűrő útválasztókon. Másik előnyük, hogy némileg rejtettebbek, mint a hagyományok SYN letapogatás. Azért sokat ne várjunk - a legtöbb modern behatolásérzékelő (IDS) képes észlelni ezt a fajta letapogatást. Nagy hátrány, hogy nem minden rendszer követi szigorúan az RFC 793 előírásait. Számos rendszer RST csomagot küld vissza ezekre a letapogatásokra a kapu állapotától függetlenül. Emiatt az összes kapu zárt jelölést kap. A jelentősebb operációs rendszerek, melyek így tesznek: a Microsoft Windows, több CISCO eszköz, a BSDI és az IBM OS/400. Ennek ellenére a legtöbb Unix alapú operációs rendszer ellen használhatók ezek a letapogatások. Másik hátránya ezeknek a letapogatásoknak, hogy nemképesek különbséget tenni a nyitott és a szűrt kapuk között, így ezek a kapuk a nyitott|szűrtjelölést kapják.

Ez a letapogatás teljesen eltér az előzőekben tárgyaltaktól, mivel sosem határozza meg a nyitott (vagy a nyitott|szűrt) kapukat. Arra használható, hogy kikémleljük egy tűzfal szabályrendszerét, meghatározva hogy állapottartó vagy sem és hogy mely kapukat szűri.

Az ACK letapogatás során olyan csomagokat küldünk a célpont felé, melynek csak az ACK zászlóját állítjuk be (kivéve, ha a --scanflags paramétert is használjuk). Szűrés nélküli rendszereknél mind a nyitott, mind a zárt kapuk RST csomagot küldenek vissza erre a próbára. Az Nmap ezeket a kapukat szűretlen jelzéssel látja el, így jelölve, hogy az ACK csomag eléri a kaput, de annak nyitott vagy zárt állapota nincs meghatározva. Azok a kapuk, melyek nem válaszolnak, vagy bizonyos ICMP hibaüzenetet (kód 3, típus 1, 2, 3, 9, 10 vagy 13) küldenek vissza, szűrt jelölést kapnak.

A Window letapogatás megegyezik az ACK letapogatással. Az egyetlen különbség, hogy kihasználja egyes rendszerek TCP megvalósításának jellegzetességét, így téve különbséget a nyitott és a zárt kapuk között, ahelyett hogy minden visszakapott RST csomag esetén a kaput szűretlennek jelölne. Ezt úgy éri el, hogy megvizsgálja a visszaküldött RST csomag Window szakaszát. Néhány rendszernél a nyitott kapu esetén a Window értéke pozitív, míg zárt kapunál nulla. Így pozitív Window érték esetén a kapu nyitott, míg nulla Window érték esetén a kapu zárt jelölést kap.

Ez a letapogatás az interneten található rendszerek egy kis részének jellegzetességén alapul, így nem tekinthető teljesen megbízhatónak. Azoknál a rendszereknél, melyek nem így működnek az összes kapu zárt állapotot fog jelezni. Természetesen lehetséges, hogy a célpontnak nincs egyetlen nyitott kapuja sem. Ha a legtöbb letapogatott kapu zárt, de néhány elterjedt kapu (például a 22, 25, 53) szűrt állapotú, a rendszer legalábbis gyanús. Alkalmanként a rendszerek teljesen ellentétesen viselkednek. Ha a letapogatás 1000 nyitott és 3 zárt vagy szűrt kaput jelez, akkor valószínűleg pont az a 3 kapu a nyitott.

A Maimon letapogatás a felfedezője, Uriel Maimon után kapta a nevét. Ő a technikát a Phrack Magazine 49-es számában írta le (1996 November). Az Nmap, mely két számmal később jelent meg, szintén ismeri ezt a technikát. Az eljárás ugyanaz, mint a NULL, FIN és Xmas letapogatásnál, csak itt FIN/ACK csomagot küldünk el. Az RFC 793 (TCP) szerint egy ilyen csomag beérkezésekor mind a nyitott, mind a zárt kapunka RST csomagot kell küldenie válaszként. Uriel észrevette, hogy sok BSD alapú rendszer nyitott kapuk esetén egyszerűen eldobja ezeket a csomagokat.

Az igazán képzett Nmap felhasználóknak nem kell magukat a programba beépített letapogatási típusokra korlátozniuk. A --scanflags paraméterrel saját letapogatási típusokat tervezhetnek, tetszőleges TCP zászlók használatával. Engedje szabadon a fantáziáját, hogy kitérhessen az olyan behatolásérzékelő rendszerek elől, amelyek gyártói csak átlapozták az Nmap leírását a szabályok megadásakor!

A --scanflags paraméterezése történhet számmal (például 9 (PSH and FIN)) is, de a szimbolikus nevek használata sokkal könnyebb. Csak keverje össze az URG, ACK, PSH, RST, SYN és FIN zászlókat tetszőleges kombinációban. Például a --scanflags URGACKPSHRSTSYNFIN beállítja az összes zászlót, bár ez nem túl hasznos. A zászlók megadásának sorrendje nem lényeges.

A kívánt zászlók megadása mellet megadhatja a TCP letapogatás típusát is (például -sA vagy -sF). Ezzel az alaptípussal meghatározhatja, hogy az Nmap hogyan értelmezze a válaszokat. Például a SYN letapogatásnál ha nem érkezik válasz, akkor a kapu állapota szűrt, míg a FIN letapogatásnál ugyanez nyitott|szűrt állapotot jelez. Az Nmap ugyanúgy viselkedik, mint az alap letapogatásnál, csak a próbacsomagban a megadott zászlókat fogja használni az alap letapogatás zászlói helyett. Ha nem ad meg alaptípust, a SYN letapogatást fogja használni.

Ez a fejlett eljárás egy igazi vakon végzett TCP letapogatást hajt végre a célállomáson (ez azt jelenti, hogy a saját IP címéről semmilyen csomag nem lesz elküldve a célállomásra). Ehelyett kihasználjuk azt, hogy a zombi gépen megjósolható az IP töredezettségmező sorszámgenerátorának következő értéke és ezzel az oldaltámadással szerzünk információt a célgépen lévő nyitott kapukról. A behatolásérzékelő rendszerek úgy látják majd, hogy a letapogatás a zombi állomás felől érkezett (melynek élőnek kell lennie és meg kell felelnie bizonyos követelményeknek). Ez az elbűvölő letapogatás túl bonyolult ahhoz, hogy ebben a leírásban részletesen is foglalkozhassunk vele, ezért írtam egy részletes leírást róla, mely a https://nmap.org/idlescan.html címen olvasható.

Amellett, hogy különösen rejtett, ezzel a letapogatással kihasználható a gépek közötti, IP alapú bizalmi viszony. A nyitott kapuk ebben az esetben a zombi gép nézőpontjából láthatóak nyitottnak. Megpróbálhat letapogatni egy célállomást több olyan zombi használatával, melyekről sejthető, hogy a célpont megbízhatónak tekinti (útválasztó vagy csomagszűrő szabályok alapján).

A zombigép nevéhez kettősponttal elválasztva hozzáadhat egy kapuszámot is, ha le akarja tesztelni az IP ID változásait a zombigépen. Egyébként az Nmap a TCP visszhang próbakapuját (80) fogja használni.

Az IP protokoll letapogatással meghatározható, hogy a célállomás mely IP protokollokat (TCP, ICMP, IGMP stb.) támogatja. Technikai szempontból ez nem igazán kapuletapogatás, mivel a TCP és UDP kapuszámok helyett az IP protokoll számokon megy végig. Ugyanúgy a -p paramétert használja, csak itt a kapu száma helyett a protokoll számát kell megadni, az eredményeket ugyanolyan formátumban adja vissza, mint a kapuletapogatások és ugyanazt a letapogató motort használja, mint a kapuletapogatás. gy elég közel áll a kapuletapogatáshoz, hogy ide tartozzon.

Amellett, hogy magában is hasznos, a protokoll letapogatáson látszik a nyílt forráskódú programok igazi ereje. Bár az alapötlet meglehetősen egyszerű, nem gondoltam, hogy bele kéne vennem a programba és nem is érkezett ilyen kérés felém. Aztán 2000 nyarán Gerhard Rieger fejében megfogalmazódott az ötlet, készített egy nagyszerű kiegészítést, melyben megvalósította a letapogatást és elküldte az nmap-hackers levelezőlistára. n beillesztettem az Nmap forrásfájába és másnap kiadtam egy új változatot a programból. Csak kevés kereskedelmi programnak vannak olyan lelkes felhasználói, akik megterveznék és tadnák a saját fejlesztéseiket!

A protokoll letapogatás az UDP letapogatáshoz hasonlóan működik. Ahelyett, hogy a kapuszámokat váltogatná az UDP csomagban, IP fejléceket küldözget, melyben a 8 bites protokollmező változtatja. A fejlécek általában üresek, nem tartalmaznak adatot és egyáltalán nem felelnek meg a tesztelt protokollnak. Három kivétel van: A TCP, az UDP és az ICMP. Ezekhez a protokollokhoz létezik a megfelelő fejléc, mert egyrészt a legtöbb rendszer nem hajlandó egyébként elküldeni a csomagot, másrészt az Nmap rendelkezik az összeállításukhoz szükséges tudással. Ahelyett, hogy az ICMP "kapu nem elérhető" üzenetre várakozna, a protokoll letapogatás az ICMP protokoll nem elérhető üzenetre vár. Ha az Nmap bármelyik protokollnál bármilyen választ kap, akkor a protokoll nyitott jelölést kap. Ha egy ICMP "protokoll nem elérhető" hiba érkezik (típus 3, kód 2), akkor a protokoll zárt jelölést kap. Más ICMP hibaüzenetek (típus 3, kód 1, 3, 9, 10 vagy 13) esetén a protokoll szűrt jelölést kap (bár ez azt bizonyítja, hogy ugyanakkor az ICMP protokoll nyitott). Ha néhány ismétlés után sem érkezik válasz, akkor a protokoll nyitott|szűrt jelölést kap.

Az FTP protokoll egy érdekes lehetősége (RFC 959) az úgynevezett megbízott (proxy) FTP kapcsolat. Ez lehetővé teszi a felhasználónak, hogy csatlakozzon egy FTP kiszolgálóhoz, majd utasítsa a kiszolgálót, hogy fájlokat küldjön egy harmadik kiszolgálónak. Ez a lehetőség olyan sok visszaélésre alkalmas, hogy a legtöbb kiszolgáló nem is támogatja. Az egyik visszaélési lehetőség, hogy az FTP kiszolgálót kapuletapogatásra lehet használni egy harmadik állomás ellen. Egyszerűen arra kell utasítani az FTP kiszolgálót, hogy küldjön el egy fájlt a célállomás minden egyes érdekes kapujára. A hibaüzenetek jelzik, hogy a kapu nyitott, vagy zárt. Ez egy jó módszer a tűzfalak megkerülésére, mivel a szervezetek FTP kiszolgálói általában a tűzfalakon belül vannak, hogy a többi állomásnak szabad hozzáférése legyen a fájlokhoz. Az Nmap a -b paraméteren keresztül támogatja az FTP ugráló letapogatást, melynek formátuma a következő: <felhasználói név>:<jelszó>@<kiszolgáló>:<kapu>. A <kiszolgáló> a kihasználni kívánt FTP kiszolgáló neve, vagy IP címe. Csakúgy, mint egy hagyományos URL-nél, itt is elhagyható a <felhasználói név>:<jelszó> páros, ha a névtelen bejelentkezés engedélyezett (felhasználó: anonymous jelszó:-wwwuser@). Szintén elhaygható a kapu megadása (a bevezető kettősponttal együtt), ilyenkor az alapértelmezett FTP kaput (21) használja a program a <kiszolgálón>.

Ez a sérülékenység az Nmap 1997-es megjelenésekor széles körben elterjedt volt, de mára már nagyrészt javították. Ennek ellenére még mindig találhatók sérülékeny FTP kiszolgálók, tehát megéri kipróbálni, ha már minden más kudarcot vallott. Ha egy tűzfal megkerülése a cél, tapogassa le a célhálózatot nyitott 21-es kaput után kutatva (vagy bármilyen FTP szolgáltatás után, ha az összes kaput vizsgálja változat ellenőrzésse), azután próbálja meg az ugráló letapogatást ezek használatával. Az Nmap megadja, hogy az állomás sérülékeny-e ebből a szempontból. Ha csak a nyomait szeretné eltakarni, akkor nem szükséges kizárólag a célhálózatban lévő gépekre korlátoznia magát. Mielőtt nekiállna sérülékeny FTP kiszolgálókat keresni az Interneten, jegyezze meg, hogy a rendszergazdák nem szeretik, ha a kiszolgálóikat ilyen célból próbálják kihasználni.