Nginx-Honeypot: Wie ich mit KI Scanner in die Falle locke

Freitagabend, Terminal offen: Jagdsaison in der Nginx-Config

Freitagabend. Das Terminal leuchtet, der Kaffee ist schwarz und im Umami-Dashboard ploppen die ersten roten Punkte auf. Irgendein Bot aus Singapur versucht gerade, auf meine Seite zuzugreifen. Erst /wp-login.php, dann /.env, dann /phpmyadmin. Der Klassiker.

Das Amüsante dabei? Meine Seite ist eine statische Visitenkarte. Da gibt es kein WordPress, kein PHP und erst recht kein Admin-Panel. Aber die automatisierten Scanner klopfen trotzdem an – hunderte Male am Tag.

Früher hat mich das genervt. Heute ist es mein persönlicher Sport. Statt diese Anfragen einfach stumpf mit einem Standard-Fehler abzuwürgen, habe ich zusammen mit Claude (meiner KI-Rechten-Hand) ein kleines Verteidigungssystem gebaut. Ein Honeypot, der Scanner erkennt, trackt und sie ein bisschen im Kreis schickt. Hier ist der Werkstattbericht, wie wir das Ding hochgezogen haben.

Warum die digitale Haustür ständig klappert

Wer glaubt, dass nur die "großen Player" angegriffen werden, liegt falsch. Ein Bot unterscheidet nicht zwischen einem DAX-Konzern und meiner Web-Visitenkarte. Die fahren mit dem digitalen Äquivalent eines Lieferwagens durch jede Straße und rütteln an jeder Klinke. IP-Range für IP-Range.

Die suchen nach der einen vergessenen WordPress-Leiche oder der offenen Konfigurationsdatei mit den Datenbank-Passwörtern. Das ist kein gezielter Hackerangriff, das ist industrielles Türklinkenputzen. Aber genau das ist die Chance: Wenn du weißt, wonach sie suchen, kannst du ihnen eine Falle bauen, die zuschnappt, bevor sie Schaden anrichten.

Die Strategie: Wenn du schon einbrichst, dann bitte hier entlang

Auf einer echten Baustelle ist es simpel: Der Zaun steht, das Tor ist zu. Wer trotzdem drüberklettert, löst die Kamera aus. In meiner Nginx-Welt habe ich das genauso gelöst. Jeder Pfad, den ein Bot typischerweise abgrast, ist bei mir eine bewusste Falle.

Ich unterscheide dabei zwischen zwei Typen von "Besuchern":

1. Die Maschinen (CLI-Tools): Wer mit curl, sqlmap oder automatisierten Scannern anrückt, bekommt eine ASCII-Art-Antwort serviert. Ein kleiner Gruß aus der Werkstatt. Wer sich die Mühe macht, meine Seite technisch abzuklopfen, darf wissen, dass ich zugucke.
2. Die Neugierigen (Browser): Falls sich mal ein Mensch vertippt und /admin eingibt, landet er nicht im digitalen Nirgendwo, sondern auf einer freundlich gestalteten Infoseite.

Mein "Best of" der Bot-Abwehr-Tricks:

• Der Localhost-Bumerang: Bei Anfragen nach /phpmyadmin schicke ich einen Redirect auf 127.0.0.1. Der Bot scannt sich am Ende selbst. Kostet mich null Ressourcen, ärgert den Angreifer aber gewaltig.
• Die 10-Jahres-Sperre: Für extrem kritische Pfade wie .ssh oder .env antworte ich mit einem 429 Too Many Requests und einem Retry-After-Header von zehn Jahren. Ein braver Crawler setzt das in seine Warteschlange und kommt erst 2036 wieder.
• Das Umami-Radar: Über einen asynchronen mirror-Request in Nginx feuere ich jeden Treffer direkt an mein Tracking-Tool Umami. So sehe ich in Echtzeit, welcher Bot aus welchem Land gerade welche Falle ausgelöst hat.

Sackgassen auf dem Weg: Warum "Viel hilft viel" hier nicht gilt

Beim Basteln mit der KI kamen wir auf ein paar Ideen, die auf dem Papier cool klangen, in der Praxis aber Murks waren. Hier ist meine Liste der Dinge, die ich nicht gemacht habe (und warum):

• GZIP-Bomben: Die Idee, dem Bot eine winzige Datei zu schicken, die sich beim Entpacken auf Gigabytes aufbläht. Klingt lustig, ist aber brandgefährlich, weil es auch meine eigenen Server-Ressourcen beim Packen frisst.
• Tarpits (Teergruben): Die Verbindung künstlich extrem langsam halten. Das bindet offene Sockets auf meinem Server. Bei einem kleinen System mit wenig RAM schieße ich mir damit selbst ins Knie.
• CrowdSec-Overkill: Ein riesiges Sicherheits-Framework für eine statische Seite? Brauche ich nicht. Es gibt keinen Login, den man per Brute-Force knacken könnte. Keep it simple.

Die KI als technischer Sparringspartner

Das Spannendste an dem Projekt war die Zusammenarbeit mit Claude. Ich habe nicht einfach gesagt "Bau mir mal Sicherheit", sondern wir sind die Config Zeile für Zeile durchgegangen.

Der Moment, in dem es "Klick" machte, war, als die KI meine Idee einer GZIP-Bombe mit einer fundierten Begründung abschmetterte. Da merkte ich: Hier sitzt kein Ja-Sager am Whiteboard, sondern ein echter Partner, der die Risiken versteht. Wir haben zusammen die Content Security Policy (CSP) so festgezogen, dass selbst wenn jemand eine Lücke findet, kein fremder Code ausgeführt werden kann. Das ist das digitale Fundament, auf dem der Honeypot-Spaß erst sicher steht.

Was wir für die Praxis lernen können

Am Ende des Abends war meine Nginx-Config zwar deutlich länger, aber meine Seite ist sicherer und ich habe ein Dashboard voller spannender Daten. Was bedeutet das für dich und dein Business?

1. Einfachheit ist Trumpf: Eine statische Seite hat fast keine Angriffsfläche. Das ist die beste Security-Strategie überhaupt.
2. Daten schlagen Raten: Durch das Tracking sehe ich, was da draußen wirklich passiert. Das ist wie eine Wildkamera im digitalen Wald – man lernt die "Tiere" kennen.
3. KI ist ein Werkzeug für Macher: Ohne die KI hätte ich für die komplexe Nginx-Logik drei Abende gebraucht. So war es eine unterhaltsame Session nach Feierabend.

Echte Digitalisierung bedeutet für mich nicht, teure Software zu kaufen, sondern die vorhandenen Werkzeuge schlau zu kombinieren, um ein Problem zu lösen – oder eben um Bots zu jagen.

Hast du schon mal mit Honeypots experimentiert oder hast du eine ganz andere Strategie gegen die automatisierten Scanner? Schreib mir mal, ich bin gespannt auf deine Lösungen!

Euer Bastian Macher in der Digitalisierung – und gelegentlicher Bot-Jäger