Cos'è un tipico meccanismo di difesa / setup contro l'inondazione di chiamate sql back-end?

1

Sono interessato a capire quale sia uno scenario tipico di prevenzione del seguente scenario di attacco:

Il back-end ha come server SQL. Front-end un semplice HTML "Hello World" che passa un input (ad esempio il nome utente) da memorizzare in SQL (sterilizzato). Come si impedisce in genere a un utente malintenzionato di scrivere un ciclo for e di eseguire il martellamento dell'SQL con milioni di richieste di archiviazione fino all'esaurimento delle risorse? Come mettere un limite alle richieste / secondo per IP?

P.S. Per favore separa la mia ignoranza - uno sviluppatore di software desktop che cerca di espandere i miei confini :) Grazie!

    
posta Nicko Po 24.08.2015 - 19:01
fonte

3 risposte

2

La parte del database di questo è in gran parte irrilevante, in quanto una porzione non trascurabile del carico sarà sul server web anziché sul database.

Esistono quattro modi comuni per implementare la limitazione della velocità:

  1. Effettua verifiche della frequenza rispetto al contesto dell'utente, all'IP del client e ad altre informazioni all'interno dell'applicazione. Ciò consentirà un controllo più granulare su quali tipi di richieste desideri limitare e da chi, ma ha il lato negativo che la richiesta deve aver già colpito il server Web e l'applicazione per poter eseguire i controlli.
  2. Esegui la limitazione della velocità su un firewall basato su host, come iptables . Ciò consente di ridurre il carico sul daemon del server di applicazioni Web e qualsiasi risorsa di back-end, ma non consente (banalmente) di creare regole attorno alle quali le richieste dovrebbero essere limitate in modi diversi, poiché opera a livello di trasporto (TCP / IP) piuttosto che a livello di applicazione (HTTP).
  3. Installa un'appliance davanti al server Web che esegue il deep packet inspection (DPI) o funge da firewall per applicazioni Web (WAF). Questi sono spesso definiti firewall di livello 7 o firewall "full stack", poiché sono progettati per funzionare sul contenuto del livello dell'applicazione (ad esempio HTTP / HTTPS) e sui livelli inferiori. Si potrebbe obiettare che rientrano nel termine di Intrusion Prevention Systems (IPS), almeno in termini di configurazione in linea. Questi possono essere molto utili per terminare i contenuti indesiderati prima che colpiscano anche il server di destinazione, e possono essere molto potenti, ma hanno lo svantaggio che in genere è necessario inserire un sacco di lavoro di configurazione o acquistare un'application.
  4. Utilizzare un prodotto "sicurezza come servizio" (SaaS) davanti al server, progettato per mitigare attacchi come flooding e DDoS. Un esempio di questo è CloudFlare . Questi di solito non sono progettati direttamente per prevenire i tipi esatti di attacchi che hai menzionato, ma sono piuttosto buoni per oscurare traffico automatico malevolo e attacchi DoS.

Questi metodi non si escludono a vicenda; in effetti, un approccio combinato è spesso il più efficace.

    
risposta data 24.08.2015 - 19:19
fonte
2

Puoi usare rate limiting , questo è un modulo per questo su Apache , Nginx e IIS .

La limitazione dei tassi può ferire le persone che stanno dietro un proxy (come me), quindi non si dovrebbe negare l'accesso in base al limite, ma impiegare un'altra difesa non appena viene raggiunto il limite. Una difesa basata su captcha è utile e alcuni sistemi captcha (come ReCaptcha ) possono essere elaborati senza esaurire le risorse .

    
risposta data 24.08.2015 - 19:20
fonte
0

Come hai detto, solitamente viene utilizzata la limitazione della velocità basata su utente / ip per prevenire richieste eccessive. Se l'applicazione rileva un utente / ip che invia richieste oltre una soglia, l'applicazione deve interrompere l'archiviazione delle richieste nel database per impedire che si verifichi un denial-of-service.

    
risposta data 24.08.2015 - 19:07
fonte

Leggi altre domande sui tag