Pourquoi y a-t-il des erreurs « audit: limite d'arriéré dépassée » dans les journaux de capture d'écran et système de mon instance Linux EC2, et que puis-je faire pour éviter cela ?

Lecture de 5 minute(s)
0

Je vois des messages d'erreur « rappels d'audit supprimés » et « audit : limite d'arriéré dépassée » dans les journaux de capture d'écran et système de mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2). Pourquoi est-ce que je reçois ces messages et comment puis-je les empêcher de se reproduire ?

Brève description

Le tampon d'arriéré d'audit dans un système Linux est une file d'attente de tampon de socket au niveau du noyau que le système d'exploitation utilise pour maintenir ou journaliser les événements d'audit. Lorsqu'un nouvel événement d'audit se déclenche, le système journalise l'événement et l'ajoute à la file d'attente du tampon d'arriéré d'audit.

La valeur du paramètre backlog_limit correspond au nombre de tampons d'arriéré d'audit. Le paramètre est défini sur 320 par défaut, comme illustré dans l'exemple suivant :

# auditctl -s
enabled 1
failure 1
pid 2264
rate_limit 0
backlog_limit 320
lost 0
backlog 0

Les événements d'audit journalisés au-delà de 320, nombre par défaut, provoquent les erreurs suivantes sur l'instance :

audit: audit_backlog=321 > audit_backlog_limit=320 

audit: audit_lost=44393 audit_rate_limit=0 audit_backlog_limit=320 

audit: backlog limit exceeded

-ou-

audit_printk_skb: 153 callbacks suppressed

audit_printk_skb: 114 callbacks suppressed

Une file d'attente de tampon d'audit égale ou supérieure à la capacité peut également entraîner le blocage ou le maintien de l'instance dans un état de non-réponse.

Pour éviter le dépassement des erreurs de la limite d'arriéré, augmentez la valeur du paramètre backlog_limit. Les grands serveurs ont un plus grand nombre de journaux d'audit déclenchés, de sorte que l'augmentation de l'espace tampon permet d'éviter les messages d'erreur.

Remarque : l'augmentation du tampon d'audit consomme davantage de mémoire de l'instance. La taille du paramètre backlog_limit dépend de la mémoire totale de l'instance. Si le système dispose de suffisamment de mémoire, vous pouvez essayer de doubler la valeur existante du paramètre backlog_limit.

Vous trouverez ci-dessous un calcul de la mémoire requise pour l'arriéré d'audit. Utilisez ce calcul pour déterminer la taille maximale de la file d'attente des arriérés sans entraîner de pression sur la mémoire de votre instance.

Un tampon d'audit = 8 970 octets
Nombre par défaut de tampons d'audit (paramètre backlog_limit) = 320
320 * 8 970 = 2 870 400 octets, ou 2,7 Mio

La taille du tampon d'audit est définie par le paramètre MAX_AUDIT_MESSAGE_LENGTH. Pour plus d'informations, consultez la section MAX_AUDIT_MESSAGE_LENGTH dans la bibliothèque d'audit Linux sur github.com.

Remarque : si votre instance est inaccessible et que vous voyez des messages limite d'arriéré dépassée dans le journal système, arrêtez et démarrez l'instance. Ensuite, procédez comme suit pour modifier la valeur du tampon d'audit.

Solution

Remarque : dans cet exemple, nous modifions la valeur du paramètre backlog_limit en 8 192 tampons. 8 192 tampons représentent 70 Mio de mémoire selon le calcul précédent. Vous pouvez utiliser n'importe quelle valeur basée sur votre calcul de mémoire.

  1. Accédez à l'instance à l'aide du service SSH.

  2. Vérifiez la taille actuelle du tampon d'audit.

Remarque : le paramètre backlog_limit est répertorié en tant que -b. Pour plus d'informations, consultez la section auditctl(8) sur la page auditctl-man.

Amazon Linux 1 et les autres systèmes d'exploitation qui n'utilisent pas systemd :

$ sudo cat /etc/audit/audit.rules
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Disable system call auditing.
# Remove the following line if you need the auditing.
-a never,task

# Feel free to add below this line. See auditctl man page

Amazon Linux 2 et les autres systèmes d'exploitation qui utilisent systemd :

$ sudo cat /etc/audit/audit.rules
# This file is automatically generated from /etc/audit/rules.d
-D
-b 320
-f 1
  1. Accédez au fichier audit.rules à l'aide d'un éditeur, tel que l'éditeur vi :

Amazon Linux 1 et les autres systèmes d'exploitation qui n'utilisent pas systemd :

$ sudo vi /etc/audit/audit.rules

Amazon Linux 2 et les autres systèmes d'exploitation qui utilisent systemd :

$ sudo vi /etc/audit/rules.d/audit.rules
  1. Modifiez le paramètre -b en une valeur plus élevée. L'exemple suivant change la valeur -b en 8 192.
$ sudo cat /etc/audit/audit.rules
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 8192

# Disable system call auditing.
# Remove the following line if you need the auditing.
-a never,task

# Feel free to add below this line. See auditctl man page

$ sudo auditctl -s
enabled 1
failure 1
pid 2264
rate_limit 0
backlog_limit 320
lost 0
backlog 0
  1. Redémarrez le service auditd. La nouvelle valeur backlog_limit prend effet. La valeur est également mise à jour dans auditctl -s, comme indiqué dans l'exemple suivant :
# sudo service auditd stop
Stopping auditd:                                           [  OK  ]
# sudo service auditd start
Starting auditd:                                           [  OK  ]
# auditctl -s
enabled 1
failure 1
pid 26823
rate_limit 0
backlog_limit 8192
lost 0
backlog 0

Remarque : si votre instance est inaccessible et que vous voyez des messages limite d'arriéré dépassée dans le journal système, arrêtez et démarrez l'instance. Ensuite, suivez les étapes précédentes pour modifier la valeur du tampon d'audit.


AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 4 ans