Re: Comportement postfix vs portmap

Startseite

Nachricht beantworten
Autor: Edgar Bonet
Datum:  
To: Liste Guilde
Betreff: Re: Comportement postfix vs portmap
Le mardi 16 décembre, Olivier Allard-Jacquin a écrit :
> [Plein de choses dont :
> /etc/hosts.deny : portmap: ALL
> /etc/hosts.allow : portmap: 127.0.0.0/8, 192.168.0.0/255.255.255.0]
>
> Avec une telle configuration, on pourrait se dire que portmap n'écoute
> que sur les interfaces "utiles" ("lo" et "eth0"), et non sur les
> interfaces "dangereuses", comme "eth2". Et ben non [...] Malgré sa
> configuration sans équivoque, portmap écoute sur TOUTES les interfaces
> réseaux, et non seulement sur "lo" et "eth0".


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

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.

>     Bon, pendant que je suis dans la configuration des /etc/hosts.*, j'ai 
> fait une petite expérience : Pourquoi ne pas tout simplement configurer 
> le "/etc/hosts.deny" de la manière la plus restrictive possible et tout 
> interdire par défaut :

>
> <extrait /etc/hosts.deny>
> # (2003/12/12) Par defaut, tous les serveurs sont interdits
> # A mettre en commentaire si sertains services se mettent à ne plus
> # marcher...
> ALL:ALL
> </extrait /etc/hosts.deny>
>
>     Et bien en fait c'est une assez mauvaise idée, parce qu'avec cela, 
> pleins de demons commencent à planter.


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.

Pour ma part j'ai arrêté d'utiliser libwrap quand je me suis mis à
iptables. Je trouve qu'utiliser les deux est redondant. 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. 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.

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.

Edgar.

-- 
Edgar Bonet           Maison : 04 76 21 29 16    Bureau : 04 76 88 10 96
3 rue Jean Prévost    Mobile : 06 77 19 79 39    Fax    : 04 76 88 11 91
38000 Grenoble        guilde@???     www.edgar-bonet.org