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