Utfordringen var: "Skriv en tcpdump / windump filter som vil fange ICMPv6 Multicast Listener pakker." Jeg har et omfattende skriv opp hva som gjør svaret så komplisert. Hvis du vet IPv6 og bare vil ha svaret, hoppe til slutten.

Først litt bakgrunnsinformasjon

Steinar gjort noen kommentarer til tidligere innlegg, og var 100% på sporet. Hvis du leser dem og tenkte "Wow, lyder som virkelig rotete", du forstår omfanget av problemet også.

Protokoll Vs. Next Header feltet

Med IPv4 hadde vi alternativene feltet. Dette kan føre til at IP header å vokse fra 20 byte til så store som 60 byte i størrelse. Med IPv6, er det ikke lenger ett alternativer feltet, og header er fast på 40 byte i størrelse. Når alternativene er nødvendig, bruker vi utvidelse overskrifter for å identifisere dem. Dette kaster et interessant kurve ball på oss fordi med IPv4-protokollen feltet (byte 9) ville (nesten) alltid identifisere den øverste nivået transport (TCP, UDP, etc.). Med IPv6 det neste header feltet (byte 6) kan identifisere det øvre laget transport, eller det kan identifisere en forlengelse header som vil inkludere noen flere alternativer.

Her er en liste over noen IPv6 forlengelse overskrifter du kan kjøre inn, samt RFCene som definerer dem:

IPv6 begrenser ikke antallet forlengelse overskrifter du kan bruke i en enkelt packet.There er imidlertid en publisert "anbefalt rekkefølge" om hvordan overskriftene skal legges ut. Rekkefølgen er:

• IPv6 Header
• Hop-by-Hop Options
• Routing Header
• Fragment Header
• AH
• ESP
• Destination Options
• Mobilitet Header
• TCP/UDP/ICMPv6

Merk denne listen er "anbefalt", men ikke obligatorisk. En IPv6-host må være i stand til å behandle overskriftene i hva noensinne rekkefølgen de ble mottatt. Dette betyr at du vil sannsynligvis finne leverandørene følge denne listen, men ikke angripere. Jeg har personlig sett enheter begynne å handle egentlig merkelig når du rotet med header orden. Faktisk har jeg kjørt over ganske mye "IPv6 kompatibel kode" som ikke kan håndtere hvis foretrukket rekkefølge ikke brukes.

Chasing Protokollen Header

Så med IPv6 kan vi ha flere hoder bak IPv6 header. Hvis dette høres ut som et nytt konsept, er det faktisk ikke. Faktisk har du sannsynligvis jobbet med det allerede. Når du distribuerer IPSec de to mulige sikkerhetsprotokoller er ESP og AH. Dette var faktisk lånt fra IPv6 og massert å jobbe med IPv4. Både AH og ESP inkluderer en neste header feltet for å identifisere hvilken type pakke de er protecting.This kalles protokoll kjeding, som du effektivt har flere hoder sitter bak lag 3 protokollen header.

Så for å finne ut hva øvre nivå transport (TCP, UDP, etc.) blir brukt, må du søke gjennom flere hoder før du finner svaret. Dette er referert til som "jage overskriften", og tcpdump / Windump gi oss et filter alternativet for å utføre denne oppgaven. Du kan være fimiliar med proto filter. I IPv4 verden, hvis jeg sier:

ip proto tcp

Som filtrerer leser "check byte 9 IPv4 header og hvis verdien er lik 6 (protokoll verdi for TCP), match på pakken". Dette filteret er ikke like effektiv i IPv6 verden selvsagt, fordi byte 6 i IPv6 header kunne identifisere de øvre lag transport, eller det kan bare identifisere en valgfri forlengelse header som blir brukt. For å løse dette problemet, ble protochain filteret innført. Writing:

ip6 protochain tcp

Leser som "Check byte 6 i IPv6 header for å se om verdien er lik seks. Hvis stedet du finner en verdi som identifiserer en valgfri forlengelse header, sjekk forlengelsen header neste header feltet til en verdi av seks. Hvis du finner flere valgfri forlengelse overskrifter, terpe den siste testen til du finner den siste forlengelsen header ".

Ganske enkelt å skrive på engelsk, men dette er et mareritt å gjennomføre i kode. De fleste valgfri utvidelse overskrifter er variabel lengde som bare legger til kompleksitet. Jeg har gjort noen tester med Scapy og du kan faktisk se forskjellen i ytelse når protochain blir påkalt. Faktisk kan du sannsynligvis gjøre en ganske god jobb dosering en IDS / IPS ved å tvinge den til å behandle en masse ubrukelig forlengelse overskrifter.

Skrive våre filter

Så vårt første problem skriftlig utfordringen filteret er at ICMPv6 header ikke kan vises rett etter IPv6 header. Vi må se opp for valgfri forlengelse overskrifter. Faktisk RFC 2710 heter det: "All MLD meldinger beskrevet i dette dokumentet er sendt med en link-local IPv6 Source Address, en IPv6 Hop Limit på 1, og en IPv6-ruter Alert alternativet [RTR-ALERT] i en Hop-by-Hop Alternativer header. "Dette betyr at våre multicast lytteren pakke er pålagt å ha et Hop-by-Hop forlengelse header med ruteren Alert alternativet satt. Med dette i tankene, bør vi først sjekke være:

ip6 protochain icmp6

For å sikre at vi kun ser på ICMPv6 pakker. Nå er det bare et spørsmål om å sjekke for å se om den typen felt (byte 0) er satt til 130 (Multicast Listener Query) eller 131 (Multicast Listener Report). Dette bringer oss til vårt andre problem likevel. I IPv4 verden kan jeg gjøre:

icmp [0] = <Skriv verdien av interest>

Hvis jeg prøver dette med icmp6 jeg får:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 øvre lag protokollen støttes ikke av proto [x]

Med andre ord, jeg kan ikke bruke forskyvninger med icmp6 å søke etter bestemte verdier. Windump og tcpdump er annonsert som IPv6 kompatibel, men ikke forvent å få alle de samme funksjonene du har med IPv4. Yuck!

Så hva gjør vi? Vi blir nødt til å falle tilbake på refererer verdien fra en ip6 offset. Med andre ord, må vi måle gjennom IPv6 header, gjennom den nødvendige Hop-by-Hop header, og inn i ICMPv6 header for å se om den type feltet er satt til 130 eller 131. Noen ting å ta hensyn til:

• IPv6 header er fast på 40 byte i størrelse
• Hop-by-Hop header er variabel, men 4 byte med Ruter Alert satt
• Den type feltet er byte 0 innen ICMPv6 header

Så her er hva vi ender opp med:

ip6 protochain icmp6 og (ip6 [44] = 130 eller ip6 [44] = 131)

Puh! Vi endelig fikk det! Eller gjorde vi?

Q: Hva skjer hvis pakken har ytterligere forlengelse overskrifter?

A: Vårt filter vil ikke fungere.

Q: Hva hvis Hop-by-Hop header har flere alternativer satt enn Ruter Alert?

A: Vårt filter vil ikke fungere.

Q: Kan vi fikse det over to problemene?

A: Ikke før tcpdump / Windump filtrering legger IF / THEN sløyfe støtte.

Så hvis vi ønsker å fange normal ML trafikk, vil ovennevnte filteret fungere fint. Hvis derimot vi ønsker å forsikre vi fange angriper trickiness også, er filteret ikke kommer til å fly.

Hva om vi prøver noe sånt som dette:

tcpdump-nn-s 1500-x ip6 protochain icmp6 | grep-i multicast> multicast.txt

og så bare bruke wireshark er text2cap verktøy for å konvertere den til Libpcap format? Problemet her er at vi vil bare få overskriften info. Grep vil matche resultatlinjen som inneholder ordet "Multicast", men da hopper alle Hex under det som er det faktiske innholdet i pakken.

Så det endelige svaret er: "Kan ikke få theya fra Haya"

Så hva om du virkelig trenger å kunne se denne trafikken? Inntil støtte for IPv6 modnes, er den eneste 100% metode for å fange alle ICMPv6 trafikk og deretter manuelt sortere gjennom det.

Minst det er mitt syn på dette. Hvis noen kan faktisk komme opp med en 100% arbeider løsning, ville jeg gjerne høre det.

OK, her er et hint til å peke deg i riktig retning.

Utfordringen var: "Skriv en tcpdump / windump filter som vil fange ICMPv6 Multicast Listener pakker."

Høres enkelt, ikke sant?

Med litt hjelp fra Google vil du finne at "type" for Multicast lytteren er 130, og ICMPv6 typefeltet er første byte i overskriften. Så dette bør være så enkelt som:

tcpdump-nn-p-v-s 0 icmp6 [0] = 130

men hvis du kjører kommandoen du får tilbake:

tcpdump: IPv6 øvre lag protokollen støttes ikke av proto [x]

Med andre ord kan du bruke "icmp6" for å se alle ICMPv6 pakker, men du kan ikke bruke den til å filtrere på noen av de ICMPv6 header feltene.

Så vi trenger en "Plan B". Figur ut plan B, og du har løst utfordringen.

Bygge på IPv6 utfordringen fra forrige gang, har jeg et nytt til deg: Skriv en tcpdump / windump filter som skal fange ICMPv6 Multicast Listener pakker.

Det er det! Ganske enkelt, ikke sant?

Vel sin nå torsdag så jeg tenkte det tid for å legge ut svarene på forrige helgs utfordring.

Først, hvorfor skulle du selv bryr deg om IPv6 hvis du ikke har startet distribusjon av det? Jeg følte mye på samme måten til jeg fant IPv6 brukes som en hemmelig kommunikasjonskanal innenfor klientens nettverk. Dataene ble deretter blir skjøvet ut til Internett via Teredo. Hvis du ikke er fortrolig med teknikken, har Scott Hogg noen gode innlegg om emnet.

Så selv om du ikke bruker IPv6, lønner det seg å begynne å kutte kur på teknologien, så vel som å se etter den på ditt lokale nettverk.

Så for å gjennomgå, var utfordringen:

Skriv en tcpdump eller Windump filter som vil fange opp all trafikk med en kilde IPv6 adresse 2001: DB8:: 10 til og med 2001: DB8:: 20.

Det er et par begrensninger med å skrive dette filteret. De første jeg dekket i det siste innlegget. Den siste, som jeg visste, men aldri egentlig trodde var et problem før jeg begynte å jobbe med IPv6 ganske tungt, er at tcpdump / Windump vil bare la deg bruke 1, 2 eller 4 byte masker. Så mens vi ville elske å løse dette med en innledende filter uttalelse av "ip6 [08:14] =", kan vi ikke fordi vi er begrenset til fire byte. Det er faktisk en måte å komme rundt dette, men jeg skal komme tilbake til det.

Så her er det filteret jeg har jobbet med:

(Ip6 [08:04] = 0x20010db8 og ip6 [12:04] = 0 og ip6 [16:04] = 0 og (ip6 [20:04]> = 0 × 0010 og ip6 [20:04] <= 0050 ))

Litt lang, men det fungerer. Elizabeth kom opp med en løsning som er langt mer elegant enn min egen:

src net 2001: DB8:: / 122 og ip6 [23]> = 0 × 10 & & ip6 [23] <= 0 × 20

Så ved å starte med Libpcap format, er hun i stand til å kombinere mine tre første uttalelser til én. Ikke for å være en størrelse dronning, men som gjør henne løsningen er mye kortere enn mine. I dette tilfellet det er en god ting.

Det er omtrent det. Jeg skal legge en annen IPv6 typen utfordring i morgen.

Wow, er lyden av sirisser øredøvende. Sikkert noen som har kompetanse til å komme oss gjennom dette dilemmaet?

OK, noen hint komme deg gjennom utfordringen. La oss starte med å løse dette som en IPv4-adresse, og så får vi jobber oss inn i IPv6. Anta at adressen serien vi ønsker å fange er 192.168.1.10 - 192.168.1.20. Det store problemet er at IP ikke er på en enda byte grense. Vi kunne gjøre noe sånt som:

src net 192.168.1.0/27

men det ville gi oss adressene 0,0 til 0.31, mer IP enn vi egentlig ønsket å se. For å løse dette problemet vi må bruke noen operatører og primitive. En mulighet er:

(Ip [12] = 192 og ip [13] = 168 og ip [14] = 1 og (ip [15]> = 10 og ip [15] <= 20))

Fra og med den indre mest brakettene, leser ovennevnte uttalelse "byte 15 må være større enn eller lik 10, men det må også være mindre enn eller lik 20. Hvis dette utsagnet er sant, sørg byte 12 er lik 192, er byte 13 lik 168 og byte 14 er lik 1 ".

Kan vi forkorte dette uttrykket? Absolutt! Først må vi konvertere den til Hex likevel. Hvorfor Hex? Hvis jeg skriver en uttalelse som "ip [12:02] =" tcpdump vil anta at resultatet vil bli en 16-biters tall, ikke to 8-bit tall. Dette er grunnen til at du kan skrive noe sånt som "tcp [02:02] = 12345", og arbeid det har. tcpdump konverterer to bytes i en 16-bits verdi og matcher den mot den verdien du har angitt. Ved å konvertere til Hex unngår vi dette problemet. Slik:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Nå har vi rett og slett skrive uttrykk:

ip [12:04]> = 0xC0A8010A og ip [12:04] <= 0xC0A80120

Det er alt som skal til.

Mens IPv4 bruker 4 byte-adresser, bruker IPv6 16 byte. Fordi adresser er så lenge, skriver vi dem i Hex å spare litt plass. Så adressene jeg ga deg i utfordringen var:

2001:0 DB8: 0000:0000:0000:0000:0000:0010

2001:0 DB8: 0000:0000:0000:0000:0000:0020

Merker jeg ikke i utgangspunktet skrive dem på den måten. Det finnes noen konvensjoner du kan bruke for å spare plass når du skriver en IPv6-adresse. Først kan vi avkorte ledende nuller. Slik:

2001:0 DB8: 0000:0000:0000:0000:0000:0010

blir:

2001: DB8: 0000:0000:0000:0000:0000:10

Nå, se alle de som nuller i midten? Vi kan hogge dem ut også. Når du ser ":" som betyr å fylle i det rommet med nok nuller til å utvide den adressen ut igjen til 16 bytes. Så legg i dette trikset så godt og vi får:

2001: DB8:: 10

Langt enklere å skrive. Det forbeholdet er at du kan bare fjerne en gruppe av nuller med den doble kolon trick. Tenk på følgende adresse:

2001:: 1234:: 10

Vi har ingen anelse hvor du vil plassere byte-sekvens "1234" i adressen. Det begynner alt fra byte 6 til byte 12.

Når du arbeider med IPv4, tcpdump og Windump bruke protokollen søkeordet "ip", som vist i eksemplene ovenfor. IPv6 kompliment til som er "ip6". Hvor er kilden adresse feltet i IPv6 header? Vel jeg kan ikke gi dere alle der svarene eller det er ikke lenger en "utfordring"