Free Press

-sL(List Scan)

List scan er en degenereret form for host discovery, der blot viser en liste over hver vært i de(t) angivne netværk uden at sende pakker til målværterne. Som standard foretager Nmap stadig reverse-DNS-opløsning på værterne for at lære deres navne at kende. Det er ofte overraskende, hvor mange nyttige oplysninger simple værtsnavne giver. F.eks. er fw.chi navnet på en virksomheds Chicago firewall. Nmap rapporterer også det samlede antal IP-adresser til sidst. List scanningen er et godt sanity check for at sikre, at du har korrekte IP-adresser til dine mål. Hvis værterne har domænenavne, som du ikke genkender, er det værd at undersøge det nærmere for at undgå at scanne det forkerte firmas netværk.

Da ideen er blot at udskrive en liste over målværter, kan muligheder for funktionalitet på højere niveau, såsom portscanning, OS-detektion eller host discovery, ikke kombineres med dette. Hvis du ønsker at deaktivere host discovery, mens du stadig udfører en sådan funktionalitet på højere niveau, skal du læse om indstillingen -Pn (skip host discovery).

-sn(No port scan)

Denne indstilling fortæller Nmap, at den ikke skal foretage en portscanning efter host discovery, og kun udskrive de tilgængelige hosts, der svarede på host discovery-proberne. Dette er ofte kendt som en “ping-scanning”, men du kan også anmode om, at traceroute- og NSE-værtsscripts køres. Dette er som standard et trin mere indgribende end list scanningen, og kan ofte bruges til de samme formål. Det giver mulighed for let rekognoscering af et målnetværk uden at tiltrække sig megen opmærksomhed. Det er mere værdifuldt for angribere at vide, hvor mange værter der er oppe, end den liste, der leveres af list scan af hver enkelt IP og værtsnavn.

Systemadministratorer finder ofte også denne mulighed værdifuld. Den kan nemt bruges til at tælle tilgængelige maskiner på et netværk eller overvåge servertilgængelighed. Dette kaldes ofte en ping-søgning og er mere pålideligt end at pinge broadcast-adressen, fordi mange værter ikke svarer på broadcast-forespørgsler.

Den standardværtsopdagelse, der udføres med -sn, består som standard af en ICMP-echo-anmodning, TCP SYN til port 443, TCP ACK til port 80 og en ICMP-tidsstempelanmodning. Når den udføres af en ikke-privilegeret bruger, sendes der kun SYN-pakker (ved hjælp af et connect-opkald) til port 80 og 443 på målet. Når en privilegeret bruger forsøger at scanne mål på et lokalt ethernet-netværk, anvendes ARP-forespørgsler, medmindre --send-ip er angivet. Indstillingen -sn kan kombineres med en hvilken som helst af discovery probe-typerne (indstillingerne -P*) for at opnå større fleksibilitet. Hvis en af disse indstillinger for probe-type og portnummer anvendes, tilsidesættes standardproberne. Når der er strenge firewalls på plads mellem kildeværten, der kører Nmap, og målnetværket, anbefales det at bruge disse avancerede teknikker. Ellers kan værter blive overset, når firewallen dropper probes eller deres svar.

I tidligere udgaver af Nmap var -sn kendt som -sP.

-Pn(Ingen ping)

Denne indstilling springer værtsopdagelsesfasen helt over. Normalt bruger Nmap denne fase til at bestemme aktive maskiner til tungere scanning og til at måle netværkets hastighed. Som standard udfører Nmap kun tunge undersøgelser som f.eks. portscanninger, versionsdetektering eller OS-detektering mod værter, der findes at være oppe. Hvis værtsopdagelse deaktiveres med -Pn, får Nmap Nmap til at forsøge de ønskede scanningsfunktioner mod alle angivne mål-IP-adresser. Så hvis et netværk på størrelse /16 er angivet på kommandolinjen, bliver alle 65.536 IP-adresser scannet. Korrekt host discovery springes over som ved list scan, men i stedet for at stoppe og udskrive mållisten fortsætter Nmap med at udføre de ønskede funktioner, som om hver mål-IP er aktiv. Der anvendes standard timingparametre, hvilket kan resultere i langsommere scanninger. Hvis du vil springe værtsopdagelse og portscanning over, mens NSE stadig kan køre, skal du bruge de to indstillinger -Pn -sn sammen.

For maskiner på et lokalt Ethernet-netværk vil ARP-scanning stadig blive udført (medmindre --disable-arp-ping eller --send-ip er angivet), fordi Nmap har brug for MAC-adresser for at kunne scanne målværter yderligere. I tidligere versioner af Nmap var -Pn -P0 og -PN.

-PS <port list>(TCP SYN Ping)

Denne indstilling sender en tom TCP-pakke med SYN-flaget sat. Standardmålporten er 80 (kan konfigureres på kompileringstidspunktet ved at ændre DEFAULT_TCP_PROBE_PORT_SPEC i nmap.h). Alternative porte kan angives som en parameter. Syntaksen er den samme som for -p, bortset fra at porttypespecifikatorer som T: ikke er tilladt. Eksempler er -PS22 og -PS22-25,80,113,1050,35000. Bemærk, at der ikke må være noget mellemrum mellem -PS og portlisten. Hvis der angives flere probes, sendes de parallelt.

SYN-flaget antyder over for fjernsystemet, at du forsøger at oprette en forbindelse. Normalt vil destinationsporten blive lukket, og en RST-pakke (reset) vil blive sendt tilbage. Hvis porten tilfældigvis er åben, vil målet tage det andet trin i en TCP-trevejshandshake ved at svare med en SYN/ACK TCP-pakke. Maskinen, der kører Nmap, afbryder derefter den begyndende forbindelse ved at svare med en RST-pakke i stedet for at sende en ACK-pakke, som ville afslutte trevejs-handshaken og etablere en fuld forbindelse. RST-pakken sendes af kernen på den maskine, der kører Nmap, som svar på den uventede SYN/ACK-pakke, ikke af Nmap selv.

Nmap er ligeglad med, om porten er åben eller lukket. Enten RST- eller SYN/ACK-svaret, som er omtalt tidligere, fortæller Nmap, at værten er tilgængelig og reagerer.

På Unix-bokse er det normalt kun den privilegerede bruger root, der kan sende og modtage rå TCP-pakker. For ikke-privilegerede brugere anvendes der automatisk en omgåelse, hvor systemkaldet connect initieres mod hver målport. Dette har den virkning, at der sendes en SYN-pakke til målværten i et forsøg på at etablere en forbindelse. Hvis connect returnerer med en hurtig succes eller en ECONNREFUSED-fejl, skal den underliggende TCP-stack have modtaget en SYN/ACK eller RST, og værten er markeret som tilgængelig. Hvis forbindelsesforsøget bliver hængende, indtil der nås en timeout, markeres værten som nede.

-PA <port list>(TCP ACK Ping)

TCP ACK ping ligner ganske meget den netop omtalte SYN ping. Forskellen er, som du sikkert kan gætte, at TCP ACK-flaget er sat i stedet for SYN-flaget. En sådan ACK-pakke foregiver at bekræfte data over en etableret TCP-forbindelse, men en sådan forbindelse eksisterer ikke. Så fjernværter bør altid svare med en RST-pakke og afsløre deres eksistens i processen.

Optionen -PA bruger den samme standardport som SYN-sonden (80) og kan også tage en liste over destinationsporte i samme format. Hvis en ikke-privilegeret bruger forsøger dette, anvendes den tidligere omtalte connect-forbedring connect. Denne omgåelse er ufuldkommen, fordi connect faktisk sender en SYN-pakke i stedet for en ACK.

Grunden til at tilbyde både SYN- og ACK-ping-probes er at maksimere chancerne for at omgå firewalls. Mange administratorer konfigurerer routere og andre simple firewalls til at blokere indgående SYN-pakker undtagen dem, der er bestemt for offentlige tjenester som f.eks. virksomhedens websted eller mailserver. Dette forhindrer andre indgående forbindelser til organisationen, mens brugerne kan oprette uhindrede udgående forbindelser til internettet uden hindringer. Denne ikke-stateful tilgang optager få ressourcer på firewallen/routeren og understøttes i vid udstrækning af hardware- og softwarefiltre. Firewallsoftwaren Linux Netfilter/iptables tilbyder bekvemmelighedsindstillingen --syn til at implementere denne stateless-tilgang. Når stateless firewallregler som denne er på plads, vil SYN ping probes (-PS) sandsynligvis blive blokeret, når de sendes til lukkede målporte. I sådanne tilfælde brillerer ACK-proben, da den skærer lige igennem disse regler.

En anden almindelig type firewall anvender stateful-regler, der dropper uventede pakker. Denne funktion fandtes oprindeligt mest på high-end firewalls, selv om den er blevet meget mere almindelig i årenes løb. Linux Netfilter/iptables-systemet understøtter dette gennem --state-indstillingen, som kategoriserer pakker baseret på forbindelsestilstand. En SYN-probe har større sandsynlighed for at virke mod et sådant system, da uventede ACK-pakker generelt bliver genkendt som falske og droppet. En løsning på dette dilemma er at sende både SYN- og ACK-probes ved at angive -PS og -PA.

-PU <port list>(UDP Ping)

En anden mulighed for værtsopdagelse er UDP ping, som sender en UDP-pakke til de angivne porte. For de fleste porte vil pakken være tom, selv om nogle bruger en protokolspecifik nyttelast, der er mere tilbøjelig til at fremkalde et svar, se afsnittet “UDP-nyttelaster”: nmap-payloads” for en beskrivelse af databasen af payloads.Pakkeindholdet kan også påvirkes med indstillingerne --data,--data-string og --data-length.

Portlisten har samme format som med de tidligere omtalte indstillinger -PS og -PA. Hvis der ikke er angivet nogen porte, er standardværdien 40125. Denne standard kan konfigureres på kompileringstidspunktet ved at ændre DEFAULT_UDP_PROBE_PORT_SPEC i nmap.h. En meget ualmindelig port anvendes som standard, fordi det ofte er uønsket at sende til åbne porte for denne særlige scanningstype.

Når UDP-sonden rammer en lukket port på målmaskinen, skal den fremkalde en ICMP-pakke med port unreachable til gengæld. Dette betyder for Nmap, at maskinen er oppe og tilgængelig. Mange andre typer ICMP-fejl, f.eks. host/network unreachables eller TTL exceeded, er tegn på, at en vært er nede eller ikke kan nås. Et manglende svar fortolkes også på denne måde. Hvis en åben port nås, ignorerer de fleste tjenester simpelthen den tomme pakke og returnerer ikke noget svar. Dette er grunden til, at standardprobport er 40125, som højst sandsynligt ikke er i brug. Nogle få tjenester, som f.eks. protokollen Character Generator (chargen), vil svare på en tom UDP-pakke og dermed afsløre over for Nmap, at maskinen er tilgængelig.

Den primære fordel ved denne scanningstype er, at den omgår firewalls og filtre, der kun screener TCP. F.eks. ejede jeg engang en Linksys BEFW11S4 trådløs bredbåndsrouter. Den eksterne grænseflade på denne enhed filtrerede som standard alle TCP-porte, men UDP-sonderinger ville stadig fremkalde port unreachable-meddelelser og dermed afsløre enheden.

-PY <port list>(SCTP INIT Ping)

Denne indstilling sender en SCTP-pakke, der indeholder en minimal INIT-chunk. Standardmålporten er 80 (kan konfigureres på kompileringstidspunktet ved at ændre DEFAULT_SCTP_PROBE_PORT_SPEC i nmap.h). Alternative porte kan angives som en parameter. Syntaksen er den samme som for -p bortset fra, at porttypespecifikatorer som S: ikke er tilladt. Eksempler er -PY22 og -PY22,80,179,5060. Bemærk, at der ikke må være noget mellemrum mellem -PY og portlisten. Hvis der angives flere probes, sendes de parallelt.

Init-chunk’en antyder over for fjernsystemet, at du forsøger at etablere en tilknytning. Normalt vil destinationsporten blive lukket, og der vil blive sendt en ABORT chunk tilbage. Hvis porten tilfældigvis er åben, vil målet tage det andet trin i en SCTP fire-vejs-handshake ved at svare med en INIT-ACK chunk. Hvis den maskine, der kører Nmap, har en funktionel SCTP-stack, nedbryder den den spirende forbindelse ved at svare med en ABORT-chunk i stedet for at sende en COOKIE-ECHO-chunk, som ville være det næste trin i firevejshandshake. ABORT-pakken sendes af kernen på den maskine, der kører Nmap, som svar på den uventede INIT-ACK, ikke af Nmap selv.

Nmap er ligeglad med, om porten er åben eller lukket. Enten ABORT- eller INIT-ACK-svaret, som tidligere omtalt, fortæller Nmap, at værten er tilgængelig og reagerer.

På Unix-bokse er det normalt kun den privilegerede bruger root, der kan sende og modtage rå SCTP-pakker. Brug af SCTP INIT Pings er i øjeblikket ikke muligt for ikke-privilegerede brugere.

-PE;-PP;-PM(ICMP Ping-typer)

Ud over de usædvanlige TCP-, UDP- og SCTP-værtsopdagelsestyper, der er omtalt tidligere, kan Nmap sende de standardpakker, der sendes af det allestedsnærværende ping-program. Nmap sender en ICMP-pakke af typen 8 (echo request) til mål-IP-adresserne og forventer til gengæld en type 0 (echo reply) fra de tilgængelige værter. Desværre for netværksforskere blokerer mange værter og firewalls nu disse pakker i stedet for at svare som krævet i RFC 1122. Af denne grund er ICMP-scanninger alene sjældent pålidelige nok mod ukendte mål over internettet. Men for systemadministratorer, der overvåger et internt netværk, kan de være en praktisk og effektiv metode. Brug indstillingen -PE for at aktivere denne echo request-adfærd.

Selv om echo request er standard ICMP ping-forespørgsel, stopper Nmap ikke her. ICMP-standarderne (RFC 792 og RFC 950 ) angiver også timestamp request, information request og address mask request-pakker som henholdsvis kode 13, 15 og 17. Selv om det tilsyneladende formål med disse forespørgsler er at få oplysninger om f.eks. adressemasker og aktuelle tidspunkter, kan de nemt bruges til at finde værter. Et system, der svarer, er oppe og tilgængeligt. Nmap implementerer i øjeblikket ikke pakker med informationsforespørgsler, da de ikke er bredt understøttet. RFC 1122 insisterer på, at “en vært SKAL IKKE implementere disse meddelelser”. Forespørgsler om tidsstempel og adressemaske kan sendes med henholdsvis indstillingerne -PP og -PM. Et tidsstempelsvar (ICMP-kode 14) eller et adressemasksvar (kode 18) oplyser, at værten er tilgængelig. Disse to forespørgsler kan være værdifulde, når administratorer specifikt blokerer echo request-pakker og samtidig glemmer, at andre ICMP-forespørgsler kan bruges til samme formål.

-PO <protocol list>(IP Protocol Ping)

En af de nyere muligheder for værtsopdagelse er IP protocol ping, som sender IP-pakker med det angivne protokolnummer sat i deres IP-header. Protokollisten har samme format som portlisterne i de tidligere omtalte TCP-, UDP- og SCTP-værtsopdagelsesmuligheder. Hvis der ikke er angivet nogen protokoller, sendes der som standard flere IP-pakker for ICMP (protokol 1), IGMP (protokol 2) og IP-in-IP (protokol 4). Standardprotokollerne kan konfigureres på kompileringstidspunktet ved at ændre DEFAULT_PROTO_PROBE_PORT_SPEC i nmap.h. Bemærk, at for ICMP, IGMP, TCP (protokol 6), UDP (protokol 17) og SCTP (protokol 132) sendes pakkerne med de korrekte protokolheadere, mens andre protokoller sendes uden yderligere data ud over IPheaderen (medmindre en af indstillingerne --data, --data-string eller --data-length er angivet).

Denne værtsopdagelsesmetode leder enten efter svar, der bruger den samme protokol som en probe, eller ICMP-protokolutilgængelige meddelelser, som angiver, at den givne protokol ikke understøttes på destinationsværten. Begge typer svar betyder, at målværten er i live. --disable-arp-ping (Ingen ARP- eller ND-ping)

Nmap udfører normalt ARP- eller IPv6 Neighbor Discovery (ND)-opdagelse af lokalt tilsluttede ethernetværter, selv om andre værtsopdagelsesindstillinger som -Pn eller -PE anvendes. Hvis du vil deaktivere denne implicitte adfærd, skal du bruge indstillingen --disable-arp-ping.

Standardadfærden er normalt hurtigere, men denne indstilling er nyttig i netværk, der bruger proxy ARP, hvor en router svarer spekulativt på alle ARP-forespørgsler, hvilket får alle mål til at se ud til at være oppe ifølge ARP-scanningen.

--discovery-ignore-rst

I nogle tilfælde kan firewalls forfalske TCP-reset (RST)-svar som svar på probes til ubesatte eller ikke tilladte adresser. Da Nmap normalt anser RST-svar for at være et bevis på, at målet er oppe, kan dette føre til spild af tid med at scanne mål, der ikke er der. Hvis du bruger --discovery-ignore-rst, forhindrer du Nmap i at tage hensyn til disse svar under værtsopdagelsen. Det kan være nødvendigt at vælge ekstra værtsopdagelsesindstillinger for at sikre, at du ikke går glip af mål i dette tilfælde.

--traceroute(Trace path to host)

Traceroutes udføres efter scanningen ved hjælp af oplysninger fra scanningsresultaterne for at bestemme den port og protokol, der er mest sandsynlig for at nå målet. Det fungerer med alle scanningstyper undtagen forbindelsesscanninger (-sT) og tomgangsscanninger (-sI). Alle sporinger bruger Nmaps dynamiske tidsmodel og udføres parallelt.

Traceroute fungerer ved at sende pakker med en lav TTL (time-to-live) i et forsøg på at fremkalde ICMP Time Exceeded-meddelelser fra mellemliggende hops mellem scanneren og målværten. Standardtraceroute-implementeringer starter med en TTL på 1 og øger TTL’en, indtil destinationsværten er nået. Nmaps traceroute starter med en høj TTL og nedsætter derefter TTL, indtil den når nul. Ved at gøre det baglæns kan Nmap anvende smarte caching-algoritmer til at fremskynde sporing over flere værter. I gennemsnit sender Nmap 5-10 færre pakker pr. vært, afhængigt af netværksforholdene. Hvis et enkelt undernet bliver scannet (dvs. 192.168.0.0.0/24), behøver Nmap måske kun at sende to pakker til de fleste værter.

-n(Ingen DNS-opløsning)

Angiver, at Nmap aldrig skal foretage omvendt DNS-opløsning på de aktive IP-adresser, den finder. Da DNS kan være langsomt, selv med Nmaps indbyggede parallelle stub-resolver, kan denne indstilling reducere scanningstiden.

-R(DNS-opløsning for alle mål)

Angiver, at Nmap altid skal foretage omvendt DNS-opløsning på målets IP-adresser. Normalt udføres reverse DNS kun mod responsive (online) værter.

--resolve-all(Scan hver opløst adresse)

Hvis et værtsnavnsmål opløser til mere end én adresse, skal du scanne dem alle. Standardadfærden er kun at scanne den første opløste adresse. Uanset dette vil kun adresser i den relevante adressefamilie blive scannet: IPv4 som standard, IPv6 med -6.

--system-dns(Brug systemets DNS-resolver)

Som standard omvendt opløser Nmap IP-adresser ved at sende forespørgsler direkte til de navneservere, der er konfigureret på din vært, og derefter lytte efter svar. Mange forespørgsler (ofte snesevis) udføres parallelt for at forbedre ydeevnen. Angiv denne indstilling for at bruge din systemopløser i stedet (en IP ad gangen via getnameinfo-opkaldet). Dette er langsommere og sjældent nyttigt, medmindre du finder en fejl i den parallelle Nmap-resolver (lad os vide, hvis du gør det). Systemresolveren bruges altid til forward lookups (hente en IP-adresse fra et værtsnavn).

--dns-servers <server1>] (Servere til brug for reverse DNS-forespørgsler)

Som standard bestemmer Nmap dine DNS-servere (til rDNS-opløsning) ud fra din resolv.conf-fil (Unix) eller registreringsdatabasen (Win32). Alternativt kan du bruge denne indstilling til at angive alternative servere. Denne indstilling respekteres ikke, hvis du bruger --system-dns. Det er ofte hurtigere at bruge flere DNS-servere, især hvis du vælger autoritative servere for dit mål-IP-område. Denne indstilling kan også forbedre stealth, da dine anmodninger kan blive afvist af stort set alle rekursive DNS-servere på internettet.

Denne indstilling er også praktisk, når du scanner private netværk. Nogle gange er det kun nogle få navneservere, der leverer ordentlige rDNS-informationer, og du ved måske ikke engang, hvor de er. Du kan scanne netværket for port 53 (evt. med versionsdetektion) og derefter prøve Nmap-listescanninger (-sL), hvor du specificerer hver navneserver én ad gangen med --dns-servers, indtil du finder en, der virker.

Denne indstilling kan muligvis ikke honoreres, hvis DNS-svaret overstiger størrelsen af en UDP-pakke. I en sådan situation vil vores DNS-resolver gøre sit bedste for at udtrække et svar fra den afkortede pakke, og hvis det ikke lykkes, vil den falde tilbage til at bruge systemets resolver. Svar, der indeholder CNAME-aliaser, vil også falde tilbage til systemopløseren.