Ein Kontaktformular soll die Kommunikation zwischen Webseitenbesuchern und Unternehmen erleichtern. Doch was passiert, wenn plötzlich im Minutentakt automatisierte Anfragen eintreffen? Ein Praxisbeispiel mit Drupal 11 zeigt, warum Webseitenbetreuung weit mehr bedeutet als gelegentliche Updates.
Alles läuft – bis die ersten Spam-Mails eintreffen
Eigentlich war es ein ganz normaler Arbeitstag. Eine von uns betreute Unternehmenswebseite auf Basis von Drupal 11 lief zuverlässig, das Kontaktformular funktionierte und die üblichen Wartungsarbeiten waren erledigt.
Dann kamen die ersten merkwürdigen Kontaktanfragen.
Statt eines Vornamens stand eine Internetadresse im Formular. Beim Nachnamen dasselbe. Auch das Feld für die Firma enthielt nur einen Link. Selbst bei der gewünschten Rückrufzeit hatte der Absender eine URL eingetragen.
Kurz darauf folgten weitere Nachrichten. Immer nach einem ähnlichen Muster, teilweise im Minutentakt.
Die E-Mail-Adressen wechselten, ebenso die Links. Innerhalb einer solchen Spam-Welle kamen die Anfragen jedoch immer von derselben IP-Adresse.
Spätestens jetzt war klar: Hier versuchte niemand ernsthaft, Kontakt mit dem Unternehmen aufzunehmen.
Die erste Spur führt in die Protokolle
Also begann die eigentliche Administratorenarbeit.
Zunächst wurden die gespeicherten Webform-Einsendungen ausgewertet. Welche Gemeinsamkeiten gab es? Welche IP-Adressen wurden verwendet? In welchen Zeitabständen trafen die Nachrichten ein?
Parallel dazu erfolgte die Kontrolle auf Serverebene. Die auffälligen IP-Adressen wurden in Suricata erkannt und anschließend blockiert.
Damit war die jeweilige Spam-Welle zunächst unterbrochen.
Doch eine einzelne IP-Adresse zu sperren, beseitigt nicht die eigentliche Schwachstelle. Der nächste Bot kann schließlich von einer anderen Adresse kommen.
Wir mussten also direkt am Kontaktformular ansetzen.
Warum ein einzelner Spamschutz nicht ausreicht
Das Drupal-Webform war bereits mit Honeypot geschützt. Diese Technik arbeitet mit versteckten Formularfeldern, die normale Besucher nicht ausfüllen, viele automatisierte Programme jedoch schon.
Offensichtlich hatte der verwendete Bot diesen Schutz umgangen.
Deshalb ergänzten wir eine zeitliche Prüfung. Wer das Formular unmittelbar nach dem Laden abschickt, wird zurückgewiesen. Für reguläre Besucher stellen wenige Sekunden Wartezeit normalerweise kein Problem dar.
Die nächste Überlegung war ebenso einfach wie wirkungsvoll:
Warum sollte in einem Feld für Vorname, Nachname oder Firmenname überhaupt eine Internetadresse stehen dürfen?
Über die Formularvalidierung von Drupal Webform richteten wir entsprechende Prüfungen mit regulären Ausdrücken ein. Eingaben mit typischen URL-Mustern werden seitdem in diesen Feldern abgewiesen.
Ein erster Test bestätigte, dass diese Validierung wie vorgesehen funktioniert.
Damit hatten wir bereits eine weitere Hürde geschaffen, unabhängig davon, welche IP-Adresse der Absender verwendet.
SpamAway als zusätzliche Schutzschicht
Für die wiederholten Einsendungen innerhalb kurzer Zeit benötigten wir allerdings noch eine weitere Lösung.
Unsere Wahl fiel auf das Drupal-Modul SpamAway.
Das Modul ermöglicht unter anderem eine Prüfung wiederkehrender Formularinhalte sowie eine zeitbasierte Begrenzung von Einsendungen anhand der IP-Adresse.
Für das betreffende Kontaktformular richteten wir zunächst eine großzügige Begrenzung ein: fünf Einsendungen innerhalb von zehn Minuten je IP-Adresse.
Das Ziel war nicht, jeden Besucher möglichst schnell auszusperren. Ein legitimer Interessent muss schließlich auch dann eine Anfrage absenden können, wenn er zuvor einen Fehler gemacht hat.
Für einen kontrollierten Funktionstest reduzierten wir die erlaubte Anzahl vorübergehend auf eine Einsendung.
Das Ergebnis war eindeutig: Die zweite Anfrage wurde zurückgewiesen und im Drupal-Protokoll als Spam-Versuch erkannt.
Anschließend stellten wir die produktiven Grenzwerte wieder her.
Wichtig ist dabei die Unterscheidung: SpamAway sperrt keine IP-Adresse dauerhaft auf Firewall-Ebene. Es begrenzt die Formularübermittlung anhand konfigurierbarer Regeln und Zeitfenster.
Auch der E-Mail-Versand gehört zur Betrachtung
Während der Analyse fiel noch ein weiterer Aspekt auf.
Das Kontaktformular versendete nicht nur eine interne Benachrichtigung an das Unternehmen, sondern auch eine automatische Eingangsbestätigung an die vom Besucher eingetragene E-Mail-Adresse.
Grundsätzlich ist das ein sinnvoller Service.
Bei automatisiertem Spam kann daraus jedoch ein zusätzliches Problem entstehen. Trägt ein Bot fremde oder ungültige E-Mail-Adressen ein, versucht der Mailserver möglicherweise, unerwünschte Bestätigungen dorthin zuzustellen.
In unserem Fall entstanden dadurch auch Unzustellbarkeitsmeldungen.
Wir überprüften deshalb die E-Mail-Handler, die verwendeten Absenderadressen und das Zusammenspiel mit den neuen Schutzmaßnahmen.
Während der Tests wurde die automatische Kundenbestätigung vorübergehend deaktiviert.
Denn auch hier gilt: Eine technische Schutzmaßnahme ist erst dann wirklich hilfreich, wenn sie im Zusammenspiel mit den übrigen Funktionen zuverlässig arbeitet.
Sicherheit darf nicht auf Kosten der Benutzerfreundlichkeit gehen
Ein Kontaktformular, das niemand mehr absenden kann, ist zwar vor Spam geschützt – erfüllt aber seinen eigentlichen Zweck nicht mehr.
Deshalb gehört zu jeder Änderung auch die Prüfung, ob normale Besucher weiterhin problemlos Kontakt aufnehmen können.
Wir testeten das Formular sowohl mit einem Administratorkonto als auch unangemeldet in einem privaten Browserfenster.
Dabei mussten wir insbesondere darauf achten, dass Administratoren bei ihren eigenen Tests nicht durch die IP-Begrenzung ausgesperrt werden.
Auch die Fehlermeldung für blockierte Einsendungen wurde angepasst. Statt einer englischen Standardmeldung erscheint nun ein verständlicher deutscher Hinweis mit einer alternativen Kontaktmöglichkeit per E-Mail.
Schließlich kann auch ein legitimer Besucher einmal versehentlich von einer Schutzmaßnahme betroffen sein.
Webseitenbetreuung ist kein einmaliger Auftrag
Dieses Beispiel zeigt ziemlich anschaulich, was im Hintergrund einer Webseite alles passiert.
Für den Besucher ist ein Kontaktformular eine einfache Angelegenheit: Angaben eintragen, Nachricht schreiben, absenden.
Für die Administratoren beginnt die Arbeit oft dort, wo niemand etwas davon bemerkt.
Serverprotokolle auswerten, ungewöhnliche Aktivitäten erkennen, Angriffsversuche einordnen, Erweiterungen prüfen, Einstellungen anpassen, Schutzmechanismen testen und dabei die Funktionsfähigkeit der Webseite erhalten.
Manchmal reichen wenige Konfigurationsänderungen. Manchmal braucht es zusätzliche Module oder Anpassungen auf Serverebene.
Entscheidend ist, nicht nur auf den aktuellen Vorfall zu reagieren, sondern aus den Erkenntnissen die nächste Verbesserung abzuleiten.
Bei unserem Drupal-Projekt arbeiten nun mehrere Schutzmaßnahmen zusammen: Honeypot, Zeitprüfung, gezielte Formularvalidierung, SpamAway und zusätzliche Sicherheitsmechanismen auf Serverebene.
Eine Garantie gegen zukünftigen Spam ist das nicht. Bots verändern ihre Vorgehensweise, und auch bestehende Schutzmechanismen müssen regelmäßig überprüft werden.
Der ständige Kreislauf
Eine Webseite ist eben kein fertiges Produkt, das man einmal installiert, veröffentlicht und anschließend sich selbst überlässt.
Sie ist Teil einer sich ständig verändernden technischen Umgebung.
Entwickeln, betreuen, beobachten, analysieren, verbessern, testen – und wieder von vorn.
Das ist ein wesentlicher Teil unserer täglichen Arbeit als Administratoren.
Und manchmal ist das schönste Ergebnis eines langen Arbeitstages etwas, das niemand bemerkt:
Das Kontaktformular funktioniert, echte Nachrichten kommen an und im Postfach herrscht endlich wieder Ruhe.
Zumindest bis zum nächsten ungebetenen Besucher.
Weiterführende Informationen: