Slow Loris and Palo Alto Firewalls.

[amansour]

I had a number of questions from clients regarding Slow Loris/Flame and others. Wanted to post on this so others could look it up if it came up.

In response to the slow loris, the attack is executed based on timeouts with HTTP.  This leaves open connections on the server and slowly attempts to tie them all up.  This is only functional if the application (apace/windows IIS) is able serve connections over port 80 without enforcing the standard timeouts and traffic from a client.  Meaning just by having the firewall and allowing only “web-browsing” the http timers that open and wait for traffic to come back (and thus DOS the server) would not stay open.

In this article a user explains the attack and at the end recommends a layer 7 firewall (Palo Alto) to enforce the HTTP traffic to the webserver conforms to the timers and does not leave them open. 

http://www.howtoforge.com/how-to-defend-slowloris-ddos-with-mod_qos-apache2-on-debian-lenny

Any questions about the testing or attack, let me know! 

[mikand]

No matter if one use a PA or something else in front of the servers both the device in front of the servers (NGFW, SPIFW, Webproxy, Loadbalancer etc) and the servers itselfs should have tweaked the default timeout.

Often the default is 120 or 300 seconds which is often way too much. One can assume that if the client today doesnt get a response back within at least 30 seconds they will hit the refreshbutton (or even sooner).

So by lowering the default timeouts to 30 seconds (or even lower) you will in some way mitigate the slowloris.

However you might have applications that will need more than 30 seconds to complete (like searchengines and such) which is why you by design should put those resources on their own server and use a higher timeout just for them. So you end up with a default of lets say 15 seconds timeout for regular http and 30 seconds for http which goes to your searchengine servers (dont forget to instruct the searchengine itself that it should search for longer than 30 seconds or whatever timeout you choose).

For Apache there are modules that can be configured to better deal with slowloris attempts (except for the already mentioned mod_qos), such as mod_reqtimeout.

Set these settings in your apache-conf (just an example):

LoadModule reqtimeout_module modules/mod_reqtimeout.so

RequestReadTimeout header=3,MinRate=5000

RequestReadTimeout body=10,MinRate=5000

http://httpd.apache.org/docs/trunk/mod/mod_reqtimeout.html

[amansour]

Why would both be necessary.  If the timeout is adjusted on the firewall and connections come from outbound the timer is left open once connected to the apache server then isn't the firewall irrelevant?

For example if the firewall timers do not close a session for 5 seconds and the server has then open for a minute.  The 5 second session is established, stays open on the server for the minute and the server overflows.

I suspect if the firewall connection timers terminate so does the session, the timers that await a response only matter on the server in this case.

[mikand]

Well depends on the firewall and which settings you use.

A regular SPI based firewall, lets say iptables in a linuxbased firewall, will just handle the timeouts internally. When a session times out it wont notify server/client that the flow is no longer valid - they (client/server) will find this out once they try to send their PSH packet and noticies it doesnt come through (or rather they dont get the proper ACK in return).

So in my opinion you should adjust the timeouts in both devices (both the firewall/whatever and the server). This way the server wont use more resources than necessary and the same goes for the firewall device (which also have upper limits when it comes to concurrent sessions and stuff like that).