Si ce défi semblait difficile que ce qu'elle devrait être, vous êtes sur la bonne voie. 
J'ai couru à travers ce problème lorsque l'écriture de mon Decode Packet outil. Je dois dire, il a été un exercice cool pour moi, comme je n'ai jamais vraiment pensé à créer tcpdump et filtres Wireshark pour chaque IP possibles, TCP, UDP et ICMP de terrain et / ou de valeur. De loin le champ des options TCP est le plus "cassé" dans une perspective de décoder les paquets que tout autre champ IP.
D'abord nous allons parler de comment les options TCP doit avoir été mis en œuvre. Si vous regardez le champ options IPv4, il commence par un "type" identifiant. Si vous êtes intéressé par une option IP spécifique, il est juste une question de vérification de ce domaine pour la combinaison de bits de droite. Si les options TCP été mis en œuvre de cette façon, ce défi aurait été assez simple.
Juste au sujet de toutes les options TCP ont un «genre» et une «longueur» de terrain, qui sont tous deux 1 octet en taille. Les exceptions sont les «Fin de la liste des options" et "Non-fonctionnement" qui ont seulement un champ Kind, et sont donc un octet en taille. Voici une liste des options TCP commun:
Page 15 de la RFC 793 nous dit: "L'en-tête TCP (même y compris les options) est un nombre entier de 32 bits de long." En d'autres termes, la taille en octets en-tête TCP doit être divisible par quatre (20 octets, 24 octets, etc.) Si vous regardez la liste des options TCP, seul "taille maximale de segment" est divisible par quatre. Ainsi, l'utilisation de toute autre option vont exiger un rembourrage.
Comment le rembourrage doit être appliqué est un peu floue. Si l'on regarde la page 26 de la RFC 1323 , nous trouvons ceci:
ANNEXE A: SUGGESTIONS DE MISE EN ŒUVRE
Les dispositions suivantes sont recommandées pour les options d'envoi sur la non-SYN
segments, pour atteindre un maximum d'alignement possible du 32-bit et 64-bit
des machines.
+--------+--------+--------+--------+
| NOP | NOP | TSopt | 10 |
+--------+--------+--------+--------+
Timestamp TSval | |
+--------+--------+--------+--------+
| Timestamp TSecr |
+--------+--------+--------+--------+ Notez le rembourrage NOP apparaît devant l'option d'horodatage, et non pas à la fin comme on pouvait s'y attendre. A noter également la RFC dit spécifiquement ce n'est pour "non-SYN segments" et qu'il est «recommandé», pas nécessaire. Semble cependant que la plupart des systèmes d'exploitation suivre cette recommandation et toujours placer un rembourrage avant la nature et les octets de longueur. J'ai vérifié sous Windows, Linux, Mac, matériels divers, etc et ils ont tous mis du rembourrage au début.
Donc nous pouvons compter sur ce qui est le "standard", pas vrai? Pas tout à fait. Page 17 de la RFC 793 décrit NOP cette façon:
Ce code option peut être utilisée entre les options, par exemple, pour
d'aligner le début d'une option ultérieure sur une frontière de mot.
Il n'ya aucune garantie que les expéditeurs utilisent cette option, donc
récepteurs doivent être prêts à traiter les options même si elles ne
commence pas sur une frontière de mot. En d'autres termes, ce n'est pas juste que les NOP peut ou peut ne pas apparaître au début, NOP ne pourrait pas être utilisé à tous! Il est tout à fait légal d'aménagement du champ de l'option TCP sans rembourrage NOP et il suffit d'utiliser l'option Fin de la liste en tant que charge à la fin pour atteindre la frontière adéquate.
Alors qu'est-ce que nous nous retrouvons avec un filtre? Si nous comptons sur NOP avant que l'option nous nous retrouvons avec un filtre qui ressemble à ceci:
tcp [13] & 2 = 2 et le protocole TCP [12] & 240> 80 et ((tcp [20] = 1 et TCP [21:02] = 0 × 0303) ou (tcp [24] = 1 et TCP [25:2 ] = 0 × 0303) ou (tcp [28] = 1 et TCP [29:2] = 0 × 0303) ou (tcp [32] = 1 et TCP [33:2] = 0 × 0303) ou (tcp [ 36] = 1 et TCP [37:2] = 0 × 0303) ou (tcp [40] = 1 et TCP [41:2] = 0 × 0303) ou (tcp [44] = 1 et TCP [45:2 ] = 0 × 0303) ou (tcp [48] = 1 et TCP [49:2] = 0 × 0303) ou (tcp [52] = 1 et TCP [53:2] = 0 × 0303) ou (tcp [ 56] = 1 et TCP [57:2] = 0 × 0303))
Pour briser ce ce filtre est fait:
- Ne vérifie SYN & paquets SYN / ACK: tcp [13] & 2 = 2
- En-tête TCP est supérieur à 20 octets (les options sont définies): tcp [12] & 240> 80
- Vérifiez le premier octet de chaque limite de quatre octets pour le NOP: tcp [20] = 1, tcp [24 = 1, ...
- Vérifiez les deux octets suivants pour voir si Kind = 3 et Longueur = 3: tcp [21:02] = 0 × 0303, tcp [25:2] = 0 × 0303, ...
Si toutefois nous voulons nous assurer que nous attrapons toutes les possibilités dans le cas d'un système ne donne pas suite NOP nous nous retrouvons avec:
tcp [13] & 2 = 2 et le protocole TCP [12] & 240> 80 et (tcp [20:02] = 0 × 0303 ou TCP [21:02] = 0 × 0303 ou TCP [22:02] = 0 × 0303 ou tcp [23:02] = 0 × 0303 ou TCP [24:2] = 0 × 0303 ou TCP [25:2] = 0 × 0303 ou TCP [26:2] = 0 × 0303 ou TCP [27:2] = 0 × 0303 ou TCP [28:2] = 0 × 0303 ou TCP [29:2] = 0 × 0303 ou TCP [30:2] = 0 × 0303 ou TCP [31:2] = 0 × 0303 ou TCP [32:2] = 0 × 0303 ou TCP [33:2] = 0 × 0303 ou TCP [34:2] = 0 × 0303 ou TCP [35:2] = 0 × 0303 ou TCP [36:2] = 0 × 0303 ou TCP [37:2] = 0 × 0303 ou TCP [38:2] = 0 × 0303 ou TCP [39:2] = 0 × 0303 ou TCP [40:2] = 0 × 0303 ou TCP [ 41:2] = 0 × 0303 ou TCP [42:2] = 0 × 0303 ou TCP [43:2] = 0 × 0303 ou TCP [44:2] = 0 × 0303 ou TCP [45:2] = 0 × 0303 ou TCP [46:2] = 0 × 0303 ou TCP [47:2] = 0 × 0303 ou TCP [48:2] = 0 × 0303 ou TCP [49:2] = 0 × 0303 ou TCP [50 : 2] = 0 × 0303 ou TCP [51:2] = 0 × 0303 ou TCP [52:2] = 0 × 0303 ou TCP [53:2] = 0 × 0303 ou TCP [54:2] = 0 × 0303 ou TCP [55:2] = 0 × 0303 ou TCP [56:2] = 0 × 0303 ou TCP [57:2] = 0 × 0303 ou TCP [58:2] = 0 × 0303)
La différence avec ce filtre est que nous vérifions Kind = 3 et Longueur = 3 tout le chemin à travers le champ d'options (comme Elizabeth suggéré).
Pouvez-un de ces filtres générer des faux positifs? Absolument! Deux possibilités:
- La valeur de timestamp peut correspondre au modèle que nous recherchons.
- Le filtre prend un champ 40 octets d'option. Il pourrait être inférieur à ces valeurs dans la charge utile.
Ainsi le filtre qui doit-on utiliser? La première va générer moins de faux positifs, mais manquent de systèmes qui sont conformes à la RFC, mais différent de la norme. Le second sera toujours attraper Window Scale si elle a été fixée, mais la chance d'un faux positif est plus élevé.
Je vais désigner Elisabeth comme le gagnant du défi. Quelques autres ont été tout aussi proche, mais elle était la seule à avoir le courage d'afficher son train de pensée dans les commentaires. Je vais attribuer un deuxième prix à Jeff qui est venu avec cette solution partielle plaisante:
tcpdump-nn | »wscale grep> wscale-matches.txt
Ce ne sera pas de générer une capture de paquets réels, mais vous pourriez faire un:
tcpdump-nn-X-s 0 | 'wscale grep> wscale-matches.txt
Et puis exécutez la sortie par txt2cap de le récupérer au format pcap. Il n'a pas suivi le défi spécifique, mais tu dois donner des kudos pour sortir des sentiers battus que cela résout tous les problèmes de faux positifs.
Elisabeth et Jeff, je vais être à la fois vous contacter par e-mail. Félicitations!
