¿La aplicación web analiza los escaneos a través del firewall de la red?

2

Tengo un escenario. Quiero escanear una aplicación web que se coloca en otro DC detrás de un firewall diferente (no firewall de aplicaciones web). Podemos tener puertos abiertos para llegar a la aplicación. Las herramientas generalmente utilizadas por los evaluadores son Acunetix, Appscan, burp y webinspect. El servidor web no está detrás de un PAT o Nat. Aunque puede haber sido equilibrado en la carga.

¿Existe una preocupación seria de que este escáner de empresa pueda DOS o el firewall o degradar la red? ¿Las exploraciones de la aplicación web nunca deben realizarse a través de un firewall de red? ¿No debería el firewall ser capaz de manejar el tráfico desde una única instancia del escáner web?

Traté de encontrar algo de investigación en línea, pero casi todos los escenarios hablaron de NAT o PAT para un escáner de puertos (nmap) o un escáner de vulnerabilidades (qualys), que no es el caso aquí.

    
pregunta Sanchit Sharma 31.01.2017 - 06:48
fuente

1 respuesta

2

Algunos escáneres webappsec son en realidad más lentos que un usuario que usa un navegador web basado en XP.

Si Burp Suite Pro Intruder (o Scanner o Spider) se ajusta a más de 100 subprocesos, digamos 175 subprocesos, entonces las cosas comienzan a caer, pero generalmente la memoria de los servidores de destino antes de los equilibradores de carga o los cortafuegos intermedios. El máximo solía ser de 175 hilos, pero se cambió a 999 hilos en 2014.

Algunos firewalls basados en software caerán bajo la carga de un escáner webappsec extremadamente cruelmente ajustado, pero no de dispositivos o basados en hardware. Por ejemplo, un Palo PA-3020 aún impulsará el tráfico a destinos si tenía 20 o incluso 30 probadores de penetración con escáneres webappsec. Sin embargo, un Palo VM-100 solo puede caer en 2 o 3 probadores de penetración porque se basa principalmente en software.

WebInspect, AppScan y Acunetix son mejores que la configuración máxima del intruso de Burp Suite Pro (por ejemplo, WebInspect solo permite un máximo de 80 subprocesos simultáneos). Incluso cuando ajusté estos otros escáneres a los subprocesos máximos admitidos por su configuración, lo peor que ha ocurrido es que un servidor web o dos se bloquearían. Nunca se ha bloqueado un WAF, IPS o un equilibrador de carga de la misma manera. Pretenda que esto me ha pasado diez veces en mi vida y que la mitad de las veces un servidor web se bloqueó y la otra mitad de las veces se bloquearon dos servidores web. Cada vez, sin importar cuántos servidores web se hayan bloqueado, la causa principal de la falla se debió a que el servidor web solo tenía 256M, 512M o 768M de vDRAM. En cada caso, se trataba de sistemas operativos invitados de un hipervisor basado en virtualización de servidores o un entorno de alojamiento compartido. Era lo suficientemente simple como para pedirle al administrador del sistema de TI remoto que apagara el servidor, le diera un poco más de vDRAM (por lo general, 1G era suficiente) y lo iniciara de nuevo.

Por lo general, la mejor manera de determinar si hay un problema es alojar su infraestructura de prueba de lápiz (sus hosts de ataque) con una puerta de enlace que ejecute Linux. Luego, puede aprovechar ntop o tcptrace para buscar retransmisiones . Si no está recibiendo ninguna retransmisión, o una cantidad muy pequeña, entonces no hay daño, no hay falta. A veces verá herramientas que abrevian retransmisiones como retransmisiones, rexmit o rexmt. Consulte el libro, TCP / IP Illustrated, Volumen I: Los Protocolos, Segunda edición para obtener más información sobre las interacciones de TCP.

    
respondido por el atdre 31.01.2017 - 07:28
fuente

Lea otras preguntas en las etiquetas