De uitdaging was: "Schrijf een tcpdump / WinDUMP filter dat vast te leggen ICMPv6 Multicast Listener-pakketten." Ik heb een uitgebreide up schrijf op wat het antwoord zo complex. Als u weet dat IPv6 en wil gewoon het antwoord, ga dan naar het einde.

Eerst wat achtergrond

Steinar een aantal opmerkingen van de vorige palen en was 100% op het juiste spoor. Als je leest ze en dacht: "Wow, dat klinkt echt vies", begrijp je de omvang van het probleem ook.

Protocol Vs. Volgende Header Field

Met IPv4 hadden we de mogelijkheden veld. Dit kan ertoe leiden dat de IP-header om te groeien van 20 bytes naar zo groot als 60 bytes groot zijn. Met IPv6, is er niet langer een optie veld en de header is vastgesteld op 40 bytes groot. Als er opties nodig zijn, gebruiken we de uitbreiding headers om ze te identificeren. Dit werpt een interessante curve bal bij ons, omdat met het protocol IPv4 veld (byte 9) zou (bijna) altijd identificeren van de bovenste verdieping transport (TCP, UDP, etc.). Met IPv6 het volgende header veld (byte 6) kunnen identificeren van de bovenste laag transport, of het kan een uitbreiding header die enkele aantal opties zal identificeren.

Hier is een lijst van een aantal IPv6-extensie headers je zou tegenkomen, evenals de RFC's die ze definiëren:

IPv6 is niet het aantal van de uitbreiding headers u kunt gebruiken in een enkele packet.There is echter een gepubliceerde "aanbevolen om" over hoe de headers moet worden aangelegd. De volgorde is:

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

Let op deze lijst is "aanbevolen", maar niet verplicht. Een IPv6-host moet in staat zijn om de headers proces wat ooit volgorde waarin ze zijn ontvangen. Dit betekent dat je waarschijnlijk leveranciers vindt naar aanleiding van deze lijst, maar niet aanvallers. Ik persoonlijk heb gezien apparaten beginnen met handelen echt vreemd als je knoeien met de kop bestelling. In feite heb ik lopen over heel wat van "IPv6-compatibele code" die niet kan omgaan als de gewenste volgorde wordt niet gebruikt.

Chasing Het protocol Header

Dus met IPv6 kunnen we meerdere koppen achter de IPv6-header. Als dit klinkt als een nieuw concept, is het eigenlijk niet. In feite hebt u waarschijnlijk gewerkt met het reeds. Wanneer u implementeert IPSec de twee mogelijke security protocollen zijn ESP en AH. Deze waren eigenlijk geleend van IPv6 en gemasseerd om te werken aan IPv4. Zowel de AH en ESP zijn een volgende header veld te bepalen welk type packet ze protecting.This wordt aangeduid als het protocol koppelen, als u effectief meerdere koppen zitten achter de laag 3 protocol header.

Dus om erachter te komen wat bovenverdieping transport (TCP, UDP, enz.) wordt gebruikt, kan je zoeken via meerdere headers voordat je het antwoord. Dit wordt aangeduid als "achter de header", en tcpdump / WinDUMP geven ons een filter optie om deze taak uit te voeren. U kunt fimiliar met de proto filter. In het IPv4-wereld, als ik zeg:

ip proto tcp

Dat filter staat "check byte 9 van de IPv4-header en als de waarde gelijk is aan 6 (protocol waarde voor TCP), wedstrijd op het pakket". Dit filter is niet zo effectief in de IPv6 wereld natuurlijk, omdat byte 6 van de IPv6-header kan de bovenste laag vervoer te identificeren, of het kan alleen maar identificeren een optionele uitbreiding header die wordt gebruikt. Om dit probleem oplossen, was de protochain filter geïntroduceerd. Schrijven:

IP6 protochain tcp

Luidt als "Controleer byte 6 van de IPv6-header om te zien of de waarde gelijk is aan 6. Als je in plaats daarvan vindt een waarde die een optionele uitbreiding header identificeert, controleert de uitbreiding header van de volgende header veld voor een waarde van 6. Als u vindt meer optionele uitbreiding koppen, blijf het herhalen van de laatste test totdat je de laatste uitbreiding header ".

Vrij eenvoudig om te schrijven in het Engels, maar dit is een nachtmerrie om te implementeren in code. De meeste optionele uitbreiding headers zijn variabel in lengte die net toevoegt aan de complexiteit. Ik heb gedaan wat testen met scapy en je kunt echt zien het verschil in prestaties wanneer protochain wordt ingeroepen. In feite kon je waarschijnlijk een vrij goed werk van de dosering een IDS / IPS door het te dwingen om veel nutteloze uitbreiding headers proces.

Het schrijven van onze filter

Dus onze eerste probleem bij het schrijven de uitdaging filter is dat de header ICMPv6 mogelijk niet goed weergegeven nadat de IPv6-header. We moeten oppassen voor optionele uitbreiding headers. In feite is RFC 2710 zegt: "Alle MLD berichten beschreven in dit document worden verzonden met een link-local IPv6-adres Source, een IPv6-Hop Limit van 1, en een IPv6-router Alert optie [RTR-ALERT] in een Hop-by-Hop Opties header. "Dit betekent dat onze luisteraar multicast-pakket is nodig om een ​​Hop-by-Hop uitbreiding header met de router Alert optie hebben. Met dit in gedachten, moet onze eerste cheque:

IP6 protochain icmp6

Om ervoor te zorgen we alleen kijken naar ICMPv6 pakketten. Nu is het gewoon een kwestie van controleren om te zien als het type veld (byte 0) is ingesteld op 130 (Multicast Listener Query) of 131 (Multicast Listener Report). Dit brengt ons echter op onze tweede probleem. In het IPv4-wereld die ik kan doen een:

icmp [0] = <typ waarde van interest>

Als ik probeer dit met icmp6 krijg ik:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 upper-layer protocol wordt niet ondersteund door proto [x]

Met andere woorden, kan ik niet gebruiken offsets met icmp6 om te zoeken naar specifieke waarden. WinDUMP en tcpdump worden aangeboden als IPv6-compatibel, maar verwacht niet dat alle dezelfde functionaliteit die je hebt met IPv4 te krijgen. YUCK!

Dus wat doen we? We zullen moeten terugvallen op verwijzing van de waarde van offset een ip6. Met andere woorden, moeten we meten door middel van de IPv6-header, door middel van de vereiste Hop-by-Hop header, en in de ICMPv6 header om te zien of het type veld is ingesteld op 130 of 131. Sommige dingen rekening te houden met:

• IPv6 header is vastgesteld op 40 bytes groot
• Hop-by-Hop header is variabel, maar vier bytes met router Alert set
• Het type veld is byte 0 binnen de ICMPv6 header

Dus hier is wat we eindigen met:

IP6 protochain icmp6 en (IP6 [44] = 130 of ip6 [44] = 131)

Whew! We hebben eindelijk het! Of hebben we?

Q: Wat gebeurt er als het pakketje heeft extra uitbreiding headers?

A: Onze filter zal niet werken.

Q: Wat gebeurt er als de Hop-by-Hop header heeft meer opties in te stellen dan de router Alert?

A: Onze filter zal niet werken.

Q: Kunnen we vast de twee bovenstaande problemen?

A: Niet tot tcpdump / WinDUMP filtering als / dan loop ondersteuning toevoegt.

Dus als we willen het normale ML verkeer vast te leggen, zal de bovenstaande filter prima werken. Als we echter willen verzekeren vangen we aanvaller lastige ook, wordt het filter niet van plan om te vliegen.

Wat gebeurt er als we proberen iets als dit:

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

en dan gewoon gebruik van Wireshark text2cap hulpmiddel om het te converteren naar formaat libpcap? Het probleem hier is dat we zullen alleen maar de header info. Grep zal overeenkomen met de samenvatting lijn die het woord "Multicast" bevat, maar dan slaat u de Hex eronder dat is de feitelijke inhoud van het pakket.

Dus is het uiteindelijke antwoord is: "Kan niet theya krijgen van haya"

Dus wat als je echt nodig hebt om te kunnen dit verkeer te zien? Tot ondersteuning voor IPv6 rijpt, de enige 100% methode is om alle ICMPv6 verkeer te grijpen en vervolgens handmatig sorteren het.

Tenminste dat is mijn mening op dit punt. Als iemand daadwerkelijk kan komen met een 100% werkende oplossing, ik zou het graag horen.

OK, hier is een hint om je in de juiste richting.

De uitdaging was: "Schrijf een tcpdump / WinDUMP filter dat vast te leggen ICMPv6 Multicast Listener pakketten."

Klinkt makkelijk, toch?

Met een beetje hulp van Google zult u merken dat het "type" voor Multicast-luisteraar is 130, en de ICMPv6 type veld is de eerste byte in de header. Dus dit moet zo eenvoudig als:

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

Maar als je het commando ben je weer terug te krijgen:

tcpdump: IPv6 upper-layer protocol wordt niet ondersteund door proto [x]

Met andere woorden, kunt u gebruik maken "icmp6" om alle ICMPv6 pakketten te lezen, maar je kunt het niet gebruiken om te filteren op een van de ICMPv6-header velden.

Dus we moeten een "Plan B". Erachter te komen plan B en je hebt opgelost de uitdaging.

Voortbouwend op de IPv6-uitdaging van de vorige keer, ik heb een nieuwe voor jullie: Schrijf een tcpdump / WinDUMP filter die zal vangen ICMPv6 Multicast Listener pakketten.

Dat is het! Lekker makkelijk, toch?

Wel zijn nu donderdag dus ik dacht dat het tijd om de antwoorden op de uitdaging van afgelopen weekend post.

De eerste, waarom zou je dan nog druk over IPv6 Als u nog niet begonnen met de implementatie van het? Ik voelde veel op dezelfde manier totdat ik vond IPv6 wordt gebruikt als een verkapte communicatiekanaal binnen het netwerk van een klant. De data werd vervolgens geduwd naar het internet via Teredo. Als u niet bekend bent met de techniek, Scott Hogg heeft een aantal uitstekende berichten over het onderwerp.

Dus zelfs als je niet bent op dit moment IPv6 gebruikt, loont het om te beginnen met het snijden van de kuur op de technologie, alsmede het kijken voor het op uw lokale netwerk.

Zo te herzien, de uitdaging was:

Schrijf een tcpdump of WinDUMP filter dat al het verkeer zal vastleggen met een bron IPv6-adres van 2001: db8:: 10 tot en met 2001: db8:: 20.

Er zijn een paar van de valkuilen bij het schrijven van dit filter. De eerste paar ik behandeld in de laatste post. De laatste een, die ik kende, maar nooit echt dacht dat het een probleem totdat ik begon te werken met IPv6 mooie zwaar, is dat tcpdump / WinDUMP alleen kunt u gebruik 1, 2 of 4 byte maskers. Dus terwijl we graag dit op te lossen met een eerste filter verklaring van "ip6 [08:14] =", kunnen we niet omdat we beperkt tot 4 bytes. Er is in feite een manier om dit te omzeilen, maar ik kom terug om het te.

Dus hier is het filter heb ik gewerkt met:

(IP6 [08:04] = 0x20010db8 en ip6 [12:04] = 0 en ip6 [16:4] = 0 en (IP6 [20:4]> = 0 × 0010 en ip6 [20:4] <= 0050 ))

Beetje lang, maar het werkt. Elizabeth kwam met een oplossing die veel meer elegant dan mijn eigen:

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

Dus door te beginnen met de libpcap formaat, ze is in staat om mijn eerste drie verklaringen te combineren tot een. Niet om een ​​formaat koningin, maar dat maakt haar oplossing is veel korter dan de mijne. In dit geval is dat een goede zaak.

Dat is het zo'n beetje. Ik kom na een ander soort uitdaging IPv6 morgen.

Wow, is het geluid van krekels oorverdovend. Zeker iemand die over de vaardigheden om ons door dit dilemma?

OK, tot op zekere tips krijg je door de uitdaging. Laten we beginnen met het oplossen van dit als een IPv4-adres en dan zullen we onze weg werk in IPv6. Stel dat de adresbereik we willen vastleggen is 192.168.1.10 - 192.168.1.20. Het grote probleem is de IP-adressen zijn niet op een nog byte grens. We kunnen iets doen, zoals:

src net 192.168.1.0/27

maar dat zou ons adressen 0,0 tot 0,31, meer IP's dan we eigenlijk wilden zien. Als oplossing voor dit probleem dat we je nodig hebt om sommige exploitanten en primitieven te gebruiken. Een mogelijkheid is:

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

Te beginnen met de binnenste haakjes, de bovenstaande verklaring luidt "byte 15 moet groter zijn dan of gelijk aan 10, maar ook moet kleiner zijn dan of gelijk aan 20. Als deze uitspraak waar is, zorg er dan byte 12 is gelijk aan 192, 13 byte is gelijk aan 168 en 14 byte is gelijk aan 1. "

Kunnen we verkorten deze uitdrukking? Absoluut! Eerst moeten we het echter converteren naar Hex. Waarom Hex? Als ik een verklaring, zoals schrijven "ip [12:02] =" tcpdump ervan uit dat het resultaat zal een 16-bits getal, niet twee 8-bits getallen. Dit is de reden waarom u iets als "tcp [02:02] = 12345" schrijven en het werkt. tcpdump zet de twee bytes in een 16-bits waarde en past het tegen de waarde die u hebt opgegeven. Door het omzetten naar Hex we dit probleem te vermijden. Dus:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Nu gaan we gewoon schrijven onze uitdrukking:

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

Dat is alles wat er is.

Terwijl IPv4 gebruikt 4 bytes adressen, IPv6 maakt gebruik van 16 bytes. Omdat de adressen zijn zo lang, we schrijven ze in Hex om wat ruimte te besparen. Dus de adressen ik je gaf in de uitdaging waren:

2001:0 db8: 0000:0000:0000:0000:0000:0010

2001:0 db8: 0000:0000:0000:0000:0000:0020

Let op, ik heb in eerste instantie niet schrijf ze op die manier. Er is een aantal conventies die u kunt gebruiken om ruimte te besparen bij het schrijven van een IPv6-adres. Ten eerste kunnen we afkappen nullen. Dus:

2001:0 db8: 0000:0000:0000:0000:0000:0010

wordt:

2001: db8: 0000:0000:0000:0000:0000:10

Nu, ziet al die nullen in het midden? We kunnen hak ze ook. Als je ziet "::" Dat betekent in die ruimte te vullen met genoeg nullen naar het adres terug te breiden naar 16 bytes. Zo toe te voegen in deze truc zo goed en krijgen we:

2001: db8:: 10

Veel gemakkelijker om te schrijven. De valkuil is dat je kunt alleen een groep van nullen te verwijderen met de dubbele punten truc. Overweeg het volgende adres:

2001:: 1234:: 10

We hebben geen idee waar de byte volgorde plaats "1234" in het adres. Het begint overal van byte 6 tot en met 12 byte.

Bij het werken met IPv4, tcpdump en WinDUMP gebruik van het protocol trefwoord "ip", zoals weergegeven in de bovenstaande voorbeelden. De IPv6 compliment aan die "ip6". Waar is de bron adres in de IPv6-header? Nou ik kan niet geven u alles antwoorden of het is niet langer een "uitdaging"