Ratenbegrenzende * nicht * authentifizierte Anfragen

Angenommen, wir haben einen Load Balancer, der auch die Geschwindigkeit begrenzt. Die Ratenbegrenzung scheint für angemeldete Benutzer ziemlich einfach zu sein. Schauen Sie sich einfach das JWT an und verwenden Sie möglicherweise einen speicherinternen Datenspeicher, um zu sehen, wie viele Anforderungen in den letzten 10 Sekunden für diesen Benutzer vorliegen.

Was ist jedoch mit nicht angemeldeten (nicht authentifizierten) Benutzern? Wir wissen nicht genau, von wem oder woher die Anfrage kommt, können diese Anfragen also nicht einfach einschränken oder ..?

Gibt es integrierte Lösungen für AWS und andere Hosting-Plattformen, über die wir uns Sorgen machen müssen? Scheint, als müssten wir die Ratenbegrenzungslogik von angemeldeten Benutzern manuell behandeln, aber was ist mit nicht angemeldeten Benutzern?

Ich vermute / hoffe, dass es einen eingebauten Mechanismus zur Begrenzung nicht authentifizierter Anfragen auf Hosting-Plattformen gibt. Bitte informieren Sie uns alle.

Was ist jedoch mit nicht angemeldeten (nicht authentifizierten) Benutzern? Wir wissen nicht genau, von wem oder woher die Anfrage kommt, können diese Anfragen also nicht einfach einschränken oder ..?

Es gibt einige Ansätze, die Sie verfolgen können. Zum einen benötigen Sie eine einigermaßen zuverlässige Ursprungskennung, beispielsweise eine IP-Adresse. Sie können das Limit nach IP-Adresse bewerten, sodass Angriffe auf einen einzelnen gefährdeten Computer begrenzt werden. Dies ist ein ziemlich einfacher Ansatz, aber es gibt einen Nachteil, dass es große Netzwerkanbieter gibt, die möglicherweise nur einzelne ausgehende IP-Adressen verwenden, um eine sehr große Anzahl von Benutzern hinter einem NAT zu verstecken.

Ein weiterer Ansatz zur Ratenbegrenzung besteht darin, für nicht authentifizierte Anfragen einen Arbeitsnachweis zu verlangen . Ihr Server gibt einen Challenge-Code aus, den Clients, die nicht authentifizierte Anforderungen stellen (z. B. Anmeldeanforderungen), eine ressourcenintensive Antwort berechnen müssen, bevor die Anforderung verarbeitet wird. Eine übliche Implementierung dieser Idee erfordert, dass die Clients eine teilweise Hash-Umkehrung berechnen.

Um zu wissen, ob eine Anfrage von einem authentifizierten Benutzer oder von einem anonymen Benutzer stammt, müssen Sie die Anfrage unbedingt (wenn auch schnell) bearbeiten. Dies bedeutet weiterhin, dass Ihre Anwendung für einen Denial-of-Service-Angriff anfällig ist.

Sie sollten die Gesamtanforderungen pro Sekunde überprüfen. Wenn eine bestimmte Anzahl überschritten wird, ignorieren Sie einfach den Rest. Diese Zahl sollte ausreichend hoch sein, um während des normalen Betriebs keine Probleme zu verursachen, sollte jedoch vor solchen Angriffen schützen.

Außerdem sollten Sie in der Regel nicht davon ausgehen, dass ein Angriff nicht von einem authentifizierten Benutzer ausgeht, zumindest was DOS-Angriffe betrifft. Ein schwaches Passwort würde es jemandem leicht ermöglichen, die Identität eines alten Benutzers anzunehmen. Angenommen, Sie könnten eine solche Prüfung durchführen, sollten Ihre (menschlichen) Benutzer niemals Anforderungen mit solchen Raten ausführen müssen, die nicht widerstehen, nur weil Sie viele einzelne Benutzer haben.

Eines der Hauptangebote von Cloudflare ist der Schutz vor Denial-of-Service-Angriffen durch Bereitstellung eines intelligenten Proxys für Ihre API / Ihren Webserver. Die Grundversorgung ist kostenlos; Sie verdienen Geld mit anderen verwandten Diensten wie CDN-Diensten und Lastausgleich. Sie bieten auch ausgefeiltere und kontrollierbarere Ratenbegrenzungsdienste , die derzeit 0,05 US-Dollar pro 10.000 gute Anfragen kosten (keine Gebühr für abgelehnte Anfragen). Sie müssen jedoch auf bezahlte Pläne upgraden, um mehr als eine globale Regel zu erhalten.

Sie können den Cloudflare-Dienst mit AWS oder einer anderen Plattform verwenden, solange Sie die Kontrolle über die Nameserver Ihrer Domain haben (wie in können Sie die für Ihre Domain registrierten Nameserver ändern).

Sie können separate Ratenlimits für anonyme und angemeldete Benutzer festlegen, indem Sie angemeldete Benutzer an verschiedene URLs weiterleiten. Beispielsweise können Sie einfach allen anonym verfügbaren URL-Pfaden das Präfix "/ u" voranstellen, um einen Endpunkt zu erstellen, der immer eine Authentifizierung erfordert und ein anderes Ratenlimit aufweist.

Beachten Sie, dass die Ratenbegrenzung von Cloudflare (wie alle mir bekannten kommerziellen Ratenbegrenzungen für anonyme Benutzer) einen Client anhand seiner IP-Adresse definiert. Dies kann zu Problemen für Benutzer von kommerziellen VPNs oder Tor führen, da diese aus Gründen der Privatsphäre eine große Anzahl von Clients hinter einer IP-Adresse verstecken.

In AWS gibt es die zugehörigen Dienste AWS Shield und AWS WAF . Sie sollen in erster Linie DDoS-Angriffe verhindern, bieten aber auch Unterstützung für die Ratenbegrenzung basierend auf IP-Adressen.

In WAF wird das Konzept als ratenbasierte Regeln bezeichnet . Das Verhindern von Brute-Force-basierten Anmeldeversuchen wird in der ursprünglichen Ankündigung als Anwendungsfall genannt :

Dieser neue Regeltyp schützt Kundenwebsites und APIs vor Bedrohungen wie DDoS-Angriffen auf Webebene, Brute-Force-Anmeldeversuchen und schlechten Bots. Ratenbasierte Regeln werden automatisch ausgelöst, wenn Webanforderungen von einem Client einen bestimmten konfigurierbaren Schwellenwert überschreiten.

Andere Cloud-Anbieter sollten ähnliche Angebote haben. Hier ist ein tabellarischer Vergleich: Google Cloud Armor vs. AWS WAF vs. Cloudflare WAF .

Da Sie Nginx bereits verwenden, kann die Verwendung der integrierten IP-basierten Ratenbegrenzung auch eine einfache Option sein. Das Modul heißt ngx_http_limit_req_module . Dieser Blog-Beitrag beschreibt, wie es verwendet werden kann.

Bitte beachten Sie, dass die IP-basierte Ratenbegrenzung ein relativ einfaches Konzept ist, aber nicht perfekt:

• IP-Adressen können gemeinsam genutzt werden (Personen, die im selben Büro arbeiten), was zu Fehlalarmen führt
• Ein Angreifer hat möglicherweise einfachen Zugriff auf mehrere IP-Adressen und verwendet diese, um die Grenzwerte zu umgehen (verteilter Brute-Force-Anmeldeangriff).

Im Allgemeinen sind IP-Adressen ein guter Anfang. Wenn Sie jedoch einen stärkeren Schutz benötigen, hängt Ihre beste Wahl von Ihrem Thread-Modell ab (welche Art von Angriffen Sie verhindern möchten).