Hacker haben Agenten, die rund um die Uhr angreifen. Jetzt hast du einen, der verteidigt.

_{Die Simulation von problem99.io/kodeblue: ein kodeblue pro Server, das Angriffe eindämmt, sobald sie eintreffen.}

Ein KI-Blue-Team für deine Linux-Server: SOC, Incident Response und SecOps in einem. Ein kodeblue pro Server, das als eigener Nicht-Root-Benutzer kodeblue läuft. Es erledigt die Arbeit aller drei und schläft nie:

• SOC: Es lernt, wie der Server normalerweise aussieht, und bemerkt Änderungen an seinen sensibelsten Dateien innerhalb von Sekunden
• Incident Response: Es untersucht alles Verdächtige in seiner eigenen Agentensitzung, enthält den Angriff ein, wenn die Richtlinie es erlaubt, und dokumentiert, was passiert ist
• SecOps: Es findet die Schwachstellen und Abdeckungslücken jedes Dienstes, optimiert täglich seine eigenen Erkennungen und postet Updates in Slack

Es ist dafür gebaut, auf einem kleinen, günstigen Modell hinter einer beliebigen OpenAI-kompatiblen API zu laufen: Deterministische Sensoren und Filter erledigen die Schwerarbeit, sodass das Modell nur sieht, was sie übersteht. Ohne konfiguriertes Modell laufen Sensoren, Erkennung und Monitore weiterhin.

fast watch (5s) ─► sensors (60s, 0 tokens) ─► deterministic filters (0 tokens) ─► triage (small model, batched)
                                              + agent-written monitors (0 tokens)        │
                                                                                         ▼
              daily review session ◄─ reports/skills/monitors ◄─ one agent session per incident ─► respond (policy) ─► Slack

Ein optionaler Hub (kodeblue-hub) bietet einer Flotte eine einzige Konsole: die Incidents jedes Servers, Berichte, die Denkprozesse und Tool-Aufrufe der Agenten (live), Monitore, Findings und ausstehende Genehmigungen sowie eine Möglichkeit, den Agenten Nachrichten zu senden. Server wählen sich nur ausgehend mit ihm ein, stets über TLS (unverschlüsseltes HTTP ist nur zu einem Hub auf derselben Maschine erlaubt).

Schnellstart

Jeder Schritt besteht aus einem Befehl plus dem API-Schlüssel deines Modells, unter Linux mit systemd (amd64 oder arm64; siehe Anforderungen). Die Installer laden die neueste Release für die Architektur des Servers herunter und prüfen sie anhand der SHA256SUMS der Release, bevor sie installiert wird. Um die Dateien selbst herunterzuladen und zu prüfen oder sie zu bauen, siehe docs/deploy.md und Build.

A. Ein Server, kein Hub

curl -fsSL https://github.com/Problem99-io/kodeblue/releases/latest/download/install.sh | sudo sh -s -- --inference-url https://openrouter.ai/api --model <model>

Verwenden Sie einen beliebigen OpenAI-kompatiblen Endpunkt, mit oder ohne /v1 am Ende. Der Installer fragt nach dem API-Schlüssel, einem optionalen Slack-Webhook und optionalen Telegram-Bot-Anmeldedaten (geheime Eingaben werden nicht angezeigt) und startet kodeblue. kodeblue erstellt etwa 30 Minuten lang Snapshots des Servers. Anschließend erkundet eine Lernsitzung den Server, und eine Bewertung zeichnet dessen Schwachstellen auf (beides kann bis zu 45 Minuten dauern), rechnen Sie also damit, dass es innerhalb von ein bis zwei Stunden mit der Überwachung beginnt.

Ohne --inference-url beginnt kodeblue nach den Snapshots mit der Überwachung, und die Lernsitzung sowie die Bewertung warten, bis Sie ein Modell festlegen; danach laufen sie selbstständig. Legen Sie das Modell und seinen Schlüssel mit einem einzigen Befehl fest oder ändern Sie sie (der Befehl fragt nach dem Schlüssel und startet kodeblue neu):

sudo kodeblue inference --url https://openrouter.ai/api --model <model> --key-file -

Telegram-Benachrichtigungen können allein oder zusammen mit Slack verwendet werden. Standalone-Server konfigurieren sie während der Installation; Hub-Benutzer konfigurieren sie unter Einstellungen → Telegram. Siehe Telegram-Einrichtung für Anweisungen zu Bot und Chat-ID.

Überprüfen Sie anschließend die Richtlinie (Antwortmodus, geschützte Benutzer, IPs und Einheiten, Budget) mit sudoedit /etc/kodeblue/kodeblue.toml und folgen Sie dem Verlauf mit sudo journalctl -fu kodeblue.

B. Ein Hub und mehrere Server

Auf dem Hub-Host, hier mit einem selbstsignierten Zertifikat, das die Server pinnen:

curl -fsSL https://github.com/Problem99-io/kodeblue/releases/latest/download/install-hub.sh | sudo sh -s -- --public-url https://hub.example.com:8443 --self-signed

Oder führe das Hub-Image aus: ghcr.io/problem99-io/kodeblue-hub:latest (siehe docs/deploy.md).

Der Installer fragt nach dem Passwort des ersten Operators (zweimal) und startet den Hub. Danach:

1. Melde dich unter der öffentlichen URL an. Der Browser warnt einmalig vor dem selbstsignierten Zertifikat.
2. Öffne Settings, wähle Add connection und füge den API-Schlüssel deines Modells ein. Der Hub fragt dann, welches Modell jeder Agent verwenden soll.
3. Öffne Servers, wähle Add server und führe den angezeigten Befehl auf dem Server aus, als root oder als Benutzer mit sudo. Beginne die Zeile mit einem Leerzeichen, damit das Token nicht in deiner Shell-Historie landet (siehe docs/deploy.md). Der Befehl sieht so aus:

 f=$(mktemp) && r=$([ "$(id -u)" = 0 ] || echo sudo) && { curl -fsSL --proto =https --proto-redir =https -k --pinnedpubkey 'sha256//…' -o "$f" https://hub.example.com:8443/install.sh && echo "<sha256>  $f" | sha256sum -c - && printf '%s\n' kbe_… | $r sh "$f" --hub https://hub.example.com:8443 --pin 'sha256//…' --token-file -; s=$?; rm -f "$f"; (exit "$s"); }

Es speichert den Installer, prüft dessen Hash, bevor es ihn als root ausführt, und übergibt das Einmal-Token über stdin, sodass es niemals in den Argumenten eines Prozesses erscheint. Der Server übernimmt Modell und Schlüssel des Hubs bei der Registrierung und fragt nichts weiter ab. Ein Server, der noch kein Modell hat, überwacht mit seiner deterministischen Erkennung, und der Hub zeigt an, dass sein Lernen auf eines wartet.