So hostest du das KI-Pentesting-Tool Strix auf einem VPS

Ein Pentest per Hand zieht sich über Wochen. Strix fährt einen ersten Durchlauf gegen eine Webanwendung in Stunden und legt zu jedem Fund einen Exploit vor, der tatsächlich greift. Auf deinem eigenen VPS behältst du dabei die Kontrolle über Ziele, Logs und API-Keys, statt sie einer SaaS-Plattform zu überlassen.

Dieser Leitfaden führt dich von der Bereitstellung des Servers über das Docker-Setup und ein isoliertes Testziel bis zum ersten Scan und zur Einbindung in CI/CD.

⚠️ Hinweis zum verantwortungsvollen Einsatz

Teste ausschließlich Systeme, die dir gehören oder für die du eine ausdrückliche schriftliche Erlaubnis hast. Strix auf einem VPS selbst zu hosten, gibt dir kein Recht, fremde Websites, APIs oder Netzwerke zu scannen. Unautorisierte Scans gegen Systeme außerhalb deiner Kontrolle verstoßen in den meisten Rechtsordnungen gegen Gesetze zum Computermissbrauch, unabhängig von Absicht oder Konfiguration. Kläre vor jedem Einsatz den autorisierten Umfang und hol dir, wo möglich, eine schriftliche Erlaubnis.

Was ist Strix?

Strix ist ein KI-Pentesting-Framework, das auf autonomen Agenten aufbaut. Diese Agenten verhalten sich wie echte Angreifer und nicht wie statische Regel-Engines. Sie führen die Zielanwendung dynamisch aus, probieren echte Exploit-Pfade durch und bestätigen jeden Fund mit einem funktionierenden Proof of Concept, bevor er im Bericht landet. Die Abdeckung reicht über die OWASP Top 10 hinaus: SQL- und NoSQL-Injection, defekte Zugriffskontrolle, SSRF, unsichere Deserialisierung, JWT-Manipulation und Server-Side Template Injection. Das Projekt steht quelloffen unter der Apache-2.0-Lizenz. Alle Agentenaktionen laufen in isolierten Docker-Sandboxes.

Voraussetzungen

• Contabo VPS 8 (8 vCores, 24 GB RAM) unter Ubuntu. Das gibt genug Luft für parallele Agentenprozesse und Sandbox-Container, ohne dass sie sich um Ressourcen streiten.
• Docker und das Docker-Compose-Plugin installiert und aktiv.
• Ein sicheres, isoliertes Testziel, das dir gehört oder für das du ausdrücklich autorisiert bist. Richte einen Scan niemals ohne schriftliche Erlaubnis gegen produktive Infrastruktur.
• Ein API-Key eines unterstützten LLM-Anbieters (OpenAI, Anthropic oder Google) für KI-gestützte Aufklärung, Exploit-Planung und Berichterstellung.
• Grundlegende Sicherheit auf der Linux-Kommandozeile. Der komplette Workflow läuft über SSH.

Schritt 1: VPS bereitstellen und Docker installieren

1. Bestell einen Contabo VPS 8 im Customer Control Panel und wähl beim Setup Ubuntu als Betriebssystem.
2. Verbinde dich per SSH mit Key-basierter Authentifizierung. Deaktiviere die Passwort-Authentifizierung in /etc/ssh/sshd_config (setze PasswordAuthentication no) und starte den SSH-Dienst neu, sobald der Login per Key nachweislich funktioniert.
3. Konfiguriere UFW so, dass eingehender Traffic nur über SSH erlaubt ist: führe ufw allow OpenSSH aus, dann ufw enable. Öffne weitere Ports bewusst und nur, wenn du sie brauchst.
4. Installiere Docker und das Docker-Compose-Plugin. Prüfe mit systemctl status docker, ob der Daemon aktiv ist, und füge dann deinen Benutzer zur docker-Gruppe hinzu, damit sich Container ohne sudo verwalten lassen.

Schritt 2: Strix mit Docker Compose ausrollen

Führe den offiziellen Strix-Installer aus und setze anschließend die Umgebungsvariablen für deinen LLM-Anbieter:

curl -sSL https://strix.ai/install | bash

export STRIX_LLM="anthropic/claude-sonnet-4-6"

export LLM_API_KEY="your-api-key"

Strix speichert diese Konfiguration nach dem ersten Lauf in ~/.strix/cli-config.json. Der erste CLI-Aufruf lädt außerdem das Sandbox-Docker-Image, das jede Agentenaktivität vom Host abschottet. Für ein lokales Modell zeigst du mit LLM_API_BASE auf einen selbstgehosteten Endpunkt wie Ollama oder LMStudio. Gehostete Modelle liefern bei komplexen Exploit-Ketten allerdings meist konsistentere Ergebnisse.

Schritt 3: Ein Testziel einrichten

1. Zieh dir den Container der Damn Vulnerable Web App (DVWA) und starte ihn auf demselben VPS:

docker run -d -p 8080:80 vulnerables/web-dvwa

• Prüfe, ob DVWA erreichbar ist: ruf die IP-Adresse des VPS auf Port 8080 im Browser auf und durchlauf den Einrichtungsbildschirm für die Datenbank, der das verwundbare Backend initialisiert.
• Merk dir die Zieladresse, etwa http://127.0.0.1:8080 für lokale Tests. Diesen Wert übergibst du Strix im Scan-Befehl.
• Optional stellst du die eingebaute Sicherheitsstufe von DVWA um, um zu vergleichen, wie gründlich Strix teilweise abgesicherte gegenüber komplett offenen Schwachstellen durcharbeitet.

Schritt 4: Einen Scan starten und den Bericht lesen

Starte einen Scan über die CLI:

strix -n --target http://127.0.0.1:8080 \

  --instruction "Focus on DVWA's known vulnerability categories including SQL injection, XSS, and command injection"

Der Flag -n startet Strix im nicht-interaktiven Modus, der sich für SSH-Sessions eignet. Er gibt Funde in Echtzeit aus und beendet den Lauf mit einem Exit-Code ungleich null, sobald Schwachstellen bestätigt sind. Die vollständigen Ergebnisse liegen auf dem Server unter strix_runs/<run-name>. Jeder Fund enthält einen CVSS-Score, einen funktionierenden Proof of Concept und eine Handlungsempfehlung in klarer Sprache. Priorisiere nach CVSS-Score: höhere Werte deuten auf größere potenzielle Wirkung hin (etwa nicht authentifizierte Remote Code Execution oder eine vollständige Umgehung der Authentifizierung), während niedrigere Werte meist auf informelle Funde verweisen, die sich nur unter ungewöhnlichen Bedingungen ausnutzen lassen.

Schritt 5: In CI/CD einbinden (optional)

Ergänze einen GitHub-Actions-Workflow, der bei jedem Pull Request automatisch einen Strix-Scan fährt und Merges bei kritischen Funden blockiert:

name: strix-penetration-test

on:

  pull_request:

jobs:

  security-scan:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v6

        with:

          fetch-depth: 0

      - name: Install Strix

        run: curl -sSL https://strix.ai/install | bash

      - name: Run Strix

        env:

          STRIX_LLM: ${{ secrets.STRIX_LLM }}

          LLM_API_KEY: ${{ secrets.LLM_API_KEY }}

        run: strix -n -t ./ --scan-mode quick

Die Einstellung fetch-depth: 0 gibt Strix Zugriff auf die vollständige Git-Historie, sodass Quick-Scans nur die in einem Pull Request geänderten Dateien anvisieren, statt die gesamte Codebasis erneut zu prüfen. Da der Workflow bei gefundenen Schwachstellen mit einem Exit-Code ungleich null endet, kann er einen PR so lange am Merge hindern, bis die kritischen Funde behoben sind.

FAQ: Strix auf einem VPS betreiben