KI-Monitoring mit Claude MCP: Cloudflare & Firewall im Griff

mehrstufig absichern, ausbauen, erkennen, beobachten, sperren. Jede Schicht einzeln schaltbar, messbar und umkehrbar.

Außen sitzt Cloudflare mit DDoS-Schutz, Firewall-Regeln und Rate Limiting: Was zu schnell und zu viel kommt, wird gedrosselt. Verschlüsselung greift ab TLS 1.2; alles darunter lehnt das System ab. KI-Sammler werden gesperrt, und wer sich nicht ausweist und trotzdem mitliest, läuft in ein Honeypot (Link Maze Injection) für Crawler. Dahinter arbeitet ein Edge-Proxy (Caddy) als Vermittler zwischen den Netzen: Die Website hat keinen eingehenden Port. Der Tunnel geht nur nach draußen, das Produktivsystem liegt in der DMZ (Demilitarisierte Zone). Auf den Servern liest CrowdSec die Logs mit und erkennt Angriffsmuster in Echtzeit.

Als Security Layer sind zwei Komponenten vorgesehen: Ein lokaler Firewall-Bouncer auf nftables-Basis blockiert erkannte Angreifer direkt über deren IP-Adresse auf dem Server. Parallel dazu trägt ein Cloudflare-Bouncer dieselben IP-Sperren bis an die Cloudflare-Kante (Edge). So wird schädlicher Datenverkehr blockiert, noch bevor er die Server-Infrastruktur überhaupt erreicht.

Ein nftables-Bouncer sperrt erkannte Angreifer direkt lokal aus. Gleichzeitig spiegelt ein Cloudflare-Bouncer diese Sperren bis an die Cloudflare-Edge. Angriffe erreichen den Server in der DMZ so erst gar nicht. Für klassische Setups lässt sich Fail2ban optional einbinden. Nach erfolgreicher Testphase und nachgewiesener Fehlalarmfreiheit ist das System nun scharf geschaltet. Fernzugriffe laufen über eine Handvoll fest definierter Aktionen, eine offene Shell gibt es dafür nicht. Rund um die Uhr wachen sechs Live-Dashboards sowie ein KI-gestütztes Monitoring über all dem.

Wie das in der Praxis aussieht, zeigt die folgende Szene: Das Monitoring arbeitet 24h/7 ohne Pause. Bugs, Fehlkonfigurationen, offene Ports, ablaufende Zertifikate: alles wird erfasst, beurteilt und erledigt oder ausgeschaltet, bevor es die produktive Umgebung beeinflusst. Der Unterschied liegt darin, dass dieses Monitoring selbst handelt, statt nur ein Ticketsystem zu beschäftigen.

Dabei geht der Nutzen über den eigenen Betrieb hinaus. Kontinuierliches, KI-gestütztes Monitoring wirkt als Sicherheitsnetz, unabhängig davon, wer ein System im Tagesgeschäft betreut. Es prüft Konfiguration und Verhalten laufend gegen den Ist-Zustand und fängt Fehlkonfigurationen sowie Abweichungen ab, bevor sie zum Vorfall werden. Dem Management liefert es eine objektive, nachvollziehbare Kontrollebene. Niemand muss sich so allein auf die Selbsteinschätzung einer einzelnen Fachkraft verlassen. Das ist für jedes Unternehmen relevant, unabhängig davon, wie erfahren das eigene Team ist.

Eines ist mir besonders wichtig: Wenn im Ernstfall die Frage aufkommt, wo eine Ursache lag, entscheidet oft nicht die Sachlage. Oft gewinnt, wer die überzeugendere Geschichte erzählt. Eine lückenlose, automatisiert mitschreibende Kontrollebene hilft hier allen Beteiligten. Wenn jede Änderung, jeder Alarm und jeder Fix mit Zeitstempel dokumentiert ist, lässt sich eine Ursache objektiv nachvollziehen. Das ersetzt Behauptung gegen Behauptung durch Fakten. So entsteht Klarheit für alle Seiten. Das schützt gewachsene Kundenbeziehungen vor unnötigem Vertrauensverlust und macht die eigene Arbeit sichtbar.

KI-gestütztes Monitoring wirkt als Sicherheitsnetz

Jedes dieser Werkzeuge sieht seine eigenen Ergebnisse: die Security den Angriff von außen, der Betrieb den Fehler von innen. Das Bindeglied dazwischen haben wir jetzt. Eine KI verbindet beide Bereiche. Sie pflegt Ausnahmen, meldet Auffälligkeiten und greift bei freigegebenen Aktionen selbst ein. Dabei trennt sie sauber, was ein Betriebsrisiko ist und was nur zweit- oder drittrangig.

Ein Dashboard zeigt, was gerade ist. Ein Sicherheitsnetz fängt ab, was schiefgeht, bevor es jemand bemerkt. Das macht aus Monitoring ein Sicherheitsnetz: Es hört niemals auf hinzusehen.

Vor einer Woche endete der erste Artikel dieser Reihe mit einem "groben Fahrplan": Wer aus dem reinen Lese-MCP-Server einen echten Assistenten machen will, braucht eigene Tools. Dazu kommen echte Authentifizierung und ein Bestätigungsschritt vor heiklen Aktionen. Ausserdem braucht es ein Protokoll, das mitschreibt. Eine Woche und 35 Commits später ist aus dem Fahrplan ein laufendes System geworden. Ein paar Dinge daran haben mich selbst überrascht.

Nach einer Woche das Resümee: Die ersten 48 Stunden entschieden alles

Das neue Monitoring ging am 20.9. um 21:57 Uhr in Betrieb, read-only, nur intern über das eigene Tailscale-Netz erreichbar. Was in den folgenden gut 31 Stunden passierte, lässt sich lückenlos im Git-Log nachvollziehen, weil jede Änderung ein eigener Commit ist:

• Innerhalb der ersten Stunde: aus einem geteilten Passwort wurde eine echte Microsoft-Entra-ID-Anmeldung mit Multi-Faktor -- inklusive der Kleinarbeit, die dazugehört (OAuth-Discovery-Dokument ergänzt, fehlender Standard-Scope nachgetragen, eigener App-Scope angelegt).
• Am nächsten Abend: ein erstes richtiges Dashboard ("Gatekeeper") mit echten Cloudflare-Firewall-Daten statt Platzhaltertext -- und noch am selben Abend der Fund, dass eine Kennzahl direkt und live bei Cloudflare abgefragt wurde, was bei jedem Seitenaufruf Kontingent gekostet hätte. Umgebaut auf einen Netdata-Sensor, der das im Hintergrund erledigt.
• Bis zum übernächsten Morgen, 31 Stunden nach dem ersten Commit: sechs vollständige Dashboards, ein zentrales Menü, eine Ampel-Färbung nach echtem Alarmstatus -- und mittendrin ein Moment, der die Sache auf den Punkt bringt: Ein automatischer "Beheben"-Knopf für einen vollen Arbeitsspeicher hatte den falschen Mechanismus benutzt (er leerte einen Cache, der mit dem eigentlichen Problem -- zu wenig Swap -- nichts zu tun hatte). Der Fehler wurde nicht von mir gefunden, sondern 13 Minuten später im selben Lauf korrigiert, mit einem Commit, dessen Nachricht es selbst so benennt: "fixt eigenen Fehler".

Dieser Befund wiegt schwerer als jedes einzelne Dashboard: Wenn ein System sich selbst beim Fehlermachen zusehen kann, wird jeder Handgriff sofort als Metrik, Log-Zeile oder Alarm sichtbar. Ein Mensch muss dann nicht mehr jeden Schritt kontrollieren. Kleinere Fehler fallen auf und werden behoben, oft bevor überhaupt jemand hinschaut. Dasselbe Muster zeigte sich diese Woche noch zweimal in kleinerem Massstab. Erstens: ein kurzzeitiger Cloudflare-API-Ausfall (sechs Minuten, danach von selbst wieder grün). Zweitens: ein Wirtschaftskalender-Termin, der strukturell nie einen Wert bekommt und fälschlich als "überfällig" gemeldet wurde. Beides fiel in derselben Sitzung auf und wurde sofort behoben. Human-in-the-Loop wird damit nicht überflüssig. Aber für diese Klasse von Problemen, die kleinen, klar erkennbaren Fehler, wird es spürbar weniger kritisch.

Das neue Dashboard: alles auf einen Blick

Nachtrag vom selben Abend: Die komplette Oberfläche lief bis eben auf Deutsch. Auf ausdrücklichen Wunsch ist sie jetzt komplett auf Englisch, bis in die Menüs und die von der KI zusammengebauten Statustexte hinein. So versteht auch ein internationales Publikum sofort, was da steht. Alle sechs Seiten wechseln im hellen Design (der Standard der meisten Besucher hier im Blog). Ports, IP-Adresse und interne Subdomains sind anonymisiert. Bei längeren Dashboards scrollt die Animation einmal von oben nach unten durch, statt oben abzuschneiden:

Dieses Zusehen-können ist der Kern der "Connections"-Seite (letzter Frame oben). Sechs Gruppen, auf einen Blick:

• MCP-Server -- alle laufenden MCP-Prozesse dieses Ökosystems (Wirtschaftskalender, Produkte, Kontor-Status, dieser Server selbst), inklusive der Frage, ob der öffentliche Zugang über brauckmann.ch tatsächlich noch dort ankommt, wo er soll.
• Broker -- vier unabhängige Saxo-Bank-Verbindungen (SIM, Live, Tour-Demo, ein separates Projekt), jede mit eigenem Keepalive-Log.
• Cloudflare -- zwei API-Tokens (eigene Zone, Website-Projekt) plus eine Live-Liste aller Subdomains inklusive HTTP-Status.
• Google / Search Console -- ob das Dienstkonto für die tägliche Indexierungsprüfung noch funktioniert.
• Wirtschaftskalender -- ob Termine, die schon vergangen sind, auch wirklich einen Ist-Wert bekommen haben.
• LLM-Wrapper -- die eigene, Claude-Abo-basierte OpenAI-kompatible Schnittstelle, über die sämtliche Analysen laufen.

Das klingt nach viel, und das ist es auch. Das Ökosystem ist über die Zeit gewachsen: mehrere Docker-Container, mehrere Host-systemd-Dienste, zwei getrennte öffentliche Zugänge, vier Broker-Verbindungen, ein Dutzend Subdomains. Unter der Haube stehen dafür heute weit über hundert einzelne Sensoren und Zusammenhänge. Entscheidend ist nicht die Zahl. Entscheidend ist, dass sich all das mit einem kurzen Gespräch mit der KI durchsuchen und erklären lässt. Die beiden Fixes von heute Nachmittag zeigen: Es lässt sich auch korrigieren, ohne dass ein Mensch selbst durch Log-Dateien, Cronjobs und Datenbanktabellen graben muss.

Das große Bild: zwei Wege ins System, eine Kontrolle

Was hinter diesen grünen Punkten steckt, zeigt sich besonders bei Cloudflare. Dort bieten öffentlich erreichbare Dienste die meiste Angriffsfläche. Der erste Frame der Animation oben zeigt den Blick dorthin: über 9'000 Anfragen in 24 Stunden, 25 automatisch blockiert. Der Verkehrsweg lautet Internet → Cloudflare Proxy → Cloudflare Tunnel → internes Netzwerk. Er ist Ende-zu-Ende ausgehend, kein eingehender Port.

Die kurze Fassung des Sicherheitsbilds: Zwei völlig unabhängige, öffentlich erreichbare Wege führen in dieses System. Keiner davon öffnet direkt einen Port am Server.

• Weg 1, brauckmann.ch und die übrigen eigenen Domains: Cloudflare als DNS- und Proxy-Schicht mit WAF, Bot-Schutz und Firewall-Regeln davor, dahinter ein Cloudflare-Tunnel (cloudflared), der die Verbindung ausgehend vom Server aus aufbaut -- am Router ist dafür kein einziger Port geöffnet. Der Tunnel liefert an einen zentralen Caddy-Edge, der je nach Pfad an den richtigen internen Dienst weiterreicht. Die eine dokumentierte Ausnahme: zwei technische Subdomains für MCP-Anbindungen zeigen direkt auf einen lokalen Port statt über den gemeinsamen Caddy-Edge zu laufen -- ohne die gemeinsamen Security-Header, dafür mit einem eigenen Bearer-Token als Schutz. Bewusst offen dokumentiert, nicht versteckt.
• Weg 2, die eigene ts.net-Adresse: Tailscale Funnel, also ein VPN-Mesh mit einer eigenen, öffentlich freigeschalteten Ausnahme -- komplett getrennt von Cloudflare, eigenes Zertifikat, eigener Pfad, landet aber am Ende beim selben internen Caddy-Edge.

Beide Wege laufen am Ende durch dieselbe lokale Infrastruktur auf demselben Server. Trotzdem hat jeder Dienst dahinter seine eigene, unabhängige Zugriffskontrolle. Die Trading-Oberfläche selbst nutzt eine dreistufige Vertrauenslogik (lokales Netz / Tailnet / öffentlicher Funnel, mit Passwort und Einmalcode für die zwei strengeren Stufen). Die Status- und Admin-Dashboards verlangen eine Microsoft-Entra-ID-Anmeldung mit Multi-Faktor. Fällt einer der beiden äusseren Wege aus oder wird missbraucht, bleibt der andere davon komplett unberührt. Zwei unabhängige Frontends stehen vor derselben, nach aussen portlosen Basis.

Nachtrag, einen Tag später: eine Lücke, die reines Perimeter-Denken nicht sieht

Alles bisher Beschriebene (Firewall, Tunnel, Zugriffskontrolle) dreht sich um die Frage, wer ins System hineinkommt. Doch es gibt eine zweite, ebenso wichtige Frage. Im Sicherheitsbild oben fehlt sie komplett: Was, wenn eine Anfrage regulär durch alle Türen hereinkommt? Als Wirtschaftskalender-Termin, als Alarmtext, als gewöhnlicher Text, aber mit Inhalt, den die KI dahinter als Anweisung statt als Daten liest? Das ist Prompt Injection, Platz eins der OWASP Top 10 für LLM-Anwendungen. Der Anstoss kam von aussen: einer LinkedIn-Folge von Volker Skwarek (Hochschule für Angewandte Wissenschaften Hamburg) über dieses Thema. Ohne diesen Anstoss hätte ich das hier vermutlich nicht angeschaut. Danke dafür, Volker.

Der Check der eigenen, in diesem Artikel beschriebenen Infrastruktur brachte einen Fund, wenn auch einen eingedämmten. Kontors Analyse-Agent bekommt bei jeder Frage einen Kontext-Block mit aktuellen Marktdaten, dem eigenen Handelsplan und dem Titel des nächsten anstehenden Wirtschaftstermins. Dieser Titel stammt roh von externen Quellen (Trading Economics, Finnhub, ForexFactory). Bislang landete er unverändert im Prompt. Ein böswillig formulierter Termintitel hätte sich theoretisch als Anweisung an die KI ausgeben können, statt als das gelesen zu werden, was er ist: ein Stück Text zum Anzeigen. Der Blast Radius war durch die bestehende Architektur schon vorher eng begrenzt, denn derselbe Chat-Pfad schaltet Werkzeuge serverseitig komplett ab und erzwingt eine harte Ein-Zug-Grenze. Eine erfolgreiche Injection hätte also nie mehr als die angezeigte Antwort verfälschen können. Die offene Tür ist jetzt zu.

Die Gegenmassnahme ist dokumentiert und überwacht, wie im Rest dieses Artikels, und über einen einmaligen Fix hinaus abgesichert. Freitext-Felder aus dem Kalender werden jetzt auf eine sinnvolle Länge begrenzt. Steuerzeichen entfernt das System, bevor sie den Prompt erreichen. Der System-Prompt selbst trennt jetzt explizit zwischen Datenmaterial und Anweisung. Ein Termintitel, der wie ein Befehl klingt, bleibt ein Termintitel. Passend zu diesem Ökosystem: Ein neuer Netdata-Sensor läuft alle 15 Minuten und prüft, ob diese Absicherung im Quelltext noch steht. Er ist sichtbar als eigene "LLM Security"-Kachel auf der Connections-Seite von oben und als eigene Karte auf dem Gatekeeper-Dashboard. Derselbe Mechanismus fing den eigenen Fehler beim Arbeitsspeicher-Alarm 13 Minuten nach dem Auftreten. Er wacht jetzt auch hier mit.

Zusammengefasst

Eine Woche, 35 Commits, sechs Dashboards, ein selbst gefundener und selbst behobener Fehler binnen 13 Minuten. Dazu ein Sicherheitsbild mit zwei unabhängigen, portlosen Zugangswegen zu derselben Infrastruktur. Der grösste Unterschied zur Realität von vorher ist die Zahl der Sensoren weniger als das, was daraus folgt: Kleine Fehler bleiben nicht mehr liegen, bis jemand zufällig draufschaut.

Recherche und Entwurf KI-gestützt, geprüft und freigegeben von Andreas Brauckmann · So arbeitet die Redaktion