Ce document est issu de mes expériences sur le sujet. Mon but n'est pas de rédiger une documentation de référence, mais de pouvoir aider toute personne voulant monter son firewall sous GNU/Linux et Debian.
Pour toute suggestion, ou demande d'aide : lehmann@free.fr
Document en version 0.4 du 16/09/2003.
Insérer le CD 1 dans le lecteur, et booter dessus (l'installation décrite ici s'effectue essentiellement avec les CDROMs de la Debian que l'utilisateur devra avoir en sa possession). Lorsque le système nous donne la main, taper bf24. Ensuite laisser faire jusqu'à ce qu'un menu pseudo-graphique nous soit affiché.
Je ne vais pas ici détailler toute l'installation. J'indiquerai juste quelques détails qui diffèreront de l'installation classique.
Le partitionnement : Il est nécessaire de distinguer les partitions suivantes (les tailles sont données à titre d'exemple) :
/ (1000 Mo)
/boot (50 Mo)
/usr (1000 Mo)
/var (2000 Mo voir plus)
/home (300 Mo)
/sauv (cette partition servira à stocker une sauvegarde du système. Elle n'est cependant pas indispensable) (700 Mo)
la partition de swap (200 Mo)
Les paramètres réseaux de la machines seront :
Hostname : firewall
Adresse IP internet (eth0) : 194.170.50.1/24 (à adapter biensûr suivant son cas)
Adresse IP LAN (eth1) : 192.168.0.1/24
Passerelle : 194.170.50.10 (à adapter suivant son cas)
Nom de domaine : (laisser vide, ou à adapter suivant son cas)
Activer le cryptage md5 des mots de passe.
Utiliser les mots de passe cachés (shadow).
Faites un choix judicieux pour le mot de passe du root (mot de passe long et mélangeant divers caractères ASCII, sans logique).
Créer un compte utilisateur dont le choix du mot de passe sera aussi judicieux que pour le root... mais sans que ce soit le même mot de passe !
Utiliser les mises à jour depuis le site security.debian.org.
N'utiliser ni RunTaskSel ni dselect pendant l'installation.
Pas de configuration de service mail.
De tous les paquetages installés, nous allons maintenant désinstaller ceux qui nous sont inutiles :
apt-get 
purge remove bc biff bind9-host dnsutils cpp-3.0 gcc-3.0 dhcp-client doc-debian doc-linux-text fdutils finger flex ftp gnupg gnupg-doc iamerican ibritish ipchains ipmasqadm ispell libdns5 libisc4 libnss-db libpcap0 lpr pppoeconf pppoe pppconfig ppp libpng2 lynx man-db manpages manpages-dev mpack mtools mtr-tiny mutt nano nfs-common nfs-kernel-server nvi pidentd portmap procmail python python-newt python2.1 reportbug setserial sharutils tcsh telnet texinfo time vacation wenglish whois
Pour effectuer cette mise à jour, il faut éditer le fichier /etc/apt/sources.list qui ne devra contenir que les lignes suivantes :
deb http://ftp.info.iut-tlse3.fr/debian stable main contrib deb http://ftp.info.iut-tlse3.fr/debian-non-US stable/non-US main contrib deb http://security.debian.org/ stable/updates main
Ensuite taper les commandes suivantes :
apt-get update
apt-get -f fix-missing fix-broken dist-upgrade
Installer les programmes suivant qui nous seront utiles ensuite (accepter d'installer les paquetages dont ils dépendent) :
Si on veut installer cette fonctionnalité indépendante du filtrage:
Si on veut faire des VPN avec IPSec:
Décompresser les sources du noyau dans le répertoire /usr/src/ et créer un lien symbolique de /usr/src/linux vers le répertoire contenant les sources de Linux.
cd /usr/src/linux
make -C /usr/src/kernel-patches/all/freeswan -f Makefile insert KERNELSRC=/usr/src/linux PATCHER=/usr/src/kernel-patches/all/freeswan/patcher
Afin de sécuriser un maximum la machine, nous patcherons le noyau pour protéger le système (espace utilisateur et espace noyau) des buffers overflows. Ainsi, les effets des rootkits voulant exploiter une faille du système, seront inhibés. Pour appliquer le patch PaX, télécharger le patch pour le noyau 2.4.x choisi (au moment de la rédaction, pour le noyau 2.4.20, le patch se nomme pax-linux-2.4.20-200304191922.patch) sur le site http://pageexec.virtualave.net, et le placer dans le répertoire /usr/src/ . Ensuite, tapez les commandes suivantes :
cd /usr/src/linux
patch -p1 < ../pax-linux-2.4.20-200304191922.patch
Attention : Nous avons pris ici l'exemple d'un patch Pax pour le noyau 2.4.20. Si vous avez utilisé les sources de Linux fournies avec la distribution (2.4.18), vous devrez vous procurer le patch noyau pour cette version là du noyau.
Il faut activer les options suivantes :
Il faut désactiver les options suivantes :
Une fois le noyau configuré, ainsi que tous les patchs que l'on aura appliqués (voir ci-dessous), déplacer le noyau créé dans la partition /boot. Configuer lilo pour que l'on puisse démarrer sur ce nouveau noyau (que nous nommerons LinFirewall). Penser à relancer lilo pour que les changements soient pris en compte lors du prochain redémarrage.
Une fois les sources décompressées, se placer dans le répertoire et taper les commandes suivantes :
make
make install
Pour pouvoir accéder directement à la commande iptables, il faudra déplacer le fichier iptables créé par la compilation dans le répertoire /sbin.
Penser à effacer le répertoire où se trouvent les sources de iptables afin que personne d'autre ne puisse recompiler le programme.
Ne pas utiliser le mot clef timeout.
Ne pas utiliser le mot clef prompt.
Le mot clef default doit avoir pour valeur le nom de notre noyau le plus sécurisé.
Utiliser le mot clef password pour protéger les images du noyau à l'aide d'un mot de passe, ainsi que le processus d'amorçage en général.
Utiliser le mot clef restricted pour assurer une protection des images par mot de passe. Si aucun argument n'est fourni, le système démarre automatiquement. Dans le cas contraire, il demande un mot de passe (voir l'option password ci-dessus) avant d'aller plus loin.
Tous les menus des autres noyaux doivent être mis en commentaires afin que l'on ne puisse, au cas où l'on aurait le choix, démarrer un autre noyau. Tout démarrage sur une disquette, cdrom ou autres doit aussi être mis en commentaire.
Exemple de menu de noyau :
lba32
boot=/dev/hdc1
install=/boot/boot.b
map=/boot/System.map
delay=00
vga=normal
# prompt
# timetout=0
default=JoliNoyau
password="Ayg5hj1PjP58"
image=/boot/vmlinuz
label=JoliNoyau
root=/dev/hdc2
restricted
read-only
Changer les droits du fichier de configuration :
chmod 400 /etc/lilo.conf
Dans /etc/lilo.conf, on peut ensuite modifier le fichier pour enlever le mot de passe et y mettre une ligne qui va sortir une erreur si on relance lilo :
password=Rentrer un nouveau mot de passe
lilo étant lancé avant, il a enregistré le bon mot de passe, et la modification du fichier que l'on vient de décrire ne l'affectera pas. Ainsi, si une personne arrive à lire le fichier, elle ne pourra pas connaître le mot de passe actuellement actif. C'est une protection supplémentaire qui ne devrait pas retardé beaucoup un pirate si ce dernier est déjà arrivé à lire le fichier dont on avait autorisé la lecture que pour le root.
S20inetd et S20exim sont à supprimer. Suivant l'utilisation que l'on peut en faire, on va aussi supprimer ou garder S89atd et S89cron
Ce qui suit n'est pas propre au firewall, mais si vous êtes un paranoïaque profond qui ne fait même pas confiance à son poisson rouge pour garder un secret, et encore moins à ce nouveau firewall, alors vous pouvez toujours appliquer ce qui suit à votre firewall ;-)
ca:12345:ctrlaltdel:/bin/shutdown -t1 -a -r now
Une chose aussi à laquelle on ne pense pas toujours, est de surveiller le niveau d'exécution par défaut. Cela se définit dans le fichier /etc/inittab :
id:5:initdefault # pour démarrer au niveau 5 id:3:initdefault # pour démarrer au niveau 3 # et ainsi de suite pour le niveau de démarrage par défaut.
En général, on n'a pas besoin de l'interface X sur le serveur et on préfèrera passer par le mode console. On utilisera alors le niveau d'exécution 3 (ou 2 selon les distributions, comme Debian) : système multi-utilisateur sans interface graphique, mais avec tous les services réseaux activés.
Pour l'entretien du serveur, il vaut mieux utiliser le niveau d'exécution 1 : système mono-utilisateur (root) et minimal.
Sous Linux, l'utilisation de nombreuses consoles est très pratique, mais il arrive qu'on utilise 3 ou 4 consoles, et que lorsqu'on a fini, on oublie de se déconnecter de toutes. Une façon d'éviter cela est de limiter le nombre de consoles disponibles suivant les modes. Un exemple commenté de ces quelques lignes du fichier /etc/inittab expliquera bien la façon de faire :
# Disponibilité de la console 1, pour les niveaux #d'execution 2, 3, 4 et 5, en utilisant le programme # (pour gérer la fenêtre) /sbin/getty, sur le #périphérique de sortie /dev/tty1. 1:2345:respawn:/sbin/getty 38400 tty1
# Disponibilité de la console 2, pour les niveaux # d'execution 2 et 3, en utilisant le programme # (pour gérer la fenêtre) /sbin/getty, sur le # périphérique de sortie /dev/tty2. 2:23:respawn:/sbin/getty 38400 tty2
# Disponibilité de la console 3, pour le niveau # d'execution 2 seulement, en utilisant le programme # (pour gérer la fenêtre) /sbin/getty, sur le périphérique # de sortie /dev/tty3. 3:2:respawn:/sbin/getty 38400 tty3
# Non-disponibilité des consoles 4, 5 et 6. # 4:23:respawn:/sbin/getty 38400 tty4 # 5:23:respawn:/sbin/getty 38400 tty5 # 6:23:respawn:/sbin/getty 38400 tty6
SSH présente, comme on aurait pu s'en douter, une architecture client-serveur. Dans notre cas, le firewall devra pouvoir accepter les connexions distantes, il faudra donc qu'il héberge la partie serveur, et qu'elle soit activée.
Pour installer SSH, c'est très simple :
apt-get install ssh
Accepter tous les paquetages dont dépend ssh. Puis pour lancer le serveur, il suffit de taper, toujours en tant que root :
/usr/sbin/sshd
ou, pour être conforme à Debian :
/etc/init.d/ssh restart
Ssh peut aussi gérer l'affichage déporté de X11. Mais si on désire utiliser X11 sans ssh, cela est trés simple (mais bien moins sécurisé!). Pour lancer l'AFFICHAGE d'une application (ici emacs) sur un autre poste, il suffit d'utiliser l'option display comme suit :
emacs display 192.168.2.6:0
L'affichage sera déporté sur le serveur 0.0 (souvent, il n'y a que celui-ci d'activé) du poste 192.168.2.6 .
Ainsi, on peut prendre le contrôle à distance du firewall, et utiliser les aplicatifs qui y sont installés, pour déporter l'affichage sur notre machine et travailler ainsi à distance avec une interface graphique. On a ainsi tout le confort pour la manipulation du firewall, tout en laissant le firewall dans un endroit fermé, protecteur matériellement.
Nous allons maintenant nous pencher plus spécialement sur la sécurité du serveur ssh. Nous éditons le fichier de configuration /etc/ssh/sshd_config :
Port 22 # Dans le cas où 1.2.3.4 est l'unique adresse à #laquelle on doit pouvoir accéder à sshd. ListenAdress 1.2.3.4 # Seul la version 2 du protocole est autorisée. Protocol 2 HostbasedAuthentication no HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_rsa_key IgnoreRhosts yes IgnoreUserKnownHosts yes KeepAlive yes LoginGraceTime 120 LogLevel INFO MaxStartups 10:30:60 PasswordAuthentication yes PermitEmptyPasswords no # Attention, une connexion directe en root sera rejettée. PermitRootLogin no PrintLastLog yes PrintMotd no PubkeyAuthentication yes RhostsRSAAuthentication no RSAAuthentication yes StrictModes yes # Subsystem sftp /usr/lib/sftp-server SyslogFacility AUTH # UseLogin no UsePrivilegeSeparation yes X11DisplayOffset 10 # Si on veut transférer du X11 à travers ssh, il faudra indiquer yes. X11Forwarding no
Le fonctionnement de la journalisation repose sur un journal. On découpe en plusieurs étapes l'écriture des données sur le disque. Chaque étape est atomique c'est-à-dire quelle se poursuivra même si votre disque dur prend feu, que vous avez coupé le courant ou que votre poisson rouge s'est noyé. La journalisation a pour but de maintenir en permanence la cohérence des métadonnées. Après un crash, le système va relire le journal, examiner les transactions non terminées, et remettre un système de fichier sain en quelques secondes. En revanche, la journalisation n'assure pas toujours le contenu des fichiers eux-même (ext3 oui, dans le mode data=ordered). Voici un exemple de fonctionnement de la journalisaton (mode data=ordered de ext3) : Les métadonnées sont d'abord écrites dans le journal, ensuite sur le disque. S'il y a un crash au moment de l'écriture dans le journal, on dispose toujours des anciennes données. En cas de crash a moment de la reécriture des données sur le disque dur, on dispose des anciennes données et des nouvelles métadonnées. On peut alors "reconstruire" les nouvelles données qui n'avaient pas eu le temps d'être écrites sur le disque dur.
Etant donné que Linux repose sur ext2, je conseille ext3 qui est en fait ext2 + journal. La mise en place de ext3 peut se faire sur un disque dur formaté en ext2 sans pertes de données.
Pour ce qui est de la pratique, passer en tant qu'utilisateur root. Si c'est la partition /dev/hda3 que nous voulons passer de ext2 à ext3 :
tune2fs -J /dev/hda3
Il faut maintenant que ces changements soient pris en compte dans le fichier /etc/fstab. Pour cela, on doit passer d'une ligne du type :
/dev/hda3 /usr ext2 defaults 0 2
à une ligne du type :
/dev/hda3 /usr auto defaults 0 2
A la place de auto, on peut écrire ext3. Mais l'avantage du flag auto est que si le noyau ne reconnaît pas le format ext3, ou qu'il y a une erreur, la partition sera montée en ext2, et donc tout de même accessible.
Nous allons ici expliquer comment modifier l'arborescence des répertoires afin de mieux sécuriser le poste de travail.
Les fichiers binaires se trouvent dans les répertoires /bin et /sbin. Il y a aussi des fichiers de commandes dans les répertoires /usr/bin et /usr/sbin.
Il ne faut pas que ces binaires soient modifiables. Pour cela, ils seront placés sur une partition en lecture seule. Ensuite un lien symbolique (ln -s) sera défini.
La partition root (/) doit être en lecture seule (en fait, une fois le système démarré, la partition racine est remontée en lecture seule). C'est donc dans cette partition que seront transférés les binaires en tapant les commandes suivantes :
mkdir /sbinu cp -dpR /usr/sbin/* /sbinu rm -rf /usr/sbin ln -s /sbinu /usr/sbin
mkdir /binu cp -dpR /usr/bin/* /binu rm -rf /usr/bin ln -s /binu /usr/bin
On considère ici que le disque considéré est /dev/hda. Si ce n'est pas le cas, adapter la syntaxe.
Disque dur en mode 32 bits classique OU disque dur en mode 32 bits avec une séquence spéciale de synchronisation, requis par de nombreux chipset.
hdparm -c 1 /dev/hda OU hdparm -c 3 /dev/hda
Passage en mode UDMA.
hdparm -d 1 /dev/hda
Activer le mode multisecteur. Faire des tests pour savoir quelle est la meilleure valeur X (4, 8, 16, 32).
hdparm -m X /dev/hda
Pour tester les accès en lecture/écriture, on a le choix entre 2 commandes :
hdparm -t /dev/hda hdparm -T /dev/hda en 16 bits : ==> 3.62 MB/sec ==> 193.94 MB/sec en 32 bites : ==> 5.25 MB/sec ==> 196.92 MB/sec en 32 bits et UDMA : ==> 21.12 MB/sec ==> 196.92 MB/sec en 32 bits et UDMA et mode multisecteur à 2 : ==> 21.19 MB/sec ==> 200 MB/sec en 32 bits et UDMA et mode multisecteur à 4 : ==> 21.12 MB/sec ==> 200 MB/sec en 32 bits et UDMA et mode multisecteur à 8 : ==> 21.05 MB/sec ==> 196.92 MB/sec en 32 bits et UDMA et mode multisecteur à 16 : ==> 21.12 MB/sec ==> 200 MB/sec
Si le programme bash est lancé non pas à la connexion d'un utilisateur, mais, par exemple, depuis un autre interpréteur de commande, ou pour le root en passant pas l'utilisation de la commande su, ce n'est pas le fichier /etc/profile qui est traité mais uniquement le fichier .bashrc dans le répertoire home du nouvel utilisateur.
Si le fichier .bashrc n'est pas dans le répertoire de l'utilisateur, c'est alors le fichier /etc/profile qui est recherché, lu et traité.
Pour sécuriser le shell, on peut placer des alias à la place de commandes que l'on veut interdire. Par exemple, si on veut interdire l'utilisation de la commande diff, on peut mettre la ligne suivante dans le /etc/profile (attention, même le root ne pourra pas l'utiliser sauf s'il redéfinit l'alias dans son propre .bashrc) :
alias diff='TuTuT'
Il faut aussi bien configurer la variable PATH qui donne le chemin des exécutables :
PATH="/usr/bin:/usr/sbin"
En ce qui concerne les droits des répertoires et des fichiers, bien positionner le umask dans le fichier /etc/profile :
umask 022
ou
umask 066
On peut aussi vouloir replacer les droits des utilisateurs. Cela peut éviter de laisser un trou de sécurité causé par des droits mal configurés par l'utilisateur. On désactive aussi les bits suid et guid (si la partition /home est montée avec l'option nosuid, l'activation des bits suid ou guid ne devrait pas poser de problème). Sinon, il faut rajouter la ligne suivante dans le fichier .bash_logout du répertoire de l'utilisateur :
chmod -R 0600 ~/
Cette ligne devra aussi être rajoutée dans le fichier /etc/skel.
Nous désirons que l'écran soit effacé lorsqu'un utilisateur quitte le shell afin que l'on ne puisse pas voir les commandes tapées, ou les dernières actions effectuées. Pour cela, l'utilisateur doit avoir dans son home directory un fichier .bash_logout qui contiendra la ligne suivante :
/usr/bin/clear
Ce fichier pourra être ajouté dans /etc/skel afin qu'il soit automatiquement copié dans le home directory de tout nouvel utilisateur.
Ensuite, pour éviter la diversification des shells utilisés sur le système (et donc la difficulté de bien administrer le tout), on va limiter le nombre de shells utilisable à un seul. Pour cela, le fichier /etc/shells ne devra comporter qu'une seule ligne. Ci-dessous un exemple de fichier /etc/shells, où le shell choisi est bash :
# /etc/shells: valid login shells /bin/bash
Ci-dessous un fichier /etc/fstab sécurisé :
# /etc/fstab: static file system information. # #<file system><mount point><type><options> <dump><pass> /dev/hda6 / ext2 defaults,errors=remount-ro 0 1 /dev/hda3 none swap sw 0 0 proc /proc proc defaults 0 0 #/dev/fd0 /floppy auto user,noauto 0 0 #/dev/cdrom /cdrom iso9660 ro,user,noauto 0 0 /dev/hda5 /boot ext2 nosuid,ro,noauto 0 2 /dev/hda7 /usr ext2 nosuid 0 2 /dev/hda8 /var ext2 nosuid 0 2 /dev/hda9 /home ext2 noexec 0 2
Nous pouvons observer que la partition root (/) a pour option defaults et qu'en cas d'erreur, elle est montée en lecture seule (errors=remount-ro).
Les lecteurs de disquettes et de CD-ROM ne sont pas accessibles.
La partition /boot est en lecture seule et les bits suid ne sont pas exécutés. Par défaut, cette partition n'est pas montée.
La partition /var n'exécute pas le bit suid d'un programme ayant ce bit activé.
La partition /home n'autorise pas l'exécution de programmes (donc pas de bits suid non plus).
Si on utilise un système de fichier journalisé, il faut aussi le prendre en compte ici.
/etc/inetd.conf /etc/services /etc/protocols /etc/hosts /etc/hosts.deny /etc/hosts.allow /etc/hostname
Nous allons maintenant voir en détail chaque fichier.
ALL: PARANOID
Voici un exemple des valeurs de ces options :
ip_forward=yes spoofprotect=yes syncookies=yes
# /etc/securetty: list of terminals on which root is allowed to login. # See securetty(5) and login(1). tty1 tty2 tty5 tty6 tty7
Nous voyons ici que l'utilisateur root ne peut se connecter directement que sur les consoles tty1, tty2, tty5, tty6, et tty7. Moins il y aura de consoles sur lesquelles l'utilisateur root pourra se connecter, mieux ce sera.
Si le fichier est vide, l'utilisateur root ne pourra pas se connecter directement à une console. Il faudra passer par le profil d'un utilisateur normal et ensuite basculer sous le profil root à l'aide de la commande su : pour accéder au profil root on a donc besoin de connaître 2 mots de passe.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 InstallFirewall.tex
The translation was initiated by Lehmann Guillaume on 2003-09-20