Contrôler l'utilisation des ressources peut se révéler très utile pour éviter une attaque de type déni de sevice local ou bien pour limiter le nombre total d'ouvertures de sessions pour un groupe ou un utilisateur. Toutefois, des limites trop strictes peuvent empêcher certains programmes de s'exécuter normalement.
Exemple de code 1.1 : /etc/security/limits.conf |
* soft core 0 * hard core 0 * hard nproc 15 * hard rss 10000 * - maxlogins 2 @dev hard core 100000 @dev soft nproc 20 @dev hard nproc 35 @dev - maxlogins 10 |
Si vous vous rendez compte que vous mettez nproc ou maxlogins à 0, il serait certainement plus simple de supprimer l'utilisateur. L'exemple ci-dessus paramètre le groupe dev pour le nombre de processus, les fichiers core et maxlogins. Le reste est laissé à la valeur par défaut.
Note : Le fichier /etc/security/limits.conf fait partie du paquet PAM et ne sera utilisé que par les paquets dépendant de PAM. |
Le fichier /etc/limits est très similaire au fichier /etc/security/limits.conf. Les seules différences sont dans le format et dans le fait qu'il ne fonctionne qu'avec des utilisateurs ou des expressions rationnelles (et non pas avec des groupes). Regardons un exemple de configuration de plus près :
Exemple de code 1.1 : /etc/limits |
* L2 C0 U15 R10000 kn L10 C100000 U35 |
Nous réglons ici les paramètres par défaut, mais également une valeur particulière pour l'utilisateur kn. Les limites font partie du paquet sys-apps/shadow. Il n'est pas nécessaire de mettre des limites dans ce fichier si vous avez activé pam dans votre make.conf.
Attention : Assurez-vous que le système de fichiers avec lequel vous travaillez supporte les quotas. Pour utiliser les quotas avec ReiserFS, vous devez appliquer à votre noyau le correctif disponible sur le site de Namesys. Les outils de l'utilisateur sont disponibles sur le site du Linux DiskQuota project. Bien que les quotas fonctionnent avec ReiserFS, vous éprouverez peut-être des problèmes lorsque vous essayerez de les utiliser ; vous voilà donc averti ! |
Placer des quotas sur un système de fichiers restreint l'utilisation du disque sur la base de l'identité de l'utilisateur et de son groupe. Les quotas sont activés dans le noyau et ajoutés par la suite sur un point de montage dans /etc/fstab. L'option du noyau qui active ce paramètre se trouve dans la section File systems->Quota support. Appliquez l'option, recompilez votre noyau et redémarrez en utilisant votre nouveau noyau.
Commencez par installer les quotas avec emerge quota. Modifiez ensuite votre fichier /etc/fstab et ajoutez les paramètres usrquota et grpquota aux partitions sur lesquelles vous souhaitez restreindre l'utilisation du disque, comme le montre l'exemple ci-dessous.
Exemple de code 1.1 : /etc/fstab |
/dev/sda1 /boot ext2 noauto,noatime 1 1 /dev/sda2 none swap sw 0 0 /dev/sda3 / reiserfs notail,noatime 0 0 /dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec,usrquota,grpquota 0 0 /dev/sda5 /var reiserfs notail,noatime,nodev,usrquota,grpquota 0 0 /dev/sda6 /home reiserfs notail,noatime,nodev,nosuid,usrquota,grpquota 0 0 /dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0 proc /proc proc defaults 0 0 |
Vous devez ensuite créer les fichiers de quotas (aquota.user et aquota.group) pour chaque partition sur lesquelles vous avez activé les quotas, puis placer ces fichiers à la racine de ces partitions.
Exemple de code 1.1 : Création des fichiers de quota |
# touch /tmp/aquota.user # touch /tmp/aquota.group # chmod 600 /tmp/aquota.user # chmod 600 /tmp/aquota.group |
Cette étape est nécessaire pour chaque partition où les quotas sont actifs. Après avoir ajouté et configuré les fichiers de quotas, vous devez ajouter le script quota aux scripts d'initialisation pour appliquer les quotas après chaque démarrage.
Important : XFS procède aux vérifications des quotas en interne, il n'a pas besoin que le script quota soit ajouté au niveau d'exécution de démarrage. D'autres systèmes de fichiers non listés dans ce document peuvent fonctionner également ainsi. Veuillez donc vérifier la documentation de votre système de fichiers pour savoir comment il gère les quotas. |
Exemple de code 1.1 : Lancer le script quota à chaque démarrage |
# rc-update add quota boot
|
Configurez le système afin de vérifier les quotas une fois par semaine en ajoutant la ligne suivante dans /etc/crontab :
Exemple de code 1.1 : Ajouter la vérification des quotas au crontab |
0 3 * * 0 /usr/sbin/quotacheck -avug. |
Après avoir redémarré la machine, il est temps de configurer les quotas pour les utilisateurs et les groupes. La commande edquota -u kn démarrera l'éditeur défini dans $EDITOR (nano par défaut) qui vous permettra d'éditer les quotas de l'utilisateur kn. edquota -g vous permet de faire la même chose pour les groupes.
Exemple de code 1.1 : Mettre en place des quotas pour l'utilisateur kn |
Quotas pour l'utilisateur kn :
/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500)
inodes in use: 356, limits (soft = 1000, hard = 1500)
|
Pour plus d'informations sur les quotas, consultez les pages man à l'aide de man edquota ou bien le mini-howto des quotas.
Si votre politique de sécurité spécifie que les utilisateurs doivent changer leur mot de passe toutes les deux semaines, mettez la valeur de PASS_MAX_DAYS à 14 et celle de PASS_WARN_AGE à 7. Il est également conseillé d'utiliser l'ancienneté des mots de passe car les attaques par force brute peuvent trouver n'importe quel mot de passe ; ce n'est qu'une question de temps. Nous recommandons également de définir la variable LOG_OK_LOGINS à yes.
Le fichier login.access fait également partie du paquet sys-apps/shadow, qui vous donne accès à une table de contrôle des ouvertures de sessions. Cette table est utilisée pour décider qui a le droit ou pas d'ouvrir une session en fonction du nom d'utilisateur, du nom de groupe ou du nom d'hôte. Par défaut, tous les utilisateurs du système ont le droit d'ouvrir une session. Le fichier n'est donc constitué que d'exemples et de commentaires. Que vous sécurisiez une station de travail ou un serveur, nous vous recommandons de configurer ce fichier de telle sorte que vous (l'administrateur) soyez le seul autorisé à accéder à la console.
Note : Ces paramètres ne s'appliquent pas à root. |
Exemple de code 1.1 : /etc/login.access |
-:ALL EXCEPT wheel sync:console -:wheel:ALL EXCEPT LOCAL .gentoo.org |
Important : Faites attention lorsque vous entrez ces options, car une erreur vous laissera sans accès à la machine si vous n'avez pas d'accès root. |
Note : Ces paramètres n'affectent pas SSH car il n'utilise pas /bin/login par défaut. Vous pouvez changer ce comportement en mettant UseLogin yes dans le fichier /etc/ssh/sshd_config. |
Cela paramétrera l'accès d'ouverture de session pour que les membres du groupe wheel puissent ouvrir une session localement ou depuis le domaine gentoo.org. Cela peut paraître paranoïaque, mais il vaut mieux être sécurisé que désolé.