Une fois que le système est installé, vous pouvez encore faire plus pour sécuriser le système ; certaines des étapes décrites ci-dessous peuvent être effectuées. Bien sûr, cela dépend vraiment de votre configuration, mais pour prévenir un accès physique, vous devriez lire Changer le BIOS (à nouveau), Section 4.1,Attribuer un mot de passe à LILO ou GRUB, Section 4.2,Enlever le prompt root du noyau, Section 4.3, Interdire le démarrage sur disquette, Section 4.4, Restreindre les accès aux consoles, Section 4.5 et Restreindre les redémarrages système depuis la console, Section 4.6.
Avant de vous connecter à tout réseau, particulièrement s'il s'agit d'un réseau public, vous devez, au minimum, exécuter une mise à jour de sécurité (voir Se mettre à jour au niveau de la sécurité, Section 4.8). Vous pouvez optionnellement prendre un instantané de votre système (voir Prendre un instantané (snapshot) du système, Section 4.18).
Vous vous souvenez de Choisir un mot de passe pour le BIOS, Section 3.1 ? Et bien, vous devriez maintenant, une fois que vous n'avez plus besoin de démarrer à partir d'un support amovible, changer la configuration par défaut du BIOS pour qu'il ne puisse démarrer que depuis le disque dur. Assurez-vous de ne pas perdre le mot de passe BIOS, sinon, en cas de défaillance du disque dur, vous ne pourrez pas retourner dans le BIOS et modifier la configuration pour le récupérer en utilisant, par exemple, un cédérom.
Un autre moyen moins sécurisé, mais plus pratique est de changer la configuration pour que le système s'amorce depuis le disque dur et, si cela échoue, d'essayer un support amovible. À propos, c'est ainsi fait parce que la plupart des personnes n'utilisent pas le mot de passe BIOS très souvent ; il est facilement oublié.
N'importe qui peut obtenir facilement un shell root et changer vos mots de passe en entrant au prompt de boot <nom-de-votre-image-de-boot> init=/bin/sh. Après le changement du mot de passe et le redémarrage du système, la personne a un accès root illimité et peut faire tout ce qu'elle veut sur le système. Après ceci, vous n'aurez plus d'accès root sur votre machine, étant donné que vous ne connaîtrez pas le mot de passe.
Pour être sûr que cela ne puisse pas se produire, vous devriez attribuer un mot de passe au démarrage. Vous avez le choix entre un mot de passe global et un mot de passe pour une image donnée.
Pour LILO, vous avez besoin d'éditer le fichier /etc/lilo.conf
et
ajouter les lignes password ainsi que restricted
comme dans l'exemple suivant.
image=/boot/2.2.14-vmlinuz label=Linux read-only password=piratemoi restricted
Une fois terminé, relancez lilo. Omettre la ligne restricted
entraîne une attente de mot de passe, en dépit des paramètres passés à LILO.
Les permissions par défaut pour le fichier /etc/lilo.conf
accordent à root les droits de lecture et d'écriture et permettent un accès en
lecture seule pour le groupe de configuration de lilo.conf
, à
savoir root.
Si vous utilisez GRUB plutôt que LILO, éditez /boot/grub/menu.lst
et ajoutez les deux lignes suivantes en début (en remplaçant, bien sûr,
piratemoi par le mot de passe désiré). Ceci empêche les
utilisateurs d'éditer les options de démarrage. timeout 3 indique
un délai de 3 secondes avant que grub
démarre l'option par défaut.
timeout 3 password piratemoi
Pour aller plus loin dans le durcissement de l'intégrité du mot de passe, vous
pourriez entreposer le mot de passe sous une forme cryptée. L'utilitaire
grub-md5-crypt
génère un hachage de mot de passe qui est
compatible avec l'algorithme du mot de passe grub (md5). Pour spécifier à
grub
qu'un mot de passe sous le format md5 va être utilisé,
utilisez la directive suivante :
timeout 3 password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
Le paramètre --md5 a été ajouté pour informer grub
d'effectuer la
procédure d'authentification md5. Le mot de passe fourni est la version md5
cryptée de piratemoi. L'utilisation de la méthode md5 pour le mot de passe est
préférable à la méthode précédente dont le mot de passe est en clair. Plus
d'information concernant les mots de passe grub
se trouvent dans
le paquet grub-doc
.
Les noyaux Linux 2.4 fournissent un moyen d'accéder à un shell root lors de
l'amorçage et qui sera présenté juste après le chargement du système de
fichiers cramfs. Un message apparaîtra pour permettre à l'administrateur
d'entrer un shell exécutable avec des permissions root, ce shell peut être
utilisé pour charger manuellement des modules quand la détection automatique
échoue. Ce comportement est celui par défaut pour linuxrc
de
l'initrd
. Le message suivant apparaîtra :
Press ENTER to obtain a shell (waits 5 seconds)
Pour supprimer ce comportement, vous devez changer
/etc/mkinitrd/mkinitrd.conf
et positionner :
# DELAY Le nombre de secondes que le script linuxrc doit attendre pour # permettre à l'utilisateur de l'interrompre avant que le système soit lancé DELAY=0
Puis, régénérez votre image de ramdisk. Vous pouvez faire cela ainsi, par exemple :
# cd /boot # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
ou (de préférence) :
# dpkg-reconfigure -plow kernel-image-2.4.x-yz
Notez que Debian 3.0 woody permet aux utilisateurs d'installer des noyaux
2.4 (en sélectionnant des saveurs), cependant le noyau par
défaut est un 2.2 (excepté pour certaines architectures pour lesquelles le
noyau 2.2 n'a pas été porté). Si vous considérez cela comme un bogue, veuillez
consulter le bogue
145244
avant d'envoyer un rapport de bogue.
Le MBR par défaut dans Debian avant la version 2.2 ne fonctionnait pas comme le master boot record habituel et laissait un moyen facile de pénétrer un système :
Ce comportement peut être modifié en entrant :
lilo -b /dev/hda
Maintenant LILO est mis dans le MBR. Ceci peut être fait également en ajoutant
boot=/dev/hda au fichier lilo.conf
. Il y a encore
une autre solution qui désactivera complètement le prompt MBR :
install-mbr -i n /dev/hda
D'un autre côté, cette « porte dérobée », dont de nombreuses personnes ne sont pas au courant, peut aussi bien vous sauver la peau si vous rencontrez de gros problèmes, quelque soient les raisons, avec votre installation.
FIXME vérifier si cela touche réellement la 2.2 ou seulement la 2.1? INFO: Les disques de démarrage de la 2.2 n'installe pas le mbr, mais seulement LILO.
Certaines règles de sécurité peuvent forcer les administrateurs à se connecter
au système via une console avec leur identifiant/mot de passe puis devenir
super utilisateur (avec su
ou sudo
). Cette règle est
appliquée sous Debian en éditant les fichiers /etc/login.defs
ou
/etc/securetty
lors de l'utilisation de PAM. Dans :
login.defs
, éditez la variable CONSOLE qui définit un fichier ou
une liste de terminaux sur lesquels la connexion de root est autorisée ;
securetty
en ajoutant/supprimant les terminaux auxquels les accès
root seront autorisés.
En cas d'utilisation de PAM d'autres changements au processus de login, qui
peuvent inclure des restrictions aux utilisateurs et groupes à certains
moments, peuvent être configurés dans /etc/pam.d/login
. Une
fonctionnalité intéressante qui peut être désactivée est la possibilité de se
connecter avec des mots de passe nuls (vides). Cette fonctionnalité peut être
limitée en enlevant nullok de la ligne :
auth required pam_unix.so nullok
Si votre système dispose d'un clavier attaché, n'importe qui (oui, vraiment
n'importe qui) peut redémarrer le système avec celui-ci sans se
connecter au système. Cela peut en conformité ou non avec vos règles de
sécurité. Si vous désirez restreindre cela, vous devez vérifier le fichier
/etc/inittab
pour que la ligne incluant ctrlaltdel
appelle shutdown
avec le paramètre -a (rappelez-vous
d'exécuter init q après avoir fait un changement à ce fichierà.
La valeur par défaut dans Debian inclut ce paramètre :
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Puis, pour permettre à certains utilisateurs d'arrêter le système,
comme décrit dans la page de manuel shutdown(8)
, vous devez créer
le fichier /etc/shutdown.allow
et inclure le nom des utilisateurs
qui peuvent amorcer (?) le système. Quand le salut à trois doigts (ou
ctrl+alt+del) est exécuté, le programme va vérifier si l'un des
utilisateurs de ce fichier est connecté. Si aucun d'entre eux ne l'est,
shutdown
ne va pas redémarrer le système.
Lorsque vous montez une partition ext2, vous avez différentes options
additionnelles pour l'appel mount ou pour le fichier /etc/fstab
.
Par exemple, ceci est mon entrée pour la partition /tmp :
/dev/hda7 /tmp ext2 defaults,nosuid,noexec,nodev 0 2
Vous voyez la différence dans la section des options. L'option nosuid ignore complètement les bits setuid et setgid, tandis que noexec interdit l'exécution de tout programme sur ce point de montage et nodev ignore les périphériques. Ceci semble bon mais cela
L'option noexec évite aux binaires d'être exécutés directement mais cela est facilement contournable :
alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev) alex@joker:/tmp# ./date bash: ./date: Permission denied alex@joker:/tmp# /lib/ld-linux.so.2 ./date Sun Dec 3 17:49:23 CET 2000
Toutefois, de nombreux script kiddies utilisent des exploits qui essayent de
créer et d'exécuter des fichiers dans /tmp
. S'ils ne sont pas
futés, ils tomberont sur un pépin. En d'autres termes, un utilisateur ne peut
être abusé en exécutant un binaire compromis (genre cheval de troie) dans /tmp
lorsqu'il a accidentellement ajouté /tmp
dans son PATH.
Soyez aussi vigilant, certains scripts peuvent dépendre du fait que
/tmp
devienne exécutable. Notamment Debconf qui a (avait ?)
quelques problèmes concernant cela, pour plus d'information voir le bogue
116448
.
Ce qui suit est un exemple un plus poussé. Prenez note que, bien que
/var
peut être mis à noexec, certains logiciels[5] conservent leurs programmes dans
/var. Les mêmes conditions peuvent être appliquées à l'option nosuid.
/dev/sda6 /usr ext2 defaults,ro,nodev 0 2 /dev/sda12 /usr/share ext2 defaults,ro,nodev,nosuid 0 2 /dev/sda7 /var ext2 defaults,nodev,usrquota,grpquota 0 2 /dev/sda8 /tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda9 /var/tmp ext2 defaults,nodev,nosuid,noexec,usrquota,grpquota 0 2 /dev/sda10 /var/log ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda11 /var/account ext2 defaults,nodev,nosuid,noexec 0 2 /dev/sda13 /home ext2 rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota 0 2 /dev/fd0 /mnt/fd0 ext2 defaults,users,nodev,nosuid,noexec 0 0 /dev/fd0 /mnt/floppy vfat defaults,users,nodev.nosuid,noexec 0 0 /dev/hda /mnt/cdrom iso9660 ro,users,nodev.nosuid,noexec 0 0
/tmp
en noexec
Soyez vigilant si vous mettez /tmp
en noexec et que vous voulez
installer de nouveaux logiciels étant donné que certains peuvent l'utiliser
pendant l'installation. Apt
est un programme de ce genre (voir
http://bugs.debian.org/116448
)
si APT::ExtractTemplates::TempDir n'est pas configuré correctement
(voir apt-extracttemplates(1)
). Vous pouvez paramétrer cette
variable dans le fichier /etc/apt/apt.conf
vers un autre
répertoire que /tmp
et qui aura les privilèges exec.
Concernant noxec, prenez conscience qu'il peut ne pas offrir le niveau de sécurité désiré. Observons ceci :
$ cp /bin/date /tmp $ /tmp/date (n'est pas exécuté pas à cause de noexec) $/lib/ld-linux.so.2 /tmp/date (fonctionne correctement étant donné que date n'est pas exécuté directement)
Si vous mettez /usr
en lecture seule, vous serez dans l'incapacité
d'installer de nouveaux paquets sur votre système Debian GNU/Linux. Vous
devrez, avant tout la remonter en lecture-écriture, puis installer les nouveaux
paquets et enfin la remonter en lecture seule. La dernière version
d'apt
(dans Debian 3.0 « Woody ») peut être configurée
pour lancer des commandes avant et après l'installation de paquets, ainsi vous
pouvez avoir envie de le configurer correctement.
Pour réaliser ceci, modifiez le fichier /etc/apt/apt.conf
et
ajoutez :
DPkg { Pre-Invoke { "mount /usr -o remount,rw" }; Post-Invoke { "mount /usr -o remount,ro" }; };
Notez que le Post-invoke peut échouer avec un message d'erreur "/usr busy". Ceci survient principalement lorsque vous utilisez des fichiers lors de la mise à jour et que ces fichiers sont justement mis à jour. C'est agaçant mais pas réellement un problème. Vérifiez juste qu'ils ne sont plus utilisés puis lancez le Post-Invoke manuellement.
Dès que des nouveaux bogues de sécurité sont décelés dans les paquets, les
responsables Debian et les auteurs en amont les corrigent 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 qu'il a pu y avoir des mises à jour de sécurité depuis la publication après qu'il a été déterminé qu'un paquet donné est vulnérable. Ainsi, il a pu y avoir des versions mineures (il y en a eu sept dans la version Debian 2.2 Potato) incluant ces mises à jour de paquets.
Vous devez noter la date à laquelle votre support amovible (si vous en utilisez un) a été créé et vérifier le site de sécurité pour savoir s'il y a eu des mises à jour de sécurité. S'il y en a et que vous ne pouvez pas télécharger les paquets du site de sécurité sur un autre système (vous n'êtes pas encore connecté à l'Internet, n'est-ce pas ?) avant de vous connecter au réseau, vous devriez évaluer (si vous n'êtes pas protégé par un pare-feu par exemple) d'ajouter des règles de pare-feu pour que votre système ne puisse se connecter qu'à security.debian.org et ensuite réaliser la mise à jour. Une configuration exemple est donnée dans Security update protected by a firewall, Annexe F.
Remarque :Depuis Debian woody 3.0, après l'installation, il vous est donné la possibilité d'ajouter les mises à jour de sécurité au système. Si vous répondez « oui » (yes ?) à ceci, le système d'installation prendra les étapes nécessaires pour ajouter la source pour les mises à jour de sécurité aux sources de paquets et votre système, s'il a une connexion Internet, téléchargera et installera toutes les mises à jour de sécurité qui auront pu être produites après que votre support a été créé. Si vous mettez à jour depuis une version précédente de Debian ou si vous demandez au système de ne pas faire cela, vous devriez faires les étapes décrites ici.
Pour metter à jour manuellement le système, mettez la ligne suivante dans votre
sources.list
et vous serez mis à jour automatiquement quand vous
mettrez à jour votre système.
deb http://security.debian.org/debian-security stable/updates main contrib non-free
Une fois ceci fait, vous pouvez utiliser soit apt
, soit
dselect
pour les mises à jour :
apt
, exécutez simplement (en tant que
root) :
# apt-get update # apt-get upgrade
dselect
, choisissez tout d'abord [U]pdate,
puis [I]nstall et enfin [C]onfigure pour mettre à jour et installer les
paquets.
Si vous voulez, vous pouvez ajouter également les lignes deb-src à
/etc/apt/sources.list
. Voir apt(8)
pour plus de
détails.
Remarque : vous n'avez pas besoin d'ajouter les lignes suivantes :
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
car security.debian.org est hébergé à un emplacement hors des États-Unis et n'a donc pas d'archive non-US séparée.
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 Avis de Sécurité Debian [6] (DSAs). Voir L'équipe de sécurité Debian, Section
7.1 pour plus d'informations sur la façon dont fonctionne l'équipe de
sécurité Debian. Pour des informations sur l'inscription aux listes de
diffusion Debian, lisez http://lists.debian.org
.
Les DSAs sont signées par la signature de l'équipe de sécurité Debian qui peut
être récupérée depuis http://security.debian.org
.
Vous devriez également considérer un abonnement à la liste de discussions debian-security pour des discussions générales sur les problèmes de sécurité dans le système d'exploitation Debian.
FIXME: ajouter la clé ici également ?
PAM (Pluggable Authentication Modules) permet aux administrateurs systèmes de
choisir comment les applications authentifient les utilisateurs. Il est à
noter que PAM ne peut rien faire tant qu'une application n'a pas été compilée
avec le support pour PAM. La plupart des applications livrées dans la Debian
2.2 ont ce support d'inclus. Par ailleurs, Debian n'avait pas le support de
PAM avant la 2.2. La configuration actuelle par défaut pour tout service
activé avec PAM est d'émuler l'authentification UNIX (lisez
/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz
pour plus
d'informations sur la façon dont les services devraient fonctionner
dans Debian).
Chaque application avec le support PAM fournit un fichier de configuration dans
/etc/pam.d
qui peut être utilisé pour modifier son
comportement :
La description qui suit est loin d'être complète, pour plus d'informations vous
pouvez regarder le The
Linux-PAM System Administrator's Guide
(sur le site primaire de distribution
de PAM
), ce document est également fourni dans
libpam-doc
.
PAM vous offre la possibilité de passer en revue plusieurs étapes
d'authentification en une seule fois, à l'insu de l'utilisateur. Vous pouvez
vous authentifier à une base de données Berkeley et à un fichier
passwd
normal, ainsi l'utilisateur pourra se connecter seulement
si l'authentification est correcte des deux côtés. Vous pouvez restreindre
beaucoup de choses avec PAM comme vous pouvez laisser libre accès à votre
système. Donc soyez prudent. Une ligne de configuration typique a un champ de
contrôle comme deuxième élément. Généralement, il devrait être paramétrer sur
requisite qui retourne un échec de connexion si un module échoue.
La première chose que j'aime faire est d'ajouter le support MD5 aux
applications PAM, étant donné que ceci protège le système contre les tentatives
d'attaques par dictionnaire (les mots de passes peuvent être plus long en
utilisant MD5). Les deux lignes suivantes devraient être ajoutées à toutes les
lignes dans /etc/pam.d/
qui alloue l'accès à la machine, tel
login et ssh.
# Vérifier que libpam-cracklib soit installé avant sinon vous ne pourrez pas vous connecter. password required pam_cracklib.so retry=3 minlen=12 difok=3 password required pam_unix.so use_authtok nullok md5
Que fait cette formule magique ? La première ligne charge le module PAM
cracklib qui fournit la vérification de la longueur des mots de passe, attend
un nouveau mot de passe avec au minimum 12 caractères, une différence
d'au-moins 3 caractères par rapport à l'ancien et autorise 3 essais. La
seconde ligne introduit le module d'authentification standard avec MD5 et
autorise un mot de passe nul. La directive use_authok est
nécessaire pour passer le mot de passe du module précédent. Le paquet dépend
d'une liste de mots (comme wenglish
, wspanish
,
wbritish
, etc.), assurez-vous d'en avoir installé une adaptée à
votre langue (sinon, cela peut ne pas être utile du tout). [7]
Afin d'être sûr que l'utilisateur root peut se connecter uniquement à partir
des terminaux locaux, la ligne suivante doit être activée dans
/etc/pam.d/login
:
auth requisite pam_securetty.so
Ensuite, vous devriez ajouter les terminaux depuis lesquels l'utilisateur root
peut se connecter au système dans le fichier
/etc/security/access.conf
. La dernière mais pas la moindre, la
ligne suivante devra être activée si vous voulez paramétrer les limites des
utilisateurs.
session required pam_limits.so
Ceci restreint les ressources du système auxquelles les utilisateurs sont
autorisées (voir ci-dessous Restreindre l'utilisation
des ressources : le fichier limits.conf
, Section 4.10.2).
Par exemple, vous pouvez restreindre le nombre de connexions (d'un groupe
d'utilisateurs donné ou tout le système) que vous avez, le nombre de processus,
la taille de la mémoire, etc.
Maintenant, éditez /etc/pam.d/passwd
et changez la première ligne.
Vous devriez ajouter l'option « md5 » pour utiliser les mots de passe
MD5, modifiez la longueur minimale du mot de passe de 4 à 6 (ou plus) et fixez
une longueur maximale si vous le désirez. La ligne devrait ressembler à
quelque chose comme ceci :
password required pam_unix.so nullok obscure min=6 max=11 md5
Si vous voulez protéger su, pour que seuls quelques personnes puissent
l'utiliser pour devenir root sur votre système, vous avez besoin de créer un
nouveau groupe « wheel » (c'est la meilleure façon, étant donné
qu'aucun fichier n'a ces permissions d'attribuées). Ajoutez root et les autres
utilisateurs, qui auront la possibilité d'utiliser su
pour devenir
root, à ce groupe. Ensuite, ajoutez la ligne suivante dans
/etc/pam.d/su
:
auth requisite pam_wheel.so group=wheel debug
Ceci permet d'être sûr qu'uniquement les personnes du groupe
« wheel » pourront utiliser su
pour devenir root. Les
autres utilisateurs ne seront pas capable de le devenir. En fait, ils
recevront un message de refus s'ils essayent de devenir root.
Si vous désirez que seulement certains utilisateurs s'authentifient à un
service PAM, il suffit de faire cela en utilisant les fichiers où sont stockés
les utilisateurs autorisés (ou pas) à se connecter. Imaginons que vous ne
vouliez autoriser que l'utilisateur « ref » à se connecter via
ssh
. Vous le mettez dans /etc/sshusers-allowed
et
écrivez ce qui suit dans /etc/pam.d/ssh
:
auth required pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
La dernière étape, mais pas la moindre, est de créer le fichier
/etc/pam.d/other
et d'ajouter les lignes suivantes :
auth required pam_securetty.so auth required pam_unix_auth.so auth required pam_warn.so auth required pam_deny.so account required pam_unix_acct.so account required pam_warn.so account required pam_deny.so password required pam_unix_passwd.so password required pam_warn.so password required pam_deny.so session required pam_unix_session.so session required pam_warn.so session required pam_deny.so
Ces lignes vont fournir une bonne configuration par défaut pour toutes les applications qui supportent PAM (accès refusé par défaut).
limits.conf
Vous devriez sérieusement jeter un œil à ce fichier. Voux pouvez définir
dans celui-ci les limites des ressources par utilisateur. Si vous utilisez
PAM, le fichier /etc/limits.conf
est ignoré et vous devriez
utiliser /etc/security/limits.conf
à la place.
Si vous ne désirez pas restreindre l'utilisation des ressources, n'importe
quel utilisateur ayant un shell valide sur votre système (ou même un
intrus qui aurait compromis le système par un service) pourra utiliser autant
de CPU, de mémoire, de pile, etc. que le système pourra fournir. Ce problème
d'épuisement de ressources ne peut être réglé que par l'utilisation de
PAM. Veuillez noter qu'il existe un moyen d'ajouter des limites de ressources
pour certains shells (par exemple, bash
a ulimit
,
voir bash(1)
), mais comme ils ne fournissent pas tous les mêmes
limites et comme l'utilisateur peut changer de shell (voir
chsh(1)
), il est préférable de placer ces limites dans les modules
PAM.
Pour plus d'informations, lisez :
Seifried's
Securing Linux Step by Step
pour la section Limiting users
overview.
LASG
pour la section
Limiting and monitoring users.
FIXME : Placer un fichier exemple de limits.conf
ici
/etc/login.defs
La prochaine étape est d'éditer la configuration et action de base sur la connexion de l'utilisateur.
FAIL_DELAY 10
Cette variable devrait être fixée à une valeur suffisamment grande de façon à
rendre plus difficile les tentatives de connexion en utilisant la manière
forte. Si un mauvais mot de passe est fourni, le pirate potentiel (ou le
simple utilisateur !) doit attendre 10 secondes avant d'obtenir un nouveau
prompt de connexion, ce qui prend pas mal de temps quand vous testez des mots
de passe. Prenez garde car ce paramétrage est inutile si vous utilisez un
programme autre que getty
, tel que mingetty
par
exemple.
FAILLOG_ENAB yes
Si vous activez cette variable, les connexions échouées seront enregistrées dans un journal. Il est important d'en garder une trace pour quelqu'un qui tente une attaque par la manière forte.
LOG_UNKFAIL_ENAB yes
Si vous mettez la variable FAILLOG_ENAB à yes, alors il faudra mettre cette variable également à yes. Ceci sauvegardera les noms d'utilisateurs inconnus si la connexion échoue. Si vous faites cela, assurez-vous que les journaux de connexion ont les bonnes permissions (640 par exemple avec un groupe adéquat comme adm), car souvent les utilisateurs entrent accidentellement leur mot de passe au lieu du nom d'utilisateur et vous ne voulez pas permettre aux autres utilisateurs de le voir.
SYSLOG_SU_ENAB yes
Ceci va activer l'écriture dans les journaux de syslog
des
tentatives de su
. Plutôt important sur des machines sérieuses,
mais notez que ceci peut aussi bien être à la base de problèmes de respect de
la vie privée.
SYSLOG_SG_ENAB yes
La même chose que SYSLOG_SU_ENAB, mais s'applique au programme sg
.
MD5_CRYPT_ENAB yes
Comme mentionné ci-dessus, les mots de passe MD5 réduit considérablement le problème des attaques par dictionnaire étant donné que vous pouvez utiliser des mots de passe plus longs. Si vous utilisez slink, lisez les documentations avant d'activer le MD5. Sinon, cela est paramétré dans PAM.
PASS_MAX_LEN 50
Si les mots de passe MD5 sont activés dans votre configuration PAM, alors cette variable devrait avoir la même valeur que dans celle-ci.
/etc/ftpusers
Ce fichier contient une liste d'utilisateurs qui ne sont pas autorisés à se connecter à l'hôte en utilisant ftp. Utilisez uniquement ce fichier si vous voulez réellement autoriser le ftp (qui n'est, en général, pas recommandé car il utilise des mots de passe en clair). Si votre démon supporte PAM, celui-ci peut être utilisé pour permettre ou refuser certains services aux utilisateurs.
FIXME (BUG): Est-ce un bogue que le fichier par défaut ftpusers
dans Debian ne contient pas tous les utilisateurs d'administration
(dans base-passwd
).
Si vous avez réellement besoin que des utilisateurs deviennent super
utilisateur sur votre système, par exemple pour installer des paquets ou
ajouter des utilisateurs, vous pouvez utiliser la commande su
pour
changer d'identité. Vous devriez essayer d'éviter toute connexion en tant que
root et d'utiliser à la place su
. En réalité, la meilleure
solution est de supprimer su
et de changer pour sudo
,
étant donné qu'il dispose de plus de caractéristiques que su
.
Cependant, su
est plus commun étant donné qu'il est utilisé sur
beaucoup d'autres Unices.
sudo
autorise l'utilisateur à exécuter des commandes définies sous
l'identité d'un autre utilisateur, même en tant que root. Si l'utilisateur est
ajouté à /etc/sudoers
et est authentifié correctement, il est
capable de lancer des commandes qui ont été définies dans
/etc/sudoers
. Les infractions, telles que les mots de passe
incorrects ou les tentatives de lancement d'un programme pour lequel vous
n'avez pas les permissions, sont logguées et envoyées au root.
Vous devriez également modifier /etc/security/access.conf
pour que
la connexion d'administration à distance soit désactivée. Ainsi, les
utilisateurs doivent utiliser su
(ou sudo
) pour qu'il
y ait toujours une trace d'audit à chaque fois qu'un utilisateur veut utiliser
les pouvoirs administratifs.
Vous devez ajouter la ligne suivant à /etc/security/access.conf
,
le fichier de configuration par défaut Debian contient une ligne exemple
commentée :
-:wheel:ALL EXCEPT LOCAL
Parfois, vous pensez avoir besoin d'utilisateurs créés dans votre système local de façon à fournir un service donné (service courrier pop3 ou ftp). Avant tout, rappelez-vous que l'implémentation PAM dans Debian GNU/Linux vous autorise à valider les utilisateurs avec une grande variété de répertoires de services externes (radius, ldap, etc.) fournis par les paquets libpam.
Si des utilisateurs doivent être créés et que le système est accessible à
distance, prenez en compte que des utilisateurs pourront se connecter au
système. Ceci peut être corrigé en donnant aux utilisateurs un shell null
(/dev/null
) (il devra être listé dans /etc/shells
).
Si vous voulez autoriser les utilisateurs à accéder au système mais limiter
leurs mouvements, vous pouvez utiliser le fichier /bin/rbash
, ce
qui est équivalent à l'ajout de l'option -r dans bash
(RESTRICTED SHELL voir bash(1)
). Veuillez noter que même
avec un shell restreint, un utilisateur ayant accès à un programme interactif
(qui peut permettre l'exécution d'un sous-shell) peut être capable de passer
outre les limites du shell.
Debian fournit actuellement dans la version unstable le module
pam_chroot
(dans le paquet libpam-chroot
) (et il
pourrait être inclus dans les prochaines versions stables). Une alternative à
celui-ci est de chroot
er le service qui fournit la connexion à
distance (ssh
, telnet
). [8]
Si vous voulez restreindre quand les utilisateurs peuvent accéder au
système, vous devrez personnaliser /etc/security/access.conf
en
fonction de vos besoins.
Des informations sur comment chroot
er des utilisateurs accédant au
système par le service ssh
sont décrites dans Chroot
environment for
SSH
, Annexe H.
Si vous êtes paranoïaque, il se peut que vous vouliez configurer pour le
système un /etc/profile
qui configure l'environnement de telle
façon que les utilisateurs ne puissent pas retirer les capacités d'audit du
shell (les commandes sont déposées dans $HISTFILE. Le
/etc/profile
peut être paramétré ainsi :
HISTFILE=~/.bash_history HISTSIZE=100000000000000000 HISTFILESIZE=10000000000000000 readonly HISTFILE readonly HISTSIZE readonly HISTFILESIZE export HISTFILE HISTSIZE HISTFILESIZE
Afin que cela fonctionne, l'utilisateur doit être seulement capable d'ajouter
des informations à .bash_history
. Vous devez aussi
positionner l'attribut ajout-uniquement en utilisant le programme
chattr
sur .bash_history
pour tous les utilisateurs.
[9]
Notez que vous pouvez faire cela grâce au fichier utilisateur
.profile
. Mais alors vous devriez configurer les permissions
correctement : pour que le répertoire des utilisateurs ne leur
appartiennent PAS mais qu'ils aient le droit de lire le fichier de
configuration .profile
et d'écrire le .bash_history
.
Il serait bon de configurer l'attribut immuable (aussi en utilisant
chattr
) pour le .profile
aussi si vous procédez
ainsi.
Si vous êtes complètement paranoïaque et que vous voulez auditer toutes les
commandes des utilisateurs, vous pouvez prendre les codes sources du
bash
, les éditer et récupérer dans un fichier toutes les commandes
que l'utilisateur tape. Ou avoir ttysnoop
constamment en attente
de nouveaux ttys et reverser toutes les sorties dans un fichier. Un autre
programme utile est snoopy
qui est un programme transparent pour
l'utilisateur qui se positionne comme une librairie fournissant une
encapsulation des appels execve(), toute commande exécutée est
loguée par syslogd
en utilisant la facilité authpriv
(généralement stocké dans /var/log/auth.log
).
Notez que vous ne pouvez pas utiliser la commande script
pour ceci
étant donné qu'elle ne fonctionnera pas comme un shell (même si vous l'ajoutez
à /etc/shells
.
L'exemple précédent est une manière simple de configurer le contrôle
utilisateur mais qui peut ne pas être pratique pour des systèmes complexes. Si
cela est votre cas, vous devrez examiner acct
, l'utilitaire de
comptabilité. Ceci archivera toutes les commandes ou processus du système au
détriment de l'espace disque.
Lors de l'activation de la comptabilité, toutes les informations sur les
processus et les utilisateurs sont conservées dans /var/account/
,
plus spécifiquement dans le fichier pacct
. Le paquetage de
comptabilité inclut des outils (sa
et ac
) afin
d'analyser ces données.
Si vous désirez voir ce que font les utilisateurs habituellement,
comme l'heure à laquelle ils se connectent, vous pouvez utiliser la base de
données wtmp
qui contient toutes les informations concernant les
connexions. Ce fichier peut être employé avec plusieurs utilitaires, parmi eux
sac
qui peut sortir un profil de chaque utilisateur montrant dans
quel créneau horaire ils se connectent au système habituellement.
Dans le cas où vous avez la comptabilité activée, vous pouvez également utiliser les outils qu'elle fournit pour déterminer quand les utilisateurs accèdent au système et ce qu'ils exécutent.
Selon vos règles d'utilisation, vous pouvez vouloir changer comment les
utilisateurs peuvent partager des informations, c'est-à-dire, quelles sont les
permissions par défaut des fichiers nouvellements créés par les utilisateurs.
Ce changement est effectué en définissant un paramètre umask
correct pour tous les utilisateurs. Vous pouvez changer le paramètre
UMASK dans /etc/limits.conf
, /etc/profile
,
/etc/csh.cshrc
, /etc/csh.login
,
/etc/zshrc
et probablement dans d'autres fichiers (selon les
shells que vous avez installé sur votre système). Parmi ceux-ci, le dernier à
être chargé prendra précédence sur les autres. L'ordre est : le
limits.conf
de PAM, la configuration système par défaut du shell
de l'utilisateur, le shell de l'utilisateur (son ~/.profile
,
~/.bash_profile
, etc.).
Le paramètre umask par défaut de Debian est 022, ceci
veut dire que les fichiers (et les répertoires) peuvent être lus et accédés par
le groupe de l'utilisateur et par tout autre utilisateur du système. Si cela
est trop permissif pour votre système, vous devrez changer ce paramètre umask
pour tous les shells (et pour PAM). N'oubliez pas de modifier les fichiers
sous /etc/skel/
car ce seront les valeurs par défaut d'un nouvel
utilisateur quand il sera créé par la commande adduser
.
Notez, cependant, que les utilisateurs peuvent modifier leur propre paramètre umask s'ils le désirent, le rendant plus permissif ou plus restrictif.
FIXME : Besoin de contenu. Indiquer les conséquences de changement des
permissions des paquets lors d'une mise à jour (et un administrateur aussi
paranoïaque que cela devrait chroot
er ses utilisateurs).
Si vous avez besoin d'accorder aux utilisateurs un accès au système avec un shell, réfléchissez-y très soigneusement. Un utilisateur peut, par défaut à moins d'être dans un environnement extrèmement restreint (comme une prison chroot), récupérer un assez grand nombre d'informations concernant votre système, y compris :
/etc
. Cependant, les
permissions par défaut de Debian pour certains fichiers sensible (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 l'utilisateur
root par exemple find /etc -type f -a -perm 600 -a -uid 0 en tant
que super-utilisateur.
/usr/share/doc
, soit en devinant en regardant
les binaires et bibliothèques installés sur votre système.
/var/log
. Notez également que
quelqies fichiers journaux ne sont accessibles que par root et le groupe
adm (essayez find /var/log -type f -a -perm 640) et
certains ne sont même disponibles que pour l'utilisateur root (essayez
find /var/log -type f -a -perm 600 -a -uid 0).
Que peut voir un utilisateur dans votre système ? Probablement un assez grand nombre de choses, essayez ceci (prenez une profonde respiration) :
find / -type f -a -perm +006 2>/dev/null find / -type d -a -perm +007 2>/dev/null
La liste des fichiers qu'un utilisateur peut voir et des répertoires auxquels il a accès est affichée.
Si vous accordez toujours un accès shell aux utilisateurs, vous pouvez vouloir limiter les informations qu'ils peuvent voir des autres utilisateurs. Les utilisateurs ayant un accès shell ont tendance à créer un grand nombre de fichiers dans leur répertoire $HOME : boîtes à lettres, documents personnels, configuration des applications X/GNOME/KDE, etc.
Sous Debian, chaque utilisateur est créé avec un groupe associé et aucun utilisateur n'appartient au groupe d'un autre utilisateur. Il s'agit du comportement par défaut : quand un utilisateur userX est créé, un groupe nommé userX est créé et l'utilisateur lui est assigné. Ceci évite le concept d'un groupe users qui peut rendre plus difficile pour les utilisateurs de cacher des informations aux autres utiisateurs.
Cependant, les répertoires $HOME des utilisateurs sont créés avec les permissions 0755 (lisible par le groupe et par tout le monde). Les permissions de groupe ne sont pas un problème car seul l'utilisateur appartient au groupe, cependant les permissions pour les autres peut être (ou non) un problème selon vos règles locales.
Vous pouvez changer ce comportement pour la création de l'utilisateur fournisse
des permissions sur $HOME différentes. Pour changer ce comportement
pour les nouveaux utilisateurs quand il seront créés, changez
DIR_MODE dans le fichier de configuration
/etc/adduser.conf
à 0750 (pas d'accès en lecture pour tout le
monde).
Les utilisateurs peuvent toujours partager des informations, mais directement dans leur répertoire $HOME à moins qu'ils change les permissions de celui-ci.
Notez que ceci empêche les utilisateurs de pouvoir mettre en place des pages
personnelles (~userX
) si un serveur web est présent, car le
serveur web ne pourra pas lire le répertoire $HOME et donc, le
répertoire public_html
sous celui-ci. Si vous voulez permettre
aux utilisateurs de publier des pages HTML dans leur
~userX/public_html
, changez DIR_MODE en 0751. Ceci
permettra au serveur web d'accéder à ce répertoire (qui sera en mode 0755) et
de fournir le contenu publié par les utilisateurs.
Il y a plusieurs cas dans lesquels un utilisateur a besoin de créer un grand
nombre de comptes utilisateur et de fournir des mots de passe pour tous
ceux-ci. Bien sûr, l'administrateur peut facilement positionner le mot de
passer pour être le même que le nom du compte utilisateur, mais ceci n'est pas
très conseillé sur le plan de la sécurité. Une meilleure approche est
d'utiliser un programme de génération de mots de passe. Debian fournit les
paquets makepasswd
, apg
et pwgen
qui
contiennent des programmes (dont le nom est le même que celui du paquet) qui
peuvent être utilisés dans ce but. Makepasswd
génère des mots de
passe vraiment aléatoires avec un accent sur la sécurité plus que la
prononçabilité tandis que pwgen
essaie de créer des mots de passe
sans signification, mais prononçables (bien sûr, cela dépend de votre langue
maternelle). Apg
dispose d'algorithmes pour les deux (il y a une
version client/serveur pour ce programme, mais elle n'est pas incluse dans le
paquet Debian).
Passwd
ne permet pas une assignation non interactive des mots de
passe (car il utilise un accès direct au terminal tty). Si vous désirez
changer des mots de passe lors de la création d'un grand nombre d'utilisateurs,
vous pouvez les créer en utilisant adduser
avec l'option
--disabled-login, puis utiliser chpasswd
[10] (dans le paquet
passwd
, vous l'avez donc déjà d'installé). Si vous voulez
utilisez un fichier avec toutes les informations pour créer les utilisateurs
comme un processus batch, il sera probablement préférable d'utiliser
newusers
.
Les mots de passe des utilisateurs peuvent parfois devenir le maillon
faible de la sécurité d'un système donné. Cela provient du fait que
quelques utilisateurs choisissent des mots de passe faibles pour leur compte
(et plus il y a d'utilisateurs, plus sont grandes les chances que cela se
produise). Même si vous mettez en place des vérifications avec le module PAM
cracklib et les limitations sur les mots de passe comme décrites dans Authentification utilisateur : PAM, Section 4.10.1,
les utilisateurs pourront toujours utiliser des mots de passe faibles. Comme
l'accès utilisateur peut inclure un accès à un shell à distance (on espère, par
ssh
), il est important qu'un attaquant à distance ne puisse pas
deviner les mots de passe utilisateur (après avoir pu énumérer les utilisateurs
par d'autres moyens).
Un administrateur ssytème doit, pour un nombre d'utilisateurs donnés, vérifier
si les mots de passe sont cohérents avec la règle locale de sécurité. Comment
vérifier ? Essayez de les cracker comme le ferait un attaquant s'il avait
accès aux mots de passe hachés (le fichier /etc/shadow
).
Un administrateur peut utiliser john
ou crack
(tous
deux utilisent la force brute pour cracker) ensemble avec une liste de mots
appropriés [11] pour vérifier
les mots de passe utilisateurs et prendre des mesures appropriées si un mot de
passe faible est détecté.
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 a été interrompue et non rétablie. Quelqu'en soit la raison, les utilisateurs inactives peuvent amener à une compromission :
telnet
).
Certains systèmes à distance ont même été compromis à travers un
screen
inactif (détaché) .
La déconnexion automatique des utilisateurs inactifs est habituellement une partie qui doit être imposée par les règles de sécurité locales. Il y a plusieurs moyens de faire cela :
bash
est le shell de l'utilisateur, un administrateur système
peut positionner une valeur TMOUT par défaut (voir
bash(1)
) qui entraînera la déconnexion automatique des
utilisateurs distants inactifs. Notez que ceci doit être position avec
l'option -o ou les utilisateurs pourront la changer (ou la
désactiver).
timeoutd
et configurer /etc/timeouts
selon
vos règles de sécurité locales. Le démon regardera les utilisateurs inactifs
et mettra un terme à leur shell en fonction.
autolog
et configurer-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 leur shell par
défaut ou il peuvent après avoir exécuter leus shell par défaut, basculer sur
un autre shell (non contrôlé).
Les TCP wrappers ont été développés quand il n'y avait pas de réels filtres de
paquets de disponible et que les contrôles d'accès étaient nécessaires. Les
TCP wrappers vous permettent d'autoriser ou de refuser un service à un hôte ou
à un domaine et de définir une règle par défaut pour les autorisations et les
refus. Pour plus de détails, jetez un œil à
hosts_access(5)
.
De nombreux services installés dans Debian sont soit :
tcpd
)
D'un côté, pour des services configurés dans /etc/inetd.conf
, ceci
incluant telnet
, ftp
, netbios
,
swat
et finger
), vous observerez que le fichier de
configuration exécute avant tout /usr/sbin/tcpd
. D'un autre côté,
même si un service n'est pas lancé par le super démon inetd
, il
peut être compilé avec le support pour les règles des tcp wrappers. Les
services compilés avec support tcp wrappers dans Debian incluent
ssh
, portmap
, in.talk
,
rpc.statd
, rpc.mountd
, gdm
,
oaf
(le démon d'activation GNOME), nessus
et beaucoup
d'autres.
Pour voir quels paquets utilisent tcpwrappers, essayez ceci :
$ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \ sed 's/,libwrap0$//;s/^[[:space:]]\+//'
Tenez compte de ceci quand vous utilisez tcpchk
. Vous pouvez
ajouter des services, qui sont liés à la bibliothèque du wrapper, dans les
fichiers host.deny
et hosts.allow
mais
tcpchk
vous informera qu'il n'est pas capable de trouver ces
services étant donné qu'il les cherche dans /etc/inetd.conf
(la
page de manuel n'est pas totalement précise ici).
À présent, voici une petite astuce et probablement le plus petit système de détection d'intrusions disponible. Généralement, vous devriez disposer d'une politique correcte concernant le pare-feu en première ligne, puis disposer de tcp wrappers en seconde ligne de défense. Un petit truc est de mettre en place une commande SPAWN [12] dans /etc/hosts.deny qui enverra un courrier à root quand un déclencheur wrapper pour service dénié est rencontré :
ALL: ALL: SPAWN ( \ echo -e "\n\ TCP Wrappers\: Connection refused\n\ By\: $(uname -n)\n\ Process\: %d (pid %p)\n\ User\: %u\n\ Host\: %c\n\ Date\: $(date)\n\ " | /usr/bin/mail -s "Connection to %d blocked" root) &
Attention : L'exemple ci-dessus peut-être facilement sujet à une attaque par déni de service en soumettant énormément de connexions dans une période très courte. De nombreux courriers signifient de nombreuses E/S en envoyant uniquement quelques paquets.
Il est facile de voir que le traitement de logs et alertes est un problème sérieux sur un système sécurisé. Supposons qu'un système est parfaitement configuré et sécurisé à 99%. Si l'attaque représentant le 1% vient à arriver et qu'il n'y a pas de mesures de sécurité mises en place pour, dans un premier temps, détecter ceci et dans un deuxième temps, lancer l'alerte, le système n'est pas sécurisé du tout.
Debian GNU/Linux fournit quelques outils pour effectuer des analyses de logs,
notamment swatch
[13], logcheck
ou log-analysis
(tous
ont besoin d'être personnalisés pour enlever les choses non nécessaires des
comptes-rendus). Il peut être également utile, si le système est proche,
d'avoir les logs du système d'affichés sur une console virtuelle. Ceci est
utile car vous pouvez (depuis une distance) voir si le système se comporte
correctement. Le fichier /etc/syslog.conf
de Debian est fourni
avec une configuration commentée par défaut ; pour l'activer, décommenter
les lignes et redémarrez syslogd
(/etc/init.d/syslogd
restart) :
daemon,mail.*;\ news.=crit;news.=err;news.=notice;\ *.=debug;*.=info;\ *.=notice;*.=warn /dev/tty8
Il y a une grande partie sur l'analyse des log qui ne peut pas être couverte
ici, une bonne ressource d'information est Couterpane's Log Analysis
Resources
. Dans tous les cas, même des outils automatiques ne
peuvent rivaliser avec le meilleur outil d'analyse : votre cerveau.
logcheck
Le paquet logcheck
dans Debian est divisé entre deux paquets
logcheck
(le programme principal) et
logcheck-database
(une base de données d'expressions rationnelles
pour le programme). Le comportement par défaut sous Debian (dans
/etc/cron.d/logcheck
) est que logcheck
est exécuté
chaque jour à 2 h 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 inhabituels dans le système.
logcheck
peut être complètement personnalisé pour envoyer des
courriers à partir d'événements récupérés des logs et qui sont dignes
d'attention. L'installation par défaut inclut des profils pour des événements
ignorés et des violations de règles pour trois configurations différentes
(station de travail, serveur et paranoïaque). Le paquet Debian inclut un
fichier de configuration /etc/logcheck/logcheck.conf
, sourcé par
le programme, qui définit à quel utilisateur sont envoyés les vérifications.
Il fournit également un moyen pour les paquets qui fournissent des services
pour implémenter de nouvelles règles dans les répertoires :
/etc/logcheck/hacking.d/_packagename_
,
/etc/logcheck/violations.d/_packagename_
,
/etc/logcheck/violations.ignore.d/_packagename_
,
/etc/logcheck/ignore.d.paranoid/_packagename_
,
/etc/logcheck/ignore.d.server/_packagename_
et
/etc/logcheck/ignore.d.workstation/_packagename_
. Cependant, peu
de paquets le font actuellement. Si vous avez une règle qui peut être utile à
d'autres utilisateurs, veuillez l'envoyer comme un rapport de bogue sur le
paquet approprié (comme un bogue de gravité wishlist). Pour plus
d'informations, veuillez lire
/usr/share/doc/logcheck/README.Debian
Le meilleur moyen de configurer logcheck
est de l'installer (il
demandera à quel utilisateur les comptes-rendus doivent être envoyés et
générera le fichier /etc/logcheck/logcheck.logfiles
à partir des
entrées syslog). Si vous désirez ajouter de nouveaux fichiers de log, ajoutez
les simplement à /etc/logcheck/logcheck.logfiles
. La dépendance
du paquet va également forcer l'installation de
logcheck-database
; pendant l'installation, il demandera quel
niveau de sécurité est désiré : station de travail, serveur ou
paranoïaque. Cela va faire pointer /etc/logcheck/ignore.d
vers
les répertoires appropriés (par des liens symboliques). Pour changer ceci,
exécutez dpkg-reconfigure -plow logcheck-database. Puis, créez le
/etc/ignore.d/local
, ce fichier contiendra toutes les rêgles pour
exclure les messages qui ne doivent pas être reportées. Laissez le vide pour
le moment (un simple cp /dev/null /etc/ignore.d/local fera
l'affaire).
Une fois ceci fait, vous pouvez vouloir vérifier les courriers envoyés, pour
les quelques premiers jours/semaines/mois. Si vous trouvez que vous recevez
des messages que vous ne voulez pas recevoir, ajoutez simplement l'expression
rationnalle (voir regex(7)
) qui correspond à ces messages au
fichier /etc/ignore.d/local
. C'est un processus d'affinement
perpétuel ; une fois que les messages qui sont envoyés sont toujours
pertinents, vous pouvez considérer que l'affinement est terminé. Notez que si
logcheck
ne trouve rien de pertinent dans votre système, il ne
vous enverra pas de courrier même s'il fonctionne (donc, vous pouvez ne
recevoir de courrier qu'une fois par semaine si vous êtes chanceux).
Debian livre une configuration standard de syslog (dans
/etc/syslog.conf
) qui archive les messages dans les fichiers
appropriés dépendant de la facilité du système. Vous devriez être familier
avec ceci ; jetez un œil au fichier syslog.conf
et à la
documentation si vous ne l'êtes pas. Si vous avez l'intention de maintenir un
système sécurisé, vous devriez être conscient de l'endroit où les logs sont
envoyées ainsi ils ne sont pas perdus dans la nature.
Par exemple, envoyer des messages à la console est également utile pour de nombreux systèmes de production. Mais pour de nombreux systèmes semblables il est également important d'ajouter une nouvelle machine qui servira de serveur de log (il reçoit les logs de tous les autres systèmes).
Le courrier de root devrait être pris en considération également, de nombreux
contrôles de sécurité (tel snort
) envoient des alertes dans la
boîte aux lettres de root. Celle-ci pointe généralement sur le premier
utilisateur créé sur le système (vérifiez /etc/aliases
). Prenez
garde à envoyer le courrier du root à un endroit où il sera lu (soit localement
soit à distance).
Il y a d'autres comptes et alias « rôles » sur votre système. Sur un petit système, c'est probablement le plus simple de s'assurer que tous ces alias pointent vers le compte root, et que ce mail pour root est retransmis vers la boîte aux lettres personnelle de l'administrateur système.
FIXME: Il serait intéressant de dire comment un système Debian peut
envoyer/recevoir des messages SNMP relatifs à des problèmes de sécurité (jfs).
Voir : snmptraglogd
, snmp
et snmpd
.
Un loghost est un hôte qui recueille les données des syslog à travers le
réseau. Si l'une de vos machines est piratée, l'intrus n'est pas capable de
dissimuler ses traces, à moins qu'il ne pirate également le loghost. Par
conséquent, le loghost devrait être particulièrement sécurisé. Faire d'une
machine un loghost est simple. Il suffit juste de démarrer le
syslogd
avec syslogd -r et un nouveau loghost est né.
De façon à rendre cela permanent dans Debian, éditez
/etc/init.d/sysklogd
et changez la ligne
SYSLOGD=""
par
SYSLOGD="-r"
Ensuite, configurez les autres machines afin qu'elles envoient les données au
loghost. Ajoutez une entrée comme celle qui suit dans
/etc/syslog.conf
:
facilité.niveau @votre_loghost
Voyez la documentation pour savoir ce qu'on peut utiliser à la place de facilité et niveau (ils ne devraient pas être mot pour mot comme ceci). Si vous voulez tout archiver à distance, il suffit d'écrire :
*.* @votre_loghost
dans votre syslog.conf
. Archiver à distance ainsi que localement
est la meilleure solution (le pirate peut estimer avoir couvert ses traces
après la suppression des fichiers de logs locaux). Voir les pages de manuel
syslog(3)
, syslogd(8)
et syslog.conf(5)
pour toutes informations complémentaires.
Il est important de décider non seulement comment les alertes sont utilisées, mais aussi qui y accède, i.e. qui peut lire ou modifier les fichiers de log (si on n'utilise pas un hôte d'archivage). Les alertes de sécurité que l'attaquant peut changer ou désactiver sont de peu de valeur en cas d'intrusion. Vous devez également tenir compte que les fichiers de log peuvent révéler un grand nombre d'informations à propos de votre système à un intrus s'il y a accès.
Certaines permissions de fichiers de log ne sont pas parfaites après
l'installation (mais, bien sûr, cela dépend vraiment de vos règles de sécurité
locales). Premièrement /var/log/lastlog
et
/var/log/faillog
n'ont pas besoin d'être lisibles par les
utilisateurs normaux. Dans le lastlog
, vous pouvez voir qui s'est
connecté récemment, et dans le faillog
, vous voyez un résumé des
connexions qui ont échouées. L'auteur recommande de un chmod 660
sur les deux fichiers. Faites un tour rapide de vos fichiers de log et décidez
avec beaucoup d'attention quels fichiers de log vous rendez lisible/modifiable
par un utilisateur avec un UID différent de 0 et un groupe autre que
« adm » ou « root ». Vous pouvez facilement vérifier ceci
sur votre système avec :
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u (voir à quels utilisateurs appartiennent les fichiers de /var/log) # find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u (voir à quels groups appartiennent les fichiers de /var/log) # find /var/log -perm +004 (fichiers lisibles par tout utilisateur) # find /var/log \! -group root \! -group adm -exec ls -ld {} \; (fichiers appartenant à des groupes autres que root ou adm)
Pour personnaliser comment les fichiers de log sont créés, vous devez probablement personnaliser le programme qui les génère. Cependant, si le fichier de log est archivé, vous pouvez personnaliser le comportement de la création et de l'archivage.
FIXME: Cette section a besoin de couvrir la manière d'installer ces rustines spécifiques sur Debian en utilisant les paquets kernel-2.x.x-patch-XXX.
Debian GNU/Linux fournit quelques rustines pour le noyau Linux qui améliorent sa sécurité du système. En voici quelques-unes :
lids-2.2.19
), par Huagang Xie et Philippe Biondi. Cette rustine
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 root. Il vous permet égaelemnt de protéger ou cacher certains
fichiers pour que même root ne puisse les modifier. C'est un outil
incontournable pour l'administrateur paranoïaque de système. Site
Internet : http://www.lids.org
kernel-patch-acl
). Cette rustine 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. Cette rustine a été ajoutée au noyau de développement 2.5 et sera
inclue par défaut dans le futur noyau 2.6. Site Internet : http://acl.bestbits.at/
trustees
). Cette rustine ajoute un
système avancé décent de gestion des permissions à votre 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. Site Internet : http://trustees.sourceforge.net/
selinux
, également disponible depuis
le site web du
développeur
)
kernel-patch-2.2.18-openwall
par Solar Designer. C'est un
ensemble utile de restrictions pour le noyau, comme la restriction de liens,
FIFOs dans /tmp, une restriction de /proc, maniement de la description de
fichiers spéciaux, pile de l'utilisateur non exécutable et bien plus. Site
Internet : http://www.openwall.com/linux/
kernel-patch-2.2.19-harden
kernel-patch-freeswan
). Si vous
voulez utiliser le protocole IPSec avec Linux, vous avez besoin de cette
rustine. Vous pouvez ainsi créer des VPNs très facilement, même vers les
machines Windows, puisque IPSec est un standard courant. 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.freeswan.org
cryptoapi-core-source
. Cette rustine noyau ajoute des
fonctionnalités de cryptage au noyau Linux, comme des fonctions cipher et
digest. L'utilisation habituelle de ces fonctions est pour le cryptage des
systèmes de fichiers et du swap. Notez qu'à partir de la version 2.5.45, des
fonctionnalités semblables ont été ajoutés au noyau officiel Linux, il est donc
probable que vous n'aurez plus besoin de cette rustine dans le futur noyau 2.6.
Remarque : ce paquet n'existe pas dans les versions de Debian
antérieures à Sarge
. Site
Internet : http://www.kerneli.org
cryptoloop-source
. Cette rustine vous permet d'utiliser les
fonctions du paquet crytoapi-core-source
pour créer des systèmes
de fichiers encryptés en utilisant le périphérique loopback.
kernel-patch-int
. Cette rustine vous permet également d'ajouter
des fonctionnalités de cryptographie au noyau Linux et elle était utile pour
les versions de Debian jusqu'à Potato. Elle ne fonctionne pas avec Woody et si
vous utilisez Sarge ou une version plus récente, vous devriez utiliser le plus
récent cryptoapi-core-source
.
Cependant, certaines rustines ne sont pas encore fournies dans Debian. Si vous
croyez que certaines devraient être incluses, veuillez le demander sur la page
des paquets en souffrance et paquets
prospectifs
. Certains d'entre eux sont :
chroot
, il prétend être plus facile à construire et
plus créer qu'un environnement chroot
. Site Internet :
http://www.immunix.org/subdomain.html
http://ramses.smeyers.be/useripacct
.
Dépassement de tampon est le nom d'une attaque courante sur un logiciel qui utilise insuffisamment des vérifications de limites (une erreur de programmation courante) pour exécuter du code machine par des entrées d'un programme. Ces attaques, contre des logiciels serveurs qui attendent des connexions distantes et contre des logiciels locaux qui autorisent des privilèges élevés aux utilisateurs (setuid ou setgid) peuvent résulter en la compromission de tout système donné.
Il y a dans l'ensemble quatre méthodes pour se protéger contre les dépassement de tampon :
ceci
) ;
Debian GNU/Linux, dans sa version 3.0, ne fournit des logiciels que pour
implémenter la première et la dernière de ces méthodes (des rustines noyau et
des outils pour détecter de possibles dépassements de tampon). L'utilisation
de ces outils pour détecter des dépassements de tampn nécessite, en tout 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 effectue un test brut sur les binaires par des dépassements de
tampon sur la ligne de commande et l'environnement) et njamd
.
En ce qui concerne les rustines noyau (décrites dans la section Les utilitaires pour mettre des rustines au noyau,
Section 4.13), la rustine Openwall fournit une protection contre les
dépassements de tampon dans les noyaux Linux 2.2. Cependant, pour les noyaux
2.4, vous devez utiliser la rustine Grsecurity (dans le paquet
kernel-patch-2.4-grsecurity
) qui inclut la rustine Openwall et
beaucoup plus de fonctionnalités
(y
compris les ACLs et un caractère aléatoire pour le réseau pour le rendre plus
résistant à la détection d'empreinte à distance du système d'exploitation) ou
le «nbsp;Linux Security Modules » (dans les paquets
kernel-patch-2.4-lsm
et kernel-patch-2.5-lsm
).
Dans tous les cas, soyez conscient que même ces contournement peuvent ne pas
prévenir les dépassements de tampon cas il existe des moyens de circonvenir
ceux-ci, comme décrit dans l'édition
58
du magazine phrack.
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 sshd
. Une autre possibilité est
d'utiliser ftpd-ssl
, un serveur FTP qui utilise Secure Socket
Layer pour encrypter les transmissions.
Toutes ces méthodes nécessitent, bien sûr, des clients spécifiques. Debian
fournit ces clients, par exemple le paquet ssh
fournit
scp
. Il fonctionner comme rcp
, mais est complètement
encrypté, donc les méchants ne peuvent même pas savoir CE QUE vous
copiez. Il existe également un paquet client ftp-ssl
pour le
serveur équivalent. Vous pouvez trouver des clients pour ces logiciels, même
pour d'autres systèmes d'exploitation (non-UNIX), putty
et
winscp
fournissent des implémentations de copie sécurisée pour
toutes les versions des systèmes d'exploitation de Microsoft.
Notez qu'utiliser scp
fournit un accès pour tous les utilisateurs
à tout le système de fichiers à moins de faire un chroot
comme
décrit dans Chrooter ssh,
Section 5.1.1. L'accès FTP peut être chroot
é, ceci est
probablement plus facile selon le démon que vous choisissez, comme décrit dans
Sécurisation FTP, Section
5.3. Si vous vous inquiétez d'utilisateurs locaux pouvant parcourir vos
fichiers locaux et que vous voulez avoir une communication encryptée, vous
pouvez utiliser soit un démon FTP avec support SSL ou combiner un FTP sans
cryptage avec une configuration VPN (voir Réseaux Privés Virtuels, Section 8.5).
Avoir une bonne politique relative aux quotas est important, vu qu'elle empêche les utilisateurs de remplir le(s) disque(s) dur(s).
Vous pouvez utiliser deux systèmes de quotas différents : les quotas utilisateur et les quotas groupe. Comme vous l'avez probablement deviné, les quotas utilisateur limitent la quantité d'espace qu'un utilisateur peut avoir, les quotas groupe quant à eux font la même chose pour les groupes. Retenez ceci quand vous calculerez les tailles des quotas.
Il y a quelques points importants auxquels il faut penser dans la mise en place d'un système de quotas :
/home
aussi bien que /tmp
.
Tous les répertoires et partitions auxquels les utilisateurs ont accès en écriture complet devraient avoir les quotas d'activés. Recherchez ces partitions et répertoires et calculez une taille adaptée qui combine disponibilité et sécurité.
Bon, maintenant vous désirez utiliser les quotas. Avant tout, vous avez besoin
de vérifier si vous avez activé le support du quota dans votre noyau. Si non,
vous devrez le recompiler. Après cela, contrôlez si le paquet
quota
est installé. Si non, vous en aurez également besoin.
L'activation des quotas pour des systèmes de fichiers différents est aussi
facile que la modification du paramètre defaults en
defaults,usrquota dans votre fichier /etc/fstab
. Si
vous avez besoin des quotas par groupe, remplacez usrquota par
grpquota. Vous pouvez également utiliser les deux. Ensuite,
créez des fichiers vides quota.user et quota.group à la racine du système de
fichiers sur lequel vous voulez utiliser les quotas (touch
/home/quota.user /home/quota.group pour un système de fichier
/home
).
Redémarrez le 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 (disons « ref ») peut être réalisée en faisant edquota -u ref. Les quotas par groupes peuvent être modifiés avec edquota -g <group>. Ensuite, paramétrez les quotas soft et hard et/ou les quotas pour inodes selon vos besoins.
Pour plus d'informations concernant les quotas, voir la page de manuel de la
commande quota et le quota mini-howto
(/usr/share/doc/HOWTO/en-html/mini/Quota.html
).
Vous pouvez apprécier ou non lshell
, puisque il transgresse le
FHS. Aussi prenez note que pam_limits.so peut vous fournir la même
fonctionnalité et lshell
est actuellement orphelin
En plus des permissions standard Unix, les systèmes de fichiers ext2 et ext3
vous offrent un ensemble d'attributs spécifiques qui vous donne plus de
contrôle sur les fichiers de votre système. À la différence des persmissions
de base, ces attributs ne sont pas affichés par la commande standard ls
-l
, ni changés par la commande chmod
et vous avez besoin de
deux autres utilitaires, lsattr
et chattr
(du paquet
e2fsprogs
) pour les gérer. Notez que ceci veut dire que ces
attributs ne sont habituellement pas sauvés quand vous sauvegardez le système,
donc si vous changez l'un d'entre eux, il peux être utile de sauver les
commandes chattr
successives dans un script pour pouvoir les
repositionner plus tard si vous avez à récupérer une sauvegarde.
Parmi tous les attributs disponibles, les deux plus importants pour améliorer la sécurité sont référencés par les lettres « i » et « a » et ils ne peuvent être positionés (ou enlevés) que le super-utilisateurs :
/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.
Il est aisé de voir que l'attribut « a » améliore la sécurité, en
donnant aux programmes qui ne fonctionnent pas en tant que super-utilisateur,
la possibilité d'ajouter des données à un fichier sans pouvoir modifier son
précédent contenu. D'un autre côté, l'attribut « i » semble moins
intéressant : après tout, le super-utilisateur peut déjà utiliser les
permissions standards Unix pour restreindre l'accès à un fichier et un intrus
qui aurait accès au compte super-utilisateur peut toujours utiliser le
programme chattr
pour supprimer l'attribut. Un tel intrus peut
tout d'abord être perplexe quand il se rendra compte qu'il ne peut pas
supprimer un fichier, mais vous ne devriez pas supposer qu'il est aveugle
— après tout, il est entré dans votre système ! Certains
manuels (y compris une précédente version de ce document) suggèrent de
supprimer simplement les programmes chattr
et lsattr
du système pour améliorer la sécurité, mais ce genre de stratégie, aussi connu
comme « sécurité par l'obscurité », doit être absolument évitée, car
elle donne un sentiment trompeur de sécurité.
Une façon sûre de résoudre ce problème est d'utiliser les fonctionnalités du noyau Linux, comme décrit dans Défense proactive, Section 9.3.2.1. La fonctionnalité intéressante est appelée ici CAP_LINUX_IMMUTABLE : si vous la supprimez de l'ensemble des fonctionnalités (en utilisant par exemple la commande lcap CAP_LINUX_IMMUTABLE), il ne sera plus possible n'importe quel attribut « a » ou « i » sur votre système, même par le super-utilisateur ! Une stratégie complète serait alors la suivante :
lcap
lui-même ;
Maintenant que la fonctionnalité a été enlevée de votre système, un intrus ne peut plus changer aucun attribut des fichiers protégés et donc, il ne peut pas changer ou supprimer les fichiers. S'il force la machine à redémarrer (ce qui est la seuNow that the capability has been rele façon de récupérer le jeu de fonctionnalités ), cela sera facile à détecter et la fonctionnalité sera de toute façon enlevée à nouveau dès que le redémarrage du système. La seule façon de changer un fichier protégé serait de ré-amorcer le système en mode utiliseur seul (single-user mode) ou d'utiliser une autre image d'amorçage, deux opérations qui nécessitent un accès physique à la machine !
Êtes-vous sûr que le /bin/login présent sur votre disque dur soit le même que celui que vous aviez installé il y a de cela quelques mois ? Que faire si c'est une version piratée, qui enregistre les mots de passe entrés dans un fichier caché ou les envoie en clair à travers l'Internet ?
La seule méthode pour avoir un semblant de protection est de vérifier vos
fichiers tous les heures/jours/mois (je préfère quotidiennement) en comparant
l'actuel et l'ancien md5sum de ce fichier. Deux fichiers ne peuvent avoir le
même md5sum (le MD5 est basé sur 128 bits, ainsi la chance que deux fichiers
différents aient le même md5sum est approximativement de un sur 3.4e3803), donc
de ce côté tout est ok, à moins que quelqu'un ait piraté également l'algorithme
qui crée les md5sums sur cette machine. Ceci est extrêmement difficile et très
improbable. Vous devriez vraiment prendre en compte que la vérification de vos
binaires est très importante étant donné que ceci est un moyen facile de
reconnaître des changements sur vos binaires. Les outils couramment utilisés
pour ceci sont sXid
, AIDE
(Advanced Intrusion
Detection Environment), TripWire
(non libre ; la nouvelle
version sera en GPL), integrit
et samhain
.
Installer debsums vous aidera à 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 faîtes attention, ces fichiers peuvent facilement être modifiés.
De plus, vous pouvez remplacer locate
par slocate
.
slocate est une version sécurisée améliorée de GNU locate. Lors de
l'utilisation de slocate, l'utilisateur ne peut voir que les fichiers auxquels
il a réellement accès et vous pouvez exclure tous fichiers et répertoires du
système.
Debian fournit une tâche cron
qui s'exécute quotidiennement dans
/etc/cron.daily/standard
. Cette tâche cron
exécutera
le script /usr/sbin/checksecurity
qui sauvegardera l'information
sur les changements.
Pour que cette vérification soit faite vous devez positionner
CHECKSECURITY_DISABLE="FALSE" dans
/etc/checksecurity.conf
. Notez que c'est la configuration par
défaut, donc à moins que vous ayez changé quelque chose, cette option sera déjà
positionnée à "FALSE".
Le comportement par défaut est de ne pas envoyer cette information au
super-utilisateur mais à la place de garder une copie journalière des
changements dans /var/log/setuid.changes
. Vous devrez positionner
CHECKSECURITY_EMAIL (dans /etc/checksecurity.conf
) à
« root » pour que cette information lui soit envoyée. Voir
checksecurity(8)
pour plus d'informations sur la configuration.
FIXME. Besoin de plus de contenu (spécifique Debian)
FIXME : Pas de contenu
Beaucoup de fonctionnalités du kernel peuvent être modifiées en cours de
fonctionnement en envoyant quelque chose (via la commande echo
)
dans le système de fichier /proc
ou en utilisant
sysctl
. En entrant sysctl -A, vous pouvez voir ce
que vous pouvez configurer et quelles sont les options, elles peuvent être
modifiées en exécutant /sbin/sysctl -w variable=valeur (voir
sysctl(8)
). Vous aurez seulement en de rares occasions à éditer
quelque chose ici, mais vous pouvez augmenter la sécurité de cette manière
aussi. Par exemple :
net/ipv4/icmp_echo_ignore_broadcasts = 1
C'est un « émulateur Windows » parce que ça agit comme Windows sur les ping de broadcast si celui-ci est positionné à 1. C'est-à-dire que les requêtes ICMP_ECHO envoyées à l'adresse broadcast seront ignorées. Sinon, cela ne fait rien.
Si vous voulez bloquer toutes requêtes ICMP sur votre système, activez cette option de configuration :
net/ipv4/icmp_echo_ignore_all = 0
Pour enregistrer les paquets avec des adresses impossibles (à cause de routes erronnées) sur votre réseau, utilisez :
/proc/sys/net/ipv4/conf/all/log_martians = 1
Pour plus d'informations sur ce qui peut être fait avec
/proc/sys/net/ipv4/*
, lisez
/usr/src/linux/Documentation/filesystems/proc.txt
. Toutes les
options sont décrites de façon complète sous
/usr/src/linux/Documentation/networking/ip-sysctl.txt
[14].
Cette option est à double tranchant. D'un côté, elle protège votre système contre le syn flooding ; d'un autre côté, elle viole les standards définis (RFCs).
net/ipv4/tcp_syncookies = 1
Si vous voulez changer cette option à chaque fois que le noyau fonctionne, vous devez le faire dans /etc/network/options en positionnant syncookies=yes. Ceci prendra effet à chaque fois que /etc/init.d/networking est exécuté (ce qui est fait lors du démarrage) alors que ceci ne fontionnera qu'avec le noyau en cours de fonctionnement :
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Cette option n'est dispobile que si vous avez compilé le noyau avec CONFIG_SYNCOOKIES. Tous les noyaux Debian sont compilés avec cette option incluse, mais vous pouvez le vérifier en exécutant :
$ sysctl -A |grep syncookies net/ipv4/tcp_syncookies = 1
Pour plus d'informations sur les syncookies TCP, lisez http://cr.yp.to/syncookies.html
.
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.
Créez le script dans /etc/network/interface-secure
(le nom est
donné comme exemple) et appelez le à 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
# Nom du script : /etc/network/interface-secure # Modifie plusieurs comportements par défaut pour sécuriser contre certaines # attaques et IP spoofing # # Fourni par Dariusz Puchalak # echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts # active la protection broadcast echo echo 0 > /proc/sys/net/ipv4/ip_forward # désactive l'ip forwarding echo 1 > /proc/sys/net/ipv4/tcp_syncookies # active la protection TCP syn cookie echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Logue les paquets avec des adresses impossibles # mais faites attention à ceci sur les serveurs web très chargés echo 1 > /proc/sys/net/ipv4/ip_always_defrag # active la protection permanente sur la défragmentation echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses # active la protection sur les mauvais messages d'erreur # maintenant la protection ip spoofing for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done # et enfin, encore d'autres choses # Désactuve l'acceptation Redirect ICMP for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > $f done for f in /proc/sys/net/ipv4/conf/*/send_redirects; do echo 0 > $f done # Désactuve Source Routed for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do echo 0 > $f done # Logue les paquets spoofés, les paquets Source Routed, les paquets Redirect for f in /proc/sys/net/ipv4/conf/*/log_martians; do echo 1 > $f done
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-feux, soit pour protéger le système
local ou d'autres derrière lui, le noyau doit être compilé avec les
options correspondant aux pare-feu. Le noyau standard 2.2 de la Debian
(également 2.2) fournit ipchains
qui est un pare-feu pour filtrer
les paquets, le noyau standard de la Debian 3.0 (noyau 2.4) fournit lui le
pare-feu iptables
(netfilter). Les anciennes distributions Debian
auront besoin de rustines appropriées pour le noyau (Debian 2.1 utilise le
noyau 2.0.34).
Dans tous les cas, il est relativement facile d'utiliser un noyau différent de
celui fourni par Debian. Vous pouvez trouver des noyaux pré-compilés sous
forme de paquets que vous pouvez facilement installer sur le système Debian.
Vous pouvez également télécharger les sources du noyau en utilisant
kernel-source-X
et construire des paquets de noyau personnalisé en
utilisant make-kpkg
.
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. Ceci prévient habituellement les services quand ils sont interrogés par une adresse donnée. Cependant, cela ne veut pas dire (bien qu'il s'agisse d'une erreur de conception commune que j'ai moi aussi faite) que le service est lié à une adresse matérielle donnée (carte interface). [15]
Ceci n'est pas un problème ARP et ce n'est pas une violation de RFC (c'est ce
que l'on appelle le weak end host dans la RFC1122
, section
3.3.4.2). Rappelez-vous que les adresses IP n'ont rien à voir avec les
interfaces physiques.
Sur les noyaux 2.2 (et antérieurs), ceci peut être corrigé avec :
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden # echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden .....
Sur des noyaux postérieurs, ceci peut être corrigé avec :
Tout au long de ce texte, il y aura plusieurs occasions pour lesquelles ils est affiché comment configurer certains services (serveur sshd, apache, service d'impression, etc.) pour les avoir en attente sur une adresse donnée, le lecteur devra prendre en compte que, sans les correctifs données ici, le correctif n'empêchera pas les accès depuis le même réseau (local). [18]
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 de votre réseau (ce qui devrait toujours être le cas parce que c'est l'attitude la plus sûre), vous devriez vous protéger contre les différentes attaques ARP existantes.
Comme vous le savez, le protocole ARP est utilisé pour lier des adresses IP à
des adresses MAC (voir la RFC826
pour tous les
détails). À chaque fois que vous envoyez un paquet à une adresse IP, une
résolution arp est effectuée (en regardant en premier dans le cache local ARP,
puis si l'adresse IP n'est pas présente dans le cache, en diffusant une requête
arp) pour trouver l'adresse matérielle de la cible. Toutes les attaques ARP
ont pour but d'amener votre machine à croîre que l'adresse IP de la machine B
est associée à l'adresse MAC de la machine de l'intrus ; puis tous les
paquets que vous voudrez envoyer à l'adresse IP associée à la machine B seront
envoyée à la machine de l'intrus, etc.
Ces attaques (empoisonnement du cache, falsification ARP, etc.) permettent à
l'attaquant de renifler le trafic même sur des réseaux switchés, pour pirater
facilement des connexions, pour déconnecter tout hôte du réseau, etc. Les
attaques arp sont puissantes et simples à implémenter, plusieurs outils
existent : arpspoof (présent dans le paquet dsniff
), arpmim
,
arpoison
, etc.
Cependant, il existe toujours une solution :
arp -s host_name hdwr_addr
En plaçant des entrées statiques pour chaque hôte important de votre 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.
arpwatch
,
karpski
ou des IDS plus générales qui peuvent également détecter
le trafic arp suspect (snort
, prelude
, etc.).
Avant de mettre le système en production, vous pouvez prendre un instantané de votre système entier. Cet instantané pourrait être utilisé en cas de compromis (see Après la compromission (la réponse à l'incident), Chapitre 10). Vous devriez refaire cette mise à jour à chaque fois que le système est mis à jour, particulièrement si vous mettez à jour vers une nouvelle version de Debian.
Pour cela, vous pouvez utiliser un support inscriptible et amovible qui peut être positionné en lecture seule, ce peut être une disquette (en lecture seule après utilisation) ou un CD d'une unité de CD-ROM (vous pourriez utiliser un CD-ROM ré-inscriptible, ainsi vous pourriez même garder des sauvegardes des md5sums à différentes dates).
Le script suivant crée un tel instantané :
#!/bin/bash /bin/mount /dev/fd0 /mnt/floppy /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 /bin/umout /dev/fd0 echo "Base de données md5 de post-installation calculée"
Notez que le binaire md5sum 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).
L'instantané n'inclut pas les fichiers sous /var/lib/dpkg/info
qui
incluent les hashes md5 des paquets installés (dans les fichiers se terminant
par .md5sums
). Vous pourriez également y copier cette
information, cependant il faut que vous remarquiez que :
Une fois que l'instantané est fait, vous devriez vous assurer de placer le
support en lecture seule. Vous pouvez ensuite le stocker pour archivage ou le
placer dans le lecteur et utiliser une vérification cron
toutes
les nuits en comparant les md5sums d'origine avec ceux de l'instantané.
SVGAlib est très bien pour les amoureux de la console comme moi mais dans le
passé il a été prouvé plusieurs fois qu'elle est très peu sûre. Des exploits
contre zgv
ont été diffusés et il était facile de devenir root.
Essayez d'éviter l'utilisation de programmes utilisant la SVGAlib chaque fois
que c'est possible.
Manuel de sécurisation de Debian
2.95 31 mayo 2004Vendredi 4 juillet 2003 23:13:42 +0100jfs@computer.org