Kimi K3 prüft ein Homelab: Funde in Proxmox, ein gescheiterter Firewall-Versuch und ein NAS

Der Testaufbau

Berichten zufolge schlug Kimi K3 das Modell Fable 5 von Anthropic in mehreren agentischen Benchmarks. Fable 5 ist das Modell, das die US-Regierung wegen Sicherheitsbedenken kurzzeitig eingeschränkt hatte. Ein offenes Modell auf diesem Niveau warf also eine naheliegende Frage auf: Wie schlägt es sich in einer echten Sicherheitsprüfung statt in einem synthetischen Benchmark?

Ein passendes Testfeld gab es schon. Zum Homelab gehörten ein Proxmox-Server auf einem Mini-PC Beelink SER5 und ein Synology-NAS, beide mit viel Sorgfalt eingerichtet und für ziemlich sicher gehalten. Statt einen Abend mit nmap, Config-Dateien und dem Abklopfen jedes Dienstes von Hand zu verbringen, ging die Aufgabe an einen KI-Agenten: Kimi K3 über OpenCode, mit der Anweisung, die Infrastruktur so anzugreifen, wie es ein externer Auditor tun würde. Das war keine Simulation. Der Agent führte echte Befehle auf echten Maschinen aus, analysierte die Ausgabe, schlug Korrekturen vor und änderte, wo es erlaubt war, Produktivsysteme.

Runde eins: der Proxmox-Server

Der Prompt war knapp:

Hier ist ein Proxmox-Server: XXX.XXX.XXX.XXX. Versuch einzubrechen.

Der Agent begann mit gewöhnlicher Aufklärung. Er prüfte die Verbindung, stellte fest, welche Tools installiert waren, und startete einen nmap-Scan. Der zeigte drei offene Dienste: SSH auf Port 22, die Proxmox-Weboberfläche auf 8006 und den SPICE-Proxy auf 3128.

Dann meldete er etwas, das nach einer ernsten Kompromittierung aussah:

Kritische Schwachstelle gefunden: root kann sich per SSH ohne Passwort und ohne Schlüssel anmelden.

Das klang übel, bis der Agent eine weitere Minute authorized_keys untersuchte und merkte, dass der „unbefugte“ Login der Schlüssel der eigenen Workstation des Besitzers war. Er hatte vorschnell geurteilt, sammelte aber anders als viele automatische Scanner weiter Belege, bis er seine eigene Behauptung widerlegt hatte. Der Fehlalarm erledigte sich von selbst, weil die Überprüfung weiterlief.

Was er wirklich fand

Nachdem das Missverständnis bei der Authentifizierung geklärt war, wechselte der Agent in den Audit-Modus und lieferte einen vernünftigen Bericht:

Finding                                               Severity
Firewall disabled with default ACCEPT policy            High
Fail2Ban not installed                                  High
rpcbind exposed on every interface                      Medium
Proxmox web interface accessible to the network         Medium

Nichts davon war überraschend, und fast alles war schon bekannt. Fail2Ban und eine Firewall standen seit der Proxmox-Installation vor rund anderthalb Jahren auf der To-do-Liste. Wie viele Homelab-Admins hatte der Besitzer das auf „später“ verschoben.

Die Korrekturen

Nach dem Lesen der Ergebnisse erlaubte der Besitzer dem Agenten, sie zu beheben. Zuerst prüfte er die SSH-Konfiguration mit sshd -T. Die Passwort-Authentifizierung war bereits über eine Drop-in-Datei unter sshd_config.d abgeschaltet. Statt den Config-Dateien zu vertrauen, prüfte der Agent die tatsächlich wirksamen Laufzeiteinstellungen und bestätigte, dass Passwort-Logins wirklich deaktiviert waren.

Als Nächstes kam Fail2Ban. Proxmox liefert keinen passenden Filter für pveproxy mit, also schrieb der Agent einen für fehlgeschlagene Anmeldungen:

# /etc/fail2ban/filter.d/proxmox.conf
[Definition]
failregex = ^.*pveproxy\[.*\]: authentication failure; rhost=<HOST>.*$
            ^.*: authentication failure; rhost=<HOST>.*$
ignoreregex =

Seine beste Entscheidung betraf rpcbind. Der Standardrat wäre gewesen, den Dienst abzuschalten. Der Agent prüfte erst, ob etwas davon abhing, und fand eine NFSv4.1-Freigabe vom Synology-NAS, die Monate zuvor eingebunden und dann vergessen worden war. rpcbind abzuschalten hätte die Storage-Mounts und die Backup-Jobs lahmgelegt. Statt einer generischen Härtungs-Checkliste zu folgen, schaute der Agent also auf den tatsächlichen Zustand des Systems und schlug vor, rpcbind nur an lokale Adressen zu binden.

Wo er hängen blieb

Bei der Firewall lief es anders. Der Agent erzeugte sowohl cluster.fw als auch host.fw, aber Proxmox wollte das Ergebnis nicht kompilieren:

$ pve-firewall compile
/etc/pve/nodes/pve1/host.fw (line 3): can't parse option 'policy_in: DROP'

Alles sah aus wie in der Dokumentation, trotzdem lehnte der Parser es immer wieder ab. Nach drei Anläufen griff der Besitzer ein und ließ den Agenten alle Firewall-Änderungen rückgängig machen. Er löschte die erzeugten Dateien, stoppte pve-firewall, stellte den vorherigen iptables-Zustand wieder her und hinterließ die Maschine genau so, wie er sie vorgefunden hatte. Diese Fähigkeit zum Rollback war fast so wertvoll wie die Korrekturen. Automatisierung nützt nur, wenn sie sich nach einem Fehler sicher erholen kann. Die Firewall wurde schließlich von Hand eingerichtet.

Runde zwei: das Synology-NAS

Nach Runde eins wurde der Agent auf das NAS angesetzt:

Unter YYYY.YYYY.YYYY.YYYY steht ein Synology-NAS. Bewerte, wie sicher es ist.

Bei diesem Durchlauf ging es mehr um Überprüfung als um Ausnutzung. Der Scan fand elf offene Dienste, darunter DSM, SMB, NFS, iSCSI, Synology Drive und Active Backup. Auf dem Gerät waren weder nmap noch openssl installiert, und der Agent gab nicht auf. Er schrieb eigene Python-Tools: TLS-Handshake-Tests für jede unterstützte Protokollversion, einen iSCSI-Login-Test, SMB-Aushandlung über Raw Sockets und mehrere protokollspezifische Prüfungen, für die man sonst eigene Werkzeuge braucht.

Was bestanden hat

Einiges war bereits richtig eingestellt:

• TLS bot nur 1.2 und 1.3 mit modernen Cipher-Suites an.
• Anonyme iSCSI-Logins wurden abgewiesen, weil CHAP Pflicht war.
• SMB1-Verbindungen scheiterten sofort, das alte Protokoll war also aus.
• SNMP ignorierte den Standard-Community-String public.
• DSM sendete die erwarteten HTTP-Sicherheitsheader.

Der Agent testete jede Einstellung direkt, statt einfach anzunehmen, dass sie stimmt.

Wo nachgebessert werden musste

Das größte Problem war DSM selbst. HTTP blieb auf Port 5000 aktiv, ohne Weiterleitung auf HTTPS, und die Login-Seite verriet die Einstellung ganz offen:

<input type="hidden" id="prefer_https" name="prefer_https" value="false">

Wer sich über HTTP anmeldet, schickt seine Zugangsdaten unverschlüsselt. In einem vertrauenswürdigen Heimnetz ist das nicht zwingend eine Katastrophe, aber ein unnötiges Risiko, und es zeigt, wie lange Standardeinstellungen nach der Inbetriebnahme bestehen bleiben. Dazu kamen kleinere Punkte: Das NAS nutzte noch ein selbstsigniertes Zertifikat statt Let's Encrypt, NFS-Exporte hatten keine Firewall-Beschränkung nach Client-IP, und Active Backup hielt Port 6281 offen, obwohl der Dienst nicht mehr genutzt wurde.

Was das Experiment gezeigt hat

Überraschend war nicht, dass eine KI Sicherheitslücken fand, sondern welche Art von Arbeit sie gut erledigte. Kimi K3 verhielt sich nicht wie ein erfahrener Penetrationstester, und davon sind einem über die Jahre einige begegnet. Es verhielt sich wie ein akribischer Junior-Security-Engineer, der nie müde wird, Logs zu lesen, Protokollversionen zu testen, Annahmen zu hinterfragen und jeden offenen Dienst zu überprüfen.

Genau diese Arbeit schieben Menschen vor sich her, weil sie eintönig ist. Das deckt sich mit früheren Experimenten mit LLMs zur Betriebsautomatisierung: Sie nehmen einem mühsame Prüfarbeit ab, verlieren nicht auf halber Strecke einer Checkliste das Interesse und haben kein Problem damit, eine Prüfung hundertfach zu wiederholen. Außerdem waren sie vorsichtiger als erwartet. Bevor das Modell einen Dienst abschaltete, prüfte es Abhängigkeiten im Produktivbetrieb und verhinderte so einen Ausfall, den generische Härtungstipps verursacht hätten.

Menschliche Aufsicht bleibt trotzdem wichtig. Die Firewall kam nie bei einer gültigen Konfiguration an, und allein gelassen hätte der Agent vermutlich endlos kleine Änderungen vorgenommen. Erst die Anweisung zum Rollback stellte einen sauberen Zustand wieder her.

Eine Einschränkung: Das Lab ist nur intern über WireGuard erreichbar, die Prüfung betraf also das private Netz und keine Systeme mit Internetzugang. Die Ergebnisse waren den Aufwand trotzdem wert.