# Auditd - Attention **URL:** \ **Category:** Support Debian\ **Created:** [Septembre 16, 2020, 4:14 UTC](https://www.debian-fr.org/t/auditd-attention/82859 "2020-09-16T16:14:32Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Septembre 16, 2020, 4:14 UTC](https://www.debian-fr.org/t/auditd-attention/82859/1 "2020-09-16T16:14:33Z")
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! ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Septembre 17, 2020, 5:36 UTC](https://www.debian-fr.org/t/auditd-attention/82859/2 "2020-09-17T05:36:36Z")
Heu, je me demande si ton système n’a pas un autre problème. > [@PmGs](#): > > mon ssh a mis 6h 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. ---
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Septembre 17, 2020, 12:14 UTC](https://www.debian-fr.org/t/auditd-attention/82859/3 "2020-09-17T12:14:05Z")
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. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 18, 2020, 11:09 UTC](https://www.debian-fr.org/t/auditd-attention/82859/4 "2020-09-18T11:09:51Z")
Avec Auditd il faut faire attention au backlog\_limit. Son paramétrage peut avoir pas mal d’effets: ## DESCRIPTION [top](https://man7.org/linux/man-pages/man3/audit_set_backlog_limit.3.html#top_of_page) 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. ---
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Septembre 23, 2020, 5:15 UTC](https://www.debian-fr.org/t/auditd-attention/82859/5 "2020-09-23T17:15:53Z")
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. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 23, 2020, 6:15 UTC](https://www.debian-fr.org/t/auditd-attention/82859/6 "2020-09-23T18:15:20Z")
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. ---
**Author:** ![PmGs](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/dfb087/32.png) [@PmGs](https://www.debian-fr.org/u/PmGs)\ **Post date:** [Septembre 23, 2020, 6:30 UTC](https://www.debian-fr.org/t/auditd-attention/82859/7 "2020-09-23T18:30:05Z")
> [@Zargos](#): > > Quel est l’etat de ton filesystem? ext4 > [@Zargos](#): > > 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). Bien vu, je garde l’idée pour un prochain test éventuel. > [@Zargos](#): > > 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. Certain et la place était largement disponible. > [@Zargos](#): > > ensuite dans auditd.conf quelle est la valeur de : Sais plus, pour l’instant j’ai tout désinstallé.