Utfordringen var: "Skriv en tcpdump / windump filter som skal fange ICMPv6 Multicast Listener pakker." Jeg har en omfattende skrive opp hva som gjør svaret så komplisert. Hvis du vet IPv6 og bare vil 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, det høres virkelig rotete", forstår du omfanget av problemet også.

Protokoll Vs. Neste Header Felt

Med IPv4 hadde vi alternativene feltet. Dette kan føre til at IP header å vokse fra 20 byte til så stor som 60 byte i størrelse. Med IPv6, er det ikke lenger ett valg feltet og header er satt til 40 byte i størrelse. Når alternativene er nødvendig, bruker vi forlengelse overskrifter for å identifisere dem. Dette kaster en interessant kurve ball på oss fordi med IPv4 protokollen feltet (byte 9) ville (nesten) alltid identifisere øverste nivå transport (TCP, UDP, etc.). Med IPv6 den 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 extension overskrifter du kan kjøre inn, samt RFCene som definerer dem:

IPv6 begrenser ikke antallet forlengelsen 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 vert må være i stand til å behandle de overskriftene i hva noensinne rekkefølge de ble mottatt. Dette betyr at du vil sannsynligvis finne leverandører følger denne listen, men ikke angripere. Jeg har personlig sett enheter begynne å handle egentlig merkelig når du rotet med overskriften orden. Faktisk har jeg kjørt over ganske mye av "IPv6 kompatibel kode" som ikke kan håndtere hvis foretrukket rekkefølge ikke brukes.

Chasing Protokollen Topptekst

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. Disse ble faktisk lånt fra IPv6 og masserte å jobbe med IPv4. Både AH og ESP er et neste header feltet for å identifisere hvilken type pakke de er protecting.This kalles protokoll kjeding, som du effektivt har flere hoder som sitter bak laget tre 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 omtales 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

At filter leser "sjekk byte 9 av IPv4 header og hvis verdien er lik 6 (protokoll verdi for TCP), samsvarer på pakken". Dette filteret er ikke like effektiv i IPv6 verden av kurset fordi byte 6 av IPv6 header kan identifisere det øvre laget 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 felt til en verdi av seks. Dersom du finner flere valgfrie forlengelse overskrifter, terpe den siste testen til du finner den siste utvidelsen overskriften ".

Ganske enkelt å skrive på engelsk, men dette er et mareritt å gjennomføre i koden. De fleste valgfrie forlengelse hodene er variabel i 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 med dosering en IDS / IPS ved å tvinge den til å behandle en masse unyttige forlengelse overskrifter.

Skrive vår filter

Så vårt første problem i skriftlig utfordringen filteret er at ICMPv6 overskriften ikke kan dukke opp etter IPv6 header. Vi må se opp for valgfrie forlengelse overskrifter. Faktisk RFC 2710 heter det: "Alle MLD meldinger beskrevet i dette dokumentet er sendt med en link-lokal IPv6 Source Address, en IPv6 Hop Limit av en, og en IPv6-ruter Alert alternativet [RTR-ALERT] i en Hop-by-Hop Alternativer header. "Dette betyr at vår multicast lytteren pakke er nødvendig for å ha en Hop-by-Hop utvidelse header med ruteren Alert alternativet sett. Med dette i tankene, bør vår første sjekk være:

IP6 protochain icmp6

For å sikre at vi bare ser på ICMPv6 pakker. Nå er det bare et spørsmål om å kontrollere om den type 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 en:

ICMP [0] = <type verdi av interest>

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

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

Med andre ord, kan jeg 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 må 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 overskriften 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 ruteren Alert satt
• Den type feltet er byte 0 innenfor ICMPv6 header

Så her er hva vi ender opp med:

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

Puh! Vi fikk endelig 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 Router Alert?

A: Vårt filter vil ikke fungere.

Spørsmål: Kan vi fikse de to ovennevnte problemene?

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

Så hvis vi ønsker å fange normal ML trafikk, vil ovennevnte filteret fungerer fint. Hvis derimot vi ønsker å forsikre vi fange angriper trickiness også, er ikke filteret 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 sin text2cap verktøy for å konvertere den til Libpcap format? Problemet her er vi bare få overskriften info. Grep vil matche resultatlinjen som inneholder ordet "Multicast", men så hopper alle Hex under det som er det faktiske innholdet i pakken.

Så det endelige svaret er: "Kan ikke få de? Fra Haya"

Så hva om du virkelig trenger å være i stand til å se denne trafikken? Inntil støtte for IPv6 modnes, er den eneste 100% metode for å fange all ICMPv6 trafikk og deretter manuelt sortere gjennom det.

I alle fall mitt syn på dette. Hvis noen kan faktisk komme opp med en 100% arbeidende løsning, ville jeg gjerne høre det.

Relaterte innlegg:

1. Weekend Challenge - svar
2. ICMPv6 Challenge - Hints
3. ICMPv6 Challenge
4. Weekend Challenge
5. Weekend Challenge - Tips

• Previous Entry: IP Lookup Fullført
• Next Entry: WinHelp 1,0 Utgitt