Bonjour à tous,
Je n’avais jamais utilisé auditd.
Je l’ai installé sur un serveur distant, la charge, comme prévue, a fortement augmentée (~1 à ~5) avec la config de base, fichier de log à 8Mo, soit ~1mn de buffer. Cette config a fonctionné toute une nuit.
Ce matin, j’ai donc passé de 8Mo à 3Go la taille de mon fichier de log après avoir vérifié que j’avais bien 5x3=15Go dispo.
Seulement ce faisant ma charge a manifestement considérablement augmentée, mes sites ne répondent plus et mon ssh a mis 6h ! pour me dire que ma dernière commande, celle qui aurait du arrêter auditd, aurait du être lancée, bien sûr, en root. Après 8h je n’ai tj pas la main pour lancer une autre cde, ce qui signifie que su; entrer du mdp, cde d’arrêt va me demander au moins 30h!
Heu, je me demande si ton système n’a pas un autre problème.
Attends, tu veux dire six heures pour te connecter en SSH, je ne savais pas qu’il était possible que la commande aboutisse au bout de six heures, tu es très patient⋅e quand même.
pas pour me connecter, j’étais déjà connecté, mais 6h pour répondre à la commadne ‹ auditctl -D › que j’avais lancé sous mon user et pas sous root!
Ceci dit ce matin, au réveil, je n’avais tj pas la main (ni sur mon 1er terminal avec une autre commande erronée, ni sur une 2ème terminal avec une dde de connection ssh.
Heureusement, mon serveur n’était pas très loin, et sur place la console était inondée de messages " audit: backlog limit exceeded" sans que je puisse prendre la main. N’ayant pas bcp de temps, j’ai effectué un Off/On et tout est reparti.
Avec Auditd il faut faire attention au backlog_limit. Son paramétrage peut avoir pas mal d’effets:
DESCRIPTION top
audit_set_backlog_limit sets the queue length for audit events awaiting transfer to the audit daemon. The default value is 64 which can potentially be overrun by bursts of activity. When the backlog limit is reached, the kernel consults the failure_flag to see what action to take.
Personnellement, cette variable dans mon /etc/default/grub (et donc dans grub.cfg) est à 8192 à minima.
2ème plantage hier avec auditd après avoir monté progressivement la taille du fichier de log de 8 à 16, puis à 32 et enfin à 64Mo et malgré un cron horaire de sécutité « auditctl -D »
Concernant le paramètre audit_set_backlog_limit je n’ l’ai pas touché car d’après le message d’init il était déjà à 8192.
Quel est l’etat de ton filesystem?
Perso j’ai une partition specifique à /var/log et une autre pour /var/og/audit (comme ca si audit pose problème ca n’impacte pas le reste).
De plus es tu sur que tes fichiers audit.log ont un logrotate ? afin de s’assurer que ton audit ne remplisse pas le disque avec tous les ficheir.
ensuite dans auditd.conf quelle est la valeur de :
max_log_file_action = KEEP_LOGS
space_left_action = email
verify_email = yes
action_mail_acct = root
admin_space_left_action = halt ->> c’est la variable qui détermine ce que fait le système en cas de saturation du disque.
ext4
Bien vu, je garde l’idée pour un prochain test éventuel.
Certain et la place était largement disponible.
Sais plus, pour l’instant j’ai tout désinstallé.