Portvizsgálati technikák

-sS(TCP SYN vizsgálat)

A SYN vizsgálat az alapértelmezett és legnépszerűbb vizsgálati lehetőség. Gyorsan elvégezhető, másodpercenként több ezer portot vizsgálva egy gyors hálózaton, amelyet nem akadályoznak korlátozó tűzfalak. Viszonylag nem feltűnő és lopakodó, mivel soha nem fejezi be a TCP-kapcsolatokat. A SYN scan bármilyen kompatibilis TCP stack ellen működik, nem pedig az egyes platformok sajátosságaitól függ, mint az NmapFIN/NULL/Xmas, Maimon és idle scanjei. Emellett lehetővé teszi a open,closed és filteredállapotok egyértelmű,megbízható megkülönböztetését.

Ezt a technikát gyakran nevezik félig nyitott szkennelésnek,mivel nem nyit meg egy teljes TCP-kapcsolatot. Küldesz egy SYN csomagot,mintha valódi kapcsolatot nyitnál, majd vársz a válaszra. A SYN/ACK jelzi, hogy a port figyel (nyitott), míg aRST (reset) azt jelzi, hogy nem figyel. Ha többszöri újraküldés után sem érkezik válasz, a portot szűrtnek jelöli. A port akkor is szűrtnek minősül, ha ICMP elérhetetlen hiba (3. típusú, 0, 1, 2, 3, 9, 10 vagy 13 kódú) érkezik. A port akkor is nyitottnak minősül, ha válaszként SYN csomag (ACK jelző nélkül) érkezik. Ennek oka lehet egy rendkívül ritka TCP-funkció, az egyidejűleg nyitott vagy osztott kézfogás-kapcsolat (lásd https://nmap.org/misc/split-handshake.pdf).

-sT(TCP connect scan)

A TCP connect scan az alapértelmezett TCP-ellenőrzési típus, ha a SYN-ellenőrzés nem opció. Ez az az eset, amikor a felhasználó nem rendelkezik nyers csomagjogosultsággal. Ahelyett, hogy nyers csomagokat írna, mint a legtöbb más letapogatás típus, az Nmap a connect rendszerhívás kiadásával megkéri a mögöttes operációs rendszert, hogy hozzon létre kapcsolatot a célgéppel és a porttal. Ez ugyanaz a magas szintű rendszerhívás, amelyet a webböngészők, a P2P-kliensek és a legtöbb más hálózatra képes alkalmazás használ kapcsolat létrehozására.Ez a Berkeley SocketsAPI néven ismert programozási interfész része. Ahelyett, hogy nyers csomagválaszokat olvasna be a vezetékről, az Nmap ezt az API-t használja arra, hogy állapotinformációkat kapjon minden egyes kapcsolódási kísérletről.

Ha a SYN-ellenőrzés elérhető, általában ez a jobb választás. Az Nmapnek kevesebb ellenőrzése van a magas szintű connect hívás felett, mint a nyers csomagok esetében, így kevésbé hatékony. A rendszerhívás inkább befejezi a kapcsolatokat a nyitott célportokhoz, minthogy a SYN scan által végzetthalf-open alaphelyzetbe állítást végezze. Ez nem csak hosszabb ideig tart és több csomagot igényel ugyanannak az információnak a megszerzéséhez, de a célgépek nagyobb valószínűséggel naplózzák a kapcsolatot. Egy megfelelő IDS mindkettőt észleli, de a legtöbb gépnek nincs ilyen riasztórendszere. Az átlagos Unix-rendszer sok szolgáltatása ad egy megjegyzést a syslogba, és néha egy rejtélyes hibaüzenetet, amikor az Nmap csatlakozik, majd lezárja a kapcsolatot adatküldés nélkül. Igazán szánalmas szolgáltatások összeomlanak, amikor ez történik, bár ez nem gyakori. Egy rendszergazdának, aki egyetlen rendszerről egy csomó csatlakozási kísérletet lát a naplójában, tudnia kell, hogy csatlakozási vizsgálat történt.

-sU(UDP vizsgálatok)

Míg az interneten a legtöbb népszerű szolgáltatás a TCPprotokollon keresztül fut, az UDP szolgáltatások széles körben elterjedtek. A DNS, az SNMP és a DHCP (regisztrált 53, 161/162 és 67/68 portok) a három legelterjedtebb. Mivel az UDP-ellenőrzés általában lassabb és nehezebb, mint a TCP, néhány biztonsági ellenőr figyelmen kívül hagyja ezeket a portokat. Ez hiba, mivel a kihasználható UDP-szolgáltatások meglehetősen gyakoriak, és a támadók biztosan nem hagyják figyelmen kívül az egész protokollt. Szerencsére az Nmap segíthet azUDP-portok leltározásában.

AzUDP-ellenőrzés a -sU opcióval aktiválható. Kombinálható egy TCP-ellenőrzési típussal, például a SYN-ellenőrzéssel (-sS), hogy mindkét protokollt ellenőrizze ugyanazon futás során.

Az UDP-ellenőrzés úgy működik, hogy minden célzott portra UDP-csomagot küld. Néhány gyakori port esetében, mint például az 53 és 161, a protokollspecifikus hasznos teher kerül elküldésre a válaszadási arány növelése érdekében, de a legtöbb port esetében a csomag üres, kivéve, ha a --data,--data-string vagy --data-lengthopciókat adjuk meg.Ha egy ICMP port elérhetetlen hiba (3. típus, 3. kód) érkezik vissza, a port closed. Más ICMP elérhetetlen hibák (3. típus, 0, 1, 2, 9, 10 vagy 13 kód) a portot filtered-ként jelölik. Esetenként a szolgáltatás egy UDP csomaggal válaszol, amely bizonyítja, hogy a port open. Ha az újraküldések után sem érkezik válasz, a port open|filtered-nak minősül. Ez azt jelenti, hogy a port nyitva lehet, vagy esetleg a csomagszűrők blokkolják a kommunikációt. A verzióérzékelés(-sV) segíthet megkülönböztetni a valóban nyitott portokat a szűrtektől.

Az UDP pásztázás nagy kihívása a gyors elvégzése.A nyitott és szűrt portok ritkán küldenek választ, így az Nmap-nek időt kell szakítania, majd újratovábbításokat kell végeznie, ha a szonda vagy a válasz elveszett. A zárt portok gyakran még nagyobb problémát jelentenek.Általában ICMP port unreachable hibát küldenek vissza. De ellentétben a zárt TCP-portok által a SYN- vagy connectscanre válaszul küldött RST-csomagokkal, sok állomás alapértelmezés szerint korlátozza az ICMP port elérhetetlen üzenetek sebességét.A Linux és a Solaris különösen szigorú ebben a tekintetben. Például aLinux 2.4.20 kernel a célállomás elérhetetlen üzeneteket egy másodpercenkénti egyre korlátozza (net/ipv4/icmp.c-ben).

AzNmap észleli a sebességkorlátozást, és ennek megfelelően lassít, hogy elkerülje a hálózat elárasztását haszontalan csomagokkal, amelyeket a célgép eldob. Sajnos a Linux-stílusú, másodpercenkénti egy csomagos korlátozás miatt egy 65.536 portos vizsgálat több mint 18 órát vesz igénybe. Az UDP-ellenőrzés felgyorsítására a következő ötletek jöhetnek szóba: több állomás párhuzamos ellenőrzése, először csak a népszerű portok gyors ellenőrzése, a tűzfal mögül történő ellenőrzés, és a --host-timeout használata a lassú hostok kihagyására.

-sY(SCTP INIT scan)

Az SCTP a TCP és UDP protokollok viszonylag új alternatívája, amely egyesíti a TCP és UDP legtöbb jellemzőjét, és olyan új funkciókkal is kiegészül, mint a multi-homing és a multi-streaming. Az SCTP INIT scan a TCP SYN scan SCTP megfelelője.Gyorsan elvégezhető, több ezer portot vizsgál át másodpercenként egy gyors hálózaton, amelyet nem akadályoznak korlátozó tűzfalak.A SYN scanhez hasonlóan az INIT scan is viszonylag feltűnésmentes és lopakodó, mivel soha nem fejezi be az SCTP társításokat. Emellett lehetővé teszi a open,closed és filteredállapotok egyértelmű,megbízható megkülönböztetését.

Ezt a technikát gyakran nevezik félig nyitott szkennelésnek,mivel nem nyit meg egy teljes SCTP-asszociációt. Küld egy INITchunkot, mintha egy valódi asszociációt nyitnál, majd vársz a válaszra. Az INIT-ACK chunk azt jelzi, hogy a port figyel(nyitott), míg az ABORT chunk azt jelzi, hogy nem figyel. Ha többszöri újraküldés után sem érkezik válasz, a portot szűrtnek jelöli. A port akkor is szűrtnek minősül, ha ICMPunreachable hiba (3. típusú, 0, 1, 2, 3, 9, 10 vagy 13 kódú) érkezik.

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

Ez a három vizsgálati típus (még több lehetséges a következő szakaszban ismertetett--scanflags opcióval)kihasználja a TCP RFC egy finom kiskapuját a open ésclosed portok megkülönböztetésére. Az RFC 793 65. oldala szerint “ha a port állapota CLOSED …. egy RST-t nem tartalmazó bejövő szegmens RST-t küld válaszul”. Ezután a következő oldal a SYN, RST vagy ACKbitek beállítása nélkül nyitott portokra küldött csomagokat tárgyalja, kimondva, hogy: “

Az RFC-szövegnek megfelelő rendszerek vizsgálatakor minden olyan csomag, amely nem tartalmaz SYN, RST vagy ACK biteket, egy visszaküldött RST-t eredményez, ha a port zárt, és egyáltalán nem válaszol, ha a port nyitott. Amíg e három bit egyike sem szerepel, a másik három (FIN, PSH és URG) bármilyen kombinációja rendben van. Az Nmap ezt három letapogatási típussal használja ki:

Ez a három letapogatás típus viselkedése pontosan megegyezik, kivéve a szondázó csomagokban beállított TCP flageket. Ha egy RST csomag érkezik,a portot closed-nak tekintik, míg a válasz hiánya azt jelenti, hogy open|filtered. A portot filtered jelöli, ha ICMP elérhetetlen hiba (3. típusú, kód0, 1, 2, 3, 9, 10 vagy 13) érkezik.

Ezeknek a letapogatási típusoknak az a fő előnye, hogy át tudnak osonni bizonyos nem-stateful tűzfalakon és csomagszűrő routereken. Egy másik előnye, hogy ezek a letapogatás típusok egy kicsit titkosabbak, mint a SYN letapogatás. Erre azonban ne számítson – a legtöbbmodern IDS termék konfigurálható az észlelésükre. A nagy hátránya, hogy nem minden rendszer követi szó szerint az RFC 793-at. Számos rendszer RST választ küld a szondákra, függetlenül attól, hogy a port nyitva van-e vagy sem. Ez azt eredményezi, hogy az összes portot closed címkével látják el. A főbb operációs rendszerek, amelyek ezt teszik, a Microsoft Windows, számos Cisco eszköz, a BSDI és az IBM OS/400. Ez a vizsgálat azonban a legtöbb Unix-alapú rendszer ellen is működik. Egy másik hátránya ezeknek a vizsgálatoknak, hogy nem tudják megkülönböztetni a open portokat bizonyos filtered portoktól, így a válasz open|filtered marad.

-sA(TCP ACK scan)

Ez a vizsgálat abban különbözik az eddig tárgyaltaktól, hogy soha nem határozza meg a open (vagy akár a open|filtered) portokat. Arra szolgál, hogy feltérképezze a tűzfal szabálykészleteit, meghatározva, hogy azok állapotfüggőek-e vagy sem, és hogy mely portokat szűrik.

Az ACK scan próbacsomagban csak az ACK flag van beállítva (kivéve, ha --scanflags-t használsz). Szűretlen rendszerek letapogatásakor a open és closed portok egyaránt RST csomagot küldenek vissza. Az Nmap ekkorunfiltered-ként címkézi őket, ami azt jelenti, hogy azACK csomaggal elérhetők, de hogy open vagy , azt nem lehet eldönteni. Azok a portok, amelyek nem válaszolnak, vagy bizonyos ICMP hibaüzeneteket küldenek vissza (3. típus, 0, 1, 2, 3, 9, 10 vagy 13 kód), filtered címkét kapnak.

-sW(TCP Window scan)

A Window scan pontosan ugyanaz, mint az ACK scan, kivéve, hogy kihasználja bizonyos rendszerek implementációs részletét a nyitott és zárt portok megkülönböztetésére, ahelyett, hogy mindigunfiltered-t írna ki, ha RST-t kap vissza. Ezt úgy teszi, hogy megvizsgálja a visszaküldött RST csomagok TCP Window mezőjét. Egyes rendszereken a nyitott portok pozitív ablakméretet használnak (még az RST csomagok esetében is)míg a zártak nulla ablakot. Így ahelyett, hogy egy portot mindig unfiltered-ként listázna, amikor RST-t kap vissza,a Window scan open vagy closed-ként listázza a portot, ha a TCP Window értéke a visszaállításban pozitív, illetve nulla.

Ez a vizsgálat az interneten lévő rendszerek egy kisebb részének végrehajtási részletére támaszkodik, így nem lehet mindig megbízni benne. Azok a rendszerek, amelyek nem támogatják, általában az összes portot visszaadjákclosed. Természetesen lehetséges, hogy a gépen valóban nincsenek nyitott portok. Ha a legtöbb beolvasott portclosed, de néhány gyakori portszám (például 22,25, 53) filtered, akkor a rendszer nagy valószínűséggel érzékeny. Előfordul, hogy a rendszerek pont az ellenkező viselkedést mutatják. Ha a vizsgálat 1000 nyitott portot és három zárt vagy szűrt portot mutat, akkor ez a három lehet a valóban nyitott port.

-sM(TCP Maimon vizsgálat)

A Maimon vizsgálat a felfedezőjéről, Uriel Maimonról kapta a nevét.A technikát a Phrack Magazine 49. számában (1996. november) írta le.Az Nmap, amely tartalmazza ezt a technikát, két számmal később jelent meg.Ez a technika pontosan ugyanaz, mint a NULL, FIN és Xmas vizsgálatok, kivéve, hogy a szonda FIN/ACK. Az RFC 793 (TCP) szerint egy RST csomagot kell generálni válaszul egy ilyen szondára, függetlenül attól, hogy a port nyitott vagy zárt. Uriel azonban észrevette, hogy sok BSD-alapú rendszeregyszerűen eldobja a csomagot, ha a port nyitott.

--scanflags(Custom TCP scan)

Az igazán haladó Nmap felhasználóknak nem kell a felkínált letapogatási típusokra korlátozódniuk. A --scanflags opció lehetővé teszi, hogy tetszőleges TCP-jelzők megadásával saját vizsgálatot tervezzen.Engedje szabadjára a kreativitását, miközben kikerüli a behatolásérzékelő rendszereket, amelyeknek a gyártói egyszerűen átlapozzák az Nmap man oldalát, és konkrét szabályokat adnak hozzá!

A --scanflags argumentum lehet egy numerikus jelzőérték, például 9 (PSH és FIN), de a szimbolikus nevek használata egyszerűbb. Csak keverjük össze a URG,ACK, PSH,RST, SYN ésFIN tetszőleges kombinációját. Például a --scanflagsURGACKPSHRSTSYNFIN mindent beállít, bár ez nem túlhasznos a szkenneléshez. A sorrend, amelyben ezeket megadjuk, nem lényeges.

A kívánt flagek megadása mellett megadhatunk egyTCP scan típust is (például -sA vagy -sF).Ez az alaptípus mondja meg az Nmap-nek, hogyan értelmezze a válaszokat. Például a SYN-ellenőrzés úgy tekinti, hogy a válasz hiányafiltered portot jelez, míg a FIN-ellenőrzés ugyaneztopen|filtered-nak tekinti. Az Nmap ugyanúgy fog viselkedni, mint az alapvizsgálati típus esetében, azzal a különbséggel, hogy helyette az Ön által megadott TCP-jelzőket fogja használni. Ha nem ad meg alaptípust, akkor a SYN vizsgálatot használja.

-sZ(SCTP COOKIE ECHO vizsgálat)

Az SCTP COOKIE ECHO vizsgálat egy fejlettebb SCTP vizsgálat. Kihasználja azt a tényt, hogy az SCTP implementációknak nyitott portokon a COOKIE ECHO darabokat tartalmazó csomagokat csendben el kell dobniuk, de ABORT-ot küldenek, ha a port le van zárva.Ennek a letapogatás típusnak az az előnye, hogy nem olyan nyilvánvaló a port letapogatás, mint az INIT letapogatás. Emellett előfordulhat, hogy vannak nem-statefulfirewall szabályrendszerek, amelyek blokkolják az INIT csomagokat, de a COOKIE ECHO csomagokat nem. Ne tévesszen meg senkit, hogy ez láthatatlanná teszi a portok vizsgálatát; egy jó IDS képes lesz észlelni az SCTPCOOKIE ECHO vizsgálatokat is.A hátránya, hogy az SCTP COOKIE ECHO vizsgálatok nem tudnak különbséget tenni a open és filteredportok között, így mindkét esetben a open|filtered állapotot kapja.

-sI <zombie host>(üresjárati pásztázás)

Ez a fejlett pásztázási módszer lehetővé teszi a célpont valóban vak TCP portjának pásztázását (ami azt jelenti, hogy a valódi IP-címéről nem küldenek csomagokat a célpontnak). Ehelyett egy egyedi oldalcsatornás támadás kihasználja a zombiállomáson a kiszámítható IP-fragmentációs ID-sorozat generálását, hogy információt szerezzen a célpont nyitott portjairól. Az IDS-rendszerek úgy jelenítik meg a vizsgálatot, mintha az Ön által megadott zombi gépről érkezne (amelynek működnie kell, és meg kell felelnie bizonyos kritériumoknak). Ennek a lenyűgöző vizsgálati típusnak a részletes leírása a “TCP Idle Scan (-sI)” című részben található.

Amellett, hogy rendkívül lopakodó (vak természetéből adódóan), ez a keresési típus lehetővé teszi a gépek közötti IP-alapú bizalmi kapcsolatok feltérképezését. A portlista a nyitott portokat mutatja a zombiállomás szemszögéből. Így kipróbálhat egy célpontot különböző zombik segítségével, amelyekről úgy gondolja, hogy megbízhatóak lehetnek (útválasztó/csomagszűrő szabályokon keresztül).

Egy kettőspontot, majd egy portszámot is hozzáadhat a zombiállomáshoz, ha egy adott portot szeretne megvizsgálni a zombin az IP-azonosító változásai miatt. Ellenkező esetben az Nmap azt a portot fogja használni, amelyet alapértelmezés szerint a TCP pingeléshez használ (80).

-sO(IP protokoll vizsgálat)

Az IP protokoll vizsgálat lehetővé teszi annak meghatározását, hogy a célgépek mely IP protokollokat (TCP, ICMP, IGMP, stb.) támogatják. Ez technikailag nem portvizsgálat, mivel nem TCP vagy UDP portszámokat, hanem IP protokollszámokat vizsgál. Mégis a-p opciót használja a beolvasott protokollszámok kiválasztására, az eredményeket a normál porttábla formátumban jelenti, és még ugyanazt az alapul szolgáló beolvasó motort használja, mint a valódi portvizsgálati módszerek. Tehát elég közel áll a portellenőrzéshez ahhoz, hogy ide tartozzon.

Amellett, hogy önmagában is hasznos, a protokollellenőrzés jól mutatja a nyílt forráskódú szoftverek erejét. Bár az alapötlet elég egyszerű, nem gondoltam arra, hogy hozzáadjam, és nem is kaptam ilyen funkcióra vonatkozó kéréseket. Aztán 2000 nyarán, Gerhard Rieger megalkotta az ötletet, írt egy kiváló javítást, ami megvalósította, és elküldte az Announce levelezési listára (akkor még nmap-hackers néven).Beépítettem a javítást az Nmap fába, és másnap kiadtam egy új verziót. Kevés olyan kereskedelmi szoftver van, amelynek felhasználói elég lelkesek ahhoz, hogy saját fejlesztéseket tervezzenek és azokhoz hozzájáruljanak!

A protokollvizsgálat az UDP vizsgálathoz hasonlóan működik. Ahelyett, hogy az UDP csomag portszám mezőjét vizsgálná, az IP csomag fejlécét küldi, és a nyolc bites IP protokoll mezőt vizsgálja.A fejlécek általában üresek, nem tartalmaznak adatot, és még az igényelt protokollnak megfelelő fejlécet sem. A kivételek a TCP, UDP, ICMP, SCTP és IGMP. Ezekhez megfelelő protokollfejléc tartozik, mivel egyes rendszerek másképp nem küldenek ilyeneket, és mert az Nmap már rendelkezik funkciókkal ezek létrehozására. Az ICMP portunreachable üzenetek figyelése helyett a protocol scan az ICMPprotokoll elérhetetlen üzeneteket figyeli. Ha az Nmap bármelyik protokollra bármilyen választ kap a célállomásról, az Nmap open-nek jelöli az adott protokollt. Az ICMP protokoll elérhetetlenségi hiba (3. típus, 2. kód) hatására a protokollt closed-nak, míg a port elérhetetlensége (3. típus, 3. kód) a protokollt open-nek jelöli. Más ICMP elérhetetlen hibák (3. típus, kód0, 1, 9, 10 vagy 13) a protokollfiltered jelölését okozzák (bár egyidejűleg bizonyítják, hogy az ICMPopen). Ha az újraküldések után nem érkezik válasz, a protokolltopen|filtered

-b <FTP relay host>jelöli (FTP bounce scan)

Az FTP protokoll (RFC 959) érdekes tulajdonsága az úgynevezett proxy FTP-kapcsolatok támogatása. Ez lehetővé teszi a felhasználó számára, hogy egy FTP-kiszolgálóhoz csatlakozzon, majd kérje a fájlok elküldését egy harmadik fél szerverére. Ez a funkció több szinten is alkalmas a visszaélésekre, ezért a legtöbb szerver már nem támogatja. Az egyik visszaélés, amit ez a funkció lehetővé tesz, hogy az FTP-kiszolgálót más hosztok portvizsgálatára készteti.Egyszerűen kérje meg az FTP-kiszolgálót, hogy sorban küldjön egy fájlt a célállomás minden egyes érdekes portjára. A hibaüzenet leírja, hogy a port nyitva van-e vagy sem. Ez egy jó módszer a tűzfalak megkerülésére, mivel a szervezeti FTP-kiszolgálók gyakran olyan helyen vannak elhelyezve, ahol nagyobb hozzáférésük van más belső hosztokhoz, mint bármelyik régi internetes hosztnak. Az Nmap támogatja az FTPbounce szkennelést a -b opcióval. Ez egy argumentumot fogad<username>:<password>@<server>:<port> formában.<Server> a sebezhető FTP-kiszolgáló neve vagy IP-címe. A normál URL-hez hasonlóan elhagyható a<username>:<password>,ebben az esetben az anonim bejelentkezési adatok (user:anonymous password:-wwwuser@)kerülnek felhasználásra. A portszám (és az azt megelőző kettőspont) szintén elhagyható, ebben az esetben az alapértelmezett FTP portot (21) használjuk<server>.

Ez a sebezhetőség 1997-ben, az Nmap kiadásakor széles körben elterjedt volt, de nagyrészt már javították. A sebezhető szerverek még mindig vannak, ezért érdemes kipróbálni, ha minden más nem sikerül. Ha a tűzfal megkerülése a cél, vizsgálja a célhálózatot a 21-es portra (vagy akár az FTP-szolgáltatásokra is, ha az összes portot verzióérzékeléssel vizsgálja), és használja aftp-bounceNSE szkriptet. Az Nmap megmondja, hogy az állomás sebezhető-e vagy sem. Ha csak a nyomokat próbálja eltüntetni, nem kell (és valójában nem is szabad) a célhálózaton lévő hosztokra korlátoznia magát. Mielőtt véletlenszerű internetes címeket keresne sebezhető FTP-kiszolgálók után, gondoljon arra, hogy a rendszergazdák nem biztos, hogy örülnének, ha ilyen módon visszaélne a szervereikkel.