Der Honeypot, der nie zuschnappte: warum Spam-Bots das Fangfeld lesen – und was stattdessen hilft

Christopher Zechendorf

05.10.2026

Share:

Ein verstecktes Fangfeld sollte ein Anmeldeformular vor Spam schützen – und schlug kein einziges Mal an. Wie wir das nachgemessen und was wir geändert haben.

Eine Falle, in die niemand tappt

Ein verstecktes Fangfeld – der „Honeypot” – ist der beliebteste unsichtbare Spamschutz für Formulare. Die Idee: Das Formular enthält ein zusätzliches Feld, das kein Mensch sieht. Ein Bot füllt blind alles aus, was er findet, verrät sich damit selbst, und die Absendung wird verworfen. Kein Bilderrätsel, keine Hürde für echte Besucher.

Genau so ein Feld haben wir im Juli in die Anmeldeformulare des Wine Trade Club eingebaut, des Händlerbereichs der internationalen Weinplattform VINUM. Dort gingen Fake-Anmeldungen mit Zufallstext ein. Die Formulare laufen über die Marketing-Software Mautic, die ein solches Fangfeld von Haus aus mitbringt.

Das Feld war korrekt eingerichtet und wurde korrekt ausgeliefert. Die Fake-Anmeldungen kamen trotzdem weiter.

Die Herausforderung

Ein unsichtbarer Schutz hat eine unangenehme Eigenschaft: Man sieht ihm nicht an, ob er arbeitet. Hier kam einiges zusammen:

• „Eingebaut” ist nicht „wirksam”. Dass ein Schutz konfiguriert ist, sagt nichts darüber, ob er je eine einzige Absendung abgewiesen hat.
• Jede Fake-Anmeldung richtete doppelt Schaden an. Sie löste eine Benachrichtigung an das Team des Kunden aus – und zusätzlich eine Bestätigungsmail für die Newsletter-Anmeldung an eine Wegwerf-Adresse. Solche Mails an Adressen, die sie nie bestellt haben, schaden dem Ruf des eigenen Mailversands. Warum uns dieser Ruf wichtig ist, haben wir beim Thema Double-Opt-In mit Mautic beschrieben.
• Die übliche Gegenwehr griff nicht. Eine Begrenzung pro Absender-Adresse setzt voraus, dass der Absender eine feste Adresse hat. Das war hier nicht der Fall.
• Das Versprechen an den Kunden galt weiter: kein Rätsel und keine Hürde für echte Weinhändler, die sich anmelden wollen.

Unsere Lösung

1. Messen statt glauben

Statt zu vermuten, haben wir zwei Zahlen nebeneinandergelegt, Tag für Tag: Wie viele Absendungen verzeichnet das Protokoll des Webservers für dieses Formular – und wie viele Einträge hat Mautic tatsächlich gespeichert? Jede Abweisung durch das Fangfeld müsste als Differenz sichtbar werden.

Das Ergebnis über den gesamten verfügbaren Zeitraum:

• 1. August: 29 Absendungen, 29 gespeicherte Einträge
• 1. August: 33 Absendungen, 33 gespeicherte Einträge
• 26., 27. und 30. August: zusammen 5 Absendungen, 5 gespeicherte Einträge

An jedem einzelnen Tag eins zu eins. Das Fangfeld hatte nicht ein einziges Mal angeschlagen. Seit dem Einbau waren 101 Fake-Anmeldungen durchgekommen.

Ein wichtiges Detail am Rand: Der HTTP-Status taugt für diese Messung nicht. Das Formular antwortet auf eine angenommene Absendung genauso wie auf eine abgewiesene. Verlässlich ist nur, ob am Ende ein Eintrag gespeichert wurde.

2. Dem Bot beim Arbeiten zusehen

Die Zugriffsprotokolle zeigten ein klares Muster. Rund zwei Sekunden vor jeder Absendung rief dieselbe Adresse das aktuelle Formular ab. Der Bot spielte also keine alte, einmal mitgeschnittene Absendung ab – er las das Formular jedes Mal frisch und baute seine Absendung daraus:

• Sichtbare Textfelder bekamen Zufallstext.
• Pflicht-Checkboxen trugen genau die Werte, die das Formular vorsieht.
• Versteckte technische Felder blieben unverändert korrekt.
• Ein vorbelegtes Feld für die Website-Adresse wurde mit seiner Vorbelegung https://www. abgeschickt – in jeder einzelnen Fake-Anmeldung. Die echten Anmeldungen im selben Zeitraum trugen dort eine richtige Adresse.

Das Fangfeld kam leer an. So, wie es ausgeliefert wird.

3. Warum „unsichtbar” für Maschinen nicht unsichtbar ist

Ein Mensch sieht die dargestellte Seite. Ein Bot liest den Quelltext – und dort ist ein Fangfeld alles andere als unauffällig. Unseres verriet sich gleich dreifach:

• durch den Namen: Das Feld hieß wörtlich spamschutz,
• durch die Kennzeichnung: der umgebende Bereich trug aria-hidden und eine CSS-Klasse mit „hidden” im Namen,
• durch die Darstellung: display:none und tabindex="-1" direkt am Eingabefeld.

Jedes dieser Merkmale genügt für sich, um das Feld als Attrappe zu erkennen.

Ob der Bot die Falle tatsächlich erkannt und umgangen hat oder ob er schlicht jedes Feld so abschickt, wie das Formular es vorgibt, lässt sich aus den Daten nicht unterscheiden. Die unveränderte Vorbelegung spricht eher für das Zweite. Für den Schutz macht es keinen Unterschied, für die Einordnung schon: Ein klassischer Honeypot fängt nur Bots, die blind alles ausfüllen. Gegen einen Absender, der sich wie ein vorsichtiger Mensch verhält – sichtbare Felder ausfüllen, alles andere in Ruhe lassen –, ist er wirkungslos. Und zwar unabhängig davon, wie gut das Feld getarnt ist.

4. Den Schutz dorthin verlegen, wo der Bot nichts lesen kann

Wenn der Inhalt einer Absendung nicht von einer echten zu unterscheiden ist, bleibt die Frage, woher sie kommt. Die Antwort war eindeutig: 17 der 18 beobachteten Absender-Adressen waren Ausgangsknoten des Anonymisierungsnetzes Tor. Die eine Ausnahme war die einzige echte Anmeldung im gesamten Zeitraum.

Das erklärt auch, warum eine Begrenzung pro Adresse nichts gebracht hätte – der Bot wechselte sie laufend. Umgekehrt hätte eine Sperre für Tor-Ausgangsknoten 100 % des Spams getroffen und 0 % der echten Anmeldungen.

Diese Sperre sitzt jetzt vor Mautic, direkt im Webserver nginx:

• Sie gilt ausschließlich für das Absenden von Formularen. Lesen, Formular anzeigen, Newsletter-Links öffnen – all das bleibt aus dem Tor-Netz möglich.
• Die Liste der Ausgangsknoten veröffentlicht das Tor-Projekt selbst. Sie wird täglich automatisch abgerufen und umfasst rund 1.400 Adressen.
• Ein zweites technisches Merkmal der Absendungen, das kein echter Browser aufweist, wird zusätzlich geprüft. Es ist bewusst nur Beigabe: Ein Angreifer kann es mit einer Zeile Code ablegen.
• Jede Absendung wird in einem eigenen Protokoll festgehalten – mit dem Vermerk, ob und welche Regel gegriffen hat. So bleibt die Wirkung zählbar, und im Fall einer Rückfrage lässt sich minutengenau nachsehen, was mit einer Anmeldung passiert ist.

Die Entscheidung hat einen Preis, den wir dem Kunden offen genannt haben: Wer mit dem Tor-Browser surft, kann auf dieser Plattform kein Formular mehr absenden. Bei einem Anmeldeformular für Weinhändler ist das vertretbar. Bei einem Hinweisgeber-Portal wäre es die falsche Maßnahme.

5. Im Zweifel offen bleiben

Eine Sperrliste, die sich täglich selbst aktualisiert, ist eine neue Fehlerquelle – und die Gegenprobe zu einem Fehler wäre hier ein geschlossenes Anmeldeformular. Deshalb ist die Aktualisierung so gebaut, dass jede Störung in dieselbe Richtung fällt: Niemand wird ausgesperrt.

• Ausgeliefert wird eine leere Liste. Fehlt der erste Abruf, ist niemand gesperrt.
• Scheitert ein Abruf, bleibt die Liste vom Vortag in Kraft.
• Eine auffällig kurze Liste (unter 200 Einträge) wird verworfen – sie wäre eher ein Fehler der Quelle als ein leeres Tor-Netz.
• Vor dem Einsatz prüft der Webserver die neue Liste. Lehnt er sie ab, wird automatisch auf die vorherige zurückgerollt.

Ein Ausfall der Sperrliste ist damit nie ein Ausfall des Formulars.

6. Die Falle im Detail: ein Job, der jeden Tag nichts tat

In der Qualitätssicherung fiel ein Fehler auf, der im Betrieb lange unbemerkt geblieben wäre. Das Aktualisierungs-Skript lief im Test einwandfrei. Als geplante Aufgabe (Cron) startet es im Container aber mit einem engeren Suchpfad – und fand dort das nginx-Programm nicht, mit dem es die neue Liste prüfen soll.

Die Folge wäre tückisch gewesen: Das Skript hätte die fehlgeschlagene Prüfung als „Liste abgelehnt” gewertet, brav auf die alte Liste zurückgerollt und sich fehlerfrei beendet. Jede Nacht. Die Sperrliste wäre nur noch bei einem Neustart des Servers aktualisiert worden und dazwischen still veraltet. Im Protokoll hätte obendrein eine Meldung gestanden, die auf eine defekte Liste zeigt, die es nie gab.

Die Sicherheitsvorkehrung aus Schritt 5 hätte also genau den Fehler verdeckt, der sie aushebelt. Behoben haben wir das an zwei Stellen: Das Skript findet das Programm jetzt unabhängig vom Suchpfad, und „Liste abgelehnt” und „Prüfprogramm nicht gefunden” sind zwei verschiedene Meldungen. Geprüft wurde anschließend nicht mehr von Hand, sondern über den echten Zeitplan-Dienst – genau so, wie der Job im Betrieb läuft.

Die Prüfung fand noch eine zweite Lücke: Mautic nimmt Absendungen nicht nur unter der einen bekannten Adresse entgegen, sondern auch unter abweichenden Schreibweisen derselben Adresse. Eine Sperre, die nur die übliche Schreibweise kennt, ist mit einer kleinen Änderung an der Adresse umgangen. Die Regel deckt jetzt alle Schreibweisen ab, die tatsächlich ankommen – jede einzeln nachgemessen.

7. Die Falle umdrehen

Bleibt das Fangfeld selbst. Seine Schwäche liegt in der Logik: „Leer ist gut.” Wer das Feld leer lässt oder ganz weglässt, kommt durch.

Wir haben die Logik umgekehrt. Das versteckte Feld trägt jetzt einen Prüfcode, den das Formular selbst mitliefert. Eine Absendung wird nur angenommen, wenn dieser Code mitkommt. Fehlt das Feld oder ist es leer, wird sie verworfen. Damit ist die ganze Klasse „Feld einfach weglassen” dauerhaft geschlossen. Das Feld hat bei der Gelegenheit auch einen unauffälligen Namen bekommen.

Zwei Dinge gehören zur ehrlichen Einordnung:

• Gegen diesen einen Bot hilft die Umkehrung voraussichtlich nicht. Er übernimmt vorbelegte Werte unverändert – also auch den Prüfcode. Gestoppt hat ihn die Sperre am Webserver. Die Umkehrung schließt eine Lücke, sie ist nicht die Lösung für alles.
• Die Risikorichtung dreht sich um. Ein kaputter Honeypot lässt Spam durch. Ein kaputter Prüfcode weist echte Kunden ab – still, bei unveränderter Antwort des Servers.

Wie real das zweite Risiko ist, zeigte die Vorbereitung: Mautic hält die fertig aufgebaute Formular-Ansicht in einem Zwischenspeicher vor, prüft Absendungen aber gegen die aktuelle Konfiguration. Hätten wir nur die Konfiguration geändert, hätte der Server sofort einen Prüfcode verlangt, während das Formular weiter ohne ihn ausgeliefert worden wäre. Jede echte Anmeldung wäre abgewiesen worden. Konfiguration und Zwischenspeicher wurden deshalb in einem einzigen Schritt umgestellt, und unmittelbar danach haben wir das ausgelieferte Formular geprüft.

Abgenommen haben wir die Änderung mit Proben in beide Richtungen:

• Absendung ohne das Feld und mit leerem Feld: kein Eintrag gespeichert.
• Kontrollprobe: dieselbe Absendung mit korrektem Prüfcode legt einen Eintrag an. Ohne diese Kontrolle wäre „kein Eintrag” auch mit einem fehlerhaften Testaufbau erklärbar gewesen.
• Eine Anmeldung aus einem echten Browser in jeder der drei Sprachversionen. Bestanden erst, als der Kunde bestätigt hatte, dass die Benachrichtigungen in seinem Postfach angekommen waren.

Alle zehn Testabsendungen beantwortete der Server mit demselben Status, angenommen wie abgewiesen. Beurteilt haben wir deshalb ausschließlich nach gespeicherten Einträgen.

Das Ergebnis

Gut drei Wochen nach dem Start haben wir das neue Protokoll ausgewertet. In einem Zeitraum von 14 Tagen gingen knapp 3.000 Formular-Absendungen über alle Formulare der Plattform ein:

• 163 hat die Sperre abgewiesen. 112 davon trugen exakt die Handschrift des bekannten Bots – er versucht es weiter, auf mehreren Formularen, und kommt nicht mehr durch.
• Kein abgewiesener Versuch sah nach einem Menschen aus. Die übrigen 51 haben wir einzeln durchgesehen: ausnahmslos Serien von mehreren Absendungen pro Minute mit veralteten Browser-Kennungen und ohne Bezug zu einer Seite, auf der das Formular eingebunden ist.
• Rund 2.800 Absendungen wurden normal angenommen.
• Null Fake-Anmeldungen auf den drei Formularen des Wine Trade Club seit dem Start der Sperre.

Die bis dahin eingegangenen Fake-Kontakte haben wir erst entfernt, als der Schutz stand – nach einer Sicherung und mit der Auflage, Zweifelsfälle stehen zu lassen. In einer Menge von Fake-Anmeldungen kann immer ein echter Kunde stecken.

Eine unsichtbare Prüfung durch einen Drittanbieter haben wir bewusst nicht eingebaut. Sie wäre der nächste Schritt, falls Spam künftig mit korrektem Prüfcode aus anderen Netzen eintrifft. Bisher ist das nicht passiert.

Dasselbe Muster an anderer Stelle: Wer ist wirklich Googlebot?

Die Lehre „eine Selbstauskunft ist kein Nachweis” hat uns kurz darauf an anderer Stelle derselben Plattform wieder eingeholt. Dort begrenzt der Webserver, wie viele Seiten Crawler pro Sekunde abrufen dürfen. Echte Suchmaschinen sind davon ausgenommen – erkannt wurden sie bis dahin an ihrer Browser-Kennung.

Diese Kennung kann sich jeder geben. In einer Woche kamen 11 % aller Anfragen, die sich als Googlebot ausgaben, gar nicht von Google. Die Ausnahme für Suchmaschinen kam damit ausgerechnet denen zugute, die sie sich erschlichen hatten.

Die Lösung folgt demselben Gedanken wie bei den Formularen: Die Behauptung wird gegen etwas geprüft, das der Absender nicht fälschen kann. Google veröffentlicht die Adressbereiche seiner Crawler und beschreibt selbst, wie man Googlebot verifiziert. Die Ausnahme gilt jetzt nur noch, wenn Kennung und Herkunft zusammenpassen. Eine Woche später war die Zahl der gedrosselten Anfragen im Besucherbereich von rund 61.000 auf rund 14.000 gefallen – und der echte Googlebot wurde kein einziges Mal ausgebremst.

Was Website-Betreiber daraus mitnehmen können

1. Die Wirksamkeit messen, nicht annehmen. Absendungen im Server-Protokoll gegen gespeicherte Einträge, Tag für Tag. Stimmen die Zahlen immer exakt überein, hat der Schutz nie etwas abgewiesen.
2. Den Quelltext mit den Augen eines Bots lesen. Ein Fangfeld namens „spamschutz” oder „honeypot”, versteckt mit display:none, verrät sich selbst.
3. Ein Honeypot fängt nur ungeduldige Bots. Gegen Absender, die das Formular frisch laden und nur ausfüllen, was ein Mensch sieht, hilft er nicht – egal wie gut er versteckt ist.
4. Auf Merkmale stützen, die der Absender nicht frei wählen kann. Die Herkunft einer Anfrage ist belastbarer als alles, was im Formular steht oder was ein Programm über sich selbst behauptet.
5. Automatik so bauen, dass sie im Fehlerfall niemanden aussperrt – und sie genau so testen, wie sie später läuft. Ein Job, der fehlerfrei endet und nichts tut, ist der gefährlichste.
6. Nach gespeicherten Daten urteilen, nicht nach Statusmeldungen. „Der Server hat 200 geantwortet” heißt nicht, dass die Anmeldung angekommen ist.

Ihre Formulare werden mit Spam geflutet – oder Sie sind nicht sicher, ob Ihr Spamschutz womöglich echte Anfragen verschluckt? Wir messen nach, statt zu vermuten, und bauen einen Schutz, der Bots stoppt und Kunden durchlässt. Sprechen Sie uns an – wir schauen uns Ihre Formulare gerne an.