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

Eerst een paar Achtergrond

Steinar een aantal opmerkingen van de vorige posts en was 100% op schema. 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 opties veld. Dit kan ertoe leiden dat de IP-header om van 20 bytes groeien zo groot als 60 bytes groot. Met IPv6 er niet langer een opties veld en de header wordt vastgesteld op 40 bytes in grootte. Bij opties nodig zijn, gebruiken we 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 niveau transport (TCP, UDP, enz.). Met IPv6 de volgende header veld (byte 6) kunnen identificeren van de bovenste laag vervoer, of is het misschien een uitbreiding header die sommige aantal opties zal identificeren.

Hier is een lijst van een aantal IPv6-extensie headers u misschien in de, evenals de RFC's die hen te definiëren:

IPv6 heeft geen beperking van het aantal extensie 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
• Bestemming Opties
• Mobiliteit Header
• TCP/UDP/ICMPv6

Let op deze lijst wordt "aanbevolen", maar niet verplicht. Een IPv6-host moet in staat zijn om de headers te verwerken in wat ooit volgorde waarin ze zijn ontvangen. Dit betekent dat je waarschijnlijk vinden verkopers het volgen van deze lijst, maar niet aanvallers. Ik heb persoonlijk gezien apparaten te starten die echt vreemd als je knoeien met de kop bestelling. In feite heb ik lopen over heel wat van "IPv6-compatibele code", die niet om kan gaan als de gewenste volgorde niet wordt 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 implementeren IPSec de twee mogelijke veiligheidsprotocollen zijn ESP en AH. Deze waren eigenlijk geleend van IPv6 en gemasseerd om te werken aan IPv4. Zowel AH en ESP zijn onder andere een volgende header veld te identificeren welk type packet ze protecting.This wordt aangeduid als protocol koppelen, als u effectief meerdere koppen zitten achter de laag 3 protocol header.

Dus om erachter te komen wat bovenste niveau transport (TCP, UDP, enz.) wordt gebruikt, kan het nodig zijn om te zoeken door meerdere headers voordat u het antwoord vinden. 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 leest "controleer byte 9 van de IPv4-header en als de waarde gelijk is aan 6 (protocol waarde voor TCP), passen op de verpakking". Dit filter is niet zo effectief in de IPv6-wereld natuurlijk door byte 6 van de IPv6-header kan de bovenste laag vervoer te identificeren, of het misschien gewoon te identificeren een optionele uitbreiding header die wordt gebruikt. Om dit probleem op te lossen, werd de protochain filter geïntroduceerd. Schrijven:

IP6 protochain tcp

Leest 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 u de uitbreiding header's volgende header veld voor een waarde van 6. Als u 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 uit te voeren in de 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 wel een redelijk goede baan van het doseren van een IDS / IPS door het te dwingen om veel nutteloze uitbreiding headers te verwerken.

Het schrijven van onze filter

Dus onze eerste probleem bij het schrijven de uitdaging filter is dat de ICMPv6 kop niet recht achter de IPv6-header. We moeten oppassen voor optionele uitbreiding headers. In feite RFC 2710 stelt: "Alle MLD berichten beschreven in dit document worden verstuurd met een link-local IPv6-adres Bron, 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 vereist om een ​​hop-by-Hop uitbreiding header met de router Alert optie is ingesteld. Met dit in gedachten, zou onze eerste controle zijn:

IP6 protochain icmp6

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

icmp [0] = <typ hier waarde van interest>

Als ik probeer dit met icmp6 krijg ik:

[Root @ Fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 bovenste 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 moeten terug te vallen op dat verwijst naar de waarde van offset een ip6. Met andere woorden, zullen we moeten 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 4 bytes met router Alert ingesteld
• 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)

Oef! We hebben eindelijk heb het! Of hebben wij?

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

A: Onze filter zal niet werken.

V: Wat 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 bovengenoemde problemen?

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

Dus als we willen normale ML verkeer vast te leggen, zal de bovenstaande filter 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 maken van text2cap programma Wireshark's te converteren naar formaat libpcap? Het probleem hier is dat we zullen alleen maar de header info. Grep zal de samenvatting lijn die het woord "Multicast" bevat dan overeenkomen met maar sla alle Hex eronder dat is de werkelijke inhoud van het zakje.

Dus het definitieve antwoord is: "Kan niet theyâ krijgen van haya"

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

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 u te wijzen in de goede richting.

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

Klinkt makkelijk, toch?

Met een beetje hulp van Google vindt u dat de "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 krijg je terug:

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

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

Dus moeten we een "Plan B". Zoek uit plan B en je hebt opgelost de uitdaging.

Voortbouwend op de IPv6-uitdaging van de vorige keer, ik heb een nieuwe voor u: Schrijf een tcpdump / WinDUMP filter dat zal vast te leggen ICMPv6 Multicast Listener pakketten.

Dat is het! Lekker makkelijk, toch?

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

Ten eerste, waarom zou je dan nog druk over IPv6 als je nog niet begonnen met de implementatie van het? Ik voelde me op dezelfde manier tot ik IPv6 wordt gebruikt als een verkapte communicatiekanaal binnen het netwerk van een klant gevonden. 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 momenteel niet gebruikt IPv6, loont het om te beginnen met het snijden van de genezing van de technologie en het kijken naar het op uw lokale netwerk.

Dus om herziening, de uitdaging was:

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

Er zijn een paar van de valkuilen bij het schrijven van dit filter. De eerste paar heb ik behandeld in de laatste post. De laatste, die ik kende, maar nooit echt dacht dat het een probleem tot ik begon te werken met IPv6 vrij zwaar is, is dat tcpdump / WinDUMP alleen kunt u gebruik maken van 1, 2 of 4 bytes 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 is veel eleganter 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 samen te voegen tot een. Niet om een ​​grootte koningin zijn, 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 IPv6 soort uitdaging morgen.

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

OK, enkele tips om je door de uitdaging. Laten we beginnen met het oplossen van dit als een IPv4-adres en dan zullen we onze weg te werken in IPv6. Neem aan dat het 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. Om dit probleem op te lossen zullen we moeten 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))

Beginnend met de innerlijke meeste haakjes het bovenstaande verklaring luidt "byte 15 moet groter zijn dan of gelijk aan 10, maar ook moet lager zijn dan of gelijk aan 20. Als deze verklaring klopt, zorg ervoor byte 12 gelijk tot 192, byte 13 is gelijk aan 168 en byte 14 is gelijk aan 1. "

Kunnen we verkorten deze uitdrukking? Absoluut! Eerst moeten we het echter om te zetten in 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 je iets als 'tcp [02:02] = 12345 "schrijven en laten werken. tcpdump converteert de twee bytes in een 16-bits waarde en deze vergelijkt tegen de waarde die u opgegeven. Door het omzetten van om de Hex we dit probleem omzeilen. 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 die 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

Merk op dat ik had 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 uit. Wanneer je zien "::" dat betekent in dat de ruimte vult met genoeg nullen op het adres weer uit te breiden naar 16 bytes. Dus 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 slechts 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 sequentie "1234" te plaatsen in het adres. Het begint ergens tussen de byte 6 tot en met byte 12.

Bij het werken met IPv4, tcpdump en WinDUMP gebruik maken 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 wat er antwoorden of het is niet langer een "uitdaging"

Hier is nog een uitdaging om uw steentje wienie vaardigheden te testen:

Schrijf een tcpdump of WinDUMP filter dat al het verkeer zal met een bron IPv6-adres van 2001 vast te leggen: db8 :: 10 tot en met 2001: db8 :: 20. Lekker makkelijk, toch? Als u nog niet geprobeerd, je zult ontdekken dat tcpdump / WinDUMP een paar bochten naar je gooit.

Om te controleren uw werk, hier is een capture-bestand:

ipv6-icmp

Het bestand bevat een mix van bron IPv6-adressen. Uiteraard uw filter moet alleen de opgegeven bereik van adressen.

De winnaar krijgt om te inspireren ontzag en bewondering in mindere geeks.

Als deze uitdaging leek moeilijker dan het zou moeten zijn, bent u op het juiste spoor.

Stuitte ik op dit probleem bij het ​​schrijven van mijn Packet Decode tool. Ik moet zeggen, het was een leuke oefening voor mij, aangezien ik nooit echt nagedacht over het creëren van tcpdump en Wireshark-filters voor alle mogelijke IP, TCP, UDP en ICMP veld en / of de waarde. Veruit de TCP opties veld is de meest "gebroken" van een pakket decoderen perspectief dan alle andere IP-veld.

Laten we het eerst hebben over de manier waarop de TCP-opties hadden moeten zijn uitgevoerd. Als je kijkt naar het IPv4-opties veld, het begint met een "type" identifier. Als u geïnteresseerd bent in een specifiek IP-optie, het is gewoon een kwestie van het controleren van dit gebied voor de juiste bit combinatie. Had het TCP opties zijn geïmplementeerd op deze manier, dan zou deze uitdaging behoorlijk recht toe recht aan zijn geweest.

Zowat alle TCP opties hebben een "soort" en een "Length" veld, die beide 1 byte groot. De uitzonderingen zijn "Einde van Option List" en "No-Operation" die slechts een Kind veld, en zijn dus een byte groot. Hier is een lijst van de gemeenschappelijke TCP opties:

Pagina 15 van RFC 793 vertelt ons "De TCP header (zelfs een inclusief opties) is lang een integraal aantal van 32 bits." Met andere woorden, de TCP header grootte in bytes deelbaar zijn door vier (20 bytes, 24 bytes, etc.). Als je kijkt naar de lijst met TCP-opties, alleen "maximum segment size" is deelbaar door vier. Dus het gebruik van eventuele andere opties gaan padding vereisen.

Hoe de bekleding moet worden toegepast is een beetje onduidelijk. Als we kijken naar pagina 26 van RFC 1323 vinden we dit:

  BIJLAGE A: UITVOERING SUGGESTIES

    De volgende lay-outs worden aanbevolen voor het verzenden van opties op niet-SYN
    segmenten, met maximaal haalbare uitlijning van 32-bits en 64-bit te bereiken
    machines.

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

Let op de NOP padding verschijnt voor de optie Tijdstempel, niet aan het eind, zoals je misschien zou verwachten. Let ook op de RFC specifiek zegt dat dit is voor "niet-SYN" en dat het wordt "aanbevolen", niet nodig. Het lijkt echter dat de meeste besturingssystemen wordt deze aanbeveling op te volgen en altijd padding te plaatsen voor de Kind en Lengte bytes. Ik heb gecontroleerd Windows, Linux, Mac, diverse hardware, etc. en ze zet de padding aan het begin.

Dus we kunnen rekenen op dit is de "standaard", toch? Niet helemaal. Pagina 17 van RFC 793 beschrijft NOP op deze manier:

  Deze optie code kan worden gebruikt tussen opties, bijvoorbeeld om
         Lijn de begin van een daaropvolgende optie op een woordgrens.
         Er is geen garantie dat de afzenders zal deze optie te gebruiken, zodat
         ontvangers moeten bereid zijn te verwerken opties, zelfs als ze dat doen
         niet beginnen op een woordgrens. 

Met andere woorden, haar niet alleen dat NOP al dan niet opdagen op eerste instantie kunnen NOP helemaal niet worden gebruikt! Het is volkomen legaal de lay-out van het TCP-optie veld met geen NOP vulling en net Einde van de keuzelijst te gebruiken als vulling op het einde om de juiste grens te bereiken.

Dus wat doen we eindigen met een filter? Als we op de NOP rekenen voor de optie die we eindigen met een filter dat ziet er als volgt uit:

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

Af te breken wat dit filter doet:

• Alleen check SYN & SYN / ACK pakketten: tcp [13] & 2 = 2
• TCP header groter is dan 20 bytes (opties zijn ingesteld): tcp [12] & 240> 80
• Controleer het eerste byte van elk vier byte grens voor NOP: tcp [20] = 1, tcp [24 = 1, ...
• Controleer de volgende twee bytes om te zien of Kind = 3 en Lengte = 3: tcp [21:2] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Als we echter willen ervoor zorgen dat we alle mogelijkheden in het geval van een systeem niet implementeert NOP we eindigen met te vangen:

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

Het verschil met dit filter is dat we vriendelijk zijn = 3 en Lengte = 3 de hele weg door de opties veld (als Elizabeth voorgesteld) te controleren.

Kan een van deze filters genereren van valse positieven? Absoluut! Twee mogelijkheden:

1. De waarde van Tijdstempel kan overeenkomen met het patroon dat we op zoek zijn.
2. Het filter gaat uit van een 40 byte optie veld. Het kan minder met deze waarden in de payload.

Dus welke filter moet je gebruiken? De eerste zal genereren minder valse positieven, maar missen systemen die RFC compliant, maar anders dan de norm. De tweede zal altijd te vangen Window Scale als deze is ingesteld, maar de kans op een vals-positieve hoger is.

Ik ga Elizabeth aan te wijzen als de winnaar van de uitdaging. Een paar anderen waren net zo dichtbij, maar ze was de enige met het lef om haar gedachtengang plaatsen in de comments. Ik ga een tweede prijs aan Jeff, die kwam met deze oplossing deels een grapje rond toe te kennen:

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

Dit zal niet leiden tot een daadwerkelijke packet capture, maar je zou kunnen doen:

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

En dan lopen de uitvoer door txt2cap om het terug te krijgen in de pcap formaat. Hij heeft niet specifiek te volgen de uitdaging aan, maar je hebt moet geven Kudos voor het denken buiten de box als hiermee is opgelost alle valse positieve zaken.

Elizabeth en Jeff, zal ik binnenkort contact met u zowel via e-mail. Congrats!

Ik heb een thread post en vier e-mails die zooooo dicht bij het juiste antwoord. Hier is nog een laatste aanwijzing voor hopelijk mensen krijgen over de laatste horde.

Ik noemde de behulpzame tshark commando. Hier is de output:

C: \ test> tshark-n-r linux-syn.cap-T-gebieden-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

Dus wat je hebt dan is de TCP opties sectie (byte 20 en hoger) van de test pakket. De Window Scale optie is de laatste optie in de lijst.

Ik weet dat het schrijven van dit filter is niet eenvoudig. In feite is dat is waarom ik maakte er een uitdaging. Het is echter mogelijk.