[gull] Clamav

[Daniel Cordey]

On Wednesday 31 December 2003 12:15, Marc SCHAEFER wrote:

> 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.

L'objectif etant d'assurer un transition la plus rapide possible. En effet, 
les adresse IP peuvent rester dans les caches des serveurs/routers pendant 
quelques heures et il n'est pas raisonnable d'accelere les mises a jour. Le 
seul moyen que j'ai trouve et d'utiliser ces alias, car une machine peut 
reprendre la main de maniere automatique en rajoutant un alias sur son 
interface losrqu'elle voit que le serveur "primaire" du service n'est plus 
la. Reste ensuite le probleme du mapping des adresse MAC dans mon routeur 
local... resolu en effectuant un arp en mode brodcast avec l'adresse IP et a 
MAC address concernee. Ceci ne vas pas mettre a jour la table dans le routeur 
(securite !), mais l'obliger a refaire une requete ARP... et hop maintenant 
l'adresse est correctement routee. Je peux arriver a garantir un temps de 
commutation de service de quelques secondes (1-5 suivant le degre de 
nervosite). Ainsi, cette commutation passe totalement inapercue pour les 
clients des services.

Ainsi, je ne touche plus mes "zones" DNS et je n'ai plus besoin de redemarrer 
le serveur losrque je transfere un service d'une machine a l'autre.

Pour info, s'il est vrai que l'usage de CNAME peut apporter un peu de clarete 
dans un fichire de "zone", il introduit un niveau d'indirection et necessaite 
une requete suplementaire pour acceder a ce a quoi il se refere. DOnc chainer 
des CNAME peut s'averer couteux :-)

> 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'.

Tout a fait. Mais comme je veux aussi beneficier de cette souplesse a 
l'interieur de mon Intranet, j'ai trouvais plsu elegant de ne pas toucher, ni 
le DNS, ni le firewall. De plus, router le traffic interne peut s'averer 
couteux chez nous. Nous avons enormement de traffic entre trois niveaux 
d'application dont chacune peut se deplacer horizontalement entre trois 
machines (redondance). Obliger tout le traffic a passer par le firewall 
serait penalisant. 

> Regarde
>     netstat -an | grep LISTEN | grep 53

Ceci me donnera bien le port tcp sur lequel named ecoute, mais pas l'udp; car 
les requetes DNS font, en general, moins de 512 bytes... d'ou l'usage de 
l'udp par defaut. Le mode d'acces en tcp est recent et doit souvent etre 
explicitement specifie suivant les versions de serveur (defaut en 9)

> Maintenant je rajoute un alias, je suppose que dans ce cas, BIND
> ne va pas rajouter un socket.

Non, en tout cas pas pour IPv6, mais il pourait avoir plusisures sockets pour 
IPv4 (j'ai oublie pourquoi mais j'ai vu ca dans le source).

> 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.

CAD en utilisant l'adresse IP du socket ouvert.

> (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 ...

C'est en ragardant le souce se server.c que j'ai commence a me poser des 
questions. En effet, les choses sont faites  proprement et tout me paraissait 
tres clair. Je vopyais donc bien que le code prenait bien l'option 
'listen-on' en compte... J'ai donc commence a douter de quelque chose et 
voila !

> > 	;; reply from unexpected source: 192.168.1.2#53, expected 192.168.1.30#5
>
> Ca semble très clair, effectivement.

Oui, maintenant tout s'explique, mais j'avoue avoir etet induit en erreur car 
ce message d'erreur ne semble etre generer que lors d'une connection tcp 
(trouver dans le code source de dig). 

> [ 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]

Le but etant de verifier que ma regle etait bien capable de traiter les 
requetes DNS uniquement et de prouver que je recrivais correctement l'adresse 
IP. En modifiant le 'sport', je devais continuer a avoir le message d'erreur 
mais je devais voir que, si le port etait faux, l'adresse par contre etait 
maintenant bien juste. cqfd. Lorsque je mettais l'adresse 53, mon paquet se 
perdait dans la suite de la queue POSROUTING. Je n'etais donc pas au bon 
endroit dans le script !

Merci pour tes explications qui m'ont un peu mis la puce a l'oreille :-)

Daniel