Linux gilt als robustes und sicheres Betriebssystem.

Doch eine frische Linux-Installation ist nicht automatisch ein sicher betriebener Server.

Ein öffentlich erreichbarer SSH-Dienst kann angegriffen werden.

Eine falsch konfigurierte Anwendung kann unnötige Ports öffnen.

Manipulierte Systemdateien können unentdeckt bleiben.

Ein kompromittiertes Benutzerkonto kann für weitere Angriffe verwendet werden.

Und wenn sicherheitsrelevante Aktivitäten nicht protokolliert werden, lässt sich ein Vorfall später möglicherweise kaum rekonstruieren.

Deshalb benötigt auch Linux ein mehrschichtiges Sicherheitskonzept.

Für viele dieser Aufgaben stehen hervorragende Open-Source-Werkzeuge zur Verfügung:

UFW        → einfache Firewallverwaltung

nftables   → leistungsfähige Paketfilterung

Fail2ban   → automatisches Blockieren auffälliger Clients

CrowdSec   → verhaltensbasierte Angriffserkennung

AppArmor   → Einschränkung von Anwendungen

AIDE       → Datei-Integritätsüberwachung

RKHunter   → Suche nach Rootkit-Indikatoren

Lynis      → Security Auditing und Hardening

auditd     → detailliertes System-Auditing

Diese Werkzeuge erfüllen unterschiedliche Aufgaben.

Gerade ihre Kombination kann eine wirkungsvolle Defense-in-Depth-Architektur ergeben.

1. Defense in Depth unter Linux

Ein sicherer Linux-Server sollte niemals ausschließlich durch eine einzelne Sicherheitsmaßnahme geschützt werden.

Eine Firewall allein reicht nicht.

Fail2ban allein reicht nicht.

Ein Virenscanner allein reicht ebenfalls nicht.

Stattdessen werden mehrere Schutzebenen kombiniert.

Beispielsweise:

Internet
   │
   ▼
Firewall
UFW / nftables
   │
   ▼
Angriffserkennung
Fail2ban / CrowdSec
   │
   ▼
Dienste
SSH / Web / Anwendungen
   │
   ▼
Anwendungsbeschränkung
AppArmor
   │
   ▼
Dateiintegrität
AIDE
   │
   ▼
Systemüberwachung
auditd
   │
   ▼
Security Audit
Lynis

Wird eine Schutzschicht überwunden, existieren weitere Kontrollmechanismen.

Dieses Prinzip nennt man Defense in Depth.

2. Vor der Härtung: System aktualisieren

Bevor zusätzliche Sicherheitswerkzeuge installiert werden, sollte das Betriebssystem aktuell sein.

Unter Debian beziehungsweise Ubuntu beispielsweise:

sudo apt update
sudo apt upgrade

Optional können nicht mehr benötigte Pakete entfernt werden:

sudo apt autoremove

Die installierte Distribution lässt sich beispielsweise mit folgendem Befehl prüfen:

cat /etc/os-release

Auch der Kernel sollte bekannt sein:

uname -r

Updates bleiben eine der wichtigsten technischen Sicherheitsmaßnahmen überhaupt.

Die in diesem Artikel beschriebenen Werkzeuge ersetzen kein Patchmanagement.

3. Offene Ports kontrollieren

Bevor eine Firewall eingerichtet wird, sollte zunächst geprüft werden, welche Dienste überhaupt lauschen.

Beispielsweise:

sudo ss -tulpn

Die Ausgabe könnte beispielsweise zeigen:

22/tcp
80/tcp
443/tcp
3306/tcp

Nun muss für jeden Port gefragt werden:

Muss dieser Dienst wirklich aus dem Netzwerk erreichbar sein?

Ein Datenbankserver auf Port 3306 muss beispielsweise häufig nicht aus dem Internet erreichbar sein.

Der wichtigste Firewall-Grundsatz lautet:

Nur freigeben, was tatsächlich benötigt wird.

4. UFW – unkomplizierte Firewallverwaltung

UFW steht für Uncomplicated Firewall.

Das Werkzeug bietet eine vergleichsweise einfache Möglichkeit, Firewallregeln auf Linux-Systemen zu verwalten.

Installation unter Debian beziehungsweise Ubuntu:

sudo apt install ufw

Status prüfen:

sudo ufw status

Eine sinnvolle Grundstrategie lautet:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Damit werden eingehende Verbindungen standardmäßig blockiert.

Ausgehende Verbindungen bleiben erlaubt.

5. SSH freigeben

Bevor UFW auf einem Remote-Server aktiviert wird, muss unbedingt sichergestellt werden, dass der eigene administrative Zugang erlaubt bleibt.

Sonst kann man sich selbst aussperren.

SSH kann beispielsweise freigegeben werden mit:

sudo ufw allow OpenSSH

Alternativ:

sudo ufw allow 22/tcp

Danach kann UFW aktiviert werden:

sudo ufw enable

Status anzeigen:

sudo ufw status verbose

6. Webserver freigeben

Ein Webserver benötigt normalerweise HTTP und HTTPS.

Beispielsweise:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Anschließend:

sudo ufw status numbered

Damit werden die Regeln nummeriert angezeigt.

Eine Regel lässt sich anschließend beispielsweise löschen:

sudo ufw delete 3

7. Zugriff auf bestimmte Netze beschränken

Administrationsdienste sollten möglichst nicht weltweit erreichbar sein.

SSH könnte beispielsweise ausschließlich aus einem Administrationsnetz zugelassen werden:

sudo ufw allow from 192.168.10.0/24 to any port 22 proto tcp

Damit reduziert sich die Angriffsfläche erheblich.

Statt:

Internet
   │
   ▼
SSH

entsteht:

Admin-Netz
   │
   ▼
SSH

Internet
   X

Noch besser kann der Zugriff beispielsweise über VPN oder einen administrativen Jump Host erfolgen.

8. nftables – die leistungsfähige Firewall

Für komplexere Anforderungen bietet Linux mit nftables ein leistungsfähiges Framework zur Paketfilterung.

nftables ist der moderne Nachfolger der klassischen iptables-Werkzeuge.

Installation:

sudo apt install nftables

Dienst aktivieren:

sudo systemctl enable --now nftables

Regelwerk anzeigen:

sudo nft list ruleset

Eine sehr einfache Grundstruktur könnte beispielsweise so aussehen:

table inet filter
 └── chain input
      ├── established → accept
      ├── loopback    → accept
      ├── ssh         → accept
      ├── http        → accept
      ├── https       → accept
      └── rest        → drop

nftables ermöglicht deutlich komplexere Regeln als dieses vereinfachte Beispiel.

9. UFW oder nftables?

Die Frage lautet häufig:

Soll ich UFW oder nftables verwenden?

UFW eignet sich hervorragend für:

• einfache Server,
• überschaubare Regelwerke,
• schnelle Administration.

nftables eignet sich besser für:

• komplexe Firewallregeln,
• größere Umgebungen,
• umfangreiche Filterlogik,
• fortgeschrittene Netzwerkarchitekturen.

Wichtig:

UFW ist eine Verwaltungsoberfläche für das zugrunde liegende Linux-Firewalling.

Man sollte deshalb nicht ohne Konzept mehrere Firewall-Werkzeuge parallel konfigurieren.

Das kann zu schwer nachvollziehbaren Regeln führen.

10. Fail2ban – automatischer Schutz gegen wiederholte Angriffe

Ein öffentlich erreichbarer SSH-Server erhält häufig zahlreiche automatisierte Loginversuche.

Beispielsweise:

admin
root
test
ubuntu
administrator
oracle

Fail2ban analysiert Logdateien beziehungsweise Logquellen und erkennt wiederholte verdächtige Aktivitäten.

Anschließend kann die Quell-IP temporär blockiert werden.

Vereinfacht:

Angreifer
   │
   ├── Login falsch
   ├── Login falsch
   ├── Login falsch
   ├── Login falsch
   └── Login falsch
          │
          ▼
       Fail2ban
          │
          ▼
      IP blockiert

11. Fail2ban installieren

Unter Debian beziehungsweise Ubuntu:

sudo apt install fail2ban

Dienststatus prüfen:

sudo systemctl status fail2ban

Eine eigene Konfiguration sollte normalerweise nicht direkt in:

/etc/fail2ban/jail.conf

vorgenommen werden.

Stattdessen können lokale Konfigurationen verwendet werden.

Beispielsweise:

sudo nano /etc/fail2ban/jail.local

12. SSH mit Fail2ban schützen

Eine einfache Konfiguration könnte beispielsweise lauten:

[sshd]
enabled = true
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h

Das bedeutet vereinfacht:

Innerhalb von zehn Minuten führen fünf entsprechende Fehlversuche zu einer einstündigen Sperre.

Danach:

sudo systemctl restart fail2ban

Status:

sudo fail2ban-client status

Status des SSH-Jails:

sudo fail2ban-client status sshd

13. Fail2ban ersetzt keine sichere SSH-Konfiguration

Ein wichtiger Punkt:

Fail2ban darf nicht als Ersatz für eine sichere SSH-Konfiguration betrachtet werden.

Die wichtigsten Maßnahmen bleiben beispielsweise:

• kein direkter Root-Login,
• Schlüssel statt Passwort, wo praktikabel,
• MFA bei geeigneten Szenarien,
• Netzwerkbeschränkung,
• VPN beziehungsweise Jump Host,
• Least Privilege.

Fail2ban ist eine zusätzliche Schutzschicht.

14. CrowdSec – kollaborative Angriffserkennung

CrowdSec verfolgt einen moderneren Ansatz.

Die Software analysiert Verhaltensmuster und erkennt verdächtige Aktivitäten.

Dabei werden Erkennung und Blockierung voneinander getrennt.

Vereinfacht:

Logs
 │
 ▼
CrowdSec
 │
 ▼
Analyse
 │
 ▼
Entscheidung
 │
 ▼
Bouncer
 │
 ▼
Firewall / Reverse Proxy

Sogenannte Bouncer können anschließend erkannte Angreifer blockieren.

15. CrowdSec installieren

Da sich Installationswege und Paketquellen ändern können, sollte für produktive Systeme die aktuelle Dokumentation des Projekts verwendet werden.

Nach einer Installation kann der Status typischerweise über die CrowdSec-Werkzeuge geprüft werden.

Beispielsweise:

sudo cscli metrics

Entscheidungen anzeigen:

sudo cscli decisions list

Installierte Collections:

sudo cscli collections list

Collections liefern vorkonfigurierte Erkennungslogik für bestimmte Dienste.

Beispielsweise für:

• SSH,
• Webserver,
• Reverse Proxies.

16. Fail2ban oder CrowdSec?

Beide Lösungen verfolgen ähnliche Ziele, unterscheiden sich jedoch im Ansatz.

Fail2ban ist:

• etabliert,
• relativ einfach,
• logbasiert,
• lokal ausgerichtet.

CrowdSec bietet:

• moderne Szenarioerkennung,
• Community-basierte Threat Intelligence,
• getrennte Detection- und Remediation-Komponenten,
• flexible Integrationen.

Es muss nicht zwingend beides gleichzeitig eingesetzt werden.

Die Lösung sollte zur eigenen Architektur und zum eigenen Betriebsmodell passen.

17. AppArmor – Anwendungen einschränken

Eine Firewall kontrolliert Netzwerkverkehr.

Doch was passiert, wenn eine Anwendung selbst kompromittiert wird?

Hier kommt Mandatory Access Control ins Spiel.

Unter Ubuntu und einigen anderen Distributionen wird häufig AppArmor eingesetzt.

AppArmor kann festlegen, auf welche Ressourcen ein Prozess zugreifen darf.

Beispielsweise:

Webserver
   │
   ├── darf lesen:
   │   /var/www/
   │
   ├── darf schreiben:
   │   /var/log/
   │
   └── darf NICHT:
       /home/admin/

Selbst wenn der Webserver kompromittiert wird, können dessen Möglichkeiten dadurch eingeschränkt werden.

18. AppArmor-Status prüfen

Status anzeigen:

sudo aa-status

Profile können unterschiedliche Zustände besitzen.

Wichtig sind insbesondere:

Enforce Mode

Regeln werden tatsächlich durchgesetzt.

Complain Mode

Verstöße werden protokolliert, aber nicht blockiert.

Der Complain Mode kann hilfreich sein, wenn zunächst geprüft werden soll, welche Zugriffe eine Anwendung benötigt.

Anschließend kann das Profil angepasst und in den Enforce Mode versetzt werden.

19. AppArmor ist besonders wertvoll bei exponierten Diensten

Besonders interessant ist AppArmor für Dienste, die:

• aus dem Internet erreichbar sind,
• komplexen Input verarbeiten,
• erhöhte Risiken besitzen.

Beispiele:

• Webserver,
• Datenbankdienste,
• DNS-Server,
• Netzwerkdienste.

Das Prinzip lautet:

Eine Anwendung erhält nur die Ressourcen, die sie für ihre Aufgabe benötigt.

Damit wird Least Privilege auf Prozessebene umgesetzt.

20. AIDE – Datei-Integrität überwachen

Ein Angreifer kompromittiert einen Server.

Anschließend verändert er beispielsweise:

/etc/passwd
/etc/ssh/sshd_config
/usr/bin/...
/etc/sudoers

Wie erkennt man solche Veränderungen?

Ein Werkzeug dafür ist AIDE – Advanced Intrusion Detection Environment.

AIDE erstellt eine Referenzdatenbank wichtiger Dateien.

Dabei können Eigenschaften wie:

• Hashwerte,
• Dateigröße,
• Berechtigungen,
• Eigentümer,
• Zeitstempel

berücksichtigt werden.

Später wird der aktuelle Zustand mit dieser Baseline verglichen.

21. AIDE installieren

Unter Debian beziehungsweise Ubuntu:

sudo apt install aide

Danach muss zunächst eine Referenzdatenbank aufgebaut werden.

Der genaue Befehl kann je nach Distribution beziehungsweise Paketierung variieren.

Typischerweise wird anschließend regelmäßig ein Integritätscheck durchgeführt.

Das Prinzip lautet:

Baseline
   │
   ▼
Systemzustand
   │
   ▼
Vergleich
   │
   ├── unverändert
   │
   └── verändert
          │
          ▼
        prüfen

22. Die AIDE-Datenbank besonders schützen

Hier entsteht ein wichtiges Sicherheitsproblem.

Wenn ein Angreifer sowohl das System als auch die lokale AIDE-Baseline manipulieren kann, verliert die Integritätsprüfung an Aussagekraft.

Deshalb sollte die Referenzdatenbank besonders geschützt werden.

Je nach Sicherheitsbedarf beispielsweise:

• restriktive Berechtigungen,
• separate Speicherung,
• externe Sicherung,
• manipulationsgeschützte Ablage.

Dasselbe gilt für die Ergebnisse der Integritätsprüfung.

23. RKHunter – nach Rootkit-Indikatoren suchen

Rootkit Hunter, kurz RKHunter, sucht Linux-Systeme nach verschiedenen Anzeichen möglicher Rootkits beziehungsweise verdächtiger Veränderungen ab.

Installation:

sudo apt install rkhunter

Prüfung starten:

sudo rkhunter --check

RKHunter kann unter anderem prüfen:

• bekannte Rootkit-Indikatoren,
• verdächtige Dateien,
• ungewöhnliche Berechtigungen,
• bestimmte Systemveränderungen.

24. RKHunter-Ergebnisse richtig interpretieren

Ein RKHunter-Warning bedeutet nicht automatisch:

„Der Server wurde gehackt.“

Das Werkzeug kann Fehlalarme erzeugen.

Deshalb müssen Ergebnisse fachlich bewertet werden.

RKHunter sollte als zusätzlicher Indikator verstanden werden.

Nicht als absoluter Beweis für:

System sauber

oder:

System kompromittiert

Bei konkretem Kompromittierungsverdacht ist eine professionelle Incident-Response- beziehungsweise forensische Untersuchung erforderlich.

25. Lynis – der Sicherheitscheck für Linux

Lynis ist eines der bekanntesten Werkzeuge für Security Auditing und System Hardening unter Unix- beziehungsweise Linux-Systemen.

Installation unter Debian beziehungsweise Ubuntu:

sudo apt install lynis

Security Audit starten:

sudo lynis audit system

Lynis untersucht zahlreiche Bereiche des Systems.

Beispielsweise:

• Boot-Konfiguration,
• Kernel,
• Benutzer,
• Authentifizierung,
• Dateisysteme,
• Netzwerk,
• SSH,
• Logging,
• Firewall,
• Dienste,
• Dateiberechtigungen,
• Hardening-Einstellungen.

26. Lynis-Ergebnisse nutzen

Nach einem Scan liefert Lynis Hinweise und Verbesserungsvorschläge.

Diese sollten nicht blind umgesetzt werden.

Die richtige Vorgehensweise lautet:

Lynis Finding
     │
     ▼
Risiko bewerten
     │
     ▼
Auswirkung prüfen
     │
     ▼
Maßnahme testen
     │
     ▼
umsetzen
     │
     ▼
dokumentieren

Eine Empfehlung, die für einen öffentlichen Webserver sinnvoll ist, muss nicht automatisch für einen internen Spezialserver geeignet sein.

Lynis ist deshalb ein Auditwerkzeug, kein automatischer NIS-2-Konfigurator.

27. Lynis regelmäßig ausführen

Besonders interessant wird Lynis, wenn Audits wiederholt werden.

Beispielsweise:

Januar
Security Audit

April
Security Audit

Juli
Security Audit

Oktober
Security Audit

So lassen sich Veränderungen und neue Findings erkennen.

Die Ergebnisse können außerdem in das Schwachstellen- und Maßnahmenmanagement übernommen werden.

28. auditd – detailliertes Linux-Auditing

Für die Nachvollziehbarkeit sicherheitsrelevanter Aktivitäten bietet Linux das Audit Framework.

Der Userspace-Dienst dafür ist auditd.

Installation:

sudo apt install auditd audispd-plugins

Dienst prüfen:

sudo systemctl status auditd

Das Audit-System kann beispielsweise überwachen:

• Zugriffe auf Dateien,
• Änderungen an Konfigurationen,
• Benutzeraktionen,
• sicherheitsrelevante Systemaufrufe.

29. Kritische Dateien überwachen

Ein klassisches Beispiel ist die Überwachung sensibler Dateien.

Beispielsweise:

sudo auditctl -w /etc/passwd -p wa -k identity

Dabei bedeutet vereinfacht:

-w  → Datei beziehungsweise Pfad beobachten
-p  → Berechtigungsarten überwachen
w   → write
a   → attribute change
-k  → Schlüssel für spätere Suche

Auch /etc/sudoers könnte überwacht werden.

Beispielsweise:

sudo auditctl -w /etc/sudoers -p wa -k sudoers

30. Audit-Ereignisse suchen

Über ausearch können Audit-Ereignisse ausgewertet werden.

Beispielsweise:

sudo ausearch -k identity

Oder:

sudo ausearch -k sudoers

Berichte können unter anderem mit aureport erstellt werden.

Beispielsweise:

sudo aureport

Damit wird auditd besonders für sicherheitsrelevante Nachvollziehbarkeit interessant.

31. Audit-Regeln persistent konfigurieren

Mit auditctl gesetzte Regeln können je nach Vorgehensweise nur temporär gelten.

Für dauerhafte Regeln werden entsprechende Audit-Konfigurationsdateien verwendet.

Typischerweise befinden sich Regeln unter:

/etc/audit/rules.d/

Beispielsweise:

/etc/audit/rules.d/security.rules

Nach Änderungen müssen die Regeln entsprechend geladen beziehungsweise der Audit-Dienst korrekt aktualisiert werden.

Vor produktiven Änderungen sollte die distributionsspezifische Dokumentation geprüft werden.

32. auditd und SIEM verbinden

Besonders leistungsfähig wird auditd in Verbindung mit zentralem Logging.

Beispielsweise:

Linux Server
    │
    ▼
auditd
    │
    ▼
Log Forwarder
    │
    ▼
SIEM
    │
    ▼
Detection Rule
    │
    ▼
Security Alert

Beispiel:

Ein Benutzer verändert /etc/sudoers.

auditd erkennt die Änderung.

Das Ereignis wird an das SIEM übertragen.

Das SIEM erkennt eine ungewöhnliche Änderung außerhalb eines Wartungsfensters.

Security erhält einen Alarm.

Damit schließt sich der Kreis zu Teil 13 – Protokollierung und Monitoring.

33. Werkzeuge sinnvoll kombinieren

Eine mögliche Linux-Sicherheitsarchitektur könnte folgendermaßen aussehen:

                    Internet
                       │
                       ▼
                UFW / nftables
                       │
                       ▼
              Fail2ban / CrowdSec
                       │
                       ▼
                 Linux-Dienste
                       │
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
          AppArmor            auditd
              │                 │
              ▼                 ▼
        eingeschränkte       SIEM
          Prozesse
              │
              ▼
             AIDE
              │
              ▼
      Integritätsprüfung

Zusätzliche Audits:

Lynis
RKHunter
Vulnerability Scanner

Damit werden unterschiedliche Sicherheitsziele abgedeckt.

34. Automatisierung nutzen

Auf wenigen Servern lassen sich viele Einstellungen noch manuell pflegen.

Bei 100 oder 1.000 Linux-Systemen wird das schwierig.

Dann sollten Konfigurationen automatisiert werden.

Beispielsweise mit:

• Ansible,
• Puppet,
• Salt,
• vergleichbaren Configuration-Management-Systemen.

Damit können Security-Baselines reproduzierbar verteilt werden.

Beispielsweise:

Security Baseline
       │
       ▼
     Ansible
       │
   ┌───┼───┐
   ▼   ▼   ▼
Server Server Server
  01    02    03

Das erhöht Konsistenz und Nachvollziehbarkeit.

35. Eine Linux-Security-Baseline definieren

Eine Organisation sollte festlegen, welche Mindestanforderungen für Linux-Systeme gelten.

Eine Baseline könnte beispielsweise enthalten:

Patchmanagement
Firewall aktiv
SSH gehärtet
Root-Login deaktiviert
Logging zentral
auditd aktiv
AppArmor aktiv
Zeit synchronisiert
unnötige Dienste deaktiviert
Integritätsprüfung eingerichtet
Security Audit durchgeführt
Backup eingerichtet
Monitoring aktiv

Abweichungen müssen anschließend begründet und dokumentiert werden.

36. Technische Maßnahmen dokumentieren

Für NIS-2 reicht es nicht, Tools irgendwann installiert zu haben.

Die Organisation sollte nachvollziehbar dokumentieren:

• welche Systeme geschützt werden,
• welche Maßnahmen eingesetzt werden,
• warum diese Maßnahmen gewählt wurden,
• wer verantwortlich ist,
• wie Konfigurationen geprüft werden,
• wie Alarme behandelt werden,
• wann Kontrollen stattfinden.

Ein technisches Kontrollregister könnte beispielsweise enthalten:

System:
srv-web-01

Firewall:
nftables

Intrusion Prevention:
CrowdSec

MAC:
AppArmor

Integrity Monitoring:
AIDE

Auditing:
auditd

Security Audit:
Lynis

Logging:
zentrales SIEM

Verantwortlich:
Linux Operations

Letzte Prüfung:
15.08.2026

Damit werden technische Sicherheitsmaßnahmen auditierbar.

37. Typische Fehler

Fehler 1: Firewall installieren und vergessen

Regeln müssen regelmäßig überprüft werden.

Fehler 2: Fail2ban als vollständigen SSH-Schutz betrachten

Sichere Authentifizierung und Netzwerkbeschränkungen bleiben wichtiger.

Fehler 3: Mehrere Firewall-Werkzeuge unkoordiniert betreiben

Das erschwert Fehlersuche und Dokumentation.

Fehler 4: AIDE-Baseline ungeschützt lokal speichern

Ein Angreifer könnte versuchen, Baseline und System gleichzeitig zu manipulieren.

Fehler 5: Jede RKHunter-Warnung als bestätigten Angriff behandeln

Findings müssen analysiert werden.

Fehler 6: Lynis-Empfehlungen blind umsetzen

Hardening muss zum jeweiligen System passen.

Fehler 7: auditd aktivieren, aber Logs niemals auswerten

Ein Log ohne Auswertung liefert nur begrenzten Schutz.

Fehler 8: Tools installieren, aber keine Prozesse definieren

Technik benötigt Verantwortlichkeiten und Reaktionswege.

Praktische NIS-2-Checkliste für Linux-Sicherheit

Grundsystem

☐ Ist das Betriebssystem aktuell?

☐ Werden Sicherheitsupdates regelmäßig installiert?

☐ Sind unnötige Pakete entfernt?

☐ Sind unnötige Dienste deaktiviert?

☐ Werden offene Ports regelmäßig überprüft?

Firewall

☐ Ist eine Host-Firewall aktiv?

☐ Existiert ein Default-Deny-Konzept für eingehenden Verkehr?

☐ Sind ausschließlich benötigte Ports freigegeben?

☐ Sind Administrationszugänge auf definierte Netze beschränkt?

☐ Werden Firewallregeln dokumentiert?

SSH

☐ Ist direkter Root-Login deaktiviert?

☐ Werden sichere Authentisierungsverfahren verwendet?

☐ Ist SSH möglichst auf Administrationsnetze beziehungsweise VPN beschränkt?

☐ Werden fehlgeschlagene Anmeldungen überwacht?

Fail2ban / CrowdSec

☐ Werden relevante Dienste überwacht?

☐ Sind Schwellenwerte sinnvoll konfiguriert?

☐ Werden Sperren beziehungsweise Entscheidungen kontrolliert?

☐ Werden False Positives berücksichtigt?

AppArmor

☐ Ist AppArmor aktiv?

☐ Existieren Profile für relevante Dienste?

☐ Werden Profile möglichst im Enforce Mode betrieben?

☐ Werden Verstöße zentral ausgewertet?

Datei-Integrität

☐ Wird AIDE oder eine vergleichbare Lösung eingesetzt?

☐ Existiert eine vertrauenswürdige Baseline?

☐ Ist die Baseline gegen Manipulation geschützt?

☐ Werden Integritätsabweichungen untersucht?

Security Auditing

☐ Werden Systeme regelmäßig mit Lynis oder vergleichbaren Werkzeugen geprüft?

☐ Werden Findings bewertet?

☐ Werden Maßnahmen dokumentiert?

☐ Werden Audits wiederholt?

auditd

☐ Ist auditd aktiv?

☐ Werden kritische Dateien überwacht?

☐ Werden sicherheitsrelevante Änderungen protokolliert?

☐ Sind wichtige Regeln persistent?

☐ Werden Audit-Logs zentral gespeichert beziehungsweise ausgewertet?

Monitoring

☐ Werden Security Logs zentral gesammelt?

☐ Existieren SIEM-Regeln für wichtige Linux-Ereignisse?

☐ Werden Ausfälle der Logging-Infrastruktur erkannt?

☐ Existieren definierte Alarmierungs- und Eskalationswege?

Linux bietet eine enorme Auswahl leistungsfähiger Sicherheitswerkzeuge.

Doch ihre Stärke liegt nicht darin, möglichst viele davon gleichzeitig zu installieren.

Entscheidend ist, welche Sicherheitsaufgabe ein Werkzeug übernimmt und wie es in das Gesamtkonzept integriert wird.

UFW beziehungsweise nftables reduzieren die erreichbare Angriffsfläche.

Fail2ban oder CrowdSec erkennen und begrenzen bestimmte automatisierte Angriffe.

AppArmor beschränkt die Möglichkeiten kompromittierter Prozesse.

AIDE überwacht die Integrität wichtiger Dateien.

RKHunter liefert zusätzliche Hinweise auf verdächtige Systemveränderungen.

Lynis hilft dabei, Schwachstellen in der Systemkonfiguration und mögliche Hardening-Maßnahmen zu erkennen.

auditd schafft detaillierte Nachvollziehbarkeit sicherheitsrelevanter Aktivitäten.

Zusammen entsteht eine mehrschichtige Architektur:

Reduzieren → Blockieren → Beschränken → Überwachen → Erkennen → Protokollieren → Analysieren → Reagieren

Genau darin liegt der entscheidende NIS-2-Gedanke.

Nicht das Vorhandensein eines bestimmten Linux-Tools macht ein System sicher oder „NIS-2-konform“.

Entscheidend ist ein risikobasiertes Sicherheitskonzept aus technischen und organisatorischen Maßnahmen, klaren Verantwortlichkeiten, regelmäßigen Kontrollen und nachvollziehbarer Dokumentation.

Oder kurz:

Installierte Security-Tools sind der Anfang.

Wirksam werden sie erst, wenn jemand sie richtig konfiguriert, überwacht und auf ihre Erkenntnisse reagiert.