-sL(List Scan)
A listás keresés a hostok felderítésének egy degenerált formája, amely egyszerűen felsorolja a megadott hálózat(ok) összes hostját, anélkül, hogy csomagokat küldene a célhostoknak. Alapértelmezés szerint az Nmap továbbra is elvégzi a hostok fordított DNS-feloldását, hogy megtudja a nevüket. Gyakran meglepő, hogy az egyszerű hosztnevek mennyi hasznos információt adnak ki. Például a fw.chi az egyik cég chicagói tűzfalának neve. Az Nmap a végén az IP-címek teljes számát is jelenti. A listavizsgálat jó szanálási ellenőrzés arra, hogy megbizonyosodjon arról, hogy a célpontok IP-címei megfelelőek. Ha a hosztok sport tartományneveit nem ismeri fel, érdemes tovább vizsgálódni, hogy elkerülje a rossz cég hálózatának szkennelését.
Mivel az ötlet egyszerűen a célállomás-listák kiírása, a magasabb szintű funkciók, például a portok szkennelése, az operációs rendszer észlelése vagy a hosztok felderítése nem kombinálható ezzel. Ha szeretné letiltani az állomásfelderítést, miközben ilyen magasabb szintű funkciókat is szeretne végrehajtani, olvasson utána a -Pn (skip host discovery) opciónak.
-sn(No port scan)
Ez az opció azt mondja az Nmap-nek, hogy az állomásfelderítés után ne végezzen portvizsgálatot, és csak azokat az elérhető állomáshelyeket nyomtassa ki, amelyek válaszoltak az állomásfelderítő szondákra. Ezt gyakran “ping scan”-ként ismerik, de kérheti a traceroute és az NSE host szkriptek futtatását is. Ez alapértelmezés szerint egy lépéssel tolakodóbb, mint a listaellenőrzés, és gyakran ugyanarra a célra használható. Lehetővé teszi a célhálózat könnyed felderítését anélkül, hogy nagy feltűnést keltene. Annak ismerete, hogy hány hoszt van fent, sokkal értékesebb a támadók számára, mint a listaellenőrzés által nyújtott lista, amely minden egyes IP-t és hosztnevet tartalmaz.
A rendszergazdák is gyakran értékesnek találják ezt a lehetőséget. Könnyen használható a hálózaton rendelkezésre álló gépek megszámlálására vagy a kiszolgálók elérhetőségének ellenőrzésére. Ezt gyakran ping sweepnek nevezik, és megbízhatóbb, mint a broadcast cím pingelése, mivel sok állomás nem válaszol a broadcast lekérdezésekre.
A -sn segítségével végzett alapértelmezett állomásfelderítés alapértelmezés szerint ICMP echo-kérésből, TCP SYN-ből a 443-as portra, TCP ACK-ból a 80-as portra és ICMP időbélyeg-kérésből áll. Ha egy nem privilegizált felhasználó hajtja végre, csak SYN csomagokat küld (egy connect hívás segítségével) a célpont 80-as és 443-as portjára. Ha egy kiváltságos felhasználó helyi ethernet hálózaton lévő célpontokat próbál vizsgálni, ARP-kéréseket használ, kivéve, ha a --send-ip volt megadva. A -sn opció a nagyobb rugalmasság érdekében kombinálható bármelyik felfedező szondatípussal (a -P* opciókkal). Ha bármelyik szondatípus és portszám opciót használjuk, az alapértelmezett szondák felülíródnak. Ha szigorú tűzfalak vannak az Nmap-et futtató forrásállomás és a célhálózat között, akkor ajánlott ezeknek a fejlett technikáknak a használata. Ellenkező esetben az állomások kimaradhatnak, amikor a tűzfal eldobja a szondákat vagy azok válaszait.
Az Nmap korábbi kiadásaiban a -sn -sP néven volt ismert.
-Pn(No ping)
Ez az opció teljesen kihagyja az állomás felderítési szakaszát. Normális esetben az Nmap ezt a szakaszt arra használja, hogy meghatározza az aktív gépeket a hevesebb pásztázáshoz, és felmérje a hálózat sebességét. Alapértelmezés szerint az Nmap csak olyan gépeken végez nehéz szondázást, mint például portvizsgálat, verzió- vagy operációsrendszer-felismerés, amelyekről kiderül, hogy üzemképesek. Az állomásfelderítés letiltása a -Pn használatával azt eredményezi, hogy az Nmap minden megadott cél-IP-címen megkísérli a kért letapogatási funkciókat. Így ha a parancssorban egy /16 méretű hálózat van megadva, akkor mind a 65 536 IP-cím átvizsgálásra kerül. A megfelelő állomáskeresés kihagyásra kerül, mint a listás keresésnél, de ahelyett, hogy megállna és kinyomtatná a célpontok listáját, az Nmap folytatja a kért funkciók végrehajtását, mintha minden egyes cél-IP-cím aktív lenne. Alapértelmezett időzítési paramétereket használ, ami lassabb letapogatást eredményezhet. Az állomásfelfedezés és a portvizsgálat kihagyásához, ugyanakkor az NSE futtatásának engedélyezéséhez használja a két -Pn -sn opciót együttesen.
A helyi ethernet-hálózaton lévő gépek esetében az ARP-szkennelés továbbra is végrehajtásra kerül (kivéve, ha --disable-arp-ping vagy --send-ip van megadva), mivel az Nmap-nek a célállomás további vizsgálatához MAC-címekre van szüksége. Az Nmap korábbi verzióiban a -Pn -P0 és -PN volt.
-PS (TCP SYN Ping)<port list>
Ez az opció egy üres TCP csomagot küld a SYN jelzővel. Az alapértelmezett célport a 80-as (fordításkor konfigurálható a DEFAULT_TCP_PROBE_PORT_SPEC megváltoztatásával a nmap.h-ben). Alternatív portok paraméterként megadhatók. A szintaxis ugyanaz, mint a -p esetében, kivéve, hogy a T:-hoz hasonló porttípus-meghatározók nem engedélyezettek. A példák a -PS22 és a -PS22-25,80,113,1050,35000. Vegye figyelembe, hogy a -PS és a portlista között nem lehet szóköz. Ha több próbát adunk meg, akkor azok párhuzamosan kerülnek elküldésre.
A SYN jelző azt sugallja a távoli rendszernek, hogy kapcsolatot próbál létrehozni. Normális esetben a célportot lezárják, és egy RST (reset) csomagot küldenek vissza. Ha a port történetesen nyitva van, a célállomás egy SYN/ACK TCP csomaggal válaszolva megteszi a TCP háromirányú kézfogás második lépését. Az Nmap-et futtató gép ekkor a készülő kapcsolatot egy RST-vel válaszolva megszakítja, ahelyett, hogy egy ACK csomagot küldene, amely befejezné a háromirányú kézfogást és teljes kapcsolatot hozna létre. Az RST csomagot az Nmap-et futtató gép kernele küldi a váratlan SYN/ACK-re válaszul, nem pedig maga az Nmap.
A Nmap-et nem érdekli, hogy a port nyitott vagy zárt. Vagy az RST, vagy a korábban tárgyalt SYN/ACK válasz közli az Nmap-pal, hogy az állomás elérhető és reagál.
A Unix gépeken általában csak a root kiváltságos felhasználó képes nyers TCP csomagokat küldeni és fogadni. A nem privilegizált felhasználók esetében automatikusan kerülő megoldást alkalmaznak, amelynek során a connect rendszerhívást kezdeményezik minden egyes célporttal szemben. Ennek hatására egy SYN csomagot küld a célállomásnak, amely megpróbál kapcsolatot létesíteni. Ha a connect gyors sikerrel vagy ECONNREFUSED hibával tér vissza, akkor a mögöttes TCP stacknek SYN/ACK-et vagy RST-t kellett kapnia, és az állomás elérhetőnek van jelölve. Ha a kapcsolatkísérlet az időkorlát eléréséig függőben marad, az állomás leállítottnak van jelölve.
-PA (TCP ACK ping)<port list>
A TCP ACK ping nagyon hasonló az imént tárgyalt SYN pinghez. A különbség, amint azt valószínűleg kitalálhatta, az, hogy a SYN-jelző helyett a TCP ACK-jelző kerül beállításra. Egy ilyen ACK csomag azt állítja, hogy egy létrehozott TCP-kapcsolaton keresztül nyugtázza az adatokat, de ilyen kapcsolat nem létezik. Ezért a távoli hosztoknak mindig RST csomaggal kell válaszolniuk, felfedve ezzel a létezésüket.
A -PA opció ugyanazt az alapértelmezett portot használja, mint a SYN szonda (80), és ugyanabban a formátumban fogadhatja a célportok listáját is. Ha egy jogosulatlan felhasználó próbálkozik ezzel, akkor a korábban tárgyalt connect megoldási módot használja. Ez a megoldás nem tökéletes, mivel a connect valójában SYN csomagot küld, nem pedig ACK-t.
A SYN és ACK ping szondák felajánlásának oka, hogy maximalizáljuk a tűzfalak megkerülésének esélyét. Sok rendszergazda úgy konfigurálja az útválasztókat és más egyszerű tűzfalakat, hogy blokkolják a bejövő SYN-csomagokat, kivéve azokat, amelyeket nyilvános szolgáltatásoknak, például a vállalati webhelynek vagy levelezőszervereknek szánnak. Ez megakadályozza a szervezethez érkező egyéb bejövő kapcsolatokat, ugyanakkor lehetővé teszi a felhasználók számára, hogy akadálytalan kimenő kapcsolatokat létesítsenek az internetre. Ez a nem-stateful megközelítés kevés erőforrást igényel a tűzfalon/routeren, és a hardveres és szoftveres szűrők széles körben támogatják. A Linux Netfilter/iptables tűzfalszoftver a --syn kényelmi opciót kínálja ennek a stateless megközelítésnek a megvalósításához. Ha ilyen stateless tűzfalszabályok vannak érvényben, a SYN ping próbák (-PS) valószínűleg blokkolva lesznek, ha zárt célportokra küldik őket. Ilyen esetekben az ACK szonda ragyog, mivel áthágja ezeket a szabályokat.
Egy másik gyakori tűzfaltípus állapotfüggő szabályokat használ, amelyek eldobják a váratlan csomagokat. Ez a funkció kezdetben főleg a csúcskategóriás tűzfalakon volt megtalálható, bár az évek során sokkal elterjedtebbé vált. A Linux Netfilter/iptables rendszer ezt a --state opcióval támogatja, amely a csomagokat a kapcsolat állapota alapján kategorizálja. Egy SYN szonda nagyobb valószínűséggel működik egy ilyen rendszer ellen, mivel a váratlan ACK csomagokat általában hamisnak ismerik fel és eldobják. Erre a dilemmára megoldást jelent, ha a -PS és -PA megadásával mind SYN-, mind ACK-szondákat küldünk.
-PU (UDP Ping)<port list>
Egy másik állomásfelfedező opció az UDP ping, amely UDP csomagot küld a megadott portokra. A legtöbb port esetében a csomag üres lesz, bár egyesek protokollspecifikus hasznos terhet használnak, amely nagyobb valószínűséggel vált ki választ.Lásd az “UDP hasznos terhek” című részt: nmap-payloads” című fejezetben található a hasznos terhek adatbázisának leírása.A csomag tartalma a --data,--data-string és --data-length opciókkal is befolyásolható.
A portok listája ugyanolyan formátumú, mint a korábban tárgyalt -PS és -PA opciók esetében. Ha nem adunk meg portot, az alapértelmezett érték 40125. Ez az alapértelmezés a fordítás idején konfigurálható a DEFAULT_UDP_PROBE_PORT_SPEC megváltoztatásával a nmap.h-ben. Alapértelmezés szerint egy nagyon szokatlan portot használunk, mivel a nyitott portokra való küldés gyakran nem kívánatos ennél a vizsgálat típusnál.
A célgépen egy zárt portba ütközve az UDP szondának egy ICMP port unreachable csomagot kell visszaküldenie. Ez azt jelzi az Nmap számára, hogy a gép működik és elérhető. Sok más típusú ICMP hiba, mint például az elérhetetlen állomás/hálózat vagy a TTL túllépése, azt jelzi, hogy az állomás leállt vagy elérhetetlen. A válasz hiánya szintén így értelmezhető. Nyitott port elérése esetén a legtöbb szolgáltatás egyszerűen figyelmen kívül hagyja az üres csomagot, és nem küld vissza semmilyen választ. Ezért van az, hogy az alapértelmezett próbaport a 40125, amely nagy valószínűséggel nincs használatban. Néhány szolgáltatás, mint például a Character Generator (chargen) protokoll, válaszol egy üres UDP csomagra, és így felfedik az Nmap számára, hogy a gép elérhető.
Az elsődleges előnye ennek a vizsgálati típusnak, hogy megkerüli a tűzfalakat és a szűrőket, amelyek csak a TCP-t szűrik. Egyszer például volt egy Linksys BEFW11S4 vezeték nélküli szélessávú routerem. Ennek az eszköznek a külső interfésze alapértelmezés szerint minden TCP-portot kiszűrt, de az UDP-szondák mégis elérhetetlen portú üzeneteket váltottak ki, és így elárulták az eszközt.
-PY (SCTP INIT Ping)<port list>
Ez az opció egy minimális INIT-chunkot tartalmazó SCTP-csomagot küld. Az alapértelmezett célport a 80-as (a fordításkor konfigurálható a DEFAULT_SCTP_PROBE_PORT_SPEC megváltoztatásával a nmap.h-ben). Alternatív portok paraméterként megadhatók. A szintaxis ugyanaz, mint a -p esetében, kivéve, hogy a S: típusú portmeghatározók nem engedélyezettek. Példák a -PY22 és a -PY22,80,179,5060. Vegye figyelembe, hogy a -PY és a portlista között nem lehet szóköz. Ha több szonda van megadva, akkor azok párhuzamosan kerülnek elküldésre.
Az INIT chunk azt sugallja a távoli rendszernek, hogy megpróbál létrehozni egy társítást. Normális esetben a célport zárva lesz, és egy ABORT chunk kerül visszaküldésre. Ha a port történetesen nyitva van, a célállomás egy INIT-ACK chunkkal válaszolva megteszi az SCTP négyirányú kézfogás második lépését. Ha az Nmap-et futtató gép rendelkezik működő SCTP stackkel, akkor a készülő kapcsolatot ABORT chunkkal válaszolva bontja le, ahelyett, hogy COOKIE-ECHO chunkot küldene, ami a négyirányú kézfogás következő lépése lenne. Az ABORT csomagot az Nmap-et futtató gép kernele küldi válaszul a váratlan INIT-ACK-re, nem maga az Nmap.
A Nmap-et nem érdekli, hogy a port nyitott vagy zárt. A korábban tárgyalt ABORT vagy INIT-ACK válasz azt jelenti az Nmap számára, hogy az állomás elérhető és reagál.
A Unix rendszereken általában csak a root kiváltságos felhasználó képes nyers SCTP csomagokat küldeni és fogadni. Az SCTP INIT Pings használata jelenleg nem privilegizált felhasználók számára nem lehetséges.
-PE;-PP;-PM(ICMP Ping típusok)
A korábban tárgyalt szokatlan TCP, UDP és SCTP állomásfelderítési típusokon kívül az Nmap képes a mindenütt jelenlévő ping program által küldött szabványos csomagok küldésére is. Az Nmap 8-as típusú ICMP (echo request) csomagot küld a cél-IP-címekre, és 0-as típusú (echo reply) választ vár vissza az elérhető hosztoktól. A hálózatkutatók sajnálatára sok hoszt és tűzfal blokkolja ezeket a csomagokat, ahelyett, hogy az RFC 1122 által előírt módon válaszolnának. Emiatt a csak ICMP-alapú vizsgálatok ritkán elég megbízhatóak az ismeretlen célpontok ellen az interneten keresztül. A belső hálózatot felügyelő rendszergazdák számára azonban praktikus és hatékony megközelítés lehet. A -PE opcióval engedélyezheti ezt az echo request viselkedést.
Míg az echo request a szabványos ICMP ping lekérdezés, az Nmap nem áll meg itt. Az ICMP-szabványok (RFC 792 és RFC 950 ) 13-as, 15-ös és 17-es kódként határozzák meg az időbélyegkérő, az információs kérő és a címmaszk kérő csomagokat is. Bár ezeknek a lekérdezéseknek a látszólagos célja az olyan információk, mint a címmaszkok és az aktuális időpontok megismerése, könnyen felhasználhatók állomásfelderítésre is. A válaszoló rendszer működik és elérhető. Az Nmap jelenleg nem implementálja az információkérő csomagokat, mivel azok nem széles körben támogatottak. Az RFC 1122 ragaszkodik ahhoz, hogy “egy állomásnak NEM KELL implementálnia ezeket az üzeneteket”. Az időbélyeg és a címmaszk lekérdezéseket a -PP, illetve a -PM opcióval lehet elküldeni. Az időbélyeg-válasz (ICMP 14-es kód) vagy a címmaszk-válasz (18-as kód) közli, hogy az állomás elérhető. Ez a két lekérdezés értékes lehet, ha a rendszergazdák kifejezetten blokkolják a visszhangkérő csomagokat, miközben elfelejtik, hogy más ICMP-lekérdezések is használhatók ugyanerre a célra.
-PO (IP protokoll ping)<protocol list>
Az újabb állomásfelderítési lehetőségek egyike az IP protokoll ping, amely IP csomagokat küld a megadott protokollszámmal az IP fejlécben. A protokolllista ugyanolyan formátumú, mint a korábban tárgyalt TCP, UDP és SCTP állomásfelderítési lehetőségek portlistái. Ha nincs protokoll megadva, az alapértelmezés szerint több IP-csomagot küld az ICMP (1. protokoll), az IGMP (2. protokoll) és az IP-in-IP (4. protokoll) számára. Az alapértelmezett protokollok a fordítás idején konfigurálhatók a DEFAULT_PROTO_PROBE_PORT_SPEC módosításával a nmap.h-ben. Megjegyzendő, hogy az ICMP, IGMP, TCP (6. protokoll), UDP (17. protokoll) és SCTP (132. protokoll) esetében a csomagok a megfelelő protokollfejlécekkel kerülnek elküldésre, míg a többi protokoll az IP fejlécen túl további adatok nélkül kerül elküldésre (kivéve, ha a --data, --data-string vagy --data-length opciók valamelyike van megadva).
Ez az állomásfelderítési módszer vagy a szondával azonos protokollt használó válaszokat, vagy ICMP protokoll elérhetetlen üzeneteket keres, amelyek azt jelzik, hogy az adott protokollt a célállomás nem támogatja. Mindkét típusú válasz azt jelzi, hogy a célállomás életben van.
--disable-arp-ping(Nincs ARP vagy ND ping)
Az Nmap általában ARP vagy IPv6 Neighbor Discovery (ND) felderítést végez a helyileg csatlakoztatott ethernet állomáson, még akkor is, ha más állomásfelfedezési opciókat, például -Pn vagy -PE használ. Ennek az implicit viselkedésnek a letiltásához használja a --disable-arp-ping opciót.
Az alapértelmezett viselkedés általában gyorsabb, de ez az opció hasznos a proxy ARP-t használó hálózatokban, ahol az útválasztó spekulatív módon válaszol minden ARP-kérésre, így minden célpont az ARP-szkennelés szerint elérhetőnek tűnik.
--discovery-ignore-rst
Egyes esetekben a tűzfalak meghamisíthatják a TCP reset (RST) válaszokat a nem foglalt vagy tiltott címekre irányuló próbákra adott válaszokat. Mivel az Nmap általában az RST-válaszokat bizonyítéknak tekinti arra, hogy a célpont működik, ez olyan célpontok pazarlásához vezethet, amelyek nem is léteznek. A --discovery-ignore-rst használata megakadályozza, hogy az Nmap figyelembe vegye ezeket a válaszokat az állomás felderítése során. Lehet, hogy további állomásfelfedezési opciókat kell választania, hogy ebben az esetben ne hagyjon ki célpontokat.
--traceroute(Trace path to host)
A letapogatás utáni nyomkövetés a letapogatás eredményeinek információi alapján történik, hogy meghatározza a célpontot leginkább elérő portot és protokollt. Ez a funkció a connect scan (-sT) és az idle scan (-sI) kivételével minden vizsgálati típusnál működik. Minden nyomkövetés az Nmap dinamikus időzítési modelljét használja, és párhuzamosan történik.
A Traceroute úgy működik, hogy alacsony TTL (time-to-live) értékű csomagokat küld, hogy megpróbáljon ICMP Time Exceeded üzeneteket kicsalni a scanner és a célállomás közötti köztes ugrásokból. A szabványos traceroute implementációk 1-es TTL-lel kezdődnek, és a TTL-t addig növelik, amíg a célállomás el nem éri a célállomás. Az Nmap traceroute magas TTL-lel indul, majd addig csökkenti a TTL-t, amíg el nem éri a nullát. A visszafelé történő végrehajtás lehetővé teszi az Nmap számára, hogy okos gyorsítótárazási algoritmusokat alkalmazzon a több állomáson történő nyomkövetés felgyorsítására. Az Nmap átlagosan 5-10 csomaggal kevesebbet küld állomásonként, a hálózati körülményektől függően. Ha egyetlen alhálózatot vizsgálunk (pl. 192.168.0.0/24), akkor az Nmap-nak a legtöbb állomásnak csak két csomagot kell küldenie.
-n(No DNS resolution)
Megadja az Nmap-nak, hogy soha ne végezzen fordított DNS-feloldást a talált aktív IP-címeken. Mivel a DNS még az Nmap beépített párhuzamos csonkfeloldójával is lassú lehet, ez az opció csökkentheti a keresési időt.
-R(DNS feloldás minden célpontra)
Megmondja az Nmap-nak, hogy mindig végezzen fordított DNS feloldást a cél IP-címeken. Normális esetben a fordított DNS-feloldást csak a reagáló (online) hosztok ellen végzi el.
--resolve-all(Minden feloldott cím átvizsgálása)
Ha egy hosztnév célpontja egynél több címre oldódik fel, akkor az összeset vizsgálja át. Az alapértelmezett viselkedés szerint csak az első feloldott címet vizsgálja. Ettől függetlenül csak a megfelelő címcsaládba tartozó címek kerülnek beolvasásra: IPv4 alapértelmezés szerint, IPv6 -6 esetén.
--system-dns(Rendszeres DNS-feloldó használata)
Az Nmap alapértelmezés szerint az IP-címek fordított feloldását úgy végzi, hogy közvetlenül az állomáson konfigurált névkiszolgálóknak küld lekérdezéseket, majd várja a válaszokat. A teljesítmény javítása érdekében sok (gyakran több tucat) lekérdezés párhuzamosan történik. Ha ezt az opciót adja meg, akkor ehelyett a rendszerfeloldót használja (egyszerre egy IP-t a getnameinfo híváson keresztül). Ez lassabb és ritkán hasznos, hacsak nem talál hibát az Nmap párhuzamos reszolverében (kérjük, értesítsen minket, ha talál). A rendszerfeloldót mindig a forward lookupokhoz használjuk (IP-cím megszerzése egy hostnévből).
--dns-servers (Fordított DNS-lekérdezésekhez használandó szerverek)<server1>]
Az Nmap alapértelmezés szerint a DNS-kiszolgálókat (az rDNS feloldáshoz) a resolv.conf fájlból (Unix) vagy a Registryből (Win32) határozza meg. Alternatívaként használhatja ezt az opciót alternatív kiszolgálók megadására. Ez az opció nem kerül figyelembe vételre, ha a --system-dns opciót használja. Több DNS-kiszolgáló használata gyakran gyorsabb, különösen akkor, ha a cél-IP-térhez tekintélyes kiszolgálókat választ. Ez az opció javíthatja az észrevétlenséget is, mivel a kérések az internet szinte bármelyik rekurzív DNS-kiszolgálójáról visszapattannak.
Ez az opció a magánhálózatok vizsgálatakor is hasznos lehet. Néha csak néhány névkiszolgáló szolgáltat megfelelő rDNS-információt, és lehet, hogy nem is tudja, hol vannak. Átvizsgálhatja a hálózatot az 53-as portra (esetleg verzióérzékeléssel), majd megpróbálkozhat az Nmap-lista átvizsgálásával (-sL), egyesével megadva az egyes névkiszolgálókat a --dns-servers-val, amíg nem talál egyet, amelyik működik.
Ez az opció esetleg nem teljesül, ha a DNS-válasz meghaladja az UDP-csomag méretét. Ilyen helyzetben a DNS-feloldónk mindent megtesz, hogy a csonka csomagból választ kapjon, és ha ez nem sikerül, akkor visszalép a rendszerfeloldó használatára. A CNAME aliasokat tartalmazó válaszok is a rendszerfeloldóhoz térnek vissza.