Laravel Threat Detection

Sicherheitsüberwachung und Angriffsprotokollierung für Laravel. Erkennt und protokolliert SQL-Injection, XSS, RCE, Directory Traversal, Bot-Scanner und /wp-admin-artige Recon-Sonden — jede feindliche Anfrage wird mit vollständigem Anwendungskontext in deiner Datenbank aufgezeichnet. Es ist ein IDS, kein WAF: Es blockiert, filtert oder verändert niemals eine Anfrage.

Bist du hier, weil du etwas wie das hier gesehen hast?```

GET /wp-admin/setup-config.php 404 — on a site that isn't WordPress GET /.env 404 — someone wants your database password GET /?id=1' UNION SELECT password FROM 200 — SQL injection against a real route GET /phpmyadmin/index.php 404 — scanning for an admin panel

Diese Anfragen erreichen deine Laravel-App bereits. Dein Access-Log zeigt die URL
und den Statuscode, und sonst nichts — nicht die dekodierte Payload, nicht welche deiner
Routen angegriffen wurde, nicht ob dieselbe IP in dieser Stunde schon vierzig andere Dinge versucht hat.

Dieses Paket beantwortet diese Fragen. Integriere es in jede Laravel-10–13-App und es beginnt
damit, jede HTTP-Anfrage gegen über 150 Angriffsmuster zu prüfen, jeden Treffer nach
Konfidenz zu bewerten und in deine Datenbank zu schreiben — mit integriertem Dashboard, Slack-Benachrichtigungen,
Geo-Anreicherung und fail2ban/Blocklist-Exporten. Keine Anfrage wird jemals blockiert. Denk an
eine Überwachungskamera, nicht an ein Schloss: Sie zeigt dir genau, wer deine Routen sondiert, wie
oft und mit welchen Techniken.

> Aus einer Produktions-App extrahiert und im echten Traffic erprobt. 1.857 Tests, keine Laufzeit-
> Abhängigkeiten außer Laravel selbst und keine Internetverbindung für die Erkennung erforderlich.
>
> Upgrade? Siehe [UPGRADING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/UPGRADING.md). Mitwirken? Siehe [CONTRIBUTING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/CONTRIBUTING.md).

## In unter einer Minute startklar```bash
composer require jayanta/laravel-threat-detection
php artisan vendor:publish --tag=threat-detection-migrations
php artisan migrate

Dann füge die Middleware zu deiner web-Gruppe hinzu (eine Zeile in bootstrap/app.php unter Laravel 11+, oder app/Http/Kernel.php unter Laravel 10) — vollständiges Snippet unten in Quick Start. Das war's; die Erkennung ist aktiv.```bash php artisan threat-detection:doctor # confirms it is actually recording

---

## Wo es einzuordnen ist: IDS vs. WAF vs. Edge

Dieses Paket ist ein **passives IDS auf Anwendungsebene** — es beobachtet und protokolliert, es
blockiert nicht. Es ist dafür gedacht, *neben* einer WAF oder einem Edge-Dienst zu stehen, nicht einen zu ersetzen. Jede Schicht sieht
etwas, das die anderen nicht sehen können:

| | **Dieses Paket** (App-IDS) | **WAF** (mod_security, Cloudflare WAF) | **Edge / CDN** (Cloudflare) |
|---|:---:|:---:|:---:|
| Blockiert bösartige Anfragen | ❌ nur Protokollierung | ✅ | ✅ |
| Voller App-Kontext (exakte Route, dekodierte Payload, authentifizierter Benutzer) | ✅ | ⚠️ teilweise | ❌ |
| Integriertes Dashboard + Bedrohungsprotokoll in deiner DB | ✅ | ⚠️ variiert | ⚠️ nur Edge |
| App-spezifische Erkennungen (z. B. Aadhaar / PAN / IFSC PII) | ✅ benutzerdefinierte Muster | ❌ | ❌ |
| Funktioniert offline / ohne externen Dienst | ✅ | ⚠️ abhängig | ❌ |
| Stoppt Traffic, bevor er deine App erreicht | ❌ | ✅ Edge | ✅ |
| Einrichtung | ein `composer require` | mittel–hoch | niedrig–mittel |
| Kosten | kostenlos, MIT | variiert | kostenlose Stufe + kostenpflichtig |

**Die Kurzfassung:** Ein Edge/WAF ist dein Schloss an der Tür; dies ist die Überwachungskamera
*im Inneren*, mit dem App-Kontext, um dir genau zu sagen, was auf welcher Route, von
wem und wie oft versucht wird. Nutze es, um echte Entscheidungen zu speisen — fail2ban-Bans, Rate Limits,
Geo-Blocking — mit Daten, die deine Edge-Schicht nie sieht.

### Was es bewusst NICHT ist

- **Keine WAF.** Es blockiert, filtert oder verändert niemals eine Anfrage. Nutze Cloudflare,
  mod_security oder eine echte WAF zur Durchsetzung. (Keine Edge-Schicht zum Weiterreichen? Die
  [betreiberseitigen Helfer](#acting-on-the-data-operator-side-blocking) legen die
  Entscheidungen des Pakets offen, damit du deine eigene fünfzeilige Blocking-Middleware schreiben kannst —
  der Durchsetzungscode bleibt deiner, nicht der des Pakets.)
- **Kein Ersatz für sicheres Programmieren.** Parametrisierte Queries, Eingabevalidierung und
  Output-Escaping sind deine eigentlichen Verteidigungen. Dieses Paket geht davon aus, dass dein Code bereits
  sicher ist, und gibt dir *Sichtbarkeit*, keinen Schutz.
- **Kein Edge-Dienst.** Wenn du Cloudflare davor setzen kannst, tu es — und füge dann dies für die
  Details auf Anwendungsebene hinzu, die Edge-Dienste nicht sehen können.
- **Kein vollständiger Detektor, und das kann es nicht sein.** Musterabgleich fängt Angriffe ab, die
  *wie* bekannte Angriffe *aussehen*. Eine neuartige Technik oder eine bekannte, ausreichend umgeschriebene, wird
  unprotokolliert durchgehen — und dir wird nicht mitgeteilt, dass sie es tat. Stille bedeutet hier
  „nichts hat gepasst", niemals „nichts ist passiert". Wo es seinen Platz verdient, ist der
  hochvolumige Traffic mit geringem Aufwand, der den Großteil dessen ausmacht, was tatsächlich eine öffentliche
  Laravel-App trifft: Scanner, Recon-Probes, Standard-Injection-Strings, Credential-
  Sprays. Behandle ein stilles Protokoll als Abwesenheit von Beweisen, nicht als Beweis für Abwesenheit.

### Erwarte, dass es am ersten Tag deine eigenen Inhalte markiert

Eine ungetunte Installation schlägt bei legitimen Inhalten an, und das solltest du wissen, bevor
du installierst, nicht danach. Diese sind gemessen, nicht hypothetisch — die Suite
fixiert genau diese Liste, damit sie nicht abweichen kann ([`LegitimateTrafficCorpusTest`](https://github.com/jay123anta/laravel-threat-detection/blob/main/tests/Feature/LegitimateTrafficCorpusTest.php)):