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

Manuel de sécurisation de Debian
Chapitre 4 - Après l'installation

Une fois que le système est installé, vous pouvez encore en faire plus pour sécuriser le système ; certaines des étapes décrites ci-dessous peuvent être effectuées. Bien sûr, cela dépend vraiment de votre configuration, mais pour prévenir un accès physique, vous devriez lire Changer le BIOS (à nouveau), Section 4.3, Attribuer un mot de passe à LILO ou GRUB, Section 4.4, Enlever le prompt root du noyau, Section 4.5, Interdire le démarrage sur disquette, Section 4.6, Restreindre les accès aux consoles, Section 4.7 et Restreindre les redémarrages système depuis la console, Section 4.8.

Avant de vous connecter à tout réseau, particulièrement s'il s'agit d'un réseau public, vous devriez, au minimum, faire une mise à jour de sécurité (voir Faire une mise à jour de sécurité, Section 4.2). Vous pouvez optionnellement faire un instantané de votre système (voir Prendre un instantané (snapshot) du système, Section 4.18).

4.1 S'abonner à la liste de diffusion Debian Security Announce

Pour recevoir des informations sur les mises à jour de sécurité disponibles, vous devriez vous abonner à la liste de diffusion debian-security-announce pour recevoir les bulletins de sécurité de Debian[8]. Voir L'équipe de sécurité Debian, Section 7.1 pour plus d'informations sur la façon dont fonctionne l'équipe de sécurité Debian. Pour des informations sur l'inscription aux listes de diffusion Debian, lisez http://lists.debian.org.

Les DSA sont signées par la signature de l'équipe de sécurité Debian qui peut être récupérée sur http://security.debian.org.

Vous devriez également envisager de vous abonner à la liste de diffusion debian-security pour des discussions générales sur les problèmes de sécurité dans le système d'exploitation Debian. Vous pourrez entrer en contact avec d'autres administrateurs système ainsi qu'avec des développeurs Debian et des développeurs amont d'outils de sécurité qui pourront répondre à vos questions et proposer leurs conseils.

FIXME: ajouter la clé ici également ?

4.2 Faire une mise à jour de sécurité

Dès que de nouveaux bogues de sécurité sont décelés dans les paquets, les responsables Debian et les auteurs amont les corrigent généralement dans les journées ou les heures suivantes. Une fois le bogue résolu, un nouveau paquet est fourni sur http://security.debian.org.

Si vous installez une version de Debian, vous devez prendre en compte le fait qu'il a pu y avoir des mises à jour de sécurité depuis la parution, à chaque fois après qu'un paquet a été découvert comme vulnérable. Ainsi, il a pu y avoir des révisions mineures (il y en a eu sept dans la version Debian 2.2 Potato) incluant ces mises à jour de paquets.

Vous devez noter la date à laquelle votre support amovible (si vous en utilisez un) a été créé et vérifier le site de sécurité pour savoir s'il y a eu des mises à jour de sécurité. S'il y en a eu et que vous ne pouvez pas télécharger les paquets du site de sécurité sur un autre système (vous n'êtes pas encore connecté à l'Internet, n'est-ce pas ?) avant de vous connecter au réseau, vous devriez envisager (si vous n'êtes pas protégé par un pare-feu par exemple) d'ajouter des règles de pare-feu pour que votre système ne puisse se connecter qu'à security.debian.org et ensuite réaliser la mise à jour. Une configuration exemple est donnée dans Mise à jour de sécurité protégée par un pare-feu, Annexe F.

Remarque : Depuis Debian Woody 3.0, après l'installation, il vous est donné la possibilité d'ajouter les mises à jour de sécurité au système. Si vous répondez « oui » (yes) à cette question, le système d'installation fera les démarches nécessaires pour ajouter la source pour les mises à jour de sécurité aux sources de paquets et votre système, si vous êtes connecté à l'Internet, téléchargera et installera toutes les mises à jour de sécurité qui auront pu être produites depuis la création de votre support. Si vous mettez à niveau depuis une version précédente de Debian ou si vous demandez au système de ne pas faire cela, vous devriez suivre les étapes décrites ici.

Pour mettre à jour manuellement le système, insérez la ligne suivante dans votre sources.list et vous recevrez les mises à jour de sécurité automatiquement quand vous mettrez à jour votre système. 

       deb http://security.debian.org/debian-security stable/updates main contrib non-free

Une fois ceci fait, vous pouvez utiliser soit apt, soit dselect pour les mises à jour :

Si vous voulez, vous pouvez ajouter également les lignes deb-src à /etc/apt/sources.list. Voir apt(8) pour plus de détails.

Remarque : vous n'avez pas besoin d'ajouter la ligne suivante : 

       deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free

car security.debian.org est hébergé à un emplacement hors des États-Unis et n'a donc pas d'archive non-US séparée.

4.2.1 Mise à jour de sécurité des bibliothèques

Une fois que vous avez exécuté une mise à jour de sécurité, il se peut que vous deviez redémarrer certains des services système. Si vous ne faites pas cela, certains services pourraient encore être vulnérables après une mise à jour de sécurité. La raison pour cela est que les démons qui fonctionnent avec une mise à jour peuvent encore utiliser les anciennes bibliothèques après la mise à jour[9]. Pour détecter quels démons peuvent devoir être redémarrés, vous pouvez utiliser le programme checkrestart (disponible dans le paquet debian-goodies) ou utiliser cette ligne de commande (en tant que superutilisateur) : 

     # lsof | grep dpkg- | awk '{print $1, $8}' | sort +0

Certains paquets (comme libc6) feront cette vérification dans la phase de postinstallation pour un nombre limité de services, en particulier car une mise à jour de bibliothèques essentielles peut casser certaines applications (avant leur redémarrage)[10].

Faire passer le système en niveau d'exécution 1 (utilisateur seul), puis ensuite au niveau d'exécution 3 (multiutilisateur) devrait entraîner le redémarrage de la plupart (si ce n'est tous) des services système. Mais cela n'est pas une possibilité si vous exécutez la mise à jour de sécurité depuis une connexion distante (comme ssh) car celle-ci serait alors interrompue.

Apportez le plus grand soin lors des mises à jour de sécurité si vous les réalisez depuis une connexion à distance comme ssh. Une procédure suggérée pour une mise à jour de sécurité qui implique un redémarrage de services est de redémarrer le démon SSH, puis immédiatement de tenter une nouvelle connexion ssh sans interrompre la précédente. Si la connexion échoue, annulez la mise à jour et analysez le problème.

4.2.2 Mise à jour de sécurité du noyau

Assurez-vous tout d'abord que votre noyau est géré par le système de gestion des paquets. Si vous l'avez installé en utilisant le système d'installation de Debian 3.0 ou de versions précédentes, votre noyau n'est pas intégré dans le système de gestion des paquets et pourrait être obsolète. Vous pouvez facilement confirmer cela en exécutant : 

     $ dpkg -S `readlink -f /vmlinuz`
     kernel-image-2.4.27-2-686: /boot/vmlinuz-2.4.27-2-686

Si votre noyau n'est pas géré, vous verrez un message indiquant que le gestionnaire de paquets n'a pas trouvé le fichier associé à un paquet au lieu du message ci-dessus, qui dit que le fichier associé au noyau actuellement en fonctionnement est fourni par le paquet kernel-image-2.4.27-2-686. Dans le premier cas, vous devrez installer manuellement un paquet d'image de noyau. L'image exacte du noyau que vous devez installer dépend de votre architecture et de votre version de noyau préférée. Une fois ceci fait, vous pourrez gérer les mises à jour de sécurité du noyau comme pour tout autre paquet. Dans tous les cas, notez que les mises à jour du noyau ne seront faites que pour la même version du noyau que celui que vous utilisez, c'est-à-dire que apt ne va pas mettre à jour automatiquement votre noyau de la version 2.4 à la version 2.6 (ou de la version 2.4.26 à la version 2.4.27[11]).

Le système d'installation de la version 3.1 de Debian gérera le noyau sélectionné (2.4 ou 2.6) comme partie du système de gestion des paquets. Vous pouvez vérifier quels noyaux sont installés en exécutant : 

     $ COLUMNS=150 dpkg -l 'kernel-image*' | awk '$1 ~ /ii/ { print $0 }'

Pour voir si votre noyau doit être mis à jour, exécutez : 

     $ kernfile=`readlink -f /vmlinuz`
     $ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
     $ apt-cache policy $kernel
     kernel-image-2.4.27-2-686:
       Installed: 2.4.27-9
       Candidate: 2.4.27-9
       Version Table:
      *** 2.4.27-9 0
     (...)

Si vous effectuez une mise à jour de sécurité incluant l'image du noyau, vous devez redémarrer le système pour que la mise à jour de sécurité soit utile. Sinon, vous utiliserez encore l'ancienne image de noyau (vulnérable).

Si vous devez effectuer un redémarrage du système (à cause d'une mise à jour du noyau), vous devriez vous assurer que le noyau démarrera correctement et que la connectivité réseau sera restaurée, particulièrement si la mise à jour de sécurité est réalisée depuis une connexion à distance comme ssh. Pour le premier point, vous pouvez configurer le chargeur d'amorçage pour redémarrer l'ancien noyau en cas d'échec (pour des informations plus détaillées, veuillez lire (en anglais) Remotely rebooting Debian GNU/Linux machines). Pour le second point, vous devez introduire un script de test de connectivité réseau qui vérifiera si le noyau a lancé le sous-système réseau correctement et qui redémarrera le système si ce n'est pas le cas[12]. Ceci devrait éviter des surprises désagréables comme une mise à jour du noyau en réalisant après un redémarrage qu'il n'a pas détecté ou configuré le matériel réseau correctement et que vous devez parcourir une longue distance pour relancer à nouveau le système. Bien sûr, avoir la console série[13] du système connectée à une console ou un serveur de terminal devrait également aider à déboguer à distance les problèmes de redémarrage.

4.3 Changer le BIOS (à nouveau)

Vous vous souvenez de Choisir un mot de passe pour le BIOS, Section 3.1 ? Et bien, vous devriez maintenant, une fois que vous n'avez plus besoin de démarrer à partir d'un support amovible, changer la configuration par défaut du BIOS pour qu'il ne puisse démarrer que depuis le disque dur. Assurez-vous de ne pas perdre le mot de passe BIOS, sinon, en cas de défaillance du disque dur, vous ne pourrez pas retourner dans le BIOS et modifier la configuration pour le récupérer en utilisant, par exemple, un cédérom.

Un autre moyen moins sécurisé, mais plus pratique est de changer la configuration pour que le système s'amorce depuis le disque dur et, si cela échoue, d'essayer un support amovible. À propos, c'est ainsi fait parce que la plupart des personnes n'utilisent pas le mot de passe BIOS très souvent ; il est facilement oublié.

4.4 Attribuer un mot de passe à LILO ou GRUB

N'importe qui peut obtenir facilement un shell root et changer vos mots de passe en entrant au prompt de boot <nom-de-votre-image-de-boot> init=/bin/sh. Après le changement du mot de passe et le redémarrage du système, la personne a un accès root illimité et peut faire tout ce qu'elle veut sur le système. Après ceci, vous n'aurez plus d'accès root sur votre machine, étant donné que vous ne connaîtrez pas le mot de passe.

Pour être sûr que cela ne puisse pas se produire, vous devriez attribuer un mot de passe au démarrage. Vous avez le choix entre un mot de passe global et un mot de passe pour une image donnée.

Pour LILO, vous avez besoin d'éditer le fichier /etc/lilo.conf et ajouter les lignes password ainsi que restricted comme dans l'exemple suivant. 

       image=/boot/2.2.14-vmlinuz
          label=Linux
          read-only
          password=piratemoi
          restricted

Puis, assurez-vous que le fichier de configuration n'est pas lisible par tout le monde pour empêcher des utilisateurs locaux de lire le mot de passe. Une fois terminé, relancez lilo. Omettre la ligne restricted entraîne une attente de mot de passe, en dépit des paramètres passés à LILO. Les permissions par défaut pour le fichier /etc/lilo.conf accordent à root les droits de lecture et d'écriture et permettent un accès en lecture seule pour le groupe de configuration de lilo.conf, à savoir root.

Si vous utilisez GRUB plutôt que LILO, éditez /boot/grub/menu.lst et ajoutez les deux lignes suivantes en début (en remplaçant, bien sûr, piratemoi par le mot de passe désiré). Ceci empêche les utilisateurs d'éditer les options de démarrage. timeout 3 indique un délai de 3 secondes avant que grub démarre l'option par défaut. 

       timeout 3
       password piratemoi

Pour aller plus loin dans le durcissement de l'intégrité du mot de passe, vous pourriez entreposer le mot de passe sous une forme cryptée. L'utilitaire grub-md5-crypt génère un hachage de mot de passe qui est compatible avec l'algorithme du mot de passe grub (md5). Pour spécifier à grub qu'un mot de passe sous le format md5 va être utilisé, utilisez la directive suivante : 

       timeout 3
       password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0

Le paramètre --md5 a été ajouté pour informer grub d'effectuer la procédure d'authentification md5. Le mot de passe fourni est la version md5 cryptée de piratemoi. L'utilisation de la méthode md5 pour le mot de passe est préférable à la méthode précédente dont le mot de passe est en clair. Plus d'information concernant les mots de passe grub se trouvent dans le paquet grub-doc.

4.5 Enlever le prompt root du noyau

Note : Cela ne s'applique pas aux noyaux fournis par Debian 3.1.

Les noyaux Linux 2.4 fournissent un moyen d'accéder à un shell root lors de l'amorçage et qui sera présenté juste après le chargement du système de fichiers cramfs. Un message apparaîtra pour permettre à l'administrateur d'entrer un shell exécutable avec des permissions root, ce shell peut être utilisé pour charger manuellement des modules quand la détection automatique échoue. Ce comportement est celui par défaut pour linuxrc de l'initrd. Le message suivant apparaîtra : 

       Press ENTER to obtain a shell (waits 5 seconds)

Pour supprimer ce comportement, vous devez changer /etc/mkinitrd/mkinitrd.conf et positionner : 

       # DELAY  Le nombre de secondes que le script linuxrc doit attendre
       # pour permettre à l'utilisateur de l'interrompre avant que le
       # système soit lancé
       DELAY=0

Puis, régénérez votre image de ramdisk. Vous pouvez faire cela ainsi, par exemple : 

       # cd /boot
       # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7

ou (de préférence) : 

       # dpkg-reconfigure -plow kernel-image-2.4.x-yz

Notez que Debian 3.0 Woody permet aux utilisateurs d'installer des noyaux 2.4 (en sélectionnant des saveurs), cependant le noyau par défaut est un 2.2 (excepté pour certaines architectures pour lesquelles le noyau 2.2 n'a pas été porté). Si vous pensez que cela est un bogue, veuillez consulter le bogue n°\|[nbsp ]\|145244 avant d'envoyer un rapport de bogue.

4.6 Interdire le démarrage sur disquette

Le MBR par défaut dans Debian avant la version 2.2 ne fonctionnait pas comme le master boot record habituel et laissait un moyen facile de pénétrer un système :

Ce comportement peut être modifié en entrant : 

       lilo -b /dev/hda

Maintenant LILO est mis dans le MBR. Ceci peut être fait également en ajoutant boot=/dev/hda au fichier lilo.conf. Il y a encore une autre solution qui désactivera complètement le prompt MBR : 

       install-mbr -i n /dev/hda

D'un autre côté, cette « porte dérobée », dont de nombreuses personnes ne sont pas au courant, peut aussi bien vous sauver la peau si vous rencontrez de gros problèmes, quelque soient les raisons, avec votre installation.

FIXME vérifier si cela touche réellement la 2.2 ou seulement la 2.1? INFO: Les disques de démarrage de la 2.2 n'installe pas le mbr, mais seulement LILO.

4.7 Restreindre les accès aux consoles

Certaines règles de sécurité peuvent forcer les administrateurs à se connecter au système via une console avec leur identifiant/mot de passe puis devenir super utilisateur (avec su ou sudo). Cette règle est appliquée sous Debian en éditant les fichiers /etc/login.defs ou /etc/securetty lors de l'utilisation de PAM. Dans :

En cas d'utilisation de PAM d'autres changements au processus de login, qui peuvent inclure des restrictions aux utilisateurs et groupes à certains moments, peuvent être configurés dans /etc/pam.d/login. Une fonctionnalité intéressante qui peut être désactivée est la possibilité de se connecter avec des mots de passe nuls (vides). Cette fonctionnalité peut être limitée en enlevant nullok de la ligne : 

       auth       required   pam_unix.so nullok

4.8 Restreindre les redémarrages système depuis la console

Si votre système dispose d'un clavier attaché, n'importe qui (oui, vraiment n'importe qui) peut redémarrer le système avec celui-ci sans se connecter au système. Cela peut en conformité ou non avec vos règles de sécurité. Si vous désirez restreindre cela, vous devez vérifier le fichier /etc/inittab pour que la ligne incluant ctrlaltdel appelle shutdown avec le paramètre -a (rappelez-vous d'exécuter init q après avoir fait un changement à ce fichierà. La valeur par défaut dans Debian inclut ce paramètre : 

       ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Puis, pour permettre à certains utilisateurs d'arrêter le système, comme décrit dans la page de manuel shutdown(8), vous devez créer le fichier /etc/shutdown.allow et inclure le nom des utilisateurs qui peuvent amorcer (?) le système. Quand le salut à trois doigts (ou ctrl+alt+del) est exécuté, le programme va vérifier si l'un des utilisateurs de ce fichier est connecté. Si aucun d'entre eux ne l'est, shutdown ne va pas redémarrer le système.

4.9 Monter correctement les partitions

Lorsque vous montez une partition ext2, vous avez différentes options additionnelles pour l'appel mount ou pour le fichier /etc/fstab. Par exemple, ceci est mon entrée pour la partition /tmp : 

     /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2

Vous voyez la différence dans la section des options. L'option nosuid ignore complètement les bits setuid et setgid, tandis que noexec interdit l'exécution de tout programme sur ce point de montage et nodev ignore les périphériques. Ceci semble bon mais cela

L'option noexec évite aux binaires d'être exécutés directement mais cela est facilement contournable : 

       alex@joker:/tmp# mount | grep tmp
       /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
       alex@joker:/tmp# ./date
       bash: ./date: Permission denied
       alex@joker:/tmp# /lib/ld-linux.so.2 ./date
       Sun Dec  3 17:49:23 CET 2000

Toutefois, de nombreux script kiddies utilisent des exploits qui essayent de créer et d'exécuter des fichiers dans /tmp. S'ils ne sont pas futés, ils tomberont sur un pépin. En d'autres termes, un utilisateur ne peut être abusé en exécutant un binaire compromis (genre cheval de troie) dans /tmp lorsqu'il a accidentellement ajouté /tmp dans son PATH.

Soyez aussi vigilant, certains scripts peuvent dépendre du fait que /tmp devienne exécutable. Notamment Debconf qui a (avait ?) quelques problèmes concernant cela, pour plus d'information voir le bogue 116448.

Ce qui suit est un exemple un plus peu poussé. Prenez note que, bien que /var peut être mis à noexec, certains logiciels[19] conservent leurs programmes dans /var. Les mêmes conditions peuvent être appliquées à l'option nosuid. 

     /dev/sda6   /usr          ext2    defaults,ro,nodev       0       2
     /dev/sda12  /usr/share    ext2    defaults,ro,nodev,nosuid        0       2
     /dev/sda7   /var          ext2    defaults,nodev,usrquota,grpquota 0      2
     /dev/sda8   /tmp          ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda9   /var/tmp      ext2    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
     /dev/sda10  /var/log      ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda11  /var/account  ext2    defaults,nodev,nosuid,noexec    0       2
     /dev/sda13  /home         ext2    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
     /dev/fd0    /mnt/fd0      ext2    defaults,users,nodev,nosuid,noexec      0       0
     /dev/fd0    /mnt/floppy   vfat    defaults,users,nodev,nosuid,noexec      0       0
     /dev/hda    /mnt/cdrom    iso9660 ro,users,nodev,nosuid,noexec            0       0

4.9.1 Paramétrer /tmp en noexec

Soyez vigilant si vous mettez /tmp en noexec et que vous voulez installer de nouveaux logiciels étant donné que certains peuvent l'utiliser pendant l'installation. Apt est un programme de ce genre (voir http://bugs.debian.org/116448) si APT::ExtractTemplates::TempDir n'est pas configuré correctement (voir apt-extracttemplates(1)). Vous pouvez paramétrer cette variable dans le fichier /etc/apt/apt.conf vers un autre répertoire que /tmp et qui aura les privilèges exec.

Concernant noexec, prenez conscience qu'il peut ne pas offrir le niveau de sécurité désiré. Observons ceci : 

       $ cp /bin/date /tmp
       $ /tmp/date
       (n'est pas exécuté pas à cause de noexec)
       $/lib/ld-linux.so.2 /tmp/date
       (fonctionne correctement car date n'est pas exécuté directement)

4.9.2 Paramétrer /usr en lecture seule

Si vous mettez /usr en lecture seule, vous serez dans l'incapacité d'installer de nouveaux paquets sur votre système Debian GNU/Linux. Vous devrez, avant tout la remonter en lecture-écriture, puis installer les nouveaux paquets et enfin la remonter en lecture seule. La dernière version d'apt (dans Debian 3.0 « Woody ») peut être configurée pour lancer des commandes avant et après l'installation de paquets, ainsi vous pouvez avoir envie de le configurer correctement.

Pour réaliser ceci, modifiez le fichier /etc/apt/apt.conf et ajoutez : 

       DPkg
       {
           Pre-Invoke  { "mount /usr -o remount,rw" };
           Post-Invoke { "mount /usr -o remount,ro" };
       };

Notez que le Post-invoke peut échouer avec un message d'erreur "/usr busy". Ceci survient principalement lorsque vous utilisez des fichiers lors de la mise à jour et que ces fichiers sont justement mis à jour. Vous pouvez trouver ces programmes en exécutant 

     # lsof +L1

Arrêtez ou relancez ces programmes et exécutez la commande de Post-Invoke manuellement. Attention ! Cela veut dire que vous devrez probablement redémarrez votre session X (si vous en faites fonctionner une) à chaque fois que vous faites une mise à jour majeure de votre système. Vous pouvez vouloir reconsidérer si un /usr en lecture seule est convenable pour votre système. Voir également cette discussion sur debian-devel à propos de /usr en lecture seule.

4.10 Fournir des accès sécurisés aux utilisateurs

4.10.1 Authentification utilisateur : PAM

PAM (Pluggable Authentication Modules) permet aux administrateurs systèmes de choisir comment les applications authentifient les utilisateurs. Il est à noter que PAM ne peut rien faire tant qu'une application n'a pas été compilée avec le support pour PAM. La plupart des applications livrées dans la Debian 2.2 ont ce support d'inclus. Par ailleurs, Debian n'avait pas le support de PAM avant la 2.2. La configuration actuelle par défaut pour tout service activé avec PAM est d'émuler l'authentification UNIX (lisez /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz pour plus d'informations sur la façon dont les services devraient fonctionner dans Debian).

Chaque application avec le support PAM fournit un fichier de configuration dans /etc/pam.d qui peut être utilisé pour modifier son comportement :

La description qui suit est loin d'être complète, pour plus d'informations vous pouvez regarder le The Linux-PAM System Administrator's Guide (sur le site primaire de distribution de PAM). Ce document est également fourni dans le paquet Debian libpam-doc.

PAM vous offre la possibilité de passer en revue plusieurs étapes d'authentification en une seule fois, à l'insu de l'utilisateur. Vous pouvez vous authentifier à une base de données Berkeley et à un fichier passwd normal, ainsi l'utilisateur pourra se connecter seulement si l'authentification est correcte des deux côtés. Vous pouvez restreindre beaucoup de choses avec PAM comme vous pouvez laisser libre accès à votre système. Donc soyez prudent. Une ligne de configuration typique a un champ de contrôle comme deuxième élément. Généralement, il devrait être paramétrer sur requisite qui retourne un échec de connexion si un module échoue.

La première chose que j'aime faire est d'ajouter le support MD5 aux applications PAM, étant donné que ceci protège le système contre les tentatives d'attaques par dictionnaire (les mots de passes peuvent être plus long en utilisant MD5). Les deux lignes suivantes devraient être ajoutées à toutes les lignes dans /etc/pam.d/ qui alloue l'accès à la machine, tel login et ssh. 

       # Vérifier que libpam-cracklib soit installé avant sinon vous ne
       # pourrez pas vous connecter.
       password   required     pam_cracklib.so retry=3 minlen=12 difok=3
       password   required     pam_unix.so use_authtok nullok md5

Que fait cette formule magique ? La première ligne charge le module PAM cracklib qui fournit la vérification de la longueur des mots de passe, attend un nouveau mot de passe avec au minimum 12 caractères, une différence d'au-moins 3 caractères par rapport à l'ancien et autorise 3 essais. Cracklib dépend d'une liste de mots (comme wenglish, wspanish, wbritish, etc.), assurez-vous donc d'en avoir installé une adaptée à votre langue, sinon, cela peut ne pas vous être du tout utile. [20] La seconde ligne introduit le module d'authentification standard avec MD5 et autorise un mot de passe nul. La directive use_authok est nécessaire pour passer le mot de passe du module précédent.

Afin d'être sûr que l'utilisateur root peut se connecter uniquement à partir des terminaux locaux, la ligne suivante doit être activée dans /etc/pam.d/login : 

       auth     requisite  pam_securetty.so

Puis, vous devez modifier la liste des terminaux sur lesquels la connexion de root est autorisée dans le fichier /etc/securetty. Vous pouvez sinon activer le module pam_access et modifier /etc/security/access.conf qui permet un contrôle plus général et affiné, mais à qui il manque (malheureusement) des messages de journalisation décents (la journalisation dans PAM n'est pas standard et est un problème particulièrement peu gratifiant à traiter). Nous reviendrons au fichier access.conf un peu plus tard.

Enfin, mais pas le moindre, la ligne suivante devrait être activée dans /etc/pam.d/login pour mettre en place des limites de ressource utilisateur. 

       session  required   pam_limits.so

Ceci restreint les ressources du système auxquelles les utilisateurs sont autorisées (voir ci-dessous Restreindre l'utilisation des ressources : le fichier limits.conf, Section 4.10.2). Par exemple, vous pouvez restreindre le nombre de connexions (d'un groupe d'utilisateurs donné ou tout le système), le nombre de processus, la taille de la mémoire, etc.

Maintenant, éditez /etc/pam.d/passwd et changez la première ligne. Vous devriez ajouter l'option « md5 » pour utiliser les mots de passe MD5, modifiez la longueur minimale du mot de passe de 4 à 6 (ou plus) et fixez une longueur maximale si vous le désirez. La ligne devrait ressembler à quelque chose comme ceci : 

       password   required   pam_unix.so nullok obscure min=6 max=11 md5

Si vous voulez protéger su, pour que seuls quelques personnes puissent l'utiliser pour devenir root sur votre système, vous avez besoin de créer un nouveau groupe « wheel » (c'est la meilleure façon, étant donné qu'aucun fichier n'a ces permissions d'attribuées). Ajoutez root et les autres utilisateurs, qui auront la possibilité d'utiliser su pour devenir root, à ce groupe. Ensuite, ajoutez la ligne suivante dans /etc/pam.d/su : 

       auth        requisite   pam_wheel.so group=wheel debug

Ceci permet d'être sûr qu'uniquement les personnes du groupe « wheel » pourront utiliser su pour devenir root. Les autres utilisateurs ne seront pas capable de le devenir. En fait, ils recevront un message de refus s'ils essayent de devenir root.

Si vous désirez que seulement certains utilisateurs s'authentifient à un service PAM, il suffit de faire cela en utilisant les fichiers où sont stockés les utilisateurs autorisés (ou pas) à se connecter. Imaginons que vous ne vouliez autoriser que l'utilisateur « ref » à se connecter via ssh. Vous le mettez dans /etc/sshusers-allowed et écrivez ce qui suit dans /etc/pam.d/ssh: 

       auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail

La dernière étape, mais pas la moindre, est de créer le fichier /etc/pam.d/other et d'ajouter les lignes suivantes : 

       auth     required       pam_securetty.so
       auth     required       pam_unix_auth.so
       auth     required       pam_warn.so
       auth     required       pam_deny.so
       account  required       pam_unix_acct.so
       account  required       pam_warn.so
       account  required       pam_deny.so
       password required       pam_unix_passwd.so
       password required       pam_warn.so
       password required       pam_deny.so
       session  required       pam_unix_session.so
       session  required       pam_warn.so
       session  required       pam_deny.so

Ces lignes vont fournir une bonne configuration par défaut pour toutes les applications qui supportent PAM (accès refusé par défaut).

4.10.2 Restreindre l'utilisation des ressources : le fichier limits.conf

Vous devriez vraiment jeter un sérieux œil à ce fichier. Vous pouvez définir dans celui-ci les limites des ressources par utilisateur. Dans d'anciennes versions, ce fichier de configuration était /etc/limits.conf, mais dans les nouvelles versions (avec PAM), le fichier de configuration à utiliser devrait être /etc/security/limits.conf.

Si vous ne désirez pas restreindre l'utilisation des ressources, n'importe quel utilisateur ayant un shell valide sur votre système (ou même un intrus qui aurait compromis le système par un service ou un démon devenu fou) pourra utiliser autant de CPU, de mémoire, de pile, etc. que le système pourra fournir. Ce problème d'épuisement de ressources peut être réglé par l'utilisation de PAM.

Il existe un moyen d'ajouter des limites de ressources pour certains shells (par exemple, bash a ulimit, voir bash(1)), mais comme ils ne fournissent pas tous les mêmes limites et comme l'utilisateur peut changer de shell (voir chsh(1)), il est préférable de placer ces limites dans les modules PAM ainsi elles s'appliqueront quel que soit le shell utilisé et également aux modules PAM qui ne sont pas orientés shell.

Les limites de ressources sont imposées par le noyau, mais elles doivent être configurées par le fichier limits.conf et la configuration PAM des différents services doit charger le module PAM approprié. Vous pouvez vérifier quels services imposent des limites en exécutant : 

     $ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"

Habituellement, login, ssh et les gestionnaires de session graphique (gdm, kdm ou xdm) devraient imposer des limites aux utilisateurs, mais vous pouvez vouloir faire cela dans d'autres fichiers de configuration de PAM, comme cron, pour empêcher les démons système d'accaparer toutes les ressources système..

Les paramètres de limites spécifiques que vous pouvez vouloir imposer dépend des ressources de votre système, c'est l'une des principales raisons pour lesquelles aucune limite n'est imposée dans l'installation par défaut.

Par exemple, l'exemple de configuration ci-desous impose une limite de 100 processus pour chaque utilisateur (pour empêcher les bombe de fork) ainsi qu'une limite de 10 Mo de mémoire par processus et une limite de 10 connexions simultanées. Les utilisateurs du groupe adm ont des limites supérieures et peuvent créer des fichiers core s'ils le désirent (c'est simplement une limite douce (soft)). 

     *              soft    core            0
     *              hard    core            0
     *              hard    rss             1000
     *              hard    memlock         1000
     *              hard    nproc           100
     *              -       maxlogins       1
     *              hard    data            102400
     *              hard    fsize           2048
     @adm           hard    core            100000
     @adm           hard    rss             100000
     @adm           soft    nproc           2000
     @adm           hard    nproc           3000
     @adm           hard    fsize           100000
     @adm           -       maxlogins       10

Voici les limites qu'un utilisateur standard (y compris les démons système) aurait : 

     $ ulimit -a
     core file size        (blocks, -c) 0
     data seg size         (kbytes, -d) 102400
     file size             (blocks, -f) 2048
     max locked memory     (kbytes, -l) 10000
     max memory size       (kbytes, -m) 10000
     open files                    (-n) 1024
     pipe size          (512 bytes, -p) 8
     stack size            (kbytes, -s) 8192
     cpu time             (seconds, -t) unlimited
     max user processes            (-u) 100
     virtual memory        (kbytes, -v) unlimited

Et voici les limites d'un utilisateur administratif : 

     $ ulimit -a
     core file size        (blocks, -c) 0
     data seg size         (kbytes, -d) 102400
     file size             (blocks, -f) 100000
     max locked memory     (kbytes, -l) 100000
     max memory size       (kbytes, -m) 100000
     open files                    (-n) 1024
     pipe size          (512 bytes, -p) 8
     stack size            (kbytes, -s) 8192
     cpu time             (seconds, -t) unlimited
     max user processes            (-u) 2000
     virtual memory        (kbytes, -v) unlimited

Pour plus d'informations, lisez :

4.10.3 Actions de connexion de l'utilisateur : éditer /etc/login.defs

La prochaine étape est d'éditer la configuration et action de base sur la connexion de l'utilisateur. Notez que ce fichier ne fait pas parti de la configuration PAM, c'est un fichier de configuration qui est pris en compte par les programmes login et su, il n'est pas logique de l'adapter aux cas pour lesquels ni l'un, ni l'autre des programme n'est appelé au moins indirectement (le programme getty qui gère les console et offre le prompt de connexion initial appelle bien login). 

       FAIL_DELAY          10

Cette variable devrait être fixée à une valeur suffisamment grande de façon à rendre plus difficile les tentatives de connexion en utilisant la manière forte. Si un mauvais mot de passe est fourni, le pirate potentiel (ou le simple utilisateur !) doit attendre 10 secondes avant d'obtenir un nouveau prompt de connexion, ce qui prend pas mal de temps quand vous testez des mots de passe. Veuillez noter que ce paramètre est inopérant si vous utilisez un programme autre que getty, comme par exemple mingetty. 

       FAILLOG_ENAB        yes

Si vous activez cette variable, les connexions échouées seront enregistrées dans un journal. Il est important d'en garder une trace pour quelqu'un qui tente une attaque par la manière forte. 

       LOG_UNKFAIL_ENAB    yes

Si vous mettez la variable FAILLOG_ENAB à yes, alors il faudra mettre cette variable également à yes. Ceci sauvegardera les noms d'utilisateurs inconnus si la connexion échoue. Si vous faites cela, assurez-vous que les journaux de connexion ont les bonnes permissions (640 par exemple avec un groupe adéquat comme adm), car souvent les utilisateurs entrent accidentellement leur mot de passe au lieu du nom d'utilisateur et vous ne voulez pas permettre aux autres utilisateurs de le voir. 

       SYSLOG_SU_ENAB      yes

Ceci va activer l'écriture dans les journaux de syslog des tentatives de su. Plutôt important sur des machines sérieuses, mais notez que ceci peut aussi bien être à la base de problèmes de respect de la vie privée. 

       SYSLOG_SG_ENAB      yes

La même chose que SYSLOG_SU_ENAB, mais s'applique au programme sg. 

       MD5_CRYPT_ENAB      yes

Comme mentionné ci-dessus, les mots de passe MD5 réduit considérablement le problème des attaques par dictionnaire étant donné que vous pouvez utiliser des mots de passe plus longs. Si vous utilisez slink, lisez les documentations avant d'activer le MD5. Sinon, cela est paramétré dans PAM. 

       PASS_MAX_LEN        50

Si les mots de passe MD5 sont activés dans votre configuration PAM, alors cette variable devrait avoir la même valeur que dans celle-ci.

4.10.4 Restreindre le ftp : éditer /etc/ftpusers

Ce fichier contient une liste d'utilisateurs qui ne sont pas autorisés à se connecter à l'hôte en utilisant ftp. Utilisez uniquement ce fichier si vous voulez réellement autoriser le ftp (qui n'est, en général, pas recommandé car il utilise des mots de passe en clair). Si votre démon supporte PAM, celui-ci peut être utilisé pour permettre ou refuser certains services aux utilisateurs.

FIXME (BUG): Est-ce un bogue que le fichier par défaut ftpusers dans Debian ne contient pas tous les utilisateurs d'administration (dans base-passwd).

4.10.5 Utilisation de su

Si vous avez réellement besoin que des utilisateurs deviennent super utilisateur sur votre système, par exemple pour installer des paquets ou ajouter des utilisateurs, vous pouvez utiliser la commande su pour changer d'identité. Vous devriez essayer d'éviter toute connexion en tant que root et d'utiliser à la place su. En réalité, la meilleure solution est de supprimer su et de changer pour le mécanisme sudo qui a une logique plus large et plus de fonctionnalités que su. Cependant, su est plus commun étant donné qu'il est utilisé sur beaucoup d'autres Unices.

4.10.6 Utilisation de sudo

sudo autorise l'utilisateur à exécuter des commandes définies sous l'identité d'un autre utilisateur, même en tant que root. Si l'utilisateur est ajouté à /etc/sudoers et est authentifié correctement, il est capable de lancer des commandes qui ont été définies dans /etc/sudoers. Les infractions, telles que les mots de passe incorrects ou les tentatives de lancement d'un programme pour lequel vous n'avez pas les permissions, sont logguées et envoyées au root.

4.10.7 Désactiver des accès d'administration à distance

Vous devriez également modifier /etc/security/access.conf pour désactiver la connexion d'administration à distance. Ainsi, les utilisateurs doivent exécuter su (ou sudo) pour utiliser des pouvoirs administratifs et ainsi la trace d'audit appropriée sera toujours générée.

Vous devez ajouter la ligne suivante à /etc/security/access.conf, le fichier de configuration par défaut Debian contient une ligne exemple commentée : 

        -:wheel:ALL EXCEPT LOCAL

Rappelez-vous d'activer le module pam_access pour chaque service (ou configuration par défaut) dans /etc/pam.d/ si vous voulez que vos modifications dans /etc/security/access.conf soient pris en compte.

4.10.8 Restriction des utilisateurs

Parfois, vous pensez avoir besoin d'utilisateurs créés dans votre système local de façon à fournir un service donné (service courrier pop3 ou ftp). Avant tout, rappelez-vous que l'implémentation PAM dans Debian GNU/Linux vous autorise à valider les utilisateurs avec une grande variété de répertoires de services externes (radius, ldap, etc.) fournis par les paquets libpam.

Si des utilisateurs doivent être créés et que le système est accessible à distance, prenez en compte que des utilisateurs pourront se connecter au système. Ceci peut être corrigé en donnant aux utilisateurs un shell null (/dev/null) (il devra être listé dans /etc/shells). Si vous voulez autoriser les utilisateurs à accéder au système mais limiter leurs mouvements, vous pouvez utiliser le fichier /bin/rbash, ce qui est équivalent à l'ajout de l'option -r dans bash (RESTRICTED SHELL voir bash(1)). Veuillez noter que même avec un shell restreint, un utilisateur ayant accès à un programme interactif (qui peut permettre l'exécution d'un sous-shell) peut être capable de passer outre les limites du shell.

Debian fournit actuellement dans la version unstable le module pam_chroot (dans le paquet libpam-chroot) (et il pourrait être inclus dans les prochaines versions stables). Une alternative à celui-ci est de chrooter le service qui fournit la connexion à distance (ssh, telnet). [21]

Si vous voulez restreindre quand les utilisateurs peuvent accéder au système, vous devrez personnaliser /etc/security/access.conf en fonction de vos besoins.

Des informations sur comment chrooter des utilisateurs accédant au système par le service ssh sont décrites dans Environnement de chroot pour SSH, Annexe G.

4.10.9 Audit d'utilisateur

Si vous êtes vraiment paranoïaque, il se peut que vous vouliez configurer pour le système un fichier de configuration qui configure l'environnement pour auditer ce que les utilisateurs font sur votre système. Cette section présente quelques conseils avec différents utilitaires que vous pouvez utiliser.

4.10.9.1 Audit d'entrée et sortie avec script

Vous pouvez utiliser la commande script pour auditer à la fois ce que les utilisateurs exécutent et quels sont les résultats de leurs commandes. Vous ne pouvez configurer script comme un shell (même si vous l'ajoutez à /etc/shells). Mais vous pouvez faire en sorte que le fichier d'initialisation su shell exécute les commandes suivantes : 

     umask 077
     exec script -q -a "/var/log/sessions/$USER"

Bien sûr, si vous faites cela pour tout le système, cela veut dire que le shell ne continuerait pas à lire les fichiers d'initialisation personnels (car le shell sera écrasé par script). Une alternative est de faire cela dans les fichiers d'initialisation de l'utilisateur (mais alorsl'utilisateur pourrait l'enlever, voir les commentaires sur cela ci-dessous).

Vous devez également configurer les fichiers dans le répertoire d'audit (dans l'exemple /var/log/sessions/) pour que les utilisateurs puissent y écrire, mais pas supprimer le fichier. Cela pourrait être fait, par exemple, en créant les fichiers de session d'utilisateur en avance et en leur positionnant le drapeau ajout-seulement (« append-only ») en utilisant chattr.

Une alternative utile pour les administrateurs système, qui inclut des informations de date, serait : 

     umask 077
     exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"

4.10.9.2 Utiliser le fichier d'historique du shell

Si vous voulez passer en revue ce que les utilisateurs entrent dans le shell (mais pas voir le résultat), vous pouvez configurer un /etc/profile pour tout le système qui configure l'environnement pour que toutes les commandes soient sauvées dans le fichier d'historique. La configuration pour tout le système doit être réalisée de telle façon que les utilisateurs ne puissent pas enlever les capacités d'audit de leur shell. Cela est plutôt spécifique au shell, donc assurez-vous que tous les utilisateurs utilisent un shell qui le gère.

Par exemple, pour bash, le fichier /etc/profile pourrait être paramétré ainsi [22] : 

       HISTFILE=~/.bash_history
       HISTSIZE=10000
       HISTFILESIZE=999999
       # Empêche les utilisateurs d'entrer des commandes qui seraient
       # ignorées dans le fichier d'historique
       HISTIGNORE=""
       HISTCONTROL=""
       readonly HISTFILE
       readonly HISTSIZE
       readonly HISTFILESIZE
       readonly HISTIGNORE
       readonly HISTCONTROL
       export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL

Afin que cela fonctionne, l'utilisateur doit être seulement capable d'ajouter des informations au fichier .bash_history. Vous devez aussi positionner l'attribut ajout-uniquement en utilisant le programme chattr sur .bash_history pour tous les utilisateurs. [23]

Notez que vous pouvez introduire la configuration ci-dessus dans le fichier utilisateur .profile. Mais alors vous devriez configurer les permissions correctement de façon à empêcher à l'utilisateur de modifier ce fichier. Cela inclut : les répertoires personnels de l'utilisateur ne doivent pas appartenir à l'utilisateur (sinon, il pourrait supprimer le fichier), mais en même temps lui permettre de lire le fichier de configuration .profile et d'écrire dans .bash_history. Il serait bien de configurer l'attribut immuable (également en utilisant chattr) pour le .profile aussi si vous procédez ainsi.

4.10.9.3 Audit utilisateur complet avec utilitaires de comptabilité

L'exemple précédent est une manière simple de configurer l'audit utilisateur, mais qui peut ne pas être utile pour des systèmes complexes ou pour ceux dans lesquels les utilisateurs ne peuvent pas exécuter de shell du tout (ou exclusivement). Si c'est votre cas, vous devrez examiner acct, les utilitaires de comptabilité. Ces utilitaires archiveront toutes les commandes exécutées par les utilisateurs ou processus du système au détriment de l'espace disque.

Lors de l'activation de la comptabilité, toutes les informations sur les processus et utilisateurs sont conservées dans /var/account/, plus spécifiquement dans le fichier pacct. Le paquet de comptabilité inclut certains outils (sa et ac) afin d'analyser ces données.

4.10.9.4 Autres méthodes d'audit utilisateur

Si vous êtes complètement paranoïaque et que vous voulez auditer toutes les commandes des utilisateurs, vous pouvez prendre les codes sources du bash, les éditer et récupérer dans un fichier toutes les commandes que l'utilisateur tape. Ou avoir ttysnoop constamment en attente de nouveaux ttys [24] et reverser toutes les sorties dans un fichier. Un autre programme utile est snoopy (voir également la page du projet) qui est un programme transparent pour l'utilisateur qui se positionne comme une librairie fournissant une encapsulation des appels execve(), toute commande exécutée est loguée par syslogd en utilisant la facilité authpriv (généralement stocké dans /var/log/auth.log).

4.10.10 Inspection des profils utilisateurs

Si vous désirez voir ce que font vraiment les utilisateurs, comme l'heure à laquelle ils se connectent, vous pouvez utiliser la base de données wtmp qui contient toutes les informations concernant les connexions. Ce fichier peut être employé avec plusieurs utilitaires, parmi eux sac qui peut sortir un profil de chaque utilisateur montrant dans quel créneau horaire ils se connectent au système habituellement.

Dans le cas où vous avez la comptabilité activée, vous pouvez également utiliser les outils qu'elle fournit pour déterminer quand les utilisateurs accèdent au système et ce qu'ils exécutent.

4.10.11 Positionner des umasks aux utilisateurs

Selon vos règles d'utilisation, vous pouvez vouloir changer comment les utilisateurs peuvent partager des informations, c'est-à-dire, quelles sont les permissions par défaut des fichiers nouvellements créés par les utilisateurs. Ce changement est effectué en définissant un paramètre umask correct pour tous les utilisateurs. Vous pouvez changer le paramètre UMASK dans /etc/limits.conf, /etc/profile, /etc/csh.cshrc, /etc/csh.login, /etc/zshrc et probablement dans d'autres fichiers (selon les shells que vous avez installé sur votre système). Parmi ceux-ci, le dernier à être chargé prendra précédence sur les autres. L'ordre est : le limits.conf de PAM, la configuration système par défaut du shell de l'utilisateur, le shell de l'utilisateur (son ~/.profile, ~/.bash_profile, etc.).

Le paramètre umask par défaut de Debian est 022, ceci veut dire que les fichiers (et les répertoires) peuvent être lus et accédés par le groupe de l'utilisateur et par tout autre utilisateur du système. Si cela est trop permissif pour votre système, vous devrez changer ce paramètre umask pour tous les shells (et pour PAM). N'oubliez pas de modifier les fichiers sous /etc/skel/ car ce seront les valeurs par défaut d'un nouvel utilisateur quand il sera créé par la commande adduser.

Notez, cependant, que les utilisateurs peuvent modifier leur propre paramètre umask s'ils le désirent, le rendant plus permissif ou plus restrictif.

4.10.12 Limiter ce que les utilisateurs peuvent voir et accéder

FIXME : Besoin de contenu. Indiquer les conséquences de changement des permissions des paquets lors d'une mise à jour (et un administrateur aussi paranoïaque que cela devrait chrooter ses utilisateurs).

Si vous avez besoin d'accorder aux utilisateurs un accès au système avec un shell, réfléchissez-y très soigneusement. Un utilisateur peut, par défaut à moins d'être dans un environnement extrèmement restreint (comme une prison chroot), récupérer un assez grand nombre d'informations concernant votre système, y compris :

Que peut voir un utilisateur dans votre système ? Probablement un assez grand nombre de choses, essayez ceci (prenez une profonde respiration) : 

       find / -type f -a -perm +006 2>/dev/null  
       find / -type d -a -perm +007 2>/dev/null

La liste des fichiers qu'un utilisateur peut voir et des répertoires auxquels il a accès est affichée.

4.10.12.1 Limiter l'accès aux informations d'autres utilisateurs

Si vous accordez toujours un accès shell aux utilisateurs, vous pouvez vouloir limiter les informations qu'ils peuvent voir des autres utilisateurs. Les utilisateurs ayant un accès shell ont tendance à créer un grand nombre de fichiers dans leur répertoire $HOME : boîtes à lettres, documents personnels, configuration des applications X/GNOME/KDE, etc.

Sous Debian, chaque utilisateur est créé avec un groupe associé et aucun utilisateur n'appartient au groupe d'un autre utilisateur. Il s'agit du comportement par défaut : quand un compte d'utilisateur est créé, un groupe du même nom est créé et l'utilisateur lui est assigné. Ceci évite le concept d'un groupe users qui peut rendre plus difficile pour les utilisateurs de cacher des informations aux autres utilisateurs.

Cependant, les répertoires $HOME des utilisateurs sont créés avec les permissions 0755 (lisible par le groupe et par tout le monde). Les permissions de groupe ne sont pas un problème car seul l'utilisateur appartient au groupe, cependant les permissions pour les autres peut être (ou non) un problème selon vos règles locales.

Vous pouvez changer ce comportement pour la création de l'utilisateur fournisse des permissions sur $HOME différentes. Pour changer ce comportement pour les nouveaux utilisateurs quand il seront créés, changez DIR_MODE dans le fichier de configuration /etc/adduser.conf à 0750 (pas d'accès en lecture pour tout le monde).

Les utilisateurs peuvent toujours partager des informations, mais directement dans leur répertoire $HOME à moins qu'ils change les permissions de celui-ci.

Notez que désactiver les répertoires utilisateur lisibles par tout le monde empêchera les utilisateurs de créer leurs pages personnelles dans le répertoire ~/public_html car le serveur web ne pourra pas lire un composant du chemin — leur répertoire $HOME. Si vous voulez permettre aux utilisateurs de publier des pages HTML dans leur ~/public_html, changez DIR_MODE en 0751. Ceci permettra au serveur web d'accéder à ce répertoire (qui devrait lui-même avoir le mode 0755) et de fournir le contenu publié par les utilisateurs. Bien sûr, nous ne parlons ici que d'une configuration par défaut ; les utilisateurs peuvent généralement ajuster les permissions de leurs fichiers comme ils le désirent, ou vous pouvez conserver le contenu destiné au web dans un emplacement séparé qui n'est pas un sous-répertoire du répertoire $HOME de chaque utilisateur.

4.10.13 Générer des mots de passe utilisateur

Il y a plusieurs cas dans lesquels un utilisateur a besoin de créer un grand nombre de comptes utilisateur et de fournir des mots de passe pour tous ceux-ci. Bien sûr, l'administrateur peut facilement positionner le mot de passer pour être le même que le nom du compte utilisateur, mais ceci n'est pas très conseillé sur le plan de la sécurité. Une meilleure approche est d'utiliser un programme de génération de mots de passe. Debian fournit les paquets makepasswd, apg et pwgen qui contiennent des programmes (dont le nom est le même que celui du paquet) qui peuvent être utilisés dans ce but. Makepasswd génère des mots de passe vraiment aléatoires avec un accent sur la sécurité plus que la prononçabilité tandis que pwgen essaie de créer des mots de passe sans signification, mais prononçables (bien sûr, cela dépend de votre langue maternelle). Apg dispose d'algorithmes pour les deux (il y a une version client/serveur pour ce programme, mais elle n'est pas incluse dans le paquet Debian).

Passwd ne permet pas une assignation non interactive des mots de passe (car il utilise un accès direct au terminal tty). Si vous désirez changer des mots de passe lors de la création d'un grand nombre d'utilisateurs, vous pouvez les créer en utilisant adduser avec l'option --disabled-login, puis utiliser usermod ou chpasswd [25] (tous les deux dans le paquet passwd, vous les avez donc déjà d'installés). Si vous voulez utilisez un fichier avec toutes les informations pour créer les utilisateurs comme un processus batch, il sera probablement préférable d'utiliser newusers.

4.10.14 Vérifier les mots de passe utilisateur

Les mots de passe des utilisateurs peuvent parfois devenir le maillon faible de la sécurité d'un système donné. Cela provient du fait que quelques utilisateurs choisissent des mots de passe faibles pour leur compte (et plus il y a d'utilisateurs, plus sont grandes les chances que cela se produise). Même si vous mettez en place des vérifications avec le module PAM cracklib et les limitations sur les mots de passe comme décrites dans Authentification utilisateur : PAM, Section 4.10.1, les utilisateurs pourront toujours utiliser des mots de passe faibles. Comme l'accès utilisateur peut inclure un accès à un shell à distance (on espère, par ssh), il est important de rendre les mots de passe aussi difficile à deviner que possible pour les attaquants à distance, particulièrement s'ils ont pu récupérer des informations importantes comme les noms d'utilisateur ou même les fichiers passwd et shadow eux-mêmes.

Un administrateur système doit, pour un nombre d'utilisateurs donnés, vérifier si les mots de passe sont cohérents avec la règle locale de sécurité. Comment vérifier ? Essayez de les cracker comme le ferait un attaquant s'il avait accès aux mots de passe hachés (le fichier /etc/shadow).

Un administrateur peut utiliser john ou crack (tous deux utilisent la force brute pour cracker) ensemble avec une liste de mots appropriés pour vérifier les mots de passe utilisateurs et prendre des mesures appropriées si un mot de passe faible est détecté. Vous pouvez rechercher des paquets Debian contenant des listes de mots en utilisant apt-cache search wordlist ou vous pouvez également visiter des sites de listes de mots sur l'Internet classique comme ftp://ftp.ox.ac.uk/pub/wordlists ou ftp://ftp.cerias.purdue.edu/pub/dict.

4.10.15 Déconnecter les utilisateurs inactifs (idle)

L'inactivité des utilisateurs pose habituellement un problème de sécurité, un utilisateur peut être inactif parce qu'il est parti déjeuner ou parce qu'une connexion à distance s'est bloquée et n'a pas été rétablie. Quelqu'en soit la raison, les utilisateurs inactifs peuvent amener à une compromission :

Certains systèmes à distance ont même été compromis à travers un screen inactif (et détaché) .

La déconnexion automatique des utilisateurs inactifs est habituellement une partie qui doit être imposée par les règles de sécurité locales. Il y a plusieurs moyens de faire cela :

Les démons timeoutd et autolog sont les méthodes préférées car, après tout, les utilisateurs peuvent changer leur shell par défaut ou il peuvent après avoir exécuter leus shell par défaut, basculer sur un autre shell (non contrôlé).

4.11 Utilisation de tcpwrappers

Les TCP wrappers ont été développés quand il n'y avait pas de réels filtres de paquets de disponible et que les contrôles d'accès étaient nécessaires. Toutefois, ils sont toujours très intéressants et utiles. Les TCP wrappers vous permettent d'autoriser ou de refuser un service à un hôte ou à un domaine et de définir une règle par défaut pour les autorisations et les refus (toutes réalisées au niveau applicatif). Pour plus de détails, jetez un œil à hosts_access(5).

De nombreux services installés dans Debian sont soit :

D'un côté, pour des services configurés dans /etc/inetd.conf, ceci incluant telnet, ftp, netbios, swat et finger), vous observerez que le fichier de configuration exécute avant tout /usr/sbin/tcpd. D'un autre côté, même si un service n'est pas lancé par le super démon inetd, il peut être compilé avec le support pour les règles des tcp wrappers. Les services compilés avec support tcp wrappers dans Debian incluent ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf (le démon d'activation GNOME), nessus et beaucoup d'autres.

Pour voir quels paquets utilisent tcpwrappers, essayez ceci : 

       $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
             sed 's/,libwrap0$//;s/^[[:space:]]\+//'

Tenez compte de ceci quand vous utilisez tcpdchk (un vérificateur très utile de règles et syntaxe de fichier de configuration de TCP wrappers). Quand vous pouvez ajouter des services indépendants (qui sont liés à la bibliothèque du wrapper) dans les fichiers host.deny et hosts.allow, tcpdchk vous informera qu'il ne peut pas trouver les services mentionnés étant donné qu'il les cherche dans /etc/inetd.conf (la page de manuel n'est pas totalement précise ici).

À présent, voici une petite astuce et probablement le plus petit système de détection d'intrusions disponible. Généralement, vous devriez disposer d'une politique correcte concernant le pare-feu en première ligne, puis disposer de tcp wrappers en seconde ligne de défense. Un petit truc est de mettre en place une commande SPAWN [26] dans /etc/hosts.deny qui enverra un courrier à root quand un déclencheur wrapper pour service dénié est rencontré : 

       ALL: ALL: SPAWN ( \
         echo -e "\n\
         TCP Wrappers\: Connection refused\n\
         By\: $(uname -n)\n\
         Process\: %d (pid %p)\n\
         User\: %u\n\
         Host\: %c\n\
         Date\: $(date)\n\
       " | /usr/bin/mail -s "Connection to %d blocked" root) &

Attention : L'exemple ci-dessus peut-être facilement sujet à une attaque par déni de service en soumettant énormément de connexions dans une période très courte. De nombreux courriers signifient de nombreuses E/S en envoyant uniquement quelques paquets.

4.12 L'importance des logs et des alertes

Il est facile de voir que le traitement de logs et alertes est un problème sérieux sur un système sécurisé. Supposons qu'un système est parfaitement configuré et sécurisé à 99%. Si l'attaque représentant le 1% vient à arriver et qu'il n'y a pas de mesures de sécurité mises en place pour, dans un premier temps, détecter ceci et dans un deuxième temps, lancer l'alerte, le système n'est pas sécurisé du tout.

Debian GNU/Linux fournit quelques outils pour effectuer des analyses de logs, notamment swatch[27], logcheck ou log-analysis (tous ont besoin d'être personnalisés pour enlever les choses non nécessaires des comptes-rendus). Il peut être également utile, si le système est proche, d'avoir les logs du système d'affichés sur une console virtuelle. Ceci est utile car vous pouvez (depuis une distance) voir si le système se comporte correctement. Le fichier /etc/syslog.conf de Debian est fourni avec une configuration commentée par défaut ; pour l'activer, décommenter les lignes et redémarrez syslogd (/etc/init.d/syslogd restart) : 

       daemon,mail.*;\
             news.=crit;news.=err;news.=notice;\
             *.=debug;*.=info;\
             *.=notice;*.=warn       /dev/tty8

Pour colorer les journaux, vous pouvez jeter un œil à colorize, ccze ou glark.

Il y a une grande partie sur l'analyse des log qui ne peut pas être couverte ici, une bonne ressource d'information est le site web Log Analysis. Dans tous les cas, même des outils automatiques ne peuvent rivaliser avec le meilleur outil d'analyse : votre cerveau.

4.12.1 Utiliser et personnaliser logcheck

Le paquet logcheck dans Debian est divisé en trois paquets logcheck (le programme principal), logcheck-database (une base de données d'expressions rationnelles pour le programme) et logtail (affiche les lignes de log qui n'ont pas encore été lues). Le comportement par défaut sous Debian (dans /etc/cron.d/logcheck) est que logcheck est exécuté toutes les heures et une fois après le démarrage.

Cet outil peut être assez utile s'il est personnalisé correctement pour alerter l'administrateur d'événements système inhabituels. logcheck peut être complètement personnalisé pour envoyer des courriers selon les événements récupérés des logs et qui sont dignes d'attention. L'installation par défaut inclut des profils pour des événements ignorés et des violations de règles pour trois configurations différentes (station de travail, serveur et paranoïaque). Le paquet Debian inclut un fichier de configuration /etc/logcheck/logcheck.conf, sourcé par le programme, qui définit à quel utilisateur sont envoyés les vérifications. Il fournit également un moyen pour les paquets qui fournissent des services pour implémenter de nouvelles règles dans les répertoires : /etc/logcheck/cracking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_ et /etc/logcheck/ignore.d.workstation/_packagename_. Cependant, peu de paquets le font actuellement. Si vous avez une règle qui peut être utile à d'autres utilisateurs, veuillez l'envoyer comme un rapport de bogue sur le paquet approprié (comme un bogue de gravité wishlist). Pour plus d'informations, veuillez lire /usr/share/doc/logcheck/README.Debian.

Le meilleur moyen de configurer logcheck est d'éditer son fichier de configuration principal /etc/logcheck/logcheck.conf après l'avoir installé. Modifiez l'utilisateur par défaut (root) à qui seront envoyés par courrier les comptes-rendus. Vous devriez également y positionner le niveau de compte-rendu. logcheck-database a trois niveaux de compte-rendu de verbosité croissante : station de travail, serveur, paranoïaque. « serveur » étant le niveau par défaut, « paranoïaque » n'est recommandé que pour les machines de haute sécurité ne faisant fonctionner qu'aussi peu de services que possible et « station de travail » est pour les machines relativement protégés et non critiques. Si vous désirez ajouter de nouveaux fichiers journaux, ajoutez-les simplement à /etc/logcheck/logcheck.logfiles. Celui-ci est configuré pour une installation de syslog par défaut.

Une fois ceci fait, vous pouvez vouloir vérifier les courriers envoyés, pour les quelques premiers jours/semaines/mois. Si vous trouvez que vous recevez des messages que vous ne voulez pas recevoir, ajoutez simplement l'expression rationnalle (voir regex(7) et egrep(1)) qui correspond à ces messages au fichier /etc/logcheck/ignore.d.reportlevel/local. Essayez de faire correspondre à la ligne de log entière. Des détails sur l'écriture des règles sont expliquées dans /usr/share/doc/logcheck-database/README.logcheck-database.gz. C'est un processus d'affinement perpétuel ; une fois que les messages qui sont envoyés sont toujours pertinents, vous pouvez considérer que l'affinement est terminé. Notez que si logcheck ne trouve rien de pertinent dans votre système, il ne vous enverra pas de courrier même s'il fonctionne (donc, vous pouvez ne recevoir de courrier qu'une fois par semaine si vous êtes chanceux).

4.12.2 Configurer l'endroit où les alertes sont envoyées

Debian livre une configuration standard de syslog (dans /etc/syslog.conf) qui archive les messages dans les fichiers appropriés dépendant de la facilité du système. Vous devriez être familier avec ceci ; jetez un œil au fichier syslog.conf et à la documentation si vous ne l'êtes pas. Si vous avez l'intention de maintenir un système sécurisé, vous devriez être conscient de l'endroit où les logs sont envoyées ainsi ils ne sont pas perdus dans la nature.

Par exemple, envoyer des messages à la console est également utile pour de nombreux systèmes de production. Mais pour de nombreux systèmes semblables il est également important d'ajouter une nouvelle machine qui servira de serveur de log (il reçoit les logs de tous les autres systèmes).

Le courrier de root devrait être pris en considération également, de nombreux contrôles de sécurité (tel snort) envoient des alertes dans la boîte aux lettres de root. Celle-ci pointe généralement sur le premier utilisateur créé sur le système (vérifiez /etc/aliases). Prenez garde à envoyer le courrier du root à un endroit où il sera lu (soit localement soit à distance).

Il y a d'autres comptes et alias « rôles » sur votre système. Sur un petit système, c'est probablement le plus simple de s'assurer que tous ces alias pointent vers le compte root, et que ce mail pour root est retransmis vers la boîte aux lettres personnelle de l'administrateur système.

FIXME: Il serait intéressant de dire comment un système Debian peut envoyer/recevoir des messages SNMP relatifs à des problèmes de sécurité (jfs). Voir : snmptragfmt, snmp et snmpd.

4.12.3 Utilisation d'un hôte d'archivage (loghost)

Un loghost est un hôte qui recueille les données des syslog à travers le réseau. Si l'une de vos machines est piratée, l'intrus n'est pas capable de dissimuler ses traces, à moins qu'il ne pirate également le loghost. Par conséquent, le loghost devrait être particulièrement sécurisé. Faire d'une machine un loghost est simple. Il suffit juste de démarrer le syslogd avec syslogd -r et un nouveau loghost est né. De façon à rendre cela permanent dans Debian, éditez /etc/init.d/sysklogd et changez la ligne 

       SYSLOGD=""

par 

       SYSLOGD="-r"

Ensuite, configurez les autres machines afin qu'elles envoient les données au loghost. Ajoutez une entrée comme celle qui suit dans /etc/syslog.conf : 

       facilité.niveau           @votre_loghost

Voyez la documentation pour savoir ce qu'on peut utiliser à la place de facilité et niveau (ils ne devraient pas être mot pour mot comme ceci). Si vous voulez tout archiver à distance, il suffit d'écrire : 

       *.*                       @votre_loghost

dans votre syslog.conf. Archiver à distance ainsi que localement est la meilleure solution (le pirate peut estimer avoir couvert ses traces après la suppression des fichiers de logs locaux). Voir les pages de manuel syslog(3), syslogd(8) et syslog.conf(5) pour toutes informations complémentaires.

4.12.4 Permissions du fichier d'archivage

Il est important de décider non seulement comment les alertes sont utilisées, mais aussi qui y accède, i.e. qui peut lire ou modifier les fichiers de log (si on n'utilise pas un hôte d'archivage). Les alertes de sécurité que l'attaquant peut changer ou désactiver sont de peu de valeur en cas d'intrusion. Vous devez également tenir compte que les fichiers de log peuvent révéler un grand nombre d'informations à propos de votre système à un intrus s'il y a accès.

Certaines permissions de fichiers de log ne sont pas parfaites après l'installation (mais, bien sûr, cela dépend vraiment de vos règles de sécurité locales). Premièrement /var/log/lastlog et /var/log/faillog n'ont pas besoin d'être lisibles par les utilisateurs normaux. Dans le lastlog, vous pouvez voir qui s'est connecté récemment, et dans le faillog, vous voyez un résumé des connexions qui ont échouées. L'auteur recommande de un chmod 660 sur les deux fichiers. Faites un tour rapide de vos fichiers de log et décidez avec beaucoup d'attention quels fichiers de log vous rendez lisible/modifiable par un utilisateur avec un UID différent de 0 et un groupe autre que « adm » ou « root ». Vous pouvez facilement vérifier ceci sur votre système avec : 

       #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
       (voir à quels utilisateurs appartiennent les fichiers de /var/log)
       #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
       (voir à quels groups appartiennent les fichiers de /var/log)
       # find /var/log -perm +004
       (fichiers lisibles par tout utilisateur)
       #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
       (fichiers appartenant à des groupes autres que root ou adm)

Pour personnaliser comment les fichiers de log sont créés, vous devez probablement personnaliser le programme qui les génère. Cependant, si le fichier de log est archivé, vous pouvez personnaliser le comportement de la création et de l'archivage.

4.13 Les utilitaires pour ajouter des rustines au noyau

FIXME: Cette section a besoin de couvrir la manière d'installer ces rustines spécifiques sur Debian en utilisant les paquets kernel-2.x.x-patch-XXX.

Debian GNU/Linux fournit quelques rustines pour le noyau Linux qui améliorent sa sécurité du système. En voici quelques-unes :

Les correctifs de sécurité du noyau suivants ne sont disponibles que pour d'anciennes versions du noyau dans Woody et ils sont obsolètes :

Cependant, certaines rustines ne sont pas encore fournies dans Debian. Si vous croyez que certaines devraient être incluses, veuillez le demander sur la page des paquets en souffrance et paquets prospectifs. Certains d'entre eux sont :

4.14 Se protéger contre les dépassements de tampon

Dépassement de tampon est le nom d'une attaque courante sur un logiciel[29] qui utilise insuffisamment des vérifications de limites (une erreur de programmation courante, le plus communément dans le langage C) pour exécuter du code machine par des entrées de programme. Ces attaques, contre des logiciels serveurs qui attendent des connexions distantes et contre des logiciels locaux qui autorisent des privilèges élevés aux utilisateurs (setuid ou setgid) peuvent résulter en la compromission de tout système donné.

Il y a dans l'ensemble quatre méthodes pour se protéger contre les dépassement de tampon :

Debian GNU/Linux, dans sa version 3.0, fournit des logiciels pour implémenter toutes ces méthodes à l'exception de la protection de la compilation du code source (mais ceci a été demandé dans le bogue n°\|[nbsp ]\|213994).

Notez que même si Debian fournissait un compilateur qui fournit cette fonction de protection de dépassement de tampon/pile, tous les paquets auraient besoin d'être recompilés pour introduire cette fonctionnalité. C'est, en fait, ce que fait Adamantix (entre autres fonctionnalités). L'effet de cette nouvelle fonctionnalité sur la stabilité des logiciels doit encore être déterminée (certains programmes ou architectures de processeur pourraient être cassés à cause d'elle).

Dans tous les cas, soyez conscient que même ces contournement peuvent ne pas prévenir les dépassements de tampon cas il existe des moyens de circonvenir ceux-ci, comme décrit dans l'édition 58 du magazine phrack ou dans l'alerte du CORE Failles multiples dans les technologies de protection d'écrasement de la pile.

Si vous voulez tester votre protection contre les dépassements de tampon, une fois que vous avez mis une en place (quelque que soit la méthode), vous pouvez vouloir installer le paxtest et exécuter les tests qu'il fournit.

4.14.1 Correctif du noyau de protection pour les dépassements de tampon

Des correctifs du noyau liés aux dépassements de tampon incluant le correctif Openwall fournissent une protection contre les dépassements de tampon dans les noyaux Linux 2.2. Pour les noyaux 2.4 et plus récents, vous devrez utiliser l'implémentation Exec-shield ou l'implémentation PaX (fourni dans le correctif grsecurity, kernel-patch-2.4-grsecurity et dans le correctif Adamantix, kernel-patch-adamantix). Pour plus d'informations sur l'utilisation de ces correctifs, veuillez lire la section Les utilitaires pour ajouter des rustines au noyau, Section 4.13.

4.14.2 Protection Libsafe

Protéger un système Debian GNU/Linux avec libsafe est plutôt facile. Installez simplement le paquet et répondez Yes pour avoir la bibliothèque préchargée globalement. Soyez attentif, cependant, car cela peut casser des logiciels (notamment, des programmes liés avec l'ancienne libc5), donc assurez-vous de lire les rapports de bogue rapportés en premier et testez d'abord les programmes les plus critiques dans votre logiciel avec le programme d'enveloppement libsafe.

Note importante : la protection Libsafe peut ne pas être actuellement effective comme décrit dans 173227. Considérez de le tester de manière approfondie avant de l'utiliser dans un environnement de production et ne dépendez pas exclusivement dessus pour protéger votre système.

4.14.3 Tester des programmes pour les dépassements

L'utilisation d'outils pour détecter des dépassements de tampon nécessitent dans tous les cas une expérience de programmation pour corriger (et recompiler) le code. Debian fournit par exemple : bfbtester (un testeur de dépassement de tampon qui brutalise des binaires par la force par des dépassements de ligne de commande et d'environnement). D'autres paquets intéressants pourraient aussi être rats, pscan, flawfinder et splint.

4.15 Sécurisation des transferts de fichiers

Pendant l'administration normale du système, il est habituellement nécessaire de transférer des fichiers à partir et vers le système installé. La copie des fichiers de façon sécurisée d'un hôte vers un autre peut être effectuée en utilisant le paquet serveur ssh. Une autre possibilité est d'utiliser ftpd-ssl, un serveur FTP qui utilise Secure Socket Layer pour encrypter les transmissions.

Toutes ces méthodes nécessitent des clients spécifiques. Debian fournit des clients logiciels, comme scp du paquet ssh, qui fonctionne comme rcp, mais est complètement encrypté, donc les méchants ne peuvent même pas savoir CE QUE vous copiez. Il existe également un paquet client ftp-ssl pour le serveur équivalent. Vous pouvez trouver des clients pour ces logiciels, même pour d'autres systèmes d'exploitation (non-UNIX), putty et winscp fournissent des implémentations de copie sécurisée pour toutes les versions des systèmes d'exploitation de Microsoft.

Notez qu'utiliser scp fournit un accès pour tous les utilisateurs à tout le système de fichiers à moins de faire un chroot comme décrit dans Chrooter ssh, Section 5.1.1. L'accès FTP peut être chrooté, ceci est probablement plus facile selon le démon que vous choisissez, comme décrit dans Sécurisation FTP, Section 5.3. Si vous vous inquiétez d'utilisateurs locaux pouvant parcourir vos fichiers locaux et que vous voulez avoir une communication encryptée, vous pouvez utiliser soit un démon FTP avec support SSL ou combiner un FTP sans cryptage avec une configuration VPN (voir Réseaux Privés Virtuels, Section 8.5).

4.16 Limites et contrôle des systèmes de fichiers

4.16.1 Utilisation de quotas

Avoir une bonne politique relative aux quotas est important, vu qu'elle empêche les utilisateurs de remplir le(s) disque(s) dur(s).

Vous pouvez utiliser deux systèmes de quotas différents : les quotas utilisateur et les quotas groupe. Comme vous l'avez probablement deviné, les quotas utilisateur limitent la quantité d'espace qu'un utilisateur peut avoir, les quotas groupe quant à eux font la même chose pour les groupes. Retenez ceci quand vous calculerez les tailles des quotas.

Il y a quelques points importants auxquels il faut penser dans la mise en place d'un système de quotas :

Tous les répertoires et partitions auxquels les utilisateurs ont accès en écriture complet devraient avoir les quotas d'activés. Recherchez ces partitions et répertoires et calculez une taille adaptée qui combine disponibilité et sécurité.

Bon, maintenant vous désirez utiliser les quotas. Avant tout, vous avez besoin de vérifier si vous avez activé le support du quota dans votre noyau. Si non, vous devrez le recompiler. Après cela, contrôlez si le paquet quota est installé. Si non, vous en aurez également besoin.

L'activation des quotas pour des systèmes de fichiers différents est aussi facile que la modification du paramètre defaults en defaults,usrquota dans votre fichier /etc/fstab. Si vous avez besoin des quotas par groupe, remplacez usrquota par grpquota. Vous pouvez également utiliser les deux. Ensuite, créez des fichiers vides quota.user et quota.group à la racine du système de fichiers sur lequel vous voulez utiliser les quotas (touch /home/quota.user /home/quota.group pour un système de fichiers /home).

Redémarrez quota en faisant /etc/init.d/quota stop;/etc/init.d/quota start. Maintenant les quotas devraient être en fonction et leurs tailles peuvent être configurées.

L'édition de quotas pour un utilisateur spécifique peut être réalisée en faisant edquota -u <user>. Les quotas par groupes peuvent être modifiés avec edquota -g <group>. Ensuite, paramétrez les quotas soft et hard et/ou les quotas pour inodes selon vos besoins.

Pour plus d'informations concernant les quotas, voir la page de manuel de la commande quota et le quota mini-howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html). Vous pouvez également vouloir étudier pam_limits.so.

Vous pouvez apprécier ou non lshell, puisque il transgresse le FHS. Aussi prenez note que pam_limits.so peut vous fournir la même fonctionnalité et lshell est actuellement orphelin

4.16.2 Les attributs spécifiques du système de fichiers ext2 (chattr/lsattr)

En plus des permissions standard Unix, les systèmes de fichiers ext2 et ext3 vous offrent un ensemble d'attributs spécifiques qui vous donne plus de contrôle sur les fichiers de votre système. À la différence des persmissions de base, ces attributs ne sont pas affichés par la commande standard ls -l, ni changés par la commande chmod et vous avez besoin de deux autres utilitaires, lsattr et chattr (du paquet e2fsprogs) pour les gérer. Notez que ceci veut dire que ces attributs ne sont habituellement pas sauvés quand vous sauvegardez le système, donc si vous changez l'un d'entre eux, il peux être utile de sauver les commandes chattr successives dans un script pour pouvoir les repositionner plus tard si vous avez à récupérer une sauvegarde.

Parmi tous les attributs disponibles, les deux plus importants pour améliorer la sécurité sont référencés par les lettres « i » et « a » et ils ne peuvent être positionnés (ou enlevés) que le super-utilisateur :

Ces attributs peuvent également être positionnés pour les répertoires, dans ce cas, le droit de modifier le contenu de la liste d'un répertoire est refusé (par exemple, renommer ou supprimer un fichier, etc.). Quand il est appliqué à un répertoire, l'attribut d'ajout ne permet que la création de fichiers.

Il est aisé de voir que l'attribut « a » améliore la sécurité, en donnant aux programmes qui ne fonctionnent pas en tant que super-utilisateur, la possibilité d'ajouter des données à un fichier sans pouvoir modifier son précédent contenu. D'un autre côté, l'attribut « i » semble moins intéressant : après tout, le super-utilisateur peut déjà utiliser les permissions standards Unix pour restreindre l'accès à un fichier et un intrus qui aurait accès au compte super-utilisateur peut toujours utiliser le programme chattr pour supprimer l'attribut. Un tel intrus peut tout d'abord être perplexe quand il se rendra compte qu'il ne peut pas supprimer un fichier, mais vous ne devriez pas supposer qu'il est aveugle —  après tout, il est entré dans votre système ! Certains manuels (y compris une précédente version de ce document) suggèrent de supprimer simplement les programmes chattr et lsattr du système pour améliorer la sécurité, mais ce genre de stratégie, aussi connu comme « sécurité par l'obscurité », doit être absolument évitée, car elle donne un sentiment trompeur de sécurité.

Une façon sûre de résoudre ce problème est d'utiliser les fonctionnalités du noyau Linux, comme décrit dans Défense proactive, Section 9.4.2.1. La fonctionnalité intéressante est appelée ici CAP_LINUX_IMMUTABLE : si vous la supprimez de l'ensemble des fonctionnalités (en utilisant par exemple la commande lcap CAP_LINUX_IMMUTABLE), il ne sera plus possible n'importe quel attribut « a » ou « i » sur votre système, même par le super-utilisateur ! Une stratégie complète serait alors la suivante :

  1. Positionner les attributs « a » et « i » sur tous les fichiers que vous désirez ;

  1. Ajouter la commande lcap CAP_LINUX_IMMUTABLE (ainsi que lcap CAP_SYS_MODULE, comme suggéré dans Défense proactive, Section 9.4.2.1) à l'un des scripts de démarrage ;

  1. Positionner l'attribut « i » sur ce script et d'autres fichiers de démarrage ainsi que sur le binaire lcap lui-même ;

  1. Exécuter la commande ci-dessus manuellement (ou ré-amorcer le système pour vous assurer que tout fonctionner comme prévu).

Maintenant que la fonctionnalité a été enlevée de votre système, un intrus ne peut plus changer aucun attribut des fichiers protégés et donc, il ne peut pas changer ou supprimer les fichiers. S'il force la machine à redémarrer (ce qui est la seule façon de récupérer le jeu de fonctionnalités ), cela sera facile à détecter et la fonctionnalité sera de toute façon enlevée à nouveau dès que le redémarrage du système. La seule façon de changer un fichier protégé serait de ré-amorcer le système en mode utiliseur seul (single-user mode) ou d'utiliser une autre image d'amorçage, deux opérations qui nécessitent un accès physique à la machine !

4.16.3 Vérifier l'intégrité des systèmes de fichiers

Êtes-vous sûr que le /bin/login présent sur votre disque dur soit le même que celui que vous aviez installé il y a de cela quelques mois ? Que faire si c'est une version piratée, qui enregistre les mots de passe entrés dans un fichier caché ou les envoie en clair à travers l'Internet ?

La seule méthode pour avoir un semblant de protection est de vérifier vos fichiers tous les heures/jours/mois (je préfère quotidiennement) en comparant l'actuel et l'ancien md5sum de ce fichier. Deux fichiers ne peuvent avoir le même md5sum (le MD5 est basé sur 128 bits, ainsi la chance que deux fichiers différents aient le même md5sum est approximativement de un sur 3.4e3803), donc de ce côté tout est ok, à moins que quelqu'un ait piraté également l'algorithme qui crée les md5sums sur cette machine. Ceci est extrêmement difficile et très improbable. Vous devriez vraiment prendre en compte que la vérification de vos binaires est très importante étant donné que ceci est un moyen facile de reconnaître des changements sur vos binaires.

Les outils couramment utilisés pour ceci sont sxid, aide (Advanced Intrusion Detection Environment), tripwire, integrit et samhain. Installer debsums vous aidera également à vérifier l'intégrité du système de fichiers en comparant le md5sum de chaque fichier avec celui utilisé dans l'archive des paquets Debian. Mais faites attention : ces fichiers peuvent facilement être modifiés par un attaquant et tous les paquets ne fournissent pas de listes de md5sum pour les binaires qu'ils fournissent. Pour plus d'informations, veuillez lire Faites des tests d'intégrité périodiques, Section 9.2 et Prendre un instantané (snapshot) du système, Section 4.18.

Vous pouvez vouloir utiliser locate pour indexer le système de fichiers en entier ; si vous faites cela, envisagez les implications de cette action. Le paquet findutils de Debian contient locate qui s'exécute en tant qu'utilisateur nobody, ainsi, il indexe les fichiers qui sont visibles à tous les utilisateurs. Cependant, si vous changez son comportement, vous rendrez les emplacements de tous les fichiers visibles à tous les utilisateurs. Si vous voulez indexer tout le système de fichiers (pas les parties que l'utilisateur nobody peut voir), vous pouvez remplacer locate par slocate. slocate est étiqueté comme une version améliorée au niveau sécurité de GNU locate, mais il fournit en fait une fonctionnalité de localisation de fichier supplémentaire. Quand il utilise slocate, l'utilisateur ne peut voir que les fichiers auxquels il a vraiment accès et vous pouvez exclure tout fichier ou répertoire du système. Le paquet slocate exécute le processus de mise à jour avec des privilèges augmentés par rapport à locate et il indexe tous les fichiers. Les utilisateurs peuvent alors rechercher rapidement tout fichier qu'ils peuvent voir. slocate ne leur laisse pas voir les nouveaux fichiers ; il filtre la sortie selon votre UID

FIXME: mentionner les binaires signés utilisant bsign ou elfsign

4.16.4 Mise en place de la vérification setuid

Le paquet Debian checksecurity fournit une tâche cron qui s'exécute tous les jours dans /etc/cron.daily/checksecurity [30]. Cette tâche cron exécutera le script /usr/sbin/checksecurity qui sauvegardera l'information sur les changements.

Le comportement par défaut est de ne pas envoyer cette information au super-utilisateur mais à la place de garder une copie journalière des changements dans /var/log/setuid.changes. Vous devrez positionner la variable MAILTO (dans /etc/checksecurity.conf) à « root » pour que cette information lui soit envoyée. Voir checksecurity(8) pour plus d'informations sur la configuration.

4.17 Sécurisations des accès réseau

FIXME. Besoin de plus de contenu (spécifique Debian)

4.17.1 Configuration des options réseaux du noyau

Beaucoup de fonctionnalités du noyau peuvent être modifiées en cours de fonctionnement en envoyant quelque chose (via la commande echo) dans le système de fichiers /proc ou en utilisant sysctl. En entrant sysctl -A, vous pouvez voir ce que vous pouvez configurer et quelles sont les options, elles peuvent être modifiées en exécutant /sbin/sysctl -w variable=valeur (voir sysctl(8)). Vous aurez seulement en de rares occasions à éditer quelque chose ici, mais vous pouvez augmenter la sécurité de cette manière aussi. Par exemple : 

     net/ipv4/icmp_echo_ignore_broadcasts = 1

C'est un « émulateur Windows » parce que ça agit comme Windows sur les ping de broadcast si celui-ci est positionné à 1. C'est-à-dire que les requêtes ICMP_ECHO envoyées à l'adresse broadcast seront ignorées. Sinon, cela ne fait rien.

Si vous voulez empêcher votre système de répondre aux requêtes d'echo ICMP, activez cette option de configuration : 

     net/ipv4/icmp_echo_ignore_all = 1

Pour enregistrer les paquets avec des adresses impossibles (à cause de routes erronées) sur votre réseau, utilisez : 

     /proc/sys/net/ipv4/conf/all/log_martians = 1

Pour plus d'informations sur ce qui peut être fait avec /proc/sys/net/ipv4/*, lisez /usr/src/linux/Documentation/filesystems/proc.txt. Toutes les options sont décrites de façon complète sous /usr/src/linux/Documentation/networking/ip-sysctl.txt [31].

4.17.2 Configurer syncookies

Cette option est à double tranchant. D'un côté, elle protège votre système contre le syn packet flooding ; d'un autre côté, elle viole les standards définis (RFCs). 

     net/ipv4/tcp_syncookies = 1

Si vous voulez changer cette option à chaque fois que le noyau fonctionne, vous devez le faire dans /etc/network/options en positionnant syncookies=yes. Ceci prendra effet à chaque fois que /etc/init.d/networking est exécuté (ce qui est habituellement fait lors du démarrage) tandis que la commande suivante aura un effet unique jusqu'au prochain redémarrage : 

     echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Cette option n'est dispobile que si vous avez compilé le noyau avec CONFIG_SYNCOOKIES. Tous les noyaux Debian sont compilés avec cette option incluse, mais vous pouvez le vérifier en exécutant : 

     $ sysctl -A |grep syncookies
     net/ipv4/tcp_syncookies = 1

Pour plus d'informations sur les syncookies TCP, lisez http://cr.yp.to/syncookies.html.

4.17.3 Sécurisation du réseau pendant l'amorçage

Quand vous positionnez des options de configuration de réseau du noyau, vous devez le configurer pour que ce soit chargé à chaque fois que le système est redémarré. L'exemple suivant active un grand nombre des options précédentes ainsi que d'autres options utiles.

Il y a en fait deux façons de configurer votre réseau au démarrage. Vous pouvez configurer /etc/sysctl.conf (voir : sysctl.conf(5)) ou introduire un script qui est appelé quand l'interface est activée. La première option sera appliquée à toutes les interfaces alors que la seconde option vous permettra de configurer cela interface par interface.

Un exemple de fichier de configuration /etc/sysctl.conf qui sécurisera quelques options de réseau au niveau du noyau est présenté ci-dessous. Notez les commentaires dans ce fichier, /etc/network/options peut forcer certaines options si elles sont en contradiction avec celles de ce fichier lors de l'exécution de /etc/init.d/networking (ce qui a lieu après procps dans la séquence de démarrage) : 

     #
     # /etc/sysctl.conf - Fichier de configuration pour positionner les
     # variables système
     # Voir sysctl.conf (5) pour plus d'informations. Voir également les
     # fichiers sous Documentation/sysctl/, Documentation/filesystems/proc.txt et
     # Documentation/networking/ip-sysctl.txt dans les sources du noyau
     # (/usr/src/kernel-$version si vous avez installé un paquet de noyau) 
     # pour plus d'informations sur les valeurs qui peuvent être définies ici.
     
     #
     # Attention : /etc/init.d/procps est exécuté pour positionner les
     # variables suivantes. Cependant, après cela, /etc/init.d/networking
     # positionne certaines options réseau avec des valeurs intrinsèques. Ces
     # valeurs peuvent être forcées en utilisant /etc/network/options.
     #
     #kernel.domainname = example.com
     
     # Paramètres supplémentaires - adapté du script fourni
     # par Dariusz Puchala (voir ci-dessous)
     # Ignorer les broadcasts ICMP
     net/ipv4/icmp_echo_ignore_broadcasts = 1
     #
     # Ignorer les erreurs ICMP bogus
     net/ipv4/icmp_ignore_bogus_error_responses = 1
     # 
     # Ne pas accepter les redirections ICMP (empêche les attaques MITM)
     net/ipv4/conf/all/accept_redirects = 0
     # _ou_
     # Accepter les redirections ICMP uniquement pour les passerelles listées
     # dans notre liste de passerelles par défaut (activé par défaut)
     # net/ipv4/conf/all/secure_redirects = 1
     #
     # Ne pas accepter les redirections ICMP (nous ne sommes pas un routeur)
     net/ipv4/conf/all/send_redirects = 0
     #
     # Ne pas faire suivre les paquets IP (nous ne sommes pas un routeur)
     # Note : Assurez-vous que /etc/network/options contient 'ip_forward=no'
     net/ipv4/conf/all/forwarding = 0
     #
     # Activer les TCP Syn Cookies
     # Note : Assurez-vous que /etc/network/options contient 'syncookies=yes'
     net/ipv4/tcp_syncookies = 1
     #
     # Enregistrer les paquets martiens
     net/ipv4/conf/all/log_martians = 1
     #
     # Activer la vérification d'adresse source pour toutes les interfaces
     # pour empêcher certaines attaques par usurpation
     # Note : Assurez-vous que /etc/network/options contient 'spoofprotect=yes'
     net/ipv4/conf/all/rp_filter = 1
     #
     # Ne pas accepter les paquets de routage source IP (nous ne sommes pas un routeur)
     net/ipv4/conf/all/accept_source_route = 0

Pour utiliser le script, vous devez tout d'abord le créer, par exemple, dans /etc/network/interface-secure (le nom est donné comme exemple) et l'appeler à partir de /etc/network/interfaces comme ceci : 

     auto eth0
     iface eth0 inet static
             address xxx.xxx.xxx.xxx
             netmask 255.255.255.xxx
             broadcast xxx.xxx.xxx.xxx
             gateway xxx.xxx.xxx.xxx
             pre-up /etc/network/interface-secure

Dans cet exemple, avant que l'interface eth0 ne soit activée, le script sera appelé pour sécuriser toutes les interfaces réseau comme montré ci-dessous. 

     #!/bin/sh -e
     # Nom du script : /etc/network/interface-secure
     # Modifie plusieurs comportements par défaut pour sécuriser contre
     # certaines attaques et usurpations IP pour toutes les interfaces
     #
     # Fourni par Dariusz Puchalak  
     #
     
     # Active la protection broadcast echo
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
                                                
     # Désactive l'ip forwarding
     echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
     
     # Active la protection TCP syn cookie
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies
     
     
     # Enregistre les paquets avec des adresses impossibles
     # (cela inclut les paquets usurpés (spoofed), les paquets routés
     # source, les paquets redirigés), mais faites attention à ceci
     # sur les serveurs web très chargés
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians 
     
     # Active la protection sur les mauvais messages d'erreur
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
     
     
     # Maintenant la protection ip spoofing
     echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
     
     # Et enfin, encore d'autres choses
     # Désactive l'acceptation Redirect ICMP
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
     echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
     
     # Désactive Source Routed
     echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
     
     exit 0

Remarquez que vous pouvez en fait avoir des scripts par interface qui activeront différentes options réseau pour différentes interfaces (si vous en avez plus d'une), il vous suffit de changer la ligne pre-up en : 

     pre-up /etc/network/interface-secure $IFACE

et utiliser un script qui n'applique les changements qu'à une interface spécifique et non à toutes les interfaces disponibles. Notez cependant que certaines options réseau ne peuvent être appliquées que globalement. Un exemple de script est celui-ci : 

     #!/bin/sh -e
     # Nom du script : /etc/network/interface-secure
     # Modifie plusieurs comportements par défaut pour sécuriser contre
     # certaines attaques et usurpations TCP/IP pour une interface donnée
     #
     # Fourni par Dariusz Puchalak  
     #
     
     IFACE=$1
     if [ -z "$IFACE" ] ; then
        echo "$0: Must give an interface name as argument!"
        echo "Usage: $0 <interface>"
        exit 1
     fi
     
     if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
        echo "$0: Interface $IFACE does not exist (cannot find /proc/sys/net/ipv4/conf/)"
        exit 1
     fi
     
     # Désactive l'ip forwarding
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding
     
     # Enregistre les paquets avec des adresses impossibles
     # (cela inclut les paquets usurpés (spoofed), les paquets routés
     # source, les paquets redirigés), mais faites attention à ceci
     # sur les serveurs web très chargés
     echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians
     
     # Maintenant la protection ip spoofing
     echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter
     
     # Et enfin, encore d'autres choses
     # Désactive l'acceptation Redirect ICMP
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects
     
     # Désactive les paquets de routage source
     echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route
     
     exit 0

Vous pouvez également créer un script init.d et le faire exécuter au démarrage (en utilisant update-rc.d pour créer les liens rc.d appropriés).

4.17.4 Configuration des fonctionnalités de pare-feu

De façon à avoir des privilèges de pare-feux, soit pour protéger le système local ou d'autres derrière lui, le noyau doit être compilé avec les options correspondant aux pare-feu. Le noyau standard 2.2 de la Debian (également 2.2) fournit ipchains qui est un pare-feu pour filtrer les paquets, le noyau standard de la Debian 3.0 (noyau 2.4) fournit lui le pare-feu iptables (netfilter). Les anciennes distributions Debian auront besoin de rustines appropriées pour le noyau (Debian 2.1 utilise le noyau 2.0.34).

Dans tous les cas, il est relativement facile d'utiliser un noyau différent de celui fourni par Debian. Vous pouvez trouver des noyaux pré-compilés sous forme de paquets que vous pouvez facilement installer sur le système Debian. Vous pouvez également télécharger les sources du noyau en utilisant kernel-source-X et construire des paquets de noyau personnalisé en utilisant make-kpkg du paquet kernel-package.

La mise en place de pare-feu dans Debian est abordée plus en détail dans Ajouter des capacités au pare-feu, Section 5.14.

4.17.5 Désactiver les problèmes d'hôtes weak-end

Les systèmes avec plus d'une interface sur différents réseaux peuvent avoir des services configurés pour qu'ils ne puissent s'associer qu'à une adresse IP donnée. Ceci prévient habituellement les accès aux services quand ils sont interrogés par une adresse donnée. Cependant, cela ne veut pas dire (bien qu'il s'agisse d'une erreur de conception commune que j'ai moi aussi faite) que le service est lié à une adresse matérielle donnée (carte interface). [32]

Ceci n'est pas un problème ARP et ce n'est pas une violation de RFC (c'est ce que l'on appelle le weak end host dans la RFC1122, section 3.3.4.2). Rappelez-vous que les adresses IP n'ont rien à voir avec les interfaces physiques.

Sur les noyaux 2.2 (et antérieurs), ceci peut être corrigé avec : 

     # echo 1 > /proc/sys/net/ipv4/conf/all/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
     # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
     .....

Sur des noyaux postérieurs, ceci peut être corrigé avec :

Tout au long de ce texte, il y aura plusieurs occasions pour lesquelles ils est affiché comment configurer certains services (serveur sshd, apache, service d'impression, etc.) pour les avoir en attente sur une adresse donnée, le lecteur devra prendre en compte que, sans les correctifs données ici, le correctif n'empêchera pas les accès depuis le même réseau (local). [35]

FIXME: commentaires sur bugtraq indiquant qu'il existe une méthode spécifique Linux pour associer à une interface donnée.

FIXME: Créer un bogue sur netbase pour que le correctif de routage soit le comportement standard dans Debian ?

4.17.6 Protéger contre les attaques ARP

Quand vous ne faites pas confiance aux autres machines de votre réseau (ce qui devrait toujours être le cas parce que c'est l'attitude la plus sûre), vous devriez vous protéger contre les différentes attaques ARP existantes.

Comme vous le savez, le protocole ARP est utilisé pour lier des adresses IP à des adresses MAC (voir la RFC826 pour tous les détails). À chaque fois que vous envoyez un paquet à une adresse IP, une résolution arp est effectuée (en regardant en premier dans le cache local ARP, puis si l'adresse IP n'est pas présente dans le cache, en diffusant une requête arp) pour trouver l'adresse matérielle de la cible. Toutes les attaques ARP ont pour but d'amener votre machine à croîre que l'adresse IP de la machine B est associée à l'adresse MAC de la machine de l'intrus ; puis tous les paquets que vous voudrez envoyer à l'adresse IP associée à la machine B seront envoyée à la machine de l'intrus, etc.

Ces attaques (empoisonnement du cache, falsification ARP, etc.) permettent à l'attaquant de renifler le trafic même sur des réseaux switchés, pour pirater facilement des connexions, pour déconnecter tout hôte du réseau, etc. Les attaques arp sont puissantes et simples à implémenter et plusieurs outils existent comme arpspoof du paquet dsniff ou arpoison.

Cependant, il existe toujours une solution :

4.18 Prendre un instantané (snapshot) du système

Avant de mettre le système en production, vous pouvez prendre un instantané de votre système entier. Cet instantané pourrait être utilisé en cas de compromis (see Après la compromission (la réponse à l'incident), Chapitre 10). Vous devriez refaire cette mise à jour à chaque fois que le système est mis à jour, particulièrement si vous mettez à jour vers une nouvelle version de Debian.

Pour cela, vous pouvez utiliser un support inscriptible et amovible qui peut être positionné en lecture seule, ce peut être une disquette (en lecture seule après utilisation), un CD d'une unité de CD-ROM (vous pourriez utiliser un CD-ROM ré-inscriptible, ainsi vous pourriez même garder des sauvegardes des md5sums à différentes dates), ou un disque USB ou une carte MMC (si votre système peut accéder à ceux-ci et qu'ils peuvent être protégés en écriture).

Le script suivant crée un tel instantané : 

     #!/bin/bash
     /bin/mount /dev/fd0 /mnt/floppy
     if [ ! -f /usr/bin/md5sum ] ; then
        echo "Impossible de trouver md5sum. Échec."
        exit 1
     fi
     /bin/cp /usr/bin/md5sum /mnt/floppy
     echo "Calcul de la base de données md5"
     >/mnt/floppy/md5checksums.txt
     for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
     do
        find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
     done
     echo "Base de données md5 de post-installation calculée"
     if [ ! -f /usr/bin/sha1sum ] ; then
        echo "Impossible de trouver sha1sum"
     else
        /bin/cp /usr/bin/sha1sum /mnt/floppy
        echo "Calcul de la base de données SHA-1"
        >/mnt/floppy/sha1checksums.txt
        for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
        do
           find $dir -type f | xargs /usr/bin/sha1sum
           >>/mnt/floppy/sha1checksums-lib.txt
       done
       echo "Base de données sha1 de post-installation calculée"
     fi
     /bin/umount /dev/fd0
     exit 0

Notez que le binaire md5sum (et le binaire sha1sum, s'il est disponible) est placé sur la disquette pour pouvoir être utilisé plus tard pour vérifier les binaires du système (juste au cas où il serait aussi corrompu). Cependant, si vous voulez vous asurer que vous exécutez bien un binaire légitime, vous pouvez vouloir, soit compiler une copie statique du binaire md5sum et utiliser celui-ci (pour empêcher une bibliothèque libc corrompue d'interférer avec le binaire), soit utiliser des instantanés de md5sums depuis un environnement propre exclusivement comme un cédérom de récupération ou un cédérom autonome (pour empêcher un noyau corrompu d'interférer). Je ne peux insister assez sur ce point : si vous êtes sur un système compromis, vous ne pouvez pas faire confiance à ce qui s'affiche, voir Après la compromission (la réponse à l'incident), Chapitre 10.

L'instantané n'inclut pas les fichiers sous /var/lib/dpkg/info qui incluent les hashes md5 des paquets installés (dans les fichiers se terminant par .md5sums). Vous pourriez également y copier cette information, cependant il faut que vous remarquiez que :

Une fois que l'instantané est fait, vous devriez vous assurer de placer le support en lecture seule. Vous pouvez ensuite le stocker pour archivage ou le placer dans le lecteur et utiliser une vérification cron toutes les nuits en comparant les md5sums d'origine avec ceux de l'instantané.

4.19 Autres recommandations

4.19.1 N'utilisez pas de logiciels dépendant de svgalib

SVGAlib est très bien pour les amoureux de la console comme moi mais dans le passé il a été prouvé plusieurs fois qu'elle est très peu sûre. Des exploits contre zgv ont été diffusés et il était facile de devenir root. Essayez d'éviter l'utilisation de programmes utilisant la SVGAlib chaque fois que c'est possible.

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

Manuel de sécurisation de Debian

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

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

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