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"

Her er en annen utfordring å teste litt wienie ferdigheter:

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. Ganske enkelt, ikke sant? Hvis du ikke har prøvd det, du kommer til å finne at tcpdump / Windump kaster noen kurver på deg.

For å sjekke arbeidet ditt, her er en fange fil:

IPv6-ICMP

Filen inneholder en blanding av kilde IPv6-adresser. Tydeligvis filteret skal bare vise det angitte området av adresser.

Vinneren får å inspirere ærefrykt og beundring i mindre geeks.

Hvis denne utfordringen virket vanskeligere enn det burde være, er du på rett spor.

Jeg kjørte over dette problemet ved å skrive min Packet Dekode verktøyet. Jeg må si, det var en kul øvelse for meg, som jeg egentlig aldri tenkt på å lage tcpdump og wireshark filtre for alle mulige IP, TCP, UDP og ICMP felt og / eller verdi. Den klart TCP alternativene feltet er det mest "brutt" fra en pakke dekode perspektiv enn noen annen IP-feltet.

Først la oss snakke om hvordan TCP alternativene burde vært gjennomført. Hvis du ser på IPv4 alternativene feltet, begynner det med en "Type" identifikator. Hvis du er interessert i en bestemt IP-alternativet, er det bare et spørsmål om å sjekke dette feltet for retten bit kombinasjonen. Hadde TCP alternativene er gjennomført på denne måten, ville denne utfordringen har vært ganske rett frem.

Omtrent alle TCP alternativer har en "Kind" og en "Length" feltet, som begge er en byte i størrelse. Unntakene er "End of Option List" og "No-Operation" som bare har en slags felt, og dermed er en byte i størrelse. Her er en liste over vanlige TCP alternativer:

Side 15 av RFC 793 forteller oss "The TCP header (selv en inkludert opsjoner) er en integrert antall 32 bits lang." Med andre ord må TCP header størrelsen i byte være delelig med fire (20 byte, 24 bytes, etc.). Hvis du ser på listen over TCP alternativer, bare "Maximum Segment Size" er delelig med fire. Så bruk av noen andre alternativer kommer til å kreve padding.

Hvordan padding bør påføres er litt uklart. Hvis vi ser på side 26 av RFC 1323 finner vi dette:

  VEDLEGG A: GJENNOMFØRING FORSLAG

    Følgende oppsett er anbefalt for sendingsvalg på ikke-SYN
    segmenter, for å oppnå maksimal mulig justering av 32-bit og 64-bit
    maskiner.

        +--------+--------+--------+--------+
        | NOP ​​| NOP ​​| TSopt | 10 |
        +--------+--------+--------+--------+
        | TSval timestamp |
        +--------+--------+--------+--------+
        | TSecr timestamp |
        +--------+--------+--------+--------+ 

Legg merke til NOP padding vises før timestamp alternativet, ikke på slutten som du kanskje forventer. Legg også merke til RFC sier spesifikt dette er for "non-SYN segmenter", og at det er "anbefalt", ikke nødvendig. Synes imidlertid at de fleste operativsystemer følger denne anbefalingen og alltid plass padding før Kind og Lengde bytes. Jeg har sjekket Windows, Linux, Mac, diverse hardware, osv., og de alle sette padding i begynnelsen.

Så vi kan regne med at dette er den "standard", ikke sant? Ikke helt. Side 17 av RFC 793 beskriver NOP på denne måten:

  Dette alternativet koden kan brukes mellom alternativer, for eksempel til
         justere begynnelsen av påfølgende opsjon på et ord grense.
         Det er ingen garanti for at avsenderne vil bruke dette alternativet, så
         mottakere må være forberedt på å behandle alternativer selv om de gjør
         ikke begynne på et ord grense. 

Med andre ord, det er ikke bare at NOP kan eller ikke kan vise opp på begynnelsen kan NOP ikke brukes i det hele tatt! Det er helt lovlig å layout TCP alternativet feltet uten NOP polstring og bare bruke End of Option List som fyllstoff på slutten for å oppnå riktig grense.

Så hva ender vi opp med et filter? Hvis vi regner på NOP før valget vi ender opp med et filter som ser slik ut:

tcp [13] og 2 = 2 og tcp [12] og 240> 80 og ((tcp [20] = 1 og tcp [21:02] = 0 × 0303) eller (tcp [24] = 1 og tcp [25:2 ] = 0 × 0303) eller (tcp [28] = 1 og tcp [29:2] = 0 × 0303) eller (tcp [32] = 1 og tcp [33:2] = 0 × 0303) eller (tcp [ 36] = 1 og tcp [37:2] = 0 × 0303) eller (tcp [40] = 1 og tcp [41:2] = 0 × 0303) eller (tcp [44] = 1 og tcp [45:2 ] = 0 × 0303) eller (tcp [48] = 1 og tcp [49:2] = 0 × 0303) eller (tcp [52] = 1 og tcp [53:2] = 0 × 0303) eller (tcp [ 56] = 1 og tcp [57:2] = 0 × 0303))

Å bryte ned hva dette filteret gjør:

• Bare sjekke SYN & SYN / ACK pakker: tcp [13] og 2 = 2
• TCP header er større enn 20 bytes (alternativer er satt): tcp [12] og 240> 80
• Sjekk den første byte i hver fire byte grense for NOP: tcp [20] = 1, tcp [24 = 1, ...
• Sjekk de to neste byte for å se om Kind = 3 og Lengde = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Hvis derimot vi ønsker å sikre at vi fange alle muligheter i tilfelle et system som ikke gjennomfører NOP vi ender opp med:

tcp [13] og 2 = 2 og tcp [12] og 240> 80 og (tcp [20:02] = 0 × 0303 eller tcp [21:02] = 0 × 0303 eller tcp [22:02] = 0 × 0303 eller tcp [23:02] = 0 × 0303 eller tcp [24:2] = 0 × 0303 eller tcp [25:2] = 0 × 0303 eller tcp [26:2] = 0 × 0303 eller tcp [27:2] = 0 × 0303 eller tcp [28:2] = 0 × 0303 eller tcp [29:2] = 0 × 0303 eller tcp [30:2] = 0 × 0303 eller tcp [31:2] = 0 × 0303 eller tcp [32:2] = 0 × 0303 eller tcp [33:2] = 0 × 0303 eller tcp [34:2] = 0 × 0303 eller tcp [35:2] = 0 × 0303 eller tcp [36:2] = 0 × 0303 eller tcp [37:2] = 0 × 0303 eller tcp [38:2] = 0 × 0303 eller tcp [39:2] = 0 × 0303 eller tcp [40:2] = 0 × 0303 eller tcp [ 41:2] = 0 × 0303 eller tcp [42:2] = 0 × 0303 eller tcp [43:2] = 0 × 0303 eller tcp [44:2] = 0 × 0303 eller tcp [45:2] = 0 × 0303 eller tcp [46:2] = 0 × 0303 eller tcp [47:2] = 0 × 0303 eller tcp [48:2] = 0 × 0303 eller tcp [49:2] = 0 × 0303 eller tcp [50 : 2] = 0 × 0303 eller tcp [51:2] = 0 × 0303 eller tcp [52:2] = 0 × 0303 eller tcp [53:2] = 0 × 0303 eller tcp [54:2] = 0 × 0303 eller tcp [55:2] = 0 × 0303 eller tcp [56:2] = 0 × 0303 eller tcp [57:2] = 0 × 0303 eller tcp [58:2] = 0 × 0303)

Forskjellen med dette filteret er at vi sjekker Kind = 3 og Lengde = 3 hele veien gjennom alternativene feltet (som Elizabeth foreslått).

Kan noen av disse filtrene generere falske positiver? Absolutt! To muligheter:

1. Verdien av Tidsstempel kan matche det mønsteret vi leter etter.
2. Filteret forutsetter en 40 byte alternativ feltet. Det kan være mindre med disse verdiene i nyttelasten.

Så hvilke filter bør du bruke? Den første vil generere færre falske positiver, men savner systemer som er RFC-kompatibel, men forskjellig fra normen. Det andre vil alltid fange Vindu Scale om det har blitt satt, men sjansen for en falsk positiv er høyere.

Jeg kommer til å utpeke Elizabeth som vinner av utfordringen. Et par andre ble like tett, men hun var den eneste med guts til å legge sin tankerekke i kommentarfeltet. Jeg kommer til å utdele en andrepris til Jeff som kom opp med denne løsningen delvis tuller rundt:

tcpdump-nn | grep 'wscale'> wscale-matches.txt

Dette vil ikke generere en faktisk pakke fange, men du kunne gjøre en:

tcpdump-nn-X-s 0 | grep 'wscale'> wscale-matches.txt

Og deretter kjøre ut gjennom txt2cap å få det tilbake i pcap format. Han fulgte ikke utfordringen spesifikt, men du har må gi kudos for å tenke utenfor boksen da dette fikser alle falske positive saker.

Elizabeth og Jeff, vil jeg kontakte deg både via e-post. Gratulerer!

Jeg har hatt en tråd post og fire e-poster som er soooooo nær det riktige svaret. Her er en siste holdepunkt for å forhåpentligvis få folk over det siste hinderet.

Jeg nevnte den hjelpsomme tshark kommandoen. Her er output:

C: \ testing> tshark-n-r linux-syn.cap-T felt-e tcp.options
02:04:05: b4: 04:02:08:0 a: 02:47:04 a: A8: 00:00:00:00:01:03:03:05

Så hva du har ovenfor er det TCP alternativene delen (byte 20 og høyere) av testen pakken. The Window Scale alternativet er det siste alternativet i listen.

Jeg vet skriver dette filteret er ikke lett. Faktisk det er derfor jeg snudde det til en utfordring. Det er mulig likevel.