Problème de compréhension de l'attaque de contournement des censures : IP over DNS

[rodrigue daniel]

Salut

J'ai fait la connaissance d'une attaque dernièrement : l'attaque de l'IP over DNS.
J'ai lu certains articles à ce sujet. J'ai appris qu'elle permet de contourner certaines
censures appliquées dans certains réseaux. Je prend le cas des réseaux sans fil avec un portail captif
configuré sur Mikrotik, pfsense ou zeroshell (peu importe).
J'ai fait la connaissance d'un programme qui implémente cette notion (IP over DNS) : programme iodine.
Je ne comprend pas concrètement ce qui se passe (malgrè que j'ai lu certaines explications). Je souhaiterais
comprendre en profondeur avec la notion du modèle OSI ou TCP/IP, couche par couche.

SVP aidez-moi à comprendre.
MERCI

[Creased]

Bonsoir,

La plupart des réseaux sans-fils publics implémentent généralement des portails captifs (ou “Hotsposts”) autorisant le protocole DNS (“Domain Name Service”, couche 7, port 53/UDP) pour la résolution de noms et ICMP (“Internet Control Message Protocol”, couche 3 au même titre qu’IP).

Malgré l’ajout de dispositifs de filtrage de type proxy (e.g. SQUID) pour HTTP, le contrôle profond des paquets encapsulant le protocole DNS est bien trop souvent négligé sur ce genre de réseau. En effet, même si un dispositif de filtrage permet le contrôle des résolutions de noms en se basant sur une liste noire ou blanche en fonction de son implémentation, il serait trop complexe de filtrer les requêtes en fonction de leur contenu (zone data), bien entendu tant qu’elle ne provoque pas de dépassement dans la taille maximale autorisée (512 octets) par la norme (c.f. RFC-1035).

Ainsi, il est possible d’encapsuler des données arbitraires (e.g. un paquet IP), à fragmenter pour ne pas dépasser les 512 octets (perte significative de débit induite), dans un paquet DNS afin de les communiquer à un serveur de confiance qui va se charger de les traiter et les faire transiter sur l’Internet à la façon d’un VPN ou d’un tunnel SSH, d’où le nom “IP over DNS”. Cependant, étant donné que DNS utilise UDP comme protocole de transport et non TCP, il sera nécessaire de procéder à un contrôle lors du ré-assemblage de ces paquets afin d’en préserver l’intégrité...

Les données sont encapsulées dans un paquet DNS standard

On pourrait schématiser le fonctionnement de NSTX et iodine sur ce même principe :

PS : Si je fais erreur, n'hésitez pas à me corriger : fichiers d'illustration (à éditer sur Draw.IO).

[rodrigue daniel]

Salut

Merci beaucoup. Tu m'as beaucoup éclairci avec ton schéma parlant de la notion du paquet IP comme DATA (données) dans un datagramme DNS.
Donc le serveur de confiance ici joue son rôle à partir du programme iodine ou NSTX installé à son sein.
En guise de rappel, on parle de datagramme UDP uniquement au niveau de la couche transport car les 3 premières couches (7, 6 et 5) ont pour rôle
de constituer les données (sans entrée dans les détails) qui vont être segmenté par la couche transport.

Une mesure de sécurité serait vraiment difficile car j'ai un peu pensé mais je ne trouve pas un truc optimal.

MERCI beaucoup tu m'as vraiment éclairci avec un exemple concrèt.

MERCI