Les adresses IP sont-elles «triviales à forger»?

Je lisais certaines des notes relatives au nouveau service DNS public de Google :

• Avantages de performance
• Avantages de la sécurité

J'ai remarqué dans la section sécurité ce paragraphe:

Jusqu'à ce qu'une solution standard au niveau des vulnérabilités DNS à l'échelle du système soit universellement mise en œuvre, telle que le protocole DNSSEC2, les résolveurs DNS ouverts doivent prendre de manière indépendante des mesures pour atténuer les menaces connues. De nombreuses techniques ont été proposées; voir IETF RFC 4542: Mesures pour rendre le DNS plus résistant aux réponses forgées pour un aperçu de la plupart d'entre elles. Dans Google Public DNS, nous avons implémenté et recommandé les approches suivantes:

• Surapprovisionnement des ressources de la machine pour se protéger contre les attaques directes de déni de service sur les résolveurs eux-mêmes. Comme les adresses IP sont faciles à falsifier, il est impossible de bloquer les requêtes basées sur une adresse IP ou un sous-réseau. le seul moyen efficace de gérer de telles attaques consiste simplement à absorber la charge.

C'est une réalisation déprimante. même en cas de dépassement de capacité / défaut du serveur / super utilisateur, nous utilisons fréquemment des adresses IP comme base pour les interdictions et les blocs de toutes sortes.

Penser qu'un attaquant "talentueux" pourrait trivialement utiliser l'adresse IP de son choix et synthétiser autant d'adresses IP fausses uniques qu'il le souhaite est vraiment effrayant!

Donc ma question (s):

• Est-il vraiment si facile pour un attaquant de forger une adresse IP à l'état sauvage?
• Si oui, quelles sont les mesures d'atténuation possibles?

Comme indiqué par de nombreux autres, les en-têtes IP sont simples à forger, tant que l’on ne se soucie pas de recevoir une réponse. C'est pourquoi on le voit surtout avec UDP, car le protocole TCP nécessite une prise de contact à trois. Une exception notable est le flot SYN , qui utilise TCP et tente d’attacher des ressources sur un hôte récepteur; là encore, les réponses étant rejetées, l'adresse source n'a pas d'importance.

Une attaque par rétrodiffusion est un effet secondaire particulièrement désagréable de la capacité des attaquants à usurper les adresses sources . Il y a une excellente description ici , mais brièvement, c'est l'inverse d'une attaque par DDoS traditionnelle:

1. Prenez le contrôle d'un botnet.
2. Configurez tous vos nœuds pour qu'ils utilisent la même adresse IP source pour les paquets malveillants. Cette adresse IP sera votre victime éventuelle.
3. Envoyez des paquets de tous vos nœuds contrôlés à diverses adresses sur Internet, en ciblant des ports généralement non ouverts ou en vous connectant à des ports valides (TCP / 80) prétendant faire partie d'une transaction déjà existante.

Dans l'un ou l'autre des cas mentionnés en (3), de nombreux hôtes répondront par une réinitialisation ICMP ou une réinitialisation TCP, ciblée sur l' adresse source du paquet malveillant . L’attaquant a maintenant potentiellement sur le réseau des milliers de machines sans compromis effectuant une attaque DDoS sur la victime de son choix, le tout à l’aide d’une adresse IP source falsifiée.

En termes d'atténuation, ce risque est en réalité un risque que seuls les fournisseurs de services Internet (et en particulier les fournisseurs de services fournissant un accès client plutôt que le transit) peuvent prendre en charge. Il existe deux méthodes principales pour ce faire:

1. Filtrage d'entrée - garantit que les paquets arrivant sur votre réseau proviennent de plages d'adresses situées sur le côté éloigné de l'interface entrante. De nombreux fournisseurs de routeurs implémentent des fonctionnalités telles que le transfert de chemin d'accès monodiffusion , qui utilisent les tables de routage et de transfert du routeur pour vérifier que le prochain saut de l'adresse source d'un paquet entrant est l'interface entrante. Cette opération est mieux effectuée lors du premier saut de couche 3 du réseau (c’est-à-dire votre passerelle par défaut).

2. Filtrage en sortie - veille à ce que les paquets quittant votre réseau proviennent uniquement des plages d'adresses que vous possédez. C’est le complément naturel du filtrage des entrées et fait essentiellement partie du processus de «bon voisin»; en veillant à ce que, même si votre réseau est compromis par un trafic malveillant, ce trafic ne soit pas transféré vers des réseaux avec lesquels vous entretenez des relations homologues.

Ces deux techniques sont les plus efficaces et les plus faciles à mettre en œuvre lorsqu'elles sont utilisées dans des réseaux «périphériques» ou «d'accès», où les clients interagissent avec le fournisseur. La mise en œuvre du filtrage entrée / sortie au-dessus de la couche d'accès devient plus difficile en raison de la complexité des trajets multiples et du routage asymétrique.

J'ai vu ces techniques (en particulier le filtrage d'entrée) être utilisées avec succès dans un réseau d'entreprise. Une personne plus expérimentée dans le domaine des fournisseurs de services peut peut-être mieux comprendre les problèmes liés au déploiement du filtrage des entrées / sorties sur Internet au sens large. J'imagine que la prise en charge du matériel et des microprogrammes est un défi de taille, tout en étant incapable de forcer les fournisseurs en amont d'autres pays à mettre en œuvre des politiques similaires ...

Est-il vraiment si facile pour un attaquant de forger une adresse IP à l'état sauvage?

Bien sûr, si je ne me soucie pas de recevoir des réponses, je peux très facilement envoyer des paquets en utilisant l’adresse source que je préfère. Étant donné que de nombreux FAI ne disposent pas de bonnes règles de sortie, tout ce que je forge en général sera livré.

Si l'attaquant a réellement besoin d'une communication à double sens, cela devient très difficile. S'ils ont besoin d'une communication à double sens, il est généralement plus simple d'utiliser un proxy quelconque. Ce qui est très facile à mettre en place si vous savez ce que vous faites.

L'interdiction des personnes par adresse IP est modérément efficace sur SF / SO / SU puisque le site utilise http / https, ce qui nécessite une communication bidirectionnelle.

Petite preuve de concept pour la réponse de Zordeche (avec Ubuntu):

$ sudo apt-get install hping3
$ sudo hping3 -1 --spoof 11.10.10.20 www.google.com
HPING www.google.com (eth0 64.233.169.105): icmp mode set, 28 headers + 0 data bytes

Puis dans une autre console:

$ sudo tcpdump -i eth0 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
13:30:19.439737 IP 11.10.10.20 > yo-in-f105.1e100.net: ICMP echo request, id 31297, seq 0, length 8

Donc oui, c'est trivial, mais vous ne recevrez pas les réponses comme indiqué précédemment, à moins que vous n'ayez accès au 11.10.10.20 ou que vous n'ayez un renifleur quelque part entre www.google.com et le 11.10.10.20 (et il devrait être placé juste devant de chaque extrémité, car vous ne pouvez pas prédire la route des paquets). En outre, la passerelle du spoofer (ISP) peut ne pas laisser ce paquet sortir de la porte si une sorte d'inspection IP est en cours et que la source sent mauvais.

Les adresses IP sont faciles à falsifier pour un trafic UDP unidirectionnel . Pour les paquets TCP, vous pouvez seulement forger pour obtenir des connexions TCP semi-ouvertes avec des paquets SYN. C’est aussi la base d’une sorte d’attaque DOS. Mais vous ne pouvez pas créer de connexion HTTP avec une adresse usurpée (par exemple, si vous filtrez des sessions pour utiliser la même adresse IP). Si oui, vous pouvez usurper une adresse IP dans les paquets, cela n’est utile que pour certains types d’attaques par déni de service.

L'article de GOOG parlait explicitement de DNS. Le DNS utilise les paquets UDP et TCP. Les UDP peuvent être falsifiés, mais pas le TCP. TCP nécessite une poignée de main à 3 voies . Si l'adresse IP d'un paquet TCP est falsifiée, la falsification ne recevra pas la réponse et la connexion échouera. UDP, comme mentionné dans d'autres réponses, est «feu et oublie» et ne nécessite aucune communication de réponse. Les attaques par déni de service prennent presque exclusivement la forme de paquets UDP pour cette raison.

Dans le contexte de Stack Overflow et de sites familiaux, le problème soulevé par Takaun Daikon est très valable. Il existe de nombreuses façons d’obtenir une nouvelle adresse IP auprès de votre fournisseur d’accès Internet. Changer une adresse MAC est clairement la solution la plus simple et convient à de nombreux FAI. En outre, beaucoup de gens qui en sont capables peuvent utiliser un proxy public ou un mandat. Un blocage clair de l'IP d'origine pour ces paquets ne ferait que bloquer le proxy ou le nœud de terminaison TOR.

Donc, le blocage des adresses IP est-il valide? Enfer oui c'est. Mais vous allez vous retrouver avec des erreurs. Vous allez bloquer des adresses IP qui ne sont pas vraiment la source du problème (c.-à-d. Des mandataires) et vous aurez également des personnes qui évitent vos blocages en modifiant des adresses IP. La personne qui a la malchance d'obtenir plus tard l'adresse IP interdite ne pourra pas accéder à la famille de sites SO. Mais le taux d' erreur devrait être faible. Sauf si vous bloquez d'énormes ensembles d'adresses IP. Mais si vous bloquez un ou deux par jour, ça devrait aller.

Vous voudrez peut-être introduire un schéma légèrement plus sophistiqué où vous bloquez, mais seulement pour une période, comme une année. Si votre réseau est capable de limiter la bande passante ou de limiter la connexion, vous pouvez également envisager un système dans lequel les sacs de douche qui exécutent Apache Benchmarks sur votre site sont simplement placés dans une cage avec une bande passante très limitée.

L'usurpation d'adresse IP continuera car les FAI sont paresseux.

Mon FAI sait très bien que je suis sur une adresse spécifique, ou du moins sur le sous-réseau sur lequel je suis. Pourtant, je peux utiliser n'importe quelle adresse source. Pourquoi donc? Simplement, le coût.

Si je feins quelques adresses ici et là, cela ne coûte rien à mon FAI. Si chaque utilisateur de mon fournisseur de services Internet simulait un seul paquet entre 13 h et 14 h, il ne s'agirait toujours pas d'un problème. Cependant, lorsqu'un réseau de zombies envoie de nombreux paquets usurpés à partir de nombreux hôtes chez de nombreux fournisseurs de services Internet, la machine ou le réseau cible bascule.

La réalité financière est que, à moins d'être attaqué, l'usurpation d'identité ne coûte rien. L'implémentation du filtrage à proximité du client coûte cher, et celui qui dépense cet argent ne rapporte que très peu de bénéfices, à part le fait de savoir qu'ils sont de bons citoyens du réseau.

UDP et ICMP sont les plus faciles à simuler, mais le protocole TCP est également possible. Cela nécessite un système d'exploitation distant non sécurisé, qui utilise des numéros de séquence prévisibles à exploiter. Parfois, ce sont les machines d'équilibrage de charge qui modifient les numéros de séquence et les rendent prévisibles. Donc, TCP est possible - mais plus difficile.

L'anti-usurpation DNS est principalement axée sur la sécurité, qui consiste à empêcher quelqu'un de soumettre une fausse réponse à un résolveur récursif. Les aspects d'inondation de UDP ne sont pas spécifiques au DNS. Une simple petite requête (par exemple, pour '.') Provoquera une réponse plutôt volumineuse. Ainsi, cela fait un beau vecteur d’amplification. Il existe de nombreux autres protocoles UDP qui fonctionnent, mais le DNS est utilisé partout et il est facile de trouver des machines à utiliser pour amplifier les attaques.

DNSSEC aggrave encore cette situation, avec des paquets UDP pouvant atteindre une taille de 4 Ko.

Les adresses IP sont faciles à falsifier en ce qui concerne les attaques DOS (D) basées sur DNS, car il s’agit généralement de paquets UDP déclenchés par incendie. Pour le trafic HTTP, ce n'est pas le cas. Vous devez donc vous trouver sur le même réseau local que le serveur Web (tout à fait possible, bien entendu, selon l'emplacement de votre site), ou contrôler les routeurs intermédiaires.

Vous pouvez envoyer une lettre à n’importe qui, et si vous ne mettez pas une adresse de retour sur l’enveloppe (ou la mauvaise), ils peuvent embaucher tous les filtres de courrier indésirable du monde et ne pas filtrer votre message sans ouverture (traitement). ) il.

Toutefois, si l'expéditeur souhaite une réponse, il est préférable que l'adresse de retour soit correcte ou qu'un mécanisme de couche d'application soit nécessaire pour obtenir l'adresse correcte. Donc, je peux vous faire croire que vous ouvrez une lettre de Nana, mais même si je vous trompe avec le contenu de la lettre, vous n'allez pas envoyer à Nana un chèque à l'ordre de CASH à une adresse au Nigéria (à moins que Nana soit nigériane ). Donc, le défi / la réponse est une défense efficace tant que vous n'êtes pas aussi un homme du Middled.

Je peux définir l'adresse IP source de mon choix dans un datagramme.
Une autre question est de savoir si mon FAI laisserait un tel paquet dans la nature.

Même s’il s’agit là d’une réalité à laquelle il convient de remédier, le problème sous-jacent est vraiment non technique: les personnes mal intentionnées essaient de faire des choses malveillantes. La vraie solution doit donc également être non technique.

Je pense que ce que Stackoverflow a fait est EXACTEMENT la solution idéale pour traiter la deuxième ligne de défense: techniques permettant de restreindre les utilisateurs de spam potentiels par le biais de différentes manières de limiter leur capacité à interagir avec la plate-forme avant d'atteindre un certain niveau de "crédibilité".

Non seulement ces techniques contribuent à améliorer la qualité générale du site, mais elles incitent en outre les utilisateurs à s'impliquer davantage et à fournir des réponses plus crédibles / fiables.

Du point de vue technique, la meilleure chose à faire serait alors de faire ce que Google suggère: il suffit d’être efficace pour absorber / gérer la charge supplémentaire.

Excellent travail et continue à progresser!

UDP est la raison principale pour laquelle cela est facile: en fait, Skype et Slingbox exploitent la capacité de créer facilement des adresses IP dans UDP pour « percer » dans la traduction d' adresses réseau ( NAT) et permettre un peer-to-peer facile.

Le protocole TCP est plus difficile car il nécessite un cycle SYN / ACK complet, mais vous pouvez toujours inonder le serveur de paquets SYN suspendus qui vont aux adresses IP plusieurs fois de suite et nouent essentiellement un grand nombre de routeurs dans le processus.

Comme mentionné ci-dessus, l’utilisation des procurations est triviale et il existe un très grand nombre de procurations anonymes ouvertes disponibles.

Même sans utiliser de proxy, je peux définir l'adresse MAC de mon pare-feu sur toute nouvelle valeur arbitraire, réinitialiser mon modem câble et mon fournisseur de services Internet m'attribuera une nouvelle adresse IP brillante.

Et ce n'est que pour commencer. Il existe de nombreuses autres façons de contourner les interdictions de propriété intellectuelle.

Si oui, quelles sont les mesures d'atténuation possibles?

Vous ne pouvez pas faire grand chose du côté de la réception.

Le fournisseur de services Internet du faussaire devrait filtrer son trafic sortant afin que ses clients ne puissent pas usurper les adresses IP de différents réseaux.

Il n’ya que quelques lignes dans la configuration du routeur, il n’ya donc pas de bonne excuse pour ne pas le faire.

Il existe un moyen de suivre l'attaquant, mais cela nécessite la coopération de vos fournisseurs en amont: http://www.cymru.com/Documents/dos-and-vip.html

Comme d'autres l'ont déjà souligné, le format UDP est assez simple à forger, pas le protocole TCP.

La défense préférée, mais malheureusement pas universellement déployée, est les filtres de sortie.

Pour les FAI utilisant des services DSL, etc., chaque ligne virtuelle doit être configurée avec ip verify unicast reverse-path(ou quel que soit son équivalent non-Cisco) qui bloque tout paquet dont l'adresse IP source n'est pas comprise dans les plages connues pour être acheminée sur cette ligne.

Je me souviens de la programmation de sockets à la fin des années 90 avec ce qui était probablement Visual Basic, et nous pouvions définir l'adresse IP source sur notre connexion. Je me souviens vaguement que lorsque nous l'avons essayé, netstat -an a montré l'adresse IP source réelle, mais les journaux Apache ont montré l'adresse IP usurpée; et je pense qu'Apache remettait l'IP spoofé aux modules perl et ainsi de suite.