Edgar Bonet wrote:
> Tu sembles confondre la fonctionnalité de libwrap avec celle de bind().
> Oublie un petit peu les firewalls et pense à comment on faisait dans le
> temps où on n'en avait pas.
Ne développant pas sous Linux à cette époque, je ne m'étais
pas posé la question... ;=)
> Retour sur l'API socket : le appels qui
> intéressent principalement un serveur sont socket(), bind(), listen() et
> accept() (cf. man 4 socket). Le nom de listen est trompeur, il ne sert
> qu'à spécifier la longueur d'une file d'attente. Les appels qui
> t'intéressent pour le contrôle d'accès sont bind() et accept().
>
> Le prototype de bind() d'après man 2 bind est
>
> int bind(int sockfd, struct sockaddr *my_addr, int addrlen);
>
> où le champ my_addr est décrit dans man 4 ip. Il sert à spécifier
> l'adresse locale, c'est à dire l'adresse ip (donc l'interface réseau) et
> le numéro de port qu'on écoute. Ces choix apparaissent dans l'affichage
> de netstat -lt dans la colonne « Local Address ». En guise d'ip on
> spécifie souvent INADDR_ANY pour écouter sur toutes les interfaces, ce
> qui est représenté par * dans l'affichage de netstat. Certains serveurs
> peuvent être configurés pour n'écouter que des interfaces spécifiques :
> Apache (directives BindAddress ou Listen), CUPS (directive Listen),
> Postfix (directive inet_interfaces), xinetd (directive bind)... Remarque
> qu'à ce niveau on spécifie l'adresse _locale_ du serveur, on n'a aucun
> moyen de mettre une restriction sur l'adresse distante (celle du
> client qui va se connecter).
C'est effectivement ce que j'ai trouvé dans les documentations et
"man" de ces différents services/démons/serveurs que j'utilise. Bien
avant d'utiliser netfilter, j'avais configurer les nombreux démons de ma
machine afin qu'ils n'écoutent pas (bind) sur les interfaces non
locales, et qu'ils ignorent (!accept) les paquets venant d'adresses
extérieurs.
> Le prototype de accept (man 2 accept) est
>
> int accept(int s, struct sockaddr *addr, int *addrlen);
>
> où le champ addr est un pointeur vers un buffer dans lequel le système
> mettra l'adresse (adresse ip et port) du client. Ce qui est important à
> retenir c'est que le serveur ne connaît l'adresse du client qu'une fois
> la connexion acceptée ! Libre à lui, s'il le désire, de la fermer tout
> de suite (avant de faire un read()) si cette adresse ne lui plaît pas.
>
> C'est là qu'intervient la bibliothèque libwrap (man -a hosts_access) : à
> partir de l'adresse du client qui est maintenant connue, et des
> informations dans /etc/hosts.{allow|deny}, elle décide s'il faut garder,
> ou au contraire fermer la connexion. Mais celle-ci est déjà établie.
Ok, merci de ces précisions. Durant le peu de programmation sur la pile
TCP/IP d'Unix que j'avais fais, nous n'avions pas abordé ces concepts.
Décidément, il y a là plein de choses intéressantes à faire !!!
> C'est pourtant la façon classique de remplir ce fichier. Dans
> /etc/hosts.allow tu mets alors :
>
> ALL: 127.0.0.1
>
> et ça ne devrait pas poser de problème.
Très bonne idée ! Cela me plaît tout à fait !
> Pour ma part j'ai arrêté d'utiliser libwrap quand je me suis mis à
> iptables. Je trouve qu'utiliser les deux est redondant.
Je pense qu'au contraire c'est une bonne idée. En matière de sécurité,
la redondance est préférable. Sous entendu, il vaut mieux bien
documenter dans les fichiers de configuration ce type d'utilisations /
modifications.
> En plus libwrap
> ne peut protéger que les démons qui l'utilisent, et ce n'est pas
> forcément bien documenté si un certain démon l'utilise ou non.
C'est clair.
> Je me
> suis déjà arraché les cheveux en essayant de comprendre pourquoi tel
> service que je venais d'autoriser avec iptables n'était pas accessible
> de l'extérieur : j'avais oublié que libwrap l'interdisait.
Pareil pour moi hier soir, avec le démon pop3...
> Dans le temps où la fonctionnalité de libwrap ne se trouvait que dans
> tcpd c'était simple, tcpd ne gérant que les services qu'on lui demandait
> (dans /etc/inetd.conf) explicitement de gérer.
Merci de toutes ces informations. J'ai quelques petits projets de
programmation IP, et je prendrais du temps à étudier le fonctionnement
de ces mécanismes.
Au revoir,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
