Le défi était: "Ecrire un filtre tcpdump / WinDump qui va capturer les paquets ICMPv6 Multicast Listener.« J'ai une vaste écrire sur ce qui fait la réponse si complexe. Si vous connaissez l'IPv6 et veulent juste la réponse, passez à la fin.

D'abord, le contexte

Steinar a fait quelques commentaires sur les publications précédentes et a été de 100% sur la bonne voie. Si vous les lisez et j'ai pensé «Wow, ça sonne vraiment désordre», vous comprenez l'ampleur du problème ainsi.

Protocole Vs. Champ-tête suivant

Avec IPv4 nous avons eu le champ des options. Cela pourrait provoquer l'en-tête IP pour passer de 20 octets à aussi grande que 60 octets en taille. Avec IPv6, il n'est plus un champ de possibilités et de l'en-tête est fixé à 40 octets. Lorsque les options sont nécessaires, nous utilisons têtes d'extension pour les identifier. Cela jette une balle courbe intéressante à nous, car avec le champ protocole IPv4 (octet 9) serait (presque) toujours d'identifier le transport de niveau supérieur (TCP, UDP, etc.) Avec IPv6 le champ d'en-tête suivant (octet 6) pourraient identifier le transport de la couche supérieure, ou il pourrait identifier une tête d'extension qui comprendra un certain nombre d'options.

Voici une liste de quelques têtes d'extension IPv6 que vous pourriez rencontrer, ainsi que les RFC qui les définissent:

IPv6 ne limite pas le nombre de têtes d'extension, vous pouvez utiliser dans une seule packet.There est cependant une publication "afin recommandé" la façon dont les têtes doivent être énoncées. L'ordre est:

• Tête IPv6
• Hop-by-Hop options
• Entête de routage
• Fragment tête
• AH
• ESP
• Options de destination
• Tête de mobilité
• TCP/UDP/ICMPv6

Notez que cette liste est «recommandé», mais pas obligatoire. Un hôte IPv6 doit être capable de traiter les en-têtes de ce que jamais l'ordre de leur réception. Cela signifie que vous trouverez probablement fournisseurs suivants cette liste, mais pas les attaquants. J'ai personnellement vu des dispositifs de commencer à agir vraiment bizarre quand vous salir avec l'ordre d'en-tête. En fait j'ai couru à travers un peu de "code compatible IPv6", qui ne peut pas traiter si l'ordre de préférence n'est pas utilisé.

Chasing l'entête du protocole

Donc, avec l'IPv6 que nous pouvons avoir plusieurs en-têtes derrière la tête IPv6. Si cela ressemble à un nouveau concept, il n'est pas réellement. En fait, vous avez probablement déjà travaillé avec elle. Lorsque vous déployez les deux protocoles IPSec de sécurité possibles sont ESP et AH. Il s'agissait en fait empruntée à l'IPv6 et massé à travailler sur IPv4. AH et ESP inclure un champ d'en-tête suivante pour identifier ce type de paquet, ils sont protecting.This est appelée chaînage du protocole, comme vous avez effectivement plusieurs en-têtes assis derrière l'en-tête du protocole de couche 3.

Donc, pour comprendre ce que le transport de niveau supérieur (TCP, UDP, etc) est utilisé, vous pouvez avoir à chercher dans plusieurs en-têtes avant de trouver la réponse. Ceci est appelé «chassant l'en-tête", et tcpdump / WinDump nous donner une option de filtre pour effectuer cette tâche. Vous pouvez être fimiliar avec le filtre proto. Dans le monde IPv4, si je dis:

ip proto tcp

Ce filtre se lit «chèque octet 9 de l'en-tête IPv4 et si la valeur est égale à 6 (valeur de protocole pour TCP), un match sur le paquet". Ce filtre n'est pas aussi efficace dans le monde IPv6, bien sûr, car l'octet 6 de l'en-tête IPv6 pourraient identifier le transport de la couche supérieure, ou il peut simplement identifier un en-tête d'extension optionnel qui est utilisé. Pour résoudre ce problème, le filtre protochain a été introduite. Rédaction:

ip6 protochain tcp

Se lit comme "Check octet 6 de l'en-tête IPv6 pour voir si la valeur est égale à 6. Si au contraire vous trouver une valeur qui identifie une tête d'extension en option, vérifiez le champ d'en-tête d'extension de tête suivant pour une valeur de 6. Si vous trouvez plus de têtes d'extension optionnelle, ne cesse de répéter le dernier test jusqu'à ce que vous trouver la tête de la dernière prolongation ».

Assez simple d'écrire en anglais, mais cela est un cauchemar pour mettre en œuvre dans le code. La plupart des têtes d'extension optionnels sont de longueur variable, qui ne fait qu'ajouter à la complexité. J'ai fait quelques tests avec Scapy et vous pouvez réellement voir la différence dans les performances lors de protochain est invoquée. En fait, vous pourriez probablement faire un bon travail de dosage un IDS / IPS en le forçant à traiter un grand nombre de têtes d'extension inutile.

Ecrire notre filtre

Donc, notre premier problème par écrit le filtre défi est que l'en-tête ICMPv6 peuvent ne pas apparaître immédiatement après l'en-tête IPv6. Nous devons nous méfier des têtes d'extension optionnelle. En fait RFC 2710 stipule: "Tous les messages MLD décrites dans ce document sont envoyés avec une adresse de lien local IPv6 source, une limite de 1 IPv6 Hop, et une option routeur IPv6 Alert [RTR-ALERT] dans un Hop-by-Hop tête Options ". Cela signifie que nos paquets Multicast Listener est nécessaire d'avoir une tête d'extension Hop-by-Hop avec l'option d'alerte du routeur. Dans cet esprit, notre première vérification devrait être:

ip6 protochain icmp6

Pour nous assurer que nous ne regardant paquets ICMPv6. Maintenant, il est juste une question de vérification pour voir si le champ Type (octet 0) est fixé à 130 (Multicast Listener Query) ou 131 (Multicast Listener Report). Ceci nous amène à notre second problème cependant. Dans le monde IPv4 je peux faire un:

ICMP [0] = valeur <type de interest>

Si j'essaie cela avec icmp6 j'obtiens:

[Root @ fubar ~] # tcpdump-nn icmp6 [0] = 130
tcpdump: IPv6 protocole de couche supérieure n'est pas supporté par proto [x]

En d'autres termes, je ne peux pas utiliser les compensations avec les icmp6 pour rechercher des valeurs spécifiques. WinDump et tcpdump sont annoncés comme compatibles avec IPv6, mais ne vous attendez pas à obtenir toutes les mêmes fonctionnalités que vous avez avec IPv4. Beurk!

Alors, que faisons-nous? Nous aurons à se replier sur le référencement de la valeur à partir d'un ip6 offset. En d'autres termes, nous aurons à mesurer à travers l'en-tête IPv6, à travers la nécessaire Hop-by-Hop-tête, et dans la tête ICMPv6 pour voir si le champ type est fixé à 130 ou 131. Certaines choses à prendre en considération:

• Tête IPv6 est fixé à 40 octets
• Hop-by-Hop-tête est variable, mais 4 octets avec Router Alert jeu
• Le champ type est de 0 octet dans l'en-tête ICMPv6

Alors voici ce que nous nous retrouvons avec:

ip6 protochain icmp6 et (ip6 [44] = 130 ou ip6 [44] = 131)

Ouf! Nous avons finalement eu! Ou avons-nous?

Q: Que faire si le paquet a-têtes d'extension supplémentaires?

R: Notre filtre ne fonctionnera pas.

Q: Que faire si l'entête Hop-by-Hop a plus d'options mis à Router Alert?

R: Notre filtre ne fonctionnera pas.

Q: Peut-on fixer les deux problèmes ci-dessus?

R: Non jusqu'au tcpdump / WinDump filtrage ajoute SI soutien boucle / THEN.

Donc, si nous voulons capturer le trafic ML normal, le filtre ci-dessus fonctionne parfaitement. Si toutefois nous voulons nous assurer que nous rattraper rouerie attaquant ainsi, le filtre ne va pas voler.

Que si nous essayons quelque chose comme ceci:

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

et ensuite il suffit d'utiliser l'outil Wireshark text2cap pour le convertir en format de Libpcap? Le problème ici est que nous ne recevoir que les informations d'en-tête. Grep va correspondre à la ligne de résumé, qui contient le mot «Multicast» mais ensuite sauter toutes les Hex-dessous de lui qui est le contenu réel du paquet.

Donc la réponse finale est: "Impossible d'obtenir à partir theyâ haya"

Alors que faire si vous avez vraiment besoin d'être en mesure de voir ce trafic? Jusqu'au support IPv6 arrive à maturité, la seule méthode 100% est de saisir l'ensemble du trafic ICMPv6 et ensuite trier manuellement à travers elle.

Du moins c'est mon avis à ce sujet. Si quelqu'un peut effectivement arriver à une solution de travail à 100%, je serais ravi de l'entendre.

OK, voici un indice pour vous diriger dans la bonne direction.

Le défi était: "Ecrire un filtre tcpdump / WinDump qui va capturer les paquets ICMPv6 Multicast Listener".

Cela semble facile, non?

Avec un peu d'aide de Google, vous trouverez que le «type» pour Multicast Listener est de 130, et le champ type ICMPv6 est le premier octet de l'en-tête. Donc, ce devrait être aussi simple que:

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

Toutefois, si vous exécutez la commande que vous obtiendrez de retour:

tcpdump: IPv6 protocole de couche supérieure n'est pas supporté par proto [x]

En d'autres termes, vous pouvez utiliser "icmp6" pour voir tous les paquets ICMPv6, mais vous ne pouvez pas l'utiliser pour filtrer sur l'un des champs d'entête ICMPv6.

Nous avons donc besoin d'un «plan B». Figure dehors de plan B et que vous avez résolu le problème.

S'appuyant sur le défi IPv6 depuis la dernière fois, j'ai une nouvelle pour vous: écrire un filtre tcpdump / WinDump qui capture les paquets ICMPv6 Multicast Listener.

Ça y est! Assez facile, non?

Eh bien aujourd'hui jeudi son alors j'ai pensé de son temps de poster les réponses à contester week-end dernier.

D'abord, pourquoi devriez-vous même les soins au sujet d'IPv6 si vous n'avez pas commencé à le déployer? J'ai senti la même manière jusqu'à ce que je trouve IPv6 étant utilisé comme un canal de communication secrète au sein du réseau d'un client. Les données ont ensuite été poussés hors de l'Internet via Teredo. Si vous n'êtes pas familier avec la technique, Scott Hogg a certains postes excellents sur le sujet.

Donc même si vous n'utilisez pas actuellement IPv6, il paye pour commencer à couper le remède à la technologie ainsi que de regarder pour cela sur votre réseau local.

Donc, pour examen, le défi était:

Ecrire un filtre tcpdump ou WinDump qui va capturer tout le trafic avec une adresse IPv6 source de l'année 2001: db8:: 10 à 2001: db8:: 20.

Il ya un couple de mises en garde avec l'écriture de ce filtre. L'J'ai quelques premiers couverts dans le dernier post. Le dernier, que je connaissais, mais jamais vraiment pensé a un problème jusqu'à ce que je commence à travailler avec IPv6 assez fortement, c'est que tcpdump / WinDump ne vous laisser utiliser 1, 2 ou 4 masques d'octets. Ainsi, alors que nous serions ravis de résoudre ce avec une déclaration initiale filtre "ip6 [8:14] =", nous ne pouvons pas parce que nous sommes limités à 4 octets. Il est en fait un moyen de contourner ce problème, mais je vais y revenir.

Alors, voici le filtre, j'ai travaillé avec:

(Ip6 [08:04] = 0x20010db8 et ip6 [12:04] = 0 et ip6 [16:04] = 0 et (ip6 [20:04]> = 0 × 0010 et ip6 [20:04] <= 0050 ))

Peu long, mais ça fonctionne. Elisabeth a trouvé une solution qui est beaucoup plus élégante que le mien:

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

Ainsi, en commençant par le format libpcap, elle est capable de combiner mes trois premiers relevés en un seul. Pour ne pas être une reine de taille, mais qui rend sa solution est beaucoup plus courte que la mienne. Dans ce cas c'est une bonne chose.

C'est à ce sujet. Je vais poster un autre défi de type IPv6 demain.

Wow, le chant des grillons est assourdissant. Il ya sûrement quelqu'un a les compétences pour nous aider à traverser ce dilemme?

OK, quelques conseils pour vous aider à traverser le défi. Commençons par résoudre ce que d'une adresse IPv4 et ensuite nous ferons notre chemin vers l'IPv6. Supposons que la plage d'adresse que nous voulons pour capturer est 192.168.1.10 - 192.168.1.20. Le gros problème est l'IP ne sont pas sur une frontière, même octet. Nous pourrions faire quelque chose comme:

src net 192.168.1.0/27

mais ce serait nous donner les adresses de 0.0 à 0.31, plus les IP que ce que nous voulions voir. Pour résoudre ce problème nous aurons besoin d'utiliser certains opérateurs et primitives. Une possibilité est la suivante:

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

En commençant par les parenthèses les plus intérieures, la déclaration ci-dessus se lit «octet 15 doit être supérieure ou égale à 10, mais il doit également être inférieur ou égal à 20. Si cette affirmation est vraie, assurez-octet est égal à 12 192, 13 octets est égale à 168 bits et de 14 est égal à 1. "

Peut-on raccourcir cette expression? Absolument! Nous devons d'abord le convertir en hexadécimal cependant. Pourquoi Hex? Si j'écris un énoncé tel que «ip [12:02] =" tcpdump va supposer que le résultat sera un nombre de 16 bits, pas deux nombres de 8 bits. C'est pourquoi vous pouvez écrire quelque chose comme "tcp [2:2] = 12345" et le faire fonctionner. tcpdump convertit les deux octets en une valeur 16 bits et elle correspond à la valeur spécifiée. En convertissant au Hex nous éviter ce problème. Donc:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Maintenant nous écrivons simplement notre expression:

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

C'est tout ce qu'il ya à faire.

Alors que les adresses IPv4 utilise 4 octets, IPv6 utilise 16 octets. Parce que les adresses sont si longtemps, nous les écrire en hexadécimal pour économiser de l'espace. Donc les adresses que je t'ai donné dans le défi étaient:

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

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

Remarquez que je n'ai pas initialement leur écrire de cette façon. Il ya quelques conventions, vous pouvez utiliser pour économiser de l'espace lors de l'écriture d'une adresse IPv6. Premièrement, nous avons peut tronquer les zéros de tête. Donc:

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

devient:

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

Maintenant, voir tous ces zéros dans le milieu? Nous pouvons les couper trop. Quand vous voyez "::" cela signifie que pour remplir cet espace avec des zéros assez pour développer l'adresse de retour vers 16 octets. Alors ajouter dans cette astuce ainsi et nous obtenons:

2001: db8:: 10

Beaucoup plus facile à écrire. La mise en garde est que vous ne pouvez supprimer un groupe de zéros avec l'astuce du double deux points. Considérer l'adresse suivante:

2001:: 1234:: 10

Nous n'avons aucune idée où placer la séquence d'octets "1234" dans l'adresse. Il commence n'importe où à partir d'octets 6 à 12 octets.

Lorsque vous travaillez avec IPv4, tcpdump et WinDump utiliser le mot clé le protocole "IP", comme le montrent les exemples ci-dessus. Le compliment IPv6 qui est "ip6". Où est le champ d'adresse source dans l'en-tête IPv6? Eh bien je ne peux pas vous donner tout ce qu'il ya des réponses ou qu'il n'est plus un «défi»

Voici un autre défi pour tester vos compétences wienie bits:

Ecrire un filtre tcpdump ou WinDump qui va capturer tout le trafic avec une adresse IPv6 source de l'année 2001: db8:: 10 à 2001: db8:: 20. Assez facile, non? Si vous ne l'avez pas essayé, vous allez trouver que tcpdump / WinDump jette quelques courbes à vous.

Pour vérifier votre travail, voici un fichier de capture:

ipv6-icmp

Le fichier contient un mélange d'adresses IPv6 source. Evidemment, votre filtre doit afficher uniquement la gamme d'adresses spécifiée.

Le gagnant obtient pour inspirer la crainte et l'admiration en moins geeks.

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:

1. La valeur de timestamp peut correspondre au modèle que nous recherchons.
2. 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!

J'ai eu un poste de fil et quatre e-mails qui sont hyper proche de la bonne réponse. Voici un indice dernier nous espérons obtenir des gens au cours de la dernière haie.

J'ai mentionné la commande tshark utile. Voici le résultat:

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

Donc ce que vous avez ci-dessus est la section options TCP (octet 20 et supérieur) du paquet de test. L'option Window Scale est la dernière option dans la liste.

Je sais écrire ce filtre n'est pas facile. En fait, c'est pourquoi je l'ai transformé en un véritable défi. Il est cependant possible.