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.