[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Une fois que le système est installé, vous pouvez encore en faire plus pour sécuriser le système ; certaines des étapes décrites ci-dessous peuvent être effectuées. Bien sûr, cela dépend vraiment de la configuration, mais pour prévenir un accès physique, vous devriez consulter Changer le BIOS (à nouveau), Section 4.3, Attribuer un mot de passe à LILO ou GRUB, Section 4.4, Enlever l'invite superutilisateur du noyau, Section 4.6, Restreindre les accès aux consoles, Section 4.7 et Restreindre les redémarrages système depuis la console, Section 4.8.
Avant de vous connecter à tout réseau, particulièrement s'il s'agit d'un réseau public, vous devriez, au minimum, faire une mise à jour de sécurité (consultez Faire une mise à jour de sécurité, Section 4.2). Vous pourriez facultativement faire un instantané du système (consultez Prendre un instantané (« snapshot ») du système, Section 4.19).
Pour recevoir des informations sur les mises à jour de sécurité disponibles,
vous devriez vous abonner à la liste de diffusion debian-security-announce
pour recevoir les bulletins de sécurité de Debian[9]. Consultez L'équipe de sécurité Debian, Section
7.1 pour plus d'informations sur le fonctionnement de l'équipe en charge
de la sécurité Debian. Pour des informations sur l'inscription aux listes de
diffusion Debian, consultez http://lists.debian.org.
Les DSA sont signées avec la clef de l'équipe de sécurité Debian qui peut
être récupérée sur http://security.debian.org.
Vous devriez également envisager de vous abonner à la liste de diffusion
debian-security pour des discussions générales sur les problèmes
de sécurité dans le système d'exploitation Debian. Vous pourrez entrer en
contact avec d'autres administrateurs système ainsi qu'avec des développeurs
Debian et des développeurs amont d'outils de sécurité qui pourront répondre
à vos questions et proposer leurs conseils.
FIXME : Ajouter la clef ici également ?
Dès que de nouveaux bogues de sécurité sont décelés dans les paquets, les
responsables Debian et les auteurs amont les corrigent généralement dans les
journées ou les heures suivantes. Une fois le bogue résolu, un nouveau
paquet est fourni sur http://security.debian.org.
Si vous installez une version de Debian, vous devez prendre en compte le fait qu'il a pu y avoir des mises à jour de sécurité depuis la parution, à chaque fois qu'une vulnérabilité a été découverte dans un paquet. Ainsi, des révisions mineures (il y en a eu quatre dans la version Debian 3.0 Sarge) incluent ces mises à jour de paquets.
Pendant l'installation, les mises à jour de sécurité sont configurées sur le système, et les mises à jour en attente sont téléchargées et appliquées, sauf indication contraire ou si le système n'est pas connecté à Internet. Les mises à jour sont appliquées avant même le premier démarrage, de telle sorte que le nouveau système commence sa vie aussi à jour que possible.
Pour mettre à jour vous-même le système, ajoutez la ligne suivante dans le
sources.list et vous recevrez les mises à jour de sécurité
automatiquement quand vous mettrez à jour le système. Remplacez
[NOM] par le nom de la version, par exemple squeeze.
deb http://security.debian.org/ [NOM]/updates main contrib non-free
Remarque : si vous utilisez la distribution testing, utilisez les source du miroir de sécurité de testing conformément à Suivi en sécurité de la branche testing, Section 10.1.4.
Après avoir fait cela, plusieurs outils vous permettent de mettre à niveau le
système. S'il s'agit d'un ordinateur de bureau, une application appelée
update-notifier[10] permet de vérifier facilement si de nouvelles mises à
niveau sont disponibles. En choisissant cela, vous pouvez faire les mises à
niveau depuis le bureau (en utilisant update-manager). Pour
obtenir plus de renseignements, veuillez consulter Vérification de mises à jour sur station
de travail, Section 10.1.2.2. Dans les environnements de bureau, vous
pouvez aussi utiliser synaptic (GNOME), kpackage ou
adept (KDE) pour des interfaces plus avancées. Si le système ne
possède qu'un terminal texte, vous pouvez utiliser aptitude,
apt ou dselect (obsolète) pour mettre à niveau.
Si vous voulez utiliser l'interface texte d'aptitude, il suffit
d'appuyer sur u (mise à jour) suivi de g (pour mettre à
niveau). Vous pouvez aussi utiliser simplement la ligne de commande (en tant
que superutilisateur) :
# aptitude update
# aptitude upgrade
Si vous voulez utiliser apt, il suffit de faire comme pour
aptitude, mais en remplaçant aptitude des lignes
précédentes par apt-get.
Si vous voulez utiliser dselect, choisissez tout d'abord mise à
jo[U]r, puis [I]nstaller et enfin [C]onfigurer pour mettre à jour et installer
les paquets.
Si vous le voulez, vous pouvez ajouter également les lignes deb-src à
/etc/apt/sources.list. Consultez apt(8) pour plus de
détails.
Once you have executed a security update you might need to restart some of the system services. If you do not do this, some services might still be vulnerable after a security upgrade. The reason for this is that daemons that are running before an upgrade might still be using the old libraries before the upgrade [11].
From Debian Jessie and up, you can install the
needrestart package, which will run automatically after each APT
upgrade and prompt you to restart services that are affected by the
just-installed updates. In earlier releases, you can run the
checkrestart program (available in the debian-goodies
package) manually after your APT upgrade.
Certains paquets (comme libc6) feront cette vérification dans la
phase de postinstallation pour un nombre limité de services, en particulier
car une mise à jour de bibliothèques essentielles peut casser certaines
applications (avant leur redémarrage)[12].
Faire passer le système en niveau d'exécution 1 (utilisateur seul), puis ensuite au niveau d'exécution 3 (multiutilisateur) devrait entraîner le redémarrage de la plupart (si ce n'est tous) des services système. Mais cela n'est pas envisageable si vous exécutez la mise à jour de sécurité depuis une connexion distante (comme SSH) car celle-ci serait alors interrompue.
Excercise caution when dealing with security upgrades if you are doing them over a remote connection like ssh. A suggested procedure for a security upgrade that involves a service restart is to restart the SSH daemon and then, immediately, attempt a new ssh connection without breaking the previous one. If the connection fails, revert the upgrade and investigate the issue.
Assurez-vous tout d'abord que le noyau est géré par le système de gestion des paquets. Si vous l'avez installé en utilisant le système d'installation de Debian 3.0 ou de versions précédentes, le noyau n'est pas intégré dans le système de gestion des paquets et pourrait être obsolète. Vous pouvez facilement confirmer cela en exécutant :
$ dpkg -S `readlink -f /vmlinuz`
linux-image-2.6.18-4-686: /boot/vmlinuz-2.6.18-4-686
Si le noyau n'est pas géré, vous verrez un message indiquant que le
gestionnaire de paquets n'a pas trouvé le fichier associé à un paquet au
lieu du message ci-dessus, qui dit que le fichier associé au noyau
actuellement en fonctionnement est fourni par le paquet
linux-image-2.6.18-4-686. Dans le premier cas, vous devrez
installer manuellement un paquet d'image de noyau. L'image exacte du noyau que
vous devez installer dépend de l'architecture et de la version de noyau
préférée. Une fois fait, vous pourrez gérer les mises à jour de
sécurité du noyau comme pour tout autre paquet. Dans tous les cas, notez que
les mises à jour du noyau ne seront faites que pour la même version
du noyau que celui que vous utilisez, c'est-à-dire que apt ne va
pas mettre à jour automatiquement le noyau de la version 2.4 à la
version 2.6 (ou de la version 2.4.26 à la version 2.4.27[13]).
Le système d'installation des dernières versions de Debian gérera le noyau sélectionné comme partie du système de gestion des paquets. Vous pouvez vérifier quels noyaux sont installés en exécutant :
$ COLUMNS=150 dpkg -l 'linux-image*' | awk '$1 ~ /ii/ { print $0 }'
Pour voir si le noyau doit être mis à jour, exécutez :
$ kernfile=`readlink -f /vmlinuz`
$ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
$ apt-cache policy $kernel
linux-image-2.6.32-5-686:
Installé : 2.6.32-35
Candidat : 2.6.32-35
Table de version :
*** 2.6.32-35
100 /var/lib/dpkg/status
Si vous effectuez une mise à jour de sécurité incluant l'image du noyau, vous devez redémarrer le système pour que la mise à jour de sécurité soit utile. Sinon, vous utiliserez encore l'ancienne image de noyau (vulnérable).
Si vous devez effectuer un redémarrage du système (à cause d'une mise à
jour du noyau), vous devriez vous assurer que le noyau démarrera correctement
et que la connectivité réseau sera restaurée, particulièrement si la mise
à jour de sécurité est réalisée depuis une connexion à distance comme
SSH. Pour le premier point, vous pouvez configurer le chargeur d'amorçage
pour redémarrer l'ancien noyau en cas d'échec (pour des informations plus
détaillées, veuillez consulter (en anglais) Remotely rebooting
Debian GNU/Linux machines). Pour le second point, vous devez
introduire un script de test de connectivité réseau qui vérifiera si le
noyau a lancé le sous-système réseau correctement et qui redémarrera le
système si ce n'est pas le cas[14]. Cela devrait éviter des surprises désagréables comme
une mise à jour du noyau en réalisant après un redémarrage qu'il n'a pas
détecté ou configuré le matériel réseau correctement et que vous devez
parcourir une longue distance pour relancer à nouveau le système. Bien sûr,
avoir la console série[15] du
système connectée à une console ou un serveur de terminal devrait également
aider à déboguer à distance les problèmes de redémarrage.
Vous vous souvenez de Choisir un mot de passe pour le BIOS, Section 3.1 ? Et bien, vous devriez maintenant, une fois que vous n'avez plus besoin de démarrer à partir d'un support amovible, changer la configuration par défaut du BIOS pour qu'il ne puisse démarrer que depuis le disque dur. Assurez-vous de ne pas perdre le mot de passe BIOS, sinon, en cas de défaillance du disque dur, vous ne pourrez pas retourner dans le BIOS et modifier la configuration pour le récupérer en utilisant, par exemple, un CD.
Un autre moyen moins sécurisé, mais plus pratique est de changer la configuration pour que le système s'amorce depuis le disque dur et, si cela échoue, d'essayer un support amovible. À propos, c'est ainsi fait parce que la plupart des personnes n'utilisent pas le mot de passe BIOS très souvent ; il est facilement oublié.
N'importe qui peut obtenir facilement une invite de commandes superutilisateur et changer les mots de passe en entrant à l'invite d'amorçage <nom-de-l-image-d-amorçage> init=/bin/sh. Après le changement du mot de passe et le redémarrage du système, la personne a un accès superutilisateur illimité et peut faire tout ce qu'elle veut sur le système. Après cela, vous n'aurez plus d'accès supertilisateur sur la machine, étant donné que vous ne connaîtrez pas le mot de passe.
Pour être sûr que cela ne puisse pas se produire, vous devriez attribuer un mot de passe au démarrage. Vous avez le choix entre un mot de passe global et un mot de passe par image.
Pour LILO, vous avez besoin d'éditer le fichier /etc/lilo.conf et
ajouter les lignes password ainsi que restricted
comme dans l'exemple suivant.
image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=piratemoi
restricted
Puis, assurez-vous que le fichier de configuration n'est pas lisible par tout
le monde pour empêcher des utilisateurs locaux de lire le mot de passe. Une
fois terminé, relancez lilo. Omettre la ligne restricted
entraîne une attente de mot de passe, en dépit des paramètres passés à
LILO. Les permissions par défaut pour le fichier /etc/lilo.conf
accordent au superutilisateur les droits de lecture et d'écriture et
permettent un accès en lecture seule pour le groupe de configuration de
lilo.conf, à savoir root.
Si vous utilisez GRUB plutôt que LILO, éditez
/boot/grub/menu.lst et ajoutez les deux lignes suivantes en début
(en remplaçant, bien sûr, piratemoi par le mot de passe
désiré). Cela 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 chiffré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 indiquer
à grub qu'un mot de passe au format MD5 va être utilisé,
utilisez la directive suivante :
timeout 3
password --md5 $1$T/vfEWUQ$t8xoW.5kp3nbqc1zOwa3W1
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 chiffré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'informations concernant les mots de passe grub sont
disponibles dans le paquet grub-doc.
Note : cela s'applique aux noyaux fournis par défaut après Debian 3.1.
Les noyaux Linux 2.6 fournissent un moyen d'accéder à une invite de commande
de superutilisateur lors de l'amorçage et qui sera présentée pendant le
chargement de l'initramfs en cas d'erreur. C'est pratique pour permettre à
l'administrateur d'entrer une invite de commande de secours avec des droits du
superutilisateur. Cette invite de commande peut être utilisée pour charger
vous-même des modules quand la détection automatique échoue. Ce
comportement est celui par défaut pour les initramfs créés par
initramfs-tools. Le message suivant apparaîtra :
"ALERT! /dev/sda1 does not exist. Dropping to a shell!
In order to remove this behavior you need to set the following boot
argument:panic=0. Add this to the variable
GRUB_CMDLINE_LINUX in /etc/default/grub and issue
update-grub or to the append section of
/etc/lilo.conf.
Note : cela ne s'applique pas aux noyaux fournis par Debian 3.1, car le temps d'attente du noyau a été modifié à 0.
Les noyaux Linux 2.4 fournissent un moyen d'accéder à une invite de commandes
superutilisateur lors de l'amorçage et qui sera présenté juste après le
chargement du système de fichiers cramfs. Un message apparaîtra pour
permettre à l'administrateur d'obtenir une invite de commandes interactive
avec des droits du superutilisateur, cette invite de commandes peut être
utilisée pour charger manuellement des modules quand la détection automatique
échoue. Ce comportement est celui par défaut pour linuxrc de
l'initrd. Le message suivant apparaîtra :
Press ENTER to obtain a shell (waits 5 seconds)
Pour supprimer ce comportement, vous devez changer
/etc/mkinitrd/mkinitrd.conf et positionner :
# DELAY Le temps, en seconde que le script linuxrc doit
# attendre pour permettre à l'utilisateur de l'interrompre
# avant que le système ne soit lancé
DELAY=0
Puis, régénérez l'image de ramdisk. Vous pouvez faire cela ainsi, par exemple :
# cd /boot
# mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
ou (de préférence) :
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Certaines règles de sécurité peuvent forcer les administrateurs à se
connecter au système sur une console avec leur identifiant et mot de passe
puis devenir superutilisateur (avec su ou sudo).
Cette règle est appliquée sous Debian en éditant les fichiers
/etc/pam.d/login et /etc/securetty lors de
l'utilisation de PAM :
/etc/pam.d/login [16] active le module pam_securetty.so. Ce module, une fois
correctement configuré, interdira la demande de mot de passe quand le
superutilisateur essaye de se connecter sur une console non sécurisée,
rejetant l'accès à cet utilisateur ;
securetty[17] en
ajoutant ou supprimant les terminaux depuis lesquels les accès du
superutilisateur seront autorisés. Si vous voulez n'autoriser que les accès
locaux en console, vous avez alors besoin de console, ttyX[18] et vc/X (si vous
utilisez des périphériques devfs), vous pouvez vouloir ajouter
également ttySX[19]
si vous utilisez une console série pour l'accès local (où X est un nombre
entier, vous pouvez vouloir avoir plusieurs instances). La configuration par
défaut pour Wheezy [20] inclut de nombreux périphériques tty, ports séries,
consoles vc ainsi que le serveur X et le périphérique console.
Vous pouvez ajuster cela en toute sécurité si vous n'utilisez pas tant de
consoles. Vous pouvez confirmer les consoles virtuelles et périphériques tty
disponibles en vérifiant /etc/inittab [21]. Pour plus d'informations sur
les périphériques de terminal, veuillez consulter le HOWTO Terminal Texte
pour Linux (ou la version
française).
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
Si un clavier est attaché au système, tout le monde (oui, tout le monde) avec un accès physique au système peut le redémarrer sans se connecter en appuyant simplement sur la combinaison Ctrl+Alt+Delete du clavier (le salut à trois doigts). Cela peut être en conformité ou non avec vos règles de sécurité.
C'est aggravé dans les environnements où le système d'exploitation est virtualisé. Dans ces environnements, la possibilité s'étend aux utilisateurs ayant accès à la console virtuelle (qui pourrait être accessible par le réseau). Remarquez aussi que, dans ces environnements, cette combinaison est utilisée constamment (pour ouvrir une invite de connexion dans certaines interfaces graphiques de systèmes d'exploitations) et qu'un administrateur pourrait l'envoyer virtuellement et forcer un système à redémarrer.
Deux manières permettent de restreindre cela :
le configurer pour que seuls les utilisateurs autorisés puissent redémarrer le système ;
désactiver complètement cette fonctionnalité.
Si vous désirez restreindre cela, vous devez vérifier le fichier
/etc/inittab pour que la ligne incluant ctrlaltdel
appelle shutdown avec le paramètre -a.
La valeur par défaut dans Debian inclut ce paramètre :
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Le paramètre -a, conformément à la description de la page de
manuel shutdown(8), donne la possibilité de permettre à
certains utilisateurs d'arrêter le système. Pour cela, le fichier
/etc/shutdown.allow doit être créé et inclure le nom des
utilisateurs qui peuvent redémarrer le système. Quand la combinaison du
salut à trois doigts est exécutée en console, le programme va
vérifier si l'un des utilisateurs définis dans ce fichier est connecté. Si
aucun d'entre eux ne l'est, shutdown ne va pas
redémarrer le système.
Pour désactiver la combinaison Ctrl+Alt+Del, il suffit de commenter la ligne
contenant la définition de ctrlaltdel dans /etc/inittab.
N'oubliez pas d'exécuter init q après toute modification du
fichier /etc/inittab pour qu'elle prenne effet.
Les touches SysRq magiques sont des combinaisons de touches qui permettent aux utilisateurs connectés à une console système du noyau Linux de réaliser des commandes de bas niveau. Ces commandes de bas niveau sont envoyées en appuyant simultanément sur Alt+SysRq et une touche de commande. La touche SysRq est la même que « Impr écran » sur la plupart des claviers.
Depuis la publication de Etch, les touches SysRq magiques sont activées dans
le noyau Linux pour donner certains droits aux utilisateurs en console. Vous
pouvez confirmer cela en vérifiant si /proc/sys/kernel/sysrq
existe et vérifier ses valeurs :
$ cat /proc/sys/kernel/sysrq
438
La valeur par défaut ci-dessus permet toutes les fonctions SysRq sauf la possibilité d'envoyer des signaux aux processus. Par exemple, elle permet aux utilisateurs connectés en console de remonter tous les systèmes de fichiers en lecture seule, redémarrer le système ou provoquer une panique du noyau. Si toutes les fonctionnalités sont activées, ou sur les anciens noyaux (avant le 2.6.12), la valeur sera simplement 1.
Vous devriez désactiver cette fonctionnalité si l'accès à la console n'est
pas restreint aux utilisateurs autorisés : par exemple si la console est
connectée à une ligne modem, s'il y a un accès physique facile au système
ou s'il est exécuté dans un environnement virtualisé et d'autres
utilisateurs ont accès à la console. Pour cela, modifiez
/etc/sysctl.conf pour ajouter les lignes suivantes :
# Désactiver les touches SysRq magiques
kernel.sysrq = 0
Pour de plus amples renseignements, consultez le chapitre
sécurité de « Remote Serial Console HOWTO », la
documentation
SysRQ du noyau et l'article de Wikipédia sur
les touches SysRq magiques.
En montant un système de fichiers ext (ext2,
ext3 ou ext4), différentes options additionnelles
sont permises pour l'appel mount ou pour le fichier /etc/fstab.
Par exemple, ceci est une 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 fichiers de périphériques. Cela semble bon mais :
ne s'applique qu'aux systèmes de fichiers ext2 ou ext3 ;
peut être contourné facilement.
L'option noexec évite aux binaires d'être exécutés directement mais c'était facilement contournable dans les premières versions du noyau :
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission non accordée
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
dimanche 3 décembre 2000, 17:49:23 (UTC+0100)
Les versions plus récentes du noyau gèrent cependant l'option noexec correctement :
angrist:/tmp# mount | grep /tmp
/dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
angrist:/tmp# ./date
bash: ./tmp: Permission non accordée
angrist:/tmp# /lib/ld-linux.so.2 ./date
./date: error while loading shared libraries: ./date: failed to map segment
from shared object: Operation not permitted
However, many script kiddies have exploits which try to create and execute
files in /tmp. If they do not have a clue, they will fall into
this pit. In other words, a user cannot be tricked into executing a trojanized
binary in /tmp e.g. when /tmp is accidentally added
into the local 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'informations consultez le
bogue nº 116448.
Ce qui suit est un exemple un plus peu poussé. Prenez note que, bien que
/var peut être mis à noexec, certains logiciels[22] conservent leurs programmes
dans /var. Les mêmes conditions peuvent être appliquées à l'option nosuid.
/dev/sda6 /usr ext3 defaults,ro,nodev 0 2
/dev/sda12 /usr/share ext3 defaults,ro,nodev,nosuid 0 2
/dev/sda7 /var ext3 defaults,nodev,usrquota,grpquota 0 2
/dev/sda8 /tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda9 /var/tmp ext3 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2
/dev/sda10 /var/log ext3 defaults,nodev,nosuid,noexec 0 2
/dev/sda11 /var/account ext3 defaults,nodev,nosuid,noexec 0 2
/dev/sda13 /home ext3 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2
/dev/fd0 /mnt/fd0 ext3 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
(consultez http://bugs.debian.org/116448)
si APT::ExtractTemplates::TempDir n'est pas configuré
correctement (consultez apt-extracttemplates(1)). Vous pouvez
paramétrer cette variable dans le fichier /etc/apt/apt.conf vers
un autre répertoire que /tmp et qui aura les droits d'exécution.
Si vous mettez /usr en lecture seule, vous serez dans
l'incapacité d'installer de nouveaux paquets sur le 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. apt peut être configuré pour lancer des
commandes avant et après l'installation de paquets, ainsi vous pouvez avoir
envie de le configurer correctement.
Pour réaliser cela, 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 ». Cela survient principalement lorsque vous utilisez des fichiers lors de la mise à jour et que ces fichiers sont justement mis à jour. Vous pouvez trouver ces programmes en exécutant
# lsof +L1
Arrêtez ou relancez ces programmes et exécutez la commande de Post-Invoke
vous-même. Attention ! Cela veut dire que vous devrez
probablement redémarrer la session X (si vous en faites fonctionner une) à
chaque fois que vous faites une mise à jour majeure du système. Vous
pourriez aussi vous redemander si paramétrer /usr en lecture
seule est adapté au système. Consultez également cette discussion
sur debian-devel à propos de /usr en lecture seule.
PAM (Pluggable Authentication Modules) permet aux administrateurs système de
choisir comment les applications authentifient les utilisateurs. Remarquez que
PAM ne peut rien faire tant qu'une application n'a pas été compilée avec la
prise en charge pour PAM. La plupart des applications livrées dans Debian ont
cette prise en charge intégrée (Debian n'avait pas de prise en charge pour
PAM avant la version 2.2). La configuration actuelle par défaut pour
tout service activé avec PAM est d'émuler l'authentification UNIX (consultez
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz pour plus
d'informations sur la façon dont les services devraient fonctionner
dans Debian).
Chaque application avec la prise en charge de PAM fournit un fichier de
configuration dans /etc/pam.d qui peut être utilisé pour
modifier son comportement :
quelle fonction de base est utilisée pour l'authentification ;
quelle fonction de base est utilisée pour les sessions ;
comment les vérifications de mots de passe se comportent.
La description qui suit est loin d'être complète, pour plus d'informations
vous pouvez lire les Guides Linux-PAM de
référence. Cette documentation est fournie par le paquet
libpam-doc dans /usr/share/doc/libpam-doc/html/.
PAM offers you the possibility to go through several authentication steps at
once, without the user's knowledge. You could authenticate against a Berkeley
database and against the normal passwd file, and the user only
logs in if the authentication succeeds in both. You can restrict a lot with
PAM, just as you can open your system doors very wide. So be careful. A
typical configuration line has a control field as its second element.
Generally it should be set to requisite, which returns a login
failure if one module fails.
Vérifiez /etc/pam.d/common-password, englobé dans
/etc/pam.d/passwd [23]. Ce fichier est aussi englobé dans d'autres fichiers de
/etc/pam.d/ pour définir le comportement des mots de passe
utilisés dans les sous-systèmes qui donnent accès aux services sur la
machine, comme la connexion en console (login), les gestionnaires
de connexion graphiques (comme gdm ou lightdm) et la
connexion à distance (comme sshd).
Assurez-vous que le module pam_unix.so utilise l'option « sha512 » pour les mots de passe chiffrés. C'est le cas par défaut dans Debian Squeeze.
La ligne avec la définition du module pam_unix devrait ressembler à :
password [success=1 default=ignore] pam_unix.so nullok obscure minlen=8 sha512
Cette définition :
renforce le chiffrement des mots de passe conservés, en utilisant la fonction de hachage SHA-512 (option sha512) ;
active les vérifications de complexité des mots de passe (option
obscure) conformément à la définition de la page de manuel
pam_unix(8) ;
impose une taille minimale de mot de passe (option min) à 8 caractères.
Assurez-vous que les mots de passe chiffrés sont utilisés dans les applications PAM, car cela aide à protéger contre les attaques par dictionnaire. L'utilisation du chiffrement permet aussi d'utiliser des mots de passe plus longs que 8 caractères.
Puisque ce module est aussi utilisé pour définir la façon dont les mots de
passe sont changés (il est inclus par chpasswd), vous pouvez
renforcer la sécurité des mots de passe dans le système en installant
libpam-cracklib et en introduisant cette définition dans le
fichier de configuration /etc/pam.d/common-password :
# 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 [success=1 default=ignore] pam_unix.so obscure minlen=8 sha512 use_authok
La première ligne charge le module PAM cracklib, qui fournit la vérification
de la sûreté des mots de passe, attend un nouveau mot de passe avec une
taille minimale [24] de
12 caractères, une différence d'au moins 3 caractères par rapport
à l'ancien et autorise 3 essais. cracklib dépend d'une liste de mots
(comme wenglish, wfrench,
wbritish, etc.), assurez-vous donc d'en avoir installé une
adaptée à votre langue, sinon, cela peut être totalement inutile.
La seconde ligne (utilisant le module pam_unix.so) est la configuration par défaut dans Debian, conformément à la description précédente, hormis pour l'option use_authok. L'option use_authok est nécessaire si pam_unix.so est empilé après pam_cracklib.so, et est utilisé pour passer le mot de passe du module précédent. Sinon le mot de passe serait demandé deux fois à l'utilisateur.
Pour plus de renseignements sur le réglage de cracklib, consultez la page de
manuel pam_cracklib(8) et l'article Sécurité des
mots de passe sous Linux avec pam_cracklib de Hal Pomeranz.
En activant le module PAM cracklib, vous définissez une règle qui oblige les utilisateurs à utiliser des mots de passe sûrs.
Autrement, les modules PAM peuvent être configurés pour utiliser une
authentification à deux facteurs, comme : libpam-barada,
libpam-google-authenticator, libpam-oath,
libpam-otpw, libpam-poldi, libpam-usb ou
libpam-yubico. La configuration de ces modules permettrait
d'accéder au système en utilisant des mécanismes d'authentification externes
comme des cartes à puce, clefs USB externes ou mots de passe uniques
générés par des applications externes exécutées, par exemple, sur le
téléphone portable de l'utilisateur.
Please note that these restrictions apply to all users but not to the password changes done by the root user. The root user will be able to set up any password (any length or complexity) for personal use or others regardless of the restrictions defined here.
Afin d'être sûr que le superutilisateur peut se connecter uniquement à
partir des terminaux locaux, la ligne suivante doit être activée dans
/etc/pam.d/login :
auth requisite pam_securetty.so
Puis, vous devez modifier la liste des terminaux sur lesquels la connexion du
superutilisateur est autorisée dans le fichier /etc/securetty
(comme c'est décrit en Restreindre les
accès aux consoles, Section 4.7). Vous pouvez sinon activer le module
pam_access et modifier /etc/security/access.conf qui
permet un contrôle plus général et affiné, mais à qui il manque
(malheureusement) des messages de journalisation décents (la journalisation
dans PAM n'est pas standard et est un problème particulièrement peu
gratifiant à traiter). Nous reviendrons au fichier access.conf
un peu plus tard.
The following line should be enabled in /etc/pam.d/login to set up
user resource limits.
session required pam_limits.so
Cela restreint les ressources du système auxquelles les utilisateurs sont autorisées (consultez ci-après Restreindre l'utilisation des ressources : le fichier limits.conf, Section 4.11.2). Par exemple, vous pouvez restreindre le nombre de connexions (d'un groupe d'utilisateurs donné ou tout le système), le nombre de processus, la taille de la mémoire, etc.
Si vous voulez protéger su, pour que seules quelques personnes
puissent l'utiliser pour devenir superutilisateur sur le système, vous avez
besoin de créer un nouveau groupe « wheel » (c'est la meilleure
façon, étant donné qu'aucun fichier n'a ces permissions d'attribuées).
Ajoutez root et les autres utilisateurs, qui auront la possibilité d'utiliser
su pour devenir superutilisateur, à ce groupe. Ensuite, ajoutez
la ligne suivante dans /etc/pam.d/su :
auth requisite pam_wheel.so group=wheel debug
Cela permet d'être sûr que seules les personnes du groupe
« wheel » pourront utiliser su pour devenir
superutilisateur. Les autres utilisateurs ne seront pas capables de le
devenir. En fait, ils recevront un message de refus s'ils essayent de devenir
superutilisateur.
If you want only certain users to authenticate at a PAM service, this is quite
easy to achieve by using files where the users who are allowed to login (or
not) are stored. Imagine you only want to allow users 'ref' to log in via
ssh. So you put them into /etc/sshusers-allowed and
write the following into /etc/pam.d/ssh:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
Puisqu'il y eu de nombreuses vulnérabilités dites de fichier temporaire non
sécurisé, dont thttpd est un exemple (consultez DSA-883-1),
libpam-tmpdir est un bon paquet à installer. Tout ce que vous
avez à faire est d'ajouter ceci à
/etc/pam.d/common-session :
session optional pam_tmpdir.so
Une discussion a eu lieu à propos de l'ajout par défaut dans Debian.
Consultez http://lists.debian.org/debian-devel/2005/11/msg00297.html
pour obtenir plus de renseignements.
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 gèrent PAM (accès refusé par défaut).
Vous devriez vraiment jeter un sérieux coup d'œil à ce fichier. Vous
pouvez y définir les limites des ressources par utilisateur. Dans d'anciennes
versions, ce fichier de configuration était /etc/limits.conf,
mais dans les nouvelles versions (avec PAM), le fichier de configuration à
utiliser devrait être /etc/security/limits.conf.
Si vous ne désirez pas restreindre l'utilisation des ressources, n'importe quel utilisateur ayant une invite de commandes valable sur le système (ou même un intrus qui aurait compromis le système par un service ou un démon devenu fou) pourra utiliser autant de CPU, de mémoire, de pile, etc. que le système pourra fournir. Ce problème d'épuisement de ressources peut être réglé par l'utilisation de PAM.
Il existe un moyen d'ajouter des limites de ressources pour certains
interpréteurs de commandes (par exemple, bash a
ulimit, consultez bash(1)), mais comme ils ne
fournissent pas tous les mêmes limites et qu'un utilisateur peut changer
d'interpréteur (consultez chsh(1)), il est préférable de placer
ces limites dans les modules PAM ainsi elles s'appliqueront quel que soit
l'interpréteur de commandes utilisé et également aux modules PAM qui ne sont
pas orientés interpréteur.
Les limites de ressources sont imposées par le noyau, mais elles doivent être
configurées par le fichier limits.conf et la configuration PAM
des différents services doit charger le module PAM approprié. Vous pouvez
vérifier quels services imposent des limites en exécutant :
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
Habituellement, login, ssh et les gestionnaires de
session graphique (gdm, kdm ou xdm)
devraient imposer des limites aux utilisateurs, mais vous pouvez vouloir faire
cela dans d'autres fichiers de configuration de PAM, comme cron,
pour empêcher les démons système d'accaparer toutes les ressources
système..
Les paramètres de limites spécifiques que vous pouvez vouloir imposer dépendent des ressources du système, c'est l'une des principales raisons pour lesquelles aucune limite n'est imposée dans l'installation par défaut.
Par exemple, l'exemple de configuration ci-dessous impose une limite de 100 processus par utilisateur (pour empêcher les bombes de fork) ainsi qu'une limite de 10 Mo de mémoire par processus et une limite de 10 connexions simultanées. Les utilisateurs du groupe adm ont des limites supérieures et peuvent créer des fichiers core s'ils le désirent (c'est simplement une limite douce (soft)).
* soft core 0
* hard core 0
* hard rss 1000
* hard memlock 1000
* hard nproc 100
* - maxlogins 1
* hard data 102400
* hard fsize 2048
@adm hard core 100000
@adm hard rss 100000
@adm soft nproc 2000
@adm hard nproc 3000
@adm hard fsize 100000
@adm - maxlogins 10
Voici les limites qu'un utilisateur standard (y compris les démons système) aurait :
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 102400
file size (blocks, -f) 2048
max locked memory (kbytes, -l) 10000
max memory size (kbytes, -m) 10000
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) unlimited
Et voici les limites d'un utilisateur administratif :
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 102400
file size (blocks, -f) 100000
max locked memory (kbytes, -l) 100000
max memory size (kbytes, -m) 100000
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 2000
virtual memory (kbytes, -v) unlimited
Pour plus d'informations, consultez :
l'article Seifried's
Securing Linux Step by Step pour la section Limiting users
overview ;
le LASG pour la
section Limiting and monitoring users.
La prochaine étape est d'éditer les configuration et action de base lors de
la connexion de l'utilisateur. Notez que ce fichier ne fait pas partie de la
configuration PAM, c'est un fichier de configuration qui est pris en compte par
les programmes login et su, il n'est pas logique de
l'adapter aux cas pour lesquels ni l'un ni l'autre des programmes n'est appelé
au moins indirectement (le programme getty qui gère les consoles
et offre l'invite de connexion initiale appelle bien
login).
FAILLOG_ENAB yes
Si vous activez cette variable, les connexions échouées seront enregistrées dans un journal. Il est important d'en garder une trace pour repérer si quelqu'un tente une attaque par force brute.
LOG_UNKFAIL_ENAB no
En configurant cette variable à « yes », les noms d'utilisateur seront enregistrés en cas d'échec de connexion. Laisser la configuration à « no » (par défaut) est plus prudent, puisque sinon, les mots de passe d'utilisateurs pourraient être enregistrés par erreur (si un utilisateur fait une faute de frappe et entre le mot de passe à la place de l'identifiant). Si vous configurez à « yes », assurez-vous que les journaux ont les droits adéquats (640 par exemple, avec une configuration de groupe adéquate comme adm).
SYSLOG_SU_ENAB yes
Cela va activer l'écriture dans les journaux de syslog des
tentatives de su. Plutôt important sur des machines sérieuses,
mais notez que cela peut aussi bien être à la base de problèmes de respect
de la vie privée.
SYSLOG_SG_ENAB yes
La même chose que SYSLOG_SU_ENAB, mais s'applique au programme
sg.
ENCRYPT_METHOD SHA512
Comme mentionné ci-dessus, les mots de passe chiffrés réduisent
considérablement le problème des attaques par dictionnaire étant donné que
vous pouvez utiliser des mots de passe plus longs. Cette définition doit
être cohérente avec la valeur définie dans
/etc/pam.d/common-password.
/etc/pam.d/loginLe fichier de configuration de connexion peut être ajusté pour implémenter une politique plus stricte. Par exemple, la configuration par défaut peut être modifiée pour augmenter le délai entre les invites de connexion. La configuration par défaut définit à 3 secondes le délai :
auth optional pam_faildelay.so delay=3000000
Augmenter la valeur de delay à une valeur suffisamment grande permet de rendre plus difficiles les tentatives de connexion en utilisant la force brute. Si un mauvais mot de passe est fourni, le pirate potentiel (ou le simple utilisateur !) doit attendre plus longtemps avant d'obtenir une nouvelle invite de connexion, ce qui prend pas mal de temps quand vous testez des mots de passe. Par exemple, avec delay=10000000, les utilisateurs devront attendre 10 secondes s'ils ont tapé un mauvais mot de passe.
Ce fichier permet aussi de définir le message présenté aux utilisateurs avant de se connecter. C'est désactivé par défaut, comme ci-dessous :
# auth required pam_issue.so issue=/etc/issue
Si la politique de sécurité l'exige, ce fichier peut être utilisé pour
montrer un message standard indiquant que l'accès au système est restreint et
que l'accès des utilisateurs est journalisé. Ce type de déclaration peut
être nécessaire dans certains environnements et juridictions. Pour
l'activer, ajoutez simplement les renseignements nécessaires dans le fichier
/etc/issue [25] et
décommentez la ligne activant le module pam_issue.so dans
/etc/pam.d/login. Dans ce fichier, vous pouvez aussi activer des
fonctionnalités supplémentaires qui pourraient être pertinentes à appliquer
aux politiques de sécurité locales comme :
la définition de règles accordant l'accès à certains utilisateurs suivant
l'heure, en activant le module pam_time.so et en configurant
/etc/security/time.conf en conséquence (désactivée par
défaut) ;
la définition de sessions de connexion pour utiliser les limitations aux
utilisateurs conformément à la définition de
/etc/security/limits.conf (activée par défaut) ;
la présentation à l'utilisateur des renseignements sur la précédente connexion (activée par défaut) ;
l'affichage d'un message (/etc/motd et
/run/motd.dynamic) aux utilisateurs après la connexion (activée
par défaut) ;
/etc/ftpusersCe fichier contient une liste d'utilisateurs qui ne sont pas autorisés à se connecter à l'hôte en utilisant FTP. Utilisez uniquement ce fichier si vous voulez réellement autoriser le FTP (qui n'est, en général, pas recommandé car il utilise des mots de passe en clair). Si le démon gère PAM, cela peut être utilisé pour permettre ou refuser certains services aux utilisateurs.
FIXME (bogue) : Est-ce un bogue que le fichier par défaut
ftpusers dans Debian ne contienne pas tous les
utilisateurs d'administration (dans base-passwd) ?
Un moyen pratique d'ajouter tous les comptes système à
/etc/ftpusers est d'exécuter
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers
Si vous avez réellement besoin que des utilisateurs deviennent
superutilisateur sur le 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 superutilisateur et d'utiliser à la place su. En réalité,
la meilleure solution est de supprimer su et de changer pour le
mécanisme sudo qui a une logique plus large et plus de
fonctionnalités que su. Cependant, su est plus
commun étant donné qu'il est utilisé sur beaucoup d'autres UNIX.
sudo allows the user to execute defined commands under another
user's identity, even as root. If the user is added to
/etc/sudoers and authenticates correctly, the commands defined in
/etc/sudoers get enabled. Violations, such as incorrect passwords
or trying to run a program you don't have permission for, are logged and mailed
to root.
Vous devriez également modifier /etc/security/access.conf pour
désactiver la connexion d'administration à distance. Ainsi, les utilisateurs
doivent exécuter su (ou sudo) pour utiliser des
pouvoirs administratifs et ainsi la trace d'audit appropriée sera toujours
générée.
Vous devez ajouter la ligne suivante à /etc/security/access.conf,
le fichier de configuration par défaut Debian contient une ligne d'exemple
commentée :
-:wheel:ALL EXCEPT LOCAL
Rappelez-vous d'activer le module pam_access pour chaque service
(ou configuration par défaut) dans /etc/pam.d/ si vous voulez que
vos modifications dans /etc/security/access.conf soient prises en
compte.
Parfois, vous pensez avoir besoin d'utilisateurs créés dans le système local de façon à fournir un service donné (service courrier POP3 ou FTP). Avant tout, rappelez-vous que l'implémentation PAM dans Debian GNU/Linux vous autorise à valider les utilisateurs avec une grande variété de répertoires de services externes (radius, LDAP, etc.) fournis par les paquets libpam.
Si des utilisateurs doivent être créés et que le système est accessible à
distance, prenez en compte que des utilisateurs pourront se connecter au
système. Cela peut être corrigé en donnant aux utilisateurs un
interpréteur de commandes vide (/dev/null) (qui doit être dans
/etc/shells). Si vous voulez autoriser les utilisateurs à
accéder au système mais limiter leurs mouvements, vous pouvez utiliser le
fichier /bin/rbash, ce qui est équivalent à l'ajout de l'option
-r dans bash (consultez INTERPRÉTEUR RESTREINT dans
bash(1)). Veuillez noter que même avec un interpréteur de
commandes restreint, un utilisateur ayant accès à un programme interactif
(qui peut permettre l'exécution d'un sous-interpréteur) peut être capable de
passer outre les limites de l'interpréteur de commandes.
Debian fournit actuellement dans la version unstable le module
pam_chroot (dans le paquet libpam-chroot) (et il
pourrait être inclus dans les prochaines versions stables). Une alternative
à celui-ci est de chrooter le service qui fournit la connexion à
distance (ssh, telnet). [26]
Si vous voulez restreindre quand les utilisateurs peuvent accéder au
système, vous devrez personnaliser /etc/security/access.conf en
fonction de vos besoins.
Des informations sur la façon de chrooter des utilisateurs
accédant au système par le service ssh sont décrites dans Environnement de chroot pour SSH, Annexe
G.
Si vous êtes vraiment paranoïaque, vous pourriez configurer l'environnement pour superviser ce que les utilisateurs font sur le système. Cette section présente quelques conseils avec différents utilitaires que vous pouvez utiliser.
Vous pouvez utiliser la commande script pour surveiller à la fois
ce que les utilisateurs exécutent et les résultats de leurs commandes. Vous
ne pouvez pas configurer script comme un interpréteur de
commandes (même si vous l'ajoutez à /etc/shells). Mais vous
pouvez faire en sorte que le fichier d'initialisation de l'interpréteur de
commandes exécute les commandes suivantes :
umask 077
exec script -q -a "/var/log/sessions/$USER"
Bien sûr, si vous faites cela pour tout le système, cela veut dire que
l'interpréteur ne continuerait pas à lire les fichiers d'initialisation
personnels (car l'interpréteur sera écrasé par script). Une
solution est de le faire dans les fichiers d'initialisation de l'utilisateur
(mais l'utilisateur pourrait alors l'enlever, consultez les commentaires sur
cela ci-dessous).
Vous devez également configurer les fichiers dans le répertoire d'audit (dans
l'exemple /var/log/sessions/) pour que les utilisateurs puissent y
écrire, mais pas supprimer le fichier. Cela pourrait être fait, par exemple,
en créant les fichiers de session d'utilisateur en avance et en positionnant
l'option append-only (« append-only ») en utilisant
chattr.
Une alternative utile pour les administrateurs système, qui inclut des informations de date, serait :
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"
Si vous voulez passer en revue ce que les utilisateurs entrent dans
l'interpréteur de commandes (mais sans voir le résultat), vous pouvez
configurer un /etc/profile pour tout le système qui configure
l'environnement pour que toutes les commandes soient enregistrées dans le
fichier d'historique. La configuration pour tout le système doit être
réalisée de telle façon que les utilisateurs ne puissent pas enlever les
capacités d'audit de leur interpréteur de commandes. C'est plutôt
spécifique à l'interpréteur de commandes, donc assurez-vous que tous les
utilisateurs utilisent un interpréteur de commandes qui le permet.
Par exemple, pour bash, le fichier /etc/profile pourrait être
paramétré ainsi [27] :
HISTFILE=~/.bash_history
HISTSIZE=10000
HISTFILESIZE=999999
# Empêcher les utilisateurs d'entrer des commandes qui seraient
# ignorées dans le fichier d'historique
HISTIGNORE=""
HISTCONTROL=""
readonly HISTFILE
readonly HISTSIZE
readonly HISTFILESIZE
readonly HISTIGNORE
readonly HISTCONTROL
export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
Afin que cela fonctionne, l'utilisateur doit être seulement capable d'ajouter
des informations au fichier .bash_history. Vous devez
aussi positionner l'attribut append-only en utilisant le
programme chattr sur .bash_history pour tous les
utilisateurs. [28]
Note that you could introduce the configuration above in the user's
.profile. But then you would need to setup permissions properly
in such a way that prevents the user from modifying this file. This includes:
having the user's home directories not belong to the user (since the
user would be able to remove the file otherwise) but at the same time allow the
user to read the .profile configuration file and write on the
.bash_history. It would be good to set the immutable
flag (also using chattr) for .profile too if you do
it this way.
L'exemple précédent est une manière simple de configurer l'audit
utilisateur, mais qui peut ne pas être utile pour des systèmes complexes ou
pour ceux dans lesquels les utilisateurs ne peuvent pas exécuter
d'interpréteur de commande du tout (ou exclusivement). Si c'est le cas, vous
devrez examiner acct, les utilitaires de comptabilité. Ces
utilitaires archiveront toutes les commandes exécutées par les utilisateurs
ou processus du système au détriment de l'espace disque.
Lors de l'activation de la comptabilité, toutes les informations sur les
processus et utilisateurs sont conservées dans /var/account/,
plus spécifiquement dans le fichier pacct. Le paquet de
comptabilité inclut certains outils (sa et ac) afin
d'analyser ces données.
Si vous êtes complètement paranoïaque et que vous voulez auditer toutes les
commandes des utilisateurs, vous pouvez prendre les codes source de
bash, les modifier et récupérer dans un fichier toutes les
commandes qu'un utilisateur tape. Vous pourriez aussi avoir
ttysnoop constamment en attente de nouveaux ttys [29] et reverser toutes les sorties
dans un fichier. Un autre programme utile est snoopy (consultez
également la
page du projet) qui est un programme transparent pour l'utilisateur
qui se positionne comme une bibliothèque fournissant une encapsulation des
appels execve(), toute commande exécutée est journalisée par
syslogd en utilisant la fonctionnalité authpriv
(généralement stockée dans /var/log/auth.log).
Si vous désirez voir ce que font vraiment les utilisateurs, comme
l'heure à laquelle ils se connectent, vous pouvez utiliser la base de données
wtmp qui contient toutes les informations concernant les
connexions. Ce fichier peut être employé avec plusieurs utilitaires, parmi
eux sac peut sortir un profil de chaque utilisateur montrant dans
quel créneau horaire il se connecte habituellement au système.
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.
En fonction de la politique d'utilisateur, vous pourriez modifier la façon dont les renseignements sont partagés entre utilisateurs, c'est-à-dire quels sont les droits de nouveaux fichiers par défaut créés par les utilisateurs.
Le paramètre umask par défaut de Debian est 022, cela
signifie que les fichiers (et les répertoires) peuvent être lus et accédés
par le groupe de l'utilisateur et par tout autre utilisateur du système.
Cette définition est configurée dans le fichier de configuration normalisé
/etc/profile utilisé par tous les interpréteurs de commandes.
If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). Debian (by default[30]) creates one group per user so that only the user is included in its group. Consequently 027 and 077 are equivalent as the user's group contains only the user.
Cette modification est configurée en définissant un réglage correct de
umask pour tous les utilisateurs. Vous pouvez modifier cela en
introduisant un appel umask dans les fichiers de configuration de
l'interpréteur de commandes : /etc/profile (source par tous
les interpréteurs de commandes compatibles Bourne),
/etc/csh.cshrc, /etc/csh.login,
/etc/zshrc et probablement d'autres (en fonction des
interpréteurs de commandes installés sur le système). Vous pouvez aussi
modifier le réglage de UMASK dans /etc/login.defs. De
toutes celles-là, la dernière chargée par l'interpréteur de commandes est
prioritaire. L'ordre est : la configuration système par défaut pour
l'interpréteur de l'utilisateur (c'est-à-dire /etc/profile et
les autres fichiers de configuration globaux du système) et ensuite ceux de
l'utilisateur (ses ~/.profile,
~/.bash_profile, etc.). Certains interpréteurs, cependant,
peuvent être exécutés avec une valeur nologin avec laquelle
certains de ces fichiers pourraient être sautés. Consultez la page de manuel
de l'interpréteur pour obtenir de plus amples renseignements.
Pour les connexions qui utilisent login, la définition de
UMASK de /etc/login.defs est utilisée avant toutes les
autres. Cependant, cette valeur ne s'applique pas aux programmes exécutés
par l'utilisateur qui n'utilisent pas login comme ceux exécutés
à travers su, cron ou ssh.
N'oubliez pas de vérifier et éventuellement modifier les fichiers de
configuration utilisateur sous /etc/skel/ car ce sont ceux qui
seront utilisés par défaut quand ils sont créés avec la commande
adduser. Les fichiers de configuration utilisateur Debian par
défaut ne contiennent pas d'appel umask mais s'il y en a dans
n'importe quel fichier de configuration utilisateur, les utilisateurs
nouvellement créés pourraient avoir une valeur différente.
Notez, cependant, que les utilisateurs peuvent modifier leur propre paramètre umask s'ils le désirent, le rendant plus permissif ou plus restrictif, en modifiant leurs propres fichiers de configuration utilisateur.
Le paquet libpam-umask règle l'umask par défaut
utilisant PAM. Après l'installation du paquet, ajoutez ceci à
/etc/pam.d/common-session :
session optional pam_umask.so umask=077
Enfin, vous pourriez envisager de modifier l'umask par défaut du
superutilisateur à 022 (tel que défini dans /root/.bashrc) à
une valeur plus restrictive. Cela évitera à l'administrateur système de
laisser fuir par inadvertance des fichiers sensibles lorsqu'il travaille en
tant que superutilisateur dans des répertoires lisibles par tous (comme
/tmp) et en les rendant lisibles aux autres utilisateurs.
FIXME : Besoin de contenu. Indiquer les conséquences de changement des
permissions des paquets lors d'une mise à jour (un administrateur aussi
paranoïaque que cela devrait chrooter ses utilisateurs au
passage) s'il n'utilise pas dpkg-statoverride.
Si vous avez besoin d'accorder aux utilisateurs un accès au système avec un interpréteur de commandes, réfléchissez-y très soigneusement. Un utilisateur peut, par défaut à moins d'être dans un environnement extrêmement restreint (comme une prison chroot), récupérer un assez grand nombre d'informations concernant le système, y compris :
certains fichiers de configuration dans /etc. Cependant, les
permissions par défaut de Debian pour certains fichiers sensibles (qui
peuvent, par exemple, contenir des mots de passe) empêcheront l'accès à des
informations critiques. Pour voir quels fichiers ne sont accessibles que par
le superutilisateur, exécutez par exemple find /etc -type f -a -perm 600
-a -uid 0 en tant que superutilisateur ;
vos paquets installés, soit en consultant la base de données des paquets,
soit dans le répertoire /usr/share/doc, soit en devinant en
regardant les binaires et bibliothèques installés sur le système ;
certains fichiers journaux dans /var/log. Notez également que
quelques fichiers journaux ne sont accessibles qu'au superutilisateur et au
groupe adm (essayez find /var/log -type f -a -perm
640) et certains ne sont même disponibles que pour le superutilisateur
(essayez find /var/log -type f -a -perm 600 -a -uid 0).
Que peut voir un utilisateur dans le système ? Probablement un assez grand nombre de choses, essayez ceci (prenez une profonde respiration) :
find / -type f -a -perm +006 2>/dev/null
find / -type d -a -perm +007 2>/dev/null
The output is the list of files that a user can see and the accessable directories.
Si vous accordez toujours un accès d'interpréteur de commandes aux utilisateurs, vous pouvez vouloir limiter les informations qu'ils peuvent voir des autres utilisateurs. Les utilisateurs ayant un accès d'interpréteur de commandes ont tendance à créer un grand nombre de fichiers dans leur répertoire $HOME : boîtes aux lettres, documents personnels, configuration des applications X/GNOME/KDE, etc.
Sous Debian, chaque utilisateur est créé avec un groupe associé et aucun utilisateur n'appartient au groupe d'un autre utilisateur. Il s'agit du comportement par défaut : quand un compte d'utilisateur est créé, un groupe du même nom est créé et l'utilisateur lui est attribué. Cela évite le concept d'un groupe users qui peut rendre plus difficile pour les utilisateurs de cacher des informations aux autres utilisateurs.
Cependant, les répertoires $HOME des utilisateurs sont créés avec les permissions 0755 (lisible par le groupe et par tout le monde). Les permissions de groupe ne sont pas un problème car seul l'utilisateur appartient au groupe, cependant les permissions pour les autres peuvent être (ou non) un problème selon vos règles locales.
Vous pouvez changer ce comportement pour que la création d'utilisateur
fournisse des permissions sur $HOME différentes. Pour changer ce
comportement pour les nouveaux utilisateurs quand ils seront créés,
changez DIR_MODE dans le fichier de configuration
/etc/adduser.conf à 0750 (pas d'accès en lecture pour tout le
monde).
Les utilisateurs peuvent toujours partager des informations, mais pas directement dans leur répertoire $HOME à moins qu'ils ne changent les permissions de celui-ci.
Notez que désactiver les répertoires utilisateur lisibles par tout le monde
empêchera les utilisateurs de créer leurs pages personnelles dans le
répertoire ~/public_html car le serveur web ne pourra pas lire un
composant du chemin — leur répertoire $HOME. Si vous voulez
permettre aux utilisateurs de publier des pages HTML dans leur
~/public_html, changez DIR_MODE en 0751. Cela permettra
au serveur web d'accéder à ce répertoire (qui devrait lui-même avoir le
mode 0755) et de fournir le contenu publié par les utilisateurs. Bien sûr,
nous ne parlons ici que d'une configuration par défaut ; les utilisateurs
peuvent généralement ajuster les permissions de leurs fichiers comme ils le
désirent, ou vous pouvez conserver le contenu destiné au web dans un
emplacement séparé qui n'est pas un sous-répertoire du répertoire
$HOME de chaque utilisateur.
Il y a plusieurs cas dans lesquels un utilisateur a besoin de créer un grand
nombre de comptes utilisateur et de fournir des mots de passe pour tous
ceux-ci. Bien sûr, l'administrateur peut facilement positionner le mot de
passe pour être le même que le nom du compte utilisateur, mais cela n'est pas
très conseillé sur le plan de la sécurité. Une meilleure approche est
d'utiliser un programme de génération de mots de passe. Debian fournit les
paquets makepasswd, apg et pwgen qui
contiennent des programmes (dont le nom est le même que celui du paquet) qui
peuvent être utilisés dans ce but. makepasswd génère des mots
de passe vraiment aléatoires avec un accent sur la sécurité plus que la
prononçabilité tandis que pwgen essaie de créer des mots de
passe sans signification, mais prononçables (bien sûr, cela dépend de votre
langue maternelle). apg dispose d'algorithmes pour les deux (il y
a une version client/serveur pour ce programme, mais elle n'est pas incluse
dans le paquet Debian).
passwd ne permet pas une attribution non interactive des mots de
passe (car il utilise un accès direct au terminal tty). Si vous désirez
changer des mots de passe lors de la création d'un grand nombre
d'utilisateurs, vous pouvez les créer en utilisant adduser avec
l'option --disabled-login, puis utiliser usermod ou
chpasswd [31]
(tous les deux dans le paquet passwd, ils sont donc déjà
installés). Si vous voulez utiliser un fichier avec toutes les informations
pour créer les utilisateurs comme un processus batch, il sera probablement
préférable d'utiliser newusers.
Les mots de passe des utilisateurs peuvent parfois devenir le maillon
faible de la sécurité d'un système donné. Cela provient du fait que
quelques utilisateurs choisissent des mots de passe faibles pour leur compte
(et plus il y a d'utilisateurs, plus grandes sont les chances que cela se
produise). Même si vous mettez en place des vérifications avec le module PAM
cracklib et les limitations sur les mots de passe comme décrites dans Authentification utilisateur : PAM, Section 4.11.1,
les utilisateurs pourront toujours utiliser des mots de passe faibles. Comme
l'accès utilisateur peut inclure un accès à une invite de commandes à
distance (en espérant que ce soit avec ssh), il est important de
rendre les mots de passe aussi difficile à deviner que possible pour les
attaquants à distance, particulièrement s'ils ont pu récupérer des
informations importantes comme les noms d'utilisateur ou même les fichiers
passwd et shadow eux-mêmes.
A system administrator must, given a big number of users, check if the
passwords they have are consistent with the local security policy. How to
check? Try to crack them as an attacker would if having access to the hashed
passwords (the /etc/shadow file).
Un administrateur peut utiliser john ou crack (tous
deux utilisent la force brute) ensemble avec une liste de mots appropriés pour
vérifier les mots de passe utilisateurs et prendre des mesures appropriées si
un mot de passe faible est détecté. Vous pouvez rechercher des paquets
Debian contenant des listes de mots en utilisant apt-cache search
wordlist ou vous pouvez également visiter des sites de listes de mots
sur Internet classique comme ftp://ftp.ox.ac.uk/pub/wordlists
ou ftp://ftp.cerias.purdue.edu/pub/dict.
L'inactivité des utilisateurs pose habituellement un problème de sécurité, un utilisateur peut être inactif parce qu'il est parti déjeuner ou parce qu'une connexion à distance s'est bloquée et n'a pas été rétablie. Quelqu'en soit la raison, les utilisateurs inactifs peuvent amener à une compromission :
car la console de l'utilisateur peut être débloquée et peut être accédée par un intrus ;
because an attacker might be able to re-attach to a closed network connection
and send commands to the remote shell (this is fairly easy if the remote shell
is not encrypted as in the case of telnet).
Certains systèmes à distance ont même été compromis à travers un
screen inactif (et détaché).
La déconnexion automatique des utilisateurs inactifs est habituellement une partie qui doit être imposée par les règles de sécurité locales. Plusieurs moyens existent pour cela :
si bash est l'interpréteur de commandes de l'utilisateur, un
administrateur système peut positionner une valeur TMOUT par
défaut (consultez bash(1)) qui entraînera la déconnexion
automatique des utilisateurs distants inactifs. Notez que cela doit être
configuré avec l'option -o ou les utilisateurs pourront la
changer (ou la désactiver) ;
installez timeoutd et configurez /etc/timeouts selon
vos règles de sécurité locales. Le démon regardera les utilisateurs
inactifs et mettra un terme à leur invite de commandes en fonction ;
installez autolog et configurez-le pour enlever les utilisateurs
inactifs.
Les démons timeoutd et autolog sont les méthodes
préférées car, après tout, les utilisateurs peuvent changer d'interpréteur
de commandes par défaut ou peuvent, après avoir exécuté leur interpréteur
de commandes par défaut, basculer sur un autre interpréteur de commandes (non
contrôlé).
L'encapsulation TCP a été développée quand il n'y avait pas de réels
filtres de paquets disponibles et que les contrôles d'accès étaient
nécessaires. Toutefois, ils sont toujours très intéressants et utiles.
L'encapsulation TCP vous permet d'autoriser ou de refuser un service à un
hôte ou à un domaine et de définir une règle par défaut pour les
autorisations et les refus (toutes réalisées au niveau applicatif). Pour
plus de détails, jetez un œil à hosts_access(5).
De nombreux services installés dans Debian sont soit :
lancés par le service tcpwrapper (tcpd) ;
compilés avec la prise en charge de libwrapper.
D'un côté, pour des services configurés dans /etc/inetd.conf,
cela comprend telnet, ftp, netbios,
swat et finger), vous observerez que le fichier de
configuration exécute avant tout /usr/sbin/tcpd. D'un autre
côté, même si un service n'est pas lancé par le super démon
inetd, il peut être compilé avec la prise en charge pour les
règles d'encapsulation TCP. Les services suivant sont compilés avec prise en
charge d'encapsulation TCP dans Debian : ssh,
portmap, in.talk, rpc.statd,
rpc.mountd, gdm, oaf (le démon
d'activation GNOME), nessus et beaucoup d'autres.
Pour voir quels paquets utilisent tcpwrappers [32], essayez :
$ apt-cache rdepends libwrap0
Tenez compte de cela quand vous utilisez tcpdchk (un vérificateur
très utile de règles et syntaxe de fichier de configuration d'encapsulation
TCP). Quand vous pouvez ajouter des services indépendants (qui sont liés à
la bibliothèque d'encapsulation) dans les fichiers host.deny et
hosts.allow, tcpdchk vous informera qu'il ne peut pas
trouver les services mentionnés étant donné qu'il les cherche dans
/etc/inetd.conf (la page de manuel n'est pas totalement précise
ici).
À présent, voici une petite astuce et probablement le plus petit système de détection d'intrusions disponible. Généralement, vous devriez disposer d'une politique correcte concernant le pare-feu en première ligne, puis disposer de l'encapsulation TCP en seconde ligne de défense. Un petit truc est de mettre en place une commande SPAWN [33] dans /etc/hosts.deny qui enverra un courrier au superutilisateur quand un service refusé déclenche l'encapsulation :
ALL: ALL: SPAWN ( \
echo -e "\n\
Encapsulation TCP \: Connexion refusée\n\
Par \: $(uname -n)\n\
Processus \: %d (pid %p)\n\
Utilisateur \: %u\n\
Hôte \: %c\n\
Date \: $(date)\n\
" | /usr/bin/mail -s "Connexion à %d bloquée" root) &
Attention : L'exemple ci-dessus peut-être facilement sujet à une attaque par déni de service en soumettant énormément de connexions dans une période très courte. De nombreux courriers signifient de nombreuses E/S en envoyant uniquement quelques paquets.
Il est facile de voir que le traitement de journaux et alertes est un problème sérieux sur un système sécurisé. Supposons qu'un système est parfaitement configuré et sécurisé à 99 %. Si l'attaque représentant le 1 % vient à arriver et qu'il n'y a pas de mesures de sécurité mises en place pour, dans un premier temps, détecter cela et, dans un deuxième temps, lancer l'alerte, le système n'est pas sécurisé du tout.
Debian GNU/Linux fournit quelques outils pour effectuer des analyses de
journaux, notamment swatch[34], logcheck ou log-analysis (tous
ont besoin d'être personnalisés pour enlever les choses non nécessaires des
comptes-rendus). Il peut être également utile, si le système est proche,
d'avoir les journaux du système affichés sur une console virtuelle. C'est
utile car vous pouvez (de loin) voir si le système se comporte correctement.
Le fichier /etc/syslog.conf de Debian est fourni avec une
configuration commentée par défaut ; pour l'activer, décommenter les
lignes et redémarrez syslogd (/etc/init.d/syslogd
restart) :
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn /dev/tty8
Pour colorer les journaux, vous pouvez jeter un œil à
colorize, ccze ou glark. Une grande
partie de l'analyse des journaux ne peut pas être couverte ici, une bonne
ressource d'informations est disponible dans les livres comme Gestion des journaux de
sécurité : identification de motifs au milieu du chaos. Dans
tous les cas, même des outils automatiques ne peuvent rivaliser avec le
meilleur outil d'analyse : votre cerveau.
Le paquet logcheck dans Debian est divisé en trois paquets
logcheck (le programme principal), logcheck-database
(une base de données d'expressions rationnelles pour le programme) et
logtail (affiche les lignes du journal qui n'ont pas encore été
lues). Le comportement par défaut sous Debian (dans
/etc/cron.d/logcheck) est que logcheck est exécuté
toutes les heures et une fois après le démarrage.
Cet outil peut être assez utile s'il est personnalisé correctement pour
alerter l'administrateur d'événements système inhabituels.
logcheck peut être complètement personnalisé pour envoyer des
courriers selon les événements récupérés des journaux et qui sont dignes
d'attention. L'installation par défaut inclut des profils pour des
événements ignorés et des violations de règles pour trois configurations
différentes (station de travail, serveur et paranoïaque). Le paquet Debian
contient un fichier de configuration /etc/logcheck/logcheck.conf,
qui définit à quel utilisateur sont envoyés les vérifications. Il permet
également aux paquets qui fournissent des services d'implémenter de nouvelles
règles dans les répertoires :
/etc/logcheck/cracking.d/_paquet_,
/etc/logcheck/violations.d/_paquet_,
/etc/logcheck/violations.ignore.d/_paquet_,
/etc/logcheck/ignore.d.paranoid/_paquet_,
/etc/logcheck/ignore.d.server/_paquet_ et
/etc/logcheck/ignore.d.workstation/_paquet_. Cependant, peu de
paquets le font actuellement. Si vous avez une règle qui peut être utile à
d'autres utilisateurs, veuillez l'envoyer comme un rapport de bogue sur le
paquet approprié (comme un bogue de gravité wishlist). Pour obtenir
plus de renseignements, veuillez consulter
/usr/share/doc/logcheck/README.Debian.
Le meilleur moyen de configurer logcheck est d'éditer son fichier
de configuration principal /etc/logcheck/logcheck.conf après
l'avoir installé. Modifiez l'utilisateur par défaut (root) à qui seront
envoyés par courrier les comptes-rendus. Vous devriez également y
positionner le niveau de compte-rendu. logcheck-database a trois
niveaux de compte-rendu de verbosité croissante : station de travail,
serveur, paranoïaque. « serveur » étant le niveau par défaut,
« paranoïaque » n'est recommandé que pour les machines de haute
sécurité ne faisant fonctionner qu'aussi peu de services que possible et
« station de travail » est pour les machines relativement
protégés et non critiques. Si vous désirez ajouter de nouveaux fichiers
journaux, ajoutez-les simplement à
/etc/logcheck/logcheck.logfiles. Celui-ci est configuré pour une
installation de syslog par défaut.
Une fois fait, vous pouvez vouloir vérifier les courriers envoyés, pour les
quelques premiers jours, semaines ou mois. Si estimez recevoir des messages
indésirables, ajoutez simplement l'expression rationnelle (consultez
regex(7) et egrep(1)) qui correspond à ces messages
au fichier
/etc/logcheck/ignore.d.niveau_de_compte-rendu/local.
Essayez de faire correspondre à la ligne entière du journal. Des détails
sur l'écriture des règles sont expliqués dans
/usr/share/doc/logcheck-database/README.logcheck-database.gz.
C'est un processus d'affinement perpétuel ; une fois que les messages
envoyés sont toujours pertinents, vous pouvez considérer que l'affinement est
terminé. Notez que si logcheck ne trouve rien de pertinent dans
le système, il ne vous enverra pas de courrier même s'il fonctionne (donc,
vous pouvez ne recevoir de courrier qu'une fois par semaine si vous êtes
chanceux).
Debian livre une configuration standard de syslog (dans
/etc/syslog.conf) qui archive les messages dans les fichiers
appropriés en fonction de la facilité du système. Vous devriez être
familier avec cela ; jetez un œil au fichier
syslog.conf et à la documentation si vous ne l'êtes pas. Si
vous avez l'intention de maintenir un système sécurisé, vous devriez être
conscient de l'endroit où les journaux 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 journalisation (il reçoit les journaux de tous les autres systèmes).
Le courrier du superutilisateur devrait être pris en considération
également, de nombreux contrôles de sécurité (comme snort)
envoient des alertes dans la boîte aux lettres du superutilisateur. Celle-ci
pointe généralement sur le premier utilisateur créé sur le système
(vérifiez /etc/aliases). Veillez à envoyer le courrier du
superutilisateur à un endroit où il sera lu (soit localement soit à
distance).
Il y a d'autres comptes et alias « rôles » sur le système. Sur un petit système, le plus simple est probablement de s'assurer que tous ces alias pointent vers le compte du superutilisateur, et que les messages à destination du superutilisateur sont retransmis vers la boîte aux lettres personnelle de l'administrateur système.
FIXME : Il serait intéressant de dire comment un système Debian peut
envoyer/recevoir des messages SNMP relatifs à des problèmes de sécurité
(jfs). Voir : snmptragfmt, snmp et
snmpd.
A loghost is a host which collects syslog data remotely over the network. If
one of your machines is cracked, the intruder is not able to cover the tracks,
unless hacking the loghost as well. So, the loghost should be especially
secure. Making a machine a loghost is simple. Just start the
syslogd with syslogd -r and a new loghost is born.
In order to do this permanently in Debian, edit
/etc/default/syslogd and change the line
SYSLOGD=""
par
SYSLOGD="-r"
Ensuite, configurez les autres machines afin qu'elles envoient les données au
loghost. Ajoutez une entrée comme celle qui suit dans
/etc/syslog.conf :
facilité.niveau @votre_loghost
Consultez la documentation pour savoir ce qu'on peut utiliser à la place de facilité et niveau (ils ne devraient pas être mot pour mot comme cela). Si vous voulez tout archiver à distance, il suffit d'écrire :
*.* @votre_loghost
dans 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 journalisation locaux). Consultez les pages de
manuel syslog(3), syslogd(8) et
syslog.conf(5) pour toutes informations complémentaires.
It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder who has access to them.
Certaines permissions de fichiers de journalisation ne sont pas parfaites
après l'installation (mais, bien sûr, cela dépend vraiment de vos règles de
sécurité locales). Premièrement /var/log/lastlog et
/var/log/faillog n'ont pas besoin d'être lisibles par les
utilisateurs normaux. Dans lastlog, vous pouvez voir qui s'est
connecté récemment, et dans faillog, vous voyez un résumé des
connexions qui ont échouées. L'auteur recommande de faire un chmod
660 sur les deux fichiers. Faites un tour rapide des fichiers de
journalisation et décidez avec beaucoup d'attention quels fichiers de
journalisation vous rendez lisible ou modifiable par un utilisateur avec un UID
différent de 0 et un autre groupe que « adm » ou
« root ». Vous pouvez facilement vérifier cela sur le système
avec :
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
(voir à quels utilisateurs appartiennent les fichiers de /var/log)
# find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
(voir à quels groups appartiennent les fichiers de /var/log)
# find /var/log -perm +004
(fichiers lisibles par tout utilisateur)
# find /var/log \! -group root \! -group adm -exec ls -ld {} \;
(fichiers appartenant à des groupes autres que root ou adm)
Pour personnaliser la façon dont les fichiers de journalisation sont créés, vous devez probablement personnaliser le programme qui les génère. Cependant, si le fichier de journalisation est archivé, vous pouvez personnaliser le comportement de la création et de l'archivage.
Debian GNU/Linux fournit quelques correctifs pour le noyau Linux qui améliorent sa sécurité du système. En voici quelques-uns.
LIDS — Linux Intrusion
Detection fourni dans le paquet kernel-patch-2.4-lids.
Ce correctif du noyau rend le processus de renforcement d'un système Linux
plus facile en vous permettant de restreindre, cacher et protéger des
processus, même par rapport au superutilisateur. Elle implémente des
fonctionnalités de contrôle d'accès obligatoire (« Mandatory Access
Control »).
Linux Trustees
fourni dans le paquet trustees. Ce correctif ajoute un système
avancé décent de gestion des permissions au noyau Linux. Des objets
spéciaux (les « trustees ») sont associés à chaque fichier ou
répertoire et ils sont stockés dans la mémoire noyau, ce qui permet un
accès rapide pour toutes les permissions.
NSA Enhanced Linux (du paquet selinux). Des rétroportages des
paquets avec SElinux activé sont disponibles en http://selinux.alioth.debian.org/.
Plus de renseignements sont disponibles sur la page SElinux du wiki Debian,
et sur les sites web de Manoj
Srivastava et Russell Cookers.
Le correctif
exec-shield fourni dans le paquet
kernel-patch-exec-shield. Ce correctif fournit une protection
contre plusieurs dépassements de tampon (attaques par écrasement de pile).
Le correctif Grsecurity
fourni par les paquets kernel-patch-2.4-grsecurity et
kernel-patch-grsecurity2 [35] implémente le contrôle d'accès obligatoire
(Mandatory Access Control) grâce à RBAC, fournit une protection de
dépassement de tampon grâce à PaX, des ACL, un caractère aléatoire du
réseau (pour rendre la reconnaissance de système d'exploitation plus
difficile) et beaucoup
d'autres fonctionnalités.
Le kernel-patch-adamantix fournit les correctifs développés pour
Adamantix, une
distribution basée sur Debian. Le correctif noyau pour les versions 2.4.x du
noyau introduit des fonctionnalités de sécurité comme une pile non
exécutable grâce à l'utilisation de PaX et du contrôle d'accès
obligatoire basé sur RSBAC.
Parmi les autres fonctionnalités, on trouve : le correctif PID
aléatoire, le périphérique boucle chiffré AES, la gestion MPPE
et un rétroportage de la version 2.6 d'IPsec.
cryptoloop-source. Ce correctif vous permet d'utiliser les
fonctions de l'API de chiffrement du noyau pour créer des systèmes de
fichiers chiffrés en utilisant le périphérique « loopback ».
Prise en charge d'IPsec par le noyau (du paquet
linux-patch-openswan). Si vous voulez utiliser le protocole IPsec
avec Linux, vous avez besoin de ce correctif. Vous pouvez ainsi créer des VPN
très facilement, même vers les machines Windows, puisque IPsec est une norme
courante. Des fonctionnalités IPsec ont été ajoutées au noyau de
développement 2.5, cette fonctionnalité sera donc présente par défaut dans
le futur noyau Linux 2.6. Site Internet : http://www.openswan.org.
FIXME : les derniers noyaux 2.4 fournis dans Debian incluent
un rétroportage du code IPsec du noyau 2.5. Commentaire sur cela.
Les correctifs de sécurité du noyau suivants ne sont disponibles que pour d'anciennes versions du noyau dans Woody et ils sont obsolètes :
POSIX Access Control Lists
(ACL) pour Linux fourni dans le paquet kernel-patch-acl. Ce
correctif du noyau ajoute les listes de contrôle d'accès, une méthode
avancée pour restreindre l'accès aux fichiers, par le noyau Linux. Cela vous
permet de contrôler finement l'accès aux fichiers et répertoires.
Openwall par Solar
Designer, fourni dans le paquet kernel-patch-2.2.18-openwall.
C'est un ensemble utile de restrictions pour le noyau, comme la restriction de
liens, FIFO dans /tmp, une restriction de /proc, une
gestion de descripteur de fichiers spéciaux, une pile de l'utilisateur non
exécutable et bien plus. Note : ce paquet s'applique à la
version 2.2, aucun paquet n'est disponible pour les correctifs de la
version 2.4 fournie par Solar.
kernel-patch-int. Ce correctif vous permet également d'ajouter
des fonctionnalités de cryptographie au noyau Linux et était utile pour les
versions de Debian jusqu'à Potato. Il ne fonctionne pas avec Woody et si vous
utilisez Sarge ou une version plus récente, vous devriez utiliser un noyau
plus récent qui inclut déjà ces fonctionnalités.
Cependant, certains correctifs ne sont pas encore fournis dans Debian. Si vous
croyez que certains devraient être inclus, veuillez le demander sur la page
des paquets en souffrance et
paquets souhaités.
Dépassement de tampon est le nom d'une attaque courante sur un logiciel[36] qui utilise insuffisamment des vérifications de limites (une erreur de programmation courante, plus particulièrement en langage C) pour exécuter du code machine par des entrées de programme. Ces attaques, contre des logiciels serveur qui attendent des connexions distantes et contre des logiciels locaux qui autorisent des droits élevés aux utilisateurs (setuid ou setgid) peuvent avoir pour conséquence la compromission de tout un système.
Quatre méthodes en particulier permettent de se protéger contre les dépassement de tampon :
appliquer un correctif au noyau pour empêcher l'exécution de la pile. Vous pouvez utiliser Exec-shield, OpenWall ou PaX (incluant les correctifs Grsecurity et Adamantix) ;
corriger le code source en utilisant des outils pour trouver des fragments qui pourraient introduire cette faille ;
recompiler le code pour introduire des vérifications qui empêchent les
dépassements en utilisant le correctif pour GCC Stack Smashing
Protector (SSP) (qui est utilisé par Adamantix).
Debian GNU/Linux, dans sa version 3.0, fournit des logiciels pour
implémenter toutes ces méthodes à l'exception de la protection de la
compilation du code source (mais cela a été demandé dans le bogue nº 213994).
Notez que même si Debian fournissait un compilateur qui fournit cette fonction de protection de dépassement de tampon/pile, tous les paquets auraient besoin d'être recompilés pour introduire cette fonctionnalité. C'est, en fait, ce que fait Adamantix (entre autres fonctionnalités). L'effet de cette nouvelle fonctionnalité sur la stabilité des logiciels doit encore être déterminée (certains programmes ou architectures de processeur pourraient être cassés à cause d'elle).
Dans tous les cas, soyez conscient que même ces contournement peuvent ne pas
prévenir les dépassements de tampon car il existe des moyens de circonvenir
ceux-ci, comme décrit dans l'édition
58 du magazine phrack ou dans l'alerte du CORE Failles multiples dans
les technologies de protection d'écrasement de la pile.
Si vous voulez tester la protection contre les dépassements de tampon une fois
que vous l'avez mise en place (quelque que soit la méthode), vous pouvez
vouloir installer le paxtest et exécuter les tests qu'il fournit.
Des correctifs du noyau liés aux dépassements de tampon incluant le correctif
Openwall fournissent une protection contre les dépassements de tampon dans les
noyaux Linux 2.2. Pour les noyaux 2.4 et plus récents, vous devrez
utiliser l'implémentation Exec-shield ou l'implémentation PaX (fournies dans
le correctif grsecurity, kernel-patch-2.4-grsecurity et dans le
correctif Adamantix, kernel-patch-adamantix). Pour plus
d'informations sur l'utilisation de ces correctifs, veuillez consulter la
section Les utilitaires pour ajouter des correctifs
au noyau, Section 4.14.
L'utilisation d'outils pour détecter des dépassements de tampon nécessitent
dans tous les cas une expérience de programmation pour corriger (et
recompiler) le code. Debian fournit par exemple : bfbtester
(un testeur de dépassement de tampon qui brutalise des binaires par la force
par des dépassements de ligne de commande et d'environnement). D'autres
paquets intéressants pourraient aussi être rats,
pscan, flawfinder et splint.
Pendant l'administration normale du système, il est habituellement nécessaire
de transférer des fichiers à partir et vers le système installé. La copie
des fichiers de façon sécurisée d'un hôte vers un autre peut être
effectuée en utilisant le paquet serveur ssh. Une autre
possibilité est d'utiliser ftpd-ssl, un serveur FTP qui utilise
Secure Socket Layer pour chiffrer les transmissions.
Toutes ces méthodes nécessitent des clients spécifiques. Debian fournit des
clients logiciels, comme scp du paquet ssh, qui
fonctionne comme rcp, mais est complètement chiffré, donc les
méchants ne peuvent même pas savoir CE QUE vous copiez. Il existe
également un paquet client ftp-ssl pour le serveur équivalent.
Vous pouvez trouver des clients pour ces logiciels, même pour d'autres
systèmes d'exploitation (non UNIX), putty et winscp
fournissent des implémentations de copie sécurisée pour toutes les versions
des systèmes d'exploitation de Microsoft.
Notez qu'utiliser scp fournit un accès pour tous les utilisateurs
à tout le système de fichiers à moins de faire un chroot comme
décrit dans Chrooter SSH,
Section 5.1.1. L'accès FTP peut être chrooté, c'est
probablement plus facile selon le démon que vous choisissez, comme décrit
dans Sécurisation de FTP,
Section 5.3. Si vous vous inquiétez d'utilisateurs locaux pouvant
parcourir les fichiers locaux et que vous voulez avoir une communication
chiffrée, vous pouvez soit utiliser un démon FTP avec la prise en charge SSL,
soit combiner un FTP sans chiffrement avec une configuration VPN (consultez Réseaux Privés Virtuels, Section 8.5).
Avoir une bonne politique relative aux quotas est important, vu qu'elle empêche les utilisateurs de remplir les disques durs.
Vous pouvez utiliser deux systèmes de quotas différents : les quotas utilisateur et les quotas groupe. Comme vous l'avez probablement deviné, les quotas utilisateur limitent la quantité d'espace qu'un utilisateur peut avoir, les quotas groupe quant à eux font la même chose pour les groupes. Retenez cela quand vous calculerez les tailles des quotas.
Il y a quelques points importants auxquels il faut penser dans la mise en place d'un système de quotas :
garder les quotas suffisamment petits, ainsi les utilisateurs ne dévoreront pas l'espace disque ;
garder les quotas suffisamment grands, ainsi les utilisateurs ne se plaindront pas et leur quota de courrier leur permettra d'accepter des courriers pendant une longue période ;
utiliser des quotas sur tous les espaces accessibles en écriture par les
utilisateurs, aussi bien sur /home que /tmp.
Tous les répertoires et partitions auxquels les utilisateurs ont accès en écriture complet devraient avoir les quotas activés. Recherchez ces partitions et répertoires et calculez une taille adaptée qui combine disponibilité et sécurité.
Bon, maintenant vous désirez utiliser les quotas. Avant tout, vous avez
besoin de vérifier si vous avez activé la prise en charge des quotas dans le
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 le fichier /etc/fstab. Si
vous avez besoin des quotas par groupe, remplacez usrquota par
grpquota. Vous pouvez également utiliser les deux. Ensuite,
créez des fichiers vides quota.user et quota.group à la racine du système de
fichiers sur lequel vous voulez utiliser les quotas (touch
/home/quota.user /home/quota.group pour un système de fichiers
/home).
Redémarrez quota en faisant /etc/init.d/quota
stop;/etc/init.d/quota start. Maintenant les quotas devraient être en
fonction et leurs tailles peuvent être configurées.
L'édition de quotas pour un utilisateur spécifique peut être réalisée en faisant edquota -u <user>. Les quotas par groupes peuvent être modifiés avec edquota -g <group>. Ensuite, paramétrez les quotas soft et hard ou les quotas pour inœuds selon vos besoins.
Pour plus d'informations concernant les quotas, consultez la page de manuel de
la commande quota et le quota mini-howto
(/usr/share/doc/HOWTO/fr-html/Quota.html). Vous pouvez également
vouloir étudier pam_limits.so.
En plus des permissions standards UNIX, les systèmes de fichiers ext2 et ext3
offrent un ensemble d'attributs spécifiques qui donnent plus de contrôle sur
les fichiers du système. À la différence des permissions de base, ces
attributs ne sont pas affichés par la commande standard ls -l, ni
changés par la commande chmod et vous avez besoin de deux autres
utilitaires, lsattr et chattr (du paquet
e2fsprogs) pour les gérer. Notez que cela veut dire que ces
attributs ne sont habituellement pas enregistrés quand vous sauvegardez le
système, donc si vous modifiez l'un d'entre eux, il peut être utile
d'enregistrer les commandes chattr successives dans un script pour
pouvoir les repositionner plus tard si vous avez à récupérer une sauvegarde.
Parmi tous les attributs disponibles, les deux plus importants pour améliorer la sécurité sont référencés par les lettres « i » et « a » et ils ne peuvent être positionnés (ou enlevés) que par le superutilisateur :
l'attribut « i » (inchangeable, « immutable ») : un fichier ayant cet attribut ne peut-être ni modifié ni effacé ou encore renommé et aucun lien ne peut le référencer, même par le superutilisateur ;
l'attribut « a » (ajout, « append ») : cet
attribut a le même effet que l'attribut « immutable », excepté
que vous pouvez encore ouvrir le fichier en mode ajout. Cela veut dire que
vous pouvez encore ajouter plus de contenu au fichier, mais qu'il est
impossible de modifier un contenu précédent. Cet attribut est
particulièrement utile pour les fichiers de journalisation stockés dans
/var/log/, bien que vous devez considérer qu'ils sont parfois
déplacés à cause des scripts d'archivage.
Ces attributs peuvent également être positionnés pour les répertoires, dans ce cas, le droit de modifier le contenu de la liste d'un répertoire est refusé (par exemple, renommer ou supprimer un fichier, etc.) Quand il est appliqué à un répertoire, l'attribut d'ajout ne permet que la création de fichiers.
It is easy to see how the 'a' attribute improves security, by giving to
programs that are not running as the superuser the ability to add data to a
file without modifying its previous content. On the other hand, the 'i'
attribute seems less interesting: after all, the superuser can already use the
basic Unix permissions to restrict access to a file, and an intruder that would
get access to the superuser account could always use the chattr
program to remove the attribute. Such an intruder may first be confused when
noticing not being able to remove a file, but you should not assume blindness -
after all, the intruder got into your system! Some manuals (including a
previous version of this document) suggest to simply remove the
chattr and lsattr programs from the system to
increase security, but this kind of strategy, also known as "security by
obscurity", is to be absolutely avoided, since it provides a false sense
of security.
Une façon sûre de résoudre ce problème est d'utiliser les fonctionnalités du noyau Linux, comme décrit dans Défense proactive, Section 10.4.2.1. La fonctionnalité intéressante est appelée ici CAP_LINUX_IMMUTABLE : si vous la supprimez de l'ensemble des fonctionnalités (en utilisant par exemple la commande lcap CAP_LINUX_IMMUTABLE), il ne sera plus possible de modifier les attributs « a » ou « i » sur le système, même pour le superutilisateur ! Une stratégie complète serait alors la suivante :
positionner les attributs « a » et « i » sur tous les fichiers voulus ;
ajouter la commande lcap CAP_LINUX_IMMUTABLE (ainsi que lcap CAP_SYS_MODULE, comme suggéré dans Défense proactive, Section 10.4.2.1) à l'un des scripts de démarrage ;
positionner l'attribut « i » sur ce script et les autres fichiers
de démarrage, ainsi que sur le binaire lcap lui-même ;
exécuter la commande ci-dessus vous-même (ou réamorcer le système pour vous assurer que tout fonctionne comme prévu).
Now that the capability has been removed from the system, an intruder cannot change any attribute on the protected files, and thus cannot change or remove the files. If the machine is forced to reboot (which is the only way to restore the capabilities bounding set), it will easily be detected, and the capability will be removed again as soon as the system restarts anyway. The only way to change a protected file would be to boot the system in single-user mode or using another bootdisk, two operations that require physical access to the machine !
Êtes-vous sûr que le /bin/login présent sur le disque dur est le même que celui que vous aviez installé il y a de cela quelques mois ? Que faire si c'est une version piratée, qui enregistre les mots de passe entrés dans un fichier caché ou les envoie en clair sur 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 bon, à moins que quelqu'un ait piraté également l'algorithme qui crée les md5sums sur cette machine. C'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 c'est un moyen facile de reconnaître des changements sur vos binaires.
Les outils couramment utilisés pour cela sont sxid,
aide (Advanced Intrusion Detection Environment),
tripwire, integrit et samhain.
Installer debsums vous aidera également à vérifier
l'intégrité du système de fichiers en comparant le md5sum de chaque fichier
avec celui utilisé dans l'archive des paquets Debian. Mais faites
attention : ces fichiers peuvent facilement être modifiés par un
attaquant et tous les paquets ne fournissent pas de listes de md5sum pour les
binaires qu'ils fournissent. Pour plus d'informations, veuillez consulter Tests d'intégrité périodiques,
Section 10.2 et Prendre un instantané
(« snapshot ») du système, Section 4.19.
You might want to use locate to index the whole filesystem, if so,
consider the implications of that. The Debian findutils package
contains locate which runs as user nobody, and so it only indexes
files which are visible to everybody. However, if you change it's behaviour
you will make all file locations visible to all users. If you want to index
all the filesystem (not the bits that the user nobody can see) you can replace
locate with the package slocate. slocate is labeled
as a security enhanced version of GNU locate, but it actually provides
additional file-locating functionality. When using slocate, the
user only sees the actually accessible files and you can exclude any files or
directories on the system. The slocate package runs its update
process with higher privledges than locate, and indexes every file. Users are
then able to quickly search for every file which they are able to see.
slocate doesn't let them see new files; it filters the output
based on your UID.
Vous pourriez utiliser bsign ou elfsign.
elfsign fournit un utilitaire pour ajouter une signature
numérique à un binaire ELF et un autre pour vérifier cette signature.
L'actuelle implémentation utilise PKI pour signer la somme de contrôle du
binaire. L'avantage de faire cela est que ceux qui le veulent peuvent
déterminer si un binaire a été modifié et qui l'a créé.
bsign utilise GPG, elfsign utilise les certificats
PKI (X.509, OpenSSL).
Le paquet Debian checksecurity fournit une tâche
cron qui s'exécute tous les jours dans
/etc/cron.daily/checksecurity [37]. Cette tâche cron exécutera le script
/usr/sbin/checksecurity qui sauvegardera les renseignements sur
les modifications.
The default behavior does not send this information to the superuser but,
instead keeps daily copies of the changes in
/var/log/setuid.changes. You should set the MAILTO variable (in
/etc/checksecurity.conf) to 'root' to have this information mailed
to the superuser. See checksecurity(8) for more configuration
info.
FIXME : Besoin de plus de contenu (spécifique à Debian).
Beaucoup de fonctionnalités du noyau peuvent être modifiées en cours de
fonctionnement en envoyant quelque chose (par la commande echo)
dans le système de fichiers /proc ou en utilisant
sysctl. En entrant sysctl -A, vous pouvez voir ce
que vous pouvez configurer et quelles sont les options, elles peuvent être
modifiées en exécutant /sbin/sysctl -w variable=valeur
(consultez sysctl(8)). Vous aurez seulement en de rares occasions
à éditer quelque chose ici, mais vous pouvez augmenter la sécurité de cette
manière aussi. Par exemple :
net/ipv4/icmp_echo_ignore_broadcasts = 1
C'est un « émulateur Windows » parce que ça agit comme Windows sur les ping de broadcast si celui-ci est positionné à 1. C'est-à-dire que les requêtes d'echo ICMP envoyées à l'adresse broadcast seront ignorées. Sinon, cela ne fait rien.
Si vous voulez empêcher le système de répondre aux requêtes d'echo ICMP, activez cette option de configuration :
net/ipv4/icmp_echo_ignore_all = 1
Pour enregistrer les paquets avec des adresses impossibles (à cause de routes erronées) sur le réseau, utilisez :
/proc/sys/net/ipv4/conf/all/log_martians = 1
Pour plus d'informations sur ce qui peut être fait avec
/proc/sys/net/ipv4/*, consultez
/usr/src/linux/Documentation/filesystems/proc.txt. Toutes les
options sont décrites de façon complète sous
/usr/src/linux/Documentation/networking/ip-sysctl.txt [38].
Cette option est à double tranchant. D'un côté, elle protège le système contre le syn packet flooding ; d'un autre côté, elle viole les standards définis (RFCs).
net/ipv4/tcp_syncookies = 1
Si vous voulez changer cette option à chaque fois que le noyau fonctionne, vous devez le faire dans /etc/network/options en positionnant syncookies=yes. Cela prendra effet à chaque fois que /etc/init.d/networking est exécuté (ce qui est habituellement fait lors du démarrage) tandis que la commande suivante aura un effet unique jusqu'au prochain redémarrage :
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Cette option n'est dispobile que si vous avez compilé le noyau avec CONFIG_SYNCOOKIES. Tous les noyaux Debian sont compilés avec cette option incluse, mais vous pouvez le vérifier en exécutant :
$ sysctl -A |grep syncookies
net/ipv4/tcp_syncookies = 1
Pour plus d'informations sur les syncookies TCP, consultez http://cr.yp.to/syncookies.html.
Quand vous positionnez des options de configuration de réseau du noyau, vous devez le configurer pour que ce soit chargé à chaque fois que le système est redémarré. L'exemple suivant active un grand nombre des options précédentes ainsi que d'autres options utiles.
Il y a en fait deux façons de configurer le réseau au démarrage. Vous
pouvez configurer /etc/sysctl.conf (consultez
sysctl.conf(5)) ou introduire un script qui est appelé quand
l'interface est activée. La première option sera appliquée à toutes les
interfaces alors que la seconde option vous permettra de configurer cela
interface par interface.
Un exemple de fichier de configuration /etc/sysctl.conf qui
sécurisera quelques options de réseau au niveau du noyau est présenté
ci-dessous. Notez les commentaires dans ce fichier,
/etc/network/options peut forcer certaines options si elles sont
en contradiction avec celles de ce fichier lors de l'exécution de
/etc/init.d/networking (ce qui a lieu après procps
dans la séquence de démarrage).
#
# /etc/sysctl.conf - Fichier de configuration pour positionner les
# variables système
# Consultez sysctl.conf(5) pour plus de renseignements. Consultez
# également les fichiers sous Documentation/sysctl/,
# Documentation/filesystems/proc.txt et
# Documentation/networking/ip-sysctl.txt dans les sources du noyau
# (/usr/src/kernel-$version si vous avez installé un paquet de noyau)
# pour plus d'informations sur les valeurs qui peuvent être définies ici.
#
# Attention : /etc/init.d/procps est exécuté pour positionner les
# variables suivantes. Cependant, après cela, /etc/init.d/networking
# positionne certaines options réseau avec des valeurs intrinsèques. Ces
# valeurs peuvent être forcées en utilisant /etc/network/options.
#
#kernel.domainname = example.com
# Paramètres supplémentaires - adapté du script fourni
# par Dariusz Puchala (voir ci-dessous)
# Ignorer les broadcasts ICMP
net/ipv4/icmp_echo_ignore_broadcasts = 1
#
# Ignorer les erreurs ICMP erronées
net/ipv4/icmp_ignore_bogus_error_responses = 1
#
# Ne pas accepter les redirections ICMP (empêche les attaques en
# homme au milieu)
net/ipv4/conf/all/accept_redirects = 0
# _ou_
# N'accepter les redirections ICMP que pour les passerelles
# de notre liste de passerelles par défaut (activé par défaut)
# net/ipv4/conf/all/secure_redirects = 1
#
# Ne pas accepter les redirections ICMP (ce n'est pas un routeur)
net/ipv4/conf/all/send_redirects = 0
#
# Ne pas faire suivre les paquets IP (ce n'est pas un routeur)
# Remarque : assurez-vous que /etc/network/options contient
# « ip_forward=no »
anet/ipv4/conf/all/forwarding = 0
#
# Activer les TCP Syn Cookies
# Remarque : assurez-vous que /etc/network/options contient
# « syncookies=yes »
net/ipv4/tcp_syncookies = 1
#
# Enregistrer les paquets martiens
net/ipv4/conf/all/log_martians = 1
#
# Activer la vérification d'adresse source pour toutes les
# interfaces pour empêcher certaines attaques par usurpation
# Remarque : assurez-vous que /etc/network/options contient
# « spoofprotect=yes »
net/ipv4/conf/all/rp_filter = 1
#
# Ne pas accepter les paquets de routage source IP
# (ce n'est pas un routeur)
net/ipv4/conf/all/accept_source_route = 0
Pour utiliser le script, vous devez tout d'abord le créer, par exemple, dans
/etc/network/interface-secure (le nom est donné comme exemple) et
l'appeler à partir de /etc/network/interfaces comme ceci :
auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
pre-up /etc/network/interface-secure
Dans cet exemple, avant que l'interface eth0 ne soit activée, le script sera appelé pour sécuriser toutes les interfaces réseau comme montré ci-dessous.
#!/bin/sh -e
# Nom du script : /etc/network/interface-secure
#
# Modification de plusieurs comportements par défaut pour sécuriser contre
# certaines attaques et usurpations IP pour toutes les interfaces.
#
# Fourni par Dariusz Puchalak.
#
# Activation de la protection broadcast echo.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Désactivation de l'IP forwarding.
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
# Activation de la protection TCP syn cookies.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Enregistrement des paquets avec des adresses impossibles
# (cela comprend les paquets usurpés (spoofed), les paquets routés
# source, les paquets redirigés), mais faites attention à cela
# sur les serveurs web très chargés.
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
# Activation de la protection sur les mauvais messages d'erreur.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Protection d'usurpation IP.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
# Désactivation des redirections ICMP.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
# Désactivation des paquets source routés.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
exit 0
Remarquez que vous pouvez en fait avoir des scripts par interface qui activeront différentes options réseau pour différentes interfaces (si vous en avez plus d'une), il vous suffit de changer la ligne pre-up en :
pre-up /etc/network/interface-secure $IFACE
et utiliser un script qui n'applique les changements qu'à une interface spécifique et non à toutes les interfaces disponibles. Notez cependant que certaines options réseau ne peuvent être appliquées que globalement. Un exemple de script est celui-ci :
#!/bin/sh -e
# Nom du script : /etc/network/interface-secure
#
# Modifie plusieurs comportements par défaut pour sécuriser contre
# certaines attaques et usurpations TCP/IP pour une interface donnée.
#
# Fourni par Dariusz Puchalak.
#
IFACE=$1
if [ -z "$IFACE" ] ; then
echo "$0 : un nom d'interface doit être fourni en argument"
echo "Utilisation : $0 <interface>"
exit 1
fi
if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
echo "$0 : l'interface $IFACE n'existe pas "
echo "(impossible de trouver /proc/sys/net/ipv4/conf/)"
exit 1
fi
# Désactivation de l'IP forwarding.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding
# Enregistrement des paquets avec des adresses impossibles
# (cela inclut les paquets usurpés (spoofed), les paquets routés
# source, les paquets redirigés), mais faites attention à cela
# sur les serveurs web très chargés.
echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians
# Protection d'usurpation IP.
echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter
# Désactivation des redirections ICMP.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects
# Désactivation des paquets source routés.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route
exit 0
Vous pouvez également créer un script init.d et le faire
exécuter au démarrage (en utilisant update-rc.d pour créer les
liens rc.d appropriés).
De façon à avoir des privilèges de pare-feu, soit pour protéger le système
local ou d'autres derrière lui, le noyau doit être compilé avec les
options correspondant aux pare-feu. Le noyau standard de Debian 2.2
(Linux 2.2) fournit ipchains qui est un pare-feu pour filtrer
les paquets, le noyau standard de Debian 3.0 (Linux 2.4) fournit lui
le pare-feu iptables (netfilter).
Dans tous les cas, il est relativement facile d'utiliser un noyau différent de
celui fourni par Debian. Vous pouvez trouver des noyaux précompilés sous
forme de paquets que vous pouvez facilement installer sur le système Debian.
Vous pouvez également télécharger les sources du noyau en utilisant
kernel-source-X et construire des paquets de noyau
personnalisé en utilisant make-kpkg du paquet
kernel-package.
La mise en place de pare-feu dans Debian est abordée plus en détail dans Ajouter des capacités au pare-feu, Section 5.14.
Les systèmes avec plus d'une interface sur différents réseaux peuvent avoir des services configurés pour qu'ils ne puissent s'associer qu'à une adresse IP donnée. Cela prévient habituellement les accès aux services quand ils sont interrogés par une adresse donnée. Cependant, cela ne veut pas dire (bien qu'il s'agisse d'une erreur classique) que le service est lié à une adresse matérielle donnée (carte interface). [39]
Ce n'est pas un problème ARP et ce n'est pas une violation de RFC (c'est ce
que l'on appelle le weak end host dans la RFC1122,
section 3.3.4.2). Rappelez-vous que les adresses IP n'ont rien à voir
avec les interfaces physiques.
Sur les noyaux 2.2 (et antérieurs), cela peut être corrigé avec :
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
...
Sur les noyaux suivants, cela peut être corrigé avec :
des règles iptables ;
un routage correctement configuré[40] ;
des correctifs du noyau[41].
Along this text there will be many occasions in which it is shown how to configure some services (sshd server, apache, printer service...) in order to have them listening on any given address, the reader should take into account that, without the fixes given here, the fix would not prevent accesses from within the same (local) network. [42]
FIXME : Commentaires sur Bugtraq indiquant qu'il existe une méthode spécifique à Linux pour associer à une interface donnée.
FIXME : Créer un bogue sur netbase pour que le correctif de routage soit le comportement standard dans Debian ?
Quand vous ne faites pas confiance aux autres machines du réseau (ce qui devrait toujours être le cas parce que c'est l'attitude la plus sûre), vous devriez vous protéger contre les différentes attaques ARP existantes.
Comme vous le savez, le protocole ARP est utilisé pour lier des adresses IP à
des adresses MAC (consultez la RFC826 pour tous les
détails). À chaque fois que vous envoyez un paquet à une adresse IP, une
résolution ARP est effectuée (en regardant en premier dans le cache local
ARP, puis si l'adresse IP n'est pas présente dans le cache, en diffusant une
requête ARP) pour trouver l'adresse matérielle de la cible. Toutes les
attaques ARP ont pour but d'amener la machine à croire que l'adresse IP de la
machine B est associée à l'adresse MAC de la machine de l'intrus ; puis
tous les paquets que vous voudrez envoyer à l'adresse IP associée à la
machine B seront envoyée à la machine de l'intrus, etc.
Ces attaques (empoisonnement du cache, falsification ARP, etc.) permettent
à l'attaquant de renifler le trafic même sur des réseaux utilisant des
switchs, pour pirater facilement des connexions, pour déconnecter tout hôte
du réseau, etc. Les attaques ARP sont puissantes et simples à
implémenter et plusieurs outils existent comme arpspoof du paquet
dsniff ou arpoison.
Cependant, il existe toujours une solution :
utiliser un cache ARP statique. Vous pouvez mettre en place des entrées « statiques » dans le cache ARP avec :
arp -s nom_d_hôte adresse_matérielle
En plaçant des entrées statiques pour chaque hôte important du réseau, vous garantissez que personne ne pourra créer ou modifier une entrée (dissimulée) pour ces hôtes (les entrées statiques n'expirent pas et elles ne peuvent pas être modifiées) et les réponses ARP falsifiées seront ignorées ;
détecter le trafic ARP suspect. Vous pouvez utiliser arpwatch,
karpski ou des IDS plus généraux qui peuvent également
détecter le trafic ARP suspect (snort, prelude, etc.) ;
implémenter un filtrage de trafic IP validant l'adresse MAC.
Avant de mettre le système en production, vous pouvez prendre un instantané du système entier. Cet instantané pourrait être utilisé en cas de compromission (consultez Après la compromission (la réponse à l'incident), Chapitre 11). Vous devriez refaire cette mise à jour à chaque fois que le système est mis à jour, particulièrement si vous mettez à jour vers une nouvelle version de Debian.
Pour cela, vous pouvez utiliser un support inscriptible et amovible qui peut être positionné en lecture seule, ce peut être une disquette (en lecture seule après utilisation), un CD d'une unité de CD (vous pourriez utiliser un CD réinscriptible, ainsi vous pourriez même garder des sauvegardes des md5sums à différentes dates), ou un disque USB ou une carte MMC (si le système peut accéder à ceux-ci et qu'ils peuvent être protégés en écriture).
Le script suivant crée un tel instantané :
#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
trap "/bin/umount /dev/fd0" 0 1 2 3 9 13 15
if [ ! -f /usr/bin/md5sum ] ; then
echo "Impossible de trouver md5sum. Échec."
exit 1
fi
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Calcul de la base de données md5"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/md5sum\
>>/mnt/floppy/md5checksums-lib.txt
done
echo "Base de données md5 de post-installation calculée"
if [ ! -f /usr/bin/sha1sum ] ; then
echo "Impossible de trouver sha1sum"
echo "Attention : seule la base de données MD5 sera gardée"
else
/bin/cp /usr/bin/sha1sum /mnt/floppy
echo "Calcul de la base de données SHA-1"
>/mnt/floppy/sha1checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/sha1sum\
>>/mnt/floppy/sha1checksums-lib.txt
done
echo "Base de données SHA-1 de post-installation calculée"
fi
exit 0
Notez que le binaire md5sum (et le binaire sha1sum, s'il est disponible) est placé sur la disquette pour pouvoir être utilisé plus tard pour vérifier les binaires du système (juste au cas où il serait aussi corrompu). Cependant, si vous voulez vous assurer que vous exécutez bien un binaire légitime, vous pouvez vouloir, soit compiler une copie statique du binaire md5sum et utiliser celui-ci (pour empêcher une bibliothèque libc corrompue d'interférer avec le binaire), soit utiliser des instantanés de md5sums depuis un environnement propre exclusivement comme un CD de récupération ou un CD autonome (pour empêcher un noyau corrompu d'interférer). Je ne peux insister assez sur ce point : si vous êtes sur un système compromis, vous ne pouvez pas faire confiance à ce qui s'affiche, consultez Après la compromission (la réponse à l'incident), Chapitre 11.
L'instantané n'inclut pas les fichiers sous /var/lib/dpkg/info
qui incluent les sommes de hachage MD5 des paquets installés (dans les
fichiers se terminant par .md5sums). Vous pourriez également y
copier ces renseignements, veuillez cependant noter que :
les fichiers md5sums incluent les md5sums de tous les fichiers fournis par les paquets Debian, pas seulement les binaires système. Par conséquent, la base de données est plus importante (5 Mo contre 600 ko dans un système Debian GNU/Linux avec un système graphique et environ 2,5 Go de logiciels installés) et elle ne tiendra sur un petit support amovible (comme une simple disquette, mais tiendra sans doute sur une clef USB) ;
tous les paquets Debian ne fournissent pas les md5sums pour les fichiers
installé car ce n'est pas (actuellement) imposé par la Charte. Notez,
cependant, que vous pouvez générer les md5sums pour tous les paquets en
utilisant debsums après avoir fini l'installation du
système :
# debsums --generate=missing,keep
Une fois que l'instantané est fait, vous devriez vous assurer de placer le
support en lecture seule. Vous pouvez ensuite le stocker pour archivage ou le
placer dans le lecteur et utiliser une vérification cron toutes
les nuits en comparant les md5sums d'origine avec ceux de l'instantané.
Si vous ne voulez pas configurer de vérification manuelle, vous pouvez toujours utiliser n'importe quel système d'intégrité disponible qui fera cela et plus, pour de plus amples renseignements, veuillez consulter Tests d'intégrité périodiques, Section 10.2.
SVGAlib est très bien pour les amoureux de la console mais s'est montrée
très peu sûre par le passé. Des exploitations de failles de
zgv ont été diffusées et il était facile de devenir
superutilisateur. 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 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]
Securing Debian Manual
Version: 3.17, construite lemailto:jfs@debian.org