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

Securing Debian Manual
Chapitre 5 - Sécurisation des services du 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 ne 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 le correctif vserver pour Linux (2.4.16) peut être utilisé 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étadémon xinetd, inclut une option bind pour faire cela. Consultez 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 en fonction de leur utilisation.

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 le système.

Encourager tous les utilisateurs du 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 superutilisateur et préférer l'utilisation de méthodes alternatives pour devenir superutilisateur comme su ou sudo. Enfin, le fichier sshd_config, dans /etc/ssh, devrait être modifié comme suit 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, trois démons SSH sont 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 même des rumeurs à propos d'un portage pour Windows). ssh2 a beaucoup d'avantages par rapport à ssh1 sauf qu'il est diffusé sous une licence non libre. OpenSSH est un démon SSH complètement libre, qui gère à 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 la prise en charge 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, consultez 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 un environnement chroot pour SSH.

5.1.2 Clients SSH

Si vous utilisez un client SSH pour se connecter au serveur SSH, vous devez vous assurer qu'il prend en charge les mêmes protocoles que ceux utilisés sur le serveur. Par exemple, si vous utilisez le paquet mindterm, il ne prend en charge 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.

Vous pouvez aussi cloisonner les utilisateurs dans un chroot (en utilisant libpam-chroot de telle sorte que même si le transfert de fichiers est autorisé, ils soient limités à un environnement qui ne contient aucun fichier système.

5.1.4 Restriction d'accès au seul transfert de fichiers

Vous pourriez restreindre l'accès aux utilisateurs pour leur permettre seulement le transfert de fichiers sans interpréteur de commandes interactif. Pour faire cela, vous pouvez :

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 le 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. Consultez le Guide d'utilisateur de Squid pour plus d'informations à propos des règles ACL. Veuillez noter que Debian fournit une configuration minimale pour Squid qui empêche tout, à l'exception de la connexion de localhost au serveur mandataire (qui fonctionnera sur le port 3128 par défaut). Vous devrez personnaliser le fichier/etc/squid/squid.conf comme nécessaire. La configuration minimale recommandée (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  # ports non enregistrés
     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 VOS PROPRES RÈGLES ICI POUR PERMETTRE L'ACCÈS
     # DEPUIS LES CLIENTS
     #
     http_access allow localhost
     # Et enfin, interdit tout autre accès à ce mandataire
     http_access deny all
     # Par défaut :
     # icp_access deny all
     #
     # Permet les requêtes ICP à 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 et le cache correctement ne représente qu'une partie de la sécurisation du site. Une autre tâche nécessaire réside dans l'analyse des journaux de Squid pour s'assurer que tout fonctionne comme prévu. Quelques paquets dans Debian GNU/Linux peuvent aider l'administrateur dans cette tâche. Les paquets suivant sont disponibles dans Debian 3.0 et Debian 3.1 (Sarge)  :

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

5.3 Sécurisation de 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 le système comme s'il disposait d'un interpréteur de commandes. Vous pouvez ajouter la ligne suivante dans la section global de proftpd.conf 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 par déni de service 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 (ce 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émentations 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 anonymes à 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 valables. Plus d'informations et le correctif sont disponibles, consultez Correctifs ProFTPD. Ce correctif a été également indiqué pour Debian, consultez le bogue nº 145669.

5.4 Sécurisation de l'accès au système X Window

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. Cela 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 la machine. Cela autorise tout client X à se connecter au système. Pour une sécurité légèrement meilleure, vous pouvez utiliser la commande xhost +hostname à la place, ce qui permet de n'autoriser les accès que depuis certains hôtes.

Une solution encore meilleure serait d'utiliser un tunnel SSH pour X et de chiffrer toute la session. C'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 (/usr/bin/xauth sur Debian unstable) pour mettre en place le pseudoaffichage 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 l'écoute sur le port TCP 6000 en tapant simplement : 

     $ startx -- -nolisten tcp

C'est le comportement par défaut dans XFree 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 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 [41].

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 de renseignements 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 le gestionnaire d'affichage

Si vous ne voulez un gestionnaire d'affichage installé que pour une utilisation locale (avec une jolie connexion graphique, tout de même), 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 le 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 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 le 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 le 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 à /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 ou hôtes qui ne sont pas autorisés à imprimer (le démon lpr ne peut être limité que pour écouter 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 indiquer l'interface sur laquelle se lier (cependant d'une manière un peu bizarre)

Si vous utilisez une imprimante sur le 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 fourni 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 par le protocole HTTP. Cela 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 chiffrement. 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 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 Debian.

5.6 Sécurisation du service de courrier

Si le serveur n'est pas un système d'envoi de courrier, vous n'avez pas réellement besoin d'un démon de courrier écoutant les connexions entrantes, mais vous pourriez vouloir que le courrier local soit distribué pour, par exemple, recevoir le courrier du superutilisateur 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. Consultez Désactivation de services démon, Section 3.6.1 pour le façon de 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. C'est courant quand vous devez 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. Comme toute la journalisation de chaque système individuel peut être centralisée en utilisant un serveur de journalisation système centralisé, les courriers peuvent être envoyés à un serveur de courriers central.

Un tel système relais 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, si le MTA est configuré pour ne délivrer que des messages locaux, de n'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 Exim n'écoutera que sur la socket 127.0.0.1:25. 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 TCP du démon de courrier ou l'ajout de règles de 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 une encapsulation TCP pour que les connexions entrantes soient 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é sur le démon de courrier, si vous mettez en place correctement la journalisation pour n'importe laquelle des méthodes décrites plus haut.

En tout cas, pour rejeter les tentatives de relais de courrier au niveau SMTP, vous pouvez modifier /etc/exim/exim.conf pour inclure : 

     receiver_verify = true

Même si le serveur de courrier ne relaiera pas le message, ce genre de configuration est nécessaire au testeur de relais à http://www.abuse.net/relay.html pour déterminer que le serveur ne peut pas faire de relais.

Si vous voulez une configuration relais 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 [42] 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[43] 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 à l'interpréteur de commandes car les utilisateurs peuvent être capables de récupérer n'importe quel fichier par celle-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 gère, uw-imapd-ssl) peut être configuré pour « chrooter » les répertoires de courrier des utilisateurs, mais cela 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 valables soient créés sur le système local (ce qui donnerait également un accès à l'interpréteur de commande), 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 de manière sûre

La lecture et réception du courrier sont des protocoles en texte clair parmi les plus courants. Si vous utilisez POP3 ou IMAP pour récupérer le 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 avec interpréteur de commandes sur la machine qui sert de serveur POP ou IMAP. Voici un fetchmailrc simple décrivant cela : 

     poll mon-serveur-imap.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
          mon-serveur-imap.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 connexions au port local 1236 vers le port IMAP du serveur de mail, mais chiffré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 chiffré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 indiqué (-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 certains renseignements donnés par le serveur DNS aux clients extérieurs pour l'empêcher d'ê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, consultez /usr/share/doc/bind/html/index.fr.html en plus à ce sujet 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 à 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 exploiter une attaque de débordement de tampon sur) le serveur DNS. Vous pouvez même le mettre uniquement en écoute sur l'adresse 127.0.0.1 si vous ne désirez offrir le service à personne d'autre que 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 cela 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 vérifier (de nouveau) le système de suivi des bogues (BTS) à propos de BIND, en particulier le bogue nº 94760 (à propos des ACL sur les transferts de zone). 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 différent du superutilisateur exécute BIND, alors BIND ne peut pas détecter de nouvelles interfaces automatiquement, par exemple, quand vous insérez une carte PCMCIA dans un portable. Consultez le fichier README.Debian du répertoire de documentation de named (/usr/share/doc/bind/README.Debian) pour plus d'informations sur ce problème. De nombreux problèmes de sécurité concernant BIND ont été récemment découverts, donc le changement d'utilisateur est utile si 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.

Remarquez, de toute façon, que cela ne concerne que la version 8 de BIND. Dans les paquets Debian de la version 9 (depuis la version 9.2.1-5, disponible avec Sarge), l'utilisateur bind est créé et utilisé en configurant la variable OPTIONS de /etc/default/bind9. Si vous utilisez BIND version 9 et que le démon de serveur de noms ne fonctionne pas avec l'utilisateur bind, vérifiez les configurations de ce fichier.

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 superutilisateur). Dans cet 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 vous pouvez soit éditer, à l'aide de votre éditeur favori, /etc/init.d/bind et modifiez les lignes commençant par 

     start-stop-daemon --start

en[44] 

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

soit modifier (créez-le s'il n'existe pas) le fichier de configuration par défaut (/etc/default/bind pour BIND en version 8) et introduisez ceci : 

     OPTIONS="-u named -g named"

Modifiez 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 superutilisateur, modifiez la ligne reload du script init.d en substituant : 

     reload)
            /usr/sbin/ndc reload

par : 

     reload)
             $0 stop
             sleep 1
             $0 start

Remarque : selon la version de Debian, vous pouvez devoir changer la ligne restart également. Cela a été corrigé dans la version 1:8.3.1-2 de BIND pour Debian.

Il ne reste plus qu'à redémarrer BIND à l'aide de /etc/init.d/bind restart, puis rechercher dans le journal système 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 named ne s'exécute plus en tant que superutilisateur. Si vous voulez lire plus d'informations sur pourquoi BIND ne fonctionne pas en tant qu'utilisateur non superutilisateur sur les systèmes Debian, veuillez vérifier le système de suivi des bogues concernant BIND, en particulier les bogues nº 50013 : bind ne devrait pas fonctionner en tant que superutilisateur, nº 132582 : l'installation par défaut est potentiellement non sécurisée, nº 53550, nº 52745 et nº 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 (consultez Paranoïa généralisée du suid et du chroot, Section 5.10) autour du démon. Il y a un moyen facile de faire cela : l'option -t (consultez la page de manuel named(8) ou la page 100 de la documentation 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 bibliothèques 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 accessible en
                       écriture à l'utilisateur named
     var/log/named   - si vous configurez le journal vers un fichier, doit
                       être accessible en écriture à l'utilisateur named
     dev/log         - syslogd devrait écouter ici si named est configuré
                       pour journaliser en l'utilisant

Pour que le 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. Prenez en compte qu'il n'a besoin que d'un accès en lecture seule aux fichiers de zone, sauf s'il s'agit un serveur de nom secondaire ou serveur cache. Si c'est le cas vous devrez permettre la lecture et l'é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 (c'est-à-dire pas seulement l'option -t) pour BIND dans Debian, assurez-vous qu'elle contient les fichiers suivants[45] : 

     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.3.6.so
     lib/libc-2.3.6.so
     lib/ld-linux.so.2 - lié symboliquement à ld-2.3.6.so  
     lib/libc.so.6 - lié symboliquement à libc-2.3.6.so
     sbin/ldconfig - pourra être effacé après la configuration du chroot
     sbin/named-xfer - si vous faites des transferts de nom
     var/run/

Modifiez aussi l'écoute de syslogd sur $CHROOT/dev/log pour que le serveur de nom puisse écrire des entrées de journalisation système dans le journal du système local.

Pour é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 faudrait faire quelque chose comme : 

     $ apt-get source bind
     # apt-get build-dep bind
     $ cd bind-8.2.5-2
       (modifier src/port/linux/Makefile pour que CFLAGS contienne
        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[46] 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 ou utilisez l'option -t de BIND en la configurant dans l'argument OPTIONS du fichier de configuration /etc/default/bind (pour la version 8) ou /etc/default/bind9 (pour la version 9).

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

La documentation d'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é sont disponibles en 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://serveur_apache/~utilisateur.

Pour empêcher cela, veuillez modifier le fichier de configuration /etc/apache/http.conf en commentant (pour Apache 1.3) le module suivant : 

     LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

Avec Apache 2.0, il faut supprimer le fichier /etc/apache2/mods-enabled/userdir.load ou restreindre la configuration par défaut en modifiant /etc/apache2/mods-enabled/userdir.conf.

Cependant, si le module a été lié statiquement (vous pouvez obtenir la liste des modules compilés en exécutant apache -l), vous devez ajouter la ligne suivante au fichier de configuration d'Apache : 

     Userdir disabled

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. Vous pouvez éviter cela en utilisant le module Rewrite.

5.8.2 Permissions des fichiers de journalisation

Les fichiers de journalisation 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 augmentation de droits) 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écute avec l'utilisateur www-data et le groupe www-data. Cela devrait rendre plus difficile aux attaquants qui compromettent le système par le site web de le défigurer. 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 devriez, lors de la mise en place par 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 d'hôtes donné (en utilisant l'encapsulation TCP) et 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 faites pas confiance à l'utilisateur ou au service, vous pouvez créer un environnement racine modifié pour lui. Cela 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 malveillant, l'étendue des dommages est limitée à la prison.

Un grand nombre de services fonctionnant en 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[47] par défaut.

Exemples : serveurs de noms de domaine (comme bind), serveurs web (comme apache), serveurs de courrier (comme sendmail) et serveurs FTP (comme wu-ftpd). La complexité de BIND est probablement la raison pour laquelle il a été exposé à de nombreuses attaques ces dernières années (consultez Sécurisation de BIND, Section 5.7).

Cependant, Debian fournit des logiciels qui peuvent vous aider à mettre en place des environnements chroot. Consultez 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. Cela comprend : révoquer les droits du superutilisateur, le faire fonctionner dans un environnement restreint (comme une 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 superutilisateur. Vous devez donc faire fonctionner le service avec un utilisateur sans droits élevés. En limitant son environnement, vous limitez les fichiers lisibles et exécutables par tout le monde auxquels le service peut accéder, vous limitez donc aussi les possibilités d'une augmentation de droits en utilisant des failles de sécurité sur le système local. Même dans une situation où vous ne pouvez pas être complètement 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

Plusieurs programmes permettent de 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 au démon en utilisant strace, stat et les dépendances du paquet Debian. De plus amples renseignements sont disponibles à http://www.floc.net/makejail/. Jailer est un outil semblable disponible à http://www.balabit.hu/downloads/jailer/ et en 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 chiffré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

Si possible, évitez d'utiliser NIS, le service d'informations réseau (« Network Information Service »), car il autorise le partage de mot de passe. Cela 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).

Des informations supplémentaires sur la sécurité de NIS sont disponibles à l'adresse NIS-HOWTO (/usr/share/doc/HOWTO/fr-txt/NIS-HOWTO.txt.gz).

FIXME (jfs) : Ajouter des renseignements sur la façon de configurer cela dans 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) sont 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é) exploitent RPC pour entrer dans le système et agir en tant qu'agent ou gestionnaire.

Vous n'avez besoin de RPC que si vous utilisez un service basé sur RPC. Les services basés sur RPC les plus communs sont NFS (Network File System) et NIS (Network Information System). Consultez 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é du réseau (plus de renseignements à propos de la sécurité NFS sont disponibles dans le NFS-HOWTO ou /usr/share/doc/HOWTO/fr-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 . Si vous installez une version récente de Debian (le noyau installé par défaut est le 2.6) vous aurez la fonctionnalité pare-feu iptables (netfilter) disponible[48].

5.14.1 Protéger le système local avec un pare-feu

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-feu 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 largement préférable de ne pas dépendre exclusivement des capacités d'un pare-feu pour protéger un système donné. La sécurité dans un système est réalisée par 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, etc.), 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 superutilisateur 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 (c'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-feu, 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. Consultez 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 (consultez 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 ne connaissez pas grand chose 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, consultez 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. Un autre bon tutoriel d'iptables est http://iptables-tutorial.frozentux.net/iptables-tutorial.html.

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.

Plusieurs logiciels peuvent être utilisés pour configurer des règles de pare-feu dans un système Debian.

De nombreuses autres interfaces à iptables sont disponibles dans Debian ; une liste exhaustive de comparaison des différents paquets dans Debian est tenue à jour sur la page du wiki Debian sur les pare-feu.

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 voulez). 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 ou 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 pare-feu 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, soit 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.
     #
     # Mises en garde
     # - 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 : activer ou désactiver le pare-feu au démarrage
     #
     # Vous pouvez tester ce script avant de l'appliquer avec l'extrait
     # de script 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/parefeu clear ; done
     #---------------------------------------------------------------
     
     PATH=/bin:/sbin:/usr/bin:/usr/sbin
     
     # Services que le système offrira au réseau
     TCP_SERVICES="22" # seulement SSH
     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
     # Port utilisé pour le service SSH, à définir si vous avez configuré
     # une gestion de réseau mais l'avez enlevé de TCP_SERVICES
     # SSH_PORT="22"
     
     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é :
       # Remarque : vous pouvez indiquer en dur l'adresse IP ici afin de prévenir une
       # usurpation DNS et configurer les règles même si le DNS ne fonctionne pas mais
       # dans ce cas vous ne « verrez » pas les modifications d'IP pour ce service :
       /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
       # Ainsi que pour tous les services 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
       # (certaines ne fonctionneront que pour certaines versions de noyau)
       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 "Démarrage du pare-feu…"
         fw_stop 
         fw_start
         echo "done."
         ;;
       stop)
         echo -n "Arrêt du pare-feu…"
         fw_stop
         echo "done."
         ;;
       clear)
         echo -n "Effacement des règles de pare-feu…"
         fw_clear
         echo "done."
         ;;
       *)
         echo "Utilisation : $0 {start|stop|restart|clear}"
         exit 1
         ;;
       esac
     exit 0

Au lieu d'intégrer toutes les règles iptables dans un script init.d, vous pouvez utiliser le programme iptables-restore pour restaurer les règles sauvées avec iptables-save. Pour faire cela, vous devez configurer les règles et sauver le jeu de règles dans un endroit statique (comme /etc/default/firewall).

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 les 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 (consultez run-parts(8)).

5.14.3.4 Tester la configuration de pare-feu

Tester la configuration de pare-feu est aussi facile et aussi dangereux que d'exécuter simplement le script de pare-feu (ou d'activer la configuration que vous avez définie dans l'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.

Plusieurs moyens permettent 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 le 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 (consultez Outils d'évaluation des vulnérabilités à distance, 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 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]

Securing Debian Manual

Version: 3.13, Sun, 08 Apr 2012 02:48:09 +0000

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