Les services présents sur un système peuvent être sécurisés de deux façons :
Restreindre les services ainsi ils ne seront accessibles que depuis un endroit bien spécifique. Ces restrictions peuvent-être faites au niveau du noyau (pare-feu), configurez les services pour écouter uniquement sur une interface définie (certains services ne fournissent peut-être pas cette fonctionnalité) ou utilisez tout autre méthode, par exemple la rustine vserver pour linux (pour 2.4.16) peut-être utilisée pour forcer les processus à utiliser qu'une interface.
Concernant les services lancés par inetd
(telnet, ftp, finger,
pop3...) il est à noter que inetd ne peut pas être configuré afin que des
services écoutent uniquement sur une interface précise. Toutefois, le
programme xinetd
substitue cela par l'inclusion d'un
raccourci pour parer ce cas. Voir xinetd.conf(5)
.
service nntp { socket_type = stream protocol = tcp wait = no user = news group = news server = /usr/bin/env server_args = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin +/usr/sbin/snntpd logger -p news.info bind = 127.0.0.1 }
Les paragraphes suivants détaillent comment déterminer les services qui peuvent être configurés correctement s'appuyant sur une utilisation définie.
Si vous utilisez toujours telnet au lieu de ssh, vous devriez prendre une pause dans la lecture de ce manuel pour remedier à cela. Ssh devrait être utilisé pour toutes les connexions distantes à la place de telnet. A une époque où il est facile de renifler le trafic Internet et d'obtenir les mots de passe en clair, vous devriez utiliser uniquement les protocoles qui utilisent la cryptographie. Par conséquent, effectuez maintenant un apt-get install ssh sur votre système.
Encourager tous les utilisateurs de votre système à utiliser ssh au lieu de telnet, ou encore mieux, désinstallez telnet/telnetd. De plus, vous devriez éviter de vous connecter au système en utilisant ssh en tant que root et préférer l'utilisation de méthodes alternatives pour devenir root tel su ou sudo. Enfin, le fichier sshd_config, dans /etc/ssh, devrait ainsi être modifié pour accroître la sécurité :
Faîtes écouter ssh seulement sur une interface donnée, juste au cas où vous en avez plus d'une (et ne voulez pas que ssh y soit disponible) où si vous ajoutez, dans le futur, une nouvelle carte réseau (et ne voulez pas de connexions ssh dessus).
Essayez autant que possible de ne pas autoriser de connexion en tant que root. Si quelqu'un veut devenir root via ssh, deux logins sont maintenant nécessaires et le mot de passe root ne peut être attaqué par moulinette via SSH.
Change le port d'écoute, ainsi l'intrus ne peut être complètement sûr de l'exécution d'un daemon sshd (soyez prévenus, c'est de la sécurité par l'obscurité).
Les mots de passe vides sont un affront au système de sécurité.
Autorise seulement certains utilisateurs à avoir accès via ssh à cette machine.
Autorise seulement certains membres de groupes à avoir accès via ssh à cette machine. AllowGroups et AllowUsers ont des directives équivalentes pour interdire l'accès à la machine. Sans surprise elles s'appellent "DenyUsers" et "DenyGroups".
Il vous appartient complètement de décider ce que vous voulez faire. Il est
plus sûr d'autoriser l'accès à la machine uniquement aux utilisateurs avec des
clés ssh placées dans le fichier ~/.ssh/authorized_keys
. Si c'est
ce que vous voulez, positionnez cette option à "no".
Pour finir, soyez conscient que ces directives proviennent d'un fichier de configuration OpenSSH. Actuellement, il y a 3 daemons ssh couramment utilisés, ssh1, ssh2, et OpenSSH par les gens d'OpenBSD. Ssh1 était le premier daemon ssh disponible et est toujours le plus couramment utilisé (il y a des rumeurs qu'il y aurait même un portage windows). Ssh2 a beaucoup d'avantages par rapport à ssh1 excepté qu'il est diffusé sous une licence non-libre. OpenSSH est un daemon ssh complètement libre, qui supporte à la fois ssh1 et ssh2. OpenSSH est la version installée sur la Debian quand le paquetage 'ssh' est choisi.
Vous pouvez obtenir plus d'informations concernant la mise en place de SSH avec
le support PAM dans les archives
de la liste de discussion sécurité
.
Squid est l'un des plus populaires serveurs proxy/cache et certains problèmes
de sécurité sont à prendre en compte. Le fichier de configuration par défaut
de Squid refuse toutes les requêtes d'utilisateurs. Vous devriez configurer
Squid pour permettre aux utilisateurs, hôtes ou réseaux de confiance une Liste
de Contrôle d'Accès (ACL) sur /etc/squid.conf
. Voir le Guide
d'utilisateur Squid
pour plus d'informations à propos des règles
ACL.
De même, si il n'est pas configuré correctement, n'importe qui peut relayer un message par l'intermédiaire de Squid, puisque les protocoles HTTP et SMTP sont désignés de façon similaire. Le fichier de configuration par défaut interdit l'accès au port 25. Si vous voulez autoriser les connexions sur ce port, il vous faudra l'ajouter dans la liste des Safe_ports (ports autorisés). Cependant, ce n'est PAS recommandé.
Installer et configurer le serveur mandataire/cache correctement représente seulement une partie de la sécurisation de votre site. Une autre tâche nécessaire consiste dans l'analyse des logs de Squid pour assurer que tout fonctionne comme il se doit. Il y a quelques paquets dans Debian GNU/Linux qui peuvent aider l'administrateur dans cette tâche. Les paquets suivant sont disponible dans la woody (Debian 3.0):
calamaris
- Analyseur de log pour Squid ou Oops proxy.
modlogan
- Un analyseur modulaire de fichier logs.
sarg
- Squid Analysis Report Generator.
FIXME: Ajouter de plus amples informations sur la sécurité sur Squid Accelerator Mode
Si vous avez réellement besoin d'utiliser FTP (sans l'emballer avec sslwrap ou
à l'intérieur d'un tunnel SSL ou SSH), vous devriez "chrooter" ftp
dans le répertoire home de l'utilisateur, ainsi l'utilisateur est incapable de
voir autre chose que ses propres répertoires. Autrement, il peut parcourir
votre système comme s'il avait un shell. Vous pouvez ajouter la ligne suivante
dans votre proftpd.conf
dans la section global pour activer ce
chroot :
DefaultRoot ~
Redémarrez proftpd par /etc/init.d/proftpd restart et vérifiez si vous pouvez sortir de votre propre répertoire home.
Pour prévenir Proftpd d'attaques Dos avec l'utilisation de ../../.., ajouter la
ligne suivante dans /etc/proftpd.conf
: DenyFilter
\*.*/
Rappelez-vous toujours que le FTP envoi les identifiants et les mots de passe
d'authentification en clair (ceci n'est pas un problème si vous fournissez un
service public anonyme) et il existe de meilleures alternatives dans Debian
pour cela. Par exemple, sftp
(fourni par ssh
). Il
existe également d'autres implémentatations de SSH pour d'autres systèmes
d'exploitation : putty
et
cygwin
par exemple.
Actuellement, les terminaux X sont de plus en plus utilisés dans les entreprises où un seul serveur est nécessaire pour un grand nombre de stations de travail. Ceci peut-être dangereux car vous devez autoriser le serveur de fichier à se connecter aux clients (le serveur X d'un point de vue X. X intervertit la notion de client et de serveur). Si vous suivez les (très mauvaises) suggestions de nombreuses docs, vous tapez xhost + sur votre machine. Ceci autorise tout client X à se connecter à votre système. Pour une sécurité légèrement meilleure, vous pouvez utiliser la commande xhost +hostname à la place qui permet d'autoriser uniquement les accès depuis des hôtes spécifiques.
Une solution encore meilleure serait d'utiliser un tunnel ssh pour X et d'encrypter toute la session. Ceci est fait automatiquement lors de l'utilisation de ssh pour se connecter sur une autre machine. Ceci doit être activé dans /etc/ssh/ssh_config en paramétrant X11Forwarding à yes. A l'heure de SSH, vous devriez abandonner complètement le contrôle d'accès basé dur xhost.
Pour une sécurité accrue, si vous n'avez pas besoin d'accéder à X depuis d'autres machines, désactivez-le du port 6000 en tapant simplement : startx -- -nolisten tcp
Ceci est le comportement par défaut dans Xfree 4.0 (le serveur X fourni dans la
Debian 3.0). Si vous utilisez Xfree 3.3.6 (vous avez donc la Debian 2.2
d'installé) vous pouvez éditer /etc/X11/xinit/xserverrcc
afin
d'avoir quelque chose ressemblant à ceci :
#!/bin/sh exec /usr/bin/X11/X -dpi 100 -nolisten tcp
Si vous utilisez XDM, mettre /etc/X11/xdm/Xservers
à : :0
local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp
Plus d'infos sur la sécurité X Window dans XWindow-User-HOWTO
(/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz
).
FIXME: Ajouter des informations sur debian-security pour avoir le cheminement de configuration des fichiers de XFree 3.3.6.
Si vous voulez seulement avoir un gestionnaire d'affichage installé pour une utilisation locale (en ayant un joli login graphique, c'est tout), assurez vous que le XDMCP (X Display Manager Control Protocol) est désactivé. Dans XDM vous pouvez faire ça avec cette ligne dans /etc/X11/xdm/xdm-config:
DisplayManager.requestPort: 0
Normalement, tous les gestionnaires d'affichages sont configurés par défaut pour ne pas démarrer les services XDMCP dans la Debian.
Imaginez, vous arrivez au travail et l'imprimante crache une quantité infinie
de papier car quelqu'un est en train de provoquer un déni de service sur votre
daemon d'impression. Méchant, n'est ce pas? Donc, gardez vos serveurs
d'impression particulièrement sûrs. Cela veut dire qu'il est nécessaire de
configurer votre service d'impression pour qu'il autorise seulement les
connexions d'un ensemble de serveurs de confiance. Pour ce faire, ajoutez les
serveurs auxquels vous voulez autoriser l'impression à votre
/etc/hosts.lpd
.
Cependant, même si vous faites cela, le daemon lpr accepte les connexions entrantes sur le port 515 de n'importe quelle interface. Vous devriez réfléchir au filtrage par un pare-feux des connexions provenant de réseaux/hôtes qui ne sont pas autorisés à imprimer (le daemon lpr ne peut être limité pour écouter seulement sur une adresse IP donnée).
Lprng doit être préféré à lpr car il peut être configuré pour faire du contrôle d'accès basé sur l'IP. Vous pouvez spécifier l'interface sur laquelle on se lie (cependant d'une manière un peu bizarre)
Si vous utilisez une imprimante sur votre système, mais seulement localement,
vous ne voulez pas partager ce service sur le réseau. Vous pouvez considérer
l'utilisation d'autres systèmes d'impression, comme celui fournit par
cups
ou PDQ
qui est basé sur les permissions utilisateurs du périphérique
/dev/lp0
.
De plus, cups
peut être configuré pour se lier à l'interface de
bouclage (loopback) en modifiant /etc/cups/cupsd.conf
:
Listen 127.0.0.1:631
FIXME: Ajouter plus de contenu (l'article sur Amateur Fortress Building
fournit
certains points de vues très intéressants).
FIXME: Vérifier la disponibilité de PDG dans la Debian, et si il l'est, le suggérer comme le système d'impression préféré.
FIXME: Vérifier si Farmer/Wietse a une alternative pour le daemon d'imprimante et si il est disponible dans la Debian.
Si votre serveur n'est pas un système d'envoi de mail, vous n'avez pas réellement besoin d'un daemon mail écoutant les connexions entrantes, mais vous pourriez vouloir votre courrier local distribué pour, par exemple, recevoir le courrier pour l'utilisateur root en provenance d'un des systèmes d'alerte en place.
Pour faire cela dans un système Debian, vous aurez à retirer le daemon smtp d'inetd:
$ update-inetd --disable smtp
et configurer le daemon de mail pour écouter seulement sur l'interface de
bouclage. Dans exim (le MTA par défaut) vous pouvez faire ça en éditant le
fichier /etc/exim.conf
et en ajoutant la ligne suivante:
local_interfaces = "127.0.0.1"
Redémarrez les deux daemons (inetd et exim) et vous aurez exim qui écoutera sur 127.0.0.1:25 uniquement. Faites attention, et avant tout désactivez inetd, sinon, exim ne démarrera pas étant donné que le daemon inetd est déjà en attente de connexions entrantes.
Pour postfix éditez /etc/postfix/main.conf
:
inet_interfaces = localhost
Si vous voulez seulement le courrier local, cette approche est meilleure que
l'encapsulation du daemon mail par un tcp wrapper ou l'ajout de règles pare-feu
pour limiter les personnes qui y accèdent. Cependant, si vous n'avez pas
besoin d'écouter sur d'autres interfaces, vous pourriez envisager de le lancer
à partir d'inetd et ajouter un tcp wrapper pour que les connexions entrantes
soit vérifiées par rapport à /etc/hosts.allow
et
/etc/hosts.deny
. De plus, vous serez au courant quand un accès
non autorisé est tenté contre votre daemon de mail, si vous mettez en place
correctement le logging pour n'importe laquelle des méthodes décrites plus
haut.
La lecture/réception du courrier est le plus courant des protocoles en texte clair. Si vous utilisez soit POP3 ou IMAP pour récupérer votre courrier, vous envoyez votre mot de passe en clair à travers le réseau, et donc presque tout le monde peut lire votre courrier à partir de maintenant. A la place, utilisez SSL (Secure Sockets Layer) pour recevoir votre courrier. L'autre alternative est ssh, si vous avez un compte shell sur la machine qui sert de serveur POP ou IMAP. Voici un fetchmailrc simple pour décrire cela :
poll my-imap-mailserver.org via "localhost" with proto IMAP port 1236 user "ref" there with password "hackme" is alex here warnings 3600 folders .Mail/debian preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref my-imap-mailserver.org sleep 15 </dev/null > /dev/null'
Le preconnect est la ligne importante. Elle lance une session ssh et crée le tunnel nécessaire, qui relaie automatiquement les connections au port local 1236 vers le port IMAP du serveur de mail, mais cryptées. Une autre possibilité serait d'utiliser fetchmail avec la fonctionnalité ssl.
si vous désirez fournir des services de courrier comme POP et IMAP cryptés, apt-get install stunnel et démarrez vos daemons ainsi:
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
Cette commande encapsule le daemon fourni (-l) au port (-d) et utilise le certificat ssl spécifié (-p).
Il y a différents problèmes qui peuvent être traités pour sécuriser le daemon de serveur de domaine; problèmes similaires à ceux étudiés quand on sécurise n'importe quel service donné:
Vous devriez restreindre certaines informations données par le serveur DNS aux
clients extérieurs pour qu'il ne puisse pas être utilisé pour obtenir des
informations de valeur sur votre organisation que vous ne voudriez pas
divulguer. Cela inclus l'ajout des options suivantes: allow-transfer,
allow-query, allow-recursive et version. Vous
pouvez soit limiter cela dans la section globale (pour que cela s'applique à
toutes les zones servies) ou individuellement par zone. Cette information est
documentée dans le paquetage bind-doc
, lisez en plus à ce sujet
dans /usr/share/doc/bind/html/index.html
une fois que le paquetage
est installé.
Imaginez que votre serveur (un serveur avec plusieurs adresses de base) est
connecté à Internet et à votre réseau interne (votre IP interne est
192.168.1.2), vous ne voulez fournir aucun service à Internet et vous voulez
juste autoriser les consultations DNS à partir de vos hôtes internes. Vous
pourriez le restreindre en incluant dans /etc/bind/named.conf
:
options { allow-query { 192.168.1/24; } ; allow-transfer { none; } ; allow-recursive { 192.168.1/24; } ; listen-on { 192.168.1.2; } ; forward { only; } ; forwarders { A.B.C.D; } ; };
L'option listen-on lie uniquement le DNS à l'interface ayant une adresse interne, mais, même si cette interface est la même que l'interface qui permet la connexion à Internet (Par l'utilisation de NAT, par exemple), les requêtes ne seront acceptées que si celles-ci proviennent d'hôtes internes. Si le système est constitué de plusieurs interfaces et que le listen-on n'est pas présent, seuls les utilisateurs internes pourront émettre des requêtes, mais, puisque le port restera accessible à des attaquants externes, ils pourront essayer de cracher (ou tenter une attaque d'exploit de débordement de tampon) le serveur DNS. Vous pouvez même le mettre uniquement en écoute sur l'adresse 127.0.0.1 si vous ne désirez pas offrir le service a quelqu'un d'autre qu'à vous même.
L'enregistrement version.bind dans la classe chaos contient la version du processus bind actuellement en cours d'exécution. Cette information est souvent utilisée par des scanners automatisés et des individus malveillants qui souhaitent déterminer si un bind est vulnérable à une attaque spécifique. En fournissant de fausses ou pas d'informations, on limite la probabilité qu'un serveur soit attaqué sur la base de la version qu'il publie. Pour fournir votre propre version, utilisez la directive version de la manière suivante:
options { ... diverses options ici ... version "Not available."; };
Changer l'enregistrement version.bind ne fournit pas actuellement de protection contre les attaques, mais ceci devrait être considéré comme une protection utile.
Concernant la limitation des privilèges de BIND vous devez être conscient que
si un utilisateur autre que root exécute BIND, alors BIND ne peut pas détecter
de nouvelles interfaces automatiquement. Par exemple, si vous insérez une
carte PCMCIA dans votre portable. Consultez le fichier README.Debian dans
votre répertoire de documentation named
(/usr/share/doc/bind/README.Debian
) pour plus d'information sur ce
problème. Il y a eu récemment de nombreux problèmes de sécurité concernant
BIND, donc le changement d'utilisateur est utile quand il est possible.
Pour démarrer BIND sous un autre utilisateur, tout d'abord créez un utilisateur et un groupe séparé (ce n'est pas une bonne idée d'utiliser nobody ou nogroup pour chaque service ne devant pas tourner en tant que root). Dans cette exemple, l'utilisateur et le groupe named seront utilisé. Vous pouvez faire cela en tapant :
addgroup named adduser --system --ingroup named named
Maintenant éditez, à l'aide de votre éditeur favori, /etc/init.d/bind et changez les lignes commençant par
start-stop-daemon --start
en
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
Tout ce dont vous avez besoin est de redémarrer bind à l'aide de '/etc/init.d/bind restart' puis rechercher dans votre syslog les deux entrées suivantes :
Sep 4 15:11:08 nexus named[13439]: group = named Sep 4 15:11:08 nexus named[13439]: user = named
Voilà! Maintenant votre named ne s'exécute plus en tant que root. Pour
atteindre une sécurité de BIND maximale, construisez mantenant une prison
chroot (voir Utilisation de chroot, Section
4.9) autour de votre daemon. Il y a un moyen facile de faire cela:
l'option -t (voyez la page de manuel named(8)
). Cela
fera que Bind se chrootera lui-même dans le répertoire donné sans que vous ayez
besoin de configurer une prison chroot et de vous inquiéter au sujet des
librairies dynamiques. Les seuls fichiers qui doivent être dans cette prison
chroot:
dev/null etc/bind/ - doit contenir named.conf et toutes les zones du serveur. sbin/named-xfer - si vous faites du transfert de nom var/run/named/ - devrait contenir le pid et le cache du serveur de nom (si il existe) ce répertoire doit être inscriptible par l'utilisateur named var/log/named - si vous configurez le log vers un fichier, doit être inscriptible par l'utilisateur named dev/log - syslogd devrait écouter ici si named est configuré pour loguer grace à lui
Pour que votre daemon Bind fonctionne correctement il a besoin de permissions dans les fichiers named. C'est une tâche facile car les fichiers de configuration sont toujours dans /etc/named. Tenez compte qu'il nécessite seulement un accès en lecture seule aux fichiers de zone, à moins qu'il ne soit un serveur de nom secondaire ou serveur cache. Si c'est votre cas vous aurez à donner les permissions en lecture-écriture aux zones nécessaires (pour que le transfert de zone à partir du serveur primaire marche).
Si vous voulez lire plus d'informations expliquant pourquoi BIND ne s'exécute
pas en tant qu'utilisateur non-root sur les systèmes Debian, veuillez, s'il
vous plaît, consulter le Bug Tracking System au sujet de Bind, spécifiquement
Bug #50013: bind should not run as
root
.
De plus, vous pouvez trouver plus d'informations concernant le chrootage de
Bind dans le Chroot-BIND-HOWTO
(Au sujet de Bind 9) et Chroot-BIND8-HOWTO
(Au sujet de Bind 8). Ces mêmes documents devraient être disponibles par
l'installation de doc-linux-text
(version texte) ou
doc-linux-html
(version html).
Si vous configurez une véritable prison chroot (i.e. pas juste l'option -t) pour Bind 8.2.3 dans la Debian (potato), assurez vous qu'elle contient les fichiers suivants:
dev/log - syslogd devrait écouter ici dev/null etc/bind/named.conf etc/localtime etc/group - avec une seule ligne: "named:x:GID:" etc/ld.so.cache - généré avec ldconfig lib/ld-2.1.3.so lib/libc-2.1.3.so lib/ld-linux.so.2 - lié symboliquement à ld-2.1.3.so lib/libc.so.6 - lié symboliquement à libc-2.1.3.so sbin/ldconfig - pourra être effacé après la configuration du chroot sbin/named-xfer - si vous faites des transferts de nom var/run/
FIXME, inclure les infos provenant de http://www.cryptio.net/~ferlatte/config/
(spécifique à la Debian) et http://www.psionic.com/papers/whitep01.html
.
FIXME. Ajout de contenu.
Vous pouvez limiter l'accès au serveur Apache si vous voulez uniquement
l'utiliser en interne (dans un but d'essai, pour accéder à l'archive
doc-central
, etc..) et ne pas vouloir que des intrus y accèdent.
Pour réaliser cela, utilisez les directives Listen ou
BindAddress dans /etc/apache/http.conf
.
Using Listen:
Listen 127.0.0.1:80
Using BindAddress:
BindAddress 127.0.0.1
Ensuite, redémarrez apache avec /etc/init.d/apache restart et vous observerez qu'il écoute uniquement l'interface loopback.
Dans tous les cas, si vous n'utilisez pas toutes les fonctionnalités fournies
par Apache, vous pouvez jeter un oeil aux autres serveurs web fourni dans
Debian tel dhttpd
.
La Documentation
Apache
fournit des informations concernant les mesures de sécurité à
prendre pour les serveurs web Apache (ces mêmes informations sont fournies dans
Debian par le paquet apache-doc
).
Si vous désirez utiliser le service finger, demandez-vous si vous en avez
réellement besoin. Si oui, vous découvrirez que Debian fourni de nombreux
daemons finger (output d'un apt-cache search fingerd
):
ffingerd
est le daemon finger recommandé si vous comptez
l'utiliser pour un service public. Dans tous les cas, vous êtes encouragé,
lors de la mise en place via inetd, xinetd ou tcpserver à: limiter le nombre de
processus qui seront lancés en même temps, limiter les accès au daemon finger
depuis un nombre donné d'hôtes (en utilisant tcp wrappers) et de l'avoir en
écoute uniquement sur une interface bien définie.
Il est probablement juste de dire que la complexité de BIND est la raison pour laquelle il a été exposé à de nombreuses attaques ces dernières années. (voir Sécurisation de BIND, Section 5.8)
D'autres programmes avec des fonctionnalités complexes et une large base d'utilisateurs incluent Sendmail et quelques daemon ftp (e.g. WUftpd). (Bien sûr un programme avec aucune fonctionnalité et pas de clients satisfaits peut être aussi peu sûr, outre le fait qu'il est inutile.)
Dans tous les cas, si vous exécutez un de ces programmes, considérez des mesures semblables à leur encontre — annuler les privilèges root, s'exécuter dans une prison chroot — ou les remplacer par des équivalents plus sûrs.
Vous devriez essayer d'éviter tout service réseau qui envoie et reçoit des mots de passe en texte clair par le net comme FTP/Telnet/NIS/RPC. L'auteur recommande l'utilisation de ssh à la place de telnet et ftp pour tout le monde.
Gardez à l'esprit que la migration de telnet vers ssh, en perpétuant l'utilisation d'autres protocoles à texte non chiffrés n'augmente votre sécurité en AUCUNE manière! Le mieux serait de retirer ftp, telnet, pop, imap, http et de les remplacer par leurs services cryptés respectifs. Vous devriez considérer la mise à jour de ces services à leurs versions SSL, ftp-ssl, telnet-ssl, pop-ssl, https...
La plupart des astuces ci-dessus s'appliquent à tout système Unix (vous les trouverez dans des documents de durcissement liés à Linux et autres Unix).
Vous ne devriez pas utiliser NIS, le Service d'Information Réseau (Network Information Service), si possible car il autorise le partage de mot de passe. Ceci peut être fortement dangereux si l'installation est cassée.
Si vous avez besoin de partager les mots de passe entre machines, pensez à
d'autres alternatives. Par exemple, mettre en place un serveur LDAP et
configurer PAM sur votre système afin de contacter le serveur LDAP pour
l'authentification des utilisateurs. Une installation détaillée est disponible
sur LDAP-HOWTO
(/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz
).
Informations supplémentaires sur la sécurité de NIS à l'adresse suivante
NIS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz
).
FIXME (jfs) : Ajouter des infos sur comment configurer cela dans la Debian
Vous devriez désactiver RPC quand c'est possible. De nombreuses failles de
sécurité pour ce service sont connues et peuvent être facilement exploitées.
D'un autre côté les services NFS sont assez importants dans certains réseaux,
trouvez donc le juste équilibre entre sécurité et facilité d'utilisation sur
votre réseau. La plupart des attaques DDos (Distributed Denial of Service ou
déni de service distribué) utilisent des exploits rpc pour s'introduire dans le
système et y agir comme agent/gestionnaire. Lisez en plus sur la sécurité de
NFS dans NFS-HOWTO
(/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz
).
La désactivation de portmap est assez simple. Il y a différentes méthodes. La
plus simple sur un système Debian 3.0 est de désinstaller le paquetage
portmap
. Si vous exécutez une autre version vous devrez
désactiver le service comme expliqué dans Désactivation de services daemon, Section
3.6.1, cela est dû au fait que le programme fait partie du paquetage
net-base
(qui ne peut être desinstallé sans endommager le
système).
Cela enlève en fait tous les liens symboliques relatifs au portmap dans
/etc/rc${runlevel}.d/, qui est aussi quelque chose que vous
pourriez faire manuellement. Une autre possibilité est de faire chmod
644 /etc/init.d/portmap, mais cela produit un message d'erreur lors du
démarrage. Vous pouvez aussi enlever la partie start-stop-daemon
du script shell /etc/init.d/portmap
.
Le système d'exploitation Debian GNU/Linux possède les capacités intégrées
fournies par le noyau Linux. Cela signifie que si vous installez un système
potato (Debian version 2.2, le noyau par défaut est le 2.2) vous aurez la
fonctionnalité pare-feu ipchains
disponible dans le noyau, vous
avez à installer le paquetage ipchains
qui sera sûrement déjà (de
part sa priorité) installé. Si vous installez un système woody (Debian version
3.0, le noyau par défaut est le 2.4) vous aurez la fonctionnalité pare-feu
iptables
(neftfilter) disponible.
Certains utilisateurs peuvent aussi bien vouloir ajouter des règles de pare-feu
dans ce script. Cependant, vérifiez quels programmes/composants pare-feu vous
voulez utiliser puisqu'ils peuvent modifier d'autres fichiers et changer les
définitions que vous avez ajouté au démarrage. Par exemple,
firewalk>, pour n'en citer qu'un, utilisera un autre fichier de
configuration pour configurer le pare-feu.
Si vous utilisez Debian 3.0, vous noterez que vous disposez du paquet
iptables
. Ceci est le support pour l'implémentation de netfilter
des noyaux 2.4.4+. Juste après l'installation, le système ne peut
connaître les règles du pare-feu (celles-ci sont spécifiques à chaque
système) et vous devez activer iptables.
De manière à réaliser ceci, vous devez :
/etc/default/iptables
ainsi la variable
enable_iptables_initd est mise à true
iptables(8)
) ou un des outils
fournit par les paquetages pare-feu Debian (voir Paquets pare-feu, Section 5.15.4). Vous devez
creer un jeu de règles du pare-feu pour les utiliser quand le pare-feu est en
état actif et un autre lorsque le pare-feu est en état
inactif (Ceux peuvent être juste des règles vides).
Une fois ceci fait l'installation de votre pare-feu est sauvegardée dans le
répertoire /var/lib/iptables/
et sera exécutée quand le système
démarrera (ou lorsque le script initd sera lancé avec les arguments
start et stop). Notez que l'installation par défaut de
Debian démarre le pare-feu dans le niveau d'exécution multi-utilisateurs (2 à
5) bientôt (10). De plus, il est arrêté en mode mono-utilisateur (1), changez
ceci si cela ne correspond pas à votre politique.
Soyez avertis que certains des paquetages passés en revue ci-dessous pourraient amener des scripts pare-feux à être exécuter quand le système démarre, cela va indubitablement entrer en conflit avec la configuration courante et vous pourriez avoir des effets indésirables. Consultez la documentation du paquetage et utilisez l'une de ces configurations.
Si vous n'avez aucun renseignement sur la manière d'organiser vos règles de
filtrage pour votre pare-feu, consulter le Packet Filtering HOWTO
fourni par iptables
pour une consultation hors-ligne sous
/usr/share/doc/iptables/html/
.
Vous pouvez utiliser des règles de pare-feu tel une manière de sécuriser l'accès à votre système local et, même, de limiter les connexions extérieures<--!outband a traduire--> produites par celles-ci. Des règles de pare-feux peuvent être également utilisées pour protéger des processus qui ne peuvent être proprement configurés pour fournir certains services à certains réseaux, certaines adresses IP, etc ...
Toutefois, cette étape est présentée en dernier dans ce manuel car il est beaucoup mieux de ne pas dépendre exclusivement des capacités d'un pare-feu de façon à protéger un système donné. La sécurité dans un système est faites de couches, le filtrage devrait être la dernière, une fois que tous les services ont été renforcés. Vous pouvez facilement imaginer une installation dans laquelle le système est uniquement protégé par le pare-feu et que l'administrateur enlève bêtement les règles pour n'importe quelle raison (problèmes avec l'installation, exaspération, erreur humaine, ...), ce système pourrait être grand ouvert à une attaque.
Un pare-feu Debian peut aussi être installé de façon à protéger, selon des règles de filtrage, l'accès aux systèmes derrière lui, limitant leur exposition à Internet.
Vous pouvez même installer une bécane Debian GNU/Linux en tant que pont pare-feux, c'est-à-dire un pare-feu filtrant complètement transparent pour le réseau qui est dépourvu d'adresse IP et donc ne peut pas être attaqué directement.
Si vous ne connaissez pas grand chose aux pare-feux, vous pouvez lire le
Firewalling-HOWTO qui se trouve dans le paquet doc-linux-text
(d'autres formats de document sont également disponibles). Voir Être conscient des problèmes de sécurité,
Section 2.2 pour plus de pointeurs.
Il existe plusieurs logiciels qui peuvent être utilisés pour configurer des règles de pare-feux dans un système Debian :
fwbuilder
mason
, qui peut suggérer des règles de pare-feux basé sur le
traffic réseau que votre réseau "voit".
bastille
(parmi les étapes de durcissement qui constituent les
nouvelles versions de bastille, une d'entre-elles est l'ajout de règles de
pare-feux exécutable au démarrage du système).
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
knetfilter
firestarter
Les derniers paquets : gfcc,firestarter et knetfilter sont des GUIs pour administration qui utilisent soit GNOME (le premier des deux) soit KDE (le dernier) qui sont plus orienté utilisateur (c'est-à-dire utilisation "familiale") tandis que les autres paquets de la liste sont plus orientés administrateur.
FIXME: Ajouter plus d'informations concernant ces paquets
FIXME: Vérifier les informations sur les pare-feux Debian et quoi/comment cela change sur les autres distributions.
FIXME: A quel endroit la personnalisation du pare-feu peut elle être activée (FAQ générale dans debian-firewall?)
Securing Debian Manual
2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100jfs@computer.org