Les services présents sur un système peuvent être sécurisés de deux façons :
Restreindre les services pour qu'ils soient accessibles que depuis un endroit bien spécifique peut être fait au niveau du noyau (pare-feu), configurez les services pour écouter uniquement sur une interface définie (certains services ne fournissent peut-être pas cette fonctionnalité) ou utilisez tout autre méthode, par exemple la rustine vserver pour linux (pour 2.4.16) peut être utilisée pour forcer les processus à n'utiliser qu'une interface.
Concernant les services lancés par inetd
(telnet
,
ftp
, finger
, pop3
, etc.), il est à noter
que inetd ne peut pas être configuré pour que des services n'écoutent
uniquement que sur une interface précise. Toutefois, son remplaçant, le
méta-démon xinetd
, inclut un raccourci pour faire
cela. Voir xinetd.conf(5)
.
service nntp { socket_type = stream protocol = tcp wait = no user = news group = news server = /usr/bin/env server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin +/usr/sbin/snntpd logger -p news.info bind = 127.0.0.1 }
Les paragraphes suivants détaillent comment déterminer les services qui peuvent être configurés correctement s'appuyant sur une utilisation définie.
Si vous utilisez toujours telnet au lieu de ssh, vous devriez prendre une pause dans la lecture de ce manuel pour remédier à cela. Ssh devrait être utilisé pour toutes les connexions distantes à la place de telnet. À une époque où il est facile de scruter le trafic Internet et d'obtenir les mots de passe en clair, vous devriez utiliser uniquement les protocoles qui utilisent la cryptographie. Par conséquent, effectuez maintenant un apt-get install ssh sur votre système.
Encourager tous les utilisateurs de votre système à utiliser ssh au lieu de
telnet, ou mieux encore, désinstallez telnet/telnetd. De plus, vous devriez
éviter de vous connecter au système en utilisant ssh en tant que root et
préférer l'utilisation de méthodes alternatives pour devenir root tel
su ou sudo. Enfin, le fichier
sshd_config
, dans /etc/ssh
, devrait être modifié
ainsi pour accroître la sécurité :
Ne faîtes écouter ssh que sur une interface donnée, juste au cas où vous en avez plus d'une (et ne voulez pas que ssh y soit disponible) ou si vous ajoutez, dans le futur, une nouvelle carte réseau (et ne voulez pas de connexions ssh dessus).
Essayez autant que possible de ne pas autoriser de connexion en tant que root. Si quelqu'un veut devenir root via ssh, deux logins sont maintenant nécessaires et le mot de passe root ne peut être attaqué par la force brute via SSH.
Change le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un démon sshd (soyez prévenus, c'est de la sécurité par l'obscurité).
Les mots de passe vides sont un affront au système de sécurité.
Autorise seulement certains utilisateurs à avoir accès via ssh à cette machine. user@host peut également être utilisé pour n'autoriser l'accès qu'à un utilisateur donné depuis un hôte donné.
Autorise seulement certains membres de groupes à avoir accès via ssh à cette machine. AllowGroups et AllowUsers ont des directives équivalentes pour interdire l'accès à la machine. Sans surprise elles s'appellent « DenyUsers » et « DenyGroups ».
Il vous appartient complètement de décider ce que vous voulez faire. Il est
plus sûr d'autoriser l'accès à la machine uniquement aux utilisateurs avec des
clés ssh placées dans le fichier ~/.ssh/authorized_keys
. Si c'est
ce que vous voulez, positionnez cette option à "no".
sshd_config(5)
).
Désactiver le protocole version 1, car il a des défauts de conception qui
facilite le crack de mots de passe. Pour plus d'informations, lisez un article
concernant les problèmes du protocole ssh
ou le bulletin d'alerte
Xforce
.
Ajouter une bannière (ellev sera récupérée du fichier) pour les utilisateurs se connectant au serveur ssh, dans certains pays, envoyer un avertissement avant l'accès à un système donné avertissant des accès non autorisés ou du suivi des utilisateurs devrait être ajouté pour avoir une protection légale.
Vous pouvez également restreindre l'accès au serveur ssh en utilisant
pam_listfile ou pam_wheel dans le fichier de contrôle
PAM de ssh pour restreindre les connexions ssh. Par exemple, vous pourriez
empêcher tous les utilisateurs qui ne sont pas dans
/etc/loginusers
en ajoutant cette ligne à
/etc/pam.d/ssh
:
auth required pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers
Pour finir, soyez conscient que ces directives proviennent d'un fichier de
configuration OpenSSH. Actuellement, il y a 3 démons ssh couramment utilisés,
ssh1, ssh2, et OpenSSH par les gens d'OpenBSD. Ssh1 était le premier démon ssh
disponible et est toujours le plus couramment utilisé (il y a des rumeurs qu'il
y aurait même un portage pour Windows). Ssh2 a beaucoup d'avantages par
rapport à ssh1 excepté qu'il est diffusé sous une licence non libre. OpenSSH
est un démon ssh complètement libre, qui supporte à la fois ssh1 et ssh2.
OpenSSH est la version installée sur Debian quand le paquetage ssh
est choisi.
Vous pouvez obtenir plus d'informations concernant la mise en place de SSH avec
le support PAM dans les archives
de la liste de discussion sécurité
.
OpenSSH ne fournit pas de moyen à l'heure actuelle pour chrooter
automatiquement les utilisateurs lors de la connexion (la version commerciale
fournit cette fonctionnalité). Cependant, il existe un projet ayant pour but
de fournir cette fonctionnalité pour OpenSSH également, voir http://chrootssh.sourceforge.net
,
il n'est cependant pas empaqueté pour Debian actuellement. Vous pourriez
cependant utiliser le module pam_chroot
module comme décrit dans
Restriction des utilisateurs, Section
4.10.8.
Dans Chroot
environment for
SSH
, Annexe H, vous pouvez trouver plusieurs options pour
créer des environnements chroot pour SSH.
Si vous utilisez un client SSH contre (?) le serveur SSH, vous devez vous
assurer qu'ils supportent les mêmes protocoles qui sont en application sur le
serveur. Par exemple, si vous utilisez le paquet mindterm
, il ne
supporte que le protocole version 1. Cependant, le serveur sshd est, par
défaut, configuré pour n'accepter que la version 2 (pour des raisons de
sécurité).
Si vous ne voulez pas que les utilisateurs transfèrent des fichiers
depuis et vers le serveur ssh, vous devez restreindre l'accès au
sftp-server
et l'accès scp
. Vous pouvez
restreindre sftp-server
en configurant le bon
Subsystem dans /etc/ssh/sshd_config
. Cependant, pour
restreindre l'accès scp
, vous devez :
Squid est l'un des plus populaires serveurs mandataire (« proxy ») et
cache et certains problèmes de sécurité sont à prendre en compte. Le fichier
de configuration par défaut de Squid refuse toutes les requêtes d'utilisateurs.
Cependant, le paquet Debian permet l'accès depuis « localhost », il
est simplement nécessaire de configurer votre navigateur correctement. Vous
devriez configurer Squid pour permettre l'accès aux utilisateurs, hôtes ou
réseaux de confiance en définissant une Liste de Contrôle d'Accès (ACL) dans
/etc/squid.conf
. Voir le Guide
d'utilisateur de Squid
pour plus d'informations à propos des règles
ACL. Veuillez noter que Debian fournit une configuration minimale pour Squi
qui empêche tout, à l'exception de la connexion de localhost au
serveur mandataire (qui fonctionnera sur le port par défaut 3128). Vous devrez
personnaliser votre fichier/etc/squid.conf
comme nécessaire. La
configuration recommandée minimum (fournie avec le paquet) est indiquée
ci-dessous :
acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl SSL_ports port 443 563 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 563 # https, snews acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl Safe_ports port 901 # SWAT acl purge method PURGE acl CONNECT method CONNECT (...) # Ne permet l'accès à cachemgr que depuis localhost http_access allow manager localhost http_access deny manager # Ne permet des requêtes de purge que depuis localhost http_access allow purge localhost http_access deny purge # Interdit les requêtes sur des ports inconnus http_access deny !Safe_ports # Interdit CONNECT sur tout autre port que SSL http_access deny CONNECT !SSL_ports # # INSÉRER VOTRE (VOS) PROPRE(S) RÊGLES ICI POUR PERMETTRE L'ACCÈS DEPUIS VOS CLIENTS # http_access allow localhost # En enfin, interdit tout autre accès à ce mandataire http_access deny all # Par défaut : # icp_access deny all # # Permet les requêtes ICP depuis tout le monde icp_access allow all
Vous pouvez également configurer Squid selon vos ressources système, en incluant la mémoire cache (option cache_mem), l'emplacement de vos fichiers du cache et la quantité d'espace qu'ils prendront sur disque (option cache_dir).
Notez que, s'il n'est pas configuré correctement, n'importe qui peut relayer un message par l'intermédiaire de Squid, puisque les protocoles HTTP et SMTP sont conçus de façon similaire. Le fichier de configuration par défaut interdit l'accès au port 25. Si vous voulez autoriser les connexions sur ce port, il vous faudra l'ajouter dans la liste des Safe_ports (ports autorisés). Cependant, ce n'est PAS recommandé.
Installer et configurer le serveur mandataire/cache correctement représente seulement une partie de la sécurisation de votre site. Une autre tâche nécessaire consiste dans l'analyse des logs de Squid pour assurer que tout fonctionne comme il se doit. Il y a quelques paquets dans Debian GNU/Linux qui peuvent aider l'administrateur dans cette tâche. Les paquets suivant sont disponible dans Woody (Debian 3.0):
calamaris
- Analyseur de log pour fichiers de Squid ou Oops proxy.
modlogan
- Un analyseur modulaire de fichier logs.
squidtaild
- Programme de surveillance des logs Squid.
Quand vous utilisez Squi en Accelerator Mode, il se comporte également comme un
serveur web. Activer cette option augmente la complexité du code, le rendant
moins fiable. Par défaut, Squid n'est pas configuré pour se comporter comme un
serveur web, donc vous n'avez pas besoin de vous tracasser à cause de cela.
Notez que si vous désirez utiliser cette fonctionnalité, assurez-vous qu'elle
est vraiment nécessaire. Pour trouver plus d'informations à propos de
l'Accelerator Mode de Squid, consultez le Guide de
l'utilisateur de Squid Chapitre 9
.
Si vous avez réellement besoin d'utiliser FTP (sans l'emballer avec sslwrap ou
à l'intérieur d'un tunnel SSL ou SSH), vous devriez « chrooter » ftp
dans le répertoire personnel de l'utilisateur, ainsi l'utilisateur ne pourra
rien voir d'autre que ses propres répertoires. Autrement, il pourrait
parcourir votre système comme s'il avait un shell. Vous pouvez ajouter la
ligne suivante dans votre proftpd.conf
dans la section global pour
activer ce chroot :
DefaultRoot ~
Redémarrez proftpd par /etc/init.d/proftpd restart et vérifiez si vous pouvez sortir de votre propre répertoire personnel.
Pour prévenir Proftpd d'attaques Dos avec l'utilisation de ../../.., ajoutez la
ligne suivante dans /etc/proftpd.conf
: DenyFilter
\*.*/
Rappelez-vous toujours que FTP envoie les identifiants et les mots de passe
d'authentification en clair (ceci n'est pas un problème si vous fournissez un
service public anonyme) et il existe de meilleures alternatives dans Debian
pour cela. Par exemple, sftp
(fourni par ssh
). Il
existe également d'autres implémentatations de SSH pour d'autres systèmes
d'exploitation : putty
et
cygwin
par exemple.
Cependant, si vous maintenez encre le serveur FTP tout en donnant un accès par
SSH aux utilisateurs, vous pouvez rencontrer un problème courant. Les
utilisateurs accédant aux serveurs FTP en anonyme à l'intérieur des systèmes
sécurisés par SSH peuvent essayer de se connecter dans le serveur FTP.
Bien que l'accès sera refusé, le mot de passe sera tout de même envoyé en clair
sur le réseau. Pour éviter cela, le développeur de ProFTPd, TJ Saunders, a
créé un correctif pour empêcher des utilisateurs de fournir au serveur FTP
anonyme des comptes SSH valides. Plus d'informations et le correctif sont
disponibles à : Correctifs ProFTPD
.
Ce correctif a été également indiqué pour Debian, voir le bogue 145669
.
Actuellement, les terminaux X sont de plus en plus utilisés dans les entreprises où un seul serveur est nécessaire pour un grand nombre de stations de travail. Ceci peut être dangereux car vous devez autoriser le serveur de fichiers à se connecter aux clients (le serveur X d'un point de vue X. X intervertit la notion de client et de serveur). Si vous suivez les (très mauvaises) suggestions de nombreuses documentations, vous tapez xhost + sur votre machine. Ceci autorise tout client X à se connecter à votre système. Pour une sécurité légèrement meilleure, vous pouvez utiliser la commande xhost +hostname à la place, ce qui permet d'autoriser uniquement les accès depuis des hôtes spécifiques.
Une solution encore meilleure serait d'utiliser un tunnel ssh pour X et
d'encrypter toute la session. Ceci est fait automatiquement lors de
l'utilisation de ssh pour se connecter sur une autre machine. Pour que cela
fonctionne, vous devez configurer à la fois le client ssh et le serveur ssh.
Sur le client ssh, ForwardX11 doit être positionné à
yes dans /etc/ssh/ssh_config
. Sur le serveur ssh,
X11Forwarding doit être positionné à yes dans
/etc/ssh/sshd_config
et le paquet xbase-clients
doit
être installé car le serveur ssh utilise /usr/X11R6/bin/xauth
pour
mettre en place le pseudo-affichage X. À l'heure de SSH, vous devriez
abandonner complètement le contrôle d'accès basé sur xhost.
Pour une sécurité accrue, si vous n'avez pas besoin d'accéder à X depuis d'autres machines, désactivez-le du port 6000 en tapant simplement :
$ startx -- -nolisten tcp
Ceci est le comportement par défaut dans Xfree 4.1.0 (le serveur X fourni dans
la Debian 3.0). Si vous utilisez Xfree 3.3.6 (vous avez donc la Debian 2.2
d'installée), vous pouvez éditer /etc/X11/xinit/xserverrcc
afin
d'avoir quelque chose ressemblant à ceci :
#!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp
Si vous utilisez XDM, mettez /etc/X11/xdm/Xservers
à :
:0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Si vous
utilisez Gdm, assurez-vous que l'option -nolisten tcp est
positionnée dans /etc/gdm/gdm.conf
(qui est par défaut dans
Debian) ainsi :
[server-Standard] name=Standard Server command=/usr/bin/X11/X -nolisten tcp
Vous pouvez également positionner l'expiration de délai système par défaut pour
les blocages xscreensaver
. Même si l'utilisateur peut annuler
cela, vous devriez éditer le fichier de configuration
/etc/X11/app-defaults/XScreenSaver
et changer la ligne de
blocage :
*lock: False
(qui est par défaut dans Debian) à :
*lock: True
FIXME: ajouter des informations sur comment désactiver les économiseurs d'écran qui affichent l'écran de l'utilisateur (qui peuvent avoir des informations sensibles).
Plus d'infos sur la sécurité X Window dans XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz
).
FIXME: Ajouter des informations d'une discussion de debian-security pour avoir les modifications des fichiers de configuration de XFree 3.3.6 pour faire cela.
Si vous voulez seulement avoir un gestionnaire d'affichage installé pour une utilisation locale (en ayant un joli login graphique, c'est tout), assurez-vous que le XDMCP (X Display Manager Control Protocol) est désactivé. Dans XDM, vous pouvez faire cela avec cette ligne dans /etc/X11/xdm/xdm-config :
DisplayManager.requestPort: 0
Normalement, tous les gestionnaires d'affichages sont configurés par défaut pour ne pas démarrer les services XDMCP dans la Debian.
Imaginez, vous arrivez au travail et l'imprimante crache une quantité infinie de papier car quelqu'un est en train de provoquer un déni de service sur votre démon d'impression. Méchant, n'est ce pas?
Dans toute architecture d'impression Unix, il y a un moyen de fournir les
données du client vers le serveur d'impression de l'hôte. Dans les
traditionnels lpr
et lp
, la commande du client copie
ou crée un lien symbolique pour les données dans le répertoire de spool (c'est
pour cela que ces programmes sont habitullement SUID ou SGID).
Pour éviter tout problème, vous devriez garder vos serveurs d'impression
particulièrement sûrs. Cela veut dire qu'il est nécessaire de configurer votre
service d'impression pour qu'il autorise seulement les connexions d'un ensemble
de serveurs de confiance. Pour ce faire, ajoutez les serveurs auxquels vous
voulez autoriser l'impression à votre /etc/hosts.lpd
.
Cependant, même si vous faites cela, le démon lpr
accepte les
connexions entrantes sur le port 515 de n'importe quelle interface. Vous
devriez réfléchir au filtrage par un pare-feu des connexions provenant de
réseaux/hôtes qui ne sont pas autorisés à imprimer (le démon lpr
ne peut être limité pour écouter seulement sur une adresse IP donnée).
Lprng
doit être préféré à lpr
car il peut être
configuré pour faire du contrôle d'accès basé sur l'adresse IP. Vous pouvez
spécifier l'interface sur laquelle se lier (cependant d'une manière un peu
bizarre)
Si vous utilisez une imprimante sur votre système, mais seulement localement,
vous ne voulez pas partager ce service sur le réseau. Vous pouvez considérer
l'utilisation d'autres systèmes d'impression, comme celui fournit par
cups
ou PDQ
qui est basé sur les permissions utilisateurs du périphérique
/dev/lp0
.
Dans cups
, les données d'impression sont transférées vers le
serveur via le protocole HTTP. Ceci veut dire que le programme client n'a pas
besoin de privilèges spéciaux, mais cela nécessite que le serveur écoute sur un
port quelque part.
Cependant, si vous voulez utiliser cups
, mais seulement
localement, vous pouvez le configurer pour se lier à l'interface de bouclage
(loopback) en modifiant /etc/cups/cupsd.conf
:
Listen 127.0.0.1:631
Il y a plusieurs autres options de sécurité comme autoriser ou interdire des
réseaux et hôtes dans le fichier de configuration. Cependant, si vous n'en
avez pas besoin, il peut être préférable de simplement limiter le port
d'écoute. Cups
fournit également la documentation par le port
HTTP, si vous ne voulez pas dévoiler des informations potentiellement utiles
aux attaquants extérieurs (et que le port est ouvert), ajoutez également :
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 </Locationi>
Ce fichier de configuration peut être modifié pour ajouter plus de
fonctionnalités y compris des certificats SSL/TLS et du cryptage. Les manuels
sont disponibles sur http://localhost:631/ ou à cups.org
.
FIXME: Ajouter plus de contenu (l'article sur Amateur Fortress Building
fournit
certains points de vues très intéressants).
FIXME: Vérifier la disponibilité de PDG dans la Debian, et s'il l'est, le suggérer comme le système d'impression préféré.
FIXME: Vérifier si Farmer/Wietse a une alternative pour le démon d'imprimante et si il est disponible dans la Debian.
Si votre serveur n'est pas un système d'envoi de mail, vous n'avez pas réellement besoin d'un démon mail écoutant les connexions entrantes, mais vous pourriez vouloir que votre courrier local soit distribué pour, par exemple, recevoir le courrier pour l'utilisateur root en provenance d'un des systèmes d'alerte en place.
Si vous avez exim
, vous n'avez pas besoin que le démon tourne pour
le faire car la tâche standard cron
vide la file des messages.
Voir Désactivation de services démon,
Section 3.6.1 sur comment faire cela.
Vous pouvez vouloir avoir un démon local de courrier pour qu'il puisse relayer les courriers envoyés localement à un autre système. Ceci est courant quand vous avez à administrer un certain nombre de systèmes et que vous ne voulez pas vous connecter à chacun d'entre eux pour lire le courrier envoyé localement. Tout comme logguer tout sur chaque système individuel peut être centralisé en utilisant un serveur syslog central, les courriers peuvent être envoyés à un serveur de courriers central.
Un tel système relai-seulement devrait être configuré correctement pour cela. Le démon pourrait également être configuré pour n'écouter que sur l'adresse de bouclage.
Pour faire cela dans un système Debian, vous aurez à retirer le démon smtp d'inetd :
$ update-inetd --disable smtp
et configurer le démon de courrier pour écouter seulement sur l'interface de
bouclage. Dans exim
(le MTA par défaut) vous pouvez faire ça en
éditant le fichier /etc/exim.conf
et en ajoutant la ligne
suivante :
local_interfaces = "127.0.0.1"
Redémarrez les deux démons (inetd et exim) et vous aurez exim qui écoutera sur la socket 127.0.0.1:25 uniquement. Faites attention, et avant tout désactivez inetd, sinon exim ne démarrera pas étant donné que le démon inetd est déjà en attente de connexions entrantes.
Pour postfix
éditez /etc/postfix/main.conf
:
inet_interfaces = localhost
Si vous voulez seulement le courrier local, cette approche est meilleure que
l'encapsulation du démon mail par un tcp wrapper ou l'ajout de règles pare-feu
pour limiter les personnes qui y accèdent. Cependant, si vous n'avez pas
besoin d'écouter sur d'autres interfaces, vous pourriez envisager de le lancer
à partir d'inetd et ajouter un tcp wrapper pour que les connexions entrantes
soit vérifiées par rapport à /etc/hosts.allow
et
/etc/hosts.deny
. De plus, vous serez au courant quand un accès
non autorisé est tenté contre votre démon de courrier, si vous mettez en place
correctement le logging pour n'importe laquelle des méthodes décrites plus
haut.
En tout cas, pour rejeter les tentatives de relai de courrier au niveau SMTP,
vous pouvez changer /etc/exim/exim.conf
pour inclure :
receiver_verify = true
Même si votre serveur de courrier ne relaiera pas le message, ce genre de
configuration est nécessaire au testeur de relai à http://www.abuse.net/relay.html
pour déterminer que votre serveur ne peut pas faire de relai.
Si vous voulez une configuration relai-seulement, cependant, vous pouvez
vouloir changer le démon de courrier pour des programmes qui ne peuvent être
configurés que pour faire suivre le courrier à un serveur de courrier
distant. Debian fournit actuellement les paquets ssmtp
et
nullmailer
dans ce but. En tout cas, vous pouvez évaluer pour
vous-même l'un de ces deux agents de transport de courrier [19] fournis par Debian et voir
lequel correspond le mieux aux buts du système.
Si vous désirez donner un accès à distance aux boîtes à lettres, il y a un certain nombre de démons POP3 et IMAP disponibles [20] . Cependant, si vous fournissez un accès IMAP, notez qu'il s'agit d'un protocole générique d'accès aux fichiers, il peut devenir l'équivalent d'un accès shell car les utilisateurs peuvent être capable de récupérer tout fichier par celui-ci.
Essayez, par exemple, de configurer comme chemin de votre boîte de réception {server.com}/etc/passwd, si cela réussit, votre démon IMAP n'est pas configuré correctement pour empêcher ce genre d'accès.
Parmi les serveurs IMAP dans Debian, le serveur cyrus
(dans le
paquet cyrus-imapd
) contourne cela en ayant tous les accès sur une
base de données dans une partie restreinte du système de fichiers. Également,
uw-imapd
(installez soit uw-imapd
ou mieux, si votre
client IMAP le supporte, uw-imapd-ssl
) peut être configuré pour
« chrooter » les répertoires de courrier des utilisateurs, mais ceci
n'est pas activé par défaut. La documentation fournie donne plus
d'informations sur la façon de le configurer.
Vous pouvez également vouloir faire fonctionner un serveur IMAP qui n'ait pas
besoin que des utilisateurs valides soient créés sur le système local (ce qui
donnerait également un accès shell), les paquets courier-imap
(pour IMAP), courier-pop
teapop
(pour POP3) et
cyrus-imapd
(pour POP3 et IMAP) fournissent des serveurs avec des
méthodes d'authentification en plus des comptes utilisateur locaux.
cyrus
peut utiliser toute méthode d'authentification qui peut être
configurée par PAM tandis que teapop
peut utiliser des bases de
données (comme postgresql
et mysql
) pour
l'authentification des utilisateurs.
FIXME: Vérifier: uw-imapd
peut être configuré avec
l'authentification utilisateur grâce à PAM également...
La lecture/réception du courrier est le plus courant des protocoles en texte
clair. Si vous utilisez soit POP3 ou IMAP pour récupérer votre courrier, vous
envoyez votre mot de passe en clair à travers le réseau, et donc presque tout
le monde peut lire votre courrier à partir de maintenant. À la place, utilisez
SSL (Secure Sockets Layer) pour recevoir votre courrier. L'autre alternative
est ssh, si vous avez un compte shell sur la machine qui sert de serveur POP ou
IMAP. Voici un fetchmailrc
simple décrivant cela :
poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 </dev/null > /dev/null'
Le preconnect est la ligne importante. Il lance une session ssh et crée le tunnel nécessaire, qui relaie automatiquement les connections au port local 1236 vers le port IMAP du serveur de mail, mais cryptées. Une autre possibilité serait d'utiliser fetchmail avec la fonctionnalité ssl.
si vous désirez fournir des services de courrier comme POP et IMAP cryptés, apt-get install stunnel et démarrez vos démons ainsi :
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
Cette commande encapsule le démon fourni (-l) au port (-d) et utilise le certificat ssl spécifié (-p).
Il y a différents problèmes qui peuvent être traités pour sécuriser le démon de serveur de domaine; problèmes similaires à ceux étudiés quand on sécurise n'importe quel service donné :
Vous devriez restreindre certaines informations données par le serveur DNS aux
clients extérieurs pour qu'il ne puisse pas être utilisé pour obtenir des
informations de valeur sur votre organisation que vous ne voudriez pas
divulguer. Cela inclut l'ajout des options suivantes :
allow-transfer, allow-query, allow-recursive et
version. Vous pouvez soit limiter cela dans la section globale (pour
que cela s'applique à toutes les zones servies) ou individuellement par zone.
Cette information est documentée dans le paquet bind-doc
, lisez en
plus à ce sujet dans /usr/share/doc/bind/html/index.html
une fois
que le paquet est installé.
Imaginez que votre serveur (un serveur avec plusieurs adresses de base) est
connecté à Internet et à votre réseau interne (votre adresse IP interne est
192.168.1.2), vous ne voulez fournir aucun service à Internet et vous voulez
juste autoriser les consultations DNS à partir de vos hôtes internes. Vous
pourriez le restreindre en incluant dans /etc/bind/named.conf
:
options { allow-query { 192.168.1/24; } ; allow-transfer { none; } ; allow-recursive { 192.168.1/24; } ; listen-on { 192.168.1.2; } ; forward { only; } ; forwarders { A.B.C.D; } ; };
L'option listen-on lie uniquement le DNS à l'interface ayant une adresse interne, mais, même si cette interface est la même que l'interface qui permet la connexion à l'Internet (par l'utilisation de NAT, par exemple), les requêtes ne seront acceptées que si celles-ci proviennent d'hôtes internes. Si le système est constitué de plusieurs interfaces et que le listen-on n'est pas présent, seuls les utilisateurs internes pourront émettre des requêtes, mais, puisque le port restera accessible à des attaquants externes, ils pourront essayer de faire tomber (ou tenter une attaque d'exploit de débordement de tampon) le serveur DNS. Vous pouvez même le mettre uniquement en écoute sur l'adresse 127.0.0.1 si vous ne désirez pas offrir le service à quelqu'un d'autre qu'à vous même.
L'enregistrement version.bind dans la classe chaos contient la version du processus bind actuellement en cours d'exécution. Cette information est souvent utilisée par des scanners automatisés et des individus malveillants qui souhaitent déterminer si un bind est vulnérable à une attaque spécifique. En fournissant des informations fausses ou pas d'informations du tout, on limite la probabilité qu'un serveur soit attaqué sur la base de la version qu'il publie. Pour fournir votre propre version, utilisez la directive version de la manière suivante :
options { ... diverses options ici ... version "Not available."; };
Changer l'enregistrement version.bind ne fournit pas actuellement de protection contre les attaques, mais ceci devrait être considéré comme une protection utile.
Un fichier de configuration named.conf
d'exemple pourrait être me
suivant :
acl internal { 127.0.0.1/32; // localhost 10.0.0.0/8; // interne aa.bb.cc.dd; // IP eth0 }; acl friendly { ee.ff.gg.hh; // DNS escalve aa.bb.cc.dd; // IP eth0 127.0.0.1/32; // localhost 10.0.0.0/8; // interne }; options { directory "/var/cache/bind"; allow-query { internal; }; allow-recursion { internal; }; allow-transfer { none; }; }; // À partir d'ici jusqu'à la zone mysite.bogus // est dans l'ensemble non modifié des valeurs par défaut Debian logging { category lame-servers { null; }; category cname { null; }; }; zone "." { type hint; file "/etc/bind/db.root"; }; zone "localhost" { type master; file "/etc/bind/db.local"; }; zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; }; zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; }; zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; }; // Zones ajoutées moi-même zone "mysite.bogus" { type master; file "/etc/bind/named.mysite"; allow-query { any; }; allow-transfer { friendly; }; };
Veuillez (s'il vous plait) vérifier le système de suivi des bogues (BTS),
spécifiquement Bug #94760
(regarding ACLs on zone transfers)
. Vous pouvez contribuer si vous
le désirez au rapport de bogue si vous pensez pouvoir ajouter des informations
utiles.
Concernant la limitation des privilèges de BIND vous devez être conscient que
si un utilisateur autre que root exécute BIND, alors BIND ne peut pas détecter
de nouvelles interfaces automatiquement, par exemple, quand vous insérez une
carte PCMCIA dans votre portable. Consultez le fichier README.Debian dans
votre répertoire de documentation named
(/usr/share/doc/bind/README.Debian
) pour plus d'information sur ce
problème. Il y a eu récemment de nombreux problèmes de sécurité concernant
BIND, donc le changement d'utilisateur est utile quand il est possible,
cependant si vous désirez le faire de façon automatique, vous pouvez essayer le
script fourni dans Sample script to change the
default Bind installation., Annexe E.
Pour démarrer BIND sous un autre utilisateur, tout d'abord créez un utilisateur et un groupe séparé (ce n'est pas une bonne idée d'utiliser nobody ou nogroup pour chaque service ne devant pas tourner en tant que root). Dans cette exemple, l'utilisateur et le groupe named seront utilisés. Vous pouvez faire cela en tapant :
addgroup named adduser --system --ingroup named named
Maintenant éditez, à l'aide de votre éditeur favori, /etc/init.d/bind et changez les lignes commençant par
start-stop-daemon --start
en
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
Pour éviter également d'exécuter quoi que ce soit en tant que root, changez la ligne reload en commentant :
reload) /usr/sbin/ndc reload
Et changez cela en
reload) $0 stop sleep 1 $0 start
Note : Selon votre version de Debian, vous pouvez devoir changer la ligne restart également. Ceci a été corrigé dans la version 1:8.3.1-2 du bind de Debian.
Tout ce dont vous avez besoin est de redémarrer bind à l'aide de « /etc/init.d/bind restart » puis rechercher dans votre syslog les deux entrées suivantes :
Sep 4 15:11:08 nexus named[13439]: group = named Sep 4 15:11:08 nexus named[13439]: user = named
Voilà ! Maintenant votre named ne s'exécute plus en tant que
root. Si vous voulez lire plus d'informations sur pourquoi BIND ne fonctionne
pas en tant qu'utilisateur non root sur les systèmes Debian, veuillez vérifier
le système de suivi des bogues concernant Bind, spécifiquement Bug #50013: bind should not run as
root
et Bug #132582:
Default install is potentially insecure
, Bug #53550
, Bug #128120
et Bug #128120
. Vous pouvez
contribuer à ces rapports de bogue si vous le désirez si vous pensez pouvoir
ajouter des informations utiles.
Pour atteindre une sécurité de BIND maximale, construisez maintenant une prison
chroot (voir Paranoïa généralisée du suid et du chroot,
Section 5.10) autour de votre démon. Il y a un moyen facile de faire
cela : l'option -t (voyez la page de manuel
named(8)
ou la page 100 de ladocumentation de
Bind 9 (PDF)
). Cela fera que Bind se chrootera lui-même dans le
répertoire donné sans que vous ayez besoin de configurer une prison chroot et
de vous inquiéter au sujet des librairies dynamiques. Les seuls fichiers qui
doivent être dans cette prison chroot :
dev/null etc/bind/ - doit contenir named.conf et toutes les zones du serveur. sbin/named-xfer - si vous faites du transfert de nom var/run/named/ - devrait contenir le pid et le cache du serveur de nom (s'il existe), ce répertoire doit être inscriptible par l'utilisateur named var/log/named - si vous configurez le log vers un fichier, doit être inscriptible par l'utilisateur named dev/log - syslogd devrait écouter ici si named est configuré pour loguer en l'utilisant
Pour que votre démon Bind fonctionne correctement il a besoin de permissions dans les fichiers named. C'est une tâche facile car les fichiers de configuration sont toujours dans /etc/named. Tenez compte qu'il nécessite seulement un accès en lecture seule aux fichiers de zone, à moins qu'il ne soit un serveur de nom secondaire ou serveur cache. Si c'est votre cas vous aurez à donner les permissions en lecture-écriture aux zones nécessaires (pour que les transferts de zone à partir du serveur primaire fonctionnent).
De plus, vous pouvez trouver plus d'informations concernant le chrootage de
Bind dans le Chroot-BIND-HOWTO
(au sujet de Bind 9) et Chroot-BIND8-HOWTO
(au sujet de Bind 8). Ces mêmes documents devraient être disponibles par
l'installation de doc-linux-text
(version texte) ou
doc-linux-html
(version html). Un autre document utile est
http://www.psionic.com/papers/dns/dns-linux
.
Si vous configurez une véritable prison chroot (i.e. pas juste l'option -t) pour Bind 8.2.3 dans la Debian (potato), assurez-vous qu'elle contient les fichiers suivants :
dev/log - syslogd devrait écouter ici dev/null etc/bind/named.conf etc/localtime etc/group - avec une seule ligne: "named:x:GID:" etc/ld.so.cache - généré avec ldconfig lib/ld-2.1.3.so lib/libc-2.1.3.so lib/ld-linux.so.2 - lié symboliquement à ld-2.1.3.so lib/libc.so.6 - lié symboliquement à libc-2.1.3.so sbin/ldconfig - pourra être effacé après la configuration du chroot sbin/named-xfer - si vous faites des transferts de nom var/run/
Et modifiez également syslogd
écoutant dans $CHROOT/dev/log pour
que le serveur de nom puisse écrire des entrées syslog dans le log du système
local.
Si vous voulez éviter des problèmes avec les bibliothèques dynamiques, vous
pouvez compiler bind statiquement. Vous pouvez utiliser apt-get
pour cela avec l'option source. Il peut même récupérer les
paquets dont vous avez besoin pour le compiler correctement. Il vous faidrait
faire quelque chose comme :
$ apt-get --download-only source bind build-dep bind $ cd bind-8.2.5-2 (éditer le Makefile.in pour que CFLAGS inclut l'option '-static' avant la définition @CFLAGS@ substituée par) $ dpkg-buildpackage -rfakeroot $ cd .. $ dpkg -i bind-8.2.5-2*deb
Après l'installation, vous devrez déplacer des fichiers dans la prison chroot
[21] vous pouvez conserver les
scrips init.d dans /etc/init.d
pour que le système
lance automatiquement le serveur de domaine, mais éditez les pour ajouter
--chroot /location_of_chroot dans les appels à
start-stop-daemon
dans ces scripts.
Pour plus d'informations sur la mise en place de chroots, consultez Paranoïa généralisée du suid et du chroot, Section 5.10.
FIXME, inclure les informations provenant de http://people.debian.org/~pzn/howto/chroot-bind.sh.txt
,
http://people.pdxlinux.org/~karlheg/
(Bind9 sur Debian), http://www.cryptio.net/~ferlatte/config/
(spécifique Debian), http://www.psionic.com/papers/whitep01.html
,
http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm
et http://www.acmebw.com/papers/securing.pdf
.
FIXME. Ajout de contenu : modules fournis par l'installation normale d'Apache (sous /usr/lib/apache/X.X/mod_*) et modules qui peuvent être installés séparément dans les paquets libapache-mod-XXX.
Vous pouvez limiter l'accès au serveur Apache si vous voulez uniquement
l'utiliser en interne (dans un but d'essai, pour accéder à l'archive
doc-central
, etc.) et si vous ne voulez pas que des intrus y
accèdent. Pour réaliser cela, utilisez les directives Listen ou
BindAddress dans /etc/apache/http.conf
.
En utilisant Listen :
Listen 127.0.0.1:80
En utilisant BindAddress :
BindAddress 127.0.0.1
Ensuite, redémarrez apache avec /etc/init.d/apache restart et vous observerez qu'il écoute uniquement l'interface loopback.
Dans tous les cas, si vous n'utilisez pas toutes les fonctionnalités fournies
par Apache, vous pouvez jeter un œil aux autres serveurs web fournis dans
Debian tel dhttpd
.
La Documentation
Apache
fournit des informations concernant les mesures de sécurité à
prendre pour les serveurs web Apache (ces mêmes informations sont fournies dans
Debian par le paquet apache-doc
). Il peut également être utile de
lire la Documentation
de configuration de sécurité Apache
fournie par InterSect Alliance
.
Plus d'informations sur des restrictions supplémentaires d'Apache en mettant en
place une prison chrooté dans Chroot
environment for
Apache
, Annexe J.
L'installation par défaut d'Apache dans Debian permet aux utilisateurs de
publier du contenu dans leur répertoire $HOME/public_html
. Ce
contenu peut être récupéré à distance en utilisant une URL comme :
http://your_apache_server/~user.
Si vous ne voulez pas permettre cela, vous devez changer le fichier de
configuration /etc/apache/http.conf
en commentant :
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
Mais, si le module a été lié statiquement (vous pouvez vérifier cela en exécutant apache -l), vous devez ajouter la ligne suivante à la place :
Userdir disabled
Remarque : Le mot-clé disabled n'est disponible que dans Apache 1.3 et supérieur. Si vous utilisez d'anciennes versions d'Apache, vous devez changer le fichier de configuration et ajouter :
<Directory /home/*/public_html> AllowOverride None Order deny,allow Deny from all </Directory>
Un attaquant peut encore faire de l'énumération d'utilisateur, car la réponse du serveur web sera un 403 Permission Denied et non un 404 Not available.
Les fichiers de log d'Apache, depuis la version 1.3.22-1, ont pour propriétaire l'utilisateur « root » et pour groupe « adm » avec les permissions 640, ces permissions sont changées après la rotation. Un intrus qui peut accéder au système par le serveur web ne pourra pas (sans escalade de privilège) enlever d'anciennes entrées de fichiers de log.
Les fichiers d'Apache sont situés sous /var/www
. Juste après
l'installation, le fichier par défaut fournit quelques informations sur le
système (principalement qu'il s'agit d'un système Debian exécutant Apache).
Les pages web par défaut appartiennent à l'utilisateur root et au groupe root
par défaut alors que le processus Apache s'exécutent avec l'utilisateur
www-data et le groupe www-data. Ceci devrait plus difficile aux attaquants qui
compromettent le système par le site web de défigurer le site. Vous devriez,
bien sûr, remplacer les pages web par défaut (qui peuvent fournir des
informations que vous ne voulez pas donner aux visiteurs) avec les vôtres.
Si vous désirez utiliser le service finger, demandez-vous si vous en avez
réellement besoin. Si oui, vous découvrirez que Debian fournit de nombreux
démons finger (sortie d'un apt-cache search fingerd
):
ffingerd
est le démon finger recommandé si vous comptez l'utiliser
pour un service public. Dans tous les cas, vous êtes encouragé, lors de la
mise en place via inetd, xinetd ou tcpserver à : limiter le nombre de
processus qui seront lancés en même temps, limiter les accès au démon finger
depuis un nombre donné d'hôtes (en utilisant tcp wrappers) et de l'avoir en
écoute uniquement sur une interface bien définie.
chroot
est l'une des plus puissantes possibilités pour restreindre
un démon, un utilisateur ou un autre service. Imaginez simplement une prison
autour de votre cible, de laquelle votre cible ne peut s'échapper (normalement,
mais il y a encore beaucoup de conditions qui peuvent permettre de s'échapper
d'une telle prison). Si vous ne fait pas confiance à l'utilisateur ou au
servuce, vous pouvez créer un environnement de changement de racine
(« root ») pour lui. Ceci peut utiliser pas mal d'espace disque car
vous devez copier tous les exécutables nécessaires, ainsi que des
bibliothèques, dans la prison. Même si l'utilisateur fait quelque chose de
malfaisant, l'étendu des dommage est limitée à la prison.
Un grand nombre de services fonctionnant comme démons pourraient bénéficier de ce type d'arrangement. Les démons que vous installez dans votre distribution Debian ne seront cependant pas fournis chrootés[22] par défaut.
Ceci inclut : serveurs de domaines (comme bind
), serveurs web
(comme apache
), serveurs de courrier (comme sendmail
)
et serveurs ftp (comme wu-ftpd
). Il est probablement juste de
dire que la complexité de BIND est la raison pour laquelle il a été exposé à de
nombreuses attaques ces dernières années (voir Sécurisation de BIND, Section 5.7).
Cependant, Debian fournit des logiciels qui peuvent vous aider à mettre en
place des environnements chroot
. Voir Créer des environnements chrooté automatiquement, Section
5.10.1.
De toute façon, si vous exécutez un quelconque service sur votre système, vous devriez considérer de le faire fonctionner de la façon la plus sécurisée possible. Ceci inclut : révoquer les privilèges root, le faire fonctionner dans un environnement restreint (comme un prison chroot) ou le remplacer par un équivalent plus sécurisé.
Cependant, soyez prévenu qu'une prison chroot
peut être cassée si
l'utilisateur fonctionnant dedans est le super-utilisateur. Vous devez donc
faire fonctionner le service avec un utilisateur non privilégié. En limitant
son environnement, vous limitez les fichiers lisibles et exécutables par tout
le monde que le service peut accéder, vous limitez donc aussi les possibilités
d'une escalade de privilège par l'utilisation de failles de sécurité du système
local. Même dans une situation où vous ne pouvez pas être complèrement certain
qu'il n'y a pas de moyen pour un attaquant intelligent de sortir de la prison
d'une manière ou d'une autre. Utiliser seulement des programmes serveur ayant
une réputation de sécurité est une bonne mesure de sécurité additionnelle.
Même des trous minuscules comme des descripteurs de fichier peuvent être
utilisés par un attaquant doué pour s'introduire dans le système. Après tout,
chroot
n'a pas été conçu pour être un outil de sécurité, mais un
outil de test.
Il existe plusieurs programmes pour chrooter automatiquement des serveurs et
services. Debian fournit actuellement (accepté en mai 2002)
chrootuid
de Wietse Venema dans le paquet chrootuid
,
ainsi que compartment
et makejail
. Ces programmes
peuvent être utilisés pour mettre en place un environnement restreint pour
exécuter tout programme (chrootuid
vous permet même de l'exécuter
avec un utilisateur restreint).
Certains de ces outils peuvent être utilisés pour mettre en place
l'environnement chrooté facilement. Le programme makejail
, par
exemple, peut créer et mettre à jour une prison chroot avec de petits fichiers
de configuration (il fournit des fichiers de configuration exemple pour
bind
, apache
, postgresql
et
mysql
). Il tente de deviner et d'installer dans la prison tous
les fichiers nécessaires requis par le démon en utilisant strace
,
stat
et les dépendances du paquet Debian. Plus d'informations à
http://www.floc.net/makejail/
.
Jailer
est un outil semblable qui peut être récupéré depuis
http://www.balabit.hu/downloads/jailer/
.
FIXME: j'ai des paquets prêts pour jailer, mettre à jour ceci quand ils seront acceptés.
deb.pl
, un script qui analyse les dépendances d'un jeu de
fichiers, est également utile pour créer des chroots (ou prisons).
Vous devriez essayer d'éviter tout service réseau qui envoie et reçoit des mots de passe en texte clair par le net comme FTP/Telnet/NIS/RPC. L'auteur recommande l'utilisation de ssh à la place de telnet et ftp pour tout le monde.
Gardez à l'esprit que la migration de telnet vers ssh, en conservant l'utilisation d'autres protocoles à texte non chiffrés n'augmente votre sécurité en AUCUNE manière ! Le mieux serait de retirer ftp, telnet, pop, imap, http et de les remplacer par leurs services cryptés respectifs. Vous devriez considérer la migration de ces services vers leurs versions SSL, ftp-ssl, telnet-ssl, pop-ssl, https, etc.
La plupart des astuces ci-dessus s'appliquent à tout système Unix (vous les trouverez dans des documents de durcissement liés à Linux et autres Unix).
Vous ne devriez pas utiliser NIS, le Service d'Information Réseau (Network Information Service), si possible car il autorise le partage de mot de passe. Ceci peut être fortement dangereux si votre installation est cassée.
Si vous avez besoin de partager les mots de passe entre machines, pensez à
d'autres alternatives. Par exemple, mettre en place un serveur LDAP et
configurer PAM sur votre système afin de contacter le serveur LDAP pour
l'authentification des utilisateurs. Une installation détaillée est disponible
dans le LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz
).
Informations supplémentaires sur la sécurité de NIS à l'adresse suivante
NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz
).
FIXME (jfs) : Ajouter des infos sur comment configurer cela dans la Debian
Vous devriez désactiver RPC quand c'est possible, c'est à dire, quand vous n'en
avez pas besoin. [23] De
nombreuses failles de sécurité pour ce service sont connues et peuvent être
facilement exploitées. D'un autre côté les services NFS sont assez importants
dans certains réseaux, trouvez donc le juste équilibre entre sécurité et
facilité d'utilisation sur votre réseau. Certaines attaques DDos (Distributed
Denial of Service ou déni de service distribué) utilisent des exploits rpc pour
s'introduire dans le système et y agir comme agent/gestionnaire. Lisez en plus
sur la sécurité de NFS dans le NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
).
La désactivation de portmap est assez simple. Il y a différentes méthodes. La
plus simple sur un système Debian 3.0 est de désinstaller le paquet
portmap
. Si vous exécutez une autre version vous devrez
désactiver le service comme expliqué dans Désactivation de services démon, Section
3.6.1, cela est dû au fait que le programme fait partie du paquetage
net-base
(qui ne peut être désinstallé sans endommager le
système).
Cela enlève en fait tous les liens symboliques relatifs à portmap dans
/etc/rc${runlevel}.d/, qui est aussi quelque chose que vous
pourriez faire manuellement. Une autre possibilité est de faire chmod
644 /etc/init.d/portmap, mais cela produit un message d'erreur lors du
démarrage. Vous pouvez aussi enlever la partie start-stop-daemon
du script shell /etc/init.d/portmap
.
Le système d'exploitation Debian GNU/Linux possède les capacités intégrées
fournies par le noyau Linux. Cela signifie que si vous installez un système
Potato (Debian version 2.2, le noyau par défaut est le 2.2) vous aurez la
fonctionnalité pare-feu ipchains
disponible dans le noyau, vous
avez à installer le paquetage ipchains
qui devrait déjà être
installé (de part sa priorité). Si vous installez un système Woody (Debian
version 3.0, le noyau par défaut est le 2.4) vous aurez la fonctionnalité
pare-feu iptables
(neftfilter) disponible. La principale
différence entre ipchains
et iptables
est que ce
dernier est basé sur une inspection des paquets en fonctione de l'état
(stateful packet inspection) qui fournit des configurations de filtrage plus
sécurisées (et plus faciles à construire).
Vous pouvez utiliser des règles de pare-feu comme façon de sécuriser l'accès à votre système local et, même, de limiter les connexions extérieures effectuées par celui-ci. Des règles de pare-feux peuvent être également utilisées pour protéger des processus qui ne peuvent être proprement configurés pour ne pas fournir certains services à certains réseaux, certaines adresses IP, etc.
Toutefois, cette étape est présentée en dernier dans ce manuel car il est beaucoup mieux de ne pas dépendre exclusivement des capacités d'un pare-feu de façon à protéger un système donné. La sécurité dans un système est faites de couches, le filtrage devrait être la dernière, une fois que tous les services ont été renforcés. Vous pouvez facilement imaginer une installation dans laquelle le système est uniquement protégé par le pare-feu et que l'administrateur enlève bêtement les règles pour n'importe quelle raison (problêmes avec l'installation, exaspération, erreur humaine, ...), ce système pourrait être grand ouvert à une attaque s'il n'y avait aucun autre renforcement dans le système pour le protéger.
D'un autre côté, avoir des règles de pare-feu sur le système local préviennent également quelques mauvaises choses de se produire. Même si les services fournis sont configurés avec sécurité, un pare-feu peut protéger des erreurs de configuration ou des services fraîchement installés qui n'ont pas encore été configurés correctement. Une configuration serrée préviendra également un cheval de Troie appelant à la maison de fonctionner sauf si le code de pare-feu est enlevé. Notez qu'un intrus n'a pas besoin de l'accès super-utilisateur pour installer un cheval de Troie qui pourrait être contrôlé à distance (car l'association sur des ports est autorisée si le port n'est pas privilégié et si des capacités n'ont pas été supprimées).
Une configuration correcte de pare-feu serait donc une rêgle de refus par défaut, c'est à dire :
Un pare-feu Debian peut aussi être installé de façon à protéger, selon des règles de filtrage, l'accès aux systèmes derrière lui, limitant leur exposition à Internet. Le pare-feu peut être configuré pour interdire aux systèmes en dehors de votre réseau local d'accéder à des services (ports) qui ne sont pas publics. Par exemple, sur un serveur de messagerie, seul le port 25 (où le service de courrier est fourni) doit être accessible depuis l'extérieur. Un pare-feu peut être configuré pour, même s'il y a d'autres services en plus des services publics, rejeter les paquets (ceci est connu sous le nom defiltrage) dirigés vers eux.
Vous pouvez même installer une machine Debian GNU/Linux en tant que pont pare-feux, c'est-à-dire un pare-feu filtrant complètement transparent pour le réseau qui est dépourvu d'adresse IP et donc ne peut pas être attaqué directement. Selon le noyau que vous avez installé, vous pouvez avoir besoin d'installer le correctif pare-feu pour pont, puis aller à 802.1d Ethernet Bridging lors de la configuration du noyau et une nouvelle option netfilter (firewalling) support. Voir Setting up a bridge firewall, Annexe D pour plus d'informations sur la façon de faire cela dans un système Debian GNU/Linux).
Bien sûr, la configuration du pare-feu dépend toujours du système et du résea.
Un administrateur doit connaître auparavant quelle est la disposition du
réseau, les systèmes qu'il désire protéger et si d'autres considérations réseau
(comme le NAT ou le routage) doivent être prises en compte ou non. Soyez
prudent quand vous configurez votre pare-feu, comme le dit Laurence J. Lane
dans son paquet iptables
:
Les outils peuvent facilement être mal utilisés, entraînant d'énormes quantités de maux en paralysant complètement l'accès au réseau pour un système d'ordinateur. Il n'est pas très inhabituel pour un administrateur système de se bloquer lui-même en dehors du système situé à quelques centaines ou milliers de kilomètres de là. Il est même possible de se bloquer en dehors d'un ordinateur dont le clavier est sous ses doigts. Veuillez s'il vous plait l'utiliser avec précaution.
Rappelez-vous de cela : installer simplement le paquet
iptables
(ou l'ancien code de pare-feu) ne vous fournit pas de
protection, mais seulement les logiciels. Pour avoir un pare-feu, vous devez
le configurer !
Si vous n'en connaissez pas beaucoup sur les pare-feu, lisez le
Firewalling-HOWTO qui se trouve dans le paquet doc-linux-text
(d'autres formats du document sont également disponibles). Consultez Être conscient des problèmes de sécurité,
Section 2.2 pour plus de pointeurs (généraux).
Si vous utilisez Debian 3.0, vous remarquerez que le paquet
iptables
est déjà installé. Il s'agit du support pour
l'implémentation de netfilter des noyaux 2.4.4 et plus. Comme, juste après
l'installation, le système ne peut pas connaître de règles de pare-feu
(toute règle de pare-feu est trop dépendante du système), vous devez activer
iptables. Cependant, les scripts ont été configurés pour que l'administrateur
puisse configurer des règles de pare-feu, puis que les scripts d'initialisation
les apprennent et les utilisent toujours pour la configuration du
pare-feu.
Pour faire cela, vous devez :
/etc/default/iptables
pour que
la variable enable_iptables_initd soit positionnée à
true.
iptables(8)
) ou certains des outils
fournis par les paquets de pare-feu de Debian (voir Paquets pare-feu, Section 5.14.3.2). Vous devez
créer un jeu de règles de pare-feu à utiliser quand le pare-feu est dans l'état
actif et un autre à utiliser quand le pare-feu est dans l'état
inactif (celles-ci peuvent être simplement des règles vides).
Une fois que ceci est fait, votre configuration de pare-feu est sauvée dans le
répertoire /var/lib/iptables/
et elle sera exécutée lors de
l'amorçage du système (ou lors de l'exécution du script d'initd avec les
paramètres start et stop). Veuillez noter que les
configurations Debian par défaut lance le code de pare-feu dans les niveaux
d'exécution multi-utilisateurs (2 à 5) assez tôt (10). Il est stoppé dans le
mode utilisateur seul (1), changez cela si cela ne correspond pas à vos règles
locales.
Si vous n'avez aucune idée comment configurer vos règles de pare-feu, consultez
manuellement le Packet Filtering HOWTO et le NAT HOWTO
fournis dans le paquet iptables
pour consultation hors-ligne dans
/usr/share/doc/iptables/html/
. Le fichier de configuration
/etc/default/iptables
fournit également plusieurs informations
concernant les problèmes relatifs à ce paquet.
Configurer manuellement un pare-feu peut être compliqué pour un administrateur débutant (et même parfois pour un expert). Cependant, la communauté des logiciels libres a créé un certain nombre d'outils pouvant être utilisés pour configurer facilement un pare-feu local. Soyez prévenu que certains de ces outils sont plus orientés vers de la protection locale seulement (également connu sous le nom de pare-feu personnel) et d'autres sont plus versatiles et peuvent être utilisés pour configurer des rêgles complexes pour protéger des réseaux entiers.
Il existe plusieurs logiciels qui peuvent être utilisés pour configurer des règles de pare-feu dans un système Debian :
firestarter
, orienté vers les utilisateurs finaux et incluant un
wizard (?) pour définir rapidement des règles de pare-feu,
knetfilter
,
fwbuilder
, une interface graphique orientée objet qui inclut des
compilateurs de règles pour diverses plates-formes de pare-feu incluant
iptables ainsi que des listes d'accès du routeur,
shorewall
qui fournit un support pour IPsec ainsi qu'un support
limité pour le dimensionnement du traffic (traffic shaping) et la définition
des règles du pare-feu,
mason
, qui peut suggérer des règles de pare-feu basées sur le
traffic réseau que votre réseau « voit ».
bastille
(parmi les étapes de durcissement qui constituent les
nouvelles versions de bastille, l'une d'entre elles est l'ajout de règles de
pare-feu exécutables au démarrage du système),
ferm
,
fwctl
,
easyfw
,
firewall-easy
,
ipac-ng
,
gfcc
,
lokkit
ou gnome-lokkit
.
Les derniers paquets : gfcc, firestarter et knetfilter sont des interfaces graphiques pour l'administration qui utilisent soit GNOME (les deux premiers) soit KDE (le dernier) qui sont plus orientées utilisateur (c'est-à-dire utilisation « familiale ») tandis que les autres paquets de la liste sont plus orientés administrateur.
Soyez prévenu que certains de ces paquets cités ci-dessus introduiront probablement des scripts de pare-feu à exécuter lors de l'amorçage du système, ce qui entrera certainement en conflit avec la configuration standard (si elle est configurée) et peut apporter des effets indésirables. Habituellement, le script de pare-feu qui s'exécute en dernier sera celui qui configurera le système (qui peut ne pas être ce que vous prétendez). Consultez la documentation du paquet et utilisez l'un d'entre eux pour ces configurations. Habituellement, les autres programmes qui vous aident à configurer les règles du pare-feu peuvent modifier d'autres fichiers de configuration.
FIXME: Ajouter plus d'informations concernant ces paquets
FIXME: Vérifier les informations sur les pare-feu Debian et quoi/comment cela change par rapport aux autres distributions.
FIXME: À quel endroit la personnalisation du pare-feu peut-elle être activée (FAQ générale dans debian-firewall ?)
FIXME: Ajouter des informations sur Zorp
dans Debian
(voir Bug #88347
. Des
paquets Debian sont fournis, mais ils dépendent de libglib1.3 qui n'est pas
encore disponible dans Debian.
Manuel de sécurisation de Debian
2.95 5 marzo 2004Vendredi 4 juillet 2003 23:13:42 +0100jfs@computer.org