-sL(List Scan)
Listskanning är en degenererad form av host discovery som helt enkelt listar varje värddator i det eller de angivna nätverken, utan att skicka några paket till målvärdarna. Som standard gör Nmap fortfarande reverse-DNS-upplösning på värdarna för att få reda på deras namn. Det är ofta förvånande hur mycket användbar information enkla värdnamn ger. Till exempel är fw.chi namnet på ett företags brandvägg i Chicago. Nmap rapporterar också det totala antalet IP-adresser i slutet. Listscanningen är en bra sanitetskontroll för att se till att du har korrekta IP-adresser för dina mål. Om värdarna har domännamn som du inte känner igen är det värt att undersöka ytterligare för att undvika att skanna fel företags nätverk.
Då idén är att helt enkelt skriva ut en lista över målvärdar kan alternativ för funktionalitet på högre nivå som portskanning, OS-detektering eller värdidentifiering inte kombineras med detta. Om du vill inaktivera värdupptäckt samtidigt som du fortfarande utför sådan funktionalitet på högre nivå kan du läsa om alternativet -Pn (skip host discovery).
-sn(No port scan)
Detta alternativ talar om för Nmap att inte göra någon portskanning efter värdupptäckt, utan endast skriva ut de tillgängliga värdar som svarade på värdupptäcktsonderna. Detta är ofta känt som en ”ping-sökning”, men du kan också begära att traceroute och NSE-värdskript körs. Detta är som standard ett steg mer påträngande än listskanning och kan ofta användas för samma ändamål. Det möjliggör en lätt spaning av ett målnätverk utan att dra till sig mycket uppmärksamhet. Att veta hur många värdar som är uppkopplade är mer värdefullt för angripare än den lista som list scan ger av varje enskild IP och värdnamn.
Systemadministratörer tycker ofta att det här alternativet också är värdefullt. Det kan lätt användas för att räkna tillgängliga maskiner i ett nätverk eller övervaka servertillgängligheten. Detta kallas ofta för en ping-sökning och är mer tillförlitligt än att pinga broadcast-adressen eftersom många värddatorer inte svarar på broadcast-förfrågningar.
Den standardvärdsidentifiering som görs med -sn består som standard av en ICMP ekoförfrågan, TCP SYN till port 443, TCP ACK till port 80 och en ICMP-tidsstämpelförfrågan. När det utförs av en icke privilegierad användare skickas endast SYN-paket (med hjälp av ett connect-anrop) till portarna 80 och 443 på målet. När en privilegierad användare försöker skanna mål på ett lokalt Ethernet-nätverk används ARP-förfrågningar om inte --send-ip har angetts. Alternativet -sn kan kombineras med någon av typerna av discovery probe (alternativen -P*) för större flexibilitet. Om något av dessa alternativ för sondtyp och portnummer används åsidosätts standardproberna. När strikta brandväggar finns på plats mellan källvärden som kör Nmap och målnätverket rekommenderas användning av dessa avancerade tekniker. Annars kan värdar missas när brandväggen släpper probes eller deras svar.
I tidigare versioner av Nmap var -sn känt som -sP.
-Pn(No ping)
Detta alternativ hoppar över steget för att upptäcka värdar helt och hållet. Normalt använder Nmap detta steg för att bestämma aktiva maskiner för tyngre skanning och för att mäta nätverkets hastighet. Som standard utför Nmap endast tunga sökningar, t.ex. portskanning, versionsupptäckt eller OS-upptäckt, mot värddatorer som är uppkopplade. Om du inaktiverar värdidentifiering med -Pn får Nmap att försöka utföra de begärda skanningsfunktionerna mot varje angiven mål-IP-adress. Så om ett nätverk i storlek /16 anges på kommandoraden skannas alla 65 536 IP-adresser. Korrekt värdupptäckt hoppas över som vid listskanning, men i stället för att stoppa och skriva ut mållistan fortsätter Nmap att utföra begärda funktioner som om varje mål-IP är aktiv. Standardtidsparametrar används, vilket kan resultera i långsammare skanningar. Om du vill hoppa över värdupptäckt och portskanning, samtidigt som NSE kan köras, använder du de två alternativen -Pn -sn tillsammans.
För maskiner i ett lokalt Ethernet-nätverk kommer ARP-skanning fortfarande att utföras (om inte --disable-arp-ping eller --send-ip har angetts) eftersom Nmap behöver MAC-adresser för att kunna skanna målvärdarna ytterligare. I tidigare versioner av Nmap var -Pn -P0 och -PN.
-PS (TCP SYN Ping)<port list>
Detta alternativ skickar ett tomt TCP-paket med SYN-flaggan satt. Standardmålporten är 80 (kan konfigureras vid kompilering genom att ändra DEFAULT_TCP_PROBE_PORT_SPEC i nmap.h). Alternativa portar kan anges som en parameter. Syntaxen är densamma som för -p förutom att porttypspecifikatorer som T: inte är tillåtna. Exempel är -PS22 och -PS22-25,80,113,1050,35000. Observera att det inte får finnas något mellanslag mellan -PS och portlistan. Om flera probes anges skickas de parallellt.
Syn-flaggan antyder för fjärrsystemet att du försöker upprätta en anslutning. Normalt stängs målporten och ett RST-paket (reset) skickas tillbaka. Om porten råkar vara öppen kommer målet att ta det andra steget i en TCP-trevägshandskakning genom att svara med ett SYN/ACK TCP-paket. Maskinen som kör Nmap bryter då den begynnande anslutningen genom att svara med ett RST-paket i stället för att skicka ett ACK-paket som skulle slutföra trevägshandskakningen och upprätta en fullständig anslutning. RST-paketet skickas av kärnan på den maskin som kör Nmap som svar på den oväntade SYN/ACK, inte av Nmap själv.
Nmap bryr sig inte om huruvida porten är öppen eller stängd. Antingen RST- eller SYN/ACK-svaret som diskuterats tidigare talar om för Nmap att värddatorn är tillgänglig och reagerar.
På Unix-boxar är det i allmänhet bara den privilegierade användaren root som kan skicka och ta emot råa TCP-paket. För icke-priviligierade användare används automatiskt en lösning som innebär att systemanropet connect initieras mot varje målport. Detta leder till att ett SYN-paket skickas till målvärden i ett försök att upprätta en anslutning. Om connect returnerar med en snabb framgång eller ett ECONNREFUSED-fel måste den underliggande TCP-stacken ha tagit emot en SYN/ACK eller RST och värddatorn är markerad som tillgänglig. Om anslutningsförsöket inte genomförs förrän en tidsgräns har uppnåtts markeras värddatorn som nere.
-PA (TCP ACK Ping)<port list>
TCP ACK ping är ganska lik den nyss diskuterade SYN ping. Skillnaden är, som du säkert kan gissa, att TCP ACK-flaggan sätts i stället för SYN-flaggan. Ett sådant ACK-paket påstås bekräfta data över en etablerad TCP-anslutning, men det finns ingen sådan anslutning. Så fjärrvärdar bör alltid svara med ett RST-paket och avslöja sin existens i processen.
Objektet -PA använder samma standardport som SYN-sonden (80) och kan också ta emot en lista över destinationsportar i samma format. Om en icke-priviligierad användare försöker detta används connectlösningen som diskuterats tidigare. Denna lösning är ofullständig eftersom connect faktiskt skickar ett SYN-paket snarare än ett ACK.
Anledningen till att man erbjuder både SYN- och ACK-pingprober är att maximera chanserna att kringgå brandväggar. Många administratörer konfigurerar routrar och andra enkla brandväggar så att de blockerar inkommande SYN-paket utom de som är avsedda för offentliga tjänster som företagets webbplats eller e-postserver. Detta förhindrar andra inkommande anslutningar till organisationen, samtidigt som användarna kan göra obehindrade utgående anslutningar till Internet. Detta icke-stateful tillvägagångssätt tar få resurser i anspråk på brandväggen/routern och stöds i stor utsträckning av hårdvaru- och mjukvarufilter. Brandväggsprogrammet Linux Netfilter/iptables erbjuder bekvämlighetsalternativet --syn för att implementera detta statslösa tillvägagångssätt. När statslösa brandväggsregler av det här slaget finns på plats kommer SYN ping-probes (-PS) sannolikt att blockeras när de skickas till stängda målportar. I sådana fall lyser ACK-proben upp eftersom den skär rakt igenom dessa regler.
En annan vanlig typ av brandvägg använder stateful-regler som släpper oväntade paket. Den här funktionen fanns till en början mest på avancerade brandväggar, även om den har blivit mycket vanligare under årens lopp. Linux Netfilter/iptables-systemet stöder detta genom alternativet --state, som kategoriserar paket baserat på anslutningstillstånd. En SYN-prov är mer sannolikt att fungera mot ett sådant system, eftersom oväntade ACK-paket i allmänhet känns igen som falska och tappas bort. En lösning på detta dilemma är att skicka både SYN- och ACK-probes genom att ange -PS och -PA.
-PU (UDP Ping)<port list>
Ett annat alternativ för värdupptäckt är UDP ping, som skickar ett UDP-paket till de angivna portarna. För de flesta portar kommer paketet att vara tomt, även om vissa använder en protokollspecifik nyttolast som har större sannolikhet att framkalla ett svar, se avsnittet ”UDP-nyttolaster”: nmap-payloads” för en beskrivning av databasen med nyttolaster.Paketinnehållet kan också påverkas med alternativen --data,--data-string och --data-length.
Portlistan har samma format som med de tidigare diskuterade alternativen -PS och -PA. Om inga portar anges är standardvärdet 40125. Detta standardvärde kan konfigureras vid kompilering genom att ändra DEFAULT_UDP_PROBE_PORT_SPEC i nmap.h. En mycket ovanlig port används som standard eftersom det ofta är oönskat att skicka till öppna portar för just den här skanningstypen.
När UDP-sonden träffar en stängd port på målmaskinen bör den framkalla ett ICMP-port unreachable-paket i retur. Detta betyder för Nmap att maskinen är uppkopplad och tillgänglig. Många andra typer av ICMP-fel, t.ex. host/network unreachables eller TTL exceeded, indikerar att värddatorn är nere eller inte går att nå. Bristande svar tolkas också på detta sätt. Om en öppen port nås ignorerar de flesta tjänster helt enkelt det tomma paketet och skickar inte tillbaka något svar. Detta är anledningen till att standardporten för sondering är 40125, som med stor sannolikhet inte används. Några få tjänster, t.ex. protokollet Character Generator (chargen), svarar på ett tomt UDP-paket och avslöjar därmed för Nmap att maskinen är tillgänglig.
Den främsta fördelen med den här skanningstypen är att den går förbi brandväggar och filter som endast granskar TCP. Jag ägde till exempel en gång en Linksys BEFW11S4 trådlös bredbandsrouter. Det externa gränssnittet för den här enheten filtrerade alla TCP-portar som standard, men UDP-sonderingar skulle fortfarande framkalla port unreachable-meddelanden och därmed avslöja enheten.
-PY (SCTP INIT Ping)<port list>
Detta alternativ skickar ett SCTP-paket som innehåller en minimal INIT chunk. Standardmålporten är 80 (konfigurerbar vid kompileringstid genom att ändra DEFAULT_SCTP_PROBE_PORT_SPEC i nmap.h). Alternativa portar kan anges som en parameter. Syntaxen är densamma som för -p förutom att porttypspecifikatorer som S: inte är tillåtna. Exempel är -PY22 och -PY22,80,179,5060. Observera att det inte får finnas något mellanslag mellan -PY och portlistan. Om flera probes anges kommer de att skickas parallellt.
INIT-klyftan antyder för fjärrsystemet att du försöker upprätta en association. Normalt stängs målporten och en ABORT chunk skickas tillbaka. Om porten råkar vara öppen kommer målet att ta det andra steget i en SCTP-fyravägshandskakning genom att svara med en INIT-ACK chunk. Om maskinen som kör Nmap har en fungerande SCTP-stack bryter den ned den begynnande associeringen genom att svara med en ABORT-chunk i stället för att skicka en COOKIE-ECHO-chunk som skulle vara nästa steg i fyrvägshandskakningen. ABORT-paketet skickas av kärnan på den maskin som kör Nmap som svar på det oväntade INIT-ACK, inte av Nmap själv.
Nmap bryr sig inte om huruvida porten är öppen eller stängd. Antingen ABORT- eller INIT-ACK-svaret som diskuterats tidigare talar om för Nmap att värddatorn är tillgänglig och reagerar.
På Unix-boxar är det i allmänhet bara den privilegierade användaren root som kan skicka och ta emot råa SCTP-paket. Att använda SCTP INIT Pings är för närvarande inte möjligt för icke-priviligierade användare.
-PE;-PP;-PM(ICMP Ping-typer)
Förutom de ovanliga TCP-, UDP- och SCTP-värden som diskuterats tidigare kan Nmap skicka de standardpaket som skickas av det allestädes närvarande ping-programmet. Nmap skickar ett ICMP-paket av typ 8 (echo request) till målets IP-adresser och förväntar sig en typ 0 (echo reply) i retur från tillgängliga värdar. Tyvärr för nätverksutforskare blockerar nu många värdar och brandväggar dessa paket i stället för att svara som krävs enligt RFC 1122. Av denna anledning är ICMP-undersökningar sällan tillräckligt tillförlitliga mot okända mål på Internet. Men för systemadministratörer som övervakar ett internt nätverk kan de vara ett praktiskt och effektivt tillvägagångssätt. Använd alternativet -PE för att aktivera det här beteendet för ekoförfrågan.
Men även om ekoförfrågan är standardförfrågan för ICMP-ping slutar Nmap inte där. ICMP-standarderna (RFC 792 och RFC 950 ) anger också tidsstämpelförfrågan, informationsförfrågan och paket för adressmaskförfrågan som koder 13, 15 respektive 17. Även om det uppenbara syftet med dessa förfrågningar är att få information om t.ex. adressmasker och aktuella tider, kan de lätt användas för att hitta värdar. Ett system som svarar är igång och tillgängligt. Nmap implementerar för närvarande inte paket med informationsförfrågningar, eftersom de inte har brett stöd. RFC 1122 insisterar på att ”en värd bör inte implementera dessa meddelanden”. Förfrågningar om tidsstämpel och adressmask kan skickas med alternativen -PP respektive -PM. Ett svar på tidsstämpel (ICMP-kod 14) eller adressmasksvar (kod 18) avslöjar att värden är tillgänglig. Dessa två förfrågningar kan vara värdefulla när administratörer specifikt blockerar echo request-paket och samtidigt glömmer att andra ICMP-förfrågningar kan användas för samma ändamål.
-PO (IP Protocol Ping)<protocol list>
Ett av de nyare alternativen för värdupptäckt är IP-protokollet ping, som skickar IP-paket med det specificerade protokollnumret angivet i IP-huvudet. Protokolllistan har samma format som portlistorna i de tidigare diskuterade TCP-, UDP- och SCTP-alternativen för värdidentifiering. Om inga protokoll anges skickas som standard flera IP-paket för ICMP (protokoll 1), IGMP (protokoll 2) och IP-in-IP (protokoll 4). Standardprotokollen kan konfigureras vid kompilering genom att ändra DEFAULT_PROTO_PROBE_PORT_SPEC i nmap.h. Observera att för ICMP, IGMP, TCP (protokoll 6), UDP (protokoll 17) och SCTP (protokoll 132) skickas paketen med de korrekta protokollhuvudena medan andra protokoll skickas utan ytterligare data utöver IP-huvudet (såvida inte något av alternativen --data, --data-string eller --data-length är specificerat).
Denna metod för värdupptäckt letar antingen efter svar som använder samma protokoll som en sond, eller efter ICMP-protokollmeddelanden som är omöjliga att nå och som innebär att det givna protokollet inte stöds på målvärden. Båda typerna av svar innebär att målvärden är levande.
--disable-arp-ping(Ingen ARP- eller ND-ping)
Nmap gör normalt ARP- eller IPv6 Neighbor Discovery (ND)-upptäckt av lokalt anslutna ethernetvärdar, även om andra värdupptäckningsalternativ som -Pn eller -PE används. Om du vill inaktivera detta implicita beteende använder du alternativet --disable-arp-ping.
Standardbeteendet är normalt sett snabbare, men det här alternativet är användbart i nätverk som använder proxy ARP, där en router spekulativt svarar på alla ARP-begäranden, vilket gör att varje mål verkar vara igång enligt ARP-sökningen.
--discovery-ignore-rst
I vissa fall kan brandväggar förfalska svaren på TCP-återställning (RST) som svar på sökningar till obesatta eller otillåtna adresser. Eftersom Nmap normalt betraktar RST-svar som ett bevis på att målet är uppkopplat kan detta leda till slöseri med tid för att skanna mål som inte finns där. Om du använder --discovery-ignore-rst förhindrar du Nmap från att ta hänsyn till dessa svar under värdidentifieringen. Du kan behöva välja extra alternativ för värdupptäckt för att se till att du inte missar mål i det här fallet.
--traceroute(Trace path to host)
Traceroutes utförs efter skanning med hjälp av information från skanningsresultaten för att bestämma den port och det protokoll som är mest troligt att nå målet. Det fungerar med alla skanningstyper utom anslutningsskanning (-sT) och tomgångsskanning (-sI). Alla spårningar använder Nmaps dynamiska tidsmodell och utförs parallellt.
Traceroute fungerar genom att skicka paket med en låg TTL (time-to-live) i ett försök att framkalla ICMP Time Exceeded-meddelanden från mellanliggande hopp mellan skannern och målvärden. Standardtraceroute-implementationer börjar med en TTL på 1 och ökar TTL tills målvärden nås. Nmaps traceroute börjar med en hög TTL och minskar sedan TTL tills den når noll. Genom att göra det baklänges kan Nmap använda smarta caching-algoritmer för att påskynda spårningar över flera värdar. I genomsnitt skickar Nmap 5-10 färre paket per värd, beroende på nätverksförhållandena. Om ett enda delnät skannas (dvs. 192.168.0.0.0/24) behöver Nmap kanske bara skicka två paket till de flesta värdar.
-n(Ingen DNS-upplösning)
Anvisar för Nmap att aldrig göra en omvänd DNS-upplösning på de aktiva IP-adresser som hittas. Eftersom DNS kan vara långsam även med Nmaps inbyggda parallella stub-resolver kan det här alternativet minska skanningstiderna.
-R(DNS-upplösning för alla mål)
Säger åt Nmap att alltid göra omvänd DNS-upplösning på målets IP-adresser. Normalt utförs omvänd DNS endast mot responsiva (online) värdar.
--resolve-all(Scan each resolved address)
Om ett värdnamnsmål löser upp till mer än en adress ska du skanna alla adresser. Standardbeteendet är att endast skanna den första upplösta adressen. Oavsett detta kommer endast adresser i lämplig adressfamilj att skannas: IPv4 som standard, IPv6 med -6.
--system-dns(Använd systemets DNS-resolver)
Som standard löser Nmap omvända IP-adresser genom att skicka förfrågningar direkt till de namnservrar som är konfigurerade på din värd och sedan lyssna på svar. Många förfrågningar (ofta dussintals) utförs parallellt för att förbättra prestandan. Ange det här alternativet för att istället använda din systemresolver (en IP i taget via getnameinfo-anropet). Detta är långsammare och sällan användbart om du inte hittar ett fel i Nmaps parallella resolver (låt oss veta om du gör det). Systemresolver används alltid för forward lookups (för att få fram en IP-adress från ett värdnamn).
--dns-servers (Servrar som ska användas för omvända DNS-frågor)<server1>]
Som standard bestämmer Nmap dina DNS-servrar (för rDNS-upplösning) från din resolv.conf-fil (Unix) eller registret (Win32). Alternativt kan du använda det här alternativet för att ange alternativa servrar. Det här alternativet respekteras inte om du använder --system-dns. Att använda flera DNS-servrar är ofta snabbare, särskilt om du väljer auktoritativa servrar för ditt mål-IP-område. Det här alternativet kan också förbättra smygandet, eftersom dina förfrågningar kan avvisas från nästan vilken rekursiv DNS-server som helst på Internet.
Det här alternativet är också praktiskt när du skannar privata nätverk. Ibland är det bara ett fåtal namnservrar som tillhandahåller korrekt rDNS-information, och du kanske inte ens vet var de finns. Du kan skanna nätverket efter port 53 (kanske med versionsupptäckt) och sedan prova Nmap-listskanning (-sL) och specificera varje namnserver en i taget med --dns-servers tills du hittar en som fungerar.
Det här alternativet kanske inte respekteras om DNS-svaret överskrider storleken på ett UDP-paket. I en sådan situation kommer vår DNS-upplösare att göra sitt bästa för att få fram ett svar från det förkortade paketet, och om det inte lyckas kommer den att återgå till att använda systemupplösaren. Svar som innehåller CNAME-alias kommer också att återgå till systemupplösaren.