Was ist auf den meisten Linux-Servern standardmäßig deaktiviert (und warum es wichtig ist)

Wenn Sie einen neuen Linux-Server bereitstellen — ob es sich um einen VPS, einen dedizierten Server oder eine Cloud-gehostete virtuelle Maschine handelt — startet das System in einer absichtlich minimalistischen und gehärteten Umgebung. Dies ist kein Versehen oder eine unvollständige Einrichtung. Es ist eine bewusste Designphilosophie, die in jeder großen Linux-Distribution verankert ist.

Moderne Linux-Server-Builds entfernen unnötige Dienste, Protokolle und Schnittstellen, um die Angriffsfläche zu minimieren, Systemressourcen zu sparen und Administratoren präzise Kontrolle darüber zu geben, was auf ihrer Infrastruktur läuft. Zu verstehen, was standardmäßig deaktiviert ist — und warum — ist grundlegendes Wissen für jeden Systemadministrator, DevOps-Ingenieur oder Entwickler, der Produktions-Workloads verwaltet.

Dieser Leitfaden analysiert die häufigsten Funktionen und Dienste, die auf Linux-Servern standardmäßig deaktiviert oder nicht vorhanden sind, erklärt die Sicherheits- und Betriebsgründe hinter jeder Entscheidung und zeigt Ihnen genau, wie Sie jede Einstellung auf Ihrem eigenen System überprüfen.

Warum „Standardmäßig deaktiviert” eine Sicherheitsstrategie ist, keine Einschränkung

Das hier angewendete Prinzip wird oft als „Sicher standardmäßig, erweiterbar nach Wahl” bezeichnet. Anstatt ein vollständig ausgestattetes System auszuliefern und Administratoren zu vertrauen, es zu sperren, liefern moderne Linux-Distributionen ein gesperrtes System aus und vertrauen Administratoren darauf, nur das zu aktivieren, was sie benötigen.

Dieser Ansatz reduziert direkt das Risiko von Fehlkonfigurationen — einer der Hauptursachen für Server-Verstöße. Jeder Dienst, der nicht läuft, ist ein Dienst, der nicht ausgenutzt werden kann. Jedes Protokoll, das nicht aktiviert ist, ist ein Protokoll, das nicht abgefangen werden kann. Jeder offene Port, der nicht existiert, ist ein Einstiegspunkt, den Angreifer nicht sondieren können.

Mit diesem Kontext wollen wir jede Standardbeschränkung im Detail untersuchen.

1. Root SSH-Anmeldung

Status: Auf praktisch allen modernen Linux-Server-Distributionen standardmäßig deaktiviert

Die direkte Root-Anmeldung über SSH ist in zeitgenössischen Linux-Server-Builds universell deaktiviert — und aus ausgezeichnetem Grund. Das Zulassen von Remote-Root-Zugriff schafft einen einzigen katastrophalen Fehlerpunkt: Ein kompromittiertes Passwort gibt einem Angreifer vollständige, uneingeschränkte Kontrolle über das gesamte System.

Der korrekte Workflow besteht darin, sich als Benutzer ohne Privilegien anzumelden und Privilegien nur bei Bedarf mit sudo oder su zu erhöhen. Dies erstellt einen Audit-Trail, begrenzt den Blast-Radius von Credential-Diebstahl und erzwingt bewusste Maßnahmen vor der Ausführung privilegierter Befehle.

So überprüfen Sie:

Erwartete Ausgabe auf einem ordnungsgemäß gehärteten Server:

Wenn Sie „yes” oder „without-password” sehen, überprüfen Sie Ihre SSH-Konfiguration sofort und stimmen Sie sie mit der Sicherheitsrichtlinie Ihrer Organisation ab.

Best Practice:

Erstellen Sie einen dedizierten Administratorbenutzer, fügen Sie ihn zur sudo-Gruppe hinzu, und stellen Sie sicher, dass PermitRootLogin no gesetzt ist, bevor Sie einen öffentlich zugänglichen Dienst bereitstellen.

2. Passwortauthentifizierung in SSH

Status: Auf den meisten Cloud-bereitgestellten Servern standardmäßig deaktiviert

Auf vielen Cloud-Plattformen und verwalteten Hosting-Umgebungen ist die SSH-Passwortauthentifizierung zum Zeitpunkt der Bereitstellung vollständig deaktiviert. SSH-Schlüsselpaare sind der einzige akzeptierte Authentifizierungsmechanismus.

Dies ist eine erhebliche Sicherheitsverbesserung. Die Passwortauthentifizierung ist anfällig für Brute-Force-Angriffe, Credential-Stuffing und Dictionary-Angriffe. SSH-Schlüssel — besonders wenn sie durch eine Passphrase geschützt sind — sind rechnerisch unmöglich, mit aktueller Technologie Brute-Force-Angriffen auszusetzen.

Traditionelle ISO-basierte Installationen können standardmäßig immer noch Passwort-Anmeldungen zulassen, aber die Best Practice besteht darin, sie sofort nach der Einrichtung der schlüsselgestützten Authentifizierung zu deaktivieren.

So überprüfen Sie:

Erwartete Ausgabe:

So deaktivieren Sie die Passwortauthentifizierung:

Bearbeiten Sie /etc/ssh/sshd_config und setzen Sie:

Laden Sie dann den SSH-Daemon neu:

> Warnung: Bestätigen Sie immer, dass Ihr SSH-Schlüssel funktioniert, bevor Sie die Passwortauthentifizierung deaktivieren, sonst riskieren Sie, sich selbst aus dem Server auszusperren.

3. Legacy- und Cleartext-Netzwerkprotokolle

Status: Nicht in modernen Server-Builds vorhanden

Dienste wie Telnet, FTP, Rlogin und Rsh sind nicht auf modernen Linux-Server-Images installiert. Diese Protokolle wurden in einer Zeit entworfen, bevor Verschlüsselung eine Priorität war. Sie übertragen Anmeldedaten, Befehle und Daten im Klartext — was sie trivial einfach zu abfangen mit einem Packet Sniffer auf jedem Netzwerksegment zwischen Client und Server macht.

Diese Protokolle wurden durch sichere Alternativen ersetzt:

So überprüfen Sie, dass keine Legacy-Dienste ausgeführt werden:

Wenn die Ports 21 (FTP) oder 23 (Telnet) nicht in der Ausgabe angezeigt werden, sind diese Dienste nicht aktiv. Wenn sie angezeigt werden, untersuchen Sie sofort und entfernen oder deaktivieren Sie sie, es sei denn, es gibt eine spezifische, begründete Anforderung.

4. Grafische Benutzeroberflächen (GUI)

Status: Nicht auf Server-Editionen installiert

Server-Distributionen — einschließlich Ubuntu Server, Debian, AlmaLinux, Rocky Linux und CentOS Stream — werden nicht mit grafischen Desktop-Umgebungen wie GNOME, KDE Plasma oder XFCE ausgeliefert. Dies ist eine bewusste und gut begründete Wahl.

Eine GUI-Umgebung:

• Verbraucht erhebliche RAM- und CPU-Ressourcen, die Workloads gewidmet sein sollten
• Führt eine große Anzahl zusätzlicher Softwarepakete ein, von denen jedes eine potenzielle Sicherheitslücke darstellt
• Ist völlig unnötig für die Serververwaltung, die über die Befehlszeile über SSH durchgeführt wird

Die Erwartung ist eindeutig: Server werden über die CLI verwaltet. Wenn Sie sich auf einem Produktionsserver eine grafische Schnittstelle wünschen, ist dies im Allgemeinen ein Signal dafür, dass ein Prozess oder Workflow überdacht werden muss.

> Hinweis: Tools wie VPS Control Panels — wie cPanel, Plesk oder DirectAdmin — bieten webbasierte grafische Verwaltungsschnittstellen, ohne dass eine vollständige Desktop-Umgebung auf dem Server installiert werden muss.

5. Entwicklungs-Toolchains und Compiler

Status: Nicht in minimalen Server-Images installiert

Compiler wie GCC und Build-Utilities wie make, autoconf und automake sind absichtlich aus den meisten minimalen Linux-Server-Images ausgeschlossen. Die Begründung ist zweifach:

1. Reduzierte Image-Größe: Minimale Images werden schneller bereitgestellt, sind einfacher zu sichern und verbrauchen weniger Ressourcen.
2. Sicherheitshärtung: Wenn ein Angreifer Zugriff auf einen Server erhält, verhindert das Fehlen eines Compilers, dass er bösartige Binärdateien oder Exploit-Code direkt auf dem System kompiliert. Dies ist ein sinnvolles Hindernis in vielen Angriffsketten.

So überprüfen Sie:

Wenn die Toolchain nicht installiert ist, sehen Sie:

So installieren Sie bei Bedarf:

Installieren Sie Entwicklungstools nur auf Servern, auf denen Kompilierung eine echte Betriebsanforderung ist — wie Build-Server oder Entwicklungsumgebungen — und vermeiden Sie die Installation auf Produktionsanwendungs- oder Datenbankservern.

6. ICMP (Ping-Antworten)

Status: Auf OS-Ebene standardmäßig aktiviert; oft auf Netzwerk-/Firewall-Ebene eingeschränkt

Linux-Server reagieren standardmäßig auf ICMP-Echo-Anfragen (Ping) auf der Betriebssystemebene. Viele Hosting-Provider und Cloud-Plattformen blockieren ICMP jedoch auf der Netzwerk-Firewall- oder Sicherheitsgruppenebene, wodurch Server unerreichbar für Ping erscheinen, auch wenn sie vollständig funktionsfähig sind.

Das Unterdrücken von ICMP-Antworten macht einen Server während Netzwerk-Reconnaissance-Scans weniger auffindbar. Es erschwert jedoch auch legitime Überwachung und Diagnose — Tools wie ping und traceroute verlassen sich auf ICMP, um ordnungsgemäß zu funktionieren.

So testen Sie:

So blockieren Sie ICMP auf OS-Ebene mit iptables (falls erforderlich):

Die Entscheidung, ICMP zu blockieren, sollte bewusst getroffen werden und den marginalen Sicherheitsvorteil gegen die Betriebskosten für Überwachungs- und Troubleshooting-Workflows abwägen.

7. IPv6

Status: In den meisten Distributionen standardmäßig aktiviert; kann auf Provider-Ebene eingeschränkt sein

IPv6 ist standardmäßig in modernen Linux-Distributionen einschließlich Ubuntu, Debian, Fedora und RHEL-Derivaten aktiviert. Viele Hosting-Provider deaktivieren IPv6 jedoch auf Netzwerkebene, wenn ihre Infrastruktur es nicht unterstützt, was bedeutet, dass das Betriebssystem für IPv6 konfiguriert sein kann, der Server aber keine routbare IPv6-Adresse hat.

So überprüfen Sie auf IPv6-Adressen:

Wenn nur ::1 (die Loopback-Adresse) angezeigt wird, ist IPv6 nicht auf Netzwerkebene konfiguriert, auch wenn es im Betriebssystem aktiviert ist.

Wenn Ihre Workload IPv6 nicht erfordert und Ihr Provider es nicht anbietet, können Sie es auf Kernel-Ebene deaktivieren, indem Sie Folgendes zu /etc/sysctl.conf hinzufügen:

Wenden Sie dann die Änderung an:

8. Unnötige Systemdienste und Daemons

Status: Variiert je nach Distribution; minimale Installationen deaktivieren die meisten nicht wesentlichen Dienste

Über die oben aufgeführten Elemente hinaus deaktivieren oder weglassen minimale Linux-Server-Installationen typischerweise eine Reihe von Diensten, die auf Desktop- oder vollständig ausgestatteten Builds vorhanden sind:

• Bluetooth — irrelevant auf Servern; nicht installiert
• Avahi/mDNS — lokale Netzwerkerkennung; unnötig und möglicherweise ein Sicherheitsrisiko auf Servern
• Cups (Drucken) — kein Anwendungsfall auf einem Server
• ModemManager — irrelevant auf Server-Hardware
• NetworkManager — oft ersetzt durch systemd-networkd oder manuelle /etc/network/interfaces-Konfiguration auf Servern

So überprüfen Sie laufende Dienste:

Überprüfen Sie diese Liste regelmäßig und deaktivieren Sie jeden Dienst, der keinen dokumentierten Zweck auf diesem spezifischen Server erfüllt.

Praktische Sicherheitscheckliste für einen neu bereitgestellten Linux-Server

Nach der Bereitstellung eines neuen Servers — ob es sich um Shared Web Hosting auf einen VPS aktualisiert oder einen brandneuen dedizierten Server handelt — führen Sie diese Checkliste durch, um Ihre Baseline-Sicherheitslage zu bestätigen:

Wahl der richtigen Hosting-Umgebung für Ihre Sicherheitsanforderungen

Die standardmäßige Sicherheitslage Ihres Servers wird auch durch die Hosting-Umgebung beeinflusst, die Sie wählen. Ein VPS mit cPanel bietet eine verwaltete, webbasierte Schnittstelle, die die Verwaltung vereinfacht und gleichzeitig das zugrunde liegende Linux-Sicherheitsmodell bewahrt. Ein Bare-Metal-dedizierter Server gibt Ihnen vollständige Kontrolle über jede Schicht des Stacks, von der Firmware bis zur Anwendung.

Für Teams, die SSL-gesicherte Webanwendungen ausführen, ist die Kopplung Ihres Servers mit einem ordnungsgemäß konfigurierten SSL-Zertifikat eine wesentliche Ergänzung zur Härtung auf Serverebene — Verschlüsselung von Daten während der Übertragung, genau wie SSH-Schlüssel-Authentifizierung den Zugriff auf den Server selbst schützt.