Comportement postfix vs portmap

Startseite

Nachricht beantworten
Autor: Olivier Allard-Jacquin
Datum:  
CC: Liste Guilde
Alte Treads: Re: remerciements et autre questions
Betreff: Comportement postfix vs portmap
    Hello Edgar,


    suite à ton commentaire, j'ai fais quelques petits tests ce soir sur ma 
machine. Elle possède 2 interfaces réseaux (eth0 et eth1, voir 
http://olivieraj.free.fr/fr/linux/information/firewall/fw-02-01.html), 
plus un loopback (lo). Comme indiqué dans ma doc, j'ai bien restreint 
l'écoute sur certaines interfaces (eth0 et lo) :


<extrait du /etc/postfix/main.cf>
inet_interfaces = localhost.localdomain phoenix0.sky.net
</extrait du /etc/postfix/main.cf>

et j'ai bien :

<commande>
[root@phoenix /]# netstat -lt | grep smtp
tcp  0  0 phoenix0.sky.net:smtp   *:*          LISTEN
tcp  0  0 localhost.localdom:smtp *:*          LISTEN
</commande>


Ma 2nd carte réseau (eth2) n'appairait pas dans le liste


    Par contre lors de mon précédent mail, si j'avais un doute sur la 
restriction effective de postfix à une certaine interface, c'était à 
cause de mes experiences avec "portmap".


    Je m'explique (t'ention, c'est long... :=)) :


    Bien que ce demon ait de l'âge, et qu'il soit un gros trou de sécurité 
potentiel (c'est un RPC, c'est donc l'équivalent de ce qui tourne sous 
Windows derrière le port 135, rendu tristement célèbre avec les attaques 
de MSBlaster de l'été), il n'en reste pas moins essentiel pour d'autres 
démons, dont :
- fam (/etc/xinetd.d/fam) : C'est un démon qui surveille l'activité sur 
les fichiers. Pas mal de softs y font appel, dont "Konqueror" sous KDE, 
qui l'utilise pour savoir par exemple si des images ont été modifiées, 
et si il doit rafraîchir les vignettes.
- NFS (Serveur de fichiers) : Je ne travaille pas qu'avec des réseaux 
Samba, et NFS n'a pas d'équivalent lorsqu'il s'agit de transmettre des 
fichiers en prenant en compte les droits d'accès, et les 
majuscules/minuscules. Transférer un 2 fichiers d'un même répertoire ne 
se différenciant que par la case pose un gros problème avec Samba, et 
aucun avec NFS.


    Fam a besoin d'une connexion avec RPC, et pour cela il se satisfait 
d'une connexion sur l'interface loopback.


    NFS est plus pénible, car il doit être pouvoir dialoguer avec le client 
à distance qui demande un partage NFS. Du coté de ce client d'ailleurs, 
lui-même doit avoir lancé portmap. Mais pour lui, un simple échange sur 
son interface loopback suffit (dialogue possible entre le "mount.nfs" et 
la commande "mount" je suppose).


    Il convient donc de sécuriser au maximum portmap, afin de restreindre 
ses connexions aux seules interfaces susceptibles  de l'utiliser. Dans 
mon cas, il s'agit toujours des interfaces "eth0" et "lo" : "eth1" ne 
partageant pas de NFS, pas la peine de prendre de risque.


    La seule méthode de sécurisation de portmap est d'utiliser les fichiers 
/etc/hosts.allow et /etc/hosts.deny. J'ai vu traîner sur la doc de 
xinetd que l'on pouvait utiliser ce dernier afin de sécuriser portmap, 
mais que la solution était encore instable, et fortement déconseillé...


    Donc j'ai configuré ainsi mes fichiers de configuration :
<extrait /etc/hosts.deny>
# (2003/12/12) Reglages du partage NFS
# On interdit toutes les connexions
# Les connexions seront autorisées dans le /etc/hosts.allow
portmap: ALL
</extrait /etc/hosts.deny>



<extrait /etc/hosts.allow>
# (2003/12/15) Autorise portmap à écouter sur le loopback.
# Certains services comme fam (lancé par xinetd) l'utilise.
# Les CLIENTS NFS en on aussi besoin, afin de communiquer avec leur
# propre commande ("mount" ???)
portmap: 127.0.0.0/8

# (2003/12/15) Partage NFS
# On autorise uniquement les connexions depuis les machines du réseau
# local
# Sans activation du portmap pour ces réseaux, les machines à distance
# NE peuvent PAS accéder aux partages NFS
portmap: 192.168.0.0/255.255.255.0
</extrait /etc/hosts.allow>

    C'est la technique classique du "j'interdis tout par défaut, et je 
n'autorise que quelques connexions aux compte goutte.


    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 :


<commande>
[root@phoenix /]# service portmap restart
[root@phoenix /]# netstat -lt | grep rpc
tcp  0      0 *:sunrpc                *:*           LISTEN
</commande>


    Malgrès sa configuration sans équivoque, portmap écoute sur TOUTES les 
interfaces réseaux, et non seulement sur "lo" et "eth0".


    Ceci est bien entendu confirmé par un nmap lancé depuis une machine 
connectée sur l'interface eth1 :


<commande>
[olivier@pirate /]$ nmap phoenix1 -p 111

Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2000-01-01 05:23 CET
Interesting ports on phoenix1.internet.net (10.0.0.1):
Port       State       Service
111/tcp    open        sunrpc


Nmap run completed -- 1 IP address (1 host up) scanned in 0.382 seconds
</commande>

    Bien entendu, portmap ignorera les requêtes arrivant sur cette 
interface eth2. Mais comme me le confirme un "strace" sur le PID de 
portmap et une récupération des trames de la connexion, celui-ci lit 
bien le paquet entrant, d'où un risque d'attaque par buffer overflow...


<commande>
[root@phoenix /]# ps -edf | grep [p]ortmap
rpc      13963     1  0 01:16 ?        00:00:00 portmap
[root@phoenix /]# strace -f -o /tmp/portmap1.log -v -p 13963
</commande>


    J'ai même teste un bon vieux "telnet phoenix1 111", et portmap accepte 
bien l'ouverture de session, même si il finit par la refermer à la 
première commande un peu louche qu'on lui envoie...


    Fin de l'explication....


    Bref, voila qui explique mon précédent mail à propos de postfix, et sur 
sa capacité à bien se restreindre aux seules interfaces configurées dans 
le "inet_interfaces".


    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. A commencer par "ipop3d", le 
demon POP3 lancé via xinetd. Bien que via le "/etc/xinetd.d/ipop3" je 
laisse les process tournant sur le loopback y accéder, la première chose 
que fait xinetd lors d'une connexion sur le port 110 est d'interroger 
les "/etc/hosts.*" (ceci est visible via un "strace").


    Il convient donc de rajouter dans le "/etc/hosts.allow" :
<extrait /etc/hosts.allow>
# (2003/12/15) Serveur POP3 (récupération de mails), lancé sous
# contrôle de xinetd
ipop3d: 127.0.0.0/255.0.0.0
<extrait /etc/hosts.allow>


    Avis aux amateurs donc : Un "ALL:ALL" dans "/etc/hosts.deny" réserve 
certaines surprises...


    Ah, une dernière chose. Il y a un bug dans "xinetd 2.3.11" ou dans 
"libwrap 7.6" : Bien que la notation "127.0.0.0/8" soit autorisée dans 
le "man hosts.allow/hosts.deny", elle ne marche pas : Il faut lui 
préférer la notation du type "127.0.0.0/255.0.0.0". J'ai mis 10 minutes 
à trouver cela, même à grand coup de strace et de "/var/log/messages"...


    Bonne nuit,


                    Olivier



Edgar Bonet wrote:
> Oui, c'est suffisant : après avoir mis inet_interfaces = localhost,
> j'ai :
>
> # netstat -lt | grep smtp
> tcp        0      0 *:smtp                  *:*                     LISTEN
> # /etc/init.d/postfix restart
> Shutting down postfix: postfix
> Starting postfix: postfix
> # netstat -lt | grep smtp
> tcp        0      0 localhost.localdom:smtp *:*                     LISTEN


-- 
~~~~~~~  _____/\_____  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix /   _ \/ _   \    Olivier Allard-Jacquin
       /   / \  / \   \   Web:  http://olivieraj.free.fr
      /___/  /  \  \___\  Mail: olivieraj@???
~~~~ /////  ///\\\  \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!