Ubuntu 18.04: Audit backlog limit exceeded?

Skulle tro att "Audit backlog limit exceeded" indikerar på att den fyller upp backlog buffern för audits.
Så något kanske spottar ur sig info väldigt snabbt så att systemet blir upptaget med att hantera det, därmed hamnar det i backloggen som även den fylls upp i den takt att meddelandena poppar upp.
Troligtvis leder det till att systemet blir helt upptaget i.o.m. alla meddelanden och därmed fungerar inte nätverkstjänsterna längre. Likt ett buffer overflow scenario.

Är du helt säker på att du inte har auditd installerat?
Kan du köra kommandot:

systemctl cat auditd

Då skall svaret bli:

No files found for auditd.service.

Om det inte är installerat/används.

Annars borde du kunna använda journalctl kommandot på Ubuntu Server 18.04 för att få en närmare blick över vad som försiggår.

Finns en hel del bra parametrar som du kan använda för att felsöka via journalctl-loggen:

https://www.digitalocean.com/community/tutorials/how-to-use-j...

Kan ha ev. ha bidragit till att skapa ett race condition som kan liknas vid nån intern DOS-attack, så att systemet slutar svara.

Kanske är någon docker-container som löper amok p.g.a. kombination med AppArmor profil som i sint tur blockerar access.
Har sett liknande även med Snaps, att AppArmor kan få flipp.
Finns ju även de containrar som är oerhört "på" när det kommer till att requesta saker.
Du kan e.v. behöva konfigurera en AppArmor profil som tillåter, vad den nu vill göra, -om du är införstådd att containrarna i sin tur kommer från säkra källor, för det kan finnas "elaka" containrar med.

Med kommandot:

dmesg | grep apparmor

Borde du kunna se alla AppArmor meddelanden och på vilken path den fått "DENIED". Troligtvis måste du tillåta den path:en via en AppArmor-profil.

Detta kanske är en användbar sida i ditt fall, när det kommer till att confa AppArmor:

https://ubuntu.com/server/docs/security-apparmor

Checking and debugging denies

You will see in ‘dmesg’ and any log that collects kernel messages if you have hit a deny.
Right away it is worth to know that this will cover any access that was denied because it was not allowed, but explicit denies will put no message in your logs at all.

Examples might look like:

[1521056.552037] audit: type=1400 audit(1571868402.378:24425): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/var/lib/libvirt/dnsmasq/" pid=1128 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[1482106.651527] audit: type=1400 audit(1571829452.330:24323): apparmor="DENIED" operation="sendmsg" profile="snap.lxd.lxc" pid=24115 comm="lxc" laddr=10.7.0.69 lport=48796 faddr=10.7.0.231 fport=445 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send"

That follows a generic structure starting with a timestamp, an audit tag and the category apparmor="DENIED".
From the following fields you can derive what was going on and why it was failing.

In the examples above that would be

First example:

operation: open (program tried to open a file)
profile: /usr/sbin/cups-browsed (you’ll find /etc/apparmor.d/usr.bin.cups-browsed)
name: /var/lib/libvirt/dnsmasq (what it wanted to access)
pid/comm: the program that did trigger the access
requested_mask/denied_mask/fsuid/ouid: parameters of that open call

Second example:

operation: sendmsg (program tried send via network)
profile: snap.lxd.lxc (snaps are special, you’ll find /var/lib/snapd/apparmor/profiles/snap.lxd.lxc)
pid/comm: the program that did trigger the access
laddr/lport/faddr/fport/family/sock_type/protocol: parameters of that sendmsg call

That way you know in which profile and at what action you have to start if you consider either debugging or adapting the profiles.