Par Chris Stoddard cstod@vvm.com
Dans mon dernier article, nous avons installé Linux avec uniquement les paquetages dont nous avions absolument besoin. (Si vous n'avez pas lu mon article précédent vous devriez le faire maintenant car c'est sur lui qu'est basée celui-ci.). Viens maintenant le boulot détaillé qui consiste à transformer votre passerelle en forteresse. La première chose à garder à l'esprit est qu'il n y a aucun moyen de s'assurer une sécurité infaillible. On n'aura jamais le temps de tout mettre en oeuvre. Des compagnies emploient de gros département TI dont l'unique but toute leur vie durant est de garantir la sécurité de leurs réseaux, et pourtant, cela ne les empêche pas d'être crackés. Acceptez cela et vivez avec. Notre unique objectif dans cet article est de garder les honnêtes gens honnêtes, éloigner les " Script Kiddies " et ralentir les autres tentatives pour vous donner le temps de les débusquer. En principe cela devrait être le cas après une installation propre, bien avant que le système soit mis sur Internet. Cet article suppose que vous disposez de rudiments Linux, comment l'installer, comment éditer les divers fichiers de configuration et que vous pouvez vous signer en tant que root. Je suppose également que vous installez un système coupe-feu et que vous n'avez nullement l'intention de fournir des services tels que DNS, DHCP, web, ftp ou telnet. Si vous prévoyez offrir l'un de ces services, je vous suggère de le faire sur une autre machine. Mettez en oeuvre une DMZ (zone démilitarisée) dans votre réseau, un système qui reste sûr tout en permettant une connexion à votre réseau de l'extérieur. Ainsi si un intrus atteint votre serveur, il devra recommencer à zéro pour attaquer votre coupe-feu dans l'espoir que vous l'aurez découvert avant qu'il n'ait eut accès à votre réseau interne.
Dans l'univers de la sécurité des ordinateurs, la connaissance c'est le pouvoir. En toute franchise, les crackers ont toujours une longueur d'avance sur les experts en sécurité, la plupart des problèmes de sécurité ne sont pas débusqués par les experts mais plutôt par les crackers et ne sont corrigés qu'après qu'ils aient été exploités. Vous devez être informés des nouveaux problèmes, tout au moins vous devrez faire la mise à jour des paquetages au fur et à mesure qu'ils sont publiés. Tapez " rpm -qa > paquetages.txt ", cela vous donnera une liste des paquetages installés sur votre systèmes ainsi que leurs version, rendez-vous alors sur le site de RedHat et téléchargez les mise à jour de ces paquetages. Pendant que vous y êtes, vous devriez lire les consignes de sécurité et mettre en oeuvre toute suggestion émise. Si vous aimez prendre les choses en main, abonnez-vous aux listes de diffusion BugTraq et CERT.
Puisque cet article est destiné à l'utilisateur d'un modem modem câble domestique, je vais supposer que le problème de la sécurité physique ne se pose pas. Si vous avez un môme ou un une baby sitter curieuse, pensez à utiliser le mot de passe BIOS disponibles sur la plupart des ordinateurs modernes.
A côté du compte root et des comptes spéciaux, dont je parlerais dans un moment, il ne doit y avoir qu'un seul compte. Les comptes des utilisateurs lambda et celui de root doivent avoir de bons mots de passe. Un bon mot de passe doit être constitué d'au moins 8 caractères avec un mélange de minuscules, majuscules et chiffres, il ne doit pas être un mot du dictionnaire. C'est aussi une excellente idée de changer ces mots de passe de temps en temps et n'inscrivez surtout pas votre mot de passe sur un stick collé au moniteur de votre ordinateur visible par tous. Utiliser un mot de passe différent suivant les machines de votre réseau, ainsi si un système est cracké, l'intrus n'aura pas un accès systématique aux autres machines du réseau. Encore une fois, nous espérons que vous aurez le temps de démasquer le crackeur avant qu'il ne fasse trop de dégâts dans la mesure où casser un mot de passe prend du temps. Dans cet ordre d'idées, il y a plusieurs comptes à usage spécial ajoutés par défaut par plusieurs distributions Linux, dans notre cas ces comptes sont inutiles et représentent de sérieux risques, donc nous allons les supprimer en utilisant la commande userdel. Le synopsis de cette commande est " userdel nomUtilisateur ", en remplaçant nomUtilisateur par le compte approprié. Les comptes que nous voulons supprimer sont : adm, lp, sync, shutdown, halt, news, uucp, operator, games, gopher, et ftp. Nous voulons également supprimer les groupes associés à ces comptes avec la commande groupdel dont le synopsis est identique à celui de userdel. Les groupes à supprimer sont : adm, lp, news, uucp, games, dip, pppusers, popusers et slipusers.
Cette section constitue, sans nul doute, la plus importante. Les fichiers de configurations mal entretenus représentent le plus grand risque pour un système. Dans cette section vous allez taper les mêmes commandes encore et encore, cela nous donne l'occasion d'écrire un petit script shell pour nous faciliter la tâche. Ce que nous voulons faire après qu'on en ait fini avec chaque fichier est de nous assurer qu'il appartient à root d'abord, ensuite qu'il n y a que root qui peut le lire et le modifier et enfin que même root ne peut l'altérer. Ceci assure que le fichier ne pourra pas être accidentellement supprimé ou modifié et assure que le fichier ne pourra être l'objet d'un lien, ce qui représente un gros risque. Tapez " touch protège-le " puis " chmod +x protège-le ", à présent ouvrez le fichier avec votre éditeur de texte préféré et entrez-y les lignes suivantes : (version texte) :
#!/bin/sh
# Appartient à l'utilisateur root et au groupe root
chown root.root $1
# Donnez à root seulement le droit de le lire et le modifier
chmod 600 $1
# Le rendre inaltérable
chattr +i $1
Sauvegardez le fichier et copiez-le dans /usr/sbin en tapant " cp protège-le /usr/sbin ". A présent dés qu'on aura fini avec un fichier, on le plombera en tapant " protège-le nomFichier ".
/etc/exports Ce fichier donne à votre système la liste des systèmes qui ont le droit de monter un volume NFS résidant sur votre système, ce fichier doit être vide, si ce ne pas le cas, supprimez-le avec " rm /etc/exports " et créez-en un vide avec " touch /etc/exports ". A présent plombez-le en tapant " protège-le /etc/exports "
/etc/inetd.conf C'est ici que la plupart des services TCP/IP démarrent. Puisque le seul service que nous utilisons est ssh -- qui n'est pas sous le contrôle de inetd - celui-ci doit être vide aussi. Donc supprimez-le, " rm /etc/inetd.conf " et créez-en un nouveau vide avec " touch /etc/inetd.conf ", plombez-le avec " protège-le /etc/inetd.conf ".
/etc/hosts.deny Ce fichier liste les systèmes dont l'accès à nos services TCP/IP est prohibé. Nous voulons éloigner tout hôte qui n'est pas listé dans /etc/hosts.allow, donc on va éditer ce fichier pour n'y laisser apparaître que la ligne ci-dessous puis nous le plombons également.
ALL: ALL
/etc/hosts.allow Ce fichier liste l'ensemble des hôtes dont l'accès aux services locaux sous contrôle de inetd est autorisé, et puisque /etc/inetd.conf est vide, celui-ci doit l'être également. Supprimez-le avec " rm /etc/hosts.allow " puis recréez-en une version vide avec " touch /etc/hosts.allow " et enfin plombez-le avec " protège-le /etc/hosts.allow ".
/etc/rc.d/rc.local La prochaine étape consiste à éviter que notre système révèle trop d'informations sur lui-même aux utilisateurs qui tentent de se signer et à travers les paquets ICMP. Supprimer /etc/issue et /etc/issue.net d'abord, ensuite ouvrez /etc/rc.d/rc.local avec votre éditeur de texte et supprimez les lignes suivates :
echo "" > /etc/issue
echo "$R" >> /etc/issue
echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue
cp -f /etc/issue /etc/issue.net
echo >> /etc/issue
Avant de sauvegarder le fichier, nous tenons à ce que le système ne réponde pas aux requêtes ICMP telles que ping et traceroute, donc nous allons ajouter les lignes suivantes juste en dessous de la ligne qui contient # !/bin/sh
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Ceci rendra votre système invisible au reste du monde, les " Script Kiddies " ne peuvent pas cracker ce qu'il ne peuvent pas trouver. La deuxième ligne vous protège contre les attaques de type SYN Denial of Service. Allons-y, enregistrons le fichier et sortons. Notez que ceci vous empêchera à vous-même de pinger le système mais ne devrait en aucun cas interférer avec d'autres fonctions telles que ssh ou IP forwarding. Nous allons enfin le plomber.
/etc/hosts.conf Puisque nous sommes entrain de nous protéger contre les attaques extérieures, nous devons ajouter les lignes suivantes en dernière ligne dans /etc/host.conf :
nospoof on
Ceci permettra au système de rejeter toute requête dont la source, en fait extérieure à notre réseau, prétend être un système membre de notre LAN, ce type d'attaque est appelé IP Spoofing (Parodie IP). Allons-y, plombons-le. Les fichiers que nous n'avons pas à changer mais que nous devons plomber sont : /etc/services, /etc/passwd, /etc/shadow, /etc/group et /etc/gshadow. Si vous prévoyez changer votre mot de passe ou ajouter un compte utilisateur, vous aurez à exécuter " chattr -i nomFichier " sur /etc/passwd, /etc/shadow, /etc/group et /etc/gshadow sinon vous aurez un message d'erreur.
/etc/fstab C'est ici que le système vient lire les informations concernant les volumes et partitions qui doivent être montés au démarrage ainsi que leurs points de montage. Si vous avez configuré votre système avec une grosse partition racine ou si vous n'avez pas configuré une partition séparée pour /home et /tmp, vous pouvez sauter cette section pour aller à la section " Quota disque ". /home et /tmp sont rendus importants par le fait que les utilisateurs autres que root y ont des droits d'écriture. Ce que nous voulons c'est de limiter les possibilités des utilisateurs lambda sur ces partitions. Sur /home, nous ne voulons pas qu'un utilisateur soit à même de créer un programme SUID ou un fichier périphérique, de plus nous voulons pas que des programmes soient exécutables sous /tmp. Nous réalisons tout ceci en modifiant /etc/fstab. Le mien ressemble à ceci et le vôtre est probablement similaire :
/dev/hda1 / ext2 defaults 1 1
/dev/hda9 /boot ext2 defaults 1 2
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0
/dev/hda5 /home ext2 defaults 1 2
/dev/hda6 /tmp ext2 defaults 1 2
/dev/sda1 /usr ext2 defaults 1 2
/dev/hda7 /var ext2 defaults 1 2
/dev/hda8 swap swap defaults 0 0
/dev/fd0 /mnt/floppy msdos noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
Nous voulons changer les lignes /home et /tmp pour qu'elles ressemblent à ceci :
/dev/hda5 /home ext2 rw,nosuid,nodev 1 2
/dev/hda6 /tmp ext2 rw,nosuid,nodev,noexec 1 2
Si vous avez des partitions différentes pour /home, cette étape est facultative. Si par contre vous avez une grande partition fourre-tout, vous devriez utiliser le système des quotas disque, ceci réduira la quantité d'espace disque qu'un utilisateur peut consommer et empêchera qu'un intrus qui aurait volé le compte remplisse votre disque jusqu'à saturation. La ligne par défaut dans /etc/fstab ressemble à ceci :
/dev/hda1 / ext2 defaults 1 1
modifiez-le pour qu'il ressemble à ceci,
/dev/hda1 / ext2 defaults,usrquota 1 1
Ajoutez les lignes suivantes à /etc/rc.d/rc.local
/sbin/quotacheck -avug
/sbin/quotaon -avug
A présent tapez " touch /quota.user " puis " chmod 700 /quota.user " et réamorcez le système. Vous verrez certaines erreurs concernant les quotas, ignorez-les.
Quand le système vous rendra la main, vous aurez à gérer les quotas pour celui qui est censé être le seul utilisateur lambda du système, tapez les commandes suivantes en remplaçant nomUtilisateur par le nom d'utilisateur que vous avez choisi, tapez " edquota -u nomUtilisateur ". Ceci lancera l'éditeur de texte vi avec quelque chose comme ceci :
Quotas for user username:
/dev/hda1: blocks in use: 7, limits (soft = 0, hard = 0)
inodes in use: 6, limits (soft = 0, hard = 0)
En spécifiant une limite en termes de blocs, vous indiquez l'espace disque que l'utilisateur peut consommer mesuré en KB, en spécifiant une limite en termes d'i-noeuds, vous indiquez le nombre de fichiers que l'utilisateur peut posséder. Une limites est dite " faible " lorsque sont dépassement entraîne l'avertissement de l'utilisateur, elle est dite " forte " lorsqu'elle est absolue (NdT : dans le sens qu'elle ne permet strictement pas de dépassement). A moins que vous ayez de bonnes raisons de les fixez à de plus grandes valeurs, comme le transfert de fichiers au format MP3 vers cette machine, je vous suggère de les fixer à des valeurs relativement basses, quelque chose comme 10MB d'espace disque ou 100 fichiers me paraît raisonnable. Modifier les lignes afin qu'elles ressemblent à ceci :
Quotas for user username:
/dev/hda1: blocks in use: 7, limits (soft = 5120, hard = 10240)
inodes in use: 6, limits (soft = 50, hard = 100)
Ceci fixera une limite " faible " à 50 fichiers couvrant 5MB et une limite " forte " à 100 fichiers pesant 100MB d'espace disque.
/etc/rc.d/init.d/* Ensuite nous devons nous assurer que tous les scripts de démarrage possèdent des jeux de permission convenables, pour cela tapez la commande "chmod -R 700 /etc/rc.d/init.d/*".
Nous devons trouver tous les fichiers SUID sur le système. Il y a des programmes qui utilisent l'identité de root quand ils sont exécutés, c'est un gros problème de sécurité. Cela fait de ces programmes une cible pour les attaques de type " Buffer overlow " et les remplacements par des chevaux de Troie. Pour trouver tous les programmes SUID sur le système, tapez " ls -alF `find / -perm -4000` > /root/suid.txt". A présent, ouvrez le fichier suid.txt et la sortie devrait ressembler à ceci :
-rwsr-xr-x 1 root root 35168 Sep 22 23:35 /usr/bin/chage
-rwsr-xr-x 1 root root 36756 Sep 22 23:35 /usr/bin/gpasswd
-r-xr-sr-x 1 root tty 6788 Sep 6 18:17 /usr/bin/wall
-rwsr-xr-x 1 root root 33152 Aug 16 16:35 /usr/bin/at
-rwxr-sr-x 1 root man 34656 Sep 13 20:26 /usr/bin/man
-r-s--x--x 1 root root 22312 Sep 25 11:52 /usr/bin/passwd
-rws--x--x 2 root root 518140 Aug 30 23:12 /usr/bin/suidperl
-rws--x--x 2 root root 518140 Aug 30 23:12 /usr/bin/sperl5.00503
-rwxr-sr-x 1 root slocate 24744 Sep 20 10:29 /usr/bin/slocate
-rws--x--x 1 root root 14024 Sep 9 01:01 /usr/bin/chfn
-rws--x--x 1 root root 13768 Sep 9 01:01 /usr/bin/chsh
-rws--x--x 1 root root 5576 Sep 9 01:01 /usr/bin/newgrp
-rwxr-sr-x 1 root tty 8328 Sep 9 01:01 /usr/bin/write
-rwsr-xr-x 1 root root 21816 Sep 10 16:03 /usr/bin/crontab
-rwsr-xr-x 1 root root 5896 Nov 23 21:59 /usr/sbin/usernetctl
-rwsr-xr-x 1 root bin 16488 Jul 2 10:21 /usr/sbin/traceroute
-rwxr-sr-x 1 root utmp 6096 Sep 13 20:11 /usr/sbin/utempter
-rwsr-xr-x 1 root root 14124 Aug 17 22:31 /bin/su
-rwsr-xr-x 1 root root 53620 Sep 13 20:26 /bin/mount
-rwsr-xr-x 1 root root 26700 Sep 13 20:26 /bin/umount
-rwsr-xr-x 1 root root 18228 Sep 10 16:04 /bin/ping
-rwxr-sr-x 1 root root 3860 Nov 23 21:59 /sbin/netreport
-r-sr-xr-x 1 root root 26309 Oct 11 20:48 /sbin/pwdb_chkpwd
Comme vous pouvez le constater, le premier champ à gauche montre les permissions de chaque fichier : tout fichier dont la chaîne de permission possède un " s " a le bit SUID activé, il n y a que root qui doit être en mesure d'exécuter ces programmes. A présent nous devons connaître les programmes dont la désactivation du bit SUID ne pose pas de problèmes. - En effet nombre de ces programmes ont besoin de cela pour leurs bon fonctionnements - Toutefois, bon nombre d'entre eux ne doivent être exécutés que par root. Pour désactiver le bit SUID tapez la commande " chmod a-s nomFichier ". Mon avis pour cette étape est de désactiver le bit SUID pour /usr/bin/chage, /usr/bin/gpasswd, /usr/bin/wall, /usr/bin/chfn, /usr/bin/chsh, /usr/bin/newgrp, /usr/bin/write, /usr/sbin/usernetctl, /usr/sbin/traceroute, /bin/mount, /bin/umount, /bin/ping, et /sbin/netreport.
La dernière chose à faire est de configurer votre système de sorte qu'il vous avertisse lorsqu'il subit des changements Si un intrus s'infiltre et vous balance un cheval de Troie ou crée un nouveau compte nous voulons que le système soit en mesure de nous dire ce qui a été altéré. Il y a pas mal de bon programmes pour cette usage, le plus facile à mettre en oeuvre à ma connaissance est fcheck, il peur être obtenu à partir de http://sites.netscape.net/fcheck/fcheck.html. Suivez les instructions pour l'installation et la configuration du logiciel, ça marche vraiment tout seul. Une fois que vous aurez terminé l'installation et la configuration, vous souhaiteriez qu'il s'exécute au moins une fois par jour et qu'il dirige le résultat vers un fichier du répertoire racine. Ceci peut être obtenu avec crond, pour installer une tâche cron tapez " crontab -e ", ceci lancera vi, tapez alors le ligne suivante :
1 0 * * * /usr/local/fcheck/fcheck -a > /root/fcheck.txt
Remplacez le chemin d'accès à fcheck par le vôtre, enregistrez et sortez. A présent, à 00 :01, fcheck s'exécutera et la sortie sera dirigée vers /root/fcheck.txt. Si d'aventure fcheck détecte un fichier altéré que vous ne pouvez pas vous expliquer, supprimez immédiatement le paquetage qui a installé le fichier et réinstallez-le à partir du CD de RedHat. Chaque fois que vous modifiez un fichier, vous devez exécuter " fcheck -ca " de nouveau, reconstruisant ainsi un autre repère.
Le système peut maintenant être mis sur Internet sans grand danger, une fois fait, vous voudriez auditer votre système de sécurité. La compagnie Gibson Research met à votre disposition un service de scanner de ports. Dans le meilleur des mondes tous les ports devraient être à l'état " stealth " (furtif), ce qui signifie que le port ne répond pas du tout aux requêtes et que votre système fera croire qu'il n y a aucune machine en ligne identifié par votre adresse IP. A défaut, le port devrait être dans l'état " closed ", ce qui signifie que le port répond mais ne traite pas les requêtes ; les ports dans cet état restent vulnérables à certains types d'attaques. Les ports dans l'état " Open " sont vulnérables, si l'un de vos ports est dans ce dernier état, retournez au fichier inetd.conf et assurez-vous qu'il est vide, assurez-vous également que apache, wu-ftpd ou quelque chose de ce genre n'est pas installé. Vérifier votre configuration ipchains pour vous assurez qu'il rejette correctement les paquets. Il est bon de répéter cette procédure de temps à autre pour vous assurer qu'un intrus n'a pas ouvert un port pour son utilisation personnelle
Encore une fois, comme dans mon dernier article, je tiens à préciser que ceci n'est pas la fin du mot sur la sécurité Linux, il ne s'agit que d'un point de départ, j'ai tout simplifié au point d'être trivial, il y a bien plus de choses à faire encore. Le fait de rechercher ces solutions ou non dépendra de ce que vous avez à protéger. Pour les utilisateurs domestiques ceci devrait suffire, toutefois, même avec une petite affaire ayant plus de machines à son actif et de données à protéger, vous devriez faire plus de recherches et mettre en oeuvre autant de règles de sécurité qu'il vous est possible. Mieux encore, recrutez un Consultant en Sécurité Réseaux pour les mettre en oeuvre à votre place.
copyright 2000, Chris Stoddard. Paru dans le numéro 55 de la Linux gazette de Juillet 2000
Traduction française de Wilane Ousmane