Limitazione della velocità * richieste non autenticate *

11

Supponiamo di avere un bilanciamento del carico che limiti anche la velocità. La limitazione della velocità sembra piuttosto semplice per gli utenti che hanno effettuato l'accesso: basta guardare JWT e forse usare un archivio dati in memoria per vedere quante richieste negli ultimi 10 secondi per quell'utente.

Tuttavia, che dire degli utenti non registrati (non autenticati)? Non sappiamo con certezza da chi o da dove provenga esattamente la richiesta, quindi non è possibile limitare facilmente tali richieste o ...?

Ci sono soluzioni integrate 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 esserci un meccanismo incorporato per limitare le richieste non autenticate su piattaforme di hosting, per favore informaci tutti.

load-balancing nginx rate-limiting

2

Questa pagina non menziona mai gli utenti che hanno effettuato l'accesso. In effetti, le tecniche ivi descritte sono citate come una mitigazione degli attacchi di forza bruta alle password, il che implica che gli utenti non sono connessi.

— Robert Harvey,

1

Perché vuoi usare la limitazione della velocità? È per contrastare gli attacchi Denial of Service, per impedire agli utenti di superare il loro piano di pagamento, qualcos'altro? Il caso d'uso influisce sui metodi che è possibile utilizzare in modo efficace.

— Bart van Ingen Schenau,

1

Questa domanda potrebbe essere più adatta a security.stackexchange.com , anche se non sto dicendo che è fuori tema

— Peeyush Kushwaha,

@BartvanIngenSchenau tutto quanto sopra?

Perché dovresti avere due limiti di velocità diversi? Stai vendendo qualche "piano" di ordinamento con vincoli / caratteristiche diverse?

— Laiv

9

Tuttavia, che dire degli utenti non registrati (non autenticati)? Non sappiamo con certezza da chi o da dove provenga esattamente la richiesta, quindi non è possibile limitare facilmente tali richieste o ...?

Ci sono un paio di approcci che puoi prendere. 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 piuttosto semplice, ma c'è uno svantaggio che ci sono grandi fornitori di rete che possono usare solo singoli indirizzi IP in uscita per nascondere un numero molto elevato di utenti dietro un NAT.

Un altro approccio al limite di velocità che puoi adottare è quello di richiedere una prova del lavoro per eventuali richieste non autenticate. Il server emette un codice di verifica che tutti i client che richiedono richieste non autenticate (ad es. Richieste di accesso) devono calcolare una risposta ad alta intensità di risorse prima che la richiesta venga elaborata. Un'implementazione comune di questa idea richiede ai clienti di calcolare una reversione parziale dell'hash.

— Lie Ryan
fonte

Non riesco a vedere, come "prova del lavoro" può impedire dagli attacchi DOS? Il client potrebbe ignorare la sfida e continuare a inviare richieste fino al fallimento. Esiste un terzo processo per gestire la sfida?

— Laiv

4

@Laiv POW può essere emesso in modo affidabile e verificato distribuito senza collegarsi a un database centrale, che è dove la maggior parte degli altri schemi di limitazione della velocità falliscono. Aumenta il costo di un attacco per un attaccante, poiché ridurre la tua difesa e aumentare il fattore di carico è più economico per te e per gli utenti legittimi che ridimensionare l'attacco per l'attaccante. Crea un disincentivo economico per attaccare il sistema, in quanto esclude efficacemente anche dispositivi a bassa potenza (ad esempio stampanti compromesse, IOT, router) dall'utilizzo come piattaforma di attacco efficace.

— Lie Ryan,

6

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 l'applicazione è vulnerabile a un attacco di tipo Denial of Service.

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

Inoltre, come regola generale, probabilmente non dovresti presumere che un attacco non verrebbe 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 simile controllo, i tuoi utenti (umani) non dovrebbero mai aver bisogno di eseguire richieste a tali tassi, nonostante il fatto che tu abbia molti singoli utenti.

— Neil
fonte

Suppongo che tu possa utilizzare gli indirizzi IP e impostare un limite di velocità elevato per ognuno. Immagino che un attacco DoS ben orchestrato potrebbe usare migliaia di indirizzi IP? forse di più? idk ... Sono consapevole che lo stesso indirizzo IP potrebbe essere utilizzato per più client diversi, ma direi che esiste una forte probabilità che sia lo stesso utente, giusto?

— Alexander Mills,

@AlexanderMills Supponiamo che tu abbia deciso che l'algoritmo sarebbe controllare più richieste dallo stesso indirizzo IP. Anche se ce ne sono migliaia, verrebbero ripetuti per più di 1000 richieste. Il tuo server registra la prima richiesta da un determinato indirizzo IP e inizia l'inondazione .. il tuo server è già backlog con richieste .. non puoi nemmeno elaborare abbastanza richieste per arrivare alla seconda ripetizione dallo stesso IP (che potrebbe essere comunque una richiesta legittima a proposito). Proteggerebbe dagli attacchi DoS in cui viene utilizzato solo lo stesso IP. Meglio usare entrambi se non altro. : P

— Neil,

0

Una delle principali offerte di Cloudflare è la protezione dagli attacchi Denial of Service fornendo un proxy intelligente per l'API / il server Web. Il servizio di base è gratuito; fanno soldi con altri servizi correlati come i servizi CDN e il bilanciamento del carico. Forniscono inoltre servizi di limitazione della tariffa più sofisticati e controllabili , attualmente al tasso di 0,05 USD per 10.000 richieste valide (nessun addebito per richieste respinte), ma è necessario passare a piani a pagamento per ottenere più di una regola globale.

Puoi utilizzare il servizio Cloudflare con AWS o qualsiasi altra piattaforma purché tu abbia il controllo sui server dei nomi del tuo dominio (come in, puoi cambiare i server dei nomi registrati per il tuo dominio).

Puoi fornire limiti di velocità separati per gli utenti anonimi e che hanno effettuato l'accesso indirizzando gli utenti che hanno effettuato l'accesso a URL diversi. Ad esempio, potresti semplicemente aggiungere come prefisso tutti i percorsi URL disponibili in modo anonimo con '/ u' per creare un endpoint che richiede sempre l'autenticazione e ha un limite di velocità diverso.

Si noti che la limitazione della tariffa di Cloudflare (come tutta la limitazione della tariffa commerciale per gli utenti anonimi di cui sono a conoscenza) definisce un client in base al suo indirizzo IP. Ciò può causare problemi alle persone che utilizzano VPN commerciali o Tor, poiché tendono a nascondere un gran numero di client dietro 1 indirizzo IP per una maggiore privacy.

— Vecchio professionista
fonte

0

In AWS sono disponibili i servizi correlati AWS Shield e AWS WAF . Sono principalmente destinati a prevenire gli attacchi DDoS ma offrono anche supporto per la limitazione della velocità basata su indirizzi IP.

In WAF, il concetto si chiama Regole basate sui tassi . Prevenire i tentativi di accesso basati sulla forza bruta è menzionato come caso d'uso nell'annuncio originale :

Questo nuovo tipo di regola protegge i siti Web e le API dei clienti da minacce come attacchi DDoS a livello Web, tentativi di accesso a forza bruta e bot dannosi. Le regole basate sulla tariffa vengono attivate automaticamente quando le richieste Web da un client superano una determinata soglia configurabile.

Altri provider cloud dovrebbero avere offerte simili. Ecco un confronto tabellare: Google Cloud Armor vs AWS WAF vs Cloudflare WAF .

Dato che stai già utilizzando Nginx, l'utilizzo della limitazione della velocità basata su IP integrata potrebbe anche essere un'opzione semplice. Il modulo si chiama ngx_http_limit_req_module . Questo post sul blog descrive come può essere utilizzato.

Si noti che la limitazione della velocità basata su IP è un concetto relativamente semplice ma non è perfetto:

Gli indirizzi IP potrebbero essere condivisi (persone che lavorano nello stesso ufficio) portando a falsi positivi
Un utente malintenzionato potrebbe avere un facile accesso a più indirizzi IP e utilizzarli per aggirare i limiti (attacco distribuito a forza bruta)

In generale, gli indirizzi IP sono un buon inizio. Ma se hai bisogno di una protezione più forte, le tue scelte migliori dipenderanno dal tuo modello di thread (che tipo di attacchi vuoi prevenire).

— Philipp Claßen
fonte