Utmaningen var: "Skriv en tcpdump / windump filter som kommer att fånga ICMPv6 Multicast Listener paket." Jag har en omfattande skriva upp vad som gör svaret så komplex. Om du känner till IPv6 och bara vill ha svaret, hoppa till slutet.

Först några Bakgrund

Steinar gjort en del kommentarer till tidigare inlägg och var 100% på rätt spår. Om du läser dem och tänkte "Wow, det låter som verkligen stökigt", förstår du omfattningen av problemet också.

Protokoll Vs. Nästa Header Field

Med IPv4 hade vi alternativen fältet. Detta kan leda till att IP-huvudet att växa från 20 byte till så stora som 60 byte i storlek. Med IPv6, finns det inte längre ett alternativ fält och rubriken är fastställt till 40 bytes i storlek. När alternativ behövs, använder vi förlängning rubriker att identifiera dem. Detta kastar ett intressant kurva boll på oss eftersom med IPv4-protokollet fältet (byte 9) skulle (nästan) alltid identifiera det övre planet transporter (TCP, UDP, etc.). Med IPv6 nästa rubrikfältet (byte 6) kan identifiera det övre lagret transporten, eller det kan identifiera en förlängning header som kommer att omfatta ett visst antal alternativ.

Här är en lista över några IPv6 förlängning rubriker du kan stöta på, liksom den RFC som definierar dem:

IPv6 inte begränsa antalet anknytning rubriker du kan använda i en enda packet.There är dock en publicerad "rekommenderade ordningen" om hur rubriker ska läggas ut. Ordern är:

• IPv6-Header
• Hop-för-Hop Alternativ
• Routing Header
• Fragment Header
• AH
• ESP
• Destination Options
• Mobility Header
• TCP/UDP/ICMPv6

Observera att denna lista är "rekommenderade", men inte obligatoriskt. En IPv6-värd måste kunna bearbeta headers i vad någonsin ordning de mottogs. Detta innebär att du förmodligen kommer att finna leverantörer efter denna lista, men inte angripare. Jag har personligen sett enheter börja agera väldigt konstigt när du bråka med huvudet ordning. Faktum är att jag har stött på en hel del "IPv6-kompatibla kod" som inte kan hantera om önskad ordning inte används.

Chasing Protokollet Header

Så med IPv6 kan vi ha flera rubriker bakom IPv6-header. Om detta låter som ett nytt koncept, är det faktiskt inte. Faktum är att du har säkert jobbat med det redan. När du distribuerar IPSec de två möjliga säkerhet protokoll är ESP och AH. Dessa var faktiskt lånat från IPv6 och masseras att arbeta med IPv4. Både AH och ESP ingår ett nästa rubrikfältet för att identifiera vilken typ av paket det är protecting.This kallas protokoll kedja, som du faktiskt har flera huvuden sitter bakom lager 3-protokoll header.

Så för att räkna ut vad övre planet transporter (TCP, UDP, etc.) används, kan du behöva söka igenom flera rubriker innan du hitta svaret. Detta kallas "jaga huvudet", och tcpdump / Windump ge oss ett filter möjlighet att utföra denna uppgift. Du kan bli fimiliar med proto filtret. I IPv4-världen, om jag säger:

IP-proto tcp

Som filtrerar lyder "kontrollera byte 9 i IPv4-huvudet och om värdet är lika med 6 (protokoll värde för TCP), match på paketet". Detta filter är inte lika effektiva i IPv6 världen naturligtvis på grund byte 6 i IPv6-huvudet kan identifiera det övre lagret transport, eller det kanske bara hitta en frivillig förlängning rubrik som används. För att lösa detta problem var protochain filtret infördes. Skriva:

ip6 protochain tcp

Läser som "Kontrollera byte 6 i IPv6-huvudet för att se om värdet är lika med 6. Om du istället hitta ett värde som identifierar en frivillig förlängning sidhuvud, kolla förlängningen huvudet nästa rubrikfältet till ett värde av 6. Om du hittar fler frivillig förlängning rubriker, fortsätta att upprepa det senaste testet tills du hittar den senaste förlängningen header ".

Ganska enkelt att skriva på engelska, men detta är en mardröm att genomföra i koden. De flesta frivillig förlängning rubriker varierar i längd som bara ökar komplexiteten. Jag har gjort några tester med scapy och du kan faktiskt se skillnaden i prestanda när protochain får åberopas. Faktum är att du kan nog göra ett ganska bra jobb dosering en IDS / IPS genom att tvinga det att bearbeta en massa meningslösa förlängning rubriker.

Skriva våra filter

Så vår första problemet skriftligen utmaningen filtret är att ICMPv6 huvudet kanske inte visas direkt efter IPv6-header. Vi måste se upp för frivillig förlängning rubriker. I själva verket RFC 2710 säger: "Alla är MLD meddelanden beskrivs i detta dokument skickas med en länk-lokal IPv6 Source Adress, en IPv6-Hop gräns på 1 och en IPv6-router Alert alternativet [RTR-alert] i ett Hop-by-hop Alternativ huvudet. "Detta betyder att våra multicast lyssnaren paket är skyldig att ha en Hop-för-Hop förlängningen huvudet med routern Alert inställt. Med detta i åtanke bör vi först kontrollera att:

ip6 protochain icmp6

För att säkerställa att vi bara tittar på ICMPv6 paket. Nu är det bara en fråga om att kontrollera om den typ fältet (byte 0) är satt till 130 (Multicast Listener Query) eller 131 (Multicast Listener rapporten). Detta leder oss till vår andra problem dock. I IPv4-världen jag kan göra en:

ICMP [0] = <Skriv värde interest>

Om jag prova det här med icmp6 jag får:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 övre skiktet protokollet stöds inte av proto [x]

Med andra ord kan jag inte använda offset med icmp6 att söka efter specifika värden. Windump och tcpdump annonseras som IPv6-kompatibla, men förvänta dig inte att få alla samma funktioner du har med IPv4. Usch!

Så vad gör vi? Vi har att falla tillbaka på att referera till värdet från en offset ip6. Med andra ord, vi måste mäta via IPv6 huvudet, genom den föreskrivna Hop-by-hop huvudet och in i ICMPv6 huvudet för att se om den typ är inställt på 130 eller 131. Några saker att beakta:

• IPv6-header är fastställt till 40 bytes i storlek
• Hop-för-Hop huvudet varierar, men är 4 byte med Router Alert som
• Den typ fältet är byte 0 i ICMPv6 header

Så här är vad vi sluta med:

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

Puh! Vi fick äntligen det! Eller gjorde vi?

F: Vad händer om paketet har ytterligare förlängning rubriker?

A: Våra filter fungerar inte.

F: Vad händer om Hop-by-Hop huvudet har mer alternativ som än Router Alert?

A: Våra filter fungerar inte.

F: Kan vi fixa de två ovan nämnda problem?

A: Inte förrän tcpdump / Windump filtrering lägger IF / THEN loop support.

Så om vi vill fånga normal ML trafiken kommer ovan filtret fungerar bra. Men om vi vill försäkra vi fånga angripare trickiness också, är filtret kommer inte att flyga.

Vad händer om vi försöker så här:

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

och sedan bara använda Wireshark är text2cap verktyg för att konvertera det till libpcap format? Problemet här är vi bara kommer att få huvudet info. Grep kommer att matcha huvudraden som innehåller ordet "multicast", men sedan hoppa över alla de Hex under det som är det faktiska innehållet i paketet.

Så det slutgiltiga svaret är: "Kan inte få theya från Haya"

Så vad händer om du verkligen behöver för att kunna se denna trafik? Fram till stöd för IPv6 mognar, är det enda 100% metod för att ta alla ICMPv6 trafik och sedan manuellt sortera igenom den.

Åtminstone det är min syn på detta. Om någon kan faktiskt komma med ett 100% fungerande lösning, jag skulle gärna höra den.

OK, här är en ledtråd att peka dig i rätt riktning.

Utmaningen var: "Skriv en tcpdump / windump filter som kommer att fånga ICMPv6 Multicast Listener paket."

Låter enkelt, eller hur?

Med lite hjälp från Google hittar du att "typ" för multicast-lyssnare är 130, och ICMPv6 typ fältet är den första byten i huvudet. Så detta bör vara så enkelt som:

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

Men om du kör kommandot får du tillbaka:

tcpdump: IPv6 övre skiktet protokollet stöds inte av proto [x]

Med andra ord kan du använda "icmp6" för att se alla ICMPv6 paket, men du kan inte använda den för att filtrera på någon av de ICMPv6 huvudet fält.

Så vi behöver en "Plan B". Räkna ut plan B och du har löst utmaningen.

Bygger på IPv6 utmaning från förra gången har jag en ny till dig: Skriv en tcpdump / windump filter som kommer att fånga ICMPv6 Multicast Listener paket.

Det är allt! Ganska enkelt, eller hur?

Tja dess nu torsdag så jag tänkte att det är dags att publicera svaren på förra helgens utmaning.

Först, varför skulle du bry dig även om IPv6 om du inte har börjat distribuera den? Jag kände ungefär på samma sätt tills jag hittade IPv6 används som en förtäckt kommunikationskanal inom en kunds nätverk. Uppgifterna var då knuffas ut till Internet via Teredo. Om du inte är bekant med tekniken har Scott Hogg några utmärkta inlägg i ämnet.

Så även om du för närvarande inte använder IPv6, lönar det sig att börja skära botemedlet på teknik samt att titta efter den på ditt lokala nätverk.

Så för att se över var utmaningen:

Skriv en tcpdump eller Windump filter som kommer att fånga all trafik med en källa IPv6-adress 2001: DB8:: 10 till 2001: DB8:: 20.

Det finns ett par varningar med att skriva det här filtret. De första jag täckte i förra inlägget. Den sista en, som jag visste men aldrig riktigt trodde var ett problem tills jag började jobba med IPv6 ganska tungt, det är tcpdump / Windump bara låter dig använda 1, 2 eller 4 byte masker. Så medan vi skulle älska att lösa detta med ett första filter uttalande "ip6 [8:14] =", kan vi inte eftersom vi är begränsade till 4 byte. Det är i själva verket ett sätt att komma runt detta, men jag kommer tillbaka till det.

Så här är filtret jag har jobbat med:

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

Lite lång, men det fungerar. Elizabeth kom med en lösning som är långt mer elegant än min egen:

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

Så genom att börja med libpcap formatet, hon kunna kombinera mina första tre uttalanden till en. Inte att vara en storlek drottning, men det gör hennes lösning är mycket kortare än mitt. I det här fallet att det är en bra sak.

Det om det. Jag kommer lägga upp en annan IPv6 typ utmaning i morgon.

Wow, är ljudet av syrsor öronbedövande. Visst någon har kompetens att ta oss igenom detta dilemma?

OK, några tips ta dig igenom utmaningen. Låt oss börja med att lösa detta som en IPv4-adress och sedan kommer vi arbeta oss in i IPv6. Antag att adressområdet vi vill fånga är 192.168.1.10 - 192.168.1.20. Det stora problemet är att IP-adresser är inte på en jämn byte gränsen. Vi skulle kunna göra något liknande:

src nätet 192.168.1.0/27

men det skulle ge oss adresserna från 0,0 till 0,31, mer IP-adresser än vad vi egentligen ville se. För att lösa detta problem som vi måste använda vissa operatörer och primitiv. En möjlighet är:

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

Från och med den inre flesta konsoler, läser ovanstående uttalande "byte 15 måste vara större än eller lika med 10, men det måste också vara mindre än eller lika med 20. Om detta påstående är sant, se byte 12 är lika med 192, är byte 13 lika med 168 och byte 14 är lika med 1. "

Kan vi förkorta detta uttryck? Absolut! Först måste vi konvertera det till Hex dock. Varför Hex? Om jag skriver ett uttalande som "ip [00:02] =" tcpdump kommer att anta att resultatet blir en 16-bitars nummer, inte två 8-bitars nummer. Det är därför du kan skriva något i stil med "tcp [02:02] = 12345" och få det att fungera. tcpdump omvandlar två byte till ett 16-bitars värde och matchar det mot det värde du angett. Genom att konvertera till hex vi undvika detta problem. Alltså:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Nu skriver vi helt enkelt våra uttryck:

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

Det är allt som finns till den.

Medan IPv4 använder 4 byte adresser använder IPv6 16 byte. Eftersom adresserna är så långa, skriver vi dem i Hex att spara lite utrymme. Så tar jag gav dig i utmaningen var:

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

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

Märker jag inte initialt skriva dem på det sättet. Det finns några konventioner du kan använda för att spara utrymme när du skriver en IPv6-adress. Först kan vi trunkera inledande nollor. Alltså:

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

blir:

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

Nu ser alla dessa nollor i mitten? Vi kan hugga ut dem också. När du ser "::" det betyder att fylla i det utrymmet tillräckligt med nollor för att expandera adressen tillbaka ut till 16 byte. Så lägg in detta trick också och vi får:

2001: DB8:: 10

Mycket lättare att skriva. Det förbehållet är att du bara kan ta bort en grupp av nollor med dubbla kolon susen. Tänk på följande adress:

2001:: 1234:: 10

Vi har ingen aning om var att placera byte sekvensen "1234" i adressfältet. Det börjar allt från byte 6 till byte 12.

När du arbetar med IPv4, tcpdump och Windump använda protokollet sökordet "IP", som visas i ovanstående exempel. IPv6 komplement till som är "ip6". Var är källan adress fältet i IPv6-huvudet? Jo jag kan inte ge dig allt det svar eller det inte längre är en "utmaning"

Här är en annan utmaning att testa dina kunskaper lite wienie:

Skriv en tcpdump eller Windump filter som kommer att fånga all trafik med en källa IPv6-adress 2001: DB8:: 10 till 2001: DB8:: 20. Ganska enkelt, eller hur? Om du inte har provat det, du kommer att finna att tcpdump / Windump kastar ett par kurvor på dig.

För att kontrollera ditt arbete, här är en capture-fil:

ipv6-ICMP

Filen innehåller en blandning av källa IPv6-adresser. Självklart ditt filter ska bara visa det angivna intervallet för adresser.

Vinnaren får att inspirera vördnad och beundran i mindre nördar.

Om den här utmaningen verkade svårare än det borde vara, är du på rätt väg.

Jag sprang över det här problemet när du skriver min Packet Decode verktyg. Jag måste säga, det var en cool övning för mig, eftersom jag aldrig riktigt tänkt på att skapa tcpdump och Wireshark filter för alla möjliga IP, TCP, UDP och ICMP område och / eller värde. Den överlägset TCP optioner fältet är den mest "trasiga" från ett paket avkoda perspektiv än någon annan IP-området.

Först ska vi prata om hur TCP optioner skulle ha varit genomfört. Om du tittar på IPv4 alternativ fältet, börjar det med en "Typ" identifierare. Om du är intresserad av en specifik IP-alternativ, det är bara en fråga om att kontrollera detta fält för rätt lite kombination. Hade TCP optioner genomförts på detta sätt skulle den här utmaningen har varit ganska rakt framåt.

Bara om alla TCP Optionerna har en "snäll" och "Längd"-fältet, som båda är 1 byte i storlek. Undantagen är "End of Option List" och "No-Operation" som bara har en sort konkurrensvillkor, och därmed är en byte i storlek. Här är en lista över vanliga TCP optioner:

Sidan 15 av RFC 793 berättar för oss "TCP-huvudet (även ett inklusive optioner) är ett helt antal 32 bitar långa." Med andra ord måste TCP-huvudet storlek i byte vara jämnt delbart med fyra (20 byte, 24 byte, etc.). Om man tittar på listan över TCP optioner, bara "Maximum Segment Size" är delbart med fyra. Så användning av andra alternativ kommer att kräva stoppning.

Hur stoppning bör tillämpas är lite oklart. Om vi tittar på sidan 26 i RFC 1323 finner vi detta:

  BILAGA A: GENOMFÖRANDE FÖRSLAG

    Följande layouter rekommenderas för sändningsalternativ på icke-SYN
    segment, för att uppnå högsta möjliga anpassning av 32-bitars och 64-bitars
    maskiner.

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

Notera NOP stoppning visas före tidsstämpel, inte i slutet som du kanske tror. Observera även RFC uttryckligen säger att detta är för "icke-SYN segment" och att det är "rekommenderat", krävs inte. Verkar dock att de flesta operativsystem följa denna rekommendation och alltid plats stoppning innan Kind och bytes längd. Jag har kollat ​​Windows, Linux, Mac, olika hårdvara, osv, och de alla lägger stoppning i början.

Så vi kan räkna med att detta är "standard", eller hur? Inte riktigt. Sidan 17 av RFC 793 beskriver NOP så här:

  Detta alternativ kod får användas mellan alternativ, till exempel för att
         anpassa början av en efterföljande alternativ på en ordgräns.
         Det finns ingen garanti för att avsändare kommer att använda detta alternativ, så
         mottagare måste vara beredd att bearbeta alternativ även om de inte
         inte börja på en ordgräns. 

Med andra ord, det är inte bara att NOP kan eller inte kan dyka upp i början, kanske NOP inte användas alls! Det är helt lagligt att layouten TCP alternativet fältet utan NOP stoppning och bara använda Slut på Alternativlista som fyllmedel i slutet för att uppnå den rätta gränsen.

Så vad hamnar vi med för ett filter? Om vi ​​räknar på NOP innan det alternativ vi sluta med ett filter som ser ut så här:

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

Att bryta ner vad detta filter gör:

• Bara kolla SYN & SYN / ACK-paket: tcp [13] & 2 = 2
• TCP-huvud är större än 20 byte (alternativ anges): tcp [12] & 240> 80
• Kontrollera den första byten i varje fyra byte gräns för NOP: tcp [20] = 1, tcp [24 = 1, ...
• Kontrollera de kommande två byte för att se om Kind = 3 och längd = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Men om vi vill se till att vi fångar alla möjligheter om ett system inte genomför NOP vi sluta med:

tcp [13] & 2 = 2 och tcp [12] & 240> 80 och (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)

Skillnaden med detta filter är att vi kontrollerar Typ = 3 och längd = 3 hela vägen igenom alternativen området (som Elizabeth föreslår).

Kan någon av dessa filter genererar falsklarm? Absolut! Två möjligheter:

1. Värdet av Timestamp kan matcha det mönster vi letar efter.
2. Filtret tar en 40 fält byte alternativ. Det kan vara mindre med dessa värden i nyttolasten.

Så vilket filter bör du använda? Den första kommer att generera färre falsklarm, men missar system som är RFC-kompatibla, men skiljer sig från normen. Den andra kommer alltid att fånga Fönster Skala om den har ställts in, men chansen till ett falskt positivt är högre.

Jag ska utse Elizabeth som vinnare av utmaningen. Några andra var lika nära men hon var den enda med modet att lägga sin tankegång i kommentarerna. Jag kommer att dela ut ett andrapris till Jeff som kom upp med den här lösningen delvis skojar runt:

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

Detta kommer inte att generera en faktisk fånga paket, men du kunde göra en:

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

Och kör sedan ut genom txt2cap att få den tillbaka in pcap format. Han följde inte utmaningen specifikt, men du har måste ge beröm för att tänka utanför boxen eftersom detta fixar alla falska positiva frågor.

Elizabeth och Jeff, jag kommer att kontakta dig både via e-post. Grattis!

Jag har haft en tråd post och fyra e-postmeddelanden som såååå är nära det rätta svaret. Här är en sista ledtråd för att förhoppningsvis få folk över sista hindret.

Jag nämnde den hjälpsamma tshark kommandot. Här är resultatet:

C: \ test> tshark-n-r linux-syn.cap-T fält-e tcp.options
02:04:05: B4: 04:02:08:0 en: 02:47:04 A: A8: 00:00:00:00:01:03:03:05

Så vad du har ovan är TCP Alternativ (byte 20 och högre) av testet paketet. Fönster Skala alternativet är det sista alternativet i listan.

Jag vet att skriva detta filter är inte lätt. Faktum är att det är därför jag gjort det till en utmaning. Det är möjligt dock.