Distinktion mellan öppna och filtrerade UDP-portar
I fallet med Felix-skanningen var alla utom de tre open|filtered-portarna closed, så skanningen lyckades ändå begränsa de potentiellt öppna portarna till en handfull. Detta är inte alltid fallet. Exempel 5.5 visar en UDP-skanning mot den kraftigt filtrerade webbplatsen Scanme.
Exempel 5.5. UDP-skanning exempel
krad# Starting Nmap ( http://nmap.org )All 1000 scanned ports on scanme.nmap.org (64.13.134.52) are open|filteredNmap done: 1 IP address (1 host up) scanned in 5.50 seconds
I det här fallet har skanningen inte begränsat de öppna portarna alls.Alla 1000 är open|filtered. En ny strategi är nödvändig.
Tabell 5.3, ”Hur Nmap tolkar svaren på en UDP-probe” visar att open|filtered-tillståndet uppstår när Nmap inte får några svar från sina UDP-probes till en viss port.Men den visar också att i sällsynta fall svarar den UDP-tjänst som lyssnar på en port på samma sätt, vilket bevisar att porten är öppen. Anledningen till att dessa tjänster inte svarar ofta är att de tomma paket som Nmap skickar anses vara ogiltiga. Tyvärr definierar UDP-tjänsterna i allmänhet sin egen paketstruktur i stället för att följa ett gemensamt generellt format som Nmap alltid kan skicka. Ett SNMP-paket ser helt annorlunda ut än ett SunRPC-, DHCP- eller DNS-förfrågningspaket.
För att skicka rätt paket för varje populär UDP-tjänst skulle Nmap behöva en stor databas som definierar deras sondformat.Lyckligtvis har Nmap det i form avnmap-service-probes, som är en del av delsystemet för tjänste- och versionsavkänning som beskrivs i kapitel 7, Avkänning av tjänste- och programversioner.
När versionsavkänning är aktiverad med -sV (eller-A) kommer den att skicka UDP-prober till varjeopen|filtered-port (samt till kändaopen-portar). Om någon av proberna framkallar ett svar från en open|filtered-port ändras tillståndet till open. Resultaten av att lägga till-sV till Felix-sökningen visas i exempel 5.6.
Exempel 5.6. Förbättring av Felix UDP-skanningsresultat med versionsupptäckt
krad# Starting Nmap ( http://nmap.org )Nmap scan report for felix.nmap.org (192.168.0.42)Not shown: 997 closed portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.2.167/udp open|filtered dhcpserver111/udp open rpcbind 2 (rpc #100000)MAC Address: 00:02:E3:14:11:02 (Lite-on Communications)Nmap done: 1 IP address (1 host up) scanned in 1037.57 seconds
Denna nya skanning visar att port 111 och 53 definitivt är öppna.Systemet är dock inte perfekt – port 67 är fortfarandeopen|filtered. I det här fallet är porten öppen, men Nmap har ingen fungerande version av DHCP-sonden.En annan svår tjänst är SNMP, som vanligtvis bara svarar när den korrekta communitysträngen anges. Många enheter är konfigurerade med communitysträngen public, men inte alla är det.Även om dessa resultat inte är perfekta är det ändå användbart att lära sig det verkliga tillståndet för två av tre testade portar.
Efter framgången med att särskilja Felix-resultaten vänder Ere sin uppmärksamhet tillbaka till Scanme, som listade alla portar som open|filtered förra gången. Han försöker igen med versionsupptäckt, vilket visas i exempel 5.7.
Exempel 5.7. Förbättring av Scanmes UDP-skanningsresultat med versionsupptäckt
krad# Starting Nmap ( http://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 999 open|filtered portsPORT STATE SERVICE VERSION53/udp open domain ISC BIND 9.3.4Nmap done: 1 IP address (1 host up) scanned in 3691.89 seconds
Och även om Ereet så småningom hittade den öppna porten gjorde han ett misstag genom att inte uppdatera sin Nmap-version först. Nmap version 5.10BETA1 och nyare har ett nyttolastsystem som skickar korrekta tjänsteprotokollförfrågningar till mer än tre dussin välkända UDP-portar om de väljs för portskanning eller värdupptäckt. Även om det inte är lika omfattande som versionsdetektering skulle det snabbt ha identifierat den öppna porten 53 i exempel 5.5.
Detta resultat tog en timme, jämfört med fem sekunder för den tidigareScanme-skanningen, men dessa resultat är faktiskt användbara. Ereets leende blir bredare och ögonen glittrar vid detta bevis på en öppen ISC BINDnameserver på en maskin som han vill äventyra. Den programvaran har en lång historia av säkerhetshål, så kanske kan han hitta ett fel i den här senaste versionen.
Ereet kommer att fokusera sina UDP-attacker på port 53 eftersom den är bekräftat öppen, men han glömmer inte bort de andra 999 portarna som listas som open|filtered. Som vi såg med dhcpserver-porten på Felix kan vissa öppna UDP-tjänster gömma sig till och med från Nmap-versionsupptäckt. Han har också bara skannat standardportarna hittills, det finns 64529 andra portar som eventuellt kan vara öppna. För övrigt är 53 den enda öppna UDP-porten på Scanme.
Men även om denna teknik för att upptäcka versioner är det enda sättet för Nmapt att automatiskt särskilja open|filtered-portar finns det ett par knep som kan användas manuellt. Ibland kan en specialiserad traceroute hjälpa till. Du kan göra en traceroute mot en känd öppen TCP- eller UDP-port med Nmap eller ett verktyg som Nping.Försök sedan samma sak mot den tvivelaktiga UDP-porten. Skillnader i antalet hopp kan skilja mellan öppna och filtrerade portar. Ereet försöker detta motScanme i exempel 5.8. Det första kommandot gör en UDP-traceroute mot den kända öppna porten 53. Det andra kommandot gör samma sak mot den förmodat stängda port 54. De första hoppen har utelämnats för att spara utrymme.
Exempel 5.8. Försök att särskilja UDP-portar med TTL-diskrepanser
krad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=8 id=4826 iplen=28RCVD (7.1010s) ICMP 4.69.134.222 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=38454 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=9 id=38166 iplen=28RCVD (8.1050s) ICMP 4.68.18.204 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=39583 iplen=56SENT (9.0420s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=10 id=6788 iplen=28RCVD (9.1080s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=59897 iplen=56SENT (10.0440s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=11 id=366 iplen=28RCVD (10.1100s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=42710 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=12 id=63478 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:53 ttl=13 id=56653 iplen=28Max rtt: 73.003ms | Min rtt: 0.540ms | Avg rtt: 48.731msRaw packets sent: 13 (364B) | Rcvd: 10 (560B) | Lost: 3 (23.08%)Tx time: 12.02836s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.02994s | Rx bytes/s: 42.98 | Rx pkts/s: 0.77Nping done: 1 IP address pinged in 13.05 secondskrad# Starting Nping ( http://nmap.org/nping )SENT (7.0370s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=8 id=56481 iplen=28RCVD (7.1130s) ICMP 4.69.134.214 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=248 id=22437 iplen=56SENT (8.0400s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=9 id=23264 iplen=28RCVD (8.1060s) ICMP 4.68.18.76 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=247 id=50214 iplen=56SENT (9.0430s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=10 id=9101 iplen=28RCVD (9.1070s) ICMP 4.59.4.78 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=246 id=880 iplen=56SENT (10.0450s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=11 id=35344 iplen=28RCVD (10.1110s) ICMP 69.36.239.221 > 192.168.0.21 TTL=0 during transit (type=11/code=0) ttl=243 id=44617 iplen=56SENT (11.0470s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=12 id=53857 iplen=28SENT (12.0490s) UDP 192.168.0.21:53 > 64.13.134.52:54 ttl=13 id=986 iplen=28Max rtt: 76.488ms | Min rtt: 0.546ms | Avg rtt: 48.480msRaw packets sent: 13 (364B) | Rcvd: 11 (616B) | Lost: 2 (15.38%)Tx time: 12.02908s | Tx bytes/s: 30.26 | Tx pkts/s: 1.08Rx time: 13.03165s | Rx bytes/s: 47.27 | Rx pkts/s: 0.84Nping done: 1 IP address pinged in 13.05 seconds
I det här exemplet kunde Ereet endast nå hopp elva för både de öppna och stängda portarna. Så dessa resultat kan inte användas för att särskilja porttillstånd för den här värden. Det var värt ett försök, och det fungerar i ett betydande antal fall. Det är mer troligt att det fungerar i situationer där den granskande brandväggen befinner sig minst ett eller två hopp före målvärden. Scanme däremot kör sin egen Linuxiptableshost-baserade brandvägg. Det finns alltså ingen skillnad i antal hopp mellan filtrerade och öppna portar.
En annan teknik är att prova programspecifika verktyg mot vanliga portar. Till exempel kan en brute force SNMP community stringcracker prövas mot port 161. I takt med att Nmaps databas med prover för versionsupptäckt växer minskar behovet av att komplettera resultaten med externa specialiserade verktyg. De kommer fortfarande att vara användbara för specialfall, t.ex. SNMP-enheter med en anpassad gemenskapssträng.