Introducing Laravel Teapot

Vor ein paar Jahren habe ich über eine einfache Idee geschrieben: Statt riesige fail2ban-RegEx-Filter für jeden obskuren Scanner-Pfad zu pflegen, lässt man die Laravel-Anwendung bei eindeutigem Probe-Traffic einen sehr spezifischen HTTP-Statuscode zurückgeben. fail2ban kann dann anhand dieses Statuscodes die IP bannen.

Jetzt gibt es diesen Ansatz als Paket: aureola/laravel-teapot

Die Idee in einem Absatz

Vulnerability Scanner klopfen oft immer wieder an denselben Türen an: .env, .git, wp-admin und ähnliche Pfade. Das Paket lässt Dich eine Liste von Pfad-Mustern definieren. Wenn eine Anfrage darauf passt, antwortet Laravel mit HTTP 418. Dieser Response landet im Webserver-Log, und fail2ban bannt die IP, sobald es wiederholt 418 sieht.

Wie Laravel Teapot funktioniert

• Du definierst Pfad-Muster in config/teapot.php.

• Wenn der Request-Pfad passt, antwortet die App mit 418 - umgesetzt über einen Fallback für nicht gematchte URLs.

• fail2ban überwacht Dein Access-Log auf 418 und bannt die IP.

Das ist im Kern derselbe Mechanismus wie in meinem Artikel von 2021 - nur eben als wiederverwendbares, testbares Paket statt als Copy-Paste-Anwendungslogik.

Installation und Setup

Installation:

composer require aureola/laravel-teapot

Config veröffentlichen:

php artisan vendor:publish --tag=teapot-config

Dann trägst Du Deine Muster ein, zum Beispiel:

• \.env

• \.git\/

• wp-admin

Für fail2ban liegen im Repo fertige Konfigurationen für Nginx und Apache unter fail2ban/ (Filter und Jail-Dateien nach /etc/fail2ban/ kopieren und fail2ban neu starten).

Wann dieser Ansatz sinnvoll ist

Nutze Laravel Teapot, wenn:

• Du mehrere Sites auf einem Server betreibst und pro Anwendung unterschiedliche "Trap-Pfade" pflegen willst, ohne eine riesige globale fail2ban-RegEx-Hölle.

• Du das Verhalten versioniert, testbar und deploybar haben willst: einmal sauber konfigurieren, dann einfach über App-Updates ausrollen.

• Du App-Level-Konfigurationen bevorzugst, statt immer komplexere fail2ban-Filter zu warten.

Nutze (oder priorisiere) klassisches fail2ban, wenn:

• Du Standardfälle wie SSH-Bruteforce, Login-Fails, Rate-Limits und ähnliche Muster abdecken willst - dafür gibt es sehr gute, bewährte Jails.

• Du Schutz möchtest, der unabhängig von der Anwendungsschicht ist (zum Beispiel, wenn Du schon bannen willst, bevor PHP überhaupt läuft).

Vorteile

• Funktioniert sehr gut mit mehreren Sites auf einem Server (unterschiedliche Configs pro Projekt).

• Testbar und deploybar: einmal einrichten, dann über die Anwendung aktualisieren.

• Einfacher zu warten als komplizierte fail2ban-Filter.

Nachteile und Caveats

• Du kannst aus Versehen Googlebot (oder andere legitime Crawler) bannen, wenn auf der Domain früher WordPress lief und alte Links wie wp-admin noch angefragt werden. Sei bei breiten Mustern vorsichtig und nutze im Zweifel Allowlisting auf Webserver- oder fail2ban-Ebene.

• Ein ungewöhnlicher HTTP-Code wie 418 kann manche CDNs, WAFs oder Monitoring-Tools irritieren. Stelle sicher, dass Deine Edge-Schicht damit sauber umgeht und trotzdem korrekt loggt.

Kleine praktische Tipps

• Starte mit sehr eindeutigen Mustern wie \.env und \.git\/, bevor Du breitere Sachen wie wp-admin dazu nimmst.

• Behalte die Access-Logs 1 bis 2 Tage nach dem Rollout im Blick und passe die Muster danach an.

• Wenn Du Statamic einsetzt, integriert sich das Paket automatisch, indem es seine Check-Middleware an die Statamic-Web-Middleware-Group hängt.