Friday, 4 December 2009
Juletip 4: IPv4 gråzoner og magiske konstanter
« Juletip 3: ARP vs NDP, IPv6 Neighbor Discovery Protocol | Main | Juletip 5: Vi bygger pakker »4. december og jeg har stadig ikke købt julegaver :-(
Idag skal det handle om IPv4, selvom det meste i denne kalender handler om IPv4 :-) Men mere præcist snakker jeg idag om IPv4 pakkens header. Lad os derfor tage en tur tilbage med tidsmaskinen til RFC-791 og snakke om IP protokollerne:
INTERNET PROTOCOL
DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
September 1981
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
Wauuw, vi taler altså om protokoller som stammer fra de tidlige 1980'ere? Ja, selvom vi skifter vores gadgets i samme tempo som konen køber sko og tøj så bruger vi en oldgammel teknologi! - eller ok, måske ikke oldgammel, men så ihvertfald 25 år gammel da, som i internetår ER oldgammelt, men næppe er på radaren for en arkæolog. Til gengæld skal det måske bemærkes at IP erstattede en ældre protokol og hele historien om routere på internet generelt er spændende.
Personligt undersøgte jeg en masse dokumenter da jeg skrev mit speciale om IPv6, og det er fantastisk hvor holdbare ideerne omkring netværk og pakkekommunikation har vist sig at være. Nå lad os komme igang.
Hvad kendetegner internet idag, det er et fælles adresserum baseret på 32-bit adresser, og så et nyt adresserum på 128-bit (IPv6). Typisk skriver vi adresserne i dot-notation, dvs med 10.0.2.1 eller evt. med subnetmasken 10.0.2.1/24 - altså en subnetmaske på 24 bit=255.255.255.0. Faktisk er det underveje blevet besluttet at subnetmasker SKULLE være et antal 1-bit efterfulgt af 0-bit. Denne notation kaldes for CIDR notation, efter princippet om Classless Inter-Domain Routing. Men hov, det betyder jo at man har ændret IP undervejs?
Ja, IP protokollerne udvikles hele tiden, konservativt og langsomt med de eksisterende protokoller - men der sker en udvikling. Se bare på IPv6 hvorlænge den har været undervejs, selvom den i praksis vil lette en hel masse.
Godt, vi har altså IP som er en samling netværkprotokoller, hvor en af dem hedder IP som er karakteriseret ved:
- Best effort - pakkerne sendes ud på netværket og vi håber den kommer frem
- Uafhængigt af hardware som benyttes både netværket og systemerne vil være heterogene (smart!)
- Lagdelt - både i designet, der er flere lag - men også implementationen er typisk holdt adskilt
- Netværket antages at tabe pakker og end-to-end princippet er centralt.
Princippet med at opdele det komplekse problem giver god mening, og man kan løse problemerne uafhængigt. Ligeledes er det forudseende at man ikke forsøger at forudsige hvad der vil ske i al fremtid. Så med end-to-end princippet overlader man et stort arbejde til end-to-end protokoller. Tænk bare på HTTP som blev opfundet i 1990'erne. Ønsker man at læse mere om dette anbefales RFC-1958 Architectural Principles of the Internet fra 1996.
Så IP er altså både et sammensurium af protokoller og en protokol selv, og min favorittegning af dette er:
Tegningen viser lagdelingen og vi har talt om ARP og hardwarenære ting tidligere og idag er det så IP laget.
IPv4 pakken
Ser vi nu idag udelukkende på IP pakkernes headere (godt dansk ord headere ...) er der fra RFC-791 følgende oversigt, alle felter er big-endian, eller network byte order:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example Internet Datagram Header
Disse felter i pakken er således defineret og der er nogle interessante observationer:
Version er 4-bit og burde vel være 4? Jo, den er 4 - men det behøver man vel ikke checke? I version 6 er det ligeledes antaget at værdien ER 6, men det er ikke beskrevet at man skal checke dette ... pudsigt. Dette fik jeg forklaret af Radia Perlman på en konference.
Internet Header Length er naturligvis længden på pakken, antallet af 32-bit words i headeren.
Type of Service er interessant, selvom det har levet en kummerlig tilværelse i mange år er der kommet mere fokus på det i de senere år. Blandt andet revolutionen med IP telefoni, streaming af lyd og video giver et ønske om bedre kvalitet af internetforbindelserne.
Total length er hele pakkens længde i bytes, og bemærk af der kan ske fragmentering i IP - hvor en stor pakke opdeles i mindre, så modtageren kan godt risikere at få data over flere pakker - hvor fragmentation offset således ikke er 0. Når vi nu snakker om fragmenter kan vi angive at identification bruges til at identificere pakkerne - som de oprindeligt blev sendt. Tidligere blev dette IP ID felt blot talt een op for hver pakke - men dette kunne faktisk bruges til stealth scanning og de fleste implementationer er mere tilfældige idag.
Time to Live er en valgfri øvre grænse for levetiden for en IP pakke, som tælles ned på routere på vejen fra afsender til modtager. Hvis den når 0 smides pakken væk og der sendes en ICMP fejlbesked tilbage til afsenderen. Denne besked hedder ICMP time exceeded in-transit og udnyttes blandt andet af traceroute programmet. Traceroute er forøvrigt lidt af et hack udviklet af Van Jacobson omkring 1988.
Protocol er feltet der angiver næste protokol, dvs typiske værdier er ICMP protokol 1, TCP 6, UDP 17, samt IPsec protokollerne ESP 50 og AH 51 du kan finde en liste i /etc/protocols
Flags er et bit-felt der bruges som en del af fragmentering.
Various Control Flags. Bit 0: reserved, must be zero Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments.
En vigtig information her er at man med Dont Fragment kan angive at pakkerne IKKE må fragmenteres og det benyttes som en central del af Path MTU (PMTU), hvor man sender store pakker for at finde den største pakkestørrelse som der kan sendes fra en afsender til en modtager - for at undgå fragmenter. PMTU er noget man gerne vil have så man bør tillade ICMP svar tilbage på dette. Samlet set tillader jeg følgende icmptypes 3,4,11,12. Disse typer kan findes i manaul siden for icmp på OpenBSD:
- 3 unreach Destination unreachable
- 4 squench Packet loss, slow down
- 11 timex Time exceeded
- 12 paramprob Invalid IP header
Header checksum er en checksum på selve headeren. Denne checksum har vist sig at være problematisk, idet den skal udregnes for hver router på vejen i den tidskritiske løkke. Samtidig viser det sig at mange protokoller over og under IP udregner deres egne checksummer - og værdien var derfor til at overse. Header checksum er sparet væk i IPv6.
Source og Destination er naturligvis afsender og modtager - men der er jo ingen garantier for at det er den rigtige afsender, man kan således spoofe afsender adresser, hvorfor man har defineret IPsec OG gode internetudbydere bør implementere både ingress og egress filtering af trafik.
Hvorfor nu denne lange gennemgang af felter? Jo, der er nogle felter som er foruddefineret - SKAL bruges sådan og sådan. Men der er et antal felter som er mere valgfrie, eksempelvis TTL Time to live. Hvad er en god værdi for en TTL? og svaret er naturligt nok, stor nok til at kunne nå frem til modtageren :-) I visse operativsystemer, eksempelvis OpenBSD har man valgt værdien 255. Dvs den højeste værdi og derfor ved man med sikkerhed at en pakke med værdien 255 ikke har krydset nogen routere på vejen - enkelt og smart.
Når forskellige implementationer af IP således vælger forskelligt kan vi benytte dette til at identificere operativsystemerne som har sendt pakkerne. TTL feltet er et godt udgangspunkt og vi kan lave vores egen lille undersøgelse på værdierne:
- 64 Mac OS X, Linux, FreeBSD
- 128 Windows 2000
- 255 OpenBSD
Hmmm, det kunne tyde på at vi ikke alene ud fra TTL kan bestemme OS entydigt øv. Men der findes mange andre felter og der har været meget research indenfor dette område, blandt andet klassikeren "ICMP Usage In Scanning" af Ofir Arkin fra 2001. Siden dengang er der kommet flere værktøjer som forsøger at identificere operativsystemerne Xprobe/Xprobe2, p0f eller mit foretrukne værktøje Nmap.
OS detection
Så der findes altså programmer der kan se på pakkerne for os og gætte operativsystemet, med en vis usikkerhed.
hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.13 Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 14:52 CET Nmap scan report for 10.0.42.13 Host is up (0.0013s latency). Not shown: 99 closed ports PORT STATE SERVICE 80/tcp open http MAC Address: 00:00:AA:AB:9F:06 (Xerox) Device type: WAP|printer Running: Apple embedded, Canon embedded, Kyocera embedded, Xerox embedded OS details: VxWorks: Apple AirPort Extreme v5.7 or AirPort Express v6.3; Canon imageRUNNER printer (5055, C3045, C3380, or C5185); Kyocera FS-4020DN printer; or Xerox Phaser 8860MFP printer Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Det lyder sandsynligt at det er en Xerox enhed, eftersom MAC adressen også er registreret til Xerox. Note: og bemærk også at netop pakkerne som Nmap sender for at finde ud af OS ligeledes afslører at det er Nmap der forsøger dette :-) Lad os prøve en mere:
hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.5 Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 14:58 CET Nmap scan report for 10.0.42.5 Host is up (0.0054s latency). Not shown: 97 closed ports PORT STATE SERVICE 22/tcp open ssh 23/tcp open telnet 80/tcp open http MAC Address: 00:14:BF:60:19:A2 (Cisco-Linksys) Device type: switch Running: Linksys embedded OS details: Linksys SRW2000-series switch Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.95 seconds
Wauw - det passer perfekt, switchen er en ældre Linksys SRW-2008 switch, og her er en pointe - Nmap og de andre programmet slår op i tabeller for at identificere OS - og her er der åbenbart noget unikt fra Linksys SRW2000-series, hvor der for andre er mere usikkerhed. Specielt er der mange små embedded enheder som bruger Linux idag og de vil naturligvis ligne hinanden.
Med nogle operativsystemer får vi således ret præcise resultater:
hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.15 Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:00 CET Nmap scan report for 10.0.42.15 Host is up (0.0018s latency). Not shown: 97 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 88/tcp open kerberos-sec MAC Address: 00:16:CB:AC:1D:9F (Apple Computer) Device type: general purpose Running: Apple Mac OS X 10.5.X OS details: Apple Mac OS X 10.5 - 10.6 (Leopard - Snow Leopard) (Darwin 9.0.0b5 - 10.0.0) Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds
Mens andre ikke er med i de kendte fingerprints - min OpenBSD 4.6 eksempelvis:
hlk@bigfoot:hlk$ sudo nmap -O -p1-100 10.0.42.44 Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:02 CET Nmap scan report for turbi (10.0.42.44) Host is up (0.0011s latency). Not shown: 95 closed ports PORT STATE SERVICE 13/tcp open daytime 21/tcp open ftp 22/tcp open ssh 37/tcp open time 80/tcp open http MAC Address: 00:40:63:C9:F3:11 (VIA Technologies) No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=5.10BETA1%D=12/4%OT=13%CT=1%CU=41602%PV=Y%DS=1%DC=D%G=Y%M=004063% OS:TM=4B191674%P=i386-apple-darwin9.8.0)SEQ(SP=100%GCD=1%ISR=102%TI=RD%CI=R OS:I%II=RI%TS=22)SEQ(SP=105%GCD=1%ISR=10B%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=10 OS:5%GCD=1%ISR=107%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=108%GCD=1%ISR=107%TI=RD%C OS:I=RI%II=RI%TS=21)SEQ(SP=105%GCD=1%ISR=106%TI=RD%CI=RI%II=RI%TS=22)ECN(R= OS:Y%DF=Y%T=40%W=4000%O=M5B4NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%R OS:D=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y% OS:DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R% OS:O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=718F%RIPCK=G%R OS:UCK=G%RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=6ECD%RIPCK=G%RUCK=G% OS:RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=2E13%RIPCK=G%RUCK=G%RUD=G) OS:U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=15CA%RIPCK=G%RUCK=G%RUD=G)U1(R=Y OS:%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=A8E0%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=S OS:%T=FF%CD=S) Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.59 seconds
Usikkerheden bliver ligeledes forværret hvis der ikke modtages svar fra både åbne og lukkede porte. Over internet vil det således ofte være sværere at bruge dette alene til at identificere OS. I disse tilfælde vil man bruger Nmap eller telnet til at interagere med portene - og det kan Nmap gøre med -A option.
hlk@bigfoot:hlk$ sudo nmap -A -p1-100 10.0.42.44 Starting Nmap 5.10BETA1 ( http://nmap.org ) at 2009-12-04 15:05 CET Warning: Unable to open interface vmnet1 -- skipping it. Warning: Unable to open interface vmnet8 -- skipping it. Nmap scan report for turbi (10.0.42.44) Host is up (0.0014s latency). Not shown: 95 closed ports PORT STATE SERVICE VERSION 13/tcp open daytime 21/tcp open ftp bsd-ftpd 22/tcp open ssh OpenSSH 5.3 (protocol 2.0) | ssh-hostkey: 1024 4b:8d:0c:ed:33:ce:39:bd:75:89:b1:b1:e8:15:86:b4 (DSA) |_ 2048 45:38:a1:8e:ab:e1:f9:b3:d7:c7:11:00:37:41:6c:55 (RSA) 37/tcp open time (32 bits) 80/tcp open http Apache httpd |_ html-title: Test Page for Apache Installation MAC Address: 00:40:63:C9:F3:11 (VIA Technologies) No exact OS matches for host (If you know what OS is running on it, see http://nmap.org/submit/ ). TCP/IP fingerprint: OS:SCAN(V=5.10BETA1%D=12/4%OT=13%CT=1%CU=40390%PV=Y%DS=1%DC=D%G=Y%M=004063% OS:TM=4B191761%P=i386-apple-darwin9.8.0)SEQ(SP=105%GCD=1%ISR=10E%TI=RD%CI=R OS:I%II=RI%TS=21)SEQ(SP=103%GCD=1%ISR=10D%TI=RD%CI=RI%II=RI%TS=21)SEQ(SP=10 OS:8%GCD=3%ISR=10D%TI=RD%CI=RI%II=RI%TS=22)SEQ(SP=FF%GCD=1%ISR=109%TI=RD%CI OS:=RI%II=RI%TS=21)SEQ(SP=108%GCD=1%ISR=108%TI=RD%CI=RI%II=RI%TS=21)ECN(R=Y OS:%DF=Y%T=40%W=4000%O=M5B4NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD OS:=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%D OS:F=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O OS:=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=476C%RIPCK=G%RU OS:CK=G%RUD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=338B%RIPCK=G%RUCK=G%R OS:UD=G)U1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=37D3%RIPCK=G%RUCK=G%RUD=G)U OS:1(R=Y%DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=BC2B%RIPCK=G%RUCK=G%RUD=G)U1(R=Y% OS:DF=N%T=FF%IPL=38%UN=0%RIPL=G%RID=67C7%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=S% OS:T=FF%CD=S) Network Distance: 1 hop Service Info: Host: localhost.kramse.org; OS: Linux HOP RTT ADDRESS 1 1.35 ms turbi (10.0.42.44) OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 29.38 seconds
Bemærk at dette stadig ikke finder OS med OS detection, men at bsd-ftpd og OpenSSH 5.3 tyder på en BSD maskine og mange ved at OpenBSD (uvist af hvilken grund) stadig har port 37 åben som standard. En tur til http://10.0.42.44 viser da også en default side for OpenBSD med logo og det hele :-)
Konklusion
Hvad er så konklusionen på ovenstående?
Jo den er, at der er en stor grad af valgfrihed og derfor er Operativsystemer forskellige på IP niveau. Dette kan bruges til at detektere operativsystemer relativt præcist, og indimellem helt ned til release, kerneniveau eller service pack.
Hvad man så vil bruge den viden til er op til en selv, men det er meget sandsynligt at en angriber over internet vil kunne skræddersy et angreb bedre med den viden :-)
Posted by at CET 13:12 04/12/2009 in Toolbox entries
[Trackback URL for this entry]
