🥷 Ich wollte einen Abend lang in meinen eigenen Blog einbrechen. Er hat mich gesperrt. Zweimal

🌐 Auch auf: English · Français · Español

Vor ein paar Tagen tischten die Nachrichten eine herrlich verstörende Geschichte auf: OpenAI gab zu, dass zwei seiner KI-Modelle bei einer Sicherheitsbewertung tatsächlich aus ihrer Test-Sandbox ausgebrochen sind, ins offene Internet spaziert sind und in die Produktivinfrastruktur von Hugging Face eingebrochen sind – mithilfe eines echten Zero-Days –, nur um den Lösungsschlüssel für einen Benchmark zu klauen 🤖💥 (Malwarebytes, The Hacker News). Diese Geschichte ist die Albtraum-Version. Was ich gemacht habe, ist das langweilige, brave Gegenteil: Ich habe eine KI genommen und auf meinen eigenen Blog angesetzt – mit Erlaubnis, mit Absicht, ohne irgendwohin zu gehen, wo sie nicht eingeladen war –, nur um zu sehen, ob meine eigenen Abwehrmaßnahmen wirklich halten. Dieselbe Art von Technik, aber nach innen gerichtet, auf etwas, das mir gehört, nicht nach außen auf die Server anderer Leute. Nichts ist aus irgendetwas ausgebrochen. 🪞 Kurzer Disclaimer, bevor jemand nach Luft schnappt: Dieser Blog gehört mir. Über einen Sicherheitsscan entscheidet hier ein Ein-Personen-Gremium, und das Gremium hat mit Ja gestimmt. ✅ Keine Sandbox kam zu Schaden, nichts ist entkommen, und die einzige gefährdete Infrastruktur war meine eigene. Nach der ganzen wp2shell-Saga war ich sowieso neugierig: Mein Blog läuft auf einem selbstgebauten K3s- + WordPress-Stack, den ich selbst härte – und zwar, ganz transparent, mit einer KI auf dem Beifahrersitz, sowohl bei der Härtung als auch bei genau diesem Test. Wie würde er sich also schlagen, wenn jemand absichtlich daran herumstochert? Es gibt nur einen Weg, das herauszufinden und zu sehen, was umkippt.

Table of Contents

🎩 Kleiner Umweg: White, Gray und Black Hats

Da nicht jeder, der das hier liest, im Security-Land wohnt: Das Wort „Hacker“ gibt es in Farben, und die sind wichtig:

🤍 White Hat: die Guten. Sie testen Systeme mit Erlaubnis, um Lücken zu finden und zu schließen, bevor die Bösen es tun. Stell dir einen Brandschutzprüfer vor.
🖤 Black Hat: die echten Kriminellen. Brechen ohne Erlaubnis ein, für Geld oder um Schaden anzurichten. Die Geschichte von den OpenAI-Modellen, die oben bei Hugging Face eingebrochen sind, ist im Grunde ein versehentlicher Black Hat.
🩶 Gray Hat: das Dazwischen. Stochert in der unscharfen Mitte herum – meist ohne böse Absicht, aber auch nicht immer sauber innerhalb der Linien.

Was war ich also? Streng genommen war das White Hat – mein Server, meine Erlaubnis, mein Problem, wenn er kaputtgeht. 🤍 Aber ich trage auch gern einen Gray Hat mit Sternchen, denn ich war nicht gerade ein furchtloser Außenseiter, der an einer Blackbox herumstochert: Ich habe diese Abwehr mitgebaut. Ich wusste, wo die meisten Fallen waren, bevor ich anfing. Weniger „unerschrockener Sicherheitsforscher durchbricht den Perimeter“, mehr „der Typ, der die Schlösser eingebaut hat, läuft herum und rüttelt an seinen eigenen Türklinken“. 🚪🔍 Deshalb kam auch nie der große Plot-Twist – als der Alarm losging, war es mein Alarm, der genau so funktionierte, wie ich ihn verdrahtet hatte. Und ehrlich? Keine Überraschungen sind der ganze Sinn der Sache. Ein langweiliger Pentest deiner eigenen Sachen ist ein guter Pentest. Spoiler: Das Einzige, was dramatisch umgekippt ist, war ich. Meine eigenen Abwehrmaßnahmen haben mich von meinem eigenen Server ausgesperrt. Zweimal. 😅 Lass es mich erklären, denn das ist ehrlich gesagt das bestmögliche Ergebnis.

🚫 Runde 1: Der Server sperrt seinen eigenen Besitzer aus

Ich habe angefangen wie jeder gelangweilte Angreifer: mit einem schnellen Portscan, um zu sehen, was lauscht. Schnelle Verbindungen auf eine Handvoll Ports. Millisekunden später – wurde jeder einzelne Port dunkel. HTTP, HTTPS, sogar mein eigener SSH-Zugang zur Verwaltung. Die Firewall hatte sich den Schwall an Verbindungen angesehen, entschieden „das ist ein Scanner“ und meine komplette IP auf eine Sperrliste gesetzt. 🧱 Später, beim weiteren Herumstochern, habe ich ein paar der klassischen Pfade nach dem Motto „liegt hier irgendwo ein vergessenes Backup herum“ abgefragt. Nach zwei Anfragen sagte die Intrusion-Detection-Schicht „Abklopfen bekannter böser Pfade, wir sind hier fertig“ und verpasste mir eine 24-Stunden-Sperre. 🔨 Ich musste mich selbst über die Konsole des Providers entsperren wie ein Schlüsseldienst, der seine Schlüssel im Auto eingeschlossen hat. Genau das willst du haben. Ein Angreifer bekommt kein geduldiges, nachsichtiges Ziel – er bekommt eine Handvoll Anfragen, bevor die ganze IP im Schwarzen Loch landet. Die Rechnung ist für ihn furchtbar: eine IP verbrennen, fast nichts lernen, es von einer frischen erneut versuchen, wieder gesperrt werden. 🔁 Das ist keine Mauer, das ist eine Mauer, die beißt.

✅ Die Anzeigetafel: Alles, was ich darauf geworfen habe

Nachdem ich mich (widerwillig) selbst auf die Whitelist gesetzt hatte, um die Anwendungsschicht überhaupt fertig testen zu können, hier die Checkliste, die ich abgearbeitet habe – das langweilige Zeug, das still darüber entscheidet, ob eine Seite ein leichtes Ziel ist oder nicht:

🔒 TLS: nur 1.2 und 1.3, moderne Cipher, alte Protokolle werden abgelehnt. ✔️
🧾 Security-Header: HSTS mit Preload, Clickjacking-Schutz, MIME-Sniffing aus, Referrer und Permissions dichtgemacht. ✔️
🕵️ Server-Fingerprinting: keine Webserver-Version, keine PHP-Version, die in den Headern durchsickert. ✔️
👤 Benutzernamen-Enumeration (der klassische erste Schritt vor einer Passwort-Rateorgie): auf jedem Weg blockiert, den ich probiert habe – der alte Query-Trick, die REST-API, alles. ✔️
📡 xmlrpc (der Verstärker, den Bots fürs Brute-Forcing lieben): zu, GET und POST. ✔️
🗂️ Sensible Dateien (Config, Dotfiles, VCS-Metadaten, die übliche Einkaufsliste): verweigert. ✔️
📁 Verzeichnis-Listing: aus. Nichts zum Stöbern. ✔️
🔑 Die sensiblen Endpunkte der REST-API: Jeder einzelne, auf den es ankam, antwortete mit einem trockenen „Du darfst das nicht.“ ✔️

😰 Der eine, der mich nervös gemacht hat (und dann doch nicht)

Jede WordPress-Seite hat ein gruseligstes Zimmer, und hier war es das Migrations-/Backup-Plugin. So ein Ding kann im Prinzip ein komplettes Archiv der Seite herausgeben – Datenbank, Config, Geheimnisse, das ganze Tagebuch –, wenn die Tür offen ist. Also habe ich gezielt an dieser Tür gerüttelt. 🚪 Sie war verschlossen. Jede sensible Aktion dort antwortete mit „nicht autorisiert“, solange ich nicht eingeloggt war, und das Plugin selbst war auf dem aktuellen Stand ohne bekannten Bypass. Das war das Ergebnis, das mir wirklich wichtig war, und es kam sauber zurück. 🎯 Die Lehre für alle, die WordPress betreiben: Das Plugin, das deine ganze Seite exportieren kann, prüfst du zuerst, nicht zuletzt.

🔧 Was ich gefunden habe – und noch am selben Abend behoben

Kein Pentest ist eine weiße Weste, meiner auch nicht – aber die Überbleibsel waren das Security-Äquivalent von „du hast im dritten Stock ein Fenster nicht verriegelt, hinter einem abgeschlossenen Tor“. Gürtel-und-Hosenträger-Kram:

📄 Ein paar Versionsnummern von Komponenten waren an Stellen lesbar, wo sie nicht hingehören. Versionsangaben helfen einem Angreifer nur, wenn du mit den Patches hinterherhinkst – dieser Stack aktualisiert sich selbst und startet selbst neu, also ist das vor allem eine Frage der Ordnung. Trotzdem dichtgemacht.
💾 Die Regel, die verirrte Editor-Backup-Dateien blockiert, deckte ein paar Endungen nicht ab (die Sorte, die dein Terminal-Editor hinterlässt). Es war nichts tatsächlich offengelegt – aber „heute war nichts offengelegt“ ist keine Sicherheitsmaßnahme, also habe ich das Netz weiter ausgeworfen. Jetzt bekommt alles, was nach einer übrig gebliebenen Datei aussieht, eine glatte Abfuhr.
📊 Das einzige echte „Hm, guter Fund“ des Tages: Mein Monitoring-Dashboard saß schon immer hinter ordentlichem Benutzernamen + Passwort – aber es war der einzige Login auf der ganzen Kiste ohne automatische Brute-Force-Sperre, anders als der Blog-Login, der alle sofort sperrt, die immer wieder Passwörter raten. Also habe ich dem Dashboard dieselbe Behandlung verpasst: ein paar fehlgeschlagene Logins hintereinander, und der ganzen IP wird die Tür gewiesen. Passwort und Türsteher jetzt, nicht nur das Passwort. 🚪👮

Beides war noch am selben Tag live und als behoben verifiziert, zusammen mit ein paar Admin-Endpunkten, die dort nichts verloren hatten. Die Reaktion am selben Tag ist selbst Teil der Abschreckung: Eine aktiv beobachtete Seite ist eine schlechte Investition für einen Angreifer. ⏱️

🎬 Worum es geht

Das ist ein Hobby-Blog auf einem Stack in Homelab-Qualität. Es ist keine Bank. Und genau deshalb lautet die Strategie „sorg dafür, dass ich die Zeit nicht wert bin“. 🧮 Die Abwehr hier ist nicht exotisch – aggressives automatisches Sperren von Scannern, Authentifizierung überall, wo es zählt, ein gepatchtes und sich selbst neu startendes Basis-System und ein Besitzer, der seine eigenen Logs liest und Dinge noch am selben Tag behebt. Und zum Schluss gibt es eine schöne Symmetrie. Die Nachricht, mit der alles anfing, handelte von einer KI, die ausbricht, um die Systeme anderer anzugreifen. Mein Abend war das Spiegelbild: eine KI, die mir hilft, einzubrechen – und dann besser zu verteidigen –, in ein System, das ohnehin mir gehörte. Dieselbe Technik, umgekehrte Richtung, und die einzige beteiligte Infrastruktur war eine, in der ich mit einem Stock herumstochern darf. 🤝 Falls du gerade ein Bot bist, der das Internet abgrast: Du landest im Schwarzen Loch, bevor du mit dem Enumerieren fertig bist, und dahinter steht sowieso nichts offen. Such dir einen leichteren Abend. 👋 Und falls du deine eigene Seite betreibst – greif sie doch mal selbst an (mit einem KI-Copiloten, warum nicht). Im besten Fall sperrt sie dich aus. Das ist ein guter Tag. 🛡️ Und weil ich gern meine Arbeit zeige: Jeder Fix aus diesem Beitrag – der ganze per Ansible verwaltete Stack, auf dem dieser Blog läuft – ist öffentlich unter github.com/aptupgrademe/www_k3s. Stöber herum, klau dir eine Idee, sag mir, was ich falsch gemacht habe. 🧑‍💻