Proxy et dns

[tomtom30]

Bonjour,

je me posais une petite question au sujet du reporting pour un proxy.
Je me demandais si on ne passe que du dns (dns tunnelling) dans un proxy qu'est ce que l'administrateur du proxy est en mesure de voir.
je parle dans la plupart des cas, sans config spécifique, disons un proxy standard.

Merci de vos réponses

[jdh]

Le terme "proxy" désigne un intermédiaire entre un client et un serveur indépendamment du protocole.
Mais un proxy est nécessairement dépendant du protocole.
On peut donc avoir un "proxy http", un "proxy http", un "proxy pop3", et ainsi de suite ...

Dans le langage courant, on parle de proxy pour le "proxy http" (voire "proxy https" et "proxy ftp" car Squid fait les 3 protocoles).

Il est clair que dns n'est pas concerné par ce proxy (http).

Donc si un petit rigolo établi un tunnel via dns, cela ne sera pas vu dans les logs du proxy (quel que soit le logiciel de présentation des logs).


La logique d'un tunnel via dns est de construire un "faux" serveur dns (avec un faux domaine) et de requêter à CE serveur des query dns (du faux domaine).
Si on autorise seulement le serveur DC windows de l'entreprise à effectuer des requête dns et vers les seuls forwarders prévus, un PC de rigolo ne pourra établir de tunnel dns (en principe).

NB : la performance d'un tunnel dns n'est pas très bonne : quelques centaines d'octets par seconde sur une ligne adsl ordinaire.

[tomtom30]

Merci pour cette réponse.

Juste une chose que je n'ai pas compris car je ne suis pas du tout dans ce metier c'est juste de la culture générale :

Si on autorise seulement le serveur DC windows de l'entreprise à effectuer des requête dns et vers les seuls forwarders prévus, un PC de rigolo ne pourra établir de tunnel dns (en principe).

Qu'est ce qu'un serveur DC ?
Les seuls forwarders prévus c'est à dire?

[jdh]

Le cas fréquent pour une entreprise :

- un accès Internet via ADSL ou SDSL,
- un firewall,
- un réseau interne,
- un serveur Windows chargé du domaine (domain controler = DC),

Le serveur Windows assure le rôle de domain controler (DC), de serveur dhcp, de serveur dns, de partage de fichier, ...

On configure le dns du serveur windows avec les redirecteurs (forwarders en anglais) indiqués par le fournisseur de la ligne Internet (194.2.0.20 pour Orange/SDSL, ...), ...

Il important de limiter, au niveau du firewall, au seul serveur Windows, l'accès DNS et juste aux redirecteurs, par sécurité !

[tomtom30]

Daccord, mais dans le cas ou l'on crée un tunnel dns, ce serveur DC va relayer les requêtes vers l'exterieur non?

Je ne comprend pas la notion de securité que cela apporte.

[jdh]

Relis ce que j'écris : il faut n'autoriser QUE le flux dns depuis le serveur dns interne (le DC) et vers les redirecteurs.

Comme on créé un domaine inexistant et/ou on interroge le serveur via son ip, cela est bloqué.

Par contre, cela pourrait éventuellement fonctionner si le serveur cible est référencé par un nom existant dont on gère le dns en spécifiant le NS. Or quand on achète (loue) un domaine, la plupart du temps le NS est un NS du fournisseur.

On pourrait utiliser un compteur de règle : on regarde l'évolution du compteur de règles dns; Statistiquement, il sera relativement régulier, si un imbécile tente un tunnel dns, le nombre de requète va augmenter sensiblement.

Mais, je rappelle, d'après ce que je sais la perf d'un tel tunnel est assez faible. Comme les tunnels basés sur icmp d'ailleurs ...

[tomtom30]

Ce que je ne comprend pas, c'est ce qui va empecher la requete du client d'aller trouver son serveur.
Meme si je n'autorise que le flux du DC, il va relayer les requetes de ses clients non?
Les forwardeur vont faire pareil non?

Le Shéma que j'ai dans ma tête est celui la:

Client (requête sur $%#&!.com) --> DC --> forwarder --> $%#&!.com --> 123.123.123.123 --> faux domaine --> http.

Il doit être faux ou bien il y a la fameuse restriction que je ne comprend pas.
A moins que ca soit la réponse qui soit bloquée.

[jdh]

Le DC va forwarder la requête aux redirecteurs, on est d'accord.
Mais il faut que les redirecteurs résolvent la requête.

Donc le domaine doit être réel et correctement enregistré.
Mais il faut la partie "serveur" sur un PC réel, qui devra donc être NS dudit domaine.

Il est possible même avec une ip dynamique d'y arriver, mais cela est largement au dessus d'un tunnel dans http.


Il y a des contre-mesures possibles contre un tel tunnel, notamment avec bind qui doit être capable de limiter (ou d'interdire) les records TXT nécessaires à un tunnel dns.

[tomtom30]

humm merci je me coucherais moins c.. ce soir .

Dernière question :

Quelle est la raison technique de la lenteur d'un tunnel dns ou icmp?

[jdh]

Un tunnel dns va utiliser des requêtes dns spéciales basées sur les records txt.
Il faut donc que le serveur créé les dits enregistrements txt (nom + contenu) et convienne avec le serveur de l'acquittement de paquets.
(Il ne faut pas oublier que le serveur ne réagit qu'à des requêtes et ne peut donc de lui même envoyer quelque chose : il ne réagit que par sollicitation : dur d'envoyer un ACK !)

La problématique est la même pour un tunnel icmp : données inscrites dans l'espace libre du ping et déséquilibre client/serveur.

Dans le cas du ping, il faut limiter le type de paquet icmp à 8=echo request pour limiter le risque d'un tunnel icmp.
Il faudrait aussi que le firewall puisse limiter la taille de paquet icmp pour assurer le coup.


Dans la pratique, je présume que ces tunnels "d'école" ne peuvent être utilisés raisonnablement que par des pgm de type chevaux de troie (pour recueillir instructions ou charges). Ils ne me semblent peu utilisables pour le kéké lamba qui utilisera plutôt un tunnel http plus simple et plus performant mais visible dans les logs du proxy (ouf).

[tomtom30]

Et bien me voila renseigner.
Merci beaucoup jdh pour ton savoir.

A bientot