Probleme avec IPTables

[neo_hijacker]

Bonjour,

Je dois mettre au point une solution de portail captif basé sur le DNS.

La config est la suivante :

1 BIND (BIND-PORTAIL) sur le 53 qui renvoit toujours la meme IP en réponse avec une TTL a 0 (celle du portail invitant à s'identifier)

1 BIND (BIND-NORMAL) sur le 54 qui est un serveur normal

Quand le portail valide l'accès, il lance un script redirigeant pour l'IP du client le port 53 vers le 54 (en TCP et UDP) (un REDIRECT dans iptables).

Cependant j'ai remarqué un phénomène étrange... En écoutant sur le client avec Wireshark les communications, je me suis apercu que les requetes DNS envoyées par le navigateur communiquaient toujours avec le BIND-PORTAIL et donc recevaient les DNS du portail, là où les requetes faites avec nslookup sont bonnes.

En redémarrant le service client DNS sur le PC Windows client, tout rentre dans l'ordre.

En clair, il semblerait que la connexion DNS entre le client Windows et le serveur soit persistante et non pris en compte par Iptables !

D'ou ma question, comment faire avec iptables pour appliquer la regle sur les connexions en cours ? Ou comment tuer une connexion particuliere ?

Merci d'avance !

[madko]

Tu peux nous indiquer ce que retourne "iptables -L -v" ? c'est peut etre juste un problème d'ordre dans les règles

[neo_hijacker]

dns:~# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 908 packets, 95998 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination
  29  1859 REDIRECT   udp  --  any	any	 10.95.20.190  anywhere			state NEW,RELATED,ESTABLISHED udp dpt:domain MAC 00:E0:4C:E9:1A:0A redir ports 54
0	 0 REDIRECT   tcp  --  any	any	 10.95.20.190   anywhere			state NEW,RELATED,ESTABLISHED tcp dpt:domain MAC 00:E0:4C:E9:1A:0A redir ports 54
0	 0 REDIRECT   udp  --  any	any	 10.95.20.190   anywhere			state NEW,RELATED,ESTABLISHED udp dpt:domain MAC 00:E0:4C:E9:1A:0A redir ports 54
0	 0 REDIRECT   tcp  --  any	any	 10.95.20.190   anywhere			state NEW,RELATED,ESTABLISHED tcp dpt:domain MAC 00:E0:4C:E9:1A:0A redir ports 54

Chain POSTROUTING (policy ACCEPT 170 packets, 12676 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination

Chain OUTPUT (policy ACCEPT 170 packets, 12676 bytes)
pkts bytes target	 prot opt in	 out	 source			   destination

Seulement, le probleme peut survenir aussi dans le sens inverse :

Si je vide les tables (flush sur nat et filter), voici le phénomene observé sous Windows :

Firefox surfe normallement et les requetes DNS sont correctes

nslookup recoit systématiquement l'IP du portail

[madko]

Et ton script il insert en debut de chain la regle ou en fin? (en gros iptables -I ou -A)

[neo_hijacker]

Il fait des -A

[madko]

c'est vraiment bizare. Peut etre que le parefeu concidere que c'est des connexions en relation avec d'autre transaction donc il continu de les envoyer sur le meme port...

Pour empecher ça tu peux tenter une legere variante, faire aussi une redirection de port pour le BIND-PORTAIL (genre le port 52). Comme ça tu vera plus clair dans les regles de preroutage qui font de la redirection.

En gros t'aura:

Regle de redirection pour client1 identifié avec son ip et sa mac adresse vers le port 53 => redirection BIND-NORMAL port 54

Regle de redirection pour client2 identifié avec son ip et sa mac adresse vers le port 53 => redirection BIND-NORMAL port 54

[...]

Regle de redirection global pour le reste (clients non identifiés) vers le port 53 => redirection BIND-PORTAIL port 52

Comme ça tu insert avec iptables -I les clients en debut de chaine. Mais bon j'espere que ça changera qqchose.

Du coup tu ouvre un tcpdump en ecoute sur le port 52 et un autre sur le port 54 et tu vois si ya bien bascule

[neologix]

Le problème c'est que iptables (netfilter) est "trop malin".

En gros, il fait du connection tracking sur un protocole stateless, l'UDP. Il se base sur l'IP/port source et destination pour considérer que les paquets font partie de la même "session". Exemple, après une résolution DNS :

# cat /proc/net/nf_conntrack

ipv4 2 udp 17 27 src=192.168.1.165 dst=192.168.1.1 sport=35017 dport=53 src=192.168.1.1 dst=192.168.1.165 sport=53 dport=35017 use=1

ipv4 2 udp 17 28 src=192.168.1.165 dst=192.168.1.1 sport=33927 dport=53 src=192.168.1.1 dst=192.168.1.165 sport=53 dport=33927 use=1

On voit qu'il a dans sa table de conntrack des entrées correspondant aux paquets envoyés. Ce qui est intéressant, c'est la 4ème colonne, le timeout:

En l'occurrence, pour l'UDP, il est à 30s., ce qui veut dire qu'au bout de 30s., l'entrée dégage.

Donc normalement, si tu ne fais pas de résolutuion DNS pendant 30s., ça devrait le faire.

Maintenant, si ça marche avec un dnslookup mais pas avec Firefox, et lorsque tu redémarres le service DNS de Windows, c'est probablement parce que dnslookup utilise un port source différent à chaque fois, mais pas le service Windows, et Firefox non plus.

Maintenant, si tu veux diminuer le timeout ;

# sysctl -a | grep conntrack | grep udp

net.netfilter.nf_conntrack_udp_timeout = 30

net.netfilter.nf_conntrack_udp_timeout_stream = 180

Un truc du genre

# sysctl -w net.netfilter.nf_conntrack_udp_timeout=10

# sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=10

devrait faire l'affaire.