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

Securing Debian Manual
Chapitre 4 - Après l'installation


4.1 Attribuer un mot de passe à LILO ou GRUB

N'importe qui peut obtenir facilement un shell root et changer vos mots de passes en entrant au prompt de boot "<nom-de-votre-imageboot> init=/bin/sh". Après le changement du mot de passe et le redémarrage du système, la personne à un accès root illimité et peut faire tout ce qu'il veut sur le système. Après ceci, vous n'aurez plus d'accès root sur votre machine, vu 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

Une fois terminé, relancer 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 accorder à root les droits de lecture et d'écriture et permettre un accès en lecture seule pour le groupe de configuration de lilo, à savoir root.

Si vous utilisez GRUB plutôt que LILO, éditez /boot/grub/menu.lst et ajouter 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 passes grub se trouvent dans le paquet grub-doc.


4.2 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", que de nombreuses personnes ne se méfient pas, 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.3 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 dans la 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.4 Monter correctement les partitions

Lorsque vous monter 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 n'ont pas d'indice, 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 bogue116448.

Ce qui suit est un exemple un plus poussé. Prenez note que, bien que /var peut être mis à noexec, certains logiciels tel Smartlist conservent ses 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.4.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 autre que /tmpqui aura les privilèges exec.

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

     $ cp /bin/date /tmp
     $ /tmp/date
     (n'exécute pas du au noexec)
     $/lib/ld-linux.so.2 /tmp/date
     (fonctionne correctement étant donné que date n'est pas exécuté directement)

4.4.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 la debian 3.0 "woody") peut être configurer 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. C'est agaçant mais pas réellement un problème. Vérifier juste qu'ils ne soient plus utilisés puis lancer le Post-Invoke manuellement.


4.5 Se mettre à jour au niveau de la sécurité

Dès que des nouveaux bogues de sécurité sont décelés dans les paquets, les responsables Debian et les auteurs en amont les raccommodent dans la journée ou les heures suivantes. Une fois le bogue résolu, un nouveau paquet est fourni sur name="http://security.debian.org" id="http://security.debian.org">. Mettre la ligne suivante dans votre sources.list et vous serez mis à jour automatiquement quand vous mettrez à jour votre système.

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

La plupart des personnes, qui vivent dans un pays qui n'interdit pas l'importation ou l'utilisation de forte cryptographie, devrait aussi ajouter cette ligne :

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

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

Vous devriez procéder à des mises à jour fréquemment, la plupart des piratages est le résultat de vulnérabilités connues mais qui n'ont pas été raccommodées à temps, tel que le décrit le texte de Bill Arbaugh (présenté au Symposium IEEE 2001 sur la Sécurité et la Vie Privé).

FIXME : Ajouter des informations sur comment est réalisé la signature des paquets, ce qui peut être réalisé automatiquement par un cron job (Gros avertissement: DNS spoofing).


4.6 Personnalisation des accès aux utilisateurs


4.6.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 de PAM. La plupart des applications embarqué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. Chaque application avec le support PAM fourni 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 (at the primary PAM distribution site)

PAM vous offre la possibilité de passer en revue plusieurs étapes d'authentification en une seule, à 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 à 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 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 fourni 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. 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é dans /etc/pam.d/login:

     auth     requisite  pam_securetty.so

Ensuite, vous devriez ajouter les terminaux depuis lesquels l'utilisateur root peut se connecter au système dans le fichier /etc/security/access.conf. La dernière mais pas la moindre, la ligne suivante devra être activée si vous voulez paramétrer les limites des utilisateurs.

     session  required   pam_limits.so

Ceci restreint les ressources du système auxquelles les utilisateurs sont autorisées (voir ci-dessous Le fichier limits.conf, Section 4.6.2). Par exemple, vous pouvez restreindre le nombre de connexions (d'un groupe d'utilisateurs donné ou tout le système) que vous avez, 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 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, ainsi seulement quelques personnes pourront 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). Ajouter root et les autres utilisateurs, qui auront la possibilité d'utiliser su pour devenir root, à ce groupe. Ensuite, ajouter 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 somme, ils seront confrontés à un message d'interdiction s'ils essayent de devenir root.

Si vous désirez que seulement certains utilisateurs s'authentifient à un service PAM, on utilise 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.6.2 Le fichier limits.conf

Vous devriez sérieusement jeter un oeil à ce fichier. Ici voux pouvez définir les limites par utilisateur des ressources. Si vous utilisez PAM, le fichier /etc/limits.conf est ignoré et vous devriez utiliser /etc/security/limits.conf à la place.

FIXME : Placer un fichier exemple de limits.conf ici


4.6.3 Editer /etc/login.defs

La prochaine étape est d'éditer la configuration et action de base sur la connexion de l'utilisateur.

     FAIL_DELAY          10

Cette variable devrait être fixé à 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, ce qui est agaçant quand vous testez des mots de passe. Prenez garde car ce paramétrage est inutile si vous utilisez un programme autre que getty, tel que mingetty par exemple.

     FAILLOG_ENAB        yes

Si vous activez cette variable, les connexions échouées seront loggées. Il est important d'en garder une trace pour attraper un éventuel pirate.

     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, soyez sûr que les logs aient les bonnes permissions (640 par exemple avec un groupe adéquat tel 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 de le voir.

     SYSLOG_SU_ENAB      yes

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

     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 dictionnaires étant donné que vous pouvez utiliser des mots de passe plus long. Si vous utilisez slink, lisez les docs avant d'activer le MD5. D'ailleurs 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.


4.6.4 Editer /etc/ftpusers

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


4.6.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 sudo, vu qu'il dispose de plus de caractéristiques que su. Cependant, su est plus commun vu qu'il est utilisé sur beaucoup d'autres Unices.


4.6.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 dont vous n'avez pas les permissions, sont logguées et envoyées au root.


4.6.7 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.) fourni par les paquets libpam.

Si des utilisateurs venaient à être créés et que le système pourrait être accessible à distance prenez en compte que l'utilisateur pourra se connecter au système. Ceci peut être résolu 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 leur limiter les 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 ne fourni pas à l'heure actuelle (mais peut être dans le futur) le module pam_chroot. Une alternative à cela est de chroot le service qui fourni les connexions à distances (ssh, telnet).

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.


4.6.7.1 Restriction de ssh pour les utilisateurs

Le serveur sshd de Debian ne vous autorisera pas à restreindre les mouvements des utilisateurs via le serveur étant donné que celui-ci est dépourvu de la fonction Chroot que la version commerciale (sshd2) possède (utilisation de "ChrootGroups" ou "ChrootUsers", voir sshd2_config(5)). Toutefois, une rustine est disponible afin de vous permettre de le faire, elle peut être trouvée depuis Bug report 139047 ou http://www.cag.lcs.mit.edu/~raoul/ (et sera peut-être appliquée au paquet OpenSSH dans le futur). Emmanuel Lacour dispose d'un paquet avec cette fonctionnalité sur http://debian.home-dn.net/woody/ssh/, quoique la compilation est recommandée. Une description de toutes les étapes nécessaires peut-être aperçue sur http://mail.incredimail.com/howto/openssh/ (pratiquement tout est applicable à Debian même s'il est question de la RedHat 7.2). Après l'application de la rustine, vous devez juste modifier le /etc/passwd en changeant le chemin personnel des utilisateurs (avec le jeton spécial /./):

     joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash

Tous deux, aussi bien les accès distants au shell que la copie via le tunnel ssh, seront restreints.

Il faut être sûr que tous les binaires et librairies soient présents dans le chemin chrooté pour les utilisateurs. Ces fichiers devraient appartenir à root pour éviter les fraudes de l'utilisateur (tel la sortie d'une prison chrooté). Un échantillon pourrait inclure ceci :

     ./bin:
     total 660
     drwxr-xr-x    2 root     root         4096 Mar 18 13:36 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -r-xr-xr-x    1 root     root       531160 Feb  6 22:36 bash
     -r-xr-xr-x    1 root     root        43916 Nov 29 13:19 ls
     -r-xr-xr-x    1 root     root        16684 Nov 29 13:19 mkdir
     -rwxr-xr-x    1 root     root        23960 Mar 18 13:36 more
     -r-xr-xr-x    1 root     root         9916 Jul 26  2001 pwd
     -r-xr-xr-x    1 root     root        24780 Nov 29 13:19 rm
     lrwxrwxrwx    1 root     root            4 Mar 30 16:29 sh -> bash
     
     ./etc:
     total 24
     drwxr-xr-x    2 root     root         4096 Mar 15 16:13 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rw-r--r--    1 root     root           54 Mar 15 13:23 group
     -rw-r--r--    1 root     root          428 Mar 15 15:56 hosts
     -rw-r--r--    1 root     root           44 Mar 15 15:53 passwd
     -rw-r--r--    1 root     root           52 Mar 15 13:23 shells
     
     ./lib:
     total 1848
     drwxr-xr-x    2 root     root         4096 Mar 18 13:37 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     -rwxr-xr-x    1 root     root        92511 Mar 15 12:49 ld-linux.so.2
     -rwxr-xr-x    1 root     root      1170812 Mar 15 12:49 libc.so.6
     -rw-r--r--    1 root     root        20900 Mar 15 13:01 libcrypt.so.1
     -rw-r--r--    1 root     root         9436 Mar 15 12:49 libdl.so.2
     -rw-r--r--    1 root     root       248132 Mar 15 12:48 libncurses.so.5
     -rw-r--r--    1 root     root        71332 Mar 15 13:00 libnsl.so.1
     -rw-r--r--    1 root     root        34144 Mar 15 16:10
     libnss_files.so.2
     -rw-r--r--    1 root     root        29420 Mar 15 12:57 libpam.so.0
     -rw-r--r--    1 root     root       105498 Mar 15 12:51 libpthread.so.0
     -rw-r--r--    1 root     root        25596 Mar 15 12:51 librt.so.1
     -rw-r--r--    1 root     root         7760 Mar 15 12:59 libutil.so.1
     -rw-r--r--    1 root     root        24328 Mar 15 12:57 libwrap.so.0
     
     ./usr:
     total 16
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 .
     drwxr-xr-x    8 guest    guest        4096 Mar 15 16:53 ..
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 bin
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 lib
     
     ./usr/bin:
     total 340
     drwxr-xr-x    2 root     root         4096 Mar 15 15:55 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rwxr-xr-x    1 root     root        10332 Mar 15 15:55 env
     -rwxr-xr-x    1 root     root        13052 Mar 15 13:13 id
     -r-xr-xr-x    1 root     root        25432 Mar 15 12:40 scp
     -rwxr-xr-x    1 root     root        43768 Mar 15 15:15 sftp
     -r-sr-xr-x    1 root     root       218456 Mar 15 12:40 ssh
     -rwxr-xr-x    1 root     root         9692 Mar 15 13:17 tty
     
     ./usr/lib:
     total 852
     drwxr-xr-x    2 root     root         4096 Mar 15 15:37 .
     drwxr-xr-x    4 root     root         4096 Mar 15 13:00 ..
     -rw-r--r--    1 root     root       771088 Mar 15 13:01
     libcrypto.so.0.9.6
     -rw-r--r--    1 root     root        54548 Mar 15 13:00 libz.so.1
     -rwxr-xr-x    1 root     root        23096 Mar 15 15:37 sftp-server

4.6.8 Audit d'utilisateur à la main

Si vous êtes paranoïaque, il se peut que vous vouliez configurer pour le système un /etc/profile qui configure l'environnement de telle façon que les utilisateurs ne puissent pas retirer les capacités d'audit du shell (les commandes sont déposées dans $HISTFILE. Le .profile ne peut être paramétré ainsi :

     HISTFILE=~/.bash_history
     HISTSIZE=100000000000000000
     HISTFILESIZE=10000000000000000
     set -o HISTFILE
     set -o HISTSIZE
     set -o HISTFILESIZE
     export HISTFILE HISTSIZE HISTFILESIZE

NB: l'attribut -o place la variable en lecture seule dans bash.

Afin que cela fonctionne, l'utilisateur doit être seulement capable d'ajouter des informations à .bash_history. Vous devez aussi positionner l'attribut ajout-uniquement en utilisant le programme chattr sur .bash_history pour tous les utilisateurs. [1] Notez que vous pouvez faire cela grâce au fichier utilisateur .profile. Mais alors vous devriez configurer les permissions correctement : pour que le répertoire des utilisateurs ne leur appartiennent PAS mais qu'ils aient le droit de lire le fichier de configuration .profile et d'écrire le .bash_history. Il serait bon de configurer l'attribut immuable (aussi en utilisant chattr) pour le .profile aussi si vous procédez ainsi.

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 et reverser toutes les sorties dans un fichier. Un autre programme utile est Snoopy 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 en utilisant la facilité authpriv (généralement stocké dans /var/log/auth.log .

Notez que vous ne pouvez pas utiliser la commande script pour ceci étant donné qu'elle ne fonctionnera pas comme un shell (même si vous l'ajoutez à /etc/shells.


4.6.9 Audit utilisateur complet

L'exemple précédent est une manière simple de configurer le contrôle utilisateur mais qui peut ne pas être pratique pour des systèmes complexes. Si cela est votre cas, vous devrez examiner acct, l'utilitaire de comptes. Ceci archivera toutes les commandes 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 l'utilisateur sont conservés dans /var/account/, plus spécifiquement dans le fichier pacct. Le paquetage de comptabilité inclus des outils (sa et ac) afin d'analyser ces données.


4.6.10 Inspection des profils utilisateurs

Si vous désirez voir ce que font les utilisateurs habituellement, 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.7 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. Les TCP wrappers vous autorise à tolérer ou à refuser un service à un hôte ou a un domaine et vous permet de définir une règle par défaut pour les autorisations et les refus. Pour plus de détails, jeter un oeil à hosts_access(5).

De nombreux services installés dans Debian sont soit :

D'un côté, des services sont configurés dans /etc/inetd.conf, ceci incluant telnet, ftp, netbios, swat et finger (vous verrez que le fichier de configuration exécute avant tout /usr/sbin/tcpd). <--! Pas bien sur de mon interprétation :(. || Ca semble correct. jpg--> D'un autre côté, même si un service n'est pas lancé par le super daemon inetdil peut, dans tous les cas, dépendre des règles du tcp wrapper Les services compilés avec support tcp wrappers dans Debian incluent ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf (the GNOME activator daemon), nessus et beaucoup d'autres.

Tenir compte de ceci lorsque tcpchk est utilisé. Vous pouvez ajouter des services, qui sont liés à la bibliothèque du wrapper, dans les fichiers host.deny et hosts.allow mais tcpchk vous informera qu'il n'est pas capable de trouver ces services étant donné qu'il les cherche dans /etc/inetd.conf (la page de manuel n'est pas totalement précise).

A présent, voici une petite astuce et probablement le plus petit système de détection d'intrusion 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, [2], dans /etc/hosts.deny qui envoi un mail à 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 "DoSé" 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.8 L'importance des logs et des alertes

Comment les logs et les alertes sont traités est un problème sérieux à prendre en compte sur un système sécurisé. Il est facile de voir que, même si le système est parfaitement configuré, il n'est sécurisé qu'à 99%. Si le 1% vient à arriver, et qu'il n'y a pas de mesures de sécurité mises en place, premièrement, first, trouvez les et, dans un deuxième temps, lancez l'alerte, le système n'est pas sécurisé du tout.

Il y a une grande partie sur l'analyse des log qui ne peut pas être couverte ici, une bonne ressource d'information est Couterpane's Log Analysis Resources.


4.8.1 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 des fichiers appropriés dépendant de la facilité du système. Vous devriez être familier avec ceci; jetez un oeil 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<--! traduction de loghost. Je me suis permis de traduire.jpg-->(il reçoit les logs de tous les autres systèmes).

Le mail du root devrait être pris en considération également, de nombreux contrôles de sécurité (tel snort) envoient des alertes dans la boite aux lettres de root. Celle-ci pointe généralement sur le premier utilisateur créé sur le système (vérifier /etc/aliases). Prenez garde à envoyer le courrier du root à un endroit où il sera lu (soit localement ou à distance). <--! ES pluriel d'alias ? => C'est pas aliases ? Non, c'est un adverbe a la base ;) On reste donc invariable, amha. Je propose donc la correction. jpg-->

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 : snmptraglogd, snmp et snmpd.


4.8.2 Utilisation d'un hôte d'archivage (loghost)<--! voir pour une traduction sur la liste. Serveur de log? jpg -->

Un loghost est un hôte qui recueille les données des syslog à travers le réseau. Si une machine 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 suffisamment 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, éditer /etc/init.d/sysklogd et changer la ligne

     SYSLOGD=""

par

     SYSLOGD="-r"

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

     facilité.niveau           @votre_loghost

Voir 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. <--! ES garder fichiers de log ou de logs ? => apparemment ils utilisent sur la liste journaux d'événements ...-->


4.8.3 Permissions du fichier d'archivage

Il est important de décider à la fois 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 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.

Certaines permissions de fichiers de log ne sont pas parfaites après l'installation. Premièrement /var/log/lastlog et /var/log/faillog n'ont pas besoin d'être lisible 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 les chmod'er tous les 2 en 660. Faites un tour rapide de vos fichiers de log et décidez avec beaucoup d'attention quels fichiers de log vous rendez lisible/inscriptible par un utilisateur avec un UID différent de 0 et un groupe autre que 'adm' ou 'root'.

Je voudrais souligner que les permissions du fichier de log d'apache sont vraiment défaillantes de par le fait que l'utilisateur apache est le propriétaire de ses fichiers de log. Si un utilisateur obtient un shell par une voie dérobée d'apache, il pourra facilement supprimer les fichiers de log.


4.9 Utilisation de chroot

chroot est une des possibilités les plus puissantes pour restreindre un daemon ou un utilisateur ou un autre service. Imaginez juste une prison autour de votre cible, dont votre cible ne peut s'échapper (normalement, mais il y a encore beaucoup de conditions qui permettent de s'échapper d'une telle prison). Si vous ne faites pas confiance à un utilisateur, vous pouvez créer un environnement à racine modifiée pour lui. Cela peut utiliser pas mal d'espace disque comme vous avez besoin de copier tous les exécutables nécessaires, ainsi que les librairies, dans la prison. Même si l'utilisateur fait quelque chose de malveillant, la portée des dégâts sera limitée à la prison.

Un bon exemple pour ce cas est, si vous n'authentifiez pas avec /etc/passwd mais utilisez LDAP ou MySQL à la place. Donc votre daemon-ftp a seulement besoin d'un binaire et peut être de quelques librairies. Un environnement chrooté serait une excellent amélioration de la sécurité ; si un nouvel exploit est découvert pour ce daemon-ftp, alors les attaquants pourront seulement exploiter l'UID de l'utilisateur-daemon-ftp et rien d'autre.

Bien sur, beaucoup d'autres daemons pourraient bénéficier de ce genre d'aménagement aussi.

Cependant, soyez averti qu'une prison chroot peut être brisée si l'utilisateur qui y évolue est le super-utilisateur. Donc, vous devez faire s'exécuter le service comme un utilisateur non-privilégié. En limitant son environnement vous limitez les fichiers lisibles/inscriptibles par tout le monde auxquels le service peut accéder, ainsi, vous limitez les possibilités d'élévation de privilège en utilisant des vulnérabilités du système local. Même si dans cette situation vous ne pouvez être complètement sur qu'il n'y a aucun moyen pour un attaquant intelligent de s'échapper d'une façon ou d'une autre de la prison. L'utilisation des seuls programmes serveurs qui ont la réputation d'être surs est une bonne mesure de sécurité supplémentaire. Même des failles minuscules comme des références de fichier ouverts peuvent être utilisées par un attaquant talentueux pour s'introduire dans le système. Après tout chroot n'a pas été conçu comme un outil de sécurité mais comme un outil de test.

Note additionnelle, le BIND par défaut de la Debian (le service de nom Internet) n'est pas livré chrooté par défaut; en fait, aucun daemon n'est chrooté. Cela pourrait changer dans la version woody (3.0).

Il y a aussi des logiciels (pas dans la Debian actuellement mais qui pourraient fournis dans le futur) qui peuvent aider à configurer des environnements chroot. makejail par exemple, peut créer et mettre à jour une prison chroot avec de petits fichiers de configuration. il essaie aussi de deviner et d'installer dans la prison tous les fichiers requis par le daemon. Plus d'information à http://www.floc.net/makejail/. Jailer est un outil similaire qui peut être récupéré sur http://www.balabit.hu/downloads/jailer/


4.9.1 Configuration noyau


4.9.2 Configuration des options réseaux du noyau

FIXME : Pas de contenu

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

     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. Sinon, ça ne fait rien.

     net/ipv4/icmp_echo_ignore_all = 0

Si vous ne voulez pas bloquer ICMP avec votre pare-feux, activez ceci.

     net/ipv4/tcp_syncookies = 1

Cette option est à double tranchant. D'un côté elle protège votre système contre le syn flooding; d'un autre côté elle viole les standards définis (RFCs). Cette option est assez stupide car elle floode l'autre partie de la même manière qu'elle vous flood, ainsi l'autre partie est aussi occupée. Si vous voulez changer cette option vous pouvez aussi la changer dans /etc/network/options en positionnant syncookies=yes.

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

Les paquets avec des adresses impossibles (du fait de routes éronnées) sur votre système sont logués.

Voici un exemple pour configurer tout ça ainsi que d'autres trucs utiles. Vous devriez ajouter cette information à un script dans /etc/network/interface-secure (le nom est donné comme exemple) et l'appeler à partir de /etc/network/interfaces comme ça:

     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
     # Script-name: /etc/network/interface-secure
     # Modifies some default behaviour in order to secure against 
     # some TCP/IP spoofing & attacks
     #
     # Contributed by Dariusz Puchalak  
     #
     echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                                # broadcast echo protection enabled
     echo 0 > /proc/sys/net/ipv4/ip_forward     # ip forwarding disabled
     echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookie protection enabled
     echo 1 >/proc/sys/net/ipv4/conf/all/log_martians 
                                                # Log packets with impossible addresses
                              # but be careful with this on heavy loaded web servers
     echo 1 > /proc/sys/net/ipv4/ip_always_defrag 
                                                #  defragging protection always enabled
     echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                                # bad error message protection enabled
     
     # now ip spoofing protection
     for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
             echo 1 > $f
     done
     
     # and finally some more things:
     # Disable ICMP Redirect Acceptance
     for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
             echo 0 > $f
     done
     
     for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
           echo 0 > $f
     done
     
     # Disable Source Routed Packets
     for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
             echo 0 > $f
     done
     
     # Log Spoofed Packets, Source Routed Packets, Redirect Packets
     for f in /proc/sys/net/ipv4/conf/*/log_martians; do
             echo 1 > $f
     done

<--! Fin de traduction je fais la partie suivante --> :)


4.9.3 Configuring firewall features

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 nécessite d'être compilé avec les options correspondant aux pare-feux. Le noyau standard 2.2 de la Debian (également 2.2) fourni ipchains qui est un pare-feux pour filtrer les paquets, le noyau standard de la Debian 3.0 (noyau 2.4) fourni lui le pare-feux 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.

La mise en place de pare-feux dans Debian est abordée d'avantage dans Ajouter des capacités au pare-feu, Section 5.15.


4.10 Ajout de rustines pour le noyau

FIXME: More content

Debian GNU/Linux fourni quelques rustines pour le noyau Linux qui améliorent sa sécurité. Ceci inclus


4.11 Sécurisation des transferts de fichiers

La copie des fichiers d'une manière sécurisée d'un hôte à un autre peut être accomplie en utilisant "scp" qui est inclus dans le paquet ssh. Cela fonctionne comme rcp mais à l'avantage d'être complètement chiffré, ainsi les méchants ne peuvent pas s'imaginer ce que vous êtes en train de copier.


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


4.12.1 Utilisation de quotas

Avoir une bonne politique quant aux quotas est importante, 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 : quota utilisateur et quota groupe. Comme vous l'avez probablement deviné, le quota utilisateur limite la quantité d'espace qu'un utilisateur peut avoir, quota groupe quant à lui fait la même chose pour les groupes. Retenez ceci quand vous calculerez les tailles des quotas.

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

Chaque partition/répertoire auquel les utilisateurs ont un accès en écriture complet devraient avoir les quotas d'activés. Rechercher ces partitions et répertoires et calculer une taille réalisable 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 fichier sur lequel vous voulez utiliser les quotas (touch /home/quota.user /home/quota.group pour un système de fichier /home).

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

L'édition de quotas pour un utilisateur spécifique (disons "ref") peut être réalisée en faisant edquota -u ref. 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 correspondant.

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 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 orphaned


4.12.2 chattr/lsattr

Ces deux commandes sont très utiles mais elles fonctionnent uniquement pour le système de fichier ext2. Avec "lsattr", vous pouvez lister les attributs d'un fichier et avec "chattr" vous pouvez les modifier. Notez que ces attributs ne sont pas les mêmes choses que les permissions. De nombreux attributs existent mais seuls les plus importants sont cité s ici. Il n'y a que deux indicateurs <--! flags attente meilleure traduction. Indicateur convient mieux? jpg --> qui peuvent être paramétrés par le super utilisateur.

Avant tout, il y a le indicateur "a". S'il est placé sur un fichier, celui-ci ne pourra être ouvert qu'en ajout. Cette propriété est utile pour certain des fichiers dans /var/log/, quoique vous devriez penser au fait qu'ils soient déplacés de temps en temps par les scripts de rotation de logs.

Le second drapeau est le drapeau "i" pour inchangeable (dans le sens qu'on ne peut pas le modifier)<--! a traduire immutable. Fait.jpg -->. S'il est placé sur un fichier, celui-ci ne peut-être ni modifié ni effacé ou encore renommé et aucun ne peut l'utiliser. Si vous ne voulez pas que les utilisateurs viennent trifouiller vos fichiers de configuration, vous pouvez mettre ce drapeau et enlever l'accès en lecture. De plus, ceci peut vous offrir un peu plus de sécurité contre les intrus, car le pirate peut-être troublé par le fait qu'il ne puisse pas supprimer un fichier. Néanmoins, vous ne devriez pas penser que le pirate est aveugle. Après tout, il a pénétré votre système.

Notez que lsattr et chattr sont uniquement disponible sur les systèmes de fichiers ext2.


4.12.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 envoi en clair à travers 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 est piraté également l'algorithme qui créé 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 (non-free; la nouvelle version sera en GPL), integrit et samhain.

Installer debsums vous aidera à vérifier l'intégrité du système de fichier en comparant le md5sum de chaque fichier avec celui utilisé dans l'archive des paquets Debian. Mais faîtes attention, ces fichiers peuvent facilement être modifiés.

De plus, vous pouvez remplacer locate par slocate. slocate est une version sécurisée améliorée de GNU locate. Lors de l'utilisation de slocate, l'utilisateur ne peut voir que les fichiers auxquels il a réellement accès et vous pouvez exclure tous les fichiers et répertoires du système.


4.12.4 Mise en place de la vérification setuid

Debian fournit une tâche cron qui s'exécute quotidiennement dans /etc/cron.daily/standard. Cette tâche cron exécutera le script /usr/sbin/checksecurity qui sauvegardera l'information sur les changements.

Pour que cette vérification soit faite vous devez positionner CHECKSECURITY_DISABLE="FALSE" dans /etc/checksecurity.conf. Notez, que c'est la configuration par défaut, donc à moins que vous ayez changé quelque chose, cette option sera déjà positionnée à "FALSE".

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 CHECKSECURITY_EMAIL (dans /etc/checksecurity.conf) à 'root' pour que cette information lui soit envoyée. voir checksecurity(8) pour plus d'info sur la configuration.


4.13 Autres recommandations


4.13.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 incertaine. Les exploits contre zgv sont sortis 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 ] [ suivant ]

Securing Debian Manual

2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100

Javier Fernández-Sanguino Peña jfs@computer.org