Linux-Server härten: Vom Kernel bis zum Container

Linux-Server härten: Vom Kernel bis zum Container

Einen SSH-Key einrichten und Fail2ban installieren — das ist erst der Anfang. Wer seinen Linux-Server wirklich absichern will, muss tiefer gehen. Vom Kernel über systemd bis zum Container gibt es auf jeder Ebene Stellschrauben, die die Angriffsfläche reduzieren.

In diesem Artikel zeige ich dir sechs konkrete Maßnahmen, die über die Standard-Absicherung hinausgehen. Jede einzelne macht deinen Server widerstandsfähiger — und zusammen greifen sie auf verschiedenen Ebenen ineinander.

DarkWolfCave.de

ℹ️ Hinweis: Die hier gezeigten Konfigurationen sind Empfehlungen aus meiner eigenen Praxis — keine Garantie für vollständige Sicherheit. Jedes Setup ist anders. Teste Änderungen immer zuerst in einer Testumgebung und passe sie an deine Infrastruktur an. System-Härtung ist ein breites Feld — dieser Artikel zeigt sechs Maßnahmen, die über die Standard-Absicherung hinausgehen.

Warum reicht SSH-Härtung allein nicht aus?

Wenn du meinen Artikel zur SSH-Server-Absicherung gelesen hast, kennst du die Basics: SSH-Keys, Root-Login deaktivieren, Algorithmen härten. Das ist wichtig und richtig. Aber SSH ist nur ein Dienst auf deinem Server.

Ein Server mit perfekt gehärtetem SSH, aber einem veralteten Webserver, offenen Debug-Ports und einem Docker-Container der als Root läuft — der ist trotzdem verwundbar. Sicherheit funktioniert nur als Gesamtkonzept.

Die folgenden sechs Maßnahmen decken verschiedene Ebenen ab:

Ebene	Maßnahme	Wirkung
Dienste	Unnötige Services deaktivieren	Angriffsfläche reduzieren
MAC	AppArmor-Profile	Zugriffe einschränken
Container	Docker/Podman härten	Isolation verstärken
Kernel	sysctl-Parameter	Kernel-Angriffe erschweren
Init	systemd-Sandboxing	Dienst-Rechte minimieren
Auth	SSH-FIDO2 mit Hardware-Key	Phishing-resistente Authentifizierung

Unnötige Dienste deaktivieren

Ein einfacher Schritt mit großer Wirkung. Jeder laufende Dienst ist ein potenzielles Einfallstor. Das Prinzip heißt minimale Angriffsfläche: Was nicht läuft, kann nicht angegriffen werden.

Wenn du meinen Artikel zu Endlessh-Go als SSH-Tarpit kennst, fragst du dich vielleicht: Ist das nicht selbst ein „unnötiger Dienst”? Streng genommen — ja. Ohne Endlessh würde ich Port 22 per Firewall schließen und mit Fail2ban arbeiten. Endlessh bringt keine zusätzliche Sicherheit, nur Monitoring-Daten und das Endlessh Fisher Angelspiel.

Trotzdem betreibe ich es bewusst, weil das reale Risiko verschwindend gering ist:

• Go statt C — endlessh-go ist in einer memory-safe Sprache geschrieben. Damit fallen Buffer Overflows und Use-after-free komplett weg — die gefährlichste Schwachstellen-Klasse bei Netzwerk-Diensten
• ~600 Zeilen Code — zum Vergleich: OpenSSH hat über 100.000 Zeilen. Die gesamte Codebase von endlessh-go lässt sich in unter einer Stunde reviewen
• Distroless Docker-Container — keine Shell, keine Tools, kein Zugriff auf das Host-Dateisystem. Selbst bei einem Exploit landet der Angreifer in einem leeren Container
• Unprivilegierter Prozess mit no-new-privileges:true — keine Rechteausweitung möglich
• Kein SSH-Handshake — der Dienst kommt nie über die Banner-Phase hinaus. Es werden nur zufällige Textzeilen gesendet, keine Kryptografie, kein Parsing von Client-Daten
• Keine bekannten CVEs — weder für endlessh-go noch für das Original in C

Port 22 komplett zu schließen bleibt objektiv sicherer — null Dienste bedeutet null Angriffsfläche. Aber der Unterschied zwischen „null” und „praktisch null” ist hier so gering, dass ich ihn für Grafana-Dashboards und ein Angelspiel bewusst trage. Der Punkt ist: Triff diese Entscheidung bewusst und kenne das Risikoprofil der Dienste, die du behältst.

Laufende Dienste anzeigen

# Alle aktiven Dienste auflisten
systemctl list-units --type=service --state=running

Auf einem typischen Debian/Ubuntu-Server findest du oft Dienste die du nicht brauchst:

Dienst	Beschreibung	Brauchst du das?
cups.service	Druckserver	Auf einem Server? Nein.
avahi-daemon	mDNS/Bonjour	Nur im LAN sinnvoll
bluetooth.service	Bluetooth-Stack	Auf einem Server nie
ModemManager	Modem-Verwaltung	Nur bei Mobilfunk
snapd.service	Snap-Paketmanager	Oft unnötig

Dienste deaktivieren

# Dienst stoppen und deaktivieren (startet nicht mehr automatisch)
sudo systemctl disable --now cups.service
sudo systemctl disable --now avahi-daemon.service
sudo systemctl disable --now bluetooth.service

# Prüfen ob der Dienst wirklich gestoppt ist
systemctl status cups.service

Wichtig: Deaktiviere nur Dienste, deren Funktion du kennst. Im Zweifel den Dienst erst recherchieren. Einen Dienst versehentlich zu stoppen ist ärgerlich, aber mit systemctl enable --now <service> schnell rückgängig gemacht.

Offene Ports prüfen

Nach dem Aufräumen prüfst du welche Ports noch offen sind:

# Alle lauschenden Ports anzeigen
sudo ss -tlnp

# Oder mit nmap von einem anderen Rechner (sudo apt install nmap)
nmap -sS -p 1-65535 dein-server.de

Jeder offene Port, der nicht bewusst geöffnet wurde, ist ein Warnsignal. Finde den zugehörigen Dienst und entscheide ob er wirklich laufen muss.

AppArmor-Profile für Mandatory Access Control

Standard-Linux-Rechte (chmod, chown) sind Discretionary Access Control — der Besitzer einer Datei entscheidet, wer Zugriff hat. Das Problem: Wenn ein Dienst kompromittiert wird, erbt der Angreifer alle Rechte dieses Diensts. AppArmor fügt eine zweite Schutzschicht hinzu: Mandatory Access Control (MAC).

Wie funktioniert AppArmor?

AppArmor arbeitet mit Profilen. Jedes Profil definiert exakt, welche Dateien, Netzwerkzugriffe und Capabilities ein Programm nutzen darf. Alles andere wird blockiert — selbst wenn die Linux-Rechte es erlauben würden.

# AppArmor-Status prüfen
sudo aa-status

# Zeigt:
# - Profile im enforce Mode (aktiv blockierend)
# - Profile im complain Mode (nur Logging)
# - Nicht profilierte Prozesse

Eigenes Profil erstellen

Für Dienste ohne vorgefertigtes Profil kannst du eines generieren:

# AppArmor-Utils installieren
sudo apt install apparmor-utils

# Profil interaktiv erstellen (z.B. für sshd)
sudo aa-genprof /usr/sbin/sshd

Der Workflow ist dabei immer gleich:

1. aa-genprof startet den Dienst im Lernmodus
2. Du nutzt den Dienst normal (SSH-Verbindungen aufbauen, etc.)
3. aa-genprof fragt für jeden Zugriff ob er erlaubt sein soll
4. Am Ende wird ein Profil unter /etc/apparmor.d/ gespeichert

Enforce vs. Complain Mode

Modus	Wirkung	Wann verwenden
complain	Verstöße werden nur geloggt	Beim Testen neuer Profile
enforce	Verstöße werden blockiert	Im Produktivbetrieb

# Profil in Complain-Mode setzen (zum Testen)
sudo aa-complain /etc/apparmor.d/usr.sbin.sshd

# Nach erfolgreichem Test: Enforce-Mode aktivieren
sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd

💡 Tipp: Lass ein neues Profil mindestens 48 Stunden im complain Mode laufen. So erkennst du Zugriffe die nur bei bestimmten Aktionen auftreten (z.B. Log-Rotation, Backups, Cron-Jobs).

Container-Hardening — Docker und Podman absichern

Container sind keine Sicherheitsgrenze. Standardmäßig laufen Docker-Container als Root, haben Schreibzugriff auf ihr Dateisystem und erhalten mehr Linux-Capabilities als sie brauchen. Das ändern wir. Docker muss installiert sein (Anleitung).

Die vier wichtigsten Container-Flags

docker run \
  --read-only \
  --user 1000:1000 \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --tmpfs /tmp:rw,noexec,nosuid \
  nginx:alpine

Was diese Flags bewirken:

Flag	Wirkung
--read-only	Dateisystem ist schreibgeschützt
--user 1000:1000	Container läuft als unprivilegierter User
--cap-drop ALL	Alle Linux-Capabilities entfernen
--no-new-privileges	Kein Privilege Escalation möglich

⚠️ Wichtig: Manche Anwendungen brauchen Schreibzugriff auf bestimmte Verzeichnisse. Nutze --tmpfs für temporäre Dateien und explizite Volume-Mounts für persistente Daten. Das --read-only-Flag verhindert, dass ein Angreifer Malware ins Container-Dateisystem schreiben kann.

In Docker Compose

services:
  webapp:
    image: nginx:alpine
    read_only: true
    user: "1000:1000"
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:rw,noexec,nosuid
      - /var/cache/nginx:rw

Container-Images auf Schwachstellen scannen

Vertraue keinem Image blind — auch nicht offiziellen:

# Trivy installieren (https://aquasecurity.github.io/trivy/)
sudo apt install wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | \
  gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | \
  sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt update && sudo apt install trivy

# Image scannen
trivy image nginx:alpine

# Mit Docker Scout (in Docker Desktop integriert)
docker scout cves nginx:alpine

Trivy zeigt dir CVEs (bekannte Schwachstellen) in den Paketen des Images. Mach das vor jedem Deployment und integriere es in deine CI/CD-Pipeline.

Rootless Podman als Alternative

Podman im Rootless-Modus geht noch einen Schritt weiter: Kein Daemon, keine Root-Rechte, gleiche Container-API:

# Podman installieren
sudo apt install podman podman-compose

# Podman rootless - kein sudo nötig
podman run --read-only --user 1000:1000 --cap-drop ALL nginx:alpine

# Docker-Compose-Dateien funktionieren auch
podman-compose up -d

Der größte Unterschied: Bei Docker läuft der Docker-Daemon als Root. Wird dieser kompromittiert, hat der Angreifer Root auf dem Host. Bei Podman rootless existiert kein Daemon — Container laufen im User-Namespace und können niemals Root auf dem Host erlangen.

Seccomp — Syscalls einschränken

Die bisherigen Flags beschränken Capabilities und das Dateisystem. Seccomp (Secure Computing Mode) geht eine Ebene tiefer: Es kontrolliert, welche Kernel-Syscalls ein Container aufrufen darf.

Docker bringt ein Default-Seccomp-Profil mit, das rund 40 gefährliche Syscalls blockiert — darunter reboot, mount, bpf und kexec_load. Für die meisten Anwendungen reicht das. Für internet-exponierte Dienste wie Nginx lohnt sich ein Custom-Profil, das nur die tatsächlich benötigten ~80 Syscalls erlaubt statt der ~300 im Default.

# Prüfen ob Seccomp aktiv ist
docker info | grep -i seccomp
# Ausgabe: Security Options: ... seccomp Profile: builtin

# Im laufenden Container prüfen
cat /proc/self/status | grep Seccomp
# Seccomp: 2 (= filter mode, gewünscht)

Ein Custom-Profil bindest du in Docker Compose so ein:

services:
  webapp:
    image: nginx:alpine
    security_opt:
      - seccomp=./nginx-seccomp.json
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true

Die benötigten Syscalls findest du mit strace:

# Syscalls eines Containers aufzeichnen
docker run --rm --security-opt seccomp=unconfined \
  --cap-add SYS_PTRACE nginx:alpine \
  sh -c "apk add strace && strace -f -c nginx -g 'daemon off;'" 2>&1 | tail -30

Aus der Ausgabe erstellst du ein JSON-Profil im Format {"defaultAction": "SCMP_ACT_ERRNO", "syscalls": [{"names": [...], "action": "SCMP_ACT_ALLOW"}]}. Nur die Syscalls in der Whitelist werden durchgelassen — alles andere blockiert der Kernel.

⚠️ Wichtig: Starte niemals Container mit --security-opt seccomp=unconfined in Produktion. Das deaktiviert Seccomp komplett und gibt dem Container Zugriff auf alle Kernel-Syscalls. Nutze unconfined nur zum Analysieren der benötigten Syscalls.

Kernel-Hardening mit sysctl

Der Linux-Kernel hat Hunderte Parameter, die das Verhalten des Systems beeinflussen. Viele davon sind aus Kompatibilitätsgründen unsicher konfiguriert. Die CIS Benchmarks empfehlen für Debian und Ubuntu eine ganze Reihe von sysctl-Einstellungen — die wichtigsten davon setzt du hier um.

Die Hardening-Konfiguration

Erstelle die Datei /etc/sysctl.d/99-hardening.conf:

# Netzwerk: Schutz gegen IP-Spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Kernel: dmesg nur für Root lesbar
kernel.dmesg_restrict = 1

# Kernel: Keine Kernel-Pointer in /proc leaken
kernel.kptr_restrict = 2

# Kernel: Unprivilegiertes BPF deaktivieren
kernel.unprivileged_bpf_disabled = 1

# Netzwerk: SYN-Flood-Schutz
net.ipv4.tcp_syncookies = 1

# Netzwerk: Kein ICMP-Redirect akzeptieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Netzwerk: Kein Source-Routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Kernel: Ptrace einschränken (Schutz gegen Credential-Dumping)
kernel.yama.ptrace_scope = 2

# Kernel: BPF-JIT-Compiler härten
net.core.bpf_jit_harden = 2

Was bewirken diese Parameter?

Parameter	Wirkung
rp_filter = 1	Pakete mit gefälschter Absender-IP werden verworfen (Reverse Path Filtering)
dmesg_restrict = 1	Kernel-Logs nur für Root — verhindert Information Disclosure
kptr_restrict = 2	Kernel-Pointer werden versteckt — erschwert Kernel-Exploits
unprivileged_bpf_disabled = 1	Normaler User kann kein BPF nutzen — schließt eine ganze Exploit-Klasse
tcp_syncookies = 1	Schutz gegen SYN-Flood-Denial-of-Service
yama.ptrace_scope = 2	Nur Root darf Prozesse debuggen — verhindert Credential-Dumping
bpf_jit_harden = 2	BPF-JIT-Compiler gehärtet — erschwert JIT-Spraying-Angriffe

Anwenden und prüfen

# Alle sysctl-Konfigurationen neu laden
sudo sysctl --system

# Einzelnen Wert prüfen
sysctl kernel.dmesg_restrict
# Ausgabe: kernel.dmesg_restrict = 1

💡 Tipp: Die Datei heißt bewusst 99-hardening.conf. Die Zahl bestimmt die Ladereihenfolge — mit 99 werden deine Härtungseinstellungen zuletzt geladen und überschreiben eventuelle Defaults aus anderen Konfigurationen.

systemd Service-Hardening

systemd bietet Sandboxing-Optionen, die oft übersehen werden. Damit kannst du jeden Dienst in eine Sandbox sperren, selbst wenn der Dienst selbst keine Sicherheitsfeatures hat.

Aktuellen Sicherheits-Score prüfen

# Sicherheitsanalyse für einen Dienst
systemd-analyze security sshd.service

Die Ausgabe zeigt eine detaillierte Liste aller Sandboxing-Optionen und einen EXPOSED-Score von 0.0 (komplett gehärtet) bis 10.0 (keinerlei Einschränkungen). Dein Ziel: unter 5.0 kommen.

Service-Override erstellen

Statt die Original-Unit-Datei zu bearbeiten, nutzt du einen Override:

sudo systemctl edit mein-dienst.service

Das erstellt eine Datei unter /etc/systemd/system/mein-dienst.service.d/override.conf. Dort fügst du die Hardening-Optionen ein:

[Service]
# Dateisystem-Schutz
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes

# Privilege-Einschränkungen
NoNewPrivileges=yes
CapabilityBoundingSet=
RestrictSUIDSGID=yes

# Netzwerk-Einschränkungen (falls der Dienst kein Netzwerk braucht)
# PrivateNetwork=yes

# Weitere Isolation
RestrictNamespaces=yes
RestrictRealtime=yes
MemoryDenyWriteExecute=yes
LockPersonality=yes

Was bewirken diese Optionen?

Option	Wirkung
ProtectSystem=strict	Gesamtes Dateisystem wird read-only gemountet
ProtectHome=yes	Kein Zugriff auf /home, /root, /run/user
PrivateTmp=yes	Eigenes /tmp — kein Zugriff auf das /tmp anderer Dienste
NoNewPrivileges=yes	Keine Rechteausweitung möglich (kein setuid, kein Capability-Gain)
CapabilityBoundingSet=	Alle Linux-Capabilities werden entzogen (leerer Wert = keine)

# Dienst neu laden und Score prüfen
sudo systemctl daemon-reload
sudo systemctl restart mein-dienst.service
systemd-analyze security mein-dienst.service

⚠️ Wichtig: Aktiviere die Optionen schrittweise und teste nach jeder Änderung ob der Dienst noch funktioniert. ProtectSystem=strict ist die aggressivste Option — manche Dienste brauchen Schreibzugriff auf bestimmte Verzeichnisse. Nutze in dem Fall ReadWritePaths=/var/lib/mein-dienst um gezielt Ausnahmen zu definieren.

Vorher/Nachher-Vergleich

# Score OHNE Hardening
systemd-analyze security mein-dienst.service
# → EXPOSED 9.2 UNSAFE 😨

# Score MIT Hardening
systemd-analyze security mein-dienst.service
# → EXPOSED 3.1 OK 🟢

Von 9.2 auf 3.1 — nur durch ein paar Zeilen Konfiguration. Das lohnt sich für jeden Dienst auf deinem Server.

SSH-FIDO2 — Authentifizierung mit Hardware-Key

Passwörter lassen sich phishen. Selbst SSH-Keys als Datei auf der Festplatte können bei einem kompromittierten Client gestohlen werden. FIDO2-Hardware-Keys lösen beide Probleme: Der private Schlüssel liegt auf dem Token und verlässt ihn nie — jede Authentifizierung erfordert physischen Kontakt mit dem Key.

OpenSSH unterstützt FIDO2 seit Version 8.2. Debian 12 (OpenSSH 9.2) und Ubuntu 24.04 (OpenSSH 9.6) bringen volle Unterstützung mit.

FIDO2-Key generieren

# ed25519-sk Key erstellen — Hardware-Key muss angesteckt sein
ssh-keygen -t ed25519-sk -O verify-required -C "user@yubikey-$(date +%Y)"

# Der Key blinkt — berühren zum Bestätigen
# Ergebnis: ~/.ssh/id_ed25519_sk (Key-Handle, NICHT der private Schlüssel)

Das -O verify-required-Flag erzwingt die PIN-Eingabe bei jeder Anmeldung. Damit greifen drei Faktoren:

Faktor	Was wird geprüft
Besitz	Hardware-Key muss physisch angesteckt sein
Präsenz	Key muss berührt werden (Blinken)
Wissen	FIDO2-PIN muss eingegeben werden

Resident Keys für mehrere Rechner

Standard-Keys speichern den Key-Handle als Datei auf der Festplatte. Wenn du von verschiedenen Rechnern aus arbeitest, nutze Resident Keys — die liegen direkt auf dem Token:

# Resident Key mit PIN-Pflicht
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "user@yubikey-resident"

# An einem neuen Rechner: Key vom Token laden
ssh-keygen -K
mv id_ed25519_sk_rk* ~/.ssh/
chmod 600 ~/.ssh/id_ed25519_sk_rk

Server-Konfiguration

Auf dem Server erstellst du ein Drop-in für sshd:

# /etc/ssh/sshd_config.d/fido2-hardened.conf
PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3

# Syntax prüfen und neu laden
sudo sshd -t && sudo systemctl reload sshd

# WICHTIG: Bestehende SSH-Session offen lassen und in neuem Terminal testen
ssh -i ~/.ssh/id_ed25519_sk user@server -v
# Der Hardware-Key blinkt — berühren und PIN eingeben

Warum FIDO2 statt TOTP?

	FIDO2	TOTP (Authenticator-App)
Phishing-resistent	Ja — kryptographisch an den Server gebunden	Nein — Code kann abgefangen werden
Shared Secret	Nein — asymmetrisch, Private Key auf dem Token	Ja — Seed auf Server und Client
Man-in-the-Middle	Geschützt durch Origin-Binding	Verwundbar
Backup	Zweiten Hardware-Key kaufen	Seed aufschreiben

⚠️ Wichtig: Richte immer zwei Hardware-Keys ein und hinterlege beide Public Keys auf dem Server. Wenn ein Key verloren geht, kommst du über den zweiten noch rein. Ohne Backup-Key sperrst du dich aus.

Alles zusammen: Defense in Depth

Die sechs Maßnahmen in diesem Artikel greifen auf verschiedenen Ebenen und ergänzen sich gegenseitig. Das ist der Kern von Defense in Depth — Verteidigung in der Tiefe:

1. Dienste deaktivieren — Angriffsfläche verkleinern
2. AppArmor — Mandatory Access Control über Linux-Rechte hinaus
3. Container härten — Isolation, minimale Rechte und Seccomp-Profile
4. Kernel-sysctl — Kernel-Exploits erschweren
5. systemd-Sandboxing — Jeden Dienst einzeln einsperren
6. SSH-FIDO2 — Phishing-resistente Authentifizierung mit Hardware-Key

Wenn ein Angreifer es schafft, eine Schicht zu durchbrechen, steht er vor der nächsten. Keine einzelne Maßnahme ist perfekt — aber zusammen machen sie einen Angriff sehr aufwändig. Wie alle Schichten im Detail zusammenspielen, zeige ich im Artikel zu Backup & Defense-in-Depth.

Womit fängst du an?

Falls du die Basics noch nicht abgehakt hast: Starte mit der SSH-Server-Absicherung und richte Endlessh als SSH-Tarpit ein. Dann arbeitest du dich durch die Tipps in diesem Artikel — angefangen bei den unnötigen Diensten, weil das am schnellsten geht und sofort Wirkung zeigt.

Jeder dieser Tipps ist ein Schritt in die richtige Richtung.

Die komplette Artikelserie

Diese sechs Artikel bilden zusammen einen Leitfaden für Linux-Server-Sicherheit:

1. SSH-Server absichern — Die Eingangstür härten
2. Netzwerk-Sicherheit & Firewall — Den Perimeter schützen
3. Linux-Server härten (dieser Artikel) — Die Angriffsfläche minimieren
4. Monitoring & Intrusion Detection — Angriffe erkennen
5. Endlessh SSH Tarpit — Bots aufhalten und beobachten
6. Backup & Defense-in-Depth — Das Sicherheitsnetz und die Gesamtstrategie