[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ suivant ]

Securing Debian Manual
Chapitre 5 - Sécuriser les services de votre système


Les services présents sur un système peuvent être sécurisés de deux façons :

Restreindre les services ainsi ils ne seront accessibles que depuis un endroit bien spécifique. Ces restrictions peuvent-être faites 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 à utiliser qu'une interface.

Concernant les services lancés par inetd (telnet, ftp, finger, pop3...) il est à noter que inetd ne peut pas être configuré afin que des services écoutent uniquement sur une interface précise. Toutefois, le programme xinetd substitue cela par l'inclusion d'un raccourci pour parer ce cas. 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.


5.1 Sécurisation de ssh

Si vous utilisez toujours telnet au lieu de ssh, vous devriez prendre une pause dans la lecture de ce manuel pour remedier à cela. Ssh devrait être utilisé pour toutes les connexions distantes à la place de telnet. A une époque où il est facile de renifler 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 encore mieux, 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 ainsi être modifié pour accroître la sécurité :

Pour finir, soyez conscient que ces directives proviennent d'un fichier de configuration OpenSSH. Actuellement, il y a 3 daemons ssh couramment utilisés, ssh1, ssh2, et OpenSSH par les gens d'OpenBSD. Ssh1 était le premier daemon ssh disponible et est toujours le plus couramment utilisé (il y a des rumeurs qu'il y aurait même un portage windows). Ssh2 a beaucoup d'avantages par rapport à ssh1 excepté qu'il est diffusé sous une licence non-libre. OpenSSH est un daemon ssh complètement libre, qui supporte à la fois ssh1 et ssh2. OpenSSH est la version installée sur la 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é.


5.2 Sécurisation de Squid

Squid est l'un des plus populaires serveurs proxy/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. Vous devriez configurer Squid pour permettre aux utilisateurs, hôtes ou réseaux de confiance une Liste de Contrôle d'Accès (ACL) sur /etc/squid.conf. Voir le Guide d'utilisateur Squid pour plus d'informations à propos des règles ACL.

De même, si 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 désignés 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 la woody (Debian 3.0):

FIXME: Ajouter de plus amples informations sur la sécurité sur Squid Accelerator Mode


5.3 Sécurisation FTP

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 home de l'utilisateur, ainsi l'utilisateur est incapable de voir autre chose que ses propres répertoires. Autrement, il peut 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 home.

Pour prévenir Proftpd d'attaques Dos avec l'utilisation de ../../.., ajouter la ligne suivante dans /etc/proftpd.conf: DenyFilter \*.*/

Rappelez-vous toujours que le FTP envoi 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.


5.4 Sécurisation de l'accès à X Window System

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 fichier à 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 docs, 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 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. Ceci doit être activé dans /etc/ssh/ssh_config en paramétrant X11Forwarding à yes. A l'heure de SSH, vous devriez abandonner complètement le contrôle d'accès basé dur 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.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é) 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, mettre /etc/X11/xdm/Xservers à : :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp

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 sur debian-security pour avoir le cheminement de configuration des fichiers de XFree 3.3.6.


5.4.1 Vérifiez votre gestionnaire d'affichage

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


5.5 Sécurisation de l'accès à l'impression (Le problème lpd et lprng)

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 daemon d'impression. Méchant, n'est ce pas? Donc, gardez 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 daemon lpr accepte les connexions entrantes sur le port 515 de n'importe quelle interface. Vous devriez réfléchir au filtrage par un pare-feux des connexions provenant de réseaux/hôtes qui ne sont pas autorisés à imprimer (le daemon 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'IP. Vous pouvez spécifier l'interface sur laquelle on se lie (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.

De plus, cups peut être configuré pour se lier à l'interface de bouclage (loopback) en modifiant /etc/cups/cupsd.conf:

     Listen 127.0.0.1:631

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 si 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 daemon d'imprimante et si il est disponible dans la Debian.


5.6 Sécurisation du daemon mail

Si votre serveur n'est pas un système d'envoi de mail, vous n'avez pas réellement besoin d'un daemon mail écoutant les connexions entrantes, mais vous pourriez vouloir votre courrier local distribué pour, par exemple, recevoir le courrier pour l'utilisateur root en provenance d'un des systèmes d'alerte en place.

Pour faire cela dans un système Debian, vous aurez à retirer le daemon smtp d'inetd:

     $ update-inetd --disable smtp

et configurer le daemon de mail 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 daemons (inetd et exim) et vous aurez exim qui écoutera sur 127.0.0.1:25 uniquement. Faites attention, et avant tout désactivez inetd, sinon, exim ne démarrera pas étant donné que le daemon 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 daemon 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 daemon de mail, si vous mettez en place correctement le logging pour n'importe laquelle des méthodes décrites plus haut.


5.7 Réception du courrier d'une manière sûre.

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. A 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 pour décrire 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. Elle 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 daemons ainsi:

     stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd

Cette commande encapsule le daemon fourni (-l) au port (-d) et utilise le certificat ssl spécifié (-p).


5.8 Sécurisation de BIND

Il y a différents problèmes qui peuvent être traités pour sécuriser le daemon 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 inclus 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 paquetage bind-doc, lisez en plus à ce sujet dans /usr/share/doc/bind/html/index.html une fois que le paquetage est installé.

Imaginez que votre serveur (un serveur avec plusieurs adresses de base) est connecté à Internet et à votre réseau interne (votre 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 à 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 cracher (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 a 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 de fausses ou pas d'informations, 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.

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

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

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. Pour atteindre une sécurité de BIND maximale, construisez mantenant une prison chroot (voir Utilisation de chroot, Section 4.9) autour de votre daemon. Il y a un moyen facile de faire cela: l'option -t (voyez la page de manuel named(8)). 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 (si 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
     				  grace à lui

Pour que votre daemon 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 le transfert de zone à partir du serveur primaire marche).

Si vous voulez lire plus d'informations expliquant pourquoi BIND ne s'exécute pas en tant qu'utilisateur non-root sur les systèmes Debian, veuillez, s'il vous plaît, consulter le Bug Tracking System au sujet de Bind, spécifiquement Bug #50013: bind should not run as root.

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

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/

FIXME, inclure les infos provenant de http://www.cryptio.net/~ferlatte/config/ (spécifique à la Debian) et http://www.psionic.com/papers/whitep01.html.


5.9 Sécurisation d'Apache

FIXME. Ajout de contenu.

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 ne pas vouloir que des intrus y accèdent. Pour réaliser cela, utilisez les directives Listen ou BindAddress dans /etc/apache/http.conf.

Using Listen:

     Listen 127.0.0.1:80

Using 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 oeil aux autres serveurs web fourni 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).


5.10 Sécurisation de finger

Si vous désirez utiliser le service finger, demandez-vous si vous en avez réellement besoin. Si oui, vous découvrirez que Debian fourni de nombreux daemons finger (output d'un apt-cache search fingerd):

ffingerd est le daemon 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 daemon 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.


5.11 Paranoïa généralisée du suid et du chroot

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

D'autres programmes avec des fonctionnalités complexes et une large base d'utilisateurs incluent Sendmail et quelques daemon ftp (e.g. WUftpd). (Bien sûr un programme avec aucune fonctionnalité et pas de clients satisfaits peut être aussi peu sûr, outre le fait qu'il est inutile.)

Dans tous les cas, si vous exécutez un de ces programmes, considérez des mesures semblables à leur encontre — annuler les privilèges root, s'exécuter dans une prison chroot — ou les remplacer par des équivalents plus sûrs.


5.12 Paranoïa généralisée du mot de passe en texte clair

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 perpétuant 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 mise à jour de ces services à leurs versions SSL, ftp-ssl, telnet-ssl, pop-ssl, https...

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


5.13 Désactivation du NIS

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 l'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 sur 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


5.14 Désactivation des services RPC

Vous devriez désactiver RPC quand c'est possible. 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. La plupart des 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 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 paquetage portmap. Si vous exécutez une autre version vous devrez désactiver le service comme expliqué dans Désactivation de services daemon, Section 3.6.1, cela est dû au fait que le programme fait partie du paquetage net-base (qui ne peut être desinstallé sans endommager le système).

Cela enlève en fait tous les liens symboliques relatifs au 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.


5.15 Ajouter des capacités au pare-feu

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 sera sûrement déjà (de part sa priorité) installé. 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.

Certains utilisateurs peuvent aussi bien vouloir ajouter des règles de pare-feu dans ce script. Cependant, vérifiez quels programmes/composants pare-feu vous voulez utiliser puisqu'ils peuvent modifier d'autres fichiers et changer les définitions que vous avez ajouté au démarrage. Par exemple, firewalk>, pour n'en citer qu'un, utilisera un autre fichier de configuration pour configurer le pare-feu.


5.15.1 Règles de Iptables

Si vous utilisez Debian 3.0, vous noterez que vous disposez du paquet iptables. Ceci est le support pour l'implémentation de netfilter des noyaux 2.4.4+. Juste après l'installation, le système ne peut connaître les règles du pare-feu (celles-ci sont spécifiques à chaque système) et vous devez activer iptables.

De manière à réaliser ceci, vous devez :

Une fois ceci fait l'installation de votre pare-feu est sauvegardée dans le répertoire /var/lib/iptables/ et sera exécutée quand le système démarrera (ou lorsque le script initd sera lancé avec les arguments start et stop). Notez que l'installation par défaut de Debian démarre le pare-feu dans le niveau d'exécution multi-utilisateurs (2 à 5) bientôt (10). De plus, il est arrêté en mode mono-utilisateur (1), changez ceci si cela ne correspond pas à votre politique.

Soyez avertis que certains des paquetages passés en revue ci-dessous pourraient amener des scripts pare-feux à être exécuter quand le système démarre, cela va indubitablement entrer en conflit avec la configuration courante et vous pourriez avoir des effets indésirables. Consultez la documentation du paquetage et utilisez l'une de ces configurations.

Si vous n'avez aucun renseignement sur la manière d'organiser vos règles de filtrage pour votre pare-feu, consulter le Packet Filtering HOWTO fourni par iptables pour une consultation hors-ligne sous /usr/share/doc/iptables/html/.


5.15.2 Firewaller le système local

Vous pouvez utiliser des règles de pare-feu tel une manière de sécuriser l'accès à votre système local et, même, de limiter les connexions extérieures<--!outband a traduire--> produites par celles-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 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.


5.15.3 Utiliser un pare-feu pour protéger d'autres systèmes

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.

Vous pouvez même installer une bécane 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.

Si vous ne connaissez pas grand chose aux pare-feux, vous pouvez lire le Firewalling-HOWTO qui se trouve dans le paquet doc-linux-text (d'autres formats de document sont également disponibles). Voir Être conscient des problèmes de sécurité, Section 2.2 pour plus de pointeurs.


5.15.4 Paquets pare-feu

Il existe plusieurs logiciels qui peuvent être utilisés pour configurer des règles de pare-feux dans un système Debian :

Les derniers paquets : gfcc,firestarter et knetfilter sont des GUIs pour administration qui utilisent soit GNOME (le premier des deux) soit KDE (le dernier) qui sont plus orienté utilisateur (c'est-à-dire utilisation "familiale") tandis que les autres paquets de la liste sont plus orientés administrateur.

FIXME: Ajouter plus d'informations concernant ces paquets

FIXME: Vérifier les informations sur les pare-feux Debian et quoi/comment cela change sur les autres distributions.

FIXME: A quel endroit la personnalisation du pare-feu peut elle être activée (FAQ générale dans debian-firewall?)


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ suivant ]

Securing Debian Manual

2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100

Javier Fernández-Sanguino Peña jfs@computer.org