Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(76.8, 36%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGA%3C/text%3E%3C/svg%3E)
Hat jemand dieses Verhalten auf Linux-Systemen beobachtet, bei dem:
Auditd Sicherheitsereignisse erfasst.
Das Auditing ordnungsgemäß aktiviert ist.
Ereignisse zunächst erfolgreich in den Kernel-Backlog geschrieben werden.
Die Anzahl der Audit-Events jedoch schneller ansteigt, als sie auf die Festplatte geschrieben werden können.
Dadurch der Audit-Backlog-Puffer voll läuft.
Infolgedessen Sicherheitsereignisse verworfen oder verloren gehen.
Die Audit-Protokolle deuten darauf hin, dass die Erfassung grundsätzlich funktioniert,
die Ereignisgenerierung erfolgreich ist,
Auditd aktiv bleibt,
aber der Backlog regelmäßig ausgelastet wird und Events verworfen werden.
Wie lässt sich in diesem Fall der Parameter backlog_limit sinnvoll anpassen, um den Verlust von Audit-Events zu vermeiden? Gibt es bewährte Empfehlungen oder Best Practices für die Dimensionierung des Audit-Backlogs in Umgebungen mit hoher Ereignisrate ?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 62%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EH%3C/text%3E%3C/svg%3E)
Wenn alles in Ordnung ist, vergessen Sie bitte nicht, Ihre Erfahrung mit diesem Problem zu teilen, indem Sie auf „Accept Answer“ klicken. Wenn Sie weitere Informationen benötigen, können Sie uns gerne eine Nachricht hinterlassen. Wir helfen Ihnen gerne weiter
Hallo Glets Alpen
Bei einem solchen Verhalten würde ich zuerst bestätigen, wie häufig der Audit-Backlog tatsächlich voll läuft, bevor ich backlog_limit einfach stark erhöhe. Der Parameter bestimmt im Wesentlichen, wie viele Audit-Ereignisse der Kernel zwischenspeichern kann, bevor sie von auditd verarbeitet werden.
Bei hoher Ereignisrate kann eine größere Queue zwar kurzfristige Lastspitzen abfangen, sie behebt aber nicht das eigentliche Problem, wenn auditd dauerhaft langsamer schreibt als neue Events entstehen. Ich würde daher zunächst die verworfenen Events und die aktuelle Backlog-Auslastung prüfen und gleichzeitig CPU-, I/O- und Storage-Latenzen des Systems beobachten. Anschließend kann man backlog_limit schrittweise erhöhen und anhand der tatsächlichen Event-Rate testen, ob dadurch die Spitzen abgefangen werden.
Wichtig ist, genügend RAM einzuplanen und den Wert nicht unnötig groß zu wählen, da ein sehr hoher Backlog lediglich mehr Ereignisse zwischenspeichert und keinen dauerhaft überlasteten Storage schneller macht. In Umgebungen mit sehr hoher Audit-Last lohnt es sich außerdem, die Audit-Regeln auf wirklich benötigte Events zu begrenzen und unnötige, extrem häufige Regeln zu vermeiden. Wenn der Backlog trotz einer angemessenen Erhöhung regelmäßig voll läuft, würde ich eher die Ursache der hohen Event-Rate oder die Schreibperformance untersuchen als den Queue-Wert immer weiter zu erhöhen. Wenn diese Schritte bei Ihnen geholfen haben, können Sie die Antwort gerne mit „Accept Answer“ markieren.
