Ihre Infrastruktur sichern
Von SSH bis KI-Agenten — jede Schicht Ihrer Infrastruktur absichern
Sichern Sie Ihre Server-Infrastruktur — SSH, Firewalls, TLS, Monitoring, Fail2ban und Incident Response. Konkrete Beispiele, Befehle und Checklisten für Ubuntu VPS.
Ce que vous allez apprendre
- Sie wissen, wie Sie sich per SSH auf einem Server einloggen.
- Sie wissen, was ein Docker-Container, ein Reverse Proxy und eine API sind.
- Sie haben einen KI-Agenten, der Befehle auf Ihrem Server ausführen kann (Hermes, Claude Code usw.).
- Sie müssen kein Sicherheitsexperte sein — genau das ist der Zweck dieses Buches.
- Kapitel 1** — Einen Ubuntu-VPS sichern: SSH, Firewall, Monitoring, Incident Response. Die Grundlagen, ohne die alles andere nutzlos ist.
- Kapitel 2** — Einen Webserver sichern: TLS, Security-Header, Docker, FastAPI, Rate Limiting. Das, was Ihre Nutzer schützt, wenn sie auf Ihre Dienste zugreifen.
- Kapitel 3** — Autonome KI-Agenten sichern: Prompt Injection, Berechtigungen, Sandboxing, Kill Switches. Die neue Grenze der Sicherheit im Jahr 2026.
- Kapitel 4** — Vollständige Checkliste: Pre-Deployment, monatliches Audit, automatisierte Tools. Alles in einem reproduzierbaren Prozess zusammenfassen.
Chapitres détaillés
-
Einleitung
- Mein Server ist für Hacker nicht interessant — wahr oder falsch?
- Warum dieses Buch
- Wie Sie dieses Buch nutzen
- Voraussetzungen
- Was Sie lernen werden
- Ein Wort zu den Beispielen
- Sicherheit ist ein Prozess
-
Kapitel 1: Einen Ubuntu-VPS absichern
- 1.1 SSH — das Eingangstor
-
1.2 Firewall (UFW)
- 1.2 Firewall (UFW)
-
1.3 Monitoring und Logs
- 1.3 Monitoring und Logs
-
1.4 Incident Response — was tun, wenn es passiert
- 1.4 Incident Response — was tun, wenn es passiert
-
1.5 Automatische Updates
- 1.5 Automatische Updates
- Zusammenfassung des Kapitels
-
1.6 Fail2ban — Angreifer automatisch blockieren
- 1.6 Fail2ban — Angreifer automatisch blockieren
-
1.7 Audit-Prompts — VPS Ubuntu
- 1.7 Audit-Prompts — VPS Ubuntu
-
2.1 TLS — Kommunikationen verschlüsseln
- HTTP vs HTTPS : was IHR ohne TLS verliert
- TLS 1.3 vs 1.2 : warum ein Upgrade sinnvoll ist
- Zertifikate : die Logik, nicht die Befehle
- HSTS : HTTPS erzwingen
- Mixed Content : wenn HTTPS nicht schützt
- KI-Prompt : Audit der TLS-Konfiguration
-
2.2 Sicherheits-Header
- Warum HTTP-Header Ihre erste Web-Verteidigungslinie sind
- Content-Security-Policy: der mächtigste Header
- X-Frame-Options: Anti-Clickjacking
- X-Content-Type-Options: Anti-MIME-Sniffing
- Referrer-Policy: Kontrolle über geteilte Daten
- Permissions-Policy: Browser-APIs einschränken
- KI-Prompt: Sicherheits-Header-Audit
-
2.3 Rate Limiting und WAF
- Warum Rate Limiting
- Rate Limit vs. Throttling
- Wo man Rate Limiting anwendet
- Häufige Fehler beim Rate Limiting
- WAF: Wann es nützlich ist, wann es nicht ausreicht
- fail2ban für Nginx: Die Verbindung Firewall ↔ Web
- KI-Prompt: Audit Rate Limiting und WAF
-
2.4 Docker — Isolierung und Containment
- Warum ein Container keine virtuelle Maschine ist
- Container Escape: Wie ein Angreifer aus einem Container ausbricht
- Niemals als Root ausführen
- Ressourcenlimits: CPU, Arbeitsspeicher, Festplatte
- Docker Compose: Trennen, um den Blast Radius zu begrenzen
- KI-Prompt: Docker-Sicherheitsaudit
-
2.5 FastAPI — Die API sichern
- CORS: Warum es notwendig ist und wann es ein Risiko darstellt
- Eingabevalidierung: Pydantic als Defense in Depth
- Secrets-Management: .env reicht im Produktionsbetrieb nicht aus
- Sicheres Logging: Niemals Tokens protokollieren
- KI-Prompt: Sicherheitsaudit für FastAPI-API
-
2.6 WAF — Web Application Firewall
- 2.6 WAF — Web Application Firewall
-
2.7 CI/CD Security — Den Deployment-Pipeline absichern
- 2.7 CI/CD Security — Den Deployment-Pipeline absichern
-
2.8 Audit-Prompts — Nginx, FastAPI, Docker
- 2.8 Audit-Prompts — Nginx, FastAPI, Docker
-
3.1 Warum KI-Agenten anders sind
- Ein KI-Agent trifft Entscheidungen — klassische Software führt nur aus
- Die Angriffsfläche ist nicht mehr der Code, sondern der Prompt
- Realer Fall: Der Meta-Vorfall (März 2026)
- Realer Fall: Summer Yue — die gelöschte Inbox
- Die Lehren für Ihre Infrastruktur
-
3.2 Prompt Injection — die Angriffe verstehen
- Direkte Injection: Den Prompt des Benutzers manipulieren
- Indirekte Injection: Den Inhalt kontrollieren, den der Agent konsumiert
- Warum Inhaltsfilterung unzureichend ist
- Der Ansatz über Berechtigungen, nicht über Filterung
- Konkrete Beispiele für erfolgreiche Angriffe
-
3.3 Berechtigungen und das Prinzip der geringsten Rechte
- Warum ein KI-Agent weniger Rechte haben sollte als Sie
- Read-only vs read-write: Entscheidung pro Aktion
- API-Scopes: Jeden Token auf seinen Nutzwert beschränken
- Automatischer Ablauf von Berechtigungen
- KI-Prompt: Berechtigungen eines KI-Agents prüfen
-
3.4 Sandboxing, Kill Switches und Überprüfbarkeit
- Warum ein Agent in einer isolierten Umgebung laufen muss
- Container, isolierte Netzwerke, Read-Only-Dateisysteme
- Hard Gates vs. Soft Prompts
- Kill Switches: der Not-Aus-Knopf
- Logs: Jede Aktion muss nachverfolgbar sein
- Maskierung und Canary-Daten
- KI-Prompt: Die Sicherheitsvorkehrungen eines Agents überprüfen
-
3.5 Kontrolle sensibler Tools und Logs
- 3.5 Kontrolle sensibler Tools und Logs
-
3.6 Audit-Prompts — Autonome KI-Agenten
- 3.6 Audit-Prompts — Autonome KI-Agenten
-
4.1 Vorab-Checkliste für das Deployment
- VPS: SSH, Firewall, Benutzer, Updates
- Docker: Isolation, Benutzer, Ressourcenlimits
- API: Header, CORS, Rate Limiting, Secrets
- KI-Agent: Berechtigungen, Sandboxing, Kill Switch, Logs
-
4.2 Automatisierte Audit-Tools
- Lynis: umfassender System-Scanner
- Trivy: Container- und Image-Schwachstellen
- docker-bench-security: CIS Docker Benchmark
- Mozilla Observatory: HTTP-Header
- Integration in einen monatlichen Workflow
- KI-Prompt: Einen vollständigen Audit durchführen und auswerten
-
4.3 Monatliches Audit und Referenzrahmen
- Warum ein einmaliges Audit nicht ausreicht
- Die 7 wesentlichen monatlichen Überprüfungen
- Wenn ein Tool eine Schwachstelle meldet
- Referenzrahmen: NIST, CIS, OWASP
-
4.4 Audit-Prompts — Vollständige Infrastruktur
- 4.4 Audit-Prompts — Vollständige Infrastruktur
-
Fazit
- Sicherheit ist ein Prozess, kein Zustand
- Rückblick: Die Grundprinzipien
- Nächste Schritte
- Glossar
- Weitere Ressourcen
Ce qui rend ce livre différent
Cypher Aeon Veda
Das ist der Satz, den man am häufigsten hört, wenn es um Serversicherheit geht. „Ich habe nichts Interessantes“, „Es ist nur eine kleine Website“, „Wer würde schon meinen 5-€-VPS hacken wollen?“
Falsch. Komplett falsch.
Formats et compatibilité
Ebook
EPUB + PDF. Lisible sur Kindle, tablette, smartphone, PC.
Questions fréquentes
Mein Server ist für Hacker nicht interessant — wahr oder falsch?
Das ist der Satz, den man am häufigsten hört, wenn es um Serversicherheit geht. „Ich habe nichts Interessantes“, „Es ist nur eine kleine Website“, „Wer würde schon meinen 5-€-VPS hacken wollen?“
Warum dieses Buch
Es gibt Hunderte von Sicherheitsanleitungen im Internet. Blogs, Videos, offizielle Dokumentationen. Aber die meisten leiden unter einem Problem: Sie sind entweder zu theoretisch (Seiten voller Konzepte ohne praktische Anwendung) oder zu praxisorientiert (Listen von Befehlen zum Kopieren und Einfügen, ohne zu verstehen, was sie tun).
Wie Sie dieses Buch nutzen
**Wenn Sie Anfänger sind** — Lesen Sie die Kapitel in der Reihenfolge. Jedes Kapitel baut auf dem vorherigen auf, vom VPS bis zur vollständigen Checkliste.
Was Sie lernen werden
- **Kapitel 1** — Einen Ubuntu-VPS sichern: SSH, Firewall, Monitoring, Incident Response. Die Grundlagen, ohne die alles andere nutzlos ist. - **Kapitel 2** — Einen Webserver sichern: TLS, Security-Header, Docker, FastAPI, Rate Limiting. Das, was Ihre Nutzer schützt, wenn sie auf Ihre Dienste zugreifen. - **Kapitel 3** — Autonome KI-Agenten sichern: Prompt Injection, Berechtigungen, Sandboxing, Kill Switches. Die neue Grenze der Sicherheit im Jahr 2026. - **Kapitel 4** — Vollständige Checkliste:
Ein Wort zu den Beispielen
Alle Beispiele in diesem Buch sind generisch. Sie werden keine echten Domänennamen, IP-Adressen oder Konfigurationen finden. Das ist absichtlich so: Sicherheit beginnt damit, keine Informationen über die eigene Infrastruktur preiszugeben. Wenn ein Konfigurationsbeispiel benötigt wird, werden fiktive Werte verwendet (`ihr-vps.example.com`, `192.0.2.1`).
Sicherheit ist ein Prozess
Noch ein letzter Punkt vor dem Start: Es gibt keinen „sicheren“ Server. Es gibt nur Server, deren Sicherheit **aktiv und gewartet** wird. Ein im Januar gesicherter Server kann im März anfällig werden, wenn keine Updates eingespielt werden, wenn ein neuer Port geöffnet wird oder wenn ein neues Tool ohne die gleichen Vorkehrungen bereitgestellt wird.