[LONG] Comment securiser sa machine Linux (Debian) ?
12 réponses
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 :
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 !)
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 ? [...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des tcp wrappers qui vient aussi avec une bibliothèque libwrap que d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow, /etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle interface, ce n'est pas tcpd qui écoute ou crée la connexion, c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la connexion (une fois qu'elle est établie) en se basant sur les adresses source et destinations de la socket et les règles définies dans /etc/hosts.*. C'est du post-filtrage encore plus haut niveau qu'iptables.
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 ?
[...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des
tcp wrappers qui vient aussi avec une bibliothèque libwrap que
d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow,
/etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle
interface, ce n'est pas tcpd qui écoute ou crée la connexion,
c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la
connexion (une fois qu'elle est établie) en se basant sur les
adresses source et destinations de la socket et les règles
définies dans /etc/hosts.*. C'est du post-filtrage encore plus
haut niveau qu'iptables.
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 ? [...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des tcp wrappers qui vient aussi avec une bibliothèque libwrap que d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow, /etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle interface, ce n'est pas tcpd qui écoute ou crée la connexion, c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la connexion (une fois qu'elle est établie) en se basant sur les adresses source et destinations de la socket et les règles définies dans /etc/hosts.*. C'est du post-filtrage encore plus haut niveau qu'iptables.
On Tue, 16 Dec 2003 13:03:49 +0100, Stephane Chazelas
2003-12-16, 12:42(+01), Pham: [...]
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 ? [...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des tcp wrappers qui vient aussi avec une bibliothèque libwrap que d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow, /etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle interface, ce n'est pas tcpd qui écoute ou crée la connexion, c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la connexion (une fois qu'elle est établie) en se basant sur les adresses source et destinations de la socket et les règles définies dans /etc/hosts.*. C'est du post-filtrage encore plus haut niveau qu'iptables.
Voir: man 5 hosts_access
Ok je pense que cette fois j'ai saisi. Après lecture des 'man' de postfix, cups et de wwwoffle j'ai réussi à trouver l'option pour limiter l'interface d'écoute. Pour postfix, c'est dans /etc/postfix/main.cf il faut rajouter : inet_interfaces = $myhostname Pour cups, c'est dans /etc/cups/cupsd.conf il faut rajouter : Listen 127.0.0.1:631 Pour wwwoffle, c'est dans /etc/wwwoffle/wwwoffle.conf il faut rajouter : bind-ipv4 = 127.0.0.1
Pour leafnode (le serveur nntp lancé par inetd) le seul moyen est de configurer le /etc/hosts.allow, là surprise sans rien toucher j'avais :
************ DEBUT ************** #-- leafnode begin leafnode: 127.0.0.1 #-- leafnode end
ALL : 127.0.0.1 # Bastille: default deny # no safe_finger for in.fingerd (prevent loops) in.fingerd : ALL : DENY # but everything else is denied & reported with safe_finger ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port Denial noted %d-%h" root) & : DENY ************ FIN **************
Et dans le /etc/hosts.deny : ************ DEBUT ************** ALL : ALL
#-- leafnode begin leafnode: ALL #-- leafnode end ************ FIN **************
Ce qui signifie si je comprends bien que leafnode s'était configuré pour que tcpd rejette les connexions venant de l'extérieur et que Bastille en plus de cela avait rajouté que tous les services lancés par tcpd rejette aussi toutes les connexions venant de l'extérieur mais qu'en plus un email était envoyé à root pour le notifier qu'une tentative de connexion avait eu lieu.
Est-ce que tout est ok ?
Merci encore pour ta précieuse aide !
*********** REPLY SEPARATOR ***********
On Tue, 16 Dec 2003 13:03:49 +0100, Stephane Chazelas
2003-12-16, 12:42(+01), Pham:
[...]
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 ?
[...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des
tcp wrappers qui vient aussi avec une bibliothèque libwrap que
d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow,
/etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle
interface, ce n'est pas tcpd qui écoute ou crée la connexion,
c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la
connexion (une fois qu'elle est établie) en se basant sur les
adresses source et destinations de la socket et les règles
définies dans /etc/hosts.*. C'est du post-filtrage encore plus
haut niveau qu'iptables.
Voir: man 5 hosts_access
Ok je pense que cette fois j'ai saisi.
Après lecture des 'man' de postfix, cups et de wwwoffle j'ai réussi à
trouver l'option pour limiter l'interface d'écoute.
Pour postfix, c'est dans /etc/postfix/main.cf il faut rajouter :
inet_interfaces = $myhostname
Pour cups, c'est dans /etc/cups/cupsd.conf il faut rajouter :
Listen 127.0.0.1:631
Pour wwwoffle, c'est dans /etc/wwwoffle/wwwoffle.conf il faut rajouter :
bind-ipv4 = 127.0.0.1
Pour leafnode (le serveur nntp lancé par inetd) le seul moyen est
de configurer le /etc/hosts.allow, là surprise sans rien toucher j'avais
:
************ DEBUT **************
#-- leafnode begin
leafnode: 127.0.0.1
#-- leafnode end
ALL : 127.0.0.1
# Bastille: default deny
# no safe_finger for in.fingerd (prevent loops)
in.fingerd : ALL : DENY
# but everything else is denied & reported with safe_finger
ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port
Denial noted %d-%h" root) & : DENY
************ FIN **************
Et dans le /etc/hosts.deny :
************ DEBUT **************
ALL : ALL
#-- leafnode begin
leafnode: ALL
#-- leafnode end
************ FIN **************
Ce qui signifie si je comprends bien que leafnode s'était configuré pour
que tcpd rejette les connexions venant de l'extérieur et que Bastille en
plus de cela avait rajouté que tous les services lancés par tcpd rejette
aussi toutes les connexions venant de l'extérieur mais qu'en plus un
email était envoyé à root pour le notifier qu'une tentative de connexion
avait eu lieu.
On Tue, 16 Dec 2003 13:03:49 +0100, Stephane Chazelas
2003-12-16, 12:42(+01), Pham: [...]
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 ? [...]
tcpd ne sert qu'en conjonction avec inetd. tcpd fait partie des tcp wrappers qui vient aussi avec une bibliothèque libwrap que d'autres applications peuvent aussi utiliser.
libwrap et tcpd utilisent les fichiers /etc/hosts.allow, /etc/hosts.deny. Ils ne servent pas à écouter sur telle ou telle interface, ce n'est pas tcpd qui écoute ou crée la connexion, c'est inetd. tcpd se charge de rejeter (refermer) ou d'accepter la connexion (une fois qu'elle est établie) en se basant sur les adresses source et destinations de la socket et les règles définies dans /etc/hosts.*. C'est du post-filtrage encore plus haut niveau qu'iptables.
Voir: man 5 hosts_access
Ok je pense que cette fois j'ai saisi. Après lecture des 'man' de postfix, cups et de wwwoffle j'ai réussi à trouver l'option pour limiter l'interface d'écoute. Pour postfix, c'est dans /etc/postfix/main.cf il faut rajouter : inet_interfaces = $myhostname Pour cups, c'est dans /etc/cups/cupsd.conf il faut rajouter : Listen 127.0.0.1:631 Pour wwwoffle, c'est dans /etc/wwwoffle/wwwoffle.conf il faut rajouter : bind-ipv4 = 127.0.0.1
Pour leafnode (le serveur nntp lancé par inetd) le seul moyen est de configurer le /etc/hosts.allow, là surprise sans rien toucher j'avais :
************ DEBUT ************** #-- leafnode begin leafnode: 127.0.0.1 #-- leafnode end
ALL : 127.0.0.1 # Bastille: default deny # no safe_finger for in.fingerd (prevent loops) in.fingerd : ALL : DENY # but everything else is denied & reported with safe_finger ALL : ALL : spawn (/usr/sbin/safe_finger -l @%h | /bin/mail -s "Port Denial noted %d-%h" root) & : DENY ************ FIN **************
Et dans le /etc/hosts.deny : ************ DEBUT ************** ALL : ALL
#-- leafnode begin leafnode: ALL #-- leafnode end ************ FIN **************
Ce qui signifie si je comprends bien que leafnode s'était configuré pour que tcpd rejette les connexions venant de l'extérieur et que Bastille en plus de cela avait rajouté que tous les services lancés par tcpd rejette aussi toutes les connexions venant de l'extérieur mais qu'en plus un email était envoyé à root pour le notifier qu'une tentative de connexion avait eu lieu.
