Adskillelse af åbne fra filtrerede UDP-porte
I Felix-scanningen var alle undtagen de tre open|filtered-porte closed, så scanningen lykkedes stadig med at indsnævre de potentielt åbne porte til en håndfuld. Det er ikke altid tilfældet. Eksempel 5.5 viser en UDP-scanning moddet stærkt filtrerede websted Scanme.
Eksempel 5.5. Eksempel på UDP-scanning
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 dette tilfælde indsnævrede scanningen slet ikke de åbne porte.Alle 1000 er open|filtered. En ny strategi er påkrævet.
Tabel 5.3, “Hvordan Nmap fortolker svar på en UDP-probe”, viser, at open|filtered-tilstanden opstår, når Nmap ikke modtager svar fra sine UDP-probes til en bestemt port.Men den viser også, at i sjældne tilfælde vil den UDP-tjeneste, der lytter på en port, svare på samme måde, hvilket beviser, at porten er åben. Grunden til, at disse tjenester ikke svarer ofte, er, at de tomme pakker, som Nmap sender, betragtes som ugyldige. Desværre definerer UDP-tjenester generelt deres egen pakkestruktur i stedet for at holde sig til et fælles generelt format, som Nmap altid kan sende. En SNMP-pakke ser helt anderledes ud end en SunRPC-, DHCP- eller DNS-anmodningspakke.
For at sende den rigtige pakke for hver enkelt populær UDP-tjeneste ville Nmap have brug for en stor database, der definerer deres probe-formater.Heldigvis har Nmap den i form afnmap-service-probes,som er en del af delsystemet til registrering af tjenester og versioner, der er beskrevet i Kapitel 7, Registrering af tjeneste- og programversioner.
Når versionsscanning er aktiveret med -sV (eller-A), vil den sende UDP-probes til hveropen|filtered port (samt kendteopen porte). Hvis nogen af sonderne fremkalder et svar fra en open|filtered-port, ændres tilstanden til open. Resultaterne af at tilføje-sV til Felix-scanningen er vist i eksempel 5.6.
Eksempel 5.6. Forbedring af Felix’ UDP-scanningsresultater med versionsdetektion
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
Denne nye scanning viser, at port 111 og 53 helt sikkert er åbne.Systemet er dog ikke perfekt – port 67 er stadigopen|filtered. I dette særlige tilfælde er porten åben, men Nmap har ikke en fungerende version probe for DHCP.En anden vanskelig tjeneste er SNMP, som normalt kun reagerer, når den korrekte community string er angivet. Mange enheder er konfigureret med fællesskabsstrengen public, men ikke alle er det.Selv om disse resultater ikke er perfekte, er det stadig nyttigt at lære den sande tilstand for to ud af tre testede porte at kende.
Efter succes med at afklare Felix-resultaterne vender Ere sin opmærksomhed tilbage til Scanme, som sidste gang angav alle porte som open|filtered. Han prøver igen med versionsdetektion, som vist i eksempel 5.7.
Eksempel 5.7. Forbedring af Scanmes UDP-scanningsresultater med versionsdetektion
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
Mens Ereet til sidst fandt den åbne port, begik han en fejl, da han ikke opdaterede sin Nmap-version først. Nmap-version 5.10BETA1 og nyere har et payload-system, som sender egentlige serviceprotokolforespørgsler til mere end tre dusin velkendte UDP-porte, hvis de er valgt til portscanning eller værtsopdagelse. Selv om det ikke er så omfattende som versionsdetektion, ville det hurtigt have identificeret den åbne port 53 i eksempel 5.5.
Dette resultat tog en time mod fem sekunder for den tidligereScanme-scanning, men disse resultater er faktisk nyttige. Ereets smil bliver bredere og øjnene funkler ved dette bevis på en åben ISC BINDnameserver på en maskine, som han ønsker at kompromittere. Denne software har en lang historie med sikkerhedshuller, så måske kan han finde en fejl i denne seneste version.
Ereet vil fokusere sine UDP-angreb på port 53, da den er bekræftet åben, men han glemmer ikke de andre 999 porte, der er opført somopen|filtered. Som vi oplevede med dhcpserver-porten på Felix, kan visse åbne UDP-tjenester skjule sig selv for Nmap-versiondetektion. Han har også kun scannet standardportene indtil videre, der er 64529 andre, som muligvis kunne være åbne. For therecord, 53 er den eneste åbne UDP-port på Scanme.
Mens denne versionsdetektionsteknik er den eneste måde for Nmapto automatisk at skelne open|filtered porte på, er der et par tricks, der kan forsøges manuelt. Nogle gange kan aspecialized traceroute hjælpe. Du kan lave en traceroute mod en kendt åben TCP- eller UDP-port med Nmap eller et værktøj som Nping.Prøv derefter det samme mod den tvivlsomme UDP-port. Forskelle i antallet af hop kan skelne mellem åbne og filtrerede porte. Ereet forsøger dette modScanme i eksempel 5.8. Den første kommando udfører en UDP-traceroute mod den kendte-åbne port 53. Den anden kommando gør det samme mod den formodet lukkede port 54. De første par hop er udeladt for at spare plads.
Eksempel 5.8. Forsøg på at afkode UDP-porte med TTL-afvigelser
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 dette eksempel var Ereet kun i stand til at nå hop elleve for både den åbne og den lukkede port. Så disse resultater kan ikke bruges til at skelne mellem porttilstande mod denne vært. Det var et forsøg værd, og det virker i et betydeligt antal tilfælde. Det er mere sandsynligt, at det virker i situationer, hvor screeningsfirewall’en er mindst et hop eller to før målværten. Scanme kører på den anden side sin egen Linuxiptableshost-baserede firewall. Så der er ingen forskel i hop-tallet mellem filtrerede og åbne porte.
En anden teknik er at afprøve applikationsspecifikke værktøjer mod almindelige porte. F.eks. kan man prøve en brute force SNMP community stringcracker mod port 161. Efterhånden som Nmaps database af versiondetekteringssonder vokser, reduceres behovet for at udvide resultaterne med eksterne specialiserede værktøjer. De vil stadig være nyttige i specialtilfælde, f.eks. SNMP-enheder med en brugerdefineret fællesskabsstreng.