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:
- Der Wert des Timestamp kann mit dem Muster, die wir suchen.
- 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!
