SOP Übersicht und Anhänge

SOP-Metadaten

SOP-Nummer: SOP1011
Priorität: Prio 2
Dauer: 30 Minuten
Status: Aktuell

Download:

Beschreibung der Aufgabe / des Problems

Einen Debian Server absichern, um ihn sicher auch erreichbar im Internet betreiben zu können.

Ziel / Endergebnis

Abgesicherter Webserver, auf den man mit einem Sicherheitsschlüssel per SSH und einem Salt Passwort zugreift.

1. Benutzer adm_andre anlegen
2. sudo Rechte geben
3. SSH-Key-Login für adm_andre einrichten
4. Login mit Key testen
5. Erst dann Passwort-Login per SSH deaktivieren
6. Root-Login per SSH deaktivieren
7. UFW einrichten
8. Fail2Ban einrichten
9. Automatische Sicherheitsupdates aktivieren
10. Alles testen

Voraussetzungen

Admin Rechte und Root Rechte.

Video-Anleitung

Text-Anleitung

1. Benutzer anlegen

adduser username

#Beispiel
adduser adm_andre

Mit diesem Befehl wird der neue Benutzer adm_andre angelegt. Dabei vergibst du ein Passwort und kannst optionale Informationen wie den vollständigen Namen eintragen.

Benutzer zur sudo-Gruppe hinzufügen

usermod -aG sudo adm_andre

Dieser Befehl gibt dem Benutzer Administratorrechte über sudo. So wird der Server später nicht direkt als Root verwaltet, sondern über einen normalen Benutzer mit erhöhten Rechten.

Gruppenmitgliedschaft prüfen

groups adm_andre

Damit kontrollierst du, ob der Benutzer wirklich Mitglied der Gruppe sudo ist. Wenn sudo in der Ausgabe erscheint, sind die Rechte korrekt gesetzt.

2. SSH-Key für den sicheren Login vorbereiten

Diesen Schritt führst du auf deinem Client-PC aus, also auf dem Rechner, mit dem du dich auf den Server verbindest.

SSH-Key erzeugen

ssh-keygen -t ed25519 -C "adm_andre@login"

Mit diesem Befehl erstellst du ein modernes SSH-Schlüsselpaar. Der private Schlüssel bleibt auf deinem PC, der öffentliche Schlüssel wird auf den Server kopiert.

Öffentlichen Schlüssel auf den Server übertragen

ssh-copy-id adm_andre@SERVER-IP

#Beispiel
ssh-copy-id adm_andre@192.168.151.23

Dieser Befehl kopiert den öffentlichen Schlüssel in das Benutzerkonto adm_andre auf dem Server. Danach kann die Anmeldung per SSH-Key erfolgen, ohne dass jedes Mal das Serverpasswort nötig ist.

3. Login mit dem neuen Benutzer testen

Testanmeldung per SSH

ssh adm_andre@SERVER-IP

Mit diesem Test prüfst du, ob der neue Benutzer sich erfolgreich anmelden kann. Dieser Schritt ist entscheidend, bevor du die Passwort-Anmeldung oder den Root-Login abschaltest.

sudo testen

sudo whoami

Damit überprüfst du, ob adm_andre administrative Rechte hat. Wenn root ausgegeben wird, funktioniert sudo korrekt.

4. SSH absichern: Nur Key-Login erlauben

SSH-Konfiguration öffnen

sudo nano /etc/ssh/sshd_config

Mit diesem Befehl öffnest du die Konfigurationsdatei des SSH-Dienstes. Hier legst du fest, wie sich Benutzer künftig anmelden dürfen.

Diese Werte einstellen:

PermitRootLogin no        #Root login wird deaktiviert
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

PermitRootLogin no verbietet den direkten Root-Login per SSH.
PasswordAuthentication no deaktiviert die Passwort-Anmeldung per SSH, sodass nur noch der sicherere SSH-Key-Login möglich ist.

PubkeyAuthentication yes stellt sicher, dass die Anmeldung per Schlüssel erlaubt ist.
ChallengeResponseAuthentication no reduziert zusätzliche Anmeldemethoden, die hier nicht benötigt werden.
UsePAM yes sollte in der Regel aktiviert bleiben, da einige Systeme und Funktionen davon abhängen.

Optional nur den Admin-Benutzer für SSH erlauben

AllowUsers adm_andre

Mit dieser Einstellung darf sich nur der Benutzer adm_andre per SSH anmelden. Das reduziert die Angriffsfläche zusätzlich, weil andere Benutzerkonten gar nicht erst für SSH verwendet werden können.

SSH-Konfiguration prüfen

sudo sshd -t

Dieser Befehl prüft die Konfiguration auf Syntaxfehler. So stellst du sicher, dass keine fehlerhafte Einstellung den SSH-Dienst unbrauchbar macht.

SSH-Dienst neu laden

sudo systemctl reload ssh

Damit übernimmt der SSH-Dienst die neuen Einstellungen. Bestehende Sitzungen bleiben dabei normalerweise erhalten, was sicherer ist als ein harter Neustart des Dienstes.

Ganz wichtiger Sicherheitstest

Zweite SSH-Sitzung öffnen und erneut anmelden.

ssh adm_andre@SERVER-IP

Jetzt testest du in einer neuen Sitzung, ob der Login wirklich noch funktioniert. Erst wenn diese Anmeldung erfolgreich klappt, solltest du die alte Sitzung schließen.
Das ist einer der wichtigsten Punkte für das Video: Nie die aktuelle SSH-Verbindung schließen, bevor der neue Login getestet wurde.

UFW-Firewall installieren und absichern

Paketliste aktualisieren

sudo apt update  #Paketquellen aktualisieren
sudo apt install ufw -y   # Firewall UFW installieren

Standardregel für eingehende und ausgehende Verbindungen

sudo ufw default deny incoming   # Alle eingehenden Verbindungen blockieren
sudo ufw default allow outgoing  # ausgehende Verbindungen des Servers erlauben

Zugriffe erlauben

sudo ufw allow 22/tcp  # SSH erlauben
sudo ufw allow 80/tcp  # Optional HTTP erlauben
sudo ufw allow 443/tcp # HTTPS erlauben
sudo ufw enable

Status prüfen

sudo ufw status numbered

7. Offene Ports kontrollieren

Laufende Ports anzeigen.

sudo ss -tulpn  #Welche Dienste aktuell laufen
sudo ufw status verbose  #UFW im Detail prüfen

Fail2Ban installieren und konfigurieren

Fail2Ban installieren

sudo apt install fail2ban -y

Mit diesem Paket schützt du den Server vor wiederholten Login-Versuchen. Verdächtige IP-Adressen werden nach mehreren Fehlversuchen automatisch für eine Zeit gesperrt.

Fail2Ban installieren

sudo apt install fail2ban -y

Mit diesem Paket schützt du den Server vor wiederholten Login-Versuchen. Verdächtige IP-Adressen werden nach mehreren Fehlversuchen automatisch für eine Zeit gesperrt.

Dienst aktivieren und starten

sudo systemctl enable --now fail2ban

Dadurch startet Fail2Ban sofort und wird auch bei jedem Serverstart automatisch geladen. So ist der Schutz dauerhaft aktiv.

Standardkonfiguration lokal kopieren

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Damit erzeugst du eine eigene lokale Konfiguration. Änderungen sollten nicht direkt in der Originaldatei gemacht werden, damit Updates sie nicht überschreiben.

Konfiguration bearbeiten

sudo nano /etc/fail2ban/jail.local

Hier legst du fest, wie aggressiv fehlgeschlagene Anmeldeversuche behandelt werden. Für SSH ist das eine sehr sinnvolle zusätzliche Schutzmaßnahme.

Diese Werte im Bereich [DEFAULT] prüfen oder setzen

ignoreip = 127.0.0.1/8 ::1
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true

Diese Werte bedeuten: Wer innerhalb von 10 Minuten fünfmal scheitert, wird für eine Stunde gesperrt. Lokale Adressen werden dabei nie blockiert. [sshd] Damit wird die Überwachung des SSH-Dienstes eingeschaltet. Gerade weil SSH oft direkt aus dem Internet erreichbar ist, ist diese Regel besonders wichtig.

Fail2Ban neu starten

sudo systemctl restart fail2ban

Nach Änderungen an der Konfiguration muss der Dienst neu gestartet werden. Erst dann werden die neuen Regeln aktiv.

Status der SSH-Regel prüfen

sudo fail2ban-client status sshd

Mit diesem Befehl kontrollierst du, ob die SSH-Überwachung korrekt läuft. Außerdem siehst du dort später auch gesperrte IP-Adressen.

Automatische Sicherheitsupdates einrichten

Notwendige Pakete installieren

sudo apt install unattended-upgrades apt-listchanges -y

Damit installierst du die Funktion für automatische Sicherheitsupdates. Das hilft dabei, wichtige Sicherheitslücken auch zwischen Wartungsintervallen zeitnah zu schließen.

Einrichtung starten

sudo dpkg-reconfigure --priority=low unattended-upgrades

Dieser Befehl startet den Einrichtungsdialog für automatische Updates. Dort aktivierst du, dass Sicherheitsupdates automatisch installiert werden.

Konfigurationsdatei prüfen

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

In dieser Datei steht, ob Paketlisten automatisch aktualisiert und Sicherheitsupdates automatisch installiert werden. Das ist ein guter Kontrollpunkt für die Dokumentation.

Typische sinnvolle Werte

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Der erste Eintrag aktualisiert regelmäßig die Paketlisten. Der zweite sorgt dafür, dass erlaubte Updates automatisch installiert werden.

Testlauf durchführen

sudo unattended-upgrade --dry-run --debug

Damit simulierst du einen automatischen Update-Lauf, ohne echte Änderungen vorzunehmen. So kannst du kontrollieren, ob die Konfiguration wie gewünscht funktioniert.

Besonderheiten

Bei dieser Absicherung geht es nicht um perfekte Härtung, sondern um eine sehr solide und praxisnahe Basis für Linux-Server. Besonders wichtig ist dabei die richtige Reihenfolge, denn ein deaktivierter Passwort-Login oder ein gesperrter Root-Zugang sind nur dann sinnvoll, wenn der SSH-Key-Zugang für den Admin-Benutzer vorher sauber eingerichtet und getestet wurde.

Ein weiterer wichtiger Punkt ist, dass Sicherheit immer vom Einsatzzweck abhängt. Ein rein interner Server im Heimnetz hat andere Anforderungen als ein öffentlich erreichbarer VPS oder Root-Server im Internet. Maßnahmen wie UFW, Fail2Ban und automatische Sicherheitsupdates sind jedoch in fast allen Szenarien sinnvoll und bilden eine starke Grundlage.

Auch wichtig: Sicherheit ist kein einmaliger Vorgang. Nach der Ersteinrichtung sollten offene Ports, aktive Dienste, Logdateien und Update-Status regelmäßig kontrolliert werden. Nur so bleibt der Server dauerhaft sauber, nachvollziehbar und wartbar.

Weiterführende Fragen

1.) Fragen von Answer The Public zum Thema beantworten:

Hier kannst du typische Nutzerfragen sammeln und direkt im Artikel beantworten. Für dein Thema passen unter anderem folgende Fragen sehr gut:

Was bringt es, den Root-Login per SSH zu deaktivieren?

Wenn sich Root nicht mehr direkt per SSH anmelden darf, wird ein besonders häufig angegriffenes Ziel entfernt. Administratoren arbeiten dann über einen normalen Benutzer mit sudo, was sicherer und besser nachvollziehbar ist.

Warum sollte die Passwort-Anmeldung per SSH deaktiviert werden?

Passwörter können erraten, wiederverwendet oder durch Brute-Force-Angriffe angegriffen werden. Ein SSH-Key ist deutlich sicherer, weil für die Anmeldung ein passendes Schlüsselpaar erforderlich ist.

Brauche ich trotz SSH-Key noch Fail2Ban?

Ja, oft ist das trotzdem sinnvoll. Fail2Ban schützt zusätzlich vor massenhaften Login-Versuchen, Log-Spam und unnötiger Last auf öffentlich erreichbaren Diensten.

Reicht eine UFW-Firewall für einen kleinen Server aus?

Für viele private und kleine produktive Umgebungen ist UFW eine sehr gute Lösung. Wichtig ist weniger die Komplexität der Firewall, sondern dass wirklich nur benötigte Ports freigegeben werden.

Sind automatische Sicherheitsupdates auf Linux sinnvoll?

Ja, vor allem für Sicherheitsupdates. Sie helfen dabei, bekannte Schwachstellen zeitnah zu schließen, auch wenn die manuelle Wartung nur alle paar Wochen erfolgt.

Kann ich mich aussperren, wenn ich SSH härte?

Ja, das ist einer der häufigsten Fehler. Deshalb muss der neue Admin-Benutzer inklusive SSH-Key-Login immer zuerst getestet werden, bevor Passwort-Login oder Root-Login deaktiviert werden.

Sollte ich den SSH-Port ändern?

Das kann Hintergrundrauschen reduzieren, ersetzt aber keine echte Absicherung. Wichtiger sind SSH-Key-Login, deaktivierter Root-Zugang, Firewall-Regeln und saubere Updates.

Wie kontrolliere ich, ob mein Server wirklich sicherer geworden ist?

Sinnvoll sind Kontrollen mit ss -tulpn, ufw status, fail2ban-client status, Logdateien und ein Test der SSH-Anmeldung in einer neuen Sitzung. Sicherheit sollte immer überprüfbar sein und nicht nur vermutet werden.

Weiterführende Dokumente

Interne Dokumente:
Externe Dokumente:

Was ist eine SOP (Standard Operating Procedure)?

Eine SOP (Standard Operating Procedure) ist eine klar definierte, schriftliche Arbeitsanweisung, die beschreibt, wie ein Prozess Schritt für Schritt korrekt ausgeführt wird. Sie sorgt dafür, dass Aufgaben einheitlich, nachvollziehbar und in gleichbleibender Qualität erledigt werden.