# AppArmor Enterprise: Performance und Monitoring im Fokus

TL;DR / Management Summary Ein Sicherheitsmodul ist nur dann nützlich, wenn es das System nicht ausbremst und wenn seine Warnungen beachtet werden. In diesem Modul schauen wir uns an, wie wir AppArmor-Events in ein zentrales SIEM (Security Information and Event Management) einspeisen und wie wir die Performance bei tausenden von Profilen optimieren. Ein “Silent Deny” ohne Benachrichtigung ist in der Enterprise-Welt wertlos.

# 1. Einführung & Architektur

Der Weg der Sicherheits-Events.

AppArmor meldet Verstöße an das Kernel-Audit-Subsystem. Von dort werden die Daten an den User-Space weitergereicht.

# Die Event-Pipeline (Mermaid)

graph LR
    A[Kernel: AppArmor Denial] --> B[Audit Subsystem]
    B --> C[auditd Daemon]
    C -->|JSON/Syslog| D[SIEM: ELK / Splunk / Graylog]
    C --> E[aa-notify: Desktop Alert]
    C --> F[aa-logprof: Admin CLI]

# 2. Performance-Aspekte

Sicherheit ohne Reibungsverlust.

AppArmor ist extrem effizient (pfadbasiert), braucht aber Kernel-Speicher für jedes geladene Profil.

# Speicherverbrauch optimieren

• Profil-Anzahl: Hunderte von Profilen sind kein Problem. Erst bei tausenden wird der Memory-Footprint des Kernels spürbar.
• Regel-Komplexität: Nutzen Sie Abstraktionen (Inklusionen). Sie werden vom Kernel effizienter verarbeitet als tausende Einzelregeln.

# 3. SIEM-Integration

Wer hat wen blockiert?

Standardmäßig schreibt AppArmor in das Audit-Log. Für eine Auswertung in ELK oder Graylog müssen die Daten strukturiert werden.

# Beispiel: Audit-Regel für AppArmor

Stellen Sie sicher, dass das Audit-Subsystem korrekt konfiguriert ist:

# In /etc/audit/rules.d/audit.rules
-w /etc/apparmor.d/ -p wa -k apparmor_config_change

# Parsing des Logs

Ein typischer AppArmor Denial sieht so aus: type=AVC msg=audit(1698312000.123:456): apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/etc/shadow" pid=1234 comm="nginx" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

# 4. Day-2 Operations: Echtzeit-Alarmierung

Sofortige Reaktion.

# aa-notify

Das Tool aa-notify kann den Admin bei Verstößen sofort benachrichtigen.

# Benachrichtige User 1000 bei jedem Denial in den letzten 24h
sudo aa-notify -u 1000 -s 1

# 5. Troubleshooting & “War Stories”

Wenn die Logs zu laut werden.

# Story 1: “Der Log-Overflow”

Symptom: Das System-Log läuft mit tausenden “DENIED” Meldungen eines hängenden Skripts voll. Die CPU-Last steigt durch den Schreibvorgang massiv an. Ursache: Eine Applikation versucht in einer Endlosschleife auf einen verbotenen Pfad zuzugreifen. Lösung: Nutzen Sie quiet deny Regeln im Profil. Dies blockiert den Zugriff, unterdrückt aber das Logging für diesen spezifischen Pfad.

# Im Profil
quiet deny /etc/shadow r,

# Story 2: “Das verschwundene Audit-Event”

Symptom: AppArmor blockiert, aber es erscheint kein Eintrag in der SIEM-Konsole. Ursache: Der auditd Dämon hat ein Limit für “Backlog Events” und verwirft neue Meldungen bei Überlastung. Lösung: Erhöhen Sie das Backlog-Limit in /etc/audit/audit.rules: -b 8192.

# 6. Fazit & Empfehlung

• Sichtbarkeit: Ohne SIEM-Integration ist AppArmor nur eine lokale Schutzmaßnahme. In der Enterprise-Umgebung müssen Security-Verstöße zentral korreliert werden.
• Performance: Überwachen Sie den Kernel-Speicher bei massiven Container-Setups (LXC/LXD), da hier hunderte Profile gleichzeitig aktiv sein können.
• Wartung: Nutzen Sie aa-status regelmäßig, um Profile zu identifizieren, die noch im Complain-Modus laufen (Technical Debt!).

# Anhang: Cheatsheet