Une règle iptables sur mon serveur de base de données est :
-A INPUT -p tcp --dport 6432 -s 10.115.0.150 -j ACCEPTJ'ai d'autres règles (boucle locale, etc.), mais je me demande si cette règle spécifique peut être "piratée". Est-ce que quelqu'un peut simplement "spoof" l'adresse IP (même si c'est une adresse de réseau privé - aussi, serait-ce différent si c'était une adresse publique) ? Quelque chose de différent ?
La réponse de Iain est généralement correcte, mais nécessite un peu d'explication pour expliquer pourquoi l'attaque serait difficile à exécuter.
TCP utilise une combinaison de drapeaux basés sur les bits et de compteurs sur 32 bits, appelés numéros de séquence et d'acquittement, pour piloter la machine d'état qui suit la progression d'une connexion TCP tout au long de sa vie. Comprendre comment ces deux compteurs sur 32 bits interviennent dans le handshake à trois voies qui précède le transfert des données de charge utile dans chaque connexion TCP clarifiera l'impraticabilité des attaques utilisant des adresses IP source falsifiées.
Lorsqu'un client initie une connexion TCP avec un serveur distant, il envoie un segment TCP avec le bit SYN activé et un numéro de séquence initial choisi de manière aléatoire. Le serveur distant répond avec un segment TCP avec à la fois les bits SYN et ACK activés, un numéro de séquence initial choisi de manière aléatoire, et un numéro d'acquittement égal au numéro de séquence initial du client plus 1. Enfin, le client répond avec un segment TCP avec le bit ACK activé, un numéro de séquence égal au numéro de séquence initial qu'il a envoyé plus 1, et un numéro d'acquittement égal au numéro de séquence initial du serveur distant plus 1.
Lorsqu'un attaquant falsifie des datagrammes IP en utilisant une adresse IP source d'un autre hôte, il est généralement le cas que l'attaquant ne reçoit pas les réponses à tout paquet qu'il pourrait envoyer. Dans un tel scénario, l'attaquant dispose, en effet, d'un canal de communication à sens unique vers le serveur distant. En examinant le flux de paquets dans le handshake TCP, il serait nécessaire que l'attaquant prédise le numéro de séquence initial que le serveur distant va générer dans sa réponse SYN/ACK afin de répondre avec le bon numéro d'acquittement dans la réponse ACK pour compléter le handshake à trois voies. L'attaquant doit deviner correctement un numéro sur 32 bits pour que l'attaque fonctionne.
Aujourd'hui, ce type d'attaque est totalement impraticable. Dans le passé, cependant, quelques attaques très médiatisées ont utilisé cette méthode. C'était possible car, dans le passé, certains systèmes d'exploitation avaient des numéros de séquence initiaux très prévisibles. (Vous pourriez trouver le document de Michal Zalewski sur Les Attracteurs Étranges et L'Analyse des Numéros de Séquence TCP/IP - Un An Plus Tard une lecture intéressante, en termes de décrire la prévisibilité des numéros de séquence initiaux de divers systèmes d'exploitation.)
Pas dans des circonstances normales.
Le protocole TCP a un handshake en 3 étapes pour établir une connexion
Hôte A envoie un paquet SYN à l'hôte B
L'hôte B envoie un paquet SYN ACK à l'hôte A
L'hôte A envoie un paquet ACK à l'hôte B et la connexion est établie
Maintenant, si nous introduisons un Hôte C qui usurpe l'adresse de l'Hôte A
Hôte C envoie un paquet SYN usurpé à l'hôte B
L'hôte B envoie un paquet SYN ACK à l'hôte A L'hôte A ne s'attendant pas à un SYN ACK, l'ignore simplement.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
1 votes
Connexe serverfault.com/questions/90725/…