Mitigating HULK Attacks with DoS Protection

by bvandivier on ‎03-27-2017 07:54 AM - edited on ‎04-04-2017 11:40 AM by (14,662 Views)

HULK Attack Summary


Example Scenario -  A PAN-OS device administrator believes he or she is experiencing a DoS attack against one of their webservers.  Upon further analysis, it is determined that HULK is being used to leverage this attack through the generation of varied and uniquely crafted HTTP requests. 


What is HULK? - HULK or "Http Unbearable Load King" is a Python script developed by Barry Shteiman. HULK was designed to repeatedly generate numerous uniquely crafted HTTP requests which will create load on a webserver, thereby exhausting webserver resources.  For more details please visit the creator's site


DoS Protection Policy to defend against HULK attacks

The information below provides an example wherein an administrator can leverage a DoS Protection Policy to defend against HULK attacks.


Caveat - Given the inherent intelligence within HULK simply applying a SYN Cookie based mitigation strategy may not be fully effective.  More granular protections are generally more effective.


Prerequisite - It is important that the administrator has a baseline understanding of how many TCP SYN requests per second are typical to the destination host(s) for which protection from a HULK attack is required.  These metrics are crucial when creating an effective DoS Protection Profile with appropriate thresholds for Alarm Rate, Activate Rate, and Max Rate.


DoS Protection Policy vs Zone Protection Profile

A typical HULK attack may attempt to launch a SYN flood against a target host in a single or distributed manner.  In addition to a large number of legitimate HTTP requests, HULK will also generate a large number of uniquely crafted malicious HTTP requests.


For this reason, it is important for an administrator to leverage the more granular protections afforded to them through a DoS Protection Policy as opposed to a broader Zone Protection Profile which, while effective, the latter may not provide fully sufficient coverage for attacks of this nature.  Page 19 of our Tech Note [4] "Understanding DoS Protection" provides detailed steps for creating the ideal DoS Protection Policy to mitigate a HULK attack.


Example DoS Protection Policy


1. Create a New DoS Protection Profile - Objects > Security Profiles > DoS Protection




2. Modify the newly created DoS Protection Profile and apply the appropriate parameters.

The below rate and duration values are arbitrary and applied as an example only.  As mentioned previously, proper due diligence should be exercised by an administrator to responsibly determine values which are appropriate to his/her environment.

  • Name - <TBD by admin>
  • Type = Classified 
  • Flood Protection
    • Enable "SYN Flood"
    • Action "Random Early Drop" aka "RED"
    • Alarm Rate - rate at which DoS Alarm is activated
    • Activate Rate - rate at which DoS Response is activated
    • Max Rate - maximum rate at which packets are allowed, when exceeded new packets are dropped
    • Block Duration - length of time offending packets will be denied




 3. Create a corresponding DoS Protection Policy rule - Policies > DoS Protection.


  • Monitor traffic from external source zone Untrust to internal destination zone DMZ
  • Specify a destination webserver of DMZ host (the host we want to protect)
  • Service = HTTP (TCP/80)
  • Action = Protect
  • Protection
    • Type = Classified
    • Profile = HULK-SYN-RED
    • Address = destination-ip-only



In the example above, we have created a DoS Policy rule with the above criteria to mitigate against HULK attacks.  Again, note that we are using a "Classified" DoS Protection Profile within this rule.


It is important to note this distinction as Classified profiles allow us to enforce different session rate limits for different classes of end hosts.  Classified profile functionality also allows us to achieve a more granular level of detection and protection as desired in this particular use case.


Additionally, our destination server is monitored individually for incoming traffic to prevent it from going above the configured rate limits from any number of source IPs.  


*(See page 19, section 3 "Classified Profiles", item 2 from Resource [4] Understanding DoS Protection)


HULK References

[1] -

[2] -


HULK Protection Resources

[3] -

[4] -



by mivaldi
on ‎04-06-2017 09:44 AM

This is a great article. I wanted to add that Zone Protection is also not effective for protecting servers behind the firewall because that implies that an allow policy exists to allow that traffic to the web-server. If the IP source is not spoofed and randomized, then successive packets will continue to match an allow policy. From the Zone Protection notes we know that: "Zone protection is enforced only when there is no session match for the packet because zone protection is based on new connections per second (cps), not on packets per second (pps). If the packet matches an existing session, it will bypass the zone protection setting".

by EdwinD
‎01-08-2018 08:23 PM - edited ‎01-08-2018 08:27 PM

In other words; $hhhh, it should just work (but nothing ever does).


I come from a generation of computer users who are used to things not working. The first computer I owned was a Commodore 64. I loved that little grey keyboard as if it were my child. It was temperamental, it was a bit of a pain at times, but by god it was beautiful. As anyone of that generation knows, you always had to have a jewellers Philips head screwdriver around to adjust the tape drives read head. If a game failed to load after a few attempts, it was time to realign. You didn’t complain, you just got on with it. Many a time I spent longer loading a game than I did playing it. By the end of its life, the tape drive was being powered by a 9 Volt battery that that I had jury rigged to it with blue tak – but I still loved it.


After that I had a Pentium 75 PC. This was the fastest home computer you could buy at the time and it was brilliant. Again, it was a bit temperamental. For instance, DOS games could be a bit difficult. Plug n Play was not all that widely available, so you would have to carefully choose your sound card type, your port, your DMA and IRQ settings. You had to alter batch files and config.sys files just to get your CD drive to work. Windows would forever run out of memory so you had to install memory managers, disk compression and daily defragging. You really needed to understand how every setting worked if you wanted to get the most from a PC, even then...

Ignite 2018, Amsterdam, Netherlands
Ask Questions Get Answers Join the Live Community