[gull] Clamav

[Marc SCHAEFER]

On Tue, Dec 30, 2003 at 05:50:46PM +0100, Daniel Cordey wrote:
> Exact. J'ai en fait plusieurs machines qui possedent force,ent chacune une adresse
> "de base". J edeplace mes services entre ces machines (DNS, mail, pop, www) en fonction

Intéressant. Je fais également cela, mais au niveau du DNS: tout pointe
sur une adresse unique (pas de CNAME, champs A). Avec des
timeouts/refresh de 4h tu peux déjà faire pas mal de flexibilité avec
ça.

Pour un DNS ça complique, mais en général on a au moins un secondaire.

Une alternative est de mettre un firewall/NAT devant. Je fais souvent ça
pour les DMZ. Chaque service est alors `mappable' facilement. Les
serveurs dans le DMZ possèdent une adresse privée.  Cela simplifie
également les concepts `fail-over'.

> effet. De plus, je me pose des questions car je peux effectuer des requetes sur l'adresse IP de "de base"
> de l'interface... et le serveur repond quand meme... zarbi !

Regarde
    netstat -an | grep LISTEN | grep 53

et tu verras tout de suite sur quoi il a fait bind(2). Si c'est 0.0.0.0
alors il recevra tout. Si c'est pour chaque adresse un bind, alors il
recevra les datagrammes sur chacun des sockets correspondants.

Exemple ici:

schaefer at shakotay:~$ netstat -an | grep LISTEN | grep 53
tcp        0      0 80.83.46.147:53         0.0.0.0:* LISTEN      
tcp        0      0 192.168.1.1:53          0.0.0.0:* LISTEN      
tcp        0      0 127.0.0.1:53            0.0.0.0:* LISTEN      
tcp        0      0 127.0.0.1:953           0.0.0.0:* LISTEN     

dans ce cas il y a peu d'ambiguité et la bonne adresse
sera choisie (3 interfaces: eth0, eth1, lo).

Maintenant je rajoute un alias, je suppose que dans ce cas, BIND
ne va pas rajouter un socket. Il va donc recevoir sur 0.0.0.0, voire
sur l'adresse IP principale de la carte et renverra par le chemin le
plus logique.

Normalement l'adresse d'émission est choisie au moment du bind(2).
Si c'est un socket 0.0.0.0, alors c'est l'adresse la plus logique
correspondant à l'interface (en fonction des tables de routage)
qui est prise.

(souvenirs lointains de programmation socket UNIX)

Je me demande si tout simplement un listen-on adresse-ip-virtuelle;
ne va pas rajouter un socket de plus et donc résoudre ton problème.
Essaie-voir ça et envoie le netstat -anp ...

> 	;; reply from unexpected source: 192.168.1.2#53, expected 192.168.1.30#5

Ca semble très clair, effectivement.

> 	iptables -t nat -A POSTROUTING -s 192.168.1.2 -p udp --sport 53 -j SNAT --to-source 192.168.1.30:53
> 
> Je ne comprends d'ailleurs pas pourquoi je dois repreciser le numero du port de la source, alors que la 
> doc dit que cette info n'est pas touchee... mais bon, je suis encore novice dans netfilter.

Effectivement, mais jusqu'ici j'avais utilisé cela dans un autre
contexte (le firewall se faisant passer pour plusieurs adresses IP et
redirigeant dans le DMZ en 192.168.x.x)

[ je ne comprends pas trop ta magouille :52 dans la mesure où tu ne dis
  pas non plus au client qu'il doit faire du DNS sur le port 52
]

> Voila l'etat de mes recherches. Je ferai aussi une petite doc explicative pour ce probleme, en meme temps que 
> celle que j'ai promise pour postfix-amavis-clamav.