Zurück zum Blog/

Ihren VPS absichern: 7 Sicherheitsmaßnahmen, die jeder Server haben sollte

Eine praktische Checkliste für einen frischen VPS: SSH-Key-Authentifizierung, Firewall, automatische Sicherheitsupdates und Überwachung - die Basis, die wir auf jedem EGYmass-Server anwenden.

Die sieben Sicherheitsmaßnahmen, die jeder VPS haben sollte, sind: SSH-Key-Authentifizierung, eine Host-Firewall, automatische Sicherheitsupdates, ein Brute-Force-Schutz nach Art von fail2ban, TLS überall, täglich automatisierte Backups und ein Monitoring, das Sie alarmiert, wenn etwas nicht stimmt.

1. SSH-Key-Authentifizierung

Passwort-Logins sind der am häufigsten angegriffene Dienst im Internet. Deaktivieren Sie Passwort-Authentifizierung und Root-Login über SSH und verlangen Sie einen Key - idealerweise einen ed25519-Key mit Passphrase, erzeugt mit ssh-keygen und über ssh-copy-id auf den Server kopiert. Die Regel, die Sie vor dem versehentlichen Aussperren bewahrt: Lassen Sie Ihre bestehende Sitzung offen, ändern Sie in der sshd_config PasswordAuthentication auf no und PermitRootLogin auf prohibit-password, und verbinden Sie sich dann von einem zweiten Terminal aus, um zu bestätigen, dass der Key noch funktioniert. Erst dann dürfen Sie die erste Sitzung schließen. Behandeln Sie den Key schließlich wie einen Hausschlüssel: einen auf Ihrem Laptop, ein Offline-Backup und einen dokumentierten Wiederherstellungsweg - denn ein verlorener Key ohne Plan B bedeutet ein Support-Ticket und eine erzwungene Neuinstallation.

2. Eine Host-Firewall

Öffnen Sie nur die Ports, die ein Dienst tatsächlich benötigt - typischerweise SSH, HTTP und HTTPS - und verweigern Sie standardmäßig alles andere: jedes eingehende Paket wird abgewiesen, wenn es nicht ausdrücklich erlaubt ist, ausgehender Verkehr ist erlaubt. Wenden Sie dieselben Regeln auf IPv6 an - das ist kein Nebenaspekt: Ein Server, der nur IPv4 filtert, bleibt über seinen zweiten Stack voll erreichbar. Machen Sie die Regeln persistent, damit ein Neustart den Server nicht komplett offen zurücklässt. Die klassische Falle ist, eine Firewall zu aktivieren, ohne den SSH-Port freizugeben, über den man gerade verbunden ist: Beim nächsten gesperrten Paket sind Sie draußen, genau wie beim Verlust des Keys - also geben Sie diesen Port zuerst frei und prüfen Sie aus einer zweiten Sitzung, bevor Sie speichern.

3. Automatische Sicherheitsupdates

Aktivieren Sie unbeaufsichtigte Upgrades für Sicherheits-Patches, damit eine CVE innerhalb von Stunden statt Wochen behoben wird. Die Updates auf Paketebene sind diejenigen, die nie auf einen Menschen warten dürfen; der einzige Teil, der bewusst eingeplant werden sollte, ist ein Kernel-Update, das einen Neustart erfordert, um wirksam zu werden - wählen Sie ein Wartungsfenster oder nutzen Sie Live-Patching, wenn die Distribution es unterstützt. Zwei Gewohnheiten machen automatische Updates sicher statt beängstigend: Lesen Sie das Update-Protokoll regelmäßig, damit stille Fehler sichtbar werden, statt sich anzusammeln, und behalten Sie gepinnte oder zurückgehaltene Pakete im Blick, denn ein gepinntes verwundbares Paket repariert sich nicht von selbst. Eine Woche zu spät angewandte Sicherheitsupdates sind der Weg, wie kleine Server zu Teilen großer Botnets werden.

4. Schutz gegen Brute-Force-Angriffe

Bots attackieren SSH und Login-Seiten rund um die Uhr. Mit SSH nur per Key ist das Ausprobieren am SSH-Port bereits eine Sackgasse - und genau deshalb sind die Bots zu den noch offenen Flächen übergegangen: Web-Logins, Admin-Panels, Mail. Setzen Sie ein Tool wie fail2ban oder einen vergleichbaren Ratenbegrenzer ein, das wiederholte Fehlversuche lang genug sperrt, um Erraten unwirtschaftlich zu machen, und lassen Sie es die Firewall speisen, damit Sperren echte Regeln werden statt nur Protokollzeilen. Ergänzen Sie Ratenlimiting und eine WAF vor Ihren Web-Anwendungen, um bösartige Anfragen zu filtern, bevor sie Ihren Code erreichen. Messen Sie es einmal im Monat: Wenn eine einzige IP gestern Tausende fehlgeschlagene Logins produziert hat, macht der Wächter seinen Job.

5. TLS überall

Beenden Sie TLS 1.3 vor Ihren Diensten - mindestens 1.2, niemals etwas Älteres - mit starken modernen Cipher-Suites, und leiten Sie jede HTTP-Anfrage auf HTTPS um, damit eine falsch getippte URL keine Zugangsdaten ans Netzwerk ausgibt. Fügen Sie HSTS hinzu, sobald die Umleitung eine Weile läuft, und sie stoppt den Downgrade beim ersten Besuch vollständig. Verwalten Sie Zertifikate mit einem automatisierten ACME-Client, mit täglicher Erneuerungsprüfung und exportiertem Ablaufdatum ins Monitoring: Ein Zertifikat, das sich lautlos erneuert, kann auch lautlos scheitern, und ein abgelaufenes Zertifikat ist der einzige Ausfall, den Besucher vor all Ihren Dashboards sehen. Erneuerung sollte nie eine Kalender-Erinnerung sein, die sich eines Tages still in einen Vorfall verwandelt.

6. Täglich automatisierte Backups

Ein Backup, das Sie nie wiederhergestellt haben, ist kein Backup - es ist eine Hoffnung. Automatisieren Sie tägliche Snapshots von dem, was den Dienst wirklich wieder aufbaut: Datenbank-Exports, Konfigurationsdateien und Nutzerdaten, nicht nur die ganze Festplatte. Bewahren Sie Kopien außerhalb des Servers und idealerweise außerhalb des Standorts auf - das ist der Unterschied zwischen einem Hardware-Ausfall und einem schlechten Morgen - und legen Sie eine Aufbewahrungsrichtlinie fest, damit alte Backups sich selbst bereinigen, statt die Festplatte zu füllen, die Sie in Schritt sieben überwachen. Verschlüsseln Sie alles, was den Server verlässt. Und beweisen Sie es: Einmal pro Quartal stellen Sie in einer Testumgebung wieder her und bestätigen, dass der Dienst wirklich zurückkommt - denn ein still beschädigtes Backup wird genau an dem Tag versagen, an dem Sie es brauchen, und das ist der falsche Tag, um das zu lernen.

7. Monitoring und Alarmierung

Sie können nicht auf einen Vorfall reagieren, von dem Sie nie erfahren. Überwachen Sie Festplatte, Arbeitsspeicher, CPU und den Zustand jedes Dienstes, und alarmieren Sie auf den Trend statt auf den binären Zustand: Eine Festplatte bei 85 Prozent mit wachsender Tendenz ist ein Alarm, eine Festplatte, die ein Jahr lang bei 85 Prozent steht, ist keiner. Nehmen Sie das auf, was still ausfällt - Zertifikatsablauf, Backup-Jobs, die stehen geblieben sind, stark steigende fehlgeschlagene Logins, Sicherheitsupdates, die nicht mehr eingespielt werden - denn das sind die Vorfälle, die Sie andernfalls per Kunden-E-Mail entdecken. Leiten Sie Alarme in einen Kanal, den jemand wirklich liest, mit einer Eskalationsregel für Nächte und Wochenenden. Das Ziel ist, zu erfahren, dass eine Festplatte fast voll ist, bevor sie die Datenbank mit sich reißt.

VPSSicherheitDevOps

Häufig gestellte Fragen

In welcher Reihenfolge sollte ich diese Schritte anwenden?

SSH-Keys und Firewall zuerst - sie sind am günstigsten und stoppen die häufigsten Angriffe -, dann automatische Updates, dann fail2ban. TLS, Backups und Monitoring können folgen, sollten aber auf einem internetzugänglichen Server nicht länger als eine Woche auf sich warten lassen.

Reicht das für den Produktivbetrieb?

Es ist die Basis. Der Produktivbetrieb braucht zusätzlich eine WAF/IDS-Schicht davor, eine getestete Wiederherstellungsprozedur, isolierte Umgebungen und eine Zugriffsrichtlinie. Diese sieben Schritte bringen einen Server vom Standard-verwundbar zu solid.

Wenden Sie das auf Ihre eigenen Server an?

Ja - das ist genau die Basis, die wir auf jedem EGYmass-Server anwenden, und der Stack hinter unserem VPS-Setup-Service. Dieselbe Automatisierung und dasselbe Monitoring halten auch unsere eigenen Produkte online.

Möchten Sie, dass wir das für Sie einrichten?

EGYmass übernimmt Hosting, Sicherheit und laufende Verwaltung - damit Sie sich auf Ihr Produkt konzentrieren können.

Kostenlose Beratung