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

Manuel de sécurisation de Debian
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 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 peut être configuré pour que les services n'écoutent que sur une interface précise (en utilisant la syntaxe service@ip), mais c'est une fonctionnalité non documentée. L'un de ses remplaçants, le méta-démon xinetd, inclut une option bind 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.

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

Vous pouvez également restreindre l'accès au serveur ssh en utilisant pam_listfile ou pam_wheel dans le fichier de contrôle PAM. Par exemple, vous pourriez bloquer 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 paquet 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.1.1 Chrooter ssh

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 Environnement de chroot pour SSH, Annexe G, vous pouvez trouver plusieurs options pour créer des environnements chroot pour SSH.

5.1.2 Clients 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é).

5.1.3 Interdire les transferts de fichiers

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 :

5.2 Sécurisation de Squid

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/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/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 disponibles dans Debian 3.0 et les versions ultérieures :

Quand vous utilisez Squid 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.

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

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 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 XFreenb 4.1.0 (le serveur X fourni dans Debian 3.0 et 3.1). Si vous utilisez XFree 3.3.6 (vous avez donc Debian 2.2 d'installée), vous pouvez éditer /etc/X11/xinit/xserverrc 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 DisallowTCP=true est positionnée dans /etc/gdm/gdm.conf (qui est par défaut dans Debian). Cela va basiquement ajouter -nolisten tcp à chaque ligne de commande X [36].

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.

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 cela avec cette ligne dans /etc/X11/xdm/xdm-config : 

     DisplayManager.requestPort:     0

Pour GDM, il devrait y avoir dans votre fichier gdm.conf : 

     [xdmcp]
     Enable=false

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 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 habituellement 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
     </Location>

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.

5.6 Sécurisation du démon mail

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.

5.6.1 Configurer un Nullmailer

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

Les étapes de configuration suivantes ne doivent être suivies que si vous configurez le paquet exim dans la version 3.0 de Debian. Si vous utilisez une version ultérieure (comme la version 3.1 qui utilise exim4), le système d'installation a été amélioré afin que, si le MTA est configuré pour ne délivrer que des messages locaux, il ne va autoriser des connexions que depuis l'hôte local et interdire toute connexion distante.

Sur un système Debian 3.0 utilisant exim, vous devrez 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 [37] fournis par Debian et voir lequel correspond le mieux aux buts du système.

5.6.2 Fournir un accès sécurisé aux boîtes à lettres

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

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

5.7 Sécurisation de BIND

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

5.7.1 Configuration de Bind pour éviter de mauvaises utilisations

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

5.7.2 Changer l'utilisateur de BIND

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 Exemple de script pour changer l'installation par défaut de Bind., 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 --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Notez que l'utilisateur named sera très restreint. Si vous désirez, pout toute raison, avoir une configuration moins restrictive, utilisez : 

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

     start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Changez les permissions des fichiers utilisés par Bind, y compris /etc/bind/rndc.key : 

     -rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key

et l'endroit où bind crée son fichier pid en utilisant, par exemple /var/run/named au lieu de /var/run : 

     $ mkdir /var/run/named
     $ chown named.named /var/run/named
     $ vi /etc/named.conf
     [ ... mettez le fichier de configuration à jour en utilisant ce nouvel
     emplacement ...]
     options { ...
             pid-file "/var/run/named/named.pid";
     };
     [ ... ]

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 #52745 et Bug #128129. Vous pouvez contribuer à ces rapports de bogue si vous le désirez si vous pensez pouvoir ajouter des informations utiles.

5.7.3 Chrooter le serveur de domaine

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://web.archive.org/web/20011024064030/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 source bind
     # apt-get build-dep bind
     $ cd bind-8.2.5-2
       (éditer src/port/linux/Makefile pour que CFLAGS inclut l'option '-static')
     $ dpkg-buildpackage -rfakeroot -uc -us
     $ cd ..
     # dpkg  -i bind-8.2.5-2*deb

Après l'installation, vous devrez déplacer des fichiers dans la prison chroot[40] vous pouvez conserver les scripts 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://www.cryptio.net/~ferlatte/config/ (spécifique Debian), http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html, http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm.

5.8 Sécurisation d'Apache

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

Plus d'informations sur des restrictions supplémentaires d'Apache en mettant en place une prison chrooté dans Environnement de chroot pour Apache, Annexe H.

5.8.1 Désactiver la publication de contenu sur le web par les utilisateurs

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.

5.8.2 Permissions des fichiers de log

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.

5.8.3 Fichiers web publiés

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.

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

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

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 service, vous pouvez créer un environnement racine modifié (« 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. Mais alors, 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[41] 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.

5.10.1 Créer des environnements chrooté automatiquement

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/ et il est également disponible en tant que paquet Debian.

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

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

Vous pouvez lire plus d'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.13 Sécurisation des services RPC

Vous devriez désactiver RPC si vous n'en avez pas besoin.

Les appels de procédure à distance (« Remote Procedure Call » ou RPC) est un protocole que les programmes peuvent utiliser pour demander des services de la part d'autres programmes liées sur différents ordinateurs. Le service portmap contrôle les services RPC en convertissant les numéros de programme RPC en numéros de port du protocole DARPA ; il doit fonctionner pour pouvoir faire des appels RPC.

Les services basés sur RPC ont eu un mauvaise historique de trous de sécurité, bien que le portmapper lui-même n'en a pas (mais il fournit des informations à un attaquant distant). Notez que certaines des attaques DDoS (déni de service distribué) utilisent des exploits RPC pour entrer dans le système et agir en tant qu'un tel agent/gestionnaire.

Vous n'avez besoin de RPC que si vous utiliser un service basé sur RPC. Les services basés sur RPC les plus communs sont NFS (Network File System) et NIS (Network Information System). Voir la section précédente pour plus d'informations à propos de NIS. Le File Alteration Monitor (FAM) fourni par le paquet fam est également un service RPC et dépend donc de portmap.

Les services NFS sont assez importants dans certains réseaux. Si c'est le cas pour vous, vous aurez alors besoin de trouver un équilibre entre la sécurité et l'utilisabilité de votre réseau. (Vous pouvez en lire plus à propos de la sécurité NFS dans le NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).)

5.13.1 Désactivation des services RPC

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 et versions supérieures est de désinstaller le paquet portmap. Si vous exécutez une version plus ancienne, 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 paquet netbase (qui ne peut être désinstallé sans endommager le système).

Notez que certains environnements de bureau (notamment, GNOME) utilisent des services RPC et ont besoin du portmapper pour certaines fonctionnalités de gestion de fichiers. Si c'est votre cas, vous pouvez limiter l'accès aux services RPC comme décrit ci-dessous.

5.13.2 Limiter l'accès aux services RPC

Malheureusement, dans certains cas, supprimer les services RPC du système n'est pas une option. Certains services de bureau local (notamment fam de SGI) sont basés sur RPC et ont donc besoin d'un portmapper local. Cela veut dire que dans certains circonstances, des utilisateurs installant un environnement de bureau (comme GNOME) installera également le portmapper.

Il y a différentes façons de limiter l'accès au portmapper et aux services RPC :

5.14 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 devez installer le paquet ipchains qui devrait déjà être installé (de part sa priorité). Si vous installez un système Debian version 3.0 (ou version 3.1) (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 fonction de l'état (stateful packet inspection) qui fournit des configurations de filtrage plus sécurisées (et plus faciles à construire).

5.14.1 Firewaller le système local

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 sortantes 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 de beaucoup préférable 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évient é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'ouverture 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 :

5.14.2 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. Un pare-feu peut être configuré pour interdire l'accès de systèmes en dehors de votre réseau local à des services internes (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 Configuration d'un pare-feu pont, Annexe D pour plus d'informations sur la façon de faire cela dans un système Debian GNU/Linux.

5.14.3 Mettre en place un pare-feu

L'installation Debian par défaut, à la différence d'autres distributions Linux, ne fournit pas encore de moyen pour l'administrateur de mettre une configuration de pare-feu lors de l'installation, mais vous pouvez installer un certain nombre de paquets de configuration de pare-feu (voir Paquets pare-feu, Section 5.14.3.1).

Bien sûr, la configuration du pare-feu dépend toujours du système et du réseau. 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 plaît 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 ne savez pas comment configurer les règles de votre pare-feu manuellement, veuillez consulter le Packet Filtering HOWTO et le NAT HOWTO fournis par iptables pour une lecture hors ligne à /usr/share/doc/iptables/html/.

Si vous n'en connaissez pas beaucoup sur les pare-feu, vous devriez commencer par lire le Firewalling and Proxy Server HOWTO, installez le paquet doc-linux-text si vous voulez le lire hors ligne. Si vous désirez poser des questions ou demander de l'aide pour configurer un pare-feu, vous pouvez utiliser la liste de diffusion debian-firewall, voir http://lists.debian.org/debian-firewall. Consultez également Être conscient des problèmes de sécurité, Section 2.2 pour plus de pointeurs (généraux) sur les pare-feu.

5.14.3.1 Paquets pare-feu

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 :

Remarquez que certains des paquets cités ci-dessus introduiront probablement des scripts de pare-feu à exécuter lors de l'amorçage du système. Testez-les de manière exhaustive avant de redémarrer le système ou vous pourriez vous retrouver bloqué en dehors de la machine. Si vous mélangez différents paquets de pare-feu, vous pouvez obtenir 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 simulez). Consultez la documentation du paquet et utilisez l'un d'entre eux pour ces configurations.

Comme mentionné précédemment, certains programmes comme firestarter, guarddog knetfilter sont des interfaces graphiques pour l'administration qui utilisent soit GNOME, soit KDE (les deux derniers). Ces applications sont plus orientées utilisateur (c'est-à-dire utilisation « familiale ») tandis que certains des autres paquets de la liste sont plus orientés administrateur. Certains des programmes mentionnés auparavant (comme bastille) sont ciblés sur la mise en place de règles de pare-feu qui protègent l'hôte sur lequel ils fonctionnent, mais ils ne sont pas nécessairement conçus pour mettre en place des règles de pare-feu pour des hôtes de pare-feu qui protègent un réseau (comme shorewall ou fwbuilder).

Il existe encore un autre type d'application de pare-feu : les serveurs mandataires (proxy) applicatifs. Si vous cherchez à mettre en place un tel serveur de niveau d'entreprise qui effectue du filtrage de paquets et fournit un certain nombre de serveurs mandataires transparents qui peuvent faire une analyse fine du trafic, vous devriez considérer l'utilisation de zorp, qui fournit cela dans un seul programme. Vous pouvez également mettre en place ce type de pare-feu manuellement en utilisant les serveurs mandataires disponibles dans Debian pour différents services comme pour le DNS en utilisant bind (correctement configuré), dnsmasq, pdnsd ou totd pour le FTP en utilisant frox ou ftp-proxy, pour X11 en utilisant xfwp, pour IMAP en utilisant imapproxy, pour le courrier en utilisant smtpd, ou pour POP3 en utilisant p3scan. Pour d'autres protocoles, vous devriez soit utiliser un serveur mandataire TCP générique comme simpleproxy ou un serveur mandataire SOCKS comme dante-server, tsocks ou socks4-server. Vous devrez également typiquement utiliser un système de cache web (comme squid) et un système de filtrage web (comme squidguard ou dansguardian).

5.14.3.2 Configuration manuelle init.d

Une autre possibilité est de configurer manuellement vos règles de pare-feu par un script init.d qui exécutera toutes les commandes iptables. Suivez les étapes ci-dessous :

Voici l'exemple de script de pare-feu : 

     #!/bin/sh
     # Exemple de configuration de pare-feu
     #
     # Défauts :
     # - Cette configuration s'applique à toutes les interfaces réseau.
     #   Si vous voulez ne restreindre cela qu'à une interface donnée,
     #   utilisez '-i INTERFACE' dans les appels iptables.
     # - L'accès à distance pour les services TCP/UDP est accordé à tout
     #   hôte, vous voudrez probablement restreindre cela en utilisant
     #   '--source'
     #
     # chkconfig: 2345 9 91
     # description: Active/Désactive le pare-feu au démarrage
     #
     # Vous pouvez tester ce script avant de l'appliquer avec l'extrait de
     # shell suivant, si vous ne tapez rien pendant 20 secondes, les
     # règles de pare-feu seront effacées.
     #---------------------------------------------------------------
     #  while true; do test=""; read  -t 20 -p "OK? " test ; \
     #  [ -z "$test" ] && /etc/init.d/myfirewall clear ; done
     #---------------------------------------------------------------
     
     PATH=/bin:/sbin:/usr/bin:/usr/sbin
     
     # Services que le systèmes offrira au réseau
     TCP_SERVICES="22" # ssh seulement
     UDP_SERVICES=""
     # Services que le système utilisera du réseau
     REMOTE_TCP_SERVICES="80" # navigation web
     REMOTE_UDP_SERVICES="53" # DNS
     # Réseau qui sera utilisé pour la gestion à distance
     # (si non défini, aucune règle ne sera mise en place)
     # NETWORK_MGMT=192.168.0.0/24
     
     if ! [ -x /sbin/iptables ]; then  
         exit 0
     fi
     
     fw_start () {
     
       # Trafic d'entrée :
       /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
       # Services
       if [ -n "$TCP_SERVICES" ] ; then
       for PORT in $TCP_SERVICES; do
         /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
       done
       fi
       if [ -n "$UDP_SERVICES" ] ; then
       for PORT in $UDP_SERVICES; do
         /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
       done
       fi
       # Gestion à distance
       if [ -n "$NETWORK_MGMT" ] ; then
         /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT
       else 
         /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT}  -j ACCEPT
       fi
       # Test à distance
       /sbin/iptables -A INPUT -p icmp -j ACCEPT
       /sbin/iptables -A INPUT -i lo -j ACCEPT
       /sbin/iptables -P INPUT DROP
       /sbin/iptables -A INPUT -j LOG
     
       # Sortie :
       /sbin/iptables -A OUTPUT -j ACCEPT -o lo 
       /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
       # ICMP est permis
       /sbin/iptables -A OUTPUT -p icmp -j ACCEPT
       # Ainsi que les mises à jour de sécurité
       /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
       # Ainsi que pour tous les services que nous avons définis
       if [ -n "$REMOTE_TCP_SERVICES" ] ; then
       for PORT in $REMOTE_TCP_SERVICES; do
         /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT
       done
       fi
       if [ -n "$REMOTE_UDP_SERVICES" ] ; then
       for PORT in $REMOTE_UDP_SERVICES; do
         /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT
       done
       fi
       # Toutes les autres connexions sont enregistrées dans syslog
       /sbin/iptables -A OUTPUT -j LOG
       /sbin/iptables -A OUTPUT -j REJECT 
       /sbin/iptables -P OUTPUT DROP
       # Autres protections réseau
       echo 1 > /proc/sys/net/ipv4/tcp_syncookies
       echo 0 > /proc/sys/net/ipv4/ip_forward 
       echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
       echo 1 >/proc/sys/net/ipv4/conf/all/log_martians 
       echo 1 > /proc/sys/net/ipv4/ip_always_defrag
       echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
       echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
       echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
       echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
     
     }
     
     fw_stop () {
       /sbin/iptables -F
       /sbin/iptables -t nat -F
       /sbin/iptables -t mangle -F
       /sbin/iptables -P INPUT DROP
       /sbin/iptables -P FORWARD DROP
       /sbin/iptables -P OUTPUT ACCEPT
     }
     
     fw_clear () {
       /sbin/iptables -F
       /sbin/iptables -t nat -F
       /sbin/iptables -t mangle -F
       /sbin/iptables -P INPUT ACCEPT
       /sbin/iptables -P FORWARD ACCEPT
       /sbin/iptables -P OUTPUT ACCEPT
     }
     
     
     case "$1" in
       start|restart)
         echo -n "Starting firewall.."
         fw_stop 
         fw_start
         echo "done."
         ;;
       stop)
         echo -n "Stopping firewall.."
         fw_stop
         echo "done."
         ;;
       clear)
         echo -n "Clearing firewall rules.."
         fw_clear
         echo "done."
         ;;
       *)
         echo "Usage: $0 {start|stop|restart|clear}"
         exit 1
         ;;
       esac
     exit 0

5.14.3.3 Configurer les règles du réseau par ifup

Vous pouvez également utiliser la configuration du réseau dans /etc/network/interfaces pour mettre en place vos règles de pare-feu. Pour cela, vous devez :

Optionnellement, vous pouvez mettre en place un jeu de règles à appliquer quand l'interface est inactivée en créant un jeu de règles, en le sauvant dans /etc/iptables.down.rules et en ajoutant la directive suivante à la configuration de l'interface : 

         post-down iptables-restore < /etc/iptables.down.rules

Pour des scripts de configuration de pare-feu plus avancés avec ifupdown, vous pouvez utiliser les accroches (hooks) disponibles pour chaque interface dans les répertoires *.d/ appelés avec run-parts (voir run-parts(8)).

5.14.3.4 Le faire à la manière (obsolète) Debian

NOTE : Cette information ne s'applique qu'à iptables de Woody. Les versions ultérieures à la version 1.2.7-8 n'ont plus le script init.d décrit ici. Les utilisateurs des versions 3.1 et ultérieures de Debian devraient soit mettre en place les règles de pare-feu manuellement, soit utiliser l'un des programmes de génération de pare-feu décrits précédemment.

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 :

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.

Veuillez lire les commentaires insérés dans le fichier de configuration /etc/default/iptables pour plus d'informations concernant les problèmes relatifs à ce paquet.

5.14.3.5 Tester votre configuration de pare-feu

Tester votre configuration de pare-feu est aussi facile et aussi dangereux que d'exécuter simplement votre script de pare-feu (ou d'activer la configuration que vous avez définie dans votre application de configuration de pare-feu). Cependant, si vous n'êtes pas assez prudent et que vous configurez le pare-feu à distance (comme à travers une connexion SSH), vous pourriez vous enfermer dehors.

Il y a plusieurs moyens d'empêcher cela. L'un est d'exécuter un script dans un terminal séparé qui va enlever la configuration de pare-feu si vous ne faites pas d'entrée clavier. Un exemple de cela est : 

     $  while true; do test=""; read  -t 20 -p "OK? " test ; \
       [ -z "$test" ] && /etc/init.d/firewall clear ; done

Un autre moyen est d'introduire une porte dérobée dans votre système par un mécanisme alternatif qui vous permet soit d'enlever le système de pare-feu, soit de percer un trou dedans si quelque chose déraille. Pour cela, vous pouvez utiliser knockd et le configurer pour qu'une tentative de connexion sur un certain port enlève le pare-feu (ou ajoute une règle temporaire). Bien que les paquets soient rejetés par le pare-feu, comme knockd se lie à l'interface et les voit, vous pourrez contourner le problème.

Tester un pare-feu qui protège un réseau interne est un problème différent, vous voudrez étudier certains des outils utilisés pour le test de failles à distance (voir Outils d'évaluation des vulnérabilités à distances, Section 8.1) pour sonder le réseau depuis l'extérieur (ou dans toute autre direction) pour tester l'efficacité de la configuration du pare-feu.

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

Manuel de sécurisation de Debian

Version: 3.4, Sun, 06 Nov 2005 22:34:04 +0100

Javier Fernández-Sanguino Peña jfs@debian.org
Auteurs, Section 1.1

version française par Frédéric Bothamy (traducteur actuel)
Pierre Machard et Arnaud Assad (anciens traducteurs)
et les membres de la liste debian-l10n-french@lists.debian.org