A lista letapogatás az állomás felderítés legprimitívebb módja. Egyszerűen kilistázza a megadott hálózat(ok)on található állomásokat anélkül, hogy bármilyen adatcsomagot küldene. Alaphelyzeben az Nmap még ekkor is elvégez egy fordított DNS lekérdezést azért, hogy megkapja az állomások neveit. Gyakran meglepően sok információval szolgálhat egy egyszerű állomásnév is. Például az fw.chi egy vállalat Chicagoban lévő tűzfalának a neve. A lista végén az Nmap megadja az IP címek számát is. A lista letapogatással könnyen ellenőrizhető, hogy a célba vett állomásokhoz a megfeleő IP címek állnak-e rendelkezésre. Ha az állomás esetleg ismeretlen tartománynevet ad vissza, érdemes további ellenőrzést is elvégezni, nehogy véletlenül más hálózatot tapogasson le.

Mivel az alapötlet az, hogy egyszerűen nyomtassunk egy listát a célpontokról, ezért a magasabb szintű funkciók, mint például a kapuletapogatás, az operációs rendszer érzékelése vagy a visszhang letapogatás nem kombinálható ezzel a funkcióval. Ha szeretné letiltani a visszhang letapogatást mialatt magasabb szintű funkciókat használ, olvassa el a -PN paraméter leírását.

Ezzel a paraméterrel arra utasítja az Nmap programot, hogy kizárólag visszhang letapogatást (állomás felderítést) hajtson végre, majd nyomtasson egy listát azokról az állomásokról, amelyek válaszoltak a letapogatásra. Semmilyen további teszt (mint például kapuletapogatás, vagy operációs rendszer felderítése) nem kerül végrehajtásra. Ez a lépés némileg tolakodóbb, mint a lista letapogatás és gyakran ugyanolyan céllal használják. Ez lehetőséget biztosít a célhálózat finom felderítésére anélkül, hogy túlságosan felkeltené a figyelmet. Egy támadó számára sokkal hasznosabb azt tudni, hogy hány élő állomás van a célhálózatban, mint a lista letapogatás által visszaadott állomásneveknevek és IP címek halmaza.

A rendszergazdák szintén hasznosnak fogják találni ezt a paramétert. Egyszerűen felderíthető vele a hálózatban elérhető állomások száma vagy ellenőrizhető egy kiszolgáló elérhetősége. Gyakran nevezik ezt a funkciót visszhang pásztázásnak is és sokkal megbízhatóbb, mint az üzenetszórási címre küldött viszhang kérés, mivel sok állomás nem válaszol az üzenetszórási címre küldött kérésre.

Az -sP paraméter alapesetben egy ICMP visszhang kérést küld, valamint egy TCP csomagot a 80-as kapura. Ha a parancsot nem rendszergazdaként adjuk ki, csak egy SYN csomag kerül elküldésre (a connect() rendszerhívásonkeresztül) a célállomás 80-as kapujára. Ha rendszergazdaként a helyi hálózaton próbál állomásokat letapogatni, akkor egy ARP kérés (-PR) kerül elküldésres, hacsak nem adja meg a --send-ip paramétert. A nagyobb rugalmasság érdekében az -sP paraméter kombinálható bármelyik felderítési próbával (-P* paraméterek, kivéve a -PN paramétert). Ha ezeket a próbatípusokat használja, akkor az alapértelemzett próbák (ACK csomag és visszhang kérés) kimaradnak. Ha az Nmap programot futtató gép és a célállomás között szigorú szabályokkal működő tűzfal találhat, akkor ezeknek a fejlett technikáknak az alkalmazása mindenképpen ajánlott. Máskülönben kimaradhatnak állomások, ha a tűzfal eldobálja a próbákat, vagy a célállomások válaszait.

Ezzel a paraméterrel az Nmap állomás felderítési lépése teljesen elhagyható. Normál esetben az Nmap ezt a lépést használja az aktív állomások meghatározására a további letapogatás előtt. Alapesetben az Nmap az erőteljesebb próbákat (kapuk letapogatása, változat érzékelés, operációs rebdszer érzékelése) csak azokon az állomásokon hajtja végre, amelyeket aktívnak érzékelt. Ha a -PN paraméterrel letiltja a felderítési funkciót, az Nmap valamennyi megadott célpont IP címén végrehajtja a kért letapogatási műveleteket. Tehát ha egy B osztályú címtartományt adott meg célpontként (/16), akkor mind a 65,536 IP cím letapogatásra kerül. Csakúgy, mint a lista letapogatásnál, a megfelelő állomás felderítési lépés kimarad, viszont a célpontok listájának kinyomtatása és a kilépés helyett az Nmap folytatja a kért műveletek végrehajtását és feltételezi, hogy valamennyi célpont aktív. A helyi ethernet hálózaton lévő gépeken az ARP letapogatás ekkor is végrehajtásra kerül (hacsak a --send-ip paramétert meg nem adja), mivel a további letapogatásokhoz az Nmap-nek szüksége van a MAC címre. Ennek a paraméternek a régi meghatározása a P0 volt, de átnevezésre került, hogy megakadályozható legyen a protokoll visszhang PO paraméterével való keveredése.

Ez a paraméter egy beállított SYN zászlójú üres TCP csomagot küld a célpont felé. Az alapértelmezett célkapu a 80-as (ez fordítási időben megváltoztatható az nmap.h) fájlban a DEFAULT_TCP_PROBE_PORT_SPEC paraméterrel. Futásidőben is megadható más célkapu paraméterként. A szintaxis ugyanaz, mint a -p paraméternél, kivéve hogy a kaputípus megadása - mint például a T: - nem engedélyezett. Néhány példa: -PS22 és -PS22-25,80,113,1050,35000. Figyeljen arra, hogy a -PS paraméter és a kapulista között nem lehet szóköz. Ha több kaput is megadott, a próbák párhuzamosan kerülnek végrehajtásra.

A beállított SYN zászló azt sugallja a célpontnak, hogy Ön kapcsolatot kíván kezdeményezni. Normál helyzetben a célkapu zárva lesz és a célpont egy RST (reset) csomagot küld vissza. Ha a kapu nyitva van, a célpont végrehajtja a 3 lépéses kapcsolatfelépítés második lépését és egy SYN/ACK TCP csomagot küld vissza. Ezután az Nmap-et futtató állomás egy RST csomag küldésével lebontja az éppen felépülő kapcsolatot ahelyett, hogy egy ACK csomag küldésével teljesen felépítené a kapcsolatot. Az RST csomagot nem az Nmap küldi, hanem a programot futtató állomás rendszermagja, válaszul a nem várt SYN/ACK csomagra.

Az Nmap nem foglalkozik azzal, hogy a kapu nyitott vagy zárt. Mind az RST mind a SYN/ACK válasz azt jelzi, hogy a célállomás elérhető és válaszol.

Unix rendszereken kizárólag a kiemelt root felhasználó képes nyers TCP csomagok küldésre és fogadására. Normál felhasználók esetén egy kerülő megoldást alkalmazunk a connect() rendszerhívás használatakor, minden egyes kapu esetén. Ennek során egy kapcsolat felépítését kezdeményező SYN csomagot küldünk a célpont felé. Ha a connect() sikeresen vagy az ECONNREFUSED hibával tér vissza, akkor az alsóbb TCP verem vagy SYN/ACK vagy RST csomagot fogadott. Ilyenkor a célállomás elérhetőnek lesz jelölve. Ha a kapcsolódási kísérlet az időzítés lejártáig függőben marad, a célállomás elérhetetlenként lesz jelölve. Ugyanez a kerülőút kerül alkalmazásra az IPv6 kapcsolatok esetén is, mivel jelenleg az Nmap nem rendelkezik nyers IPv6 csomagok összeállításának képességével.

A TCP ACK visszhang próba meglehetősen hasonlít az előzőekben tárgyalt SYN visszhang próbához. A különbség annyi, hogy a SYN zászló helyett az ACK zászló a beállított állapotú. Az ACK csomag jelzi, hogy a csomagot küldő fél készen áll az adatok fogadására a felépített kapcsolaton keresztül. Azonban jelen esetben nincs ilyen létező kapcsolat. A célállomások ilyenkor szinte minden esetben egy RST csomagot küldenek, felfedvén ezzel a jelenlétüket.

A -PA paraméter a SYN próbához hasonlóan ugyanazt az alapértelmezett kaput használja és ugyanolyan formátumban adható át neki más célkapuk listája is. Ha nem kiemelt felhasználó próbálja használni ezt a funkciót, vagy a célpont IPv6 formátumú, akkor az előzőekben már tárgyalt kerülőút kerül alkalmazásra. Azonban jelen esetben ez nem tökéletes, mivel a connect() valójában SYN csomagot küld, nem ACK csomagot.

Azért található meg mind a SYN, mind az ACK próba, hogy a lehető legjobban megnöveljük az esélyét a tűzfalak megkerülésének. A legtöbb rendszergazda úgy állítja be az útválasztóit és más egyszerű tűzfalait, hogy a nyilvános szolgáltatások felé tartó forgalom (pl. céges web- vagy levelező kiszolgáló) kivételével minden bejövő SYN csomagot dobjon el. Ez megakadályozza a bejövő forgalmat a céges hálózatba, viszont a felhasználók részére zavartalan kimenő forgalmat biztosít az Internet felé. Ez a nem-állapottartó megközelítés kevesebb erőforrást igényel a tűzfalakon/útválasztókon és széles körben támogatott. A Linux Netfilter/iptables tűzfalprogramja a --syn paraméteren keresztül valósítja meg ezt a nem-állapottartó működést. Az ilyen állapot nélküli tűzfalszabályok a SYN visszhang próbákat (-PS) nagy valószínűséggel elutasítják, ha azok zárt kaput céloznak. Ilyenkor az ACK próba sikeresen vágja át magát ezeken a szabályokon.

Más általánosan használt tűzfalak állapottartó szabályok használatával utasítják el a nem várt csomagokat. Kezdetben ez a jellemző csak a felső kategóriás tűzfalakban volt megtalálható, de az utóbbi években egyre inkább elterjed az alsóbb kategóriákban is. A Linux Netfilter/iptables rendszere a --state paraméteren keresztül valósítja ezt meg, melyben a csomagokat a kapcsolat állapota alapján kategorizálja. Az ilyen rendszerek ellen a SYN próbák hatásosabbak, mivel a nem várt ACK csomagokat hamisnak tekintik és eldobják. Ezt a zavart úgy lehet elhárítani, ha mind a SYN, mind ACK próbát végrehajtjuk a -PS és -PA paraméterek megadásával.

Egy újabb állomás felderítési módszer az UDP visszhang próba, mely során egy üres (hacsak nem adja meg a --data-length paramétert) UDP csomagot küldünk a megadott kapu felé. A kapulista formátuma megegyezik az előző pontokban tárgyalt -PS és -PA paraméterekével. Ha nem adunk meg kaput, akkor alapértelmezettként a 31338-as kapu kerül használatra. Ez fordítási időben megváltoztatható az nmap.h állomány DEFAULT_UDP_PROBE_PORT_SPEC paraméterén keresztül. Ennél a letapogatásnál nem kifejezetten jó, ha egy nyitott kapuval próbálkozunk, ezért választunk egy magas számú, nagy valószínűséggel nem használt kaput.

Ha a célponton egy zárt kaput tapogatunk le az UDP próbával, a célállomásból kicsalhatunk egy kapu nem elérhető (port unreachable) ICMP válaszcsomagot. Ez jelzi az Nmap-nek, hogy a célpont él és elérhető. Bármilyen más ICMP hibaüzenet (pl. állomás/hálózat nem elérhető, TTL élettartam lejárt) azt jelzi, hogy a célállomás nem érhető el. A válasz hiányát szintén így értelmezi a program. Ha nyitott kaput érünk el, a legtöbb szolgáltatás figyelmen kívül hagyja az üres csomagot és nem küld vissza semmilyen választ. Ezért használjuk alapértelmezésként a 31338-as kaput, melyet nagy valószínűséggel nem használ semmi. Néhány szolgáltatás, mint például a chargen válaszol az üres csomagokra is, mely így szintén azt jelzi, hogy a célpont elérhető.

A legfőbb előnye ennek a letapogatásnak, hogy megkerüli azokat a szűrőket és útválasztókat, melyek kizárólag a TCP forgalmat figyelik. Például a program készítőjének volt egy Linksys BEFW11S4 vezeték nélküli útválasztója, mely a külső csatolóján az összes TCP kaput szűrte. Azonban az UDP próbák ellen védtelen volt.

Az előzőekben tárgyalt szokatlan TCP és UDP állomás felderítési típusok mellett az Nmap képes a széles körben elterjedt ping program által használt csomagok küldésére is. Az Nmap egy 8-as típusú (visszhang kérés) ICMP csomagot küld a cél IP címre és egy 0-ás típusú (visszhang válasz) csomagot vár vissza az elérhető állomásoktól. A hálózati felderítők bánatára a legtöbb állomás és tűzfal blokkolja ezeket a csomagokat ahelyett, hogy az RFC 1122 leírás szerint válaszolna rájuk. Emiatt a kizárólag ICMP alapú letapogatások ritkán adnak megbízható eredményt ismeretlen célpontok felderítésekor. Azonban belső hálózatokat felügyelő rendszergazdák számára praktikus és hasznos eszköz lehet. Használja a -PE paramétert a visszhang kérés engedélyezésére.

Noha a visszhang kérés a szabványos ICMP kérés, az Nmap ennél tovább megy. Az ICMP szabvány (RFC 792) emellett meghatároz még időbélyeg kérést (13-as kód), információ kérést (15-ös kód) és címmaszk kérést (17-es kód) is. Noha látszólag ezek a kérések arra szolgálnak, hogy információkat szerezzünk (például címmaszk vagy időbélyeg), de emellett könnyen használhatóak állomások felderítésére is. Amelyik rendszer válaszol az élő és elérhető. Az Nmap jelenleg nem támogatja az információ kérés csomagot, mivel ezt nem támogatják széles körben. Az RFC 1122 ragaszkodik ahhoz, hogy “az állomásoknak nem kellene támogatniuk ezeket az üzeneteket”. Az időbélyeg és a címmaszk kérések a -PP és a -PM paramétereken keresztül küldhetőek el. Az időbélyeg válasz (14-es ICMP kód) vagy a címmaszk válasz (18-as kód) elárulja, hogy az állomás elérhető. Ezek a kérések különösen akkor válnak értékessé, ha a rendszergazda letiltotta a visszhang kéréseket, miközben elfelejtett, hogy más ICMP kérések is használhatóak erre a célra.

Egy másik állomás federítési módszer az IPProto visszhang, amely az IP fejléc protokoll mezőjében megadott típusú IP csomagokat küld el. A protokoll lista ugyanolyan formátumú, mint az előzőekben tárgyal TCP és UDP felderítési paramétereknél használ kapulista. Ha nincs megadva protokoll, akkor alapértelmezettként ICMP (1-es protokoll), IGMP (2-es protokoll és IP-in-IP (4-es protokoll) csomagok lesznek elküldve. Az alapértelmezett protokollok fordítási időben adhatók meg az nmap.h állomány DEFAULT_PROTO_PROBE_PORT_SPEC változójában. Figyeljen arra, hogy az ICMP, IGMP, TCP (6-os protokoll és UDP (17-es protokoll) protokollok esetén a csomagok további fejlécekkel kerülnek elküldésre, míg más protokolloknál az IP fejléc mögött más adat nem kerül elküldésre (kivéve, ha a --data-length paramétert is megadta).

Ez a felderítési metódus kétféle választ vár. Vagy az elküldött protokollnak megfelelő válasz érkezik, vagy egy 'Protocol Unreachable' ICMP üzenet, mely szerint az állomás nem támogatja az adott protokollt (mellyel el is árulta a létezését).

Az Nmap egyik leggyakoribb használata a helyi ethernet hálózat letapogatása. A legtöbb helyi hálózaton, különösen melyek az áldott RFC1918 alapú privát címtartományt használják, az IP címek legnagyobb része általában nincs használatban. Amikor az Nmap nyers IP csomagot próbál küldeni (például egy ICMP visszhang kérést), az operációs rendszernek meg kell határoznia a célpont IP címe alapján a hardvercímet (ARP) azért, hogy az ethernet keretet megfelelően tudja címezni. Ez gyakran lassú és problémás, mivel az operációs rendszereket nem úgy tervezik, hogy rövid ídő alatt több millió ARP kérést küldjenek el elérhetetlen állomások felé.

Az ARP letapogatásnál az ARP kéréseket az Nmap program kifinomult algoritmusára bízzuk. Ha itt válasz érkezik, akkor már nem szükséges az IP alapú visszhang kérésekkel foglalkozni, mivel a célpont elérhető. Ezért az ARP letapogatás sokkal gyorsabb és megbízhatóbb, mint az IP alapú letapogatások. Ezért ezt a letapogatást az Nmap alaphelyzetben elvégzi, ha úgy érzékeli, hogy a célpont a helyi ethernet hálózaton található. A helyi hálózaton az Nmap még akkor is az ARP letapogatást fogja végrehajtani, ha más visszhang alapú letapogatást adtunk meg (mint például a -PE vagy a -PS). Ha egyáltalán nem kívánja használni az ARP letapogatást, adja meg a --send-ip paramétert.

Az útvonal nyomkövetése a letapogatás után történik meg, a letapogatás eredményének figyelembe vételével. A nyomkövetéshez a célponton elérhető kapuk és protokollok közül azok lesznek felhasználva, melyekkel a célpont nagy valószínűséggel elérhető. A nyomkövetés a kapcsolódási letapogatás (connect (-sT)) és az üresjárati letapogatás (idle (-sI)) kivételével minden letapogatási típussal működőképes. Minden nyomkövetés az Nmap dinamikus időzítési modelljét használja és párhuzamosan kérül végrehajtásra.

A nyomkövetéskor a csomagokat alacsony élettartam (time-to-live (TTL)) értékkel küldjük el, hogy az útvonalon lévő közbenső állomásokból az Időzítés letelt (Time Exceeded) ICMP hibaüzenetet tudjunk kicsalni. Alapesetben a nyomkövetésnél TTL=1 értékkel kezdünk és addig növeljük a TTL értékét, amíg el nem érjük a célállomást. Az Nmap nyomkövetése magas TTL értékkel indít és egészen nuuláig csökken. A visszafelé történő kereséssel és egy ügyes gyorstároló algoritmussal az Nmap felgyorsítja a több állomáson keresztül végzett nyomkövetést. Átlagban az Nmap 5-10 csomaggal kevesebbet küld el állomásonként, de ez nagyban függ a hálózat állapotától. Ha csak egy alhálózat letapogatása történik (pl. 192.168.0.0/24), az Nmap a legtöbb állomáshoz valószínűleg csak egy csomagot küld.

Megjeleníti, hogy az egyes állomások és kapuk miért lettek a megadott állapotúnak jelölve. Ez a paraméter megjeleníti annak a csomagnak a típusát, amely az állomás vagy kapu állapotát meghatározta. Például egy RST csomag egy zárt kapuról vagy egy visszhang válasz egy működő állomásról. Az Nmap által szolgáltatott információk a letapogatás vagy a visszhang típusától függenek. A SYN letapogatás és a SYN visszhang (-sS és -PT) eredményei például nagyon részletesek, míg a TCP kapcsolódási letapogatás és visszhang (-sT) eredményei korlátozottak a connect rendszerhívás megvalósítása miatt. Ezt a jellemzőt a hibakeresési paraméter (-d) automatikusan engedélyezi. Az eredmények egy XML fájlban tárolódnak akkor is, ha ezt a paramétert nem adja meg.

Utasítja az Nmap programot, hogy soha ne végezzen fordított DNS feloldást az aktívnak talált IP címeken. Mivel a DNS még az Nmap beépített párhuzamos DNS feloldójával is lassú lehet, ennek a paraméternek a megadása felgyorsíthatja a letapogatást.

Utasítja az Nmap programot, hogy mindig végezzen fordított DNS feloldást a célpontok IP címeire. Normál helyzetben csak az elérhető (online) állomásokon történik fordított DNS feloldás.

Alaphelyzetben az Nmap a névfeloldást maga végzi úgy, hogy a rendszeren beállított névkiszolgáló felé közvetlenül küldi el a kéréseket és vár a válaszra. A teljesítmény javítása érdekében több kérés kerül elküldésre párhuzamosan (gyakran többszáz). A rendszer DNS feloldójának használatához adja meg ezt a paramétert (egyszerre egy IP a getnameinfo() rendszerhíváson keresztül). Ez sokkal lassabb és ritkán hasznos, kivéve ha valamilyen hibát talál az Nmap párhuzamos feloldójában (kérjük jelezze, ha így van). Az IPv6 letapogatásokhoz mindig a rendszer feloldóját használja a program.

Alaphelyzetben az Nmap a DNS kiszolgálók adatait a resolv.conf fájlból (UNIX) vagy a regisztrációs adatbázisból (Windows) próbálja meg kinyerni. Ezzel a paraméterrel Ön más kiszolgálókat is megadhat. A program nem veszi figyelembe ezt a paramétert, ha a --system-dns paramétert használja, vagy IPv6 letapogatást hajt végre. Több DNS kiszolgáló használat gyakran felgyorsítja a feloldást, különösen ha a célpont IP tartományának meghatalmazott kiszolgálóját használja. Ezzel a paraméterrel fokozható a rejtőzködés is, mivel a kérések tküldhetők több rekurzív DNS kiszolgálón is.

Szintén hasznos lehet ez a paraméter a magánhálózatok letapogatásakor. Néha csak néhány névkiszolgáló ad vissza megfelelő fordított DNS információkat és nem mindig tudhatja, hogy ezek hol vannak. Letapogathatja a hálózatot az 53-as kapura keresve (esetleg változat érzékeléssel együtt), ezután kipróbálhatja a lista alapú letapogatást (-sL) egyesével megadva a névkiszolgálókat a --dns-servers paraméterben addig, amíg meg nem találja a megfelelőt.