[LONG] Comment securiser sa machine Linux (Debian) ?

Le
Pham
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 !)
  • Partager ce contenu :
Vos réponses Page 1 / 2
Trier par : date / pertinence
Frencia
Le #881254
Pham wrote:

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

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.

Salutations

JPF

Stephane Chazelas
Le #884272
2003-12-12, 19:56(+01), Pham:
[...]
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 Etat
$ ps -eH -o args
COMMAND
init [3]
[keventd]
[ksoftirqd_CPU0]
[kswapd]
[bdflush]
[kupdated]
/usr/sbin/crond -l8
/usr/sbin/syslogd
/usr/sbin/klogd
login -- chazelas
xinit /home/chazelas/.xinitrc -- /home/chazelas/.xserverrc
/usr/X11R6/bin/Xwrapper -nolisten tcp -auth /home/chazelas/.Xauthority
ion
uxterm -u8 +lc -C -e screen -UR
screen -UR
SCREEN -UR
/bin/zsh
elinks
/usr/local/bin/slrn.bin --spool
vim +8 /home/chazelas/.followup
/bin/zsh
ps -eH -o args
$

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

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]

Stephane Chazelas
Le #884087
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).

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]


Pham
Le #889623
On Sat, 13 Dec 2003 13:39:09 +0100, Frencia

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


Ok merci mais est-ce que ces bouquins ne s'adressent pas plutôt à des
administrateurs réseaux ?
Ca me semble un peu euh...'overkill' pour moi qui désire juste sécuriser
ma machine...


Pham
Le #889442
On Sat, 13 Dec 2003 14:50:07 +0100, Stephane Chazelas

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 ?

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


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

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.


Oui j'aimerais bien en arriver à ce niveau comme toi mais je ne vois pas
comment me passer de tous ces serveurs pour le moment ?

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.


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

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


Je ne connais pas slrnpull mais je ne vois pas très bien comment m'en
sortir pour lire des news offline sans serveur derrière (si je veux
dissocier le logiciel de lecture de news, par exemple PAN ou sylpheed,
et la gestion des news proprement dite).

Merci pour tes commentaires. Pourrais-tu m'indiquer de quels docs tu
tiens tes 'mesures de sécurité' ?


Pham
Le #889441
On Sat, 13 Dec 2003 16:15:02 +0100, Stephane Chazelas

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.


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 ?



Stephane Chazelas
Le #887293
2003-12-14, 21:00(+01), Pham:
[...]
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 ?


Du moment que ton système a une couche IP, elle peut être
connectée à plusieurs réseaux aux travers de différentes
"interfaces" (une carte ethernet, un lien ppp ou une interface
de loopback). Une interface de loopback est un fil qui part de
ton ordinateur et qui boucle sur celui-ci (virtuellement, le
bouclage est software, c'était pour imager le terme loopback).

$ ifconfig -a
lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Tu as un réseau de classe A (127.0.0.0/8) sur lequel il n'y a
que ta machine (127.1) et qui n'est visible que depuis ta
machine. Il sert a établir des connexions TCP/UDP... internes au
système.

Le nom associé à 127.1 est en général "localhost". Ça ne fait
pas beaucoup de sens de lui associer "mamachine". Tu peux créer
d'autres interfaces de loopback si tu veux
(ifconfig lo:toto 127.2 par exemple)

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. Pour linuxconf,
il faut voir dans la config de linuxconf.

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.

[...]
"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'


Le nom de ta machine, c'est ce que renvoie uname -n, ça n'est
pas forcément lié au nom attribué à une adresse d'une interface.

tcp 0 0 *:ipp *:* LISTEN 252/cupsd


À quoi sert d'écouter sur toutes les interfaces.


Pareil ; je ne sais pas comment limiter l'interface...


Voir la config de cups.

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


La plupart des lecteurs de news sont capables d'aller lire
directement dans les spools d'un serveur de news. slrnpull
est un outil qui va télécharger les articles et les stocker sur
disque à la manière du spool d'un serveur de news. leafnode
offre des possibilités supplémentaires par rapport à slrnpull,
donc, si tu es content avec, ça va. Mais écouter sur toutes les
interfaces revient à dire que tu offres ce service à tout le
monde. Maintenant, si tu as des tcp wrappers ou des règles
iptable qui post-limitent l'utilisation, c'est OK aussi, c'est
juste que je trouve plus cohérent de limiter au départ ce qui
est autorisé plutot que d'autoriser tout et n'importe quoi et de
mettre des rustines par dessus.

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.

Sur mon système, j'utilise sendmail et son interface en ligne de
commande, mais j'imagine que ce n'est pas envisageable sur les
distribution récentes (même les versions récentes de sendmail
(8.12.*) ne permettent plus de faire ça facilement).

Mais, là encore tu dois pouvoir limiter les connexions à une
utilisation locale.

[...]
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...


C'est pas lui qui écoute en fait, c'est inetd, d'où mon autre
message.

[...]
Merci pour tes commentaires. Pourrais-tu m'indiquer de quels docs tu
tiens tes 'mesures de sécurité' ?


La sécurité, ça passe beaucoup par le bon sens. Je suis loin
d'être un expert de ce côté-là et le sujet ne me passionne pas
énormément, je ne lis que les manuels des outils que j'utilise.

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]



Stephane Chazelas
Le #887291
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.

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 ?


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

--
Stéphane ["Stephane.Chazelas" arobase "free.fr"]


Pham
Le #891791
On Mon, 15 Dec 2003 12:02:23 +0100, Stephane Chazelas

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.


Donc si je te suis bien ou bien l'application a prévue une option
permettant de limiter les interfaces d'écoute ou bien je peux faire ça
par tcpd. Cependant je faire un 'man tcpd' et il ne parle pas du tout de
cet aspect là-dedans ?
Est-ce que c'est lors de l'appel à tcpd dans le inetd.conf (par exemple
la ligne '/usr/sbin/tcpd /usr/sbin/leafnode') que je dois passer des
arguments spécifiques ?

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.


Oui effectivement, cependant je trouve aussi qu'il est plus cohérent de
limiter ce que l'on fait au départ...

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.


Si mon besoin se limitait juste à écrire et recevoir des emails de mes
amis, je n'aurais effectivement pas besoin de serveur SMTP. Cependant
apparemment Debian utilise ce serveur pour m'envoyer des messages
d'avertissement de temps en temps. Donc il me faudrait modifier la
configuration de ces outils qui m'envoient des messages... Je ne pense
pas en être encore capable donc je vais déjà essayer de limiter
l'interface d'écoute.

En résumé histoire d'avoir une politique plus claire pour les serveurs,
je pense que je vais tout faire passer par tcpd pour limiter l'interface
d'écoute à l'interface de loopback. Cela me paraît un bon compromis
entre efficacité et temps passé à administrer.
Mais bon je n'ai rien trouvé dans le 'man tcpd' pour cela, comment faire
donc ?

Merci encore pour ton aide !




Pham
Le #891789
On Mon, 15 Dec 2003 12:15:18 +0100, Stephane Chazelas

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.


Ah ça y est ! je viens de comprendre ! merci !

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.


Effectivement, cependant comme expliqué dans mon autre message je pense
faire passer tous les services par inetd dans le futur...

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



Ok bon je ne pense pas m'y connaître assez pour remettre en question la
politique des distributions majeures. Je vais donc rester sur inetd en
attendant d'y voir un peu plus clair...

Merci !



Poster une réponse
Anonyme