Est-il possible de passer TCP poignée de main avec une adresse IP usurpée?
Il y a peu de temps, mes amis et moi nous sommes disputés si TCP poignée de main peut être passée avec une adresse IP usurpée.
Supposons que j'ai un serveur Web qui n'autorise que certaines adresses IP. Quelqu'un peut-il connecter ce serveur Web par usurpation d'adresse IP?
Réponse courte: non.
Réponse plus longue: oui, si vous contrôlez un périphérique de routeur près du périphérique cible (il doit se trouver sur le chemin entre la véritable adresse IP source et la cible, et sur le chemin entre la fausse adresse IP et la cible) ou si le réseau/l'hôte cible accepte paquets routés par la source .
Réponse courte: Oui, mais pas aussi possible qu'avant, et cela dépend de la façon dont on prend votre question au pied de la lettre.
Longue réponse:
Je remarque que vous n'avez pas demandé "Est-il possible de poursuivre une conversation TCP avec une adresse IP usurpée" - cette question était habile répondu par @symcbean. Vous avez spécifiquement demandé "Est-il possible de passer la poignée de main TCP avec une adresse IP usurpée". Il y a donc une différence entre la question que vous avez posée - "Pouvez-vous usurper SYN-> SYN/ACK-> ACK de telle manière que le serveur pense qu'une connexion a été correctement établie" - et la question que vous vouliez probablement dire - "Pouvez-vous poursuivre une conversation TCP avec une adresse client usurpée ".
Examinons donc la question littérale que vous avez posée. Dans ce cas, la réponse est "Oui, si le numéro de séquence TCP initial inclus dans le SYN/ACK par le serveur est prévisible." C'est pourquoi la prévisibilité ISN (Initial Sequence Number) est quelque chose de testé par les scanners de vulnérabilité, et quelque chose qui est beaucoup plus largement mis en œuvre correctement aujourd'hui qu'il y a 10 ou 15 ans. Pour citer un avis Cisco de 2001 relatif à cette vulnérabilité, " Le cas général de cette vulnérabilité dans TCP est bien connu de la communauté de la sécurité des systèmes d'information. " Le plus célèbre, Mitnick a abusé de cette fonctionnalité dans son attaque contre Shimomura .
À moins que le routage source ou l'accès à un routeur dans le chemin réseau ne soit disponible, ce n'est pas une configuration durable. Le client peut être capable de deviner l'ISN, mais les numéros de séquence ultérieurs sont incrémentés par la taille des paquets envoyés , que l'attaquant ne verra pas et ne peut pas prédire de manière fiable. Ils devraient donc pouvoir recevoir au moins un paquet après la négociation à trois, mais pas une conversation. Et parfois, un paquet suffit.
La prédiction ISN est un sous-ensemble spécifique de attaques de prédiction de séquence TCP . Bien que je ne puisse pas citer de bons chiffres, mon expérience suggère que c'est une vulnérabilité qui a persisté beaucoup plus longtemps qu'elle n'aurait dû; vous exécutez toujours sur des appareils qui échouent à cause de cela. Il est difficile d'amener tout le monde à simplement réparer leurs piles TCP, en particulier lorsque la correction implique une génération de nombres aléatoires robuste, ce qui est quelque peu difficile sur un matériel limité et bon marché (le genre qui est jeté dans les périphériques réseau tous les fois).
Sans accès au réseau derrière l'une des adresses IP autorisées ou accès à une machine derrière l'une des adresses IP autorisées, vous pouvez ne pas passer un - TCP 3-way handshake avec une adresse IP usurpée.
Il est facile d'envoyer un TCP avec n'importe quelle adresse IP. Sous Linux, vous pouvez ouvrir un socket brut et envoyer tout ce que vous voulez. Le problème est de recevoir le SYN/ACK (ou toute autre réponse) , qui sera routé vers l'IP d'origine.
Les routeurs entre votre client peuvent avoir des règles de pare-feu pour rejeter la demande, mais ils supposent souvent que votre client achemine simplement un paquet à partir d'un autre hôte.