Un moyen pratique de mettre en œuvre la prévention de l'IP Spoofing

Je suis un étudiant de premier cycle en informatique et j'espérais acquérir des connaissances sur les moyens d'éviter la falsification d'IP, mais toutes les ressources que j'ai essayées élaborent ce concept de façon théorique. Je veux essayer mes mains à l'une des techniques suivantes:

Http://fr.wikipedia.org/wiki/Port_knocking

Http://en.wikipedia.org/wiki/SYN_cookies

Comment simuler cette situation entière dans mon propre système, si je suis moi-même l'attaquant et que je dois le défendre? Et une fois que je l'ai compris, puis-je commencer à traduire cela en termes de programmation?

La première chose que vous devez faire est de comprendre les types d'attaques que vous souhaitez protéger contre. Je ne pense pas que n'importe quoi peut vous donner une meilleure compréhension des attaques que d'écrire un code pour effectuer les attaques.

Les trois classes d'attaques que je connais en ce qui concerne la falsification d'IP sont les suivantes :

  • Consommation de ressources sur le serveur
  • Attaques de réflexion
  • Attaques sur la responsabilité

Je vais décrire chacun d'eux plus en détail. La classe de consommation de ressources d'attaque signifie que le serveur recevra une quantité de paquets, dont la plupart ont une IP source falsifiée. Étant donné que les adresses IP falsifiées peuvent avoir une distribution choisie par l'attaquant, il n'y a pas de messages falsifiés à partir de paquets légitimes. Le serveur n'a que des ressources pour gérer un certain nombre de ces paquets, plus le paquet de paquets envoyé par l'attaquant, la plus petite fraction de paquets légitimes peut être gérée par le serveur.

L'attaque typique dans cette classe est l'inondation SYN, qui était des décennies il ya quelques décennies. La ressource qu'il consomme sur le serveur est principalement une mémoire pour conserver l'état de chaque connexion TCP.

Les cookies SYN sont conçus pour protéger exactement contre cette attaque. Ils prennent le concept d'un cookie et le pressent dans la poignée de main TCP. Un cookie est une valeur courte que le serveur envoie au client avec le seul but, que le client puisse le renvoyer au serveur. Cela prouve que le client a reçu le cookie. Le scénario de spoofing habituel ne permet à l'attaquant d'envoyer des paquets à partir d'une adresse IP falsifiée, et ne reçoit pas les paquets que le serveur envoie à cette adresse IP.

Les cookies SYN perdent un peu de fonctionnalité à partir de TCP. Ceci a été une conséquence de la nécessité d'être compatible avec les clients TCP existants et, en même temps, ne pas utiliser de mémoire sur le serveur avant que le client ait prouvé l'adresse IP en renvoyant le cookie.

Le frappement du port échoue dans les deux objectifs de conception mentionnés ci-dessus. Ce n'est pas du tout transparent pour le client. En outre, il faut également que l'état soit stocké même après que le premier (knock) paquet a été envoyé au serveur. Port knocking n'est tout simplement pas conçu pour atténuer la falsification d'IP, il est conçu pour un but entièrement différent. Si vous voulez une protection efficace contre la falsification d'IP et que vous êtes disposé à exiger une mise à jour logicielle sur le client, il existe des approches beaucoup plus efficaces.

Les attaques de réflexion visent à consommer de la bande passante réseau plutôt que des ressources sur le serveur lui-même. De telles attaques mettent l'adresse IP de la victime dans l'IP source et tout serveur approprié dans l'IP de destination. Une fois que le serveur reçoit la demande, il répondra à la source falsifiée avec une réponse qui peut être beaucoup plus grande que la demande. Cela permet à l'attaquant d'inonder une victime avec beaucoup plus de trafic qu'elle n'envoie lui-même.

Plusieurs services basés sur UDP peuvent être utilisés dans cette classe d'attaques. Le DNS et le NTP sont des services bien connus qui, lorsqu'ils reçoivent une petite demande, peuvent envoyer une grande réponse.

La méthode la plus efficace pour se protéger contre les attaques de réflexion est que le serveur n'émet jamais plus d'un paquet en réponse à une demande d'une adresse IP qui n'a pas déjà été prouvée correctement et que cette réponse ne doit contenir plus d'octets que la demande . TCP est généralement considéré comme immunisé contre les attaques de réflexion, mais les services basés sur UDP peuvent être vulnérables.

La troisième classe d'attaques est celle où vous effectuez une transaction complète sur le serveur en utilisant une IP falsifiée dans toute la communication. Tous les logs sur le serveur indiquent que cette transaction a été effectuée par l'IP falsifiée. Ceci est généralement considéré comme une attaque purement théorique.

Habituellement, la communication, là où cela compte vraiment, se fait sur TCP. L'attaquant doit deviner un numéro de séquence de 32 bits pour même établir la connexion. L'attaquant peut également deviner la taille de chaque réponse du serveur. Et si le cryptage est utilisé, l'attaquant peut même deviner une partie du contenu. De plus, l'attaquant doit compléter la transaction avant que l'hôte soit falsifié ait eu le temps d'envoyer un message d'erreur au serveur, ce qui fermerait la connexion.

Comment tester les attaques

En configurant un petit réseau de machines, il n'est pas difficile de falsifier l'IP de n'importe quel hôte sur Internet et d'envoyer des paquets de cette IP à votre propre serveur. Dans le même temps, vous pouvez organiser la table de routage pour acheminer les réponses vers celles vers Internet. Avec cette configuration, vous avez un réseau réaliste pour tester la falsification d'IP. N'oubliez pas de falsifier les adresses IP, qui ne sont pas autorisées à être annoncées via BGP, de sorte que vous ne posez pas de problème pour quelqu'un avec les paquets réfléchis.

Une fois que vous avez configuré, un client TCP ou DNS ordinaire est suffisant pour envoyer des paquets falsifiés vers le serveur. Une inondation réelle nécessiterait un peu plus d'effort d'installation, mais ce n'est pas difficile.

Comment protéger le DNS contre la falsification

Tout d'abord, si vous avez un serveur DNS, vous pouvez détecter qu'il est utilisé dans une attaque de réflexion. Une attaque de réflexion entraînera une erreur ICMP après le retour du serveur à une adresse IP falsifiée.

Que pouvez-vous faire pour atténuer l'attaque? Tout d'abord, vous pouvez suivre les adresses IP prouvées et les adresses IP falsifiées. De toute évidence, la plupart des adresses IP seront dans la catégorie de ne pas savoir. Lorsque vous recevez une erreur ICMP en réponse à une réponse DNS, l'adresse IP est placée dans la catégorie des adresses IP falsifiées. Lorsqu'une IP est entrée dans ce groupe, les mesures d'atténuation doivent être mises en œuvre.

Pour atténuer l'attaque, le serveur DNS envoie une réponse contenant uniquement la requête, mais aucune réponse réelle. De plus, le bit tronqué doit être réglé. Cela indiquera au client de réessayer la demande en utilisant TCP. Une demande réussie sur TCP prouve que l'IP est celle d'un client réel et déplace l'adresse IP vers l'ensemble des adresses IP éprouvées.

Si l'ensemble des adresses IP falsifiées connues augmente plus que vous ne le souhaitez, vous devez simplement arrêter de la suivre et basculer pour utiliser l'atténuation même sur les adresses IP, où l'état falsifié est inconnu.

Comment protéger tous les protocoles contre la spoofing

Le code spécifique du service d'écriture pour chaque service unique exécuté sur UDP ne semble pas être le bon moyen de se protéger contre la falsification. Il devrait y avoir un moyen indépendant du service de protéger contre la falsification.

Je ne pense pas que vous pouvez le faire d'une manière complètement différente. Mais supposons que nous pourrions mettre quelque chose de nouveau entre la couche IP et la couche de transport qui aiderait à la falsification, et supposons que l'on envisage d'enlever suffisamment de problèmes pour déployer une telle protection, alors, à quoi pourrait ressembler cette protection?

J'ai une idée basée sur un en-tête d'extension IPv6 pour y parvenir. J'ai rédigé plus de détails il y a quelques mois. Si vous êtes en mesure de la mettre en œuvre dans une pile IPv6 open source, je serais ravi de traduire mon projet en anglais.