Alle Beispiele mit fiktiven Daten: Server beispielserver.example.com, User anna, Mail-Relay mailrelay.example.com.
Ausgangslage
Root-Login per SSH, Passwort-Auth, Standard-Port 22 - so kommt ein Server frisch vom Provider. Bevor irgendein Dienst draufkommt, sichern wir den Zugang ab und bringen das System auf einen sauberen Stand.
1. Benutzer anlegen und SSH-Key hinterlegen
Root bleibt fuer den taeglichen Zugriff tabu. Erst einen Admin-User anlegen:
adduser anna
usermod -aG sudo anna
mkdir -p /home/anna/.ssh
chown -R anna:anna /home/anna/.ssh
chmod 700 /home/anna/.ssh
Auf dem eigenen Rechner einen dedizierten Key pro Server erzeugen (kein Passphrase-Zwang, aber empfohlen):
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_beispielserver -C "anna@beispielserver"
Public Key auf dem Server eintragen:
echo "ssh-ed25519 AAAA... anna@beispielserver" >> /home/anna/.ssh/authorized_keys
chmod 600 /home/anna/.ssh/authorized_keys
Login testen (root-Session dabei offen lassen!):
ssh -i ~/.ssh/id_ed25519_beispielserver anna@beispielserver.example.com
sudo whoami
Kommt root zurueck, ist sudo eingerichtet.
2. SSH absichern
Config sichern, dann anpassen:
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
In /etc/ssh/sshd_config setzen:
Port 4022
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Vor dem Neustart immer testen:
sshd -t
systemctl restart ssh
Die alte root-Session nicht schliessen, bis der Login auf dem neuen Port in einem zweiten Fenster bestaetigt ist:
ssh -p 4022 anna@beispielserver.example.com
Erst wenn das klappt, die alte Session beenden.
3. System aktualisieren
apt update
apt list --upgradable
apt full-upgrade -y
Ist ein neuer Kernel dabei, folgt ein Reboot. Vorher pruefen, ob ein Rescue-Zugang beim Provider verfuegbar ist (Absicherung falls nach dem Reboot etwas klemmt).
reboot
Nach dem Neustart erneut per SSH verbinden und pruefen:
uname -r
4. Firewall einrichten
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 4022/tcp comment 'SSH'
ufw show added
Regeln pruefen, bevor scharf geschaltet wird. Dann:
ufw enable
Sofort in einem zweiten Fenster (bestehende Session offen lassen!) den Login erneut testen.
ufw status kann “active” melden, waehrend systemctl status ufw “inactive (dead)” zeigt - das ist normal, die Regeln laufen direkt im Kernel. Fuer Monitoring-Skripte den ufw status-Text pruefen, nicht den systemd-Status.
5. Fail2Ban einrichten
apt install -y fail2ban
Eigene Config-Datei anlegen, nie die Default-Datei direkt bearbeiten:
tee /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
port = 4022
EOF
systemctl restart fail2ban
fail2ban-client status sshd
6. Mail-Relay konfigurieren
Fuer System-Mails (Cronjobs, Health-Checks) reicht ein einfacher Relay-Client, kein voller Mailserver. Beispiel mit OpenSMTPD, Relay ueber einen bestehenden Mailserver:
apt install -y opensmtpd
Zugangsdaten hinterlegen:
tee /etc/secrets << 'EOF'
relaylabel anna@mailrelay.example.com:DEIN_PASSWORT
EOF
chmod 600 /etc/secrets
Config unter /etc/smtpd.conf (Debian-Pfad, nicht /etc/mail/):
tee /etc/smtpd.conf << 'EOF'
table aliases file:/etc/aliases
table secrets file:/etc/secrets
table localdomains { "beispielserver.example.com", "beispielserver", "localhost" }
listen on localhost
action "local" maildir alias <aliases>
action "outbound" relay host smtp+tls://relaylabel@mailrelay.example.com:587 auth <secrets> mail-from beispielserver@example.com
match for domain <localdomains> action "local"
match from local for any action "outbound"
EOF
smtpd -n
systemctl restart opensmtpd
Steht root in der localdomains-Tabelle, versucht das System, lokal an den Systemuser root zuzustellen - das scheitert unter Debian mit permission denied. Loesung: In /etc/aliases root auf eine externe Adresse umleiten:
tee -a /etc/aliases << 'EOF'
root: admin-beispielserver@example.com
EOF
systemctl restart opensmtpd
Zum Testen wird ein mail-Kommando benoetigt, das ist bei Debian nicht vorinstalliert:
apt install -y mailutils
Bei der Installation kann ein Debconf-Dialog zur Mailserver-Konfiguration erscheinen - dort “Keine Konfiguration” waehlen, da OpenSMTPD separat als Relay laeuft.
Testen:
echo "Testmail" | mail -s "Testbetreff" root
journalctl -u opensmtpd -n 15 --no-pager
systemctl reload opensmtpd schlaegt bei diesem Unit fehl (“Job type reload is not applicable”) - nach Config-Aenderungen systemctl restart opensmtpd verwenden.
7. Health-Check einrichten
Ein taegliches Script, das Diskspace, Firewall- und Fail2Ban-Status sowie verfuegbare Updates prueft und per Mail meldet - Grundgeruest, je nach Server um weitere Kennzahlen (Speicher, Load, Dienste) erweiterbar:
tee /usr/local/bin/beispielserver-health.sh << 'SCRIPT'
#!/bin/bash
HOSTNAME=$(hostname)
DATE=$(date '+%Y-%m-%d %H:%M:%S')
STATUS="OK"
DISK=$(df -h / | awk 'NR==2 {print $5}')
UFW=$(ufw status | grep -q "Status: active" && echo active || echo inactive)
FAIL2BAN=$(systemctl is-active fail2ban)
UPDATES=$(apt list --upgradable 2>/dev/null | grep -c upgradable)
[[ "$UFW" != "active" ]] && STATUS="WARN"
[[ "$FAIL2BAN" != "active" ]] && STATUS="WARN"
[[ "$UPDATES" -gt 0 ]] && STATUS="WARN"
REPORT="$HOSTNAME Health Check - $DATE
Disk: $DISK
UFW: $UFW
Fail2Ban: $FAIL2BAN
Updates verfuegbar: $UPDATES
"
echo "$REPORT" | mail -s "[$STATUS] $HOSTNAME Health Check" root
SCRIPT
chmod +x /usr/local/bin/beispielserver-health.sh
Als Cronjob taeglich um 06:00:
echo "0 6 * * * root /usr/local/bin/beispielserver-health.sh" | tee /etc/cron.d/beispielserver-health
Debian 13 bringt cron nicht in der Minimalinstallation mit. Ein angelegter Cronjob unter /etc/cron.d/ liegt dann zwar bereit, wird aber nie ausgefuehrt - ohne Fehlermeldung. Vor dem ersten produktiven Cronjob pruefen:
which cron
systemctl status cron --no-pager
Fehlt der Dienst, nachinstallieren und aktivieren:
apt install -y cron
systemctl enable --now cron
Danach greift der Cronjob wie erwartet.
8. Firewall beim Provider zusaetzlich aktivieren
Neben der Server-Firewall (ufw) bieten viele Provider eine vorgelagerte Netzwerk-Firewall im Kundenpanel an. Sinnvoll als zusaetzliche Ebene (“Defense in Depth”): Traffic wird schon vor dem Server gefiltert, entlastet also Netzwerk-Interface und Kernel - und dient als Rueckfallebene, falls ufw mal aus Versehen falsch konfiguriert oder deaktiviert wird.
Vorgehen im Kundenpanel (Beispiel mit einem typischen Anbieter-Interface, “Experte”-Modus):
- Alle mitgelieferten Standardregeln deaktivieren, die nicht gebraucht werden (Plesk, POP3/IMAP, SMTP, HTTP/HTTPS, FTP, MySQL - auf einem frischen Server laeuft davon meist nichts extern).
- Eigene Regel anlegen: Beschreibung
SSH beispielserver, Zielport4022, Protokoll TCP. - Vor dem Speichern pruefen: Quellport bleibt auf dem vollen Client-Bereich (z.B.
1024:65535) - das ist der Port, von dem der eigene Rechner aus verbindet, nicht der Serverport. Nur der Zielport wird auf 4022 eingeschraenkt. - Aenderung speichern, danach sofort in einem zweiten Fenster (laufende Session offen lassen!) den Login testen:
ssh -p 4022 anna@beispielserver.example.com
Erst wenn der Login bestaetigt ist, die alte Session schliessen.
Ergebnis
Server-Zugang abgesichert (Key-only, kein Root-Login, eigener Port), System aktuell, Firewall doppelt abgesichert (ufw + Provider-Firewall) und Fail2Ban aktiv, Mail-Relay funktionsfaehig, taeglicher Health-Check eingerichtet. Basis fuer den weiteren Ausbau steht.
