Étendre la limite de file d'attente d'audit pour le démon d'audit
Ajoute le paramètre de démarrage du noyau audit_backlog_limit=8192 afin que la file des événements d'audit soit assez grande pour contenir les messages générés avant le démarrage de auditd.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
audit_backlog_limit définit la longueur de la file des événements d'audit en attente de transfert vers le démon d'audit. Tant qu'auditd n'est pas démarré, tous les messages d'audit du noyau sont mis en tampon dans cette file. Avec la limite par défaut (faible), la file peut déborder en début de démarrage, déclenchant l'action d'échec d'audit et, surtout, abandonnant silencieusement des enregistrements de l'activité la plus précoce, précisément la fenêtre que viserait un attaquant. La porter à 8192 préserve ces preuves précoces.
Ce que vérifie Pavois
Pavois lit /proc/cmdline, la ligne de commande réelle avec laquelle le noyau en cours a démarré, et vérifie la présence de audit_backlog_limit=8192. C'est supérieur à l'analyse de /etc/default/grub ou grub.cfg : ceux-ci décrivent ce qui devrait démarrer la prochaine fois, alors que /proc/cmdline prouve que la valeur est active maintenant. Un update-grub raté ou un drop-in concurrent laisserait le fichier correct alors que le noyau tourne avec l'ancienne valeur.
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )audit_backlog_limit=8192( |$)/) }
end
describe command("grep -hwsF 'audit_backlog_limit=8192' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez cat /proc/cmdline et confirmez qu'elle contient audit_backlog_limit=8192. La valeur active est celle du démarrage. Après un changement de configuration, vous devez redémarrer pour qu'elle apparaisse ici.
Inspecter et investiguer
Les débordements de file et l'action d'échec sont visibles dans le tampon noyau : dmesg | grep -i audit (cherchez "audit: backlog limit exceeded"). Les enregistrements d'audit eux-mêmes vont dans /var/log/audit/audit.log ; auditctl -s montre backlog et backlog_limit actuels.
Remédiation
pavois harden apply utilise la ressource kernel_cmdline pour ajouter audit_backlog_limit=8192 à la configuration du chargeur d'amorçage (GRUB) et la régénérer. Comme un paramètre de démarrage du noyau ne prend effet qu'au démarrage, le changement est signalé reboot_required : la valeur n'apparaît dans /proc/cmdline qu'après le redémarrage suivant.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| param | audit_backlog_limit=8192 |
|---|---|
| reboot_required | true |
| resource | kernel_cmdline |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque faible : une file plus grande consomme un peu plus de mémoire noyau mais ne change pas le fonctionnement normal. Précautions : le changement nécessite un redémarrage pour prendre effet, planifiez-le ; vérifiez que le chargeur d'amorçage s'est régénéré proprement (/proc/cmdline après redémarrage) afin de ne pas démarrer une ligne de noyau imprévue. Sur les systèmes à mémoire très limitée, choisissez une valeur cohérente avec la RAM disponible.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 10.7.2, 6.2.1.4, 6.3.1.3 | direct | per OS, see the benchmark table | haute |
| NIST | CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.7.2 | support | 4.0.1 | moyenne |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.