Cupfighter.net

The Cisco ASA firewall offers protection for Denial of Service attacks, such as SYN floods, TCP excessive connection attacks etc.
With the Policy Framework functionality, you can configure granular controls for TCP Connection limits and timeouts. For example, you can control and limit the maximum number of simultaneous TCP and UDP connections that are allowed towards a specific host (or subnet), the maximum number of simultaneous embryonic connections allowed (for SYN flood attacks), the per-client max number of connections allowed etc.

STEP1: Identify the traffic to apply connection limits using a class map
ASA(config)# access list CONNECTIONS-ACL extended permit ip any 10.1.1.1 255.255.255.255
ASA(config)# class-map CONNECTIONS-MAP
ASA(config-cmap)# match access-list CONNECTIONS-ACL

STEP2: Add a policy map to set the actions to take on the class map traffic
ASA(config)# policy-map CONNECTIONS-POLICY
ASA(config-pmap)# class CONNECTIONS-MAP
! The following sets connection number limits
ASA(config-pmap-c)# set connection {[conn-max n] [embryonic-conn-max n]
[per-client-embryonic-max n] [per-client-max n] [random-sequence-number {enable | disable}]}

The conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535.
The embryonic-conn-max n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535.
The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535.
The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535.

! The following sets connection timeouts
ASA(config-pmap-c)# set connection timeout {[embryonic hh:mm:ss] {tcp hh:mm:ss
[reset]] [half-closed hh:mm:ss] [dcd hh:mm:ss [max_retries]]}

STEP3: Apply the Policy on one or more interfaces or Globaly
ASA(config)# service-policy CONNS-POLICY {global | interface interface_name}

The IP audit feature provides basic IPS support for the ASA. It supports a basic list of signatures, and you can configure the ASA to perform one or more actions on traffic that matches a signature.

STEP:1 To define an IP audit policy for informational signatures
ASA(config)# ip audit name policy_name info [action [alarm] [drop] [reset]]

STEP:2 To define an IP audit policy for attack signatures
ASA(config)# ip audit name policy_name attack [action [alarm] [drop] [reset]]

Where alarm generates a system message showing that a packet matched a signature, drop drops the packet, and reset drops the packet and closes the connection. If you do not define an action, then the default action is to generate an alarm.

STEP:3 To assign the policy to an interface
ASA(config)# ip audit interface interface_name policy_name

STEP:4 To disable signatures
ASA(config)# no ip audit signature [signature]

The ACE has two different ways of treating the L7 connections internally, that we call “proxied” and “unproxied”. In essence, the proxied mode means that the traffic will be processed by one of the CPU (normally to inspect/modify the L7 data), while, on the unproxied mode, the ACE sets up a hardware shortcut (Fastpath) that allows forwarding traffic without the need to do any processing on it.

For a L7 connection, the ACE will proxy it at the beginning, and, once all the L7 processing has been done it will unproxy the connection to save resources until L7 processing is required again. Before it goes ahead with the unproxying, it needs to see the ACK for the last L7 data sent.
In packet captures, we see that the client is taking approximately 200ms to send this acknowledgement each time. When a connection is composed of many HTTP requests, the proxy/unproxy process can add up a total delay of several seconds.

The configuration of a sorry/backup server farm with for example a HTTP redirect to a sorry page will cause the ACE to treat the connections to the VIP as a L7 and influence the total page load time.

The proxy/unproxy delay can have a big impact for situations in which the client is taking a long time to send the acknowledgement, so, the ACE allows to change the behavior. It is possible to define a “round-trip-time” threshold so that connections from clients with a RTT value higher than the threshold are never unproxied.
You can do this by setting the threshold to 0 to ensure to keep connections always proxied. To do this, you would need to configure a parameter map like the one below and add it to the policy-map.
parameter-map type connection
set tcp wan-optimization rtt 0

Even though this setting will most likely solve the issue, it also has some drawbacks. The main one is that the ACE appliance only supports up to 256K simultaneous L7 connections in proxied state (which includes also the connections towards the servers, so, it would be 128K for client connections), so, if the amount of simultaneous connections reaches that limit, new connections would be dropped. The second issue, although not so impacting, would be that the maximum number of connections per second supported would also go down slightly due to the increased processing needed.

Today I spent most of my time analyzing the Slowloris and Nkiller2 denial of service (DoS) tools together with my colleague Gert Kremer.

Slowloris (name after the slow moving primates is a httpd DoS tool written by RSnake of ha.ckers. It works by tying up the httpd worker processes by slowly sending more and more headers of an httpd request.

Nkiller2 is a TCP/IP DoS attack tool which was published in issue 66 of Phrack magazine. It works by tying up httpd worker processes by requesting a file then stalling, mimicking the behavior of a client with full TCP/IP receive buffers.

Cisco CSS is a load balancer produced by Cisco.

In nearly all of the infrastructures built by my employer Schuberg Philis, the web servers are located behind a load balancer. In most cases a Cisco CSS. Because some of our customers were worried, I set out together with my colleague Gert Kremer to see if having a CSS load balancer in front of the web server provides any protection.

Slowloris

First we just had to try and find out what Slowloris did with an unprotected Apache server. The first video shows what happens when you run slowloris against a webserver. The window on the top left shows the number of apache processes, the top right window shows the scoreboard. This shows what the http processes are actually doing. The bottom window shows the slowloris output.

Slowloris vs Apache (No load balancer)

When slowloris is using 100 sockets, you can see 100 httpd workers in state “R”, meaning it is reading requests. The same is the case when running with 200 and 250 sockets. When running with 300 sockets the apache worker processes pool is exhausted and the web server can no longer service requests.

Slowloris vs Apache behind a Cisco CSS load balancer

Slowloris is running against the webserver with 3000 sockets (should be more then enough). As you can see on the top two windows the load balancer does not forward any of the incomplete requests to the webserver. We have stress tested the loadbancer up to 10,000 sockets and it had no effect on the loadbancer.

NKiller

Nkiller vs Apache (No load balancer)

In the video we see for windows. Top left and right show the number of apache processes and the apache dashboard. The middle window displays the NKiller output and the bottom window TCPdump.

When NKiller starts we see the it exhausts the httpd workers processes by putting them in a state where they are hanging while writing their reply back to the client.
Nkiller vs Apache behind a CSS load balancer

When NKiller was used against a server protected by a Cisco CSS load balancer the packets received from the load balancer do not match the expections of the Nkiller tool and the tool crashed producing a segmentation fault.