2012-07-28 11 views
6

La mia comprensione è che l'unico modo per mitigare realmente un attacco DDoS è automatizzare il processo di lista nera degli indirizzi/intervalli IP.Google App Engine e dos.xml

Google App Engine (GAE) consente di configurare e caricare un file dos.xml e specificare indirizzi IP/intervalli per la lista nera in qualsiasi momento.

Ovviamente, se la mia app Web è sotto un attacco DDoS ben orchestrato, gli indirizzi IP/intervalli che mi attaccheranno cambieranno costantemente.

Con quale frequenza GAE mi consente di aggiornare dos.xml? Quanto tempo impiega le modifiche per entrare in vigore? Chiedo perché sto inventando un sistema AutoBlacklister che ispeziona gli indirizzi IP che crede siano gli aggressori e aggiornerà dinamicamente dos.xml. Se ci sono più di 100 aggressori (GAE ti limita a 100 indirizzi/intervalli), solo i primi 100 "peggiori trasgressori" saranno nell'elenco.

Ma, se dos.xml può essere aggiornato solo con una certa periodicità (come una volta al giorno, ecc.), E se impiega troppo tempo (più di qualche minuto!) Per fare effetto, allora questo sistema è praticamente inutile contro un reale DDoS.

Inoltre, questa domanda presuppone che ci sia un modo per automatizzare il caricamento di dos.xml: c'è? Vorrei immaginare c'è un URL sicuro che potrei caricare il file con qualcosa come HttpClient, ma con GAE, non sai mai quali termini/restrizioni hai intenzione di affrontare! Grazie in anticipo!

+1

Non interamente correlati, ma solo per salvare potenzialmente alcuni problemi in seguito, la [documentazione] (https://developers.google.com/appengine/docs/java/config/dos) dice che è 'dos.xml' , piuttosto che 'ddos.xml'. –

+0

Grazie per averlo indicato (+1) - L'OP è ora aggiornato. – IAmYourFaja

+0

FWIW, il nuovo [GAE firewall] (https://cloud.google.com/appengine/docs/standard/python/application-security#app_engine_firewall) supporta gli aggiornamenti programmatici delle regole del firewall tramite l'API di amministrazione (REST): https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1beta/apps.firewall.ingressRules –

risposta

1

Blacklisting IP non è al 100% DDoS tecniche di mitigazione prova come:

A.) Botnet DDoS utilizzerà IP legittime (ad esempio Trojan botnet) e, in questo caso, il blocco IP sarà anche impedire l'accesso da legittima utenti.

B.) Questo non farà nulla contro l'attacco DDoS di rete (cioè SYN Flood) - un attacco che utilizza IP falsificati e non ha nemmeno bisogno di stabilire una connessione a 2 vie per far funzionare DDoS. (Per evitare ciò, è necessario disporre di una sorta di proxy inverso per cancello anteriore, per impedire l'accesso finché non viene stabilita una connessione 2 completa -> ACK ricevuto.)

Per la protezione DDoS completa è necessario avere una "pipa" abbastanza grande, sia investendo in hardware (troppo espansivo e quindi di solito non conveniente) o in una soluzione proxy front-gate in grado di bilanciare il traffico in eccesso pur consentendo di rimanere pienamente operativi (es. proxy Cloud).

+0

Google si occupa di tutto ciò per evitare che le richieste arrivino all'app in primo luogo ? –

+0

Non sicuro al 100%. So che consentono aggiornamenti ma non hanno familiarità con le loro politiche di prevenzione interne. Vorrei saperne di più a riguardo. –

2

È possibile aggiornare dos.xml tramite AppCfg. È possibile aggiornare questo file senza una ridistribuzione completa del server, che è un processo costoso. Per quanto ne so, non c'è limite alla frequenza con cui questo aggiornamento può essere eseguito.

distribuzione completa ha un limite che è descritto here:

Il numero di volte che l'applicazione è stata caricata da uno sviluppatore. Il contingente attuale è 1.000 al giorno.