2012-07-28 40 views
6

Según tengo entendido, la única manera de mitigar realmente un ataque DDoS es automatizar el proceso de listas negras de rangos/direcciones IP.Google App Engine y dos.xml

Google App Engine (GAE) le permite configurar y cargar un archivo dos.xml y especificar direcciones IP/rangos a la lista negra en un momento dado.

Obviamente, si mi aplicación web está bajo un ataque DDoS bien orquestado, las direcciones IP/rangos que me atacarán cambiarán constantemente.

¿Con qué frecuencia GAE me permite actualizar dos.xml? ¿Cuánto tiempo tardan los cambios en entrar en vigencia? Lo pregunto porque estoy diseñando un sistema AutoBlacklister que inspecciona las direcciones IP que cree que son los atacantes, y actualizará dos.xml dinámicamente. Si hay más de 100 atacantes (GAE lo restringe a 100 direcciones/rangos), entonces solo estarán incluidos en la lista los "100 principales infractores".

Pero, si dos.xml solo se puede actualizar con una cierta periodicidad (como una vez al día, etc.), y si tarda demasiado (¡más de unos minutos!) En aplicarse, este sistema es bastante inútil contra un real DDoS.

Además, esta pregunta supone que hay una forma de automatizar la carga de dos.xml: ¿está ahí? Me gustaría imaginar hay una URL segura que podría cargar el archivo con algo así como HttpClient, pero con GAE, nunca se sabe qué términos/restricciones se van a enfrentar! ¡Gracias por adelantado!

+1

No del todo relacionado, pero para poder guardar algunos problemas más adelante, la [documentación] (https://developers.google.com/appengine/docs/java/config/dos) dice que es 'dos.xml' , en lugar de 'ddos.xml'. –

+0

Gracias por señalar eso (+1) - OP ahora se ha actualizado. – IAmYourFaja

+0

FWIW, el recientemente liberado [firewall GAE] (https://cloud.google.com/appengine/docs/standard/python/application-security#app_engine_firewall) admite actualizaciones programáticas de las reglas del firewall a través de la API de administración (REST): https://cloud.google.com/appengine/docs/admin-api/reference/rest/v1beta/apps.firewall.ingressRules –

Respuesta

1

listas negras IPs no es 100% DDoS técnicas de mitigación de prueba como:

A.) Botnet DDoS utilizará IPs de fiar (es decir, Trojan Botnet) y, en este caso, el bloqueo IP también impedir el acceso desde legítimo usuarios.

B.) Esto no hará nada contra el ataque DDoS de red (es decir, SYN Flood), un ataque que usa direcciones IP falsificadas y ni siquiera necesita establecer una conexión bidireccional completa para que funcione el DDoS. (Para detener esto, necesitará tener algún tipo de proxy inverso de puerta frontal en su lugar, para evitar el acceso hasta que se establezca la conexión 2 completa -> ACK recibido.)

Para una protección DDoS completa, necesitará tener una "tubería" lo suficientemente grande, ya sea invirtiendo en hardware (demasiado expansivo y, por lo tanto, usualmente no rentable) o en una solución de proxy de puerta frontal que equilibrará el tráfico adicional y le permitirá mantenerse completamente operativo (es decir, proxy de nube))

+0

¿Se encarga Google de esto para evitar que las solicitudes lleguen a la aplicación en primer lugar? ? –

+0

No 100% seguro. Sé que permiten actualizaciones pero no están familiarizados con sus políticas internas de prevención. Me gustaría aprender más sobre esto yo mismo. –

2

Puede actualizar dos.xml hasta AppCfg. Es posible actualizar este archivo sin una redistribución completa del servidor, que es un proceso costoso. Hasta donde yo sé, no hay límite en la frecuencia con la que se puede realizar esta actualización.

despliegue completo tiene un límite que se describe here:

El número de veces que la aplicación ha sido subido por un desarrollador. La cuota actual es de 1,000 por día.