2

I have a scenario. I want to scan a web app which is placed in another DC behind a different firewall(not web application firewall). We can have open ports to reach the application. The tools generally used by testers is Acunetix, Appscan, burp and webinspect. The Web server is not behind a PAT or Nat. It may have been load balanced though.

Is there a serious concern that these enterprise scanner would DOS the firewall or degrade the network? Should Web App scans be never done through a network firewall? Shouldn't the firewall be able to handle the traffic from a single instance of the web scanner?

I tried to find some research online but almost all scenarios talked about NAT or PAT scenarios for a port scanner(nmap) or vulnerability scanner(qualys), which is not the case here.

Sanchit Sharma
  • 331
  • 5
  • 9

1 Answers1

2

Some webappsec scanners are actually slower than one user using one XP-based web browser.

If Burp Suite Pro Intruder (or Scanner or Spider) is tweaked to over 100 threads, say 175 threads, then things start to fall down, but usually the memory of the target servers before load balancers or firewalls in-between. The max used to be 175 threads but changed to 999 threads in 2014.

Some software-based firewalls will fall under the load of an extremely-cruelly tweaked webappsec scanner, but not appliances or hardware-based ones. For example, a Palo PA-3020 will still push traffic to destinations if you had 20 or even 30 penetration testers using webappsec scanners. However, a Palo VM-100 might only fall to 2 or 3 penetration testers because it's mostly software-based.

WebInspect, AppScan, and Acunetix are nicer than Burp Suite Pro Intruder's maximum configuration (e.g., WebInspect only allows a max of 80 concurrent threads). Even when I tweaked these other scanners to max threads supported by their configuration, the worst that has ever happened was that a web server or two would lock up. Never had a WAF, IPS, or load balancer lock up in that same way. Pretend this has happened to me ten times in my life and that half of the time one web server locked up and the other half of the time two web servers locked up. Every time, no matter how many web servers locked up -- the root cause of failure was due to the web server only having 256M, 512M, or 768M of vDRAM. In every instance these were guest OSes of a server-virtualization based hypervisor or a shared-hosting environment. It was simple enough to ask the far-end IT System Administrator to shutdown the server, give it some more vDRAM (usually 1G was enough), and start it back up.

Usually the best way to determine if there is a problem is to host your pen-test infrastructure (your attacking hosts) with a gateway running Linux. Then, you can leverage ntop or tcptrace to look for retransmissions. If you're not getting any retransmissions, or a very-small amount, then no harm, no foul. Sometimes you will see tools abbreviate retransmissions as retrans, rexmit, or rexmt. Check out the book, TCP/IP Illustrated, Volume I: The Protocols, Second Edition for more information about the inter workings of TCP.

atdre
  • 19,072
  • 6
  • 61
  • 108
  • Yes, that has been my experience as well but in my org there is a concern for the firewalls, which i think should not be a problem. And yes i was referring to hardware based or appliance based firewalls. – Sanchit Sharma Jan 31 '17 at 06:39
  • Usually these concerns involve careful preparation and planning. Having performed thousands of these scans in my lifetime, I would tell the people who have concerns that their concerns come from fear and not wisdom or knowledge. I would ask if the firewall, load balancers, and web servers (each network element in the path including the destination hosts) are hardware accelerated, and especially if they are not, if they have at least 1GB of DRAM. – atdre Jan 31 '17 at 06:52