2009-03-28 15 views
14

Je travaille actuellement sur un programme qui renifle les paquets TCP envoyés et reçus vers et depuis une adresse particulière. Ce que j'essaye d'accomplir répond avec des paquets faits sur commande sur mesure à certains paquets reçus. J'ai déjà fait l'analyse. Je peux déjà générer des paquets Ethernet, IP et - pour la plupart - TCP.TCP: Comment les numéros seq/ack sont-ils générés?

La seule chose que je n'arrive pas à comprendre est comment les numéros seq/ack sont déterminés.

Bien que cela puisse être sans rapport avec le problème, le programme est écrit en C++ en utilisant WinPCap. Je demande des conseils, des articles ou d'autres ressources susceptibles de m'aider.

+0

Le meilleur endroit pour l'information normalisée est habituellement le RFC original (Request for comments), dans ce cas, [RFC 2018] (http: //tools.ietf .org/html/rfc2018). En général [Wikipedia] (http://en.wikipedia.org/wiki/Transmission_Control_Protocol) est également un bon endroit pour regarder. A défaut, vous êtes presque assuré d'obtenir des résultats [ici] (http://tinyurl.com/dkkjfn). –

Répondre

23

Lorsqu'une connexion TCP est établie, chaque côté génère un nombre aléatoire comme numéro de séquence initial. C'est un nombre fortement aléatoire: il y a des problèmes de sécurité si quelqu'un sur Internet peut deviner le numéro de séquence, car il peut facilement créer des paquets à injecter dans le flux TCP. Par la suite, pour chaque octet transmis, le numéro de séquence sera incrémenté de 1. Le champ ACK est le numéro de séquence de l'autre côté, renvoyé pour accuser réception.

La RFC 793 (la spécification de protocole TCP d'origine) serait d'une grande aide.

+2

N'est pas le champ ack * pas * le seq # de l'autre côté, mais seq # + longueur reçue (comme dans la réponse zainee khan ci-dessous) –

0

Les numéros de séquence augmentent après l'établissement d'une connexion. Le numéro de séquence initial sur une nouvelle connexion est idéalement choisi au hasard, mais beaucoup d'OS ont un algorithme semi-aléatoire. Les RFC sont le meilleur endroit pour en savoir plus TCP RFC.

1

RFC 793 La section 3.3 couvre les numéros de séquence. La dernière fois que j'ai écrit du code à ce niveau, je pense que nous avons juste gardé un compteur pour les numéros de séquence qui persistaient.

1

Ces valeurs font référence aux décalages attendus du début de la charge utile du paquet par rapport au numéro de séquence initial de la connexion.

Reference

numéro de séquence (32 bits) - a un double rôle Si le drapeau SYN est défini, ce est le numéro de séquence initial. Le numéro de séquence de la première réelle octet de données sera alors cette séquence nombre plus 1. Si le drapeau SYN est pas ensemble, alors c'est le numéro de séquence du premier octet de données

Acquittement nombre (32 bits) - si l'indicateur ACK est , la valeur de ce champ est l'octet attendu suivant que le récepteur attend.

1

Les nombres sont générés aléatoirement des deux côtés, puis augmentés du nombre d'octets (octets) envoyés.

2

Il semble que le reste des réponses a expliqué à peu près tout sur l'endroit où trouver des informations détaillées et officielles sur ACK, à savoir TCP RFC

Voici une page « comprise facile » plus pratique et que je trouvais quand je faisais la même mises en œuvre qui peuvent également aider TCP Analysis - Section 2: Sequence & Acknowledgement Numbers

+0

Merci pour le lien :) – xian

+0

merci pour le lien –

4

Si je vous comprends bien - vous essayez de monter un TCP SEQ prediction attack. Si c'est le cas, vous voudrez étudier les spécificités du générateur Initial Sequence Number de votre système d'exploitation cible.

Il y avait des vulnérabilités largement publicisées à peu près all the major OS's avec leurs générateurs ISN étant prévisibles. Je n'ai pas suivi de près les retombées, mais je crois comprendre que la plupart des fournisseurs ont publié des correctifs à randomize their ISN increments.

4

J'ai le même travail à faire. Premièrement, le seq # initial sera généré aléatoirement (0-4294967297). Ensuite, le récepteur comptera la longueur des données reçues et enverra l'ACK de seq# + length = x à l'expéditeur. La séquence sera alors x et l'expéditeur enverra les données. De même, le récepteur comptera la longueur x + length = y et envoyer l'ACK comme y et ainsi de suite ... Sa façon dont le seq/ack est générée ...

Si vous voulez montrer essayer pratiquement renifler un paquet dans Wireshark et suivez le flux TCP et voyez le scénario ...

+1

Améliorer la clarté de votre réponse. – JSuar

+0

vous pouvez également capturer des paquets à partir du terminal comme ceci: sudo tcpdump -i eth0 – zee