Die Herausforderung war: "Schreiben Sie eine tcpdump / WinDump Filter, ICMPv6 Multicast Listener Pakete erfassen wird." Ich habe ein umfangreiches Schreiben auf, was die Antwort so komplex. Wenn Sie IPv6 und wissen wollen einfach nur die Antwort, bis zum Ende zu springen.

Zunächst einige Hintergrundinformationen

Steinar machte einige Bemerkungen zu den vorherigen Posts und war 100% auf Kurs. Wenn Sie sie lesen und dachte: "Wow, das ist wirklich chaotisch klingt", Sie verstehen die Tragweite des Problems als auch.

Protokoll Vs. Next Header-Feld

Mit IPv4 hatten wir die Optionen Feld. Dies könnte dazu führen, den IP-Header von 20 Byte bis so groß wie 60 Bytes in der Größe wachsen. Mit IPv6 gibt es nicht mehr ein Feld Optionen und der Header ist 40 Bytes eine feste Größe. Als Optionen erforderlich sind, verwenden wir Erweiterungs-Header, um sie zu identifizieren. Dies wirft eine interessante Kurve Ball an uns, weil mit IPv4 Protokoll-Feld (Byte 9) würde (fast) immer identifizieren die obere Ebene Transport (TCP, UDP, etc.). Mit IPv6 der nächsten Header-Feld (Byte 6) könnte identifizieren die obere Schicht transportieren, oder es könnte eine Erweiterung Header, die eine bestimmte Anzahl von Optionen umfassen wird zu identifizieren.

Hier ist eine Liste von einigen IPv6 Header-Erweiterung Sie den Weg laufen könnte, als auch die RFCs, dass sie zu definieren:

IPv6 nicht die Anzahl der Erweiterungs-Header Sie in einem einzigen packet.There verwenden können, ist allerdings eine veröffentlichte "empfohlene Reihenfolge", wie die Header beschaffen sein müssen. Die Reihenfolge lautet:

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

Notieren Sie sich diese Liste ist "empfehlenswert", aber nicht zwingend. Ein IPv6-Host muss die Header in was auch immer damit waren sie empfangen werden. Das heißt, Sie werden wahrscheinlich feststellen, Anbieter im Anschluss an diese Liste aber nicht die Angreifer. Ich habe persönlich gesehen, Geräte handeln beginnen wirklich seltsam, wenn man mit dem Kopf, um Durcheinander. In der Tat habe ich über eine ganze Menge "IPv6 kompatibel Code", die nicht umgehen kann, wenn die bevorzugte Reihenfolge nicht verwendet wird laufen.

Chasing The Protocol Header

Also mit IPv6 können wir mehrere Header hinter dem IPv6-Header. Wenn das klingt wie ein neues Konzept, ist es eigentlich nicht. In der Tat haben Sie wahrscheinlich mit ihm arbeitete bereits. Wenn Sie IPSec Implementierung der beiden möglichen Sicherheits-Protokolle ESP und AH. Diese wurden tatsächlich von IPv6 geliehen und massiert, um auf IPv4 arbeiten. Beide AH-und ESP gehören eine Next Header-Feld zu identifizieren, welche Art von Paket sind sie protecting.This als Protokoll Verkettung bezeichnet wird, wie Sie effektiv mehrere Header sitzt hinter der Schicht 3-Protokoll-Header.

So um herauszufinden, was Obergeschoss Transport (TCP, UDP, etc.) verwendet wird, müssen Sie unter Umständen über mehrere Header suchen, bevor Sie die Antwort zu finden. Dies wird als "Jagd nach dem Header" genannt, und tcpdump / WinDump uns eine Filter-Option, um diese Aufgabe durchzuführen. Sie können fimiliar mit dem Proto-Filter. In der IPv4-Welt, wenn ich sage:

ip proto tcp

Das Filter liest "check byte 9 der IPv4-Header und, wenn der Wert gleich 6 (Protokoll für TCP), auf der Packung überein". Dieser Filter ist nicht so effektiv in der IPv6-Welt natürlich auch, weil Byte 6 der IPv6-Header der oberen Schicht Transport identifizieren könnten, oder es könnte nur identifizieren, eine optionale Erweiterung Header, die verwendet wird. Um dieses Problem zu lösen, wurde die protochain Filter eingeführt. Schreiben:

ip6 protochain tcp

Liest als "Check-Byte 6 der IPv6-Header, um zu sehen, wenn der Wert gleich 6 ist. Wenn Sie stattdessen ein Wert, der eine optionale Erweiterung Header identifiziert finden, überprüfen Sie die Verlängerung Header der nächsten Header-Feld für einen Wert von 6 Jahren. Wenn Sie mehrere optionale Erweiterungs-Header zu finden, immer wieder das letzte Test, bis Sie die letzte Erweiterung header "zu finden.

Ganz einfach auf Englisch zu schreiben, aber das ist ein Albtraum, in Code umzusetzen. Die meisten optionalen Erweiterungs-Header sind variabel in Länge, die nur erhöht die Komplexität. Ich habe einige Tests mit gemacht Scapy und man kann tatsächlich sehen, der Unterschied in der Leistung, wenn protochain aufgerufen wird. In der Tat könnte man wahrscheinlich einen ziemlich guten Job der Dosierung ein IDS / IPS mittels Pressen zu viel nutzlose Verlängerung Header verarbeiten.

Writing unseren Filter

So unser erstes Problem in schriftlicher Form die Herausforderung Filters ist, dass die ICMPv6 Header kann nicht richtig angezeigt, nachdem der IPv6-Header. Wir müssen aufpassen, für die Erweiterung Header. In der Tat RFC 2710 lautet: "Alle MLD-Nachrichten in diesem Dokument beschriebenen Produkte sind mit einem Link-lokale IPv6-Quell-Adresse, eine IPv6-Hop Limit von 1, und eine IPv6-Router Alert Option geschickt [RTR-ALERT] in einer Hop-by-Hop Options-Header. "Dies bedeutet, dass unsere Multicast Listener-Paket benötigt, um eine Hop-by-Hop Extension Header mit dem Router Alert Option gesetzt haben. In diesem Sinne sollte unser erstes überprüft werden:

ip6 protochain icmp6

Um zu gewährleisten, suchen wir nur an ICMPv6-Pakete. Jetzt ist es nur eine Frage der Kontrolle, ob der Typ-Feld (Byte 0) bis 130 (Multicast Listener Query) oder 131 (Multicast Listener-Bericht) gesetzt ist. Dies bringt uns zu unserem zweiten Problem jedoch. In der IPv4-Welt, die ich tun kann, a:

icmp [0] = <type Wert interest>

Wenn ich dies mit icmp6 bekomme ich die Meldung:

[Root @ fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 Protokoll der oberen Schicht wird nicht durch proto [x] unterstützt

Mit anderen Worten, kann ich nicht verwenden Offsets mit icmp6 nach bestimmten Werten suchen. WinDump und tcpdump als IPv6 kompatibel beworben, aber erwarte nicht, dass alle die gleiche Funktionalität haben Sie mit IPv4 zu bekommen. YUCK!

Also, was sollen wir tun? Wir müssen zurückgreifen auf Referenzierung der Wert aus einer ip6 ausgeglichen. Mit anderen Worten, wir müssen über die IPv6-Header zu messen, durch die erforderlichen Hop-by-Hop-Header und in die ICMPv6-Header zu sehen, ob der Typ-Feld auf 130 oder 131 eingestellt wird. Einige Dinge zu berücksichtigen:

• IPv6-Header ist 40 Bytes in eine feste Größe
• Hop-by-Hop-Header ist variabel, aber 4 Bytes mit Router Alert gesetzt
• Das Typ-Feld ist Byte 0 im ICMPv6 Header

Hier ist also das, was wir am Ende mit:

ip6 protochain icmp6 und (ip6 [44] = 130 oder ip6 [44] = 131)

Puh! Wir finally got it! Oder haben wir?

Q: Was passiert, wenn das Paket über zusätzliche Header-Erweiterung?

A: Unser Filter wird nicht funktionieren.

Q: Was ist, wenn die Hop-by-Hop-Header hat mehr Optionen als Router Alert eingestellt?

A: Unser Filter wird nicht funktionieren.

Q: Können wir die beiden oben genannten Probleme?

A: Erst tcpdump / WinDump Filterung IF / THEN Schleife Unterstützung hinzu.

Wenn wir also in den normalen ML-Verkehr aufnehmen möchten, werden die oben genannten Filter funktionieren. Wenn wir aber zu versichern, wir fangen Angreifer Verschlagenheit sowie möchten, wird der Filter nicht zu fliegen.

Was ist, wenn wir versuchen, etwas wie dieses:

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

und dann benutzen Sie einfach Wireshark ist text2cap Werkzeug, um es zu konvertieren Format Libpcap? Das Problem hier ist, werden wir bekommen nur die Header-Informationen. Grep passt auf die Zusammenfassung Linie, die das Wort "Multicast" enthält, aber dann überspringen alle Hex darunter die eigentliche Inhalt des Pakets ist.

So die endgültige Antwort ist: "Ich kann nicht Theyâ von Haya"

So was, wenn Sie wirklich brauchen, um in der Lage sein, um diesen Verkehr zu sehen? Bis Unterstützung für IPv6 reift, ist die einzige 100%-Methode, um alle ICMPv6 Verkehr zu packen und dann manuell durch sie zu sortieren.

Zumindest ist das meine Meinung. Wenn jemand tatsächlich kommen kann, mit einer 100% funktionierende Lösung, würde ich gerne davon hören.

OK, hier ist ein Hinweis auf die Sie in die richtige Richtung weisen.

Die Herausforderung war: "Schreiben Sie eine tcpdump / WinDump Filter, ICMPv6 Multicast Listener Pakete erfassen wird."

Klingt einfach, nicht wahr?

Mit ein wenig Hilfe von Google finden Sie, dass der "Typ" für Multicast Listener 130 ist, und die ICMPv6 Typ-Feld wird das erste Byte in der Kopfzeile. So sollte dies so einfach sein wie:

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

wenn Sie den Befehl ausführen Sie zurück zu bekommen:

tcpdump: IPv6 Protokoll der oberen Schicht wird nicht durch proto [x] unterstützt

Mit anderen Worten, können Sie mit "icmp6", um alle ICMPv6 Pakete zu sehen, aber Sie können nicht verwenden, um auf einem der ICMPv6-Header-Felder zu filtern.

Also brauchen wir einen "Plan B". Finde heraus, Plan B und du hast die Herausforderung gelöst.

Aufbauend auf den IPv6 Herausforderung vom letzten Mal habe ich ein neues für Sie: Schreiben Sie eine tcpdump / WinDump Filter, ICMPv6 Multicast Listener Pakete erfassen wird.

Das ist es! Ziemlich einfach, oder?

Nun, es ist jetzt Donnerstag so dass ich dachte seine Zeit, um die Antworten auf letzte Wochenende der Herausforderung Beitrag.

Erstens, warum sollte man auch über IPv6 egal, ob du nicht angefangen haben, setzt es? Ich fühlte mich viel die gleiche Weise, bis ich IPv6 als eine verdeckte Kommunikationskanal innerhalb eines Client-Netzwerk verwendet gefunden. Die Daten wurden dann durchgeführt, um die Internet via Teredo geschoben. Wenn Sie nicht vertraut mit der Technik sind, hat Scott Hogg einige hervorragende Beiträge zum Thema.

Also selbst wenn Sie derzeit nicht über IPv6, lohnt es sich, fang an zu schneiden die Heilung auf die Technologie als auch gerade für sie in Ihrem lokalen Netzwerk.

So zu überprüfen, war die Herausforderung:

Schreiben Sie eine tcpdump oder WinDump Filter, der den gesamten Datenverkehr mit einer IPv6-Quelladresse des Jahres 2001 wird zu erfassen: db8:: 10 bis 2001: db8:: 20.

Es gibt ein paar Einschränkungen mit dem Schreiben dieses Filters. Die ersten paar deckte ich in den letzten Beitrag. Die letzte, die ich kannte, aber nie wirklich gedacht, war ein Problem, bis ich die Arbeit mit IPv6 ziemlich stark begonnen, ist, dass tcpdump / WinDump nur lassen Sie 1, 2 oder 4 Byte Masken. Während wir also lieben würde, dies mit einer ersten Filter Aussage "ip6 [08.14] =" zu lösen, können wir nicht, weil wir zu 4 Byte begrenzt. Es gibt in der Tat eine Möglichkeit, dies zu umgehen, aber ich werde darauf zurückkommen.

Also hier ist der Filter, mit denen ich gearbeitet habe:

(Ip6 [08.04] = 0x20010db8 und ip6 [12.04] = 0 und ip6 [16.04] = 0 und (ip6 [20.04]> = 0 × 0010 und ip6 [20.04] <= 0050 ))

Bit lang, aber es funktioniert. Elizabeth kam mit einer Lösung, die viel eleganter als meine eigene ist:

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

So, indem Sie mit der Libpcap Format, sie ist in der Lage, meine ersten drei Aussagen miteinander zu kombinieren. Nicht zu einer Größe Königin sein, aber das macht ihre Lösung ist viel kürzer als die meinige. In diesem Fall ist das eine gute Sache.

Das ist alles. Ich werde nach einem anderen IPv6-Typ Herausforderung von morgen.

Wow, ist das Zirpen der Grillen ohrenbetäubend. Sicherlich hat jemand die Fähigkeiten, die uns durch dieses Dilemma zu bekommen?

OK, einige Hinweise Sie durch die Herausforderung zu bekommen. Beginnen wir mit der Lösung dieses wie eine IPv4-Adresse zu starten und dann werden wir unseren Weg in IPv6 arbeiten. Nehmen Sie den Adressbereich wollen wir erfassen ist 192.168.1.10 - 192.168.1.20. Das große Problem ist die IPs nicht auf einer geraden Byte-Grenze. Wir könnten etwas tun:

src net 192.168.1.0/27

aber das würde uns Adressen von 0,0 bis 0,31, mehr IPs als wir eigentlich sehen wollte. Zur Lösung dieses Problems werden wir brauchen, um einige Operatoren und Primitiven verwenden. Eine Möglichkeit ist:

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

Beginnend mit dem innersten Klammern, liest die obige Aussage "Byte 15 muss größer als oder gleich 10, aber es muss auch weniger als oder gleich 20 ist. Wenn diese Aussage wahr ist, stellen Sie sicher, Byte 12 ist gleich 192, wird Byte 13 gleich 168 und Byte 14 ist gleich 1 ist. "

Können wir verkürzen dieser Ausdruck? Absolut! Zuerst müssen wir es aber Hex umwandeln. Warum Hex? Wenn ich eine Aussage wie schreiben "ip [12.02] =" tcpdump davon aus, dass das Ergebnis einer 16-Bit-Zahl, nicht zwei 8-Bit-Zahlen. Aus diesem Grund können Sie so etwas wie "tcp [2:2] = 12345" zu schreiben und zu arbeiten. tcpdump wandelt die zwei Bytes zu einem 16-Bit-Wert und vergleicht sie gegen den Wert, den Sie angegeben. Durch die Umstellung auf Hex wir dieses Problem zu vermeiden. Also:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Jetzt schreiben wir einfach unser Ausdruck:

ip [12.04]> = 0xC0A8010A und ip [0.04] <= 0xC0A80120

Das ist alles dort ist zu ihm.

Während IPv4 verwendet 4-Byte-Adressen verwendet IPv6 16 Byte. Da die Adressen so lang sind, schreiben wir sie in Hex, um Speicherplatz zu sparen. So die Adressen Ich habe Ihnen in der Herausforderung waren:

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

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

Beachte, dass ich zunächst nicht schreiben sie auf diese Weise. Es gibt ein paar Konventionen, die Sie verwenden, um Platz zu sparen kann beim Schreiben einer IPv6-Adresse. Erstens können wir abschneiden führenden Nullen. Also:

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

wird:

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

Jetzt sehen alle, die Nullen in der Mitte? Wir können hacken Sie sie auch. Wenn Sie sehen "::" das bedeutet, in diesem Raum mit genügend Nullen füllen, um die Adresse wieder zu erweitern out bis 16 Byte. So in dieser Trick auch hinzufügen, und wir bekommen:

2001: db8:: 10

Weit einfacher zu schreiben. Der Nachteil ist, kann man nur entfernen Sie eine Gruppe von Nullen mit dem doppelten Doppelpunkt Trick. Betrachten Sie die folgende Adresse:

2001:: 1234:: 10

Wir haben keine Ahnung, wo die Byte-Reihenfolge statt "1234" in der Adresse. Es beginnen überall von Byte 6 bis Byte 12.

Bei der Arbeit mit IPv4 verwenden tcpdump und WinDump das Protokoll Stichwort "ip", wie in den obigen Beispielen gezeigt. Die IPv6 Kompliment, das "ip6". Wo ist die Quell-Adresse Feld im IPv6-Header? Nun, ich kann Ihnen nicht alles beantwortet, oder es ist nicht mehr eine "Herausforderung"

Hier ist eine weitere Herausforderung für Ihre bit wienie Fähigkeiten zu testen:

Schreiben Sie eine tcpdump oder WinDump Filter, der den gesamten Datenverkehr mit einer IPv6-Quelladresse des Jahres 2001 wird zu erfassen: db8:: 10 bis 2001: db8:: 20. Ziemlich einfach, oder? Wenn Sie nicht versucht haben, gehen Sie zu finden, dass tcpdump / WinDump ein paar Kurven auf dich wirft.

So überprüfen Sie Ihre Arbeit, hier ist eine Capture-Datei:

ipv6-icmp

Die Datei enthält eine Mischung aus Quell IPv6-Adressen. Offensichtlich hat Ihr Filter sollte nur Anzeige des angegebenen Bereichs von Adressen.

Der Gewinner erhält zur Ehrfurcht und Bewunderung in geringerem Geeks zu begeistern.

Wenn diese Herausforderung schien schwerer als es sein sollte, sind Sie auf dem richtigen Weg.

Ich rannte über dieses Problem beim Schreiben von meinem Packet Decode -Tool. Ich muss sagen, es war eine coole Übung für mich, da ich nie wirklich über das Erstellen von tcpdump und Wireshark-Filter für jeden möglich, IP, TCP, UDP und ICMP-Feld und / oder Wert gedacht. Bei weitem die TCP-Optionen Feld ist die "broken" von einem Paket entschlüsseln Perspektive als jede andere IP Bereich.

Lassen Sie uns zunächst darüber, wie die TCP-Optionen sollten umgesetzt haben zu sprechen. Wenn man sich die IPv4-Optionen Bereich suchen, beginnt es mit einem "Type"-Kennung. Wenn Sie in eine bestimmte IP-Option interessiert sind, ist es nur eine Frage der Kontrolle auf diesem Gebiet für die richtige Bit-Kombination. Hätte die TCP-Optionen umgesetzt diese Weise würde diese Herausforderung ziemlich geradlinig gewesen.

So gut wie alle TCP-Optionen haben eine "Art" und ein Feld "Länge", die beide 1 Byte groß sind. Die Ausnahmen sind "End of Option List" und "No-Operation", die nur eine Art Feld, und sind somit ein Byte groß. Hier ist eine Liste der gemeinsamen TCP-Optionen:

Seite 15 von RFC 793 sagt uns: "Der TCP-Header (auch wenn einschließlich Optionen) eine ganze Zahl von 32 Bit lang." In anderen Worten muss der TCP-Header-Größe in Bytes werden gleichmäßig durch vier teilbar (20 Byte, 24 Byte, etc.). Wenn man sich die Liste der TCP-Optionen aussehen, nur "Maximum Segment Size" ist durch vier teilbar. So der Einsatz anderer Optionen wirst padding erfordern.

Wie die Polsterung angewendet werden sollte ist ein bisschen unklar. Wenn wir auf Seite 26 Look RFC 1323 finden wir diese:

  ANHANG A: Detaillierte Vorschläge

    Folgende Layouts sind für das Senden von Optionen auf Nicht-SYN empfohlen
    Segmente zu erreichen maximal mögliche Ausrichtung der 32-bit und 64-Bit
    Maschinen.

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

Beachten Sie die NOP padding erscheint vor dem Timestamp-Option, nicht am Ende, wie Sie vielleicht erwarten. Beachten Sie auch die RFC speziell sagt, das ist für "Nicht-SYN-Segmente" und dass es "empfohlen", nicht erforderlich. Scheint jedoch, dass die meisten Betriebssysteme dieser Empfehlung zu folgen und immer Platz Polsterung vor der Art und Länge bytes. Ich habe Windows, Linux, Mac, verschiedene Hardware, etc. überprüft und sie alle stellen die Polsterung am Anfang.

So können wir auf dieser verlassen, dass der "Standard", nicht wahr? Nicht ganz. Seite 17 von RFC 793 beschreibt NOP auf diese Weise:

  Diese Option Code kann zwischen den Optionen verwendet werden, z. B. auf
         Richten Sie den Beginn eines nachfolgenden Option auf eine Wortgrenze.
         Es gibt keine Garantie, dass die Absender wird diese Option verwenden, so
         Empfänger müssen bereit sein, Optionen Prozess sein, auch wenn sie
         nicht auf einer Wortgrenze beginnen. 

Mit anderen Worten, es ist nicht nur so, dass NOP kann oder auch nicht zeigen, bis zu Beginn, könnte NOP überhaupt nicht verwendet werden! Es ist völlig legal, Layout die Option TCP Feld ohne NOP Polsterung und verwenden Sie einfach End of Option List als Füllstoff am Ende die richtige Grenze zu erreichen.

Also, was tun wir am Ende mit für einen Filter? Wenn wir zählen auf NOP vor der Option, die wir am Ende mit einem Filter, der wie folgt aussieht:

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

Zu brechen, was dieser Filter ist dabei:

• Nur überprüfen SYN & SYN / ACK-Pakete: tcp [13] und 2 = 2
• TCP-Header ist größer als 20 Byte (Optionen eingestellt sind): tcp [12] & 240> 80
• Überprüfen Sie das erste Byte eines jeden Vier-Byte-Grenze für NOP: tcp [20] = 1, tcp [24 = 1, ...
• Überprüfen Sie in den nächsten zwei Bytes zu sehen, ob Kind = 3 und Länge = 3: tcp [21.02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...

Wenn wir aber sicherstellen, dass wir alle Möglichkeiten fangen bei wollen ein System nicht implementiert NOP wir am Ende mit:

tcp [13] und 2 = 2 und tcp [12] und 240> 80 und (tcp [20.02] = 0 × 0303 oder tcp [21.02] = 0 × 0303 oder tcp [22.02] = 0 × 0303 oder tcp [23.02] = 0 × 0303 oder tcp [24:2] = 0 × 0303 oder tcp [25:2] = 0 × 0303 oder tcp [26:2] = 0 × 0303 oder tcp [27:2] = 0 × 0303 oder tcp [28:2] = 0 × 0303 oder tcp [29:2] = 0 × 0303 oder tcp [30:2] = 0 × 0303 oder tcp [31:2] = 0 × 0303 oder tcp [32:2] = 0 × 0303 oder tcp [33:2] = 0 × 0303 oder tcp [34:2] = 0 × 0303 oder tcp [35:2] = 0 × 0303 oder tcp [36:2] = 0 × 0303 oder tcp [37:2] = 0 × 0303 oder tcp [38:2] = 0 × 0303 oder tcp [39:2] = 0 × 0303 oder tcp [40:2] = 0 × 0303 oder tcp [ 41:2] = 0 × 0303 oder tcp [42:2] = 0 × 0303 oder tcp [43:2] = 0 × 0303 oder tcp [44:2] = 0 × 0303 oder tcp [45:2] = 0 × 0303 oder tcp [46:2] = 0 × 0303 oder tcp [47:2] = 0 × 0303 oder tcp [48:2] = 0 × 0303 oder tcp [49:2] = 0 × 0303 oder tcp [50 : 2] = 0 × 0303 oder tcp [51,2] = 0 × 0303 oder tcp [52:2] = 0 × 0303 oder tcp [53:2] = 0 × 0303 oder tcp [54:2] = 0 × 0303 oder tcp [55:2] = 0 × 0303 oder tcp [56:2] = 0 × 0303 oder tcp [57:2] = 0 × 0303 oder tcp [58:2] = 0 × 0303)

Der Unterschied mit diesem Filter ist, dass wir die Überprüfung Kind = 3 und Länge = 3 den ganzen Weg durch die Optionen-Feld (als Elizabeth vorgeschlagen).

Kann einer dieser Filter erzeugen Fehlalarme? Absolut! Zwei Möglichkeiten:

1. Der Wert des Timestamp kann mit dem Muster, die wir suchen.
2. Der Filter nimmt eine 40-Byte-Option Feld. Es könnte sein, weniger mit diesen Werten in der Payload.

So, die Filter sollten Sie verwenden? Das erste erzeugt weniger False Positives aber verfehlen Systeme, die RFC-konform, aber anders als die Norm sind. Der zweite wird immer fangen Window Scale, wenn diese festgelegt wurde, aber die Chance eines falsch-positiven höher ist.

Ich werde Elizabeth als Sieger der Herausforderung zu bezeichnen. Ein paar andere waren einfach so nah, aber sie war die einzige, mit dem Mut, ihre Gedanken in den Kommentaren posten. Ich werde einen zweiten Preis an Jeff, die mit dieser Lösung teilweise kidding herum kam award:

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

Dies wird nicht erzeugen eine tatsächliche Paketerfassung, aber man könnte eine zu tun:

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

Und dann laufen die Ausgabe durch txt2cap, um es wieder in pcap-Format. Er folgte nicht der Herausforderung gesagt, aber du mußt geben dickes Lob für das Denken außerhalb der Box, da dies behebt alle falsch positiven Aspekte.

Elizabeth und Jeff, ich werde mit Ihnen Kontakt aufnehmen sowohl per E-Mail. Herzlichen Glückwunsch!

Ich habe einen Thread Beitrag und vier E-Mails, soooooo die richtige Antwort sind zu schließen. Hier ist noch eine letzte Hinweis auf hoffentlich Leute über die letzte Hürde.

Ich erwähnte die hilfreichen tshark Befehl. Hier ist die Ausgabe:

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

Also, was haben Sie über die TCP-Optionen Abschnitt (Byte 20 und höher) der Test-Paket. Die Window Scale Option ist die letzte Option in der Liste.

Ich weiß, schreibe diesen Filter ist nicht einfach. In der Tat, deshalb habe ich es verwandelte sich in eine Herausforderung. Es ist jedoch möglich.