Limitazione di velocità delle richieste * un * -autenticate

Question

Limitazione di velocità delle richieste * un * -autenticate

#1 da (4 voti)
#2 da (3 voti)

0

Supponiamo di avere un sistema di bilanciamento del carico che limiti la velocità. La limitazione della velocità sembra abbastanza semplice per gli utenti che hanno effettuato l'accesso: basta guardare la JWT e magari usare un data-store in memoria per vedere quante richieste negli ultimi 10 secondi per quell'utente.

Tuttavia, per quanto riguarda gli utenti non connessi (non autenticati)? Non sappiamo con certezza da chi o da dove viene esattamente la richiesta, quindi non possiamo facilmente limitare le richieste o ...?

Esistono soluzioni integrate a questo su AWS e altre piattaforme di hosting è qualcosa di cui dobbiamo preoccuparci? Sembra che dobbiamo gestire manualmente la logica di limitazione della velocità degli utenti registrati, ma per quanto riguarda gli utenti non registrati?

La mia ipotesi / speranza è che potrebbe esistere un meccanismo integrato per le richieste non autenticate di limitazione della velocità sulle piattaforme di hosting, per favore informaci.

nginx load-balancing rate-limiting

posta MrCholo 24.12.2018 - 03:46

fonte

2 risposte

Leggi altre domande sui tag nginx load-balancing rate-limiting

Qual è il modello di interfaccia utente più pragmatico e di base da seguire per Silverlight e / o WPF Frasi chiave che mostrano i vantaggi di eseguire test di software certificati per la "tua" azienda?

score 4 · Answer 1

However, what about non-logged in (unauthenticated) users? We don't know for sure who they or where the request is coming from exactly, so can't easily rate-limit those requests or..?

Ci sono un paio di approcci che puoi adottare. Uno è che è necessario un identificatore di origine ragionevolmente affidabile, ad esempio l'indirizzo IP. È possibile valutare il limite in base all'indirizzo IP, in modo che gli attacchi su un singolo computer compromesso siano limitati. Questo è un approccio abbastanza semplice, ma c'è un inconveniente che ci sono grandi provider di rete che possono utilizzare solo indirizzi IP in uscita per nascondere un numero molto grande di utenti dietro un NAT.

Un altro approccio alla limitazione della frequenza che puoi eseguire è richiedere una prova di lavoro per qualsiasi richieste non autenticate. Il tuo server invia un codice di verifica che i client che effettuano richieste non autenticate (ad es. Richieste di accesso) devono calcolare una risposta intensiva della risorsa prima che la richiesta venga elaborata. Un'implementazione comune di questa idea richiede che i client calcolino una reversione hash parziale.

score 3 · Answer 2

Per sapere se una richiesta proviene da un utente autenticato o da un utente anonimo, devi necessariamente elaborare la richiesta (anche se rapidamente). Ciò significa che la tua applicazione è vulnerabile a un attacco denial of service.

Dovresti controllare le richieste complessive al secondo e se un determinato numero viene superato, devi semplicemente ignorare il resto. Quel numero dovrebbe essere sufficientemente alto da non causare problemi durante il normale funzionamento, ma dovrebbe proteggere da tali attacchi.

Inoltre, come regola generale, non dovresti presumere che un attacco non provenga da un utente autenticato, almeno per quanto riguarda gli attacchi DOS. Una password debole consentirebbe facilmente a qualcuno di presumere l'identità di un vecchio utente. Quindi, supponendo che tu possa fare un tale controllo, i tuoi utenti (umani) non dovrebbero mai avere bisogno di eseguire richieste a tali tassi, non sospettando semplicemente perché hai molti utenti individuali.