[rés] Stopper les demandes DNS d'IPCOP pour les requêtes LAN

[PierreC]

Bonjour,

Toutes les demandes de DNS pour les machines de mon LAN sont transmises par IPCOP sur le DNS du WAN (provider).
Sur le LAN les machines sont en DHCP et le DNS déclaré est le serveur IPCOP lui même.
1) Est-ce un problème de configuration ou le fonctionnement normale d'IPCOP??
2) Pour des raisons de sécurité évidentes, y a-t-il moyen de les stopper???

Merci d'avance pour vos explications et suggestions de solutions,

[jdh]

On va remettre cela dans l'ordre :

- les PC sont en DHCP,
- IPCOP est le serveur DHCP,
- le serveur DNS fourni aux clients DHCP est l'IPCOP (qui doit donc être "serveur dns"),
- IPCOP contient un relais DNS (dnsmasq je suppose qui fonctionne bien comme "serveur dns"),
- ce relais DNS
soit résout localement (hôtes statiques + clients dhcp)
soit résout via le serveur DNS configuré pour IPCOP (normalement le DNS du FAI).

D'un, cela est le fonctionnement normal d'IPCOP.
De deux, pourquoi les stopper ?

Le fonctionnement décrit me semble logique et correct.

[PierreC]

Bonjour jdh,
C'est vrai je n'ai pas été clair.
La description est correcte et évidemment je ne veux pas stopper les requêtes DNS
Ce qui le chagrine c'est que les résolutions des noms pour le LAN (intranet) sont transmises au DNS de mon provider ce qui a priori ne le regarde pas bien qu'elles soient résolues par IPCOP comme des adresses intranet.
En gros je ne veux pas qu'une requête DNS émise à partir du LAN pour une machine du LAN sorte du LAN.
Or si je regarde sur l'interface WAN de mon IPCOP (relié au routeur adsl de mon provider voici ce que je vois si je fais par exemple un ssh de pluto vers dingo

Code: Tout sélectionner

root@ipcop:~ # tcpdump -s 0 -i eth2 port 53 -v
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
13:48:36.886225 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 70) 192.168.1.62.65104 > smtp3.9tel.net.domain: 47616+ AAAA? dingo.intplutonet.net. (42)
13:48:36.948346 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 143) smtp3.9tel.net.domain > 192.168.1.62.65104: 47616 NXDomain 0/1/0 (115)
13:48:37.087248 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 192.168.1.62.26874 > smtp3.9tel.net.domain: 18676+ AAAA? pluto.intplutonet.net. (40)
13:48:37.150062 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 141) smtp3.9tel.net.domain > 192.168.1.62.26874: 18676 NXDomain 0/1/0 (113)
13:48:37.150630 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 88) 192.168.1.62.44981 > smtp3.9tel.net.domain: 19316+ AAAA? pluto.intplutonet.net.intplutonet.net. (60)
13:48:37.211666 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 161) smtp3.9tel.net.domain > 192.168.1.62.44981: 19316 NXDomain 0/1/0 (133)
13:48:37.315361 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 192.168.1.62.14902 > smtp3.9tel.net.domain: 41038+ AAAA? pluto.intplutonet.net. (40)
13:48:37.370339 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 141) smtp3.9tel.net.domain > 192.168.1.62.14902: 41038 NXDomain 0/1/0 (113)
13:48:37.370899 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 88) 192.168.1.62.53481 > smtp3.9tel.net.domain: 6622+ AAAA? pluto.intplutonet.net.intplutonet.net. (60)
13:48:37.425772 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 161) smtp3.9tel.net.domain > 192.168.1.62.53481: 6622 NXDomain 0/1/0 (133)
13:48:37.429052 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 192.168.1.62.9044 > smtp3.9tel.net.domain: 31264+ AAAA? pluto.intplutonet.net. (40)
13:48:37.483921 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 141) smtp3.9tel.net.domain > 192.168.1.62.9044: 31264 NXDomain 0/1/0 (113)
13:48:37.484477 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 88) 192.168.1.62.13915 > smtp3.9tel.net.domain: 6710+ AAAA? pluto.intplutonet.net.intplutonet.net. (60)
13:48:37.539852 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 161) smtp3.9tel.net.domain > 192.168.1.62.13915: 6710 NXDomain 0/1/0 (133)
13:48:37.541819 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 192.168.1.62.58362 > smtp3.9tel.net.domain: 35804+ AAAA? pluto.intplutonet.net. (40)
13:48:37.597240 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 141) smtp3.9tel.net.domain > 192.168.1.62.58362: 35804 NXDomain 0/1/0 (113)
13:48:37.597767 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 88) 192.168.1.62.35079 > smtp3.9tel.net.domain: 38676+ AAAA? pluto.intplutonet.net.intplutonet.net. (60)
13:48:37.652687 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 161) smtp3.9tel.net.domain > 192.168.1.62.35079: 38676 NXDomain 0/1/0 (133)
13:48:37.739613 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 68) 192.168.1.62.47532 > smtp3.9tel.net.domain: 57642+ AAAA? pluto.intplutonet.net. (40)
13:48:37.794357 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 141) smtp3.9tel.net.domain > 192.168.1.62.47532: 57642 NXDomain 0/1/0 (113)
13:48:37.794899 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 88) 192.168.1.62.41760 > smtp3.9tel.net.domain: 25834+ AAAA? pluto.intplutonet.net.intplutonet.net. (60)
13:48:37.850039 IP (tos 0x30, ttl 57, id 0, offset 0, flags [DF], proto UDP (17), length 161) smtp3.9tel.net.domain > 192.168.1.62.41760: 25834 NXDomain 0/1/0 (133)

[ccnet]

Si je comprend bien ce que vous nous dites c'est que les demandes dns des clients, pour des machines locales, sont envoyées chez votre isp au lieu d'être uniquement traité par ipcop ?

[PierreC]

Tout à fait.

[jdh]

Comme je l'écris, c'est dnsmasq qui est utilisé comme relais dns/serveur dns par IPCOP.

Bien évidemment, les machines locales devraient être résolues sur IPCOP.

Outre les pc clients dhcp dont le nom est automatiquement "importé" dans la zone dns, il y a les hôtes statiques qui peuvent/doivent être utilisé pour les serveurs (du lan ou de la dmz), imprimantes, ... (qui ne sont pas clients dhcp).


Je me complète :

ATTENTION 192.168.1.62 est-elle une adresse de PC interne ?
Si c'est le cas, il est IMPORTANT de ne pas autoriser cela : IPCOP comporte un relais dns/serveur dns, il n'y a AUCUNE raison qu'un PC (de la zone Green) accède directement au dns du FAI.

Il est aussi important de vérifier que c'est bien IPCOP qui est indiqué comme dns pour les clients DHCP (cde "ipconfig /all" sous windows).

[PierreC]

Nous sommes bien d'accord d'ailleurs pluto et dingo sont des serveurs (fichiers, imprimantes etc) du LAN déclarés en fixed leases.

Pourquoi donc IPCOP laisse passer ces demandes???

En ce qui concerne l'adresse 192.168.1.62 c'est celle de l'interface WAN d'IPCOP, ou plutôt celle de la carte ethernet du serveur IPCOP relié à la BOX tele2.

Si je comprends bien, il faut que je me penche sur la config de dnsmasq pour trouver une solution.

[jdh]

dingo.intplutonet.net et pluto.intplutonet.net sont ils définis comme hôtes statiques ?
Sont ce des clients dhcp ?

Il est possible qu'ils soient définis comme dingo et pluto et non dingo.intplutonet.net et pluto.intplutonet.net (FQDN comme disent les english !). Au besoin, je les ajouterais (sous les 2 formes) dans hôtes statiques.


(Mais je connais que très mal IPCOP ...)

[Franck78]

A vu de nez comme ça, si dnsmasq laisse partir des requètes de nom de domaine interne,..... c'est qu'il ne sait pas que cela concerne le domaine interne!


En regardant le code d'IPCop, je pense (je suis sur même!) qu'il y a un manque sur l'utilisation du parametre 'local'
de dnsmasq

C'est '--local=/tondomaine/' qu'il faut ajouter

Dans le fichier rc.updatered(ligne~=101) et rc.netadress.up (l=54)

ajoute aux options --local=/$DOMAIN_NAME_GREEN/

ne pas oublier le / / !!!!



Testé chez moi, c'est OK.

Je remonte un bug a Gesp.

[leso]

C'est une bonne chose a savoir.

[PierreC]

Youpi
merci Franck78, c'était effectivement là le problème.
Je ne comprends pas pourquoi IPCOP n'intègre pas d'office cette option.
Pour moi il s'agit d'une faille de sécurité qui permet à quelqu'un à l'extérieur du réseau de surveiller toutes les demandes de trafic interne et de connaitre les noms des machines et serveurs .
Enfin c'est réglé il n'y a plus qu'à changer ces noms sur le LAN

[tomtom]

Je remonte un bug a Gesp.

C'ets un bug, ca devrait etre corrigé assez vite ;o)

t.

[Franck78]

Enfin c'est réglé il n'y a plus qu'à changer ces noms sur le LAN

@PierreC:
je saisis pas vraiment la réponse. Les phrases pleines d'affirmations....


1) Tu as patché comme indiqué
2) Tu as vérifié qu'il n'y avait plus de fuite
3) Tu changes les noms des machines qui ont été divulgués??
4) Le problème est résolu pour toi


Je n'ai pas regardé si ORANGE/BLUE ont aussi un nom dns différent (et si c'est possible). Auquel cas, mon patch n'est pas complet/suffisant.

[PierreC]

Enfin c'est réglé il n'y a plus qu'à changer ces noms sur le LAN

1) Tu as patché comme indiqué?

Oui, plus exactement voilà la correction que j'ai apporté sur le fichier rc.updatered

Code: Tout sélectionner

if [ -e "/var/ipcop/red/dial-on-demand" -a "$DIALONDEMANDDNS" == "on" -a ! -e "/var/ipcop/red/active" ]; then
    /usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases $DOMopt -r /var/ipcop/ppp/fake-resolv.conf --min-port=4096 --local=/$DOMAIN_NAME_GREEN/
else
    /usr/sbin/dnsmasq -l /var/state/dhcp/dhcpd.leases  --local=/$DOMAIN_NAME_GREEN/ $DOMopt -r /var/ipcop/red/resolv.conf --min-port=4096
fi


et sur le fichier rc.netaddress.up

Code: Tout sélectionner

/usr/sbin/dnsmasq $OPT_DNSMASQ --local=/$DOMAIN_NAME_GREEN/


2) Tu as vérifié qu'il n'y avait plus de fuite?

Bien sûr avec tcpdump sur le port reliant ipcop avec la zone rouge

3) Tu changes les noms des machines qui ont été divulgués??

Oui,, peut-être un peu parano comme modification mais bon

4) Le problème est résolu pour toi

Oui j'ai voulu marquer résolu dans le sujet mais la limitation du nombre de caractères ne m'a pas permis de le faire (il faudrait que je coupe la fin du sujet??)

Je n'ai pas regardé si ORANGE/BLUE ont aussi un nom dns différent (et si c'est possible). Auquel cas, mon patch n'est pas complet/suffisant.

Je n'utilise pas ces zones, mais je comprends le problème potentiel

[Franck78]

merci pour les précisions
bye