Sehr gern – hier ist Teil 10 der NIS-2-Serie als ausführlicher Praxisbeitrag. Der Schwerpunkt liegt darauf, Linux- und Windows-Server nicht nur technisch zu härten, sondern die Maßnahmen in einen nachvollziehbaren, dokumentierten und dauerhaft betriebenen Sicherheitsprozess einzubetten.

NIS-2 Teil 10: Server absichern – Linux, Windows, SSH, RDP und Logging

Server bilden das Rückgrat nahezu jeder IT-Infrastruktur. Sie stellen Anwendungen bereit, speichern Daten, übernehmen Authentifizierungsaufgaben, betreiben Datenbanken oder dienen als Plattform für Fachverfahren und interne Dienste. Genau deshalb gehören sie zu den attraktivsten Angriffszielen einer IT-Umgebung.

Ein kompromittierter Arbeitsplatzrechner ist bereits problematisch. Ein kompromittierter Server kann dagegen schnell Auswirkungen auf ganze Organisationen haben.

Im Rahmen von NIS-2 reicht es deshalb nicht aus, einen Server zu installieren, regelmäßig Updates einzuspielen und auf eine Firewall zu vertrauen. Server müssen über ihren gesamten Lebenszyklus hinweg sicher konfiguriert, überwacht, aktualisiert und dokumentiert werden.

Dabei spielt es keine Rolle, ob Ubuntu, Debian, Red Hat Enterprise Linux, Windows Server oder eine andere Plattform eingesetzt wird. Die grundlegenden Prinzipien bleiben dieselben:

Angriffsfläche reduzieren, Zugriffe begrenzen, Systeme aktuell halten und sicherheitsrelevante Vorgänge sichtbar machen.

Warum Server-Härtung für NIS-2 wichtig ist

NIS-2 verlangt von betroffenen Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen zum Management von Cyberrisiken.

Server-Härtung ist dabei keine einzelne Maßnahme. Vielmehr setzt sie sich aus verschiedenen Sicherheitsmechanismen zusammen.

Dazu gehören beispielsweise:

• sichere Basiskonfigurationen,
• Patch- und Updateprozesse,
• Zugriffskontrollen,
• sichere Administration,
• Protokollierung,
• Überwachung,
• Schwachstellenmanagement,
• Backup und Wiederherstellung,
• sowie die regelmäßige Überprüfung der Konfiguration.

Entscheidend ist außerdem die Nachvollziehbarkeit.

Es genügt langfristig nicht, dass ein Administrator sagt:

„Der Server ist sicher konfiguriert.“

Die Organisation sollte vielmehr nachvollziehen können, welche Sicherheitsvorgaben gelten, wann Änderungen durchgeführt wurden und ob die Systeme diesen Vorgaben weiterhin entsprechen.

1. Linux-Server härten

Linux-Systeme gelten grundsätzlich als sehr gut absicherbar. Eine Standardinstallation ist jedoch nicht automatisch eine gehärtete Installation.

Der erste Schritt sollte deshalb darin bestehen, eine definierte Basiskonfiguration festzulegen.

Diese kann sich beispielsweise an etablierten Empfehlungen wie CIS Benchmarks, Herstellerempfehlungen oder eigenen Sicherheitsrichtlinien orientieren.

Nur notwendige Software installieren

Je mehr Software auf einem Server installiert ist, desto größer wird grundsätzlich dessen mögliche Angriffsfläche.

Ein Webserver benötigt beispielsweise normalerweise keine grafische Desktopumgebung.

Installierte Pakete lassen sich unter Debian oder Ubuntu beispielsweise mit folgendem Befehl anzeigen:

apt list --installed

Pakete, die nicht benötigt werden, sollten nach einer Prüfung entfernt werden.

sudo apt remove paketname

Dabei gilt allerdings:

Nicht blind aufräumen.

Abhängigkeiten und Auswirkungen auf produktive Anwendungen müssen vor einer Entfernung geprüft werden.

Benutzer und Berechtigungen überprüfen

Auch lokale Benutzerkonten gehören regelmäßig auf den Prüfstand.

Eine Übersicht liefert beispielsweise:

cat /etc/passwd

Besonders relevant sind Konten mit administrativen Berechtigungen.

getent group sudo

Administrationsrechte sollten nach dem Least-Privilege-Prinzip vergeben werden. Ein Benutzer erhält also nur die Berechtigungen, die er tatsächlich benötigt.

Direkte Arbeit mit dem Root-Konto sollte möglichst vermieden werden. Stattdessen können administrative Tätigkeiten kontrolliert über sudo durchgeführt werden.

2. Windows Server sicher konfigurieren

Auch Windows Server sollte nach einer definierten Sicherheitsbaseline betrieben werden.

Wichtige Bereiche sind unter anderem:

• lokale Sicherheitsrichtlinien,
• Gruppenrichtlinien,
• Windows Defender Firewall,
• Microsoft Defender,
• Benutzerrechte,
• NTFS-Berechtigungen,
• PowerShell,
• Remotezugriffe,
• SMB-Konfiguration,
• Ereignisprotokollierung.

Besonders in Active-Directory-Umgebungen bietet sich eine zentrale Konfiguration über Group Policy Objects (GPOs) an.

Damit lassen sich Sicherheitsvorgaben konsistent auf viele Systeme übertragen.

Ein wesentlicher Vorteil:

Sicherheitskonfigurationen hängen nicht ausschließlich davon ab, ob ein Administrator daran denkt, einen bestimmten Haken zu setzen.

Lokale Administratoren kontrollieren

Lokale Administratorrechte sollten stark begrenzt werden.

Eine einfache Abfrage mit PowerShell kann beispielsweise zeigen, welche Benutzer Mitglieder der lokalen Administratorengruppe sind:

Get-LocalGroupMember -Group "Administrators"

In deutschsprachigen Installationen kann die Bezeichnung der Gruppe abweichen.

Gerade dauerhaft eingerichtete lokale Administratorkonten können ein erhebliches Risiko darstellen.

Für lokale Administratorkennwörter kann in Active-Directory-Umgebungen beispielsweise Windows LAPS eingesetzt werden.

3. Updates und Patchmanagement

Eine der wichtigsten Maßnahmen zur Serverabsicherung ist gleichzeitig eine der unspektakulärsten:

Updates installieren.

Bekannte Schwachstellen gehören zu den bevorzugten Angriffspunkten automatisierter Angriffe.

Unter Debian und Ubuntu können verfügbare Updates beispielsweise folgendermaßen geprüft werden:

sudo apt update
apt list --upgradable

Anschließend können Updates installiert werden:

sudo apt upgrade

Unter Windows Server übernimmt Windows Update beziehungsweise eine zentral eingesetzte Update-Management-Lösung diese Aufgabe.

Entscheidend ist jedoch weniger das verwendete Werkzeug als der dahinterliegende Prozess.

Eine Organisation sollte definieren:

• Wer überwacht verfügbare Sicherheitsupdates?
• Wie werden kritische Schwachstellen priorisiert?
• Wie schnell müssen Updates installiert werden?
• Werden Updates vorher getestet?
• Wer dokumentiert die Installation?
• Was passiert, wenn ein Patch nicht installiert werden kann?
• Gibt es einen definierten Rollback-Prozess?

NIS-2 sollte deshalb nicht als Aufforderung verstanden werden, Updates einfach automatisch einzuschalten.

Benötigt wird vielmehr ein nachvollziehbares Patchmanagement.

4. SSH absichern

SSH ist eines der wichtigsten Administrationsprotokolle in Linux-Umgebungen.

Gleichzeitig sind öffentlich erreichbare SSH-Dienste ein beliebtes Ziel automatisierter Angriffe.

Die zentrale Konfiguration befindet sich üblicherweise unter:

/etc/ssh/sshd_config

Eine wichtige Maßnahme ist beispielsweise die Deaktivierung direkter Root-Anmeldungen:

PermitRootLogin no

Noch wichtiger kann die Umstellung von Kennwörtern auf Public-Key-Authentifizierung sein.

Nach erfolgreicher Einrichtung der Schlüsselanmeldung kann beispielsweise die Kennwortanmeldung deaktiviert werden:

PasswordAuthentication no

Wichtig: Eine solche Änderung sollte niemals vorgenommen werden, bevor die Anmeldung per Schlüssel erfolgreich getestet wurde. Andernfalls kann man sich selbst aus dem System aussperren.

Zusätzlich sollte der SSH-Zugriff möglichst über Netzwerkregeln eingeschränkt werden.

Ein Administrationsserver muss normalerweise nicht aus dem gesamten Internet per SSH erreichbar sein.

Besser sind beispielsweise:

Administrationsnetz → Firewall → Server

oder

VPN → Administrationsnetz → Server

Zusätzliche Schutzmechanismen wie Fail2ban oder CrowdSec können automatisierte Angriffe erkennen und blockieren.

5. RDP absichern

Was SSH für Linux ist, ist in vielen Windows-Umgebungen das Remote Desktop Protocol – kurz RDP.

Auch hier gilt:

RDP sollte möglichst nicht direkt aus dem Internet erreichbar sein.

Sicherer sind Architekturen mit:

• VPN,
• Remote Desktop Gateway,
• Jump Hosts,
• administrativen Netzwerksegmenten,
• MFA,
• restriktiven Firewallregeln.

Network Level Authentication sollte aktiviert sein.

Außerdem sollte genau definiert werden, welche Benutzer überhaupt Remote-Desktop-Zugriff erhalten.

RDP ist ein Administrationswerkzeug und sollte nicht automatisch für jeden Benutzer eines Servers freigeschaltet werden.

6. Unnötige Dienste deaktivieren

Jeder laufende Dienst kann potenziell eine zusätzliche Angriffsfläche darstellen.

Unter Linux lassen sich aktive Dienste beispielsweise mit systemctl untersuchen:

systemctl --type=service --state=running

Lauschende Netzwerkports können beispielsweise mit ss angezeigt werden:

sudo ss -tulpn

Dabei sollte für jeden offenen Port die Frage gestellt werden:

Warum ist dieser Port geöffnet und welcher Dienst benötigt ihn?

Ein nicht benötigter Dienst sollte deaktiviert werden.

Beispielsweise:

sudo systemctl disable --now dienstname

Auch bei Windows Server sollte regelmäßig überprüft werden, welche Rollen, Features und Dienste tatsächlich benötigt werden.

Das Prinzip lautet:

Was nicht benötigt wird, sollte nach Möglichkeit auch nicht laufen.

7. Logging – Angriffe sichtbar machen

Ein Server kann hervorragend gehärtet sein und trotzdem angegriffen werden.

Deshalb benötigt eine moderne Sicherheitsarchitektur ausreichende Protokollierung.

Unter Linux können beispielsweise Systemereignisse mit journalctl untersucht werden:

journalctl

Nur Meldungen seit dem letzten Start:

journalctl -b

SSH-Ereignisse lassen sich je nach Distribution beispielsweise über das Journal untersuchen:

journalctl -u ssh

Windows Server stellt umfangreiche Ereignisprotokolle über die Windows-Ereignisanzeige bereit.

Interessant sind unter anderem:

• erfolgreiche Anmeldungen,
• fehlgeschlagene Anmeldungen,
• Änderungen an Benutzerkonten,
• Änderungen administrativer Gruppen,
• gestartete Dienste,
• Richtlinienänderungen,
• Defender-Ereignisse,
• PowerShell-Aktivitäten.

Doch Logs ausschließlich lokal auf dem jeweiligen Server zu speichern, ist aus Sicherheitssicht problematisch.

Ein Angreifer mit administrativen Rechten könnte versuchen, Protokolle zu manipulieren oder zu löschen.

Deshalb sollten wichtige Ereignisse möglichst an ein zentrales Logging- oder SIEM-System übertragen werden.

Die Architektur könnte beispielsweise folgendermaßen aussehen:

Linux-Server ─────┐
                  │
Windows-Server ───┼──► Zentrales Logging / SIEM ──► Alarmierung
                  │
Firewall ─────────┤
                  │
Endpoints ────────┘

Damit werden Ereignisse verschiedener Systeme miteinander korrelierbar.

Logging allein reicht nicht

Ein häufiges Problem besteht darin, große Mengen von Protokolldaten zu sammeln, ohne diese anschließend auszuwerten.

Eine Organisation besitzt dann möglicherweise mehrere Terabyte Logs – erkennt einen Angriff aber trotzdem nicht.

Deshalb gehören drei Dinge zusammen:

Logging → Analyse → Alarmierung

Beispiele für relevante Ereignisse sind:

• zahlreiche fehlgeschlagene Anmeldungen,
• Anmeldung administrativer Konten zu ungewöhnlichen Zeiten,
• neue Administratoren,
• neue Dienste,
• unerwartete Prozesse,
• Änderungen an Firewallregeln,
• deaktivierte Sicherheitssoftware,
• ungewöhnliche Netzwerkverbindungen.

Für solche Ereignisse sollten Regeln und Alarmierungswege definiert werden.

Server in eigene Netzwerksegmente verschieben

Server-Härtung endet nicht am Betriebssystem.

Server sollten zusätzlich durch die Netzwerkarchitektur geschützt werden.

Statt eines großen gemeinsamen Netzes kann beispielsweise segmentiert werden:

Clients
   │
   ▼
Firewall
   │
   ├── Webserver
   ├── Applikationsserver
   ├── Datenbankserver
   └── Management-Netz

Ein Benutzer-PC benötigt beispielsweise normalerweise keinen direkten administrativen Zugriff auf einen Datenbankserver.

Firewallregeln sollten deshalb nach dem Prinzip gestaltet werden:

Nur notwendige Kommunikation erlauben.

Damit wird gleichzeitig die laterale Bewegung eines Angreifers erschwert.

Sicherheitsbaselines definieren

Für NIS-2 ist es sinnvoll, verbindliche Sicherheitsbaselines für Servertypen festzulegen.

Eine Linux-Baseline könnte beispielsweise vorgeben:

• SSH-Root-Login deaktiviert,
• SSH-Schlüssel für Administration,
• Host-Firewall aktiviert,
• zentrale Protokollierung eingerichtet,
• automatische Zeitsynchronisation aktiv,
• nur notwendige Dienste installiert,
• definierter Patchprozess,
• Backup eingerichtet,
• Monitoring aktiv.

Eine Windows-Server-Baseline könnte entsprechend enthalten:

• Microsoft Defender aktiviert,
• Windows Firewall aktiviert,
• RDP eingeschränkt,
• NLA aktiviert,
• lokale Administratoren begrenzt,
• sichere GPOs angewendet,
• Logging aktiviert,
• zentraler Logversand eingerichtet,
• definierter Patchprozess,
• Backup und Monitoring aktiv.

Solche Baselines machen Sicherheitsmaßnahmen messbar und überprüfbar.

Regelmäßige Überprüfung statt einmaliger Härtung

Ein entscheidender Punkt wird häufig übersehen:

Server-Härtung ist kein einmaliges Projekt.

Ein Server kann heute sicher konfiguriert sein und sechs Monate später erheblich von seiner ursprünglichen Sicherheitsbaseline abweichen.

Gründe dafür können sein:

• neue Software,
• temporäre Firewallfreigaben,
• neue Benutzer,
• vergessene Testkonten,
• geänderte Dienste,
• veraltete Pakete,
• neue Schwachstellen,
• Änderungen an Anwendungen.

Deshalb sollten Server regelmäßig überprüft werden.

Für Linux können beispielsweise Werkzeuge wie Lynis bei Sicherheitsprüfungen unterstützen. In größeren Umgebungen können zusätzlich Schwachstellenscanner, Konfigurationsmanagement und zentrale Monitoring-Systeme eingesetzt werden.

Dokumentation gehört zur technischen Maßnahme

Eine NIS-2-orientierte Server-Härtung sollte nachvollziehbar dokumentiert werden.

Dazu gehören beispielsweise:

• Servername und Funktion,
• Betriebssystem und Version,
• Verantwortlicher,
• Sicherheitsbaseline,
• installierte Dienste,
• freigegebene Ports,
• administrative Zugänge,
• Patchstatus,
• Backupstatus,
• Logging,
• Monitoring,
• Abweichungen von der Baseline.

Besonders wichtig sind begründete Ausnahmen.

Kann beispielsweise ein geschäftskritischer Server aufgrund einer inkompatiblen Anwendung vorübergehend nicht aktualisiert werden, sollte dies nicht einfach hingenommen werden.

Die Abweichung sollte dokumentiert, das daraus entstehende Risiko bewertet und durch kompensierende Maßnahmen reduziert werden.

Praktische NIS-2-Checkliste für Server

Für jeden produktiven Server sollten mindestens folgende Fragen beantwortet werden können:

System

☐ Ist das Betriebssystem noch unterstützt?

☐ Sind aktuelle Sicherheitsupdates installiert?

☐ Werden Schwachstellen regelmäßig überprüft?

☐ Sind nur notwendige Pakete, Rollen und Features installiert?

Zugriff

☐ Sind administrative Konten eindeutig zugeordnet?

☐ Wird das Least-Privilege-Prinzip angewendet?

☐ Ist MFA dort aktiviert, wo dies technisch möglich und sinnvoll ist?

☐ Sind SSH und RDP ausreichend geschützt?

☐ Sind administrative Zugriffe auf notwendige Netze beschränkt?

Netzwerk

☐ Befindet sich der Server im richtigen Netzwerksegment?

☐ Sind nur erforderliche Ports geöffnet?

☐ Werden Firewallregeln regelmäßig überprüft?

Logging und Monitoring

☐ Werden sicherheitsrelevante Ereignisse protokolliert?

☐ Werden wichtige Logs zentral gespeichert?

☐ Existieren Regeln für sicherheitsrelevante Ereignisse?

☐ Werden Alarme tatsächlich bearbeitet?

Betrieb

☐ Existiert ein funktionierendes Backup?

☐ Wird die Wiederherstellung getestet?

☐ Gibt es einen definierten Patchprozess?

☐ Ist die Sicherheitskonfiguration dokumentiert?

☐ Werden Abweichungen regelmäßig überprüft?

Server-Härtung im Sinne von NIS-2 besteht nicht darin, möglichst viele Sicherheitseinstellungen zu aktivieren.

Entscheidend ist ein systematischer und dauerhaft betriebener Sicherheitsprozess.

Linux- und Windows-Server müssen nach definierten Baselines betrieben, regelmäßig aktualisiert und überwacht werden. Administrative Zugänge über SSH oder RDP gehören besonders geschützt. Nicht benötigte Dienste sollten verschwinden, Netzwerkzugriffe auf das notwendige Minimum reduziert und sicherheitsrelevante Ereignisse zentral protokolliert werden.

Die wichtigste Erkenntnis lautet deshalb:

Ein sicherer Server ist kein Zustand, sondern ein kontinuierlicher Prozess.

Neue Schwachstellen, Updates und Konfigurationsänderungen sorgen dafür, dass eine heute sichere Konfiguration morgen bereits überprüft werden muss.

Wer NIS-2 ernsthaft umsetzen möchte, sollte deshalb nicht nur Server härten, sondern einen wiederholbaren Prozess etablieren:

Baseline definieren → härten → dokumentieren → überwachen → aktualisieren → überprüfen → verbessern.

Damit wird aus einer Sammlung technischer Einzelmaßnahmen ein belastbares Sicherheitskonzept – und genau darauf kommt es bei einer nachhaltigen NIS-2-Umsetzung an.