Server-Grundschutz: was du prüfen und tun solltest

6. November 2026

TL;DR

1. Was nicht aus dem Internet erreichbar ist, kann von dort auch niemand angreifen. Admin-Zugänge gehören in ein privates Netz, die Hoster-Firewall lässt nur durch, was wirklich öffentlich sein muss.
2. Setz bei jedem API-Anbieter ein hartes Ausgabenlimit. Das ist die wichtigste Maßnahme, wenn ein Key doch abfließt.
3. Deine Reaktionszeit sind heute Tage, nicht Wochen. Updates, Monitoring und ein Backup außerhalb des Servers sind deshalb laufende Arbeit und keine einmalige Einrichtung.

Das ist eine unverbindliche Empfehlung aus unserer Praxis, keine Beratung für deinen konkreten Server und keine Garantie. Auch wer alles umsetzt, kann angegriffen werden. Für deinen Server und jede Änderung daran bleibst du selbst verantwortlich. Prüfe also, was davon bei dir passt, und mach vorher ein Backup. Wenn Kundendaten oder Geschäftsbetrieb daran hängen, hol dir jemanden dazu, der das beurteilen kann.

Sich einen Server zu holen und darauf Agenten, n8n oder eine Datenbank zu betreiben, geht heute schnell. Das ist eine gute Sache. Nur steht so ein Server vom ersten Moment an im Internet, und sein Schutz richtet sich nicht von selbst ein.

Wir retten seit Wochen gekaperte Server, und die API-Keys darauf laufen dabei Amok. Als wir das in einer Gruppe erzählt haben, kam die Frage nach einer Anleitung. Hier ist sie.

Sie gilt für alle, die einen VPS, Root-Server oder eine Cloud-Instanz betreiben. Das ist keine vollständige Härtungsanleitung, sondern das, was wir bei SJT auf unseren Servern tun und was uns in Vorfällen immer wieder begegnet.

Die Befehle gelten für Debian und Ubuntu. Auf anderen Systemen heißen manche Pakete anders.

Die wichtigste Regel

Was nicht aus dem Internet erreichbar ist, kann von dort auch niemand angreifen.

Ein neuer Server mit öffentlicher IP wird innerhalb von Minuten gescannt. Das macht niemand gezielt gegen dich, das laufen Bots gegen den kompletten Adressraum. Sie suchen offene Dienste und bekannte Lücken. Deine beste Maßnahme ist deshalb nicht das stärkste Passwort, sondern möglichst wenig Angriffsfläche.

Stell dir bei jedem Dienst drei Fragen:

1. Muss das wirklich jemand aus dem Internet erreichen, oder nur ich?
2. Wenn nur ich: Warum hängt es dann offen im Netz?
3. Wenn alle: Wer patcht es, und wer merkt, wenn es gekapert wird?

Stufe 1: Zumachen

Admin-Zugänge weg vom Internet

SSH, Dashboards, Datenbanken, n8n, Portainer, Ollama, Open WebUI, Grafana, Agenten-Oberflächen: Das alles braucht kein Fremder. Dafür gibt es ein privates Netz zwischen deinen Geräten und dem Server. Welches Werkzeug du nimmst, ist zweitrangig. Hauptsache, du nimmst eins:

• Mesh-VPN wie NetBird oder Tailscale: am schnellsten eingerichtet, der Server braucht keinen offenen Port.
• WireGuard direkt: schlank, aber du pflegst Schlüssel und Konfiguration selbst.
• Jumphost: ein einziger, gut gepflegter Einstiegspunkt, die anderen Server nehmen SSH nur von dort an. So machen wir es bei einem Teil unserer Systeme.

Beim Mesh-VPN nicht die Standardregel „alle dürfen zu allen“ stehen lassen. Sonst kommt ein gekapertes Gerät an alles andere heran.

Firewall beim Hoster

Die meisten Hoster bieten eine Firewall vor dem Server. Sie ist der stärkste Hebel, denn sie greift, bevor der Verkehr deinen Server überhaupt erreicht, und keine Fehlkonfiguration auf dem Server hebelt sie aus.

• Eingehend ist alles zu.
• Offen sind nur 80 und 443, und nur, wenn wirklich eine öffentliche Webseite läuft.
• Die Regeln gelten auch für IPv6.

Zusätzlich auf dem Server selbst ufw oder nftables einrichten, ebenfalls mit „alles zu, dann gezielt auf“.

Vorsicht bei Docker: ufw schützt deine Container nicht

Das ist ein Klassiker. Veröffentlichte Docker-Ports laufen an ufw vorbei. Du siehst eine saubere Firewall, und die Datenbank steht trotzdem offen im Netz.

ports:
  - "5432:5432"            # offen für die ganze Welt, trotz ufw
  - "127.0.0.1:5432:5432"  # nur lokal erreichbar

• Jeder Port in deinen Compose-Dateien ist an 127.0.0.1 oder die VPN-Adresse gebunden.
• Nach außen geht nur ein Reverse Proxy auf 80 und 443 (Traefik, Caddy, nginx).
• Datenbanken, Redis und Co. haben gar keinen ports:-Eintrag und sprechen nur im internen Docker-Netz.

Bei uns sperrt auf neu aufgebauten Docker-Hosts eine eigene Regel alles außer 80 und 443, und ohne diese Sperre startet Docker gar nicht erst. Für den Anfang reicht die Hoster-Firewall.

Von außen nachprüfen

Prüfe von außen, nicht vom Server selbst, denn dort sieht alles anders aus. Scanne nur deine eigenen Server:

ss -tulpen                # auf dem Server: was lauscht?
nmap -Pn -p- <deine-IP>   # von einem anderen Rechner: was ist wirklich offen?
nmap -6 -Pn -p- <deine-IPv6>

Alles, was im Scan auftaucht und du nicht erklären kannst, wird zugemacht.

Stufe 2: Grundhärtung

SSH

• Anmeldung nur mit Schlüssel, Passwörter aus.
• Kein direkter Root-Login, stattdessen eigener Benutzer mit sudo.
• Schlüssel vom Typ ed25519, mit Passphrase oder auf einem Hardware-Key.
• authorized_keys durchgesehen: Jeder Schlüssel ist bekannt, alte sind raus.

Prüfe den tatsächlich wirksamen Wert, nicht die Datei:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|pubkeyauthentication'

Der Grund: cloud-init legt auf Ubuntu gern eine 50-cloud-init.conf mit PasswordAuthentication yes an. Die wird zuerst gelesen, und der erste Wert gewinnt. Deine sshd_config sieht dann richtig aus und wirkt nicht.

Aussperren vermeiden: Vor Änderungen an SSH oder Firewall eine zweite Sitzung offen lassen, die Änderung in einer neuen Sitzung testen und vorher wissen, wie du über die Konsole des Hosters hineinkommst.

Updates

• unattended-upgrades ist aktiv, damit Sicherheitsupdates automatisch kommen.
• Neustarts passieren auch wirklich, sonst läuft der alte Kernel weiter.
• Die Betriebssystem-Version bekommt noch Sicherheitsupdates. Prüfe das Support-Ende.
• Container-Images werden regelmäßig neu gezogen, zum Beispiel an einem festen Termin.
• Anwendungen sind mit abgedeckt: WordPress-Plugins und -Themes, n8n, alles, was nicht über apt kommt.

Automatische Updates für das System schaltest du so ein:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Für automatische Neustarts trägst du in /etc/apt/apt.conf.d/50unattended-upgrades eine Uhrzeit ein, zu der ein kurzer Ausfall nicht stört:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Container aktualisierst du am festen Termin mit docker compose pull && docker compose up -d. In WordPress lassen sich automatische Updates in den Übersichten für Plugins und Themes einschalten. Ein Update kann auch einmal etwas kaputt machen, deshalb gehört ein getestetes Backup immer dazu.

Der Punkt mit den Anwendungen ist der, an dem es in der Praxis scheitert. In einem aktuellen Fall bei uns war das Betriebssystem nicht der Einstieg, sondern ein Theme. Automatische Updates für den Kern waren an, für Plugins und Themes fast nirgends. Zwischen dem Fix und dem ersten Angriff auf den Server lagen drei Tage.

Drei Tage sind heute deine Reaktionszeit, nicht drei Wochen. Wer keine Zeit hat, das nachzuhalten, sollte den Dienst nicht öffentlich betreiben.

Dein Betriebssystem bestimmt, wann der Patch kommt

Patches kommen nicht überall gleich schnell. Bei Linux-Lücken hängst du an deiner Distribution, nicht am Kernel-Projekt. Ein aktuelles Beispiel ist CVE-2026-98432 , eine kritische Lücke im TCP-Verbindungsaufbau des Kernels (CVSS 9.8), die Codeausführung aus der Ferne ermöglichen kann.

Stand 06.11.2026:

• Debian 12 und 13: Der gefixte Kernel ist da (Debian-Tracker ). Mit aktiven automatischen Updates kommt er von allein auf den Server. Wirksam wird er aber erst nach dem Neustart.
• Ubuntu 22.04, 24.04 und 26.04: Noch kein freigegebener Kernel, der Fix ist in Arbeit. Bis dahin hilft auch unattended-upgrades nicht.
• Ubuntu 20.04: Der Standard-Support ist vorbei. Laut Tracker ist nur für einzelne Kernel-Pakete ein Fix in Arbeit, darauf solltest du dich nicht verlassen.

Bis der Patch da ist, gibt es einen Workaround: Eine nftables-Regel verwirft eingehende IPv4-TCP-Pakete mit IP-Optionen. Die Regel steht auf der Ubuntu-Seite oben. Für solche Provisorien gilt:

• Du weißt überhaupt, dass du handeln musst. Automatische Updates melden dir nicht, was noch nicht da ist. Abonniere die Sicherheitsmeldungen deiner Distribution und schau bei kritischen Lücken in ihren Tracker.
• Der Workaround überlebt den Neustart. Eine von Hand gesetzte Regel ist danach weg. Auch ein flush ruleset in der nftables.conf löscht sie, und dabei die Regeln von Docker und ufw gleich mit.
• Er greift auch für Container. Ubuntus Beispiel sitzt im Hook input. Für Docker muss die Regel vor der Weiterleitung sitzen, also im Hook prerouting. Container mit eigenem Netzwerk-Stack brauchen sie laut Ubuntu gesondert.
• Du weißt, was er nicht kann. Er senkt das Risiko, schließt die Lücke aber nicht, und er kann Verbindungen stören, die IP-Optionen brauchen.
• Der Rückbau ist eingeplant. Notier dir, wo der Workaround läuft. Sobald der Kernel da ist: einspielen, neu starten, mit uname -r prüfen, Workaround entfernen.

Hier zahlt sich auch die wichtigste Regel von oben aus: Je weniger TCP-Ports aus dem Netz erreichbar sind, desto kleiner ist die Angriffsfläche, solange du auf den Patch wartest.

uname -r                           # welcher Kernel läuft gerade?
ls /var/run/reboot-required        # wartet ein Neustart? (Ubuntu)
apt list --upgradable | grep linux # liegt ein neuer Kernel bereit?

fail2ban ist gut, aber kein Schutzschild

Installieren, ja. Bei uns gehört es zur Grundinstallation. Es sperrt IPs nach Fehlversuchen und macht die Logs ruhiger. Gegen eine Lücke in deiner Webanwendung hilft es aber gar nicht, denn der Angreifer braucht keinen einzigen Fehlversuch. Wer sich auf fail2ban verlässt und die Anwendung nicht patcht, ist nicht geschützt.

Dienste voneinander trennen

• Dienste und Agenten laufen unter eigenen Benutzern, nicht als root.
• Wer in der Gruppe docker ist, ist faktisch root. Nimm dort nur auf, wer es wirklich braucht.
• Container laufen nicht privileged, und der Docker-Socket wird nicht in Container gemountet, wenn es nicht sein muss.
• Nicht Benötigtes wird entfernt, auch alte Testinstallationen.

Testseiten sind ein beliebter Einstieg: vergessen, nie gepatcht, oft mit einer Kopie echter Kundendaten. Wenn alle Seiten unter einem Benutzer laufen, kommt der Angreifer über eine vergessene Testseite an die Zugangsdaten aller anderen. Testumgebungen gehören hinter ein VPN oder mindestens hinter Basic Auth, und echte Daten haben dort nichts zu suchen.

Stufe 3: API-Keys und Agenten

Hier wird es teuer. Ein gekaperter Server ist ärgerlich, ein gekaperter Server mit API-Keys kostet richtig Geld, und zwar schneller, als du es merkst.

• Beim Anbieter ist ein hartes Ausgabenlimit gesetzt, mit Warnung vorher. Das ist die wichtigste Maßnahme, wenn ein Key doch abfließt.
• Die Konten beim Hoster und bei den API-Anbietern nutzen die Zwei-Faktor-Anmeldung.
• Jeder Server und jede Anwendung hat einen eigenen Key. Dann siehst du, welcher missbraucht wird, und musst nur den sperren.
• Keys haben nur die Rechte, die sie brauchen, nie den Admin-Key auf dem Server.
• Keine Keys in Git, auch nicht in privaten Repos. .env steht in .gitignore und hat die Rechte 600.
• Du führst eine Liste, welche Keys auf welchem Server liegen. Im Ernstfall brauchst du genau die.

Für Agenten auf dem Server gilt zusätzlich:

• Ein Agent darf nicht mehr als ein neuer Praktikant: eigener Benutzer, kein root, kein Zugriff auf alles.
• Agenten lesen fremde Inhalte wie Webseiten, Mails und Tickets. Darin können Anweisungen stecken. Ein Agent mit Shell, Secrets und Internetzugang ist deshalb ein Risiko, auch wenn der Server selbst sauber ist.
• Berechtigungsabfragen abzuschalten ist auf einem Server mit echten Schlüsseln und Daten keine gute Idee.

Stufe 4: Merken, wenn etwas passiert

Viele erfahren vom Einbruch erst über die Abuse-Mail des Hosters oder die Rechnung. Das geht besser:

• Monitoring für Last, Platte, Dienste und ausgehenden Verkehr. Plötzliche Dauerlast ist oft ein Krypto-Miner.
• Die Kontaktadresse beim Hoster ist echt und wird gelesen. Wer auf Abuse-Mails nicht reagiert, riskiert die Sperre des Servers.
• Logs liegen zusätzlich außerhalb des Servers, sonst löscht sie der Angreifer. Bewahre sie lange genug auf und protokolliere genug: In einem Fall fehlten uns genau die Protokolle, mit denen sich hätte klären lassen, ob Daten abgeflossen sind.
• Nach jedem Notfall-Patch nachsehen, ob jemand vorher schon drin war. Genau so haben wir einen Einbruch gefunden, von dem niemand etwas wusste.

Wir setzen dafür Checkmk für das Monitoring und Wazuh als SIEM ein. Für einen einzelnen Server reicht deutlich weniger, aber gar nichts reicht nicht.

Erste Schnellprüfung:

last -a | head -20                          # wer war zuletzt angemeldet?
sudo cat /root/.ssh/authorized_keys         # fremde Schlüssel? Auch bei allen anderen Benutzern ansehen
sudo crontab -l; ls -la /etc/cron.*         # fremde Cronjobs?
systemctl list-units --type=service --state=running
ps auxf --sort=-%cpu | head -20             # was frisst CPU?
ss -tnp state established                   # wohin bestehen Verbindungen?

Das findet Grobes. Ein leeres Ergebnis heißt nicht, dass der Server sauber ist.

Stufe 5: Backup

• Backup liegt woanders: anderer Anbieter oder anderes Konto.
• Der Server kann sein eigenes Backup nicht löschen oder überschreiben. Bewährt sind unveränderliche Sicherungen (Immutability).
• Du hast die Wiederherstellung schon einmal getestet.
• Du kannst den Server aus Backup und Doku neu aufbauen, und du weißt, wie lange das dauert.

Ein Snapshot beim selben Hoster ist kein Backup im Ernstfall. Ein Backup-Ziel, das der Server dauerhaft als Netzlaufwerk eingebunden hat, auch nicht, siehe Die Freigabe, die jeder löschen darf . Wir haben kürzlich einen Ransomware-Fall begleitet, bei dem die SMB-Ablagen des Backup-Servers mitverschlüsselt wurden, auch der Speicher in der Cloud.

So automatisieren wir das

Nichts davon hält, wenn es jemand von Hand erledigen muss. Deshalb automatisieren wir, soweit es vertretbar ist, und entscheiden bewusst, was beim Menschen bleibt.

Was bei uns automatisch läuft:

• Betriebssystem: Automatische Updates und Neustarts richten wir per Ansible ein. Ausnahmen gibt es dort, wo ein Neustart nicht einfach so passieren darf, etwa auf Backup-Repositories. Wartungstermine werden automatisch als Ticket angelegt.
• Container: Eine Watchtower-Variante aktualisiert nachts, je Server in einem eigenen Zeitfenster. Auf den meisten Servern nur freigegebene Container. Das braucht Zugriff auf den Docker-Socket, ein Kompromiss, den wir bewusst eingehen.
• Reifezeit: Neue Images ziehen wir erst nach drei Tagen, damit kaputte Releases nicht sofort landen.
• Sicherung davor: Vor dem Fenster entsteht ein Dump je Dienst mit Daten. Das Skript prüft den Inhalt, nicht nur, ob die Datei existiert.
• Wächter danach: Ein Skript prüft nach dem Fenster, ob der Lauf wirklich fertig wurde. Ein abgebrochener Lauf schreibt nämlich keinen Bericht und damit auch keine Fehlermail.
• Neue Versionen: Für alles ohne Automatik meldet Diun neue Images als Ticket. Jeder Container hat genau einen Zuständigen: Entweder die Automatik handelt oder ein Mensch bekommt das Ticket.
• Erreichbarkeit und Erkennung: Uptime Kuma prüft je Dienst den erwarteten Statuscode, Wazuh überwacht auf den Linux-Hosts unter anderem Dateiänderungen.

Was bewusst beim Menschen bleibt:

• Kritische Lücken. Drei Tage Reifezeit wären hier zu lang, also gehen wir von Hand daran vorbei. Workarounds rollen wir per Playbook aus, gestartet wird es von einem Menschen.
• Die Frage, ob uns eine Lücke betrifft. Diun kennt Versionen, keine Sicherheitslücken. Von neuen Lücken erfahren wir nicht automatisch.
• Hauptversionen und Updates ohne Rückweg, zum Beispiel große Datenbank-Sprünge.
• Löschen, Kundenkommunikation und Entscheidungen im Vorfall. Eine automatische Reaktion auf Alarme gibt es bei uns nicht.

Was Automatik nicht abdeckt: Container-Updates heben keine WordPress-Plugins oder -Themes, darum braucht es dort eine eigene Lösung. Und ein grüner Container heißt nicht, dass die Anwendung funktioniert. Das hatten wir mehrfach.

Für deinen einzelnen Server reicht eine kleine Version davon:

• unattended-upgrades mit automatischem Neustart in einem festen Zeitfenster.
• Geplantes Compose-Update mit etwas Reifezeit. Images auf eine Versionslinie festlegen statt auf latest, und vorher prüfen, ob das Tag noch gepflegt wird.
• Dump vor dem Update-Fenster.
• Ein Cron-Skript pingt nach dem Lauf einen Push-Monitor. Bleibt der Ping aus, kommt ein Alarm. So merkst du auch einen Lauf, der gar nicht erst berichtet hat.
• Ein Monitor von außen prüft den echten Statuscode, nicht den Container-Status.
• Sicherheitsmeldungen deiner Distribution und deiner Anwendungen sind abonniert. Das ersetzt keine Automatik.

Wenn es passiert ist

1. Nicht „schnell aufräumen“ und nicht sofort löschen. Server vom Netz nehmen oder über die Hoster-Firewall abriegeln. Falls möglich, vorher Snapshot und Logs sichern.
2. Alle Geheimnisse tauschen, die jemals auf dem Server lagen: API-Keys, Datenbank-Passwörter, SSH-Schlüssel, Tokens. Das geht von einem sauberen Gerät aus, und zwar zuerst, weil hier gerade Geld verbrennt.
3. Neu aufsetzen statt reinigen. Du findest nie mit Sicherheit alles. Baue neu auf, spiele nur Daten aus einem Backup von vor dem Einbruch zurück, und schließe zuerst die Lücke, durch die der Angreifer kam.
4. Einstieg klären. Sonst bist du nach einer Woche wieder an derselben Stelle.
5. Meldepflicht prüfen. Siehe nächster Abschnitt.

Deine Pflichten als Betreiber

Das ist keine Rechtsberatung, aber das solltest du kennen:

• Wer einen Server betreibt, ist dafür verantwortlich. Der Hoster stellt nur die Maschine, Betriebssystem und Dienste sind deine Sache. Greift dein Server andere an, bekommst du den Ärger.
• Sobald dort personenbezogene Daten liegen, und das sind schon Kunden-E-Mail-Adressen, gilt die DSGVO: angemessene technische Schutzmaßnahmen (Art. 32), Vertrag zur Auftragsverarbeitung mit dem Hoster (Art. 28).
• Bei einem Datenschutzvorfall läuft die Meldefrist an die Aufsichtsbehörde: 72 Stunden, sobald du davon weißt (Art. 33), außer es besteht voraussichtlich kein Risiko für die Betroffenen. Bei hohem Risiko musst du auch die Betroffenen informieren (Art. 34).
• Betreibst du den Server für Kunden, bist du selbst Auftragsverarbeiter. Dann brauchst du AVV und klare Absprachen, wer im Ernstfall was tut.

Audit mit Claude Code oder einem anderen Agenten

Das funktioniert gut und nimmt dir bei den meisten Punkten die Handarbeit ab. Wichtig ist: erst lesen, dann berichten, ändern nur nach deinem OK.

Mach ein Sicherheits-Audit dieses Servers. Nur lesen, ändere nichts.
Gib keine Inhalte von .env-Dateien, Schlüsseln oder Passwörtern aus,
nenne nur Fundort und Dateirechte.

Prüfe:
1. Welche Dienste lauschen, und welche sind von außen erreichbar (IPv4 und IPv6)?
2. Docker: Welche Ports sind veröffentlicht und an welche Adresse gebunden? Beachte,
   dass veröffentlichte Ports ufw umgehen. Gibt es privileged-Container oder
   gemountete Docker-Sockets?
3. SSH: wirksame Werte per sshd -T, authorized_keys aller Benutzer.
4. Benutzer, sudo-Rechte, Mitglieder der Gruppe docker.
5. Updates: offene Pakete, Support-Ende des Systems, unattended-upgrades,
   Stand von Anwendungen und Container-Images.
6. Hinweise auf Kompromittierung: Logins, Cronjobs, Timer, fremde Prozesse,
   ausgehende Verbindungen, neue Dateien in Webverzeichnissen.
7. Wo liegen Geheimnisse, und wer darf sie lesen?
8. Backup: Gibt es eins, und könnte dieser Server es löschen?

Liefere eine Liste nach Schwere: Befund, Risiko, Vorschlag. Mach danach nichts weiter.

Vier Dinge, die du dabei wissen solltest:

• Der Agent sieht, was er liest. Inhalte gehen an den Modellanbieter. Secrets also nicht ausgeben lassen, und nach dem Audit den Zugang wieder entfernen.
• Er ist nur so gut wie das, was er von innen sieht. Die Hoster-Firewall, deine Key-Limits und das, was von außen wirklich offen ist, musst du selbst prüfen. Deshalb gehört der nmap von außen dazu.
• Das Wissen eines Modells endet am Trainingsstand. Eine Lücke von letzter Woche kennt es nicht, wenn es nicht nachschlägt. Den aktuellen Stand holst du dir aus dem Tracker deiner Distribution.
• Ein Audit ist eine Momentaufnahme. Die Lücke von morgen findet es heute nicht. Sicherheit entsteht durch den laufenden Betrieb: patchen, beobachten, Backups testen. Das ist die eigentliche Arbeit.

KI ist dabei ein Werkzeug, sie übernimmt nicht deine Verantwortung. Als grobe Regel: Was du ohne KI nicht betreuen kannst, solltest du nicht betreiben, zumindest nicht, wenn Dritte davon betroffen sind. Das gilt besonders für Webseiten und Anwendungen, die du für Kunden baust oder verkaufst.

Die Kurzliste

Wenn du heute nur wenig Zeit hast, dann in dieser Reihenfolge:

1. Hoster-Firewall: alles zu außer dem, was wirklich öffentlich sein muss.
2. Ausgabenlimits bei allen API-Anbietern setzen.
3. Docker-Ports prüfen und auf 127.0.0.1 binden.
4. nmap von außen laufen lassen.
5. SSH nur mit Schlüssel und ohne Root, Prüfung mit sshd -T.
6. unattended-upgrades einschalten.
7. Backup an einem anderen Ort einrichten und einmal wiederherstellen.

Best Practices nachlesen: der BSI-Grundschutz

Nichts davon haben wir erfunden. Das meiste sind bewährte Best Practices, und vieles davon findest du auch im IT-Grundschutz-Kompendium des BSI. Es ist für Organisationen geschrieben und viel umfangreicher als diese Liste. Zum Nachschlagen taugt es aber auch bei einem einzelnen Server:

Die Nummern gelten für die Edition 2023, daneben gibt es seit Anfang 2026 den Nachfolger Grundschutz++. Wie wir den Grundschutz bei einer kleinen IT-Abteilung als Zielbild nutzen, steht in Grundschutz, bevor man muss .

Du hängst an einem Punkt fest oder hast eine Frage dazu? Schreib uns gern .

Sven-Jendrik Timmermann, SJT SOLUTIONS, Stand 11/2026