it-swarm.com.de

Welcher Ansatz soll verwendet werden, um mehrere Anforderungen an die API zu verhindern, die öffentlich zugänglich sind?

Ich habe eine API, in der Besucher eine E-Mail über ein Abonnement senden können:

/ api/abonnieren

Wie kann ich diesen Endpunkt sichern, um eine massive Belastung durch öffentliche Exposition zu verhindern? Muss ich eine Datenbank verwenden oder kann ich dies ohne eine Art Caching, Speicher usw. tun, die alle 10 Minuten usw. veröffentlicht?

7
amels

Ich habe WebApiThrottle verwendet, mit dem Sie die Anforderungsmenge auf dem ausgewählten Endpunkt begrenzen können.

2
amels

Sie können Proof of Work verwenden, um die Ratenbegrenzung zu erzwingen, ohne sich IP-Adressen merken zu müssen.

Bei Proof of Work muss der Client eine rechenintensive Funktion ausführen, um einen Proof zu generieren, den Sie kostengünstig überprüfen können. Eine der häufigsten PoWs ist die partielle Hash-Inversion, bei der Sie verlangen, dass jeder API-Übermittlung ein Hash of Proof + Request beigefügt ist, für den der Hash ein vordefiniertes Präfix (normalerweise Nullen) einer bestimmten Länge haben muss. Für den Kunden erfordert die Berechnung des Beweises das Testen von Hunderten oder Tausenden potenzieller Beweise, bis er auf einen stößt, der die erforderliche Anzahl von Nullen aufweist. Das Ziel sollte sein, dass typische Clients für jede gesendete Nachricht mehrere Sekunden oder Minuten Rechenleistung aufwenden müssen. Für den Server umfasst die Überprüfung des Beweises jedoch nur eine Hash-Berechnung. Diese Asymmetrie bedeutet, dass es für den Client viel teurer ist, eine gültige Anforderung zu generieren, als für den Server, ungültige Anfragen abzulehnen.

Um Wiederholungsangriffe zu verhindern, können Sie verlangen, dass Anforderungen einen Zeitstempel oder einen Zähler enthalten müssen. Ihr Server kann prüfen, ob Anforderungen mit zu alten Zeitstempeln oder mit einem bereits verwendeten Zählerwert abgelehnt werden.

5
Lie Ryan

Ich habe das getan, also weiß ich, wie es optimal gemacht wird. Die Idee ist, eine Hash-Funktion wie SipHash zu verwenden, um einen Hash-Wert für die IP-Adresse zu berechnen. Dann verwenden Sie einen Token Bucket Algorithmus für jeden Hash Bucket: haben z. 100 anfängliche Token in jedem Hash-Bucket, fügen Sie 10 Token pro Sekunde bis zu maximal 100 Token hinzu und entfernen Sie jedes Mal einen Token, wenn Sie eine Anfrage erhalten. Wenn keine Token vorhanden sind, lehnen Sie die Anfrage ab. Dies würde 10 Anforderungen pro Sekunde mit einer maximalen Burst-Größe von 100 ermöglichen.

Theoretisch ist es möglich, dass zwei IP-Adressen in denselben Bucket gehasht werden. Dies ist jedoch in diesem Anwendungsfall kein Problem, wenn Sie über genügend Hash-Buckets verfügen.

Sie können die Buckets mithilfe von Batch-Timern aktualisieren. Z.B. Für 131072-Eimer können Sie z. 4096 Buckets pro Timer und dann 32 Timer, die innerhalb einer Sekunde gleichmäßig ablaufen. Bei 1/32 Sekunden aktualisieren Sie also die ersten 4096 Buckets, bei 2/32 Sekunden aktualisieren Sie die nächsten 4096 Buckets usw. Die Datenstruktur für die Verwaltung von Timern ist optimalerweise ein Prioritätswarteschlange wie z a binärer Heap .

Wenn jemand auf diese Weise implementiert wird und Ihr System mit zahlreichen gefälschten Quell-IP-Adressen überflutet, wird Ihr Speicher nicht gefüllt.

Der von diesem Ansatz verwendete Speicher verwendet 8, 16 oder 32 Bit pro Hash-Bucket, wenn Sie ein ganzzahliges Array verwenden. Die ganzzahlige Größe ergibt sich aus Ihren Anforderungen: z. 8 Bit können nicht mehr als Burst-Größen von 255 unterstützen. In ähnlicher Weise erlauben 16 Bit Burst-Größen von höchstens 65535. So kann z. 8 Bit oder 1 Byte pro Bucket und 131072 Buckets benötigen 128 Kilobyte Speicher. Nirgendwo ein Problem. Ein guter Computer verfügt über mindestens 2 GB Arbeitsspeicher, was mehr als das 15 000-fache der für dieses System erforderlichen Menge bedeutet.

Sie müssen auch die Speicherbandbreite berücksichtigen: Wenn jeder Bucket einmal pro Sekunde aktualisiert wird, beträgt die erforderliche Bandbreite 128 KB/s. Gute Computer unterstützen mehr als 5 GB/s Lese-/Schreibbandbreite oder mehr als das 40 000-fache dessen, was dieser Vorschlag von mir verwendet.

Speichern Sie den Cache im RAM. Verwenden Sie keine Datenbank oder Festplattendatei dafür. Wenn Ihr System abstürzt, initialisieren Sie einfach alle Buckets auf den Anfangswert.

4
juhist

Mit öffentlicher Exposition meinen Sie, dass die API selbst keine Authentifizierung erfordert? Sie können die Entscheidung, es überhaupt öffentlich zu machen, überdenken. Alles, was Sie Ressourcen kostet und Sie zusätzlich in Schwierigkeiten bringen könnte (das Versenden zu vieler E-Mails ) würde Sie in Schwierigkeiten bringen, sowohl mit Spam-Filtern als auch mit Personen, die diese erhalten E-Mails) sollten nicht öffentlich verfügbar sein, sondern auf die registrierten Benutzer beschränkt sein, die Sie sperren können (oder besser jede Anfrage bezahlen lassen).

Wenn Sie aus irgendeinem Grund keine Authentifizierung benötigen, können Sie leider nicht viel tun. Sie können nach DOS- und DDOS-Angriffen suchen; Sie werden viele Ressourcen finden, aber keine versichert Ihnen mit Sicherheit, dass die API von weisen Personen nur für legitime Zwecke verwendet wird.

Die Blockierung pro IP ist der grundlegendste, am wenigsten wirksame und auch der problematischste Schutz gegen DOS und DDOS. Die Hauptprobleme sind:

  • Die Tatsache, dass dieselbe IP-Adresse von mehreren Personen verwendet werden kann. In der Firma, in der ich arbeite, teilen sich wahrscheinlich mehrere Tausend dieselbe öffentliche IP-Adresse (oder einen kleinen Bereich von IP-Adressen).

    Dies verursachte einige Probleme mit einigen Websites, einschließlich Stack Exchange, die mehrmals behaupteten, zu viele Anfragen von der IP-Adresse erhalten zu haben, und uns blockierten. Tatsächlich generieren Hunderte von Entwicklern, die gleichzeitig arbeiten , viele Anfragen.

    In einem früheren Unternehmen hat uns die Google-Suche gelegentlich blockiert, sodass ein CAPTCHA ausgefüllt werden muss. Auch hier können Hunderte von Personen, die gleichzeitig arbeiten, jede Minute viele Google-Suchen durchführen.

  • Die Tatsache, dass ein DDOS-Angriff speziell von mehreren IP-Adressen aus ausgeführt wird. Möglicherweise erhalten Sie Hunderte oder Tausende von Anfragen, die jeweils von einer anderen IP-Adresse kommen und alle gleichzeitig auf Ihren Servern eingehen. Und selbst wenn Sie versuchen, diese Adressen zu blockieren (die Personen gehören können, die weder die Absicht noch die Fähigkeiten hatten, Ihrem Server Schaden zuzufügen, und die nicht einmal wissen, dass Ihre Website vorhanden ist), kann der Angreifer relativ einfach zu anderen Computern wechseln.

2