Home page logo
/
Intro Reference Guide Book Install Guide
Download Changelog Zenmap GUI Docs
Bug Reports OS Detection Propaganda Related Projects
In the Movies In the News

Sponsors


Nmap Network Scanning

Kapuletapogatási technikák

Mint kezdő autószerelő, több órás küzdelmet folytattam azért, hogy a munkához szükséges legelemibb szerszámok (kalapács, ragasztószalag, csavarkulcs stb.) kéznél legyenek. Miután szánalmas kudarcot vallottam, elvontattam a tragacsomat egy igazi szerelőhöz. Ő szintén sokáig kotorászott egy óriási szerszámos ládában de végül előhúzta a megfelelő ketyerét, amivel aztán könnyedén elvégezte a munkát. A kapuletapogatás művészete is hasonló. A szakértők ismerik a letapogatási technikák százait és minden feladathoz a megfelelőt (vagy több kombinációját) használják. Másfelől viszont a gyakorlatlan felhasználók és a szkriptkölykök minden feladathoz az alap SYN letapogatást használják. Mivel az Nmap ingyenesen elérhető, így a mesteri letapogatás egyetlen határa a tudás. Így természetesen legyőzi az autóipart, ahol már annak a meghatározásához is elég sok szaktudás kell, hogy miféle szerszámra lesz szükség. Ráadásul ezt még meg is kell venni egy rakás pénzért.

A legtöbb letapogatási technikát kizárólag kiemelt felhasználók érik el. Ez azért van, mert ezek a technikák nyers csomagok küldésével dolgoznak, melyhez rendszergazdai hozzáférés szükséges. Windows rendszereken is ajánlatos rendszergazda szintű felhasználóként használni a programot még akkor is, ha a WinPcap programkönyvtár elérhető az operációs rendszerhez. A rendszergazda szintű használat az Nmap 1997-es megjelenésekor egy komoly korlátozás volt, mivel akkoriban a legtöbb felhasználónak csak korlátozott parancshéj hozzáférése volt. Ma már más a helyzet. A számítógépek olcsóbbak, sokkal több ember kapcsolódik folyamatosan az Internetre és az asztali Unix rendszerek (mint például a Linux és a Mac OS X) is jobban elterjedtek. Ma már elérhető az Nmap Windows környezetben is, így még több gépen használható. Mindezeknek köszönhetően egyre kevesebb helyen kell az Nmap programot korlátozott parancshéj alatt futtani. Ez jó dolog, mivel a kiemelt felhasználóknak nyújtott szolgáltatások teszik a programot erőteljessé és rugalmassá.

Bár az Nmap a lehető legpontosabb eredményre törekszik, nem szabad megfeledkezni arról, hogy minden eredménye a célállomás (vagy egy előtte lévő tűzfal) által visszaküldött csomagokon alapul. Ezek lehetnek megbízhatatlan állomások, melyek szándékosan megtévesztő válaszokat küldenek. Meglehetősen elterjedtek az olyan állomások, melyek az Nmap próbáira nem úgy válaszolnak, ahogyan azt az RFC szabványok meghatározzák. A FIN, NULL és Xmas letapogatások különösen érzékenyek az ilyen problémákra. Ezek a problémák erősen kötődnek egyes letapogatási típusokhoz, így a megfelelő letapogatások leírásainál részletesen is foglalkozunk velük.

Ebben a szakaszban található az Nmap által támogatott tucatnyi letapogatási technika leírása. Egyszerre csak egyféle technika használható. Kivételt képez az UDP letapogatás (-sU), mely bármelyik TCP letapogatással kombinálható. A letapogatások típusának megadása a következő formátumban lehetséges: -s<C>, ahol a <C> a letapogatás nevének egy kiemelt betűje, általában az első. Az egyetlen kivétel a sokak által utált FTP ugráló letapogatás (-b). Alapértelmezetten az Nmap egy SYN letapogatást hajt végre. Kivétel, ha a felhasználónak nincs megfelelő jogosultsága nyers csomagok küldésére, vagy a célpont címe IPv6 formátumú. Ilyenkor a hagyományos connect() letapogatás történik. Az ebben a szakaszban felsorolt letapogatásokat csak kiemelt felhasználók hajthatják végre. Normál felhasználók csak a connect() és az FTP ugráló letapogatásra jogosultak.

-sS (TCP SYN letapogatás)

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.

-sT (TCP connect letapogatás)

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.

-sU (UDP letapogatások)

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.

-sN; -sF; -sX (TCP NULL, FIN és Xmas letapogatás)

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:

NULL letapogatás (-sN)

Nem állít be egyetlen bitet sem (a TCP zászlók értéke 0)

FIN letapogatás (-sF)

Csak a TCP FIN bitet állítja be.

Xmas letapogatás (-sX)

Beállítja a FIN, PSH és URG zászlókat, így a csomag olyan lesz, mint a karácsonyfa.

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.

-sA (TCP ACK letapogatás)

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.

-sW (TCP Window letapogatás)

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.

-sM (TCP Maimon letapogatás)

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.

--scanflags (Testreszabott TCP letapogatás)

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.

-sI <zombi állomás[:próbakapu]> (Üresjárati letapogatás)

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 http://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.

-sO (IP protokoll letapogatás)

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.

-b <FTP átjátszó állomás> (FTP ugráló letapogatás)

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.

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]