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.
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
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 :
login.defs
, éditez la variable CONSOLE qui défini un fichier ou
une liste de terminaux sur lesquels la connexion de root est autorisée.
securetty
en ajoutant/supprimant les terminaux auxquels les accès
root seront autorisés.
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
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
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 /tmp
qui 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)
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.
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).
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).
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
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.
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.
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.
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.
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.
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
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
.
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.
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.
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 :
tcpd
)
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
inetd
il 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.
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
.
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
.
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 ...-->
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.
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/
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 --> :)
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.
FIXME: More content
Debian GNU/Linux fourni quelques rustines pour le noyau Linux qui améliorent sa sécurité. Ceci inclus
lids-2.2.19
)
lcap
)
trustees
)
selinux
also available from
the developer's
website
)
kernel-patch-2.2.19-harden
lcap
kernel-patch-freeswan
)
kernel-patch-int
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.
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
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.
Ê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.
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.
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.
Securing Debian Manual
2.8 14 febrero 2004Mon, 18 Nov 2002 23:13:42 +0100jfs@computer.org