Bonjour,
Voilà je viens de me lancer avec intérêt dans l'aventure Linux avec une
Debian Woody et je sollite l'avis des experts de ce forum pour sécuriser
la machine.
Je précise que je suis débutant mais que je n'ai aucune réticence à lire
de la doc, au contraire (c'est comme ça que j'arrive à comprendre ce que
je fais). Et puis le domaine de la sécurité semble particulièrement
intéressant en plus... ;-) Idéalement j'aimerais faire une doc pour
mettre le pied à l'étrier au niveau sécurité pour les tout débutants
comme moi.
Quelques précisions de configuration tout d'abord : un seul poste pour
une utilisation personnelle (PC sous Debian Woody donc), connexion en
RTC et dans l'avenir en ADSL ethernet. L'utilisation est vraiment
basique : web, email, un peu de traitement de texte, etc... mais pas de
choses sophistiquée comme l'hébergement d'un Apache ou d'un serveur
MySQL. Ah si j'utilise postfix et leafnode (serveur de newsgroups) quand
même.
Bon voici comment j'ai déjà procédé par étapes (pas sûr d'avoir tout
fait dans l'ordre):
1) Installation normale de la Woody
2) Création d'un utilisateur normal 'toto'
3) 'toto' s'est vu affecter aux groupes suivants : dialout cdrom audio
dip video scanner
4) configuration via kppp de la connexion : j'avais un peu galéré au
début car kppp voulait absolument être lancé par root mais j'ai plus ou
moins réglé le problème en rajoutant les groupes dialout et dip à 'toto'
puis en créant un fichier contenant la chaîne 'noauth' appelé en
argument de pppd, mais je ne suis pas sûr du tout que ce soit la bonne
méthode.
5) Lecture de http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO et de
http://olivieraj.free.fr/fr/linux/information/firewall
6) Désactivation des services inutiles :
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
7) Définition des règles iptables, là ce fut la partie difficile. Après
quelques tentatives personnelles plus ou moins fructueuses je me suis
rabattu sur le script que fournissait l'auteur de la doc sur les
firewall vu au 5) : netfilter_cfg (disponible à l'adresse
http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/)
J'ai ajouté un appel à ce script dans /etc/ppp/ip-up.d/01iptables
Maintenant quand je fais 'iptables -L -n -v' en étant connecté
j'obtiens :
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:4660:4700
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:4660:4700
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10738
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:10738
26 1541 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- ppp0 * 0.0.0.0/0 80.9.46.140
state RELATED,ESTABLISHED
0 0 DROP all -- ppp0 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 10.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 172.16.0.0/12 0.0.0.0/0
0 0 DROP all -- ppp0 * 192.168.0.0/16 0.0.0.0/0
0 0 DROP all -- ppp0 * 224.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
26 1541 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- * ppp0 80.9.46.140 0.0.0.0/0
state NEW,RELATED,ESTABLISHED
8) Installation de 'bastille' (version 1:1.3.0-2) sensé 'durcir' le
système(j'ai choisi les options proposé par défaut partout sauf pour les
règles iptables)
9) Installation de l'IDS snort et de snortsnarf au cas où.
Voilà à partir de là je ne sais plus trop quoi faire. Quelques questions
que je me pose cependant :
-J'ai beaucoup entendu parler de 'sudo', 'setuid','chrootage' mais je
n'ai jamais eu besoin de faire appel à ça jusqu'ici, mais peut-être
ai-je eu tort ?
-j'ai du mal à interpreter les informations envoyés par snort (via
snortsnarf), par exemple je ne vois jamais de tentative de connexion de
ce Blaster dont tous le monde me parle, est-ce qu'il faut configurer son
snort pour que celui-ci reconnaisse les tentatives de connexion (ici un
P2P, ici un ver, ici une tentative d'exploitation de failles) et n'est
ce pas déjà disponible quelque part ? Je n'ai pas voulu installer de
serveur MySQL ou autre pour gérer dans une base de données les
informations de snort, cela ajouterait un serveur de plus à maintenir,
est-ce que j'ai eu raison ? J'ai aussi essayé prelude et celui-ci
voulait aussi absolument installer un MySQL pour pouvoir exploiter les
logs...
-Je ne vois pas très bien ou se place l'IDS dans mon cas ? est-il
derrière le firewall ou devant ? et où faut-il idéalement le placer (je
ne dispose que d'une seule machine !)
-J'ai longuement hésité entre définir mes propres règles iptables (via
un script ou pas) et utiliser un firewall (guarddog ?) déjà tout fait.
Que me recommandez vous ? et sinon quel est le firewall 'tout fait' le
plus efficace ?
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Merci à tous ceux qui sont arrivé jusqu'ici et j'attends donc vos
commentaires et ou conseils et ou critiques (qui sont les bienvenues !)
Bonjour,
Voilà je viens de me lancer avec intérêt dans l'aventure Linux avec une
Debian Woody et je sollite l'avis des experts de ce forum pour sécuriser
la machine.
Je précise que je suis débutant mais que je n'ai aucune réticence à lire
de la doc, au contraire (c'est comme ça que j'arrive à comprendre ce que
je fais). Et puis le domaine de la sécurité semble particulièrement
intéressant en plus... ;-) Idéalement j'aimerais faire une doc pour
mettre le pied à l'étrier au niveau sécurité pour les tout débutants
comme moi.
Quelques précisions de configuration tout d'abord : un seul poste pour
une utilisation personnelle (PC sous Debian Woody donc), connexion en
RTC et dans l'avenir en ADSL ethernet. L'utilisation est vraiment
basique : web, email, un peu de traitement de texte, etc... mais pas de
choses sophistiquée comme l'hébergement d'un Apache ou d'un serveur
MySQL. Ah si j'utilise postfix et leafnode (serveur de newsgroups) quand
même.
Bon voici comment j'ai déjà procédé par étapes (pas sûr d'avoir tout
fait dans l'ordre):
1) Installation normale de la Woody
2) Création d'un utilisateur normal 'toto'
3) 'toto' s'est vu affecter aux groupes suivants : dialout cdrom audio
dip video scanner
4) configuration via kppp de la connexion : j'avais un peu galéré au
début car kppp voulait absolument être lancé par root mais j'ai plus ou
moins réglé le problème en rajoutant les groupes dialout et dip à 'toto'
puis en créant un fichier contenant la chaîne 'noauth' appelé en
argument de pppd, mais je ne suis pas sûr du tout que ce soit la bonne
méthode.
5) Lecture de http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO et de
http://olivieraj.free.fr/fr/linux/information/firewall
6) Désactivation des services inutiles :
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
7) Définition des règles iptables, là ce fut la partie difficile. Après
quelques tentatives personnelles plus ou moins fructueuses je me suis
rabattu sur le script que fournissait l'auteur de la doc sur les
firewall vu au 5) : netfilter_cfg (disponible à l'adresse
http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/)
J'ai ajouté un appel à ce script dans /etc/ppp/ip-up.d/01iptables
Maintenant quand je fais 'iptables -L -n -v' en étant connecté
j'obtiens :
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:4660:4700
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:4660:4700
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10738
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:10738
26 1541 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- ppp0 * 0.0.0.0/0 80.9.46.140
state RELATED,ESTABLISHED
0 0 DROP all -- ppp0 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 10.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 172.16.0.0/12 0.0.0.0/0
0 0 DROP all -- ppp0 * 192.168.0.0/16 0.0.0.0/0
0 0 DROP all -- ppp0 * 224.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
26 1541 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- * ppp0 80.9.46.140 0.0.0.0/0
state NEW,RELATED,ESTABLISHED
8) Installation de 'bastille' (version 1:1.3.0-2) sensé 'durcir' le
système(j'ai choisi les options proposé par défaut partout sauf pour les
règles iptables)
9) Installation de l'IDS snort et de snortsnarf au cas où.
Voilà à partir de là je ne sais plus trop quoi faire. Quelques questions
que je me pose cependant :
-J'ai beaucoup entendu parler de 'sudo', 'setuid','chrootage' mais je
n'ai jamais eu besoin de faire appel à ça jusqu'ici, mais peut-être
ai-je eu tort ?
-j'ai du mal à interpreter les informations envoyés par snort (via
snortsnarf), par exemple je ne vois jamais de tentative de connexion de
ce Blaster dont tous le monde me parle, est-ce qu'il faut configurer son
snort pour que celui-ci reconnaisse les tentatives de connexion (ici un
P2P, ici un ver, ici une tentative d'exploitation de failles) et n'est
ce pas déjà disponible quelque part ? Je n'ai pas voulu installer de
serveur MySQL ou autre pour gérer dans une base de données les
informations de snort, cela ajouterait un serveur de plus à maintenir,
est-ce que j'ai eu raison ? J'ai aussi essayé prelude et celui-ci
voulait aussi absolument installer un MySQL pour pouvoir exploiter les
logs...
-Je ne vois pas très bien ou se place l'IDS dans mon cas ? est-il
derrière le firewall ou devant ? et où faut-il idéalement le placer (je
ne dispose que d'une seule machine !)
-J'ai longuement hésité entre définir mes propres règles iptables (via
un script ou pas) et utiliser un firewall (guarddog ?) déjà tout fait.
Que me recommandez vous ? et sinon quel est le firewall 'tout fait' le
plus efficace ?
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Merci à tous ceux qui sont arrivé jusqu'ici et j'attends donc vos
commentaires et ou conseils et ou critiques (qui sont les bienvenues !)
Bonjour,
Voilà je viens de me lancer avec intérêt dans l'aventure Linux avec une
Debian Woody et je sollite l'avis des experts de ce forum pour sécuriser
la machine.
Je précise que je suis débutant mais que je n'ai aucune réticence à lire
de la doc, au contraire (c'est comme ça que j'arrive à comprendre ce que
je fais). Et puis le domaine de la sécurité semble particulièrement
intéressant en plus... ;-) Idéalement j'aimerais faire une doc pour
mettre le pied à l'étrier au niveau sécurité pour les tout débutants
comme moi.
Quelques précisions de configuration tout d'abord : un seul poste pour
une utilisation personnelle (PC sous Debian Woody donc), connexion en
RTC et dans l'avenir en ADSL ethernet. L'utilisation est vraiment
basique : web, email, un peu de traitement de texte, etc... mais pas de
choses sophistiquée comme l'hébergement d'un Apache ou d'un serveur
MySQL. Ah si j'utilise postfix et leafnode (serveur de newsgroups) quand
même.
Bon voici comment j'ai déjà procédé par étapes (pas sûr d'avoir tout
fait dans l'ordre):
1) Installation normale de la Woody
2) Création d'un utilisateur normal 'toto'
3) 'toto' s'est vu affecter aux groupes suivants : dialout cdrom audio
dip video scanner
4) configuration via kppp de la connexion : j'avais un peu galéré au
début car kppp voulait absolument être lancé par root mais j'ai plus ou
moins réglé le problème en rajoutant les groupes dialout et dip à 'toto'
puis en créant un fichier contenant la chaîne 'noauth' appelé en
argument de pppd, mais je ne suis pas sûr du tout que ce soit la bonne
méthode.
5) Lecture de http://www.tldp.org/HOWTO/Security-Quickstart-HOWTO et de
http://olivieraj.free.fr/fr/linux/information/firewall
6) Désactivation des services inutiles :
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
7) Définition des règles iptables, là ce fut la partie difficile. Après
quelques tentatives personnelles plus ou moins fructueuses je me suis
rabattu sur le script que fournissait l'auteur de la doc sur les
firewall vu au 5) : netfilter_cfg (disponible à l'adresse
http://olivieraj.free.fr/fr/linux/programme/netfilter_cfg/)
J'ai ajouté un appel à ce script dans /etc/ppp/ip-up.d/01iptables
Maintenant quand je fais 'iptables -L -n -v' en étant connecté
j'obtiens :
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:4660:4700
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:4660:4700
0 0 DROP tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10738
0 0 DROP udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:10738
26 1541 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- ppp0 * 0.0.0.0/0 80.9.46.140
state RELATED,ESTABLISHED
0 0 DROP all -- ppp0 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 10.0.0.0/8 0.0.0.0/0
0 0 DROP all -- ppp0 * 172.16.0.0/12 0.0.0.0/0
0 0 DROP all -- ppp0 * 192.168.0.0/16 0.0.0.0/0
0 0 DROP all -- ppp0 * 224.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
0 0 DROP all -- ppp0 * 240.0.0.0/4 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
26 1541 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 state
NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- * ppp0 80.9.46.140 0.0.0.0/0
state NEW,RELATED,ESTABLISHED
8) Installation de 'bastille' (version 1:1.3.0-2) sensé 'durcir' le
système(j'ai choisi les options proposé par défaut partout sauf pour les
règles iptables)
9) Installation de l'IDS snort et de snortsnarf au cas où.
Voilà à partir de là je ne sais plus trop quoi faire. Quelques questions
que je me pose cependant :
-J'ai beaucoup entendu parler de 'sudo', 'setuid','chrootage' mais je
n'ai jamais eu besoin de faire appel à ça jusqu'ici, mais peut-être
ai-je eu tort ?
-j'ai du mal à interpreter les informations envoyés par snort (via
snortsnarf), par exemple je ne vois jamais de tentative de connexion de
ce Blaster dont tous le monde me parle, est-ce qu'il faut configurer son
snort pour que celui-ci reconnaisse les tentatives de connexion (ici un
P2P, ici un ver, ici une tentative d'exploitation de failles) et n'est
ce pas déjà disponible quelque part ? Je n'ai pas voulu installer de
serveur MySQL ou autre pour gérer dans une base de données les
informations de snort, cela ajouterait un serveur de plus à maintenir,
est-ce que j'ai eu raison ? J'ai aussi essayé prelude et celui-ci
voulait aussi absolument installer un MySQL pour pouvoir exploiter les
logs...
-Je ne vois pas très bien ou se place l'IDS dans mon cas ? est-il
derrière le firewall ou devant ? et où faut-il idéalement le placer (je
ne dispose que d'une seule machine !)
-J'ai longuement hésité entre définir mes propres règles iptables (via
un script ou pas) et utiliser un firewall (guarddog ?) déjà tout fait.
Que me recommandez vous ? et sinon quel est le firewall 'tout fait' le
plus efficace ?
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Merci à tous ceux qui sont arrivé jusqu'ici et j'attends donc vos
commentaires et ou conseils et ou critiques (qui sont les bienvenues !)
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
tcp 0 0 *:nntp *:* LISTEN 248/inetd
tcp 0 0 *:smtp *:* LISTEN 357/master
Je pense avoir gardé le minimum vital.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire pour
les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Concernant de la documentation sur la sécurité, il existe au moins
deux bons bouquins traduits en Français :
- Sécurité sous Linux, Aron Hsiao, édition CampusPress
(www.campuspress.net), ISBN 2-7440-1222-X
- Administration réseaux sous Linux, Olaf Kirsch & Terry Dawson,
édition O'Reilly (www.oreilly.fr), ISBN 2-84177-125-3
Ils sont trés didactiques avec des exemples (notamment de firewall).
Même moi, j'ai (presque) tout compris même si je n'ai pas tout mis en
pratique sur ma machine.
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Concernant de la documentation sur la sécurité, il existe au moins
deux bons bouquins traduits en Français :
- Sécurité sous Linux, Aron Hsiao, édition CampusPress
(www.campuspress.net), ISBN 2-7440-1222-X
- Administration réseaux sous Linux, Olaf Kirsch & Terry Dawson,
édition O'Reilly (www.oreilly.fr), ISBN 2-84177-125-3
Ils sont trés didactiques avec des exemples (notamment de firewall).
Même moi, j'ai (presque) tout compris même si je n'ai pas tout mis en
pratique sur ma machine.
-Quelles sont les autres voies à explorer pour améliorer encore la
sécurité ?
Concernant de la documentation sur la sécurité, il existe au moins
deux bons bouquins traduits en Français :
- Sécurité sous Linux, Aron Hsiao, édition CampusPress
(www.campuspress.net), ISBN 2-7440-1222-X
- Administration réseaux sous Linux, Olaf Kirsch & Terry Dawson,
édition O'Reilly (www.oreilly.fr), ISBN 2-84177-125-3
Ils sont trés didactiques avec des exemples (notamment de firewall).
Même moi, j'ai (presque) tout compris même si je n'ai pas tout mis en
pratique sur ma machine.
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
"mamachine", c'est "localhost" (l'interface de loopback)?
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Je pense avoir gardé le minimum vital.
Chez moi:
$ netstat -ltu
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante
[SNIP]
Pas besoin de grand chose de plus.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
"mamachine", c'est "localhost" (l'interface de loopback)?
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Je pense avoir gardé le minimum vital.
Chez moi:
$ netstat -ltu
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante
[SNIP]
Pas besoin de grand chose de plus.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
tcp 0 0 *:webcache *:* LISTEN 384/wwwoffled
tcp 0 0 *:tproxy *:* LISTEN 384/wwwoffled
tcp 0 0 mamachine:8118 *:* LISTEN 363/privoxy
"mamachine", c'est "localhost" (l'interface de loopback)?
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Je pense avoir gardé le minimum vital.
Chez moi:
$ netstat -ltu
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale Adresse distante
[SNIP]
Pas besoin de grand chose de plus.
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
2003-12-13, 14:50(+01), Stephane Chazelas:
[...]Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour> les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
2003-12-13, 14:50(+01), Stephane Chazelas:
[...]
Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour> les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
2003-12-13, 14:50(+01), Stephane Chazelas:
[...]Au cas où j'ai quand même utilisé le Tcpwrappers pour leafnode en
modifiant le /etc/inetd.conf, je pense que ce n'est pas nécessaire
pour> les autres.
Je connais pas leafnode, mais ça m'étonnerait que tu ne puisses
pas lui dire de n'écouter que sur l'interface de loopback.
Avec slrnpull, pas besoin de faire tourner un daemon
supplémentaire comme leafnode. slrnpull peut aussi s'utiliser
avec pine ou tin au moins (pour le postage d'article aussi sans
doute, mais peut-etre moyennant un petit script d'adaptation).
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
C'est effectivement un outil d'administration. Mais comment limiter les
interfaces à ma machine ?
"mamachine", c'est "localhost" (l'interface de loopback)?
Oui en effet mamachine est le nom de ma machine (je ne connais pas le
terme 'interface de loopback'
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
Pareil ; je ne sais pas comment limiter l'interface...
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
C'est leafnode qui est lancé. Je crois effectivement que c'est un
serveur de news ? Je ne connais pas d'autre moyens pour consulter les
news offline...
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses emails.
Par contre il me semblait avoir lu quelque part dans une doc concernant
l'administration d'une Debian que celle-ci exigeait d'avoir un serveur
de mail pour recevoir les emails d'avertissement destinés à root.
J'avoue que je n'ai pas bien saisi...
leafnode est un serveur de news comme INN.
Mais je ne sais pas comment lui dire de n'écouter que les informations
provenant de ma machine...
Merci pour tes commentaires. Pourrais-tu m'indiquer de quels docs tu
tiens tes 'mesures de sécurité' ?
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
C'est effectivement un outil d'administration. Mais comment limiter les
interfaces à ma machine ?
"mamachine", c'est "localhost" (l'interface de loopback)?
Oui en effet mamachine est le nom de ma machine (je ne connais pas le
terme 'interface de loopback'
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
Pareil ; je ne sais pas comment limiter l'interface...
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
C'est leafnode qui est lancé. Je crois effectivement que c'est un
serveur de news ? Je ne connais pas d'autre moyens pour consulter les
news offline...
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses emails.
Par contre il me semblait avoir lu quelque part dans une doc concernant
l'administration d'une Debian que celle-ci exigeait d'avoir un serveur
de mail pour recevoir les emails d'avertissement destinés à root.
J'avoue que je n'ai pas bien saisi...
leafnode est un serveur de news comme INN.
Mais je ne sais pas comment lui dire de n'écouter que les informations
provenant de ma machine...
Merci pour tes commentaires. Pourrais-tu m'indiquer de quels docs tu
tiens tes 'mesures de sécurité' ?
Maintenant en faisant un netstat -tap | grep LISTEN j'obtiens :
tcp 0 0 *:linuxconf *:* LISTEN 248/inetd
Connais pas, est-il vraiment nécessaire de le laisser ouvert sur
toutes les interfaces, tu comptes faire de l'administration à
distance de ta machine ?
C'est effectivement un outil d'administration. Mais comment limiter les
interfaces à ma machine ?
"mamachine", c'est "localhost" (l'interface de loopback)?
Oui en effet mamachine est le nom de ma machine (je ne connais pas le
terme 'interface de loopback'
tcp 0 0 *:ipp *:* LISTEN 252/cupsd
À quoi sert d'écouter sur toutes les interfaces.
Pareil ; je ne sais pas comment limiter l'interface...
tcp 0 0 *:nntp *:* LISTEN 248/inetd
Tu fais serveur de news ?!
C'est leafnode qui est lancé. Je crois effectivement que c'est un
serveur de news ? Je ne connais pas d'autre moyens pour consulter les
news offline...
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses emails.
Par contre il me semblait avoir lu quelque part dans une doc concernant
l'administration d'une Debian que celle-ci exigeait d'avoir un serveur
de mail pour recevoir les emails d'avertissement destinés à root.
J'avoue que je n'ai pas bien saisi...
leafnode est un serveur de news comme INN.
Mais je ne sais pas comment lui dire de n'écouter que les informations
provenant de ma machine...
Merci pour tes commentaires. Pourrais-tu m'indiquer de quels docs tu
tiens tes 'mesures de sécurité' ?
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
Note xinetd qui te permet de te passer des tcp wrappers.
(http://www.xinetd.org).
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
C'est effectivement un outil d'administration. Mais comment limiter
les interfaces à ma machine ?
Quand tu crées une listening socket, tu spécifies une adresse et
un port. Si tu mets 0 comme adresse, le système écoute sur
toutes les interfaces. Si tu mets une adresse IP, seuls les
packets à destination de cette adresse seront acceptés pour
cette socket, donc si tu mets l'adresse d'une interface, ça
revient à n'écouter que sur cette interface.
C'est au moment du "bind()" que c'est fait. Les applications
doivent donc avoir prévu un paramètre de configuration pour ça.
Le inetd de GNU n'a pas ce genre d'option, mais peut utiliser
tcpd pour rejeter les connexions que l'on ne veut pas après que
la connexion ait été établie par inetd mais avant que
l'application qui va l'utiliser ne soit démarrée. xinetd permet
de spécifier une ou plusieurs adresses de bind.
Maintenant, l'utilisation de règles iptable te permet de faire
un filtrage par dessus, c'est peut-être le moyen le plus simple
pour établir une politique globale sur ton système.
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses
emails. Par contre il me semblait avoir lu quelque part dans une doc
concernant l'administration d'une Debian que celle-ci exigeait
d'avoir un serveur de mail pour recevoir les emails d'avertissement
destinés à root. J'avoue que je n'ai pas bien saisi...
On peut avoir un système de mail sans avoir de serveur SMTP, le
tout étant de fournir une interface cohérente. Les solutions de
mail qu'on trouve aujourd'hui sont souvent surdimensionnées et
inadaptées pour une utilisation sur un PC personnel avec
connexion RTC intermittante. Difficile aujourd'hui en effet de
se passer d'un serveur SMTP même s'il ne sert à rien vu qu'on ne
reçoit pas de mail de l'extérieur.
C'est effectivement un outil d'administration. Mais comment limiter
les interfaces à ma machine ?
Quand tu crées une listening socket, tu spécifies une adresse et
un port. Si tu mets 0 comme adresse, le système écoute sur
toutes les interfaces. Si tu mets une adresse IP, seuls les
packets à destination de cette adresse seront acceptés pour
cette socket, donc si tu mets l'adresse d'une interface, ça
revient à n'écouter que sur cette interface.
C'est au moment du "bind()" que c'est fait. Les applications
doivent donc avoir prévu un paramètre de configuration pour ça.
Le inetd de GNU n'a pas ce genre d'option, mais peut utiliser
tcpd pour rejeter les connexions que l'on ne veut pas après que
la connexion ait été établie par inetd mais avant que
l'application qui va l'utiliser ne soit démarrée. xinetd permet
de spécifier une ou plusieurs adresses de bind.
Maintenant, l'utilisation de règles iptable te permet de faire
un filtrage par dessus, c'est peut-être le moyen le plus simple
pour établir une politique globale sur ton système.
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses
emails. Par contre il me semblait avoir lu quelque part dans une doc
concernant l'administration d'une Debian que celle-ci exigeait
d'avoir un serveur de mail pour recevoir les emails d'avertissement
destinés à root. J'avoue que je n'ai pas bien saisi...
On peut avoir un système de mail sans avoir de serveur SMTP, le
tout étant de fournir une interface cohérente. Les solutions de
mail qu'on trouve aujourd'hui sont souvent surdimensionnées et
inadaptées pour une utilisation sur un PC personnel avec
connexion RTC intermittante. Difficile aujourd'hui en effet de
se passer d'un serveur SMTP même s'il ne sert à rien vu qu'on ne
reçoit pas de mail de l'extérieur.
C'est effectivement un outil d'administration. Mais comment limiter
les interfaces à ma machine ?
Quand tu crées une listening socket, tu spécifies une adresse et
un port. Si tu mets 0 comme adresse, le système écoute sur
toutes les interfaces. Si tu mets une adresse IP, seuls les
packets à destination de cette adresse seront acceptés pour
cette socket, donc si tu mets l'adresse d'une interface, ça
revient à n'écouter que sur cette interface.
C'est au moment du "bind()" que c'est fait. Les applications
doivent donc avoir prévu un paramètre de configuration pour ça.
Le inetd de GNU n'a pas ce genre d'option, mais peut utiliser
tcpd pour rejeter les connexions que l'on ne veut pas après que
la connexion ait été établie par inetd mais avant que
l'application qui va l'utiliser ne soit démarrée. xinetd permet
de spécifier une ou plusieurs adresses de bind.
Maintenant, l'utilisation de règles iptable te permet de faire
un filtrage par dessus, c'est peut-être le moyen le plus simple
pour établir une politique globale sur ton système.
tcp 0 0 *:smtp *:* LISTEN 357/master
Tu fais serveur de mail ?!
Non j'utilise sylpheed qui s'occupe d'envoyer directement ses
emails. Par contre il me semblait avoir lu quelque part dans une doc
concernant l'administration d'une Debian que celle-ci exigeait
d'avoir un serveur de mail pour recevoir les emails d'avertissement
destinés à root. J'avoue que je n'ai pas bien saisi...
On peut avoir un système de mail sans avoir de serveur SMTP, le
tout étant de fournir une interface cohérente. Les solutions de
mail qu'on trouve aujourd'hui sont souvent surdimensionnées et
inadaptées pour une utilisation sur un PC personnel avec
connexion RTC intermittante. Difficile aujourd'hui en effet de
se passer d'un serveur SMTP même s'il ne sert à rien vu qu'on ne
reçoit pas de mail de l'extérieur.
2003-12-14, 21:02(+01), Pham:
[...]Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
inetd est un meta-daemon. Il permet d'éviter de faire tourner
12000 daemons quand on veut fournir 12000 services. C'est lui
qui gère les requetes et les dispatche en démarrant le serveur
correspondant au besoin.
C'est lui qui écoute sur le port 119 établit les connexions et
lance leafnode après. leafnode n'écoute pas, il n'a même
probablement pas de notion de réseau, il peut se contenter de
lire et écrire sur ses entree/sortie standard qu'inetd s'est
chargé de relier à la socket.
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Vu que ton inetd ne fournit qu'un service, tu peux même
carrément t'en passer et lancer leafnode en standalone.
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
On note chez les distribution une préférence pour les outils GNU
même quand ils sont moins bien foutus que les autres. L'avantage
du inetd de GNU est qu'il est semblable dans sa configuration à
la plupart des autres inetd qu'on trouve sur d'autres systèmes,
et qu'il est basé sur du code BSD longuement éprouvé.
xinetd est censé apporter plus de flexibilité et améliorer la
sécurité (voir à http://www.xinetd.org/ pour plus de détails).
2003-12-14, 21:02(+01), Pham:
[...]
Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
inetd est un meta-daemon. Il permet d'éviter de faire tourner
12000 daemons quand on veut fournir 12000 services. C'est lui
qui gère les requetes et les dispatche en démarrant le serveur
correspondant au besoin.
C'est lui qui écoute sur le port 119 établit les connexions et
lance leafnode après. leafnode n'écoute pas, il n'a même
probablement pas de notion de réseau, il peut se contenter de
lire et écrire sur ses entree/sortie standard qu'inetd s'est
chargé de relier à la socket.
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Vu que ton inetd ne fournit qu'un service, tu peux même
carrément t'en passer et lancer leafnode en standalone.
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
On note chez les distribution une préférence pour les outils GNU
même quand ils sont moins bien foutus que les autres. L'avantage
du inetd de GNU est qu'il est semblable dans sa configuration à
la plupart des autres inetd qu'on trouve sur d'autres systèmes,
et qu'il est basé sur du code BSD longuement éprouvé.
xinetd est censé apporter plus de flexibilité et améliorer la
sécurité (voir à http://www.xinetd.org/ pour plus de détails).
2003-12-14, 21:02(+01), Pham:
[...]Oops, j'ai rien dit, j'avais pas tilté que tu passais par inetd.
Euh... je ne comprends pas ton commentaire ?
inetd est un meta-daemon. Il permet d'éviter de faire tourner
12000 daemons quand on veut fournir 12000 services. C'est lui
qui gère les requetes et les dispatche en démarrant le serveur
correspondant au besoin.
C'est lui qui écoute sur le port 119 établit les connexions et
lance leafnode après. leafnode n'écoute pas, il n'a même
probablement pas de notion de réseau, il peut se contenter de
lire et écrire sur ses entree/sortie standard qu'inetd s'est
chargé de relier à la socket.
OK. Mais est-il vraiment utile de passer de inetd à xinetd ?
Vu que ton inetd ne fournit qu'un service, tu peux même
carrément t'en passer et lancer leafnode en standalone.
Et pourquoi ma Debian Woody ne m'a pas installé ça par défaut ?
On note chez les distribution une préférence pour les outils GNU
même quand ils sont moins bien foutus que les autres. L'avantage
du inetd de GNU est qu'il est semblable dans sa configuration à
la plupart des autres inetd qu'on trouve sur d'autres systèmes,
et qu'il est basé sur du code BSD longuement éprouvé.
xinetd est censé apporter plus de flexibilité et améliorer la
sécurité (voir à http://www.xinetd.org/ pour plus de détails).