Server Admin Master-Class
Self-Hosting Guide: Vom nackten Linux zum gehärteten Server.
Step 0: Bevor du mietest!
Ein öffentlicher Server ist kein Spielzeug. Wenn er übernommen wird, bist du verantwortlich.
-
Weißt du, wie man Logs liest (`journalctl`, `/var/log`)? Kannst du den Server retten, wenn SSH nicht mehr geht? Wenn nein: Übe erst in einer lokalen VM (VirtualBox), nicht im Internet!
-
Wenn dein Server Teil eines Botnets wird oder Spam versendet, haftest oft du (Störerhaftung). Dein Hoster wird den Server bei Abuse-Meldungen sofort sperren.
-
Hast du geprüft, was passiert, wenn du 50TB Traffic durch einen DDoS verursachst? Gibt es ein Kosten-Limit oder eine Flatrate?
1. Basissystem & SSH
Die Eingangstür vernageln.
-
Guide
Passwörter sind in Sekunden knackbar. `PasswordAuthentication no` in der `/etc/ssh/sshd_config` ist Pflicht. Nutze ED25519 Keys.
-
`PermitRootLogin no`. Arbeite immer als normaler User und nutze `sudo` für Befehle. Das verhindert viele automatisierte Angriffe, die "root" als User probieren.
-
Tool
Installiere Tools, die IPs nach 3-5 Fehlversuchen automatisch bannen. Das hält die Logs sauber und blockt Brute-Force-Bots.
2. Netzwerk & Firewall
Nur reinlassen, was sein muss.
-
UFW
Alles ist verboten, außer es ist explizit erlaubt. Starte mit `ufw default deny incoming`.
-
MySQL/Redis Ports (3306/6379) dürfen NIEMALS offen im Netz stehen. Binde sie an `127.0.0.1` oder nutze VPNs (WireGuard), wenn du von außen drauf musst.
-
Bietet der Hoster eine Hardware-Firewall (Arbor/Voxility) an? Ohne Schutz ist dein Game-Server beim ersten Angriff offline.
3. Hoster & Kontakt
Wissen, wen man anruft.
-
Wenn dein Server gehackt wird, bekommst du eine "Abuse Message". Weißt du, wie du darauf reagierst (Stellungnahme schreiben, Logs prüfen)? Wenn nicht, wird gekündigt.
-
Hast du Zugriff auf eine Web-Konsole (VNC/KVM) im Hoster-Panel? Das ist dein einziger Weg rein, wenn du dich per SSH ausgesperrt hast. Teste das VORHER!
-
Ist der Support am Wochenende da? Bei billigen VPS oft nicht. Wenn der Server Freitagabend stirbt, wartest du bis Montag.
4. Backup Strategie
Daten auf dem Server sind flüchtig.
-
Borg
Backups auf der gleichen Festplatte bringen nichts, wenn die Platte stirbt. Nutze S3, FTP-Backupspace oder eine Hetzner StorageBox.
-
Menschen vergessen Backups. Cronjobs nicht. Richte tägliche, automatische Backups ein (z.B. nachts um 4 Uhr).
-
Ein Backup, das man nicht wiederherstellen kann, ist Datenmüll. Lösche testweise eine Datei und hole sie aus dem Backup zurück.
5. Game-Server Specs
Besonderheiten bei Games.
-
Docker
Installiere Games (Minecraft, CS:GO) immer im Container. Wenn der Game-Server eine Sicherheitslücke hat, ist nur der Container betroffen, nicht dein ganzes Linux.
-
Game-Server Binaries sind oft unsicher. Starte sie niemals mit `sudo` oder als `root` User. Lege einen User `steam` oder `minecraft` an.
-
Speichere deine `server.cfg` in einem privaten Git-Repo. Wenn du etwas kaputt konfigurierst, kannst du zur Version von gestern zurück.
6. Performance
Lags vermeiden.
-
Wenn der RAM voll ist und das System auf die Festplatte auslagert (Swap), laggt der Game-Server extrem. Deaktiviere Swap oder überwache RAM strikt.
-
Begrenze Docker-Container (z.B. `--memory="4g"`). Ein Memory-Leak im Game darf nicht dazu führen, dass dein SSH-Dienst abstürzt.
7. Updates & Wartung
Ein Server ist wie ein Haustier.
-
Linux Sicherheitsupdates sollten sich automatisch installieren. Richte `unattended-upgrades` (Debian/Ubuntu) ein.
-
Game-Server spammen Logs voll. Prüfe `logrotate`, sonst ist nach 3 Monaten die Festplatte voll und der Server stürzt ab.
8. Social Engineering
Der Mensch ist die Schwachstelle.
-
Dein Co-Admin braucht keinen Root-Zugriff, nur um den Server neu zu starten. Gib ihm Rechte nur für den Docker-Container oder das Web-Panel.
-
Gib niemals temporär Passwörter raus ("Nur kurz zum Testen"). Passwörter werden weitergegeben oder in Textdateien gespeichert.
⚖️ Haftungsausschluss (Disclaimer)
Wichtiger Hinweis: Diese Checkliste dient ausschließlich zu Bildungszwecken und erhebt keinen Anspruch auf Vollständigkeit. IT-Sicherheit ist ein komplexes Feld, das sich täglich ändert.
Die Umsetzung der hier genannten Maßnahmen erfolgt auf eigene Gefahr. Der Betreiber dieser Webseite übernimmt keine Haftung für Schäden an Hard- oder Software, Datenverlust, Sicherheitslücken, gehackte Server oder rechtliche Konsequenzen (z.B. durch Störerhaftung), die aus der Nutzung dieser Informationen entstehen.