Botnet-Traffic blockieren, bevor er Ihre Datenbank erreicht

Die meisten Application Stacks sind auf Höflichkeit gebaut. Eine Anfrage kommt an, der Router reicht sie an einen Controller weiter, der Controller öffnet eine Datenbankverbindung, führt eine Abfrage aus und rendert eine Antwort. Für Menschen ist dieser Weg völlig in Ordnung. Für ein Botnet ist er ein Geschenk.

Ein verteiltes Botnet braucht keine Sicherheitslücke, um Schaden anzurichten. Es reicht, wenn Ihre Anwendung immer wieder Ja sagt: ja zum Login-Formular, ja zum Such-Endpunkt, ja zur Passwort-zurücksetzen-E-Mail, ja zu noch einer Verbindung aus dem Pool. Wenn der Traffic erst einmal Ihr ORM erreicht, haben Sie bereits für TLS, Session-Lookup und einen Datenbank-Roundtrip bezahlt — multipliziert mit Tausenden Nodes pro Minute.

Die günstigste Anfrage ist die, die Sie gar nicht erst verarbeiten. Genau darum geht es bei IP-Filterung am Edge.

Wie ein Botnet auf IP-Ebene tatsächlich aussieht

Botnet-Traffic kommt selten von einer einzigen Adresse. Er kommt von vielen, und die Mischung fällt meist in einige gut erkennbare Kategorien:

• Kompromittierte Privatanschlüsse. Heimrouter, IoT-Geräte und infizierte Desktop-Rechner. Einzeln unauffällig, zusammen enorm.
• Gemietete Datacenter-Kapazität. Billige VPS-Instanzen, massenhaft hochgezogen. Ein menschlicher Kunde besucht Ihren Checkout fast nie aus einem AWS-, OVH- oder Hetzner-Range heraus.
• Kommerzielle Proxy-Netzwerke. Residential- und Mobile-Proxy-Pools, die gigabyteweise weiterverkauft werden — ausdrücklich mit dem Versprechen, IP-basierte Sperren zu umgehen.
• Öffentliche VPN- und TOR-Exits. Für datenschutzbewusste Nutzer legitim, in Missbrauchsszenarien aber überproportional vertreten.

Nichts davon ist automatisch bösartig. Eine Datacenter-IP kann ein Monitoring-Probe sein, den Sie selbst eingerichtet haben. Ein VPN-Exit kann ein Kunde im Hotel-WLAN sein. Genau deshalb sollte die Entscheidung bei Ihnen liegen und nicht in einer pauschalen Blockliste: Sie brauchen die Klassifizierung — und wenden darauf Ihre Policy an.

Vor der Datenbank blockieren, nicht danach

Die Reihenfolge ist wichtiger als die Treffsicherheit eines einzelnen Signals. Nehmen wir zwei Varianten desselben Login-Endpunkts.

| Stage | Without IP filtering | With IP filtering first | | --- | --- | --- | | Parse request | Yes | Yes | | IP classification | — | ~1 lookup, cached | | Session / user lookup | Yes | Only if allowed | | Password hash verify | Yes (expensive by design) | Only if allowed | | Rate-limit write | Yes | Only if allowed |

Passwort-Hashing ist absichtlich langsam — das ist sein Zweck. Ein Credential-Stuffing-Lauf gegen ein ungeschütztes Login macht aus Ihrer eigenen Sicherheitsmaßnahme den DoS-Hebel. Wenn die IP-Entscheidung davor fällt, bekommt ein angreifender Node für den Preis eines Hash-Map-Treffers ein 403, während Ihr Datenbank-Connection-Pool für echte Kunden frei bleibt.

Dasselbe Prinzip gilt für Such-Endpunkte mit Full-Text-Index, Registrierungsformulare mit transaktionalen E-Mails und jeden Endpunkt, der pro Versuch eine Audit-Zeile schreibt.

Eine praktikable Policy, keine Mauer

Alles Verdächtige hart zu blockieren, ist der schnellste Weg zu verärgerten Support-Tickets. Besser funktioniert eine abgestufte Reaktion — und sie lässt sich leicht formulieren, sobald Sie für jede Adresse einen Risikoscore und einen Typ haben:

• Still erlauben. Residential- und Business-ISP-Adressen mit niedrigem Risikoscore. Das ist der überwiegende Teil des echten Traffics.
• Reibung einbauen. VPN- oder TOR-Exits nur bei sensiblen Aktionen strenger behandeln — Registrierung, Passwort-Reset, Änderungen an Auszahlungen. Challenge anzeigen, E-Mail-Bestätigung verlangen, den Free-Trial-Bonus nicht automatisch gewähren.
• Hart drosseln. Datacenter- und Hosting-Ranges auf Endpunkten, die für Menschen gedacht sind. Legitime Integrationen gehören mit einem Key auf Ihre API, nicht auf Ihr Login-Formular.
• Am Edge abweisen. Bekannte missbräuchliche Proxy-Infrastruktur, die Authentifizierung hämmert, oder alles, was bereits über Ihrem Per-IP-Budget liegt.

Wichtig: Schritt 4 ist der kleinste Topf, nicht die Voreinstellung. Ziel ist es, Missbrauch teuer zu machen — nicht Ihr Produkt unerreichbar.

Wo der Check in Ihren Stack gehört

Drei sinnvolle Positionen, grob nach Wirksamkeit sortiert:

• CDN oder Reverse Proxy. Der frühestmögliche Punkt. Die Anfrage berührt keinen Application Server. Ideal für pauschale Regeln gegen eindeutig feindliche Ranges.
• Middleware in Ihrer Anwendung. Läuft vor dem Routing und vor jedem Datenbankzugriff. Hier gehören nuancierte, endpunktspezifische Policies hin — streng auf /login, entspannter auf /pricing.
• In der Business-Logik. Für Entscheidungen, die Account-Kontext brauchen, etwa wenn ein Login von einer Datacenter-IP auf einem Konto auftaucht, das bisher nur einen bestimmten Mobilfunkanbieter genutzt hat.

Die meisten Teams brauchen zuerst die mittlere Variante. Ein paar Zeilen vor dem Router schützen alles, was dahinterliegt.

Aggressiv cachen, im Zweifel offen bleiben

Zwei Betriebsregeln verhindern, dass ein IP-Reputation-Check selbst zum Ausfallrisiko wird:

Nach Adresse cachen. Botnets verwenden Nodes mehrfach. Ein kurzer In-Memory-TTL — Minuten, nicht Tage — reduziert Tausende Requests auf einen einzigen Lookup und hält die zusätzliche Latenz bei Wiederholungstätern im Mikrosekundenbereich. Guarda cached Lookups aus genau diesem Grund serverseitig; das Cache-Fenster ist konfigurierbar.

Fail open, laut loggen. Wenn der Reputation Service nicht erreichbar ist, lassen Sie die Anfrage durch und protokollieren Sie den Vorfall. Eine Anti-Abuse-Kontrolle, die Ihren Checkout lahmlegt, nur weil ein Drittanbieter einen schlechten Tag hat, kostet Sie am Ende mehr als der Missbrauch selbst. Fail-closed sollten Sie nur für wirklich kritische Aktionen reservieren, etwa Auszahlungen.

Was Sie danach messen sollten

Schalten Sie den Filter zunächst im Log-only-Modus ein und vergleichen Sie eine Woche Traffic mit einer Woche Blocking:

• Anteil der Requests, die abgewiesen wurden, bevor sie die Datenbank erreicht haben.
• Sättigung des Datenbank-Connection-Pools während Abuse-Spitzen.
• Fehlgeschlagene Login-Versuche pro Stunde.
• Support-Tickets mit Hinweisen wie „kann mich nicht einloggen“ — Ihr Frühwarnsignal für False Positives.
• Verhältnis von Registrierungen zu verifizierten Accounts, das sich meist deutlich verbessert, sobald Wegwerf-Signups aus Datacentern ausbleiben.

Wenn sich die letzten beiden Kennzahlen in die falsche Richtung bewegen, lockern Sie die jeweilige Stufe, statt den gesamten Schutz abzuschalten.

Ehrliche Grenzen

IP-Reputation ist eine Schicht, keine Firewall. Residential-Proxy-Pools rotieren über echte Verbraucheranschlüsse, die von Ihren Kunden kaum zu unterscheiden sind. Carrier-grade NAT bedeutet, dass eine einzige mobile IP für Tausende Menschen stehen kann. Angreifer mit Budget werden immer sauberere Infrastruktur finden als Angreifer ohne Budget.

Was IP-Filterung zuverlässig leistet: Sie entfernt den günstigen, volumenstarken Großteil — die geskripteten Floods auf gemieteten Servern und verbrannten Proxy-Listen. Dadurch müssen Ihre langsameren, intelligenteren Schutzmechanismen wie Device Fingerprinting, Verhaltensanalyse, MFA und accountbezogene Rate Limits nur noch über eine deutlich kleinere und interessantere Grundgesamtheit entscheiden.

Das ist der realistische Gewinn: keine uneinnehmbare Festung, sondern eine Datenbank, die auch während eines Angriffs noch Abfragen beantwortet.

Mit dem kostenlosen Check auf der Homepage können Sie jede Adresse gegen Guardas Signale für proxy, VPN, TOR, hosting und risk score klassifizieren — und denselben Aufruf anschließend in die Middleware vor Ihren Routen einbauen.