Why a 3Gbps DoS can take out your 40Gbps NGFW and 20Gbps Internet Circuit

Denial of Service (DoS Attack) or Distributed Denial of Service (DDoS attack) is still a hot topic in 2016 even though it was discovered in 1994 and began being seen in the wild in September of 1996. There are many solutions that counter these attacks via on premise and off premise solutions. Let’s expand on on-premise solutions.

A DoS attack is an attack that is not necessarily volumetric in nature. Instead is it focused on overwhelming the on premise gear but not  saturating the full internet pipe. A good example of this would be a syn flood that fills up the connection table on your firewall. I know what you are thinking, “But Brian, we have a NGFW that is capable of moving 40Gbps!” but let’s look at this a bit closer. Yes, your firewall is capable of moving a 20GB file but what happens if you break up that 40GB into millions of connections? The real attack vector here is not throughput, it’s connections.

Connections per second (CPS):

Connections per second (CPS) refers to the rate at which a device can establish state parameters for new connections. A stateful device must create and manage connection information on all unique IP streams that transit the device. Typically, the device must handle the first packet of a new connection differently than all subsequent packets so that the device can establish the state parameters for the new connection. Because this process is specialized, it usually occurs in the software process of the devices, as opposed to the normal hardware-based forwarding process.

What firewall administrators usually do not do is to check the max CPS numbers their Internet facing link can carry. This number depends on the Internet link speed. It is the same number as the max frames per second a link can carry. Frames per second is calculated as following:
(Link speed)/(84 Byte * 8bit/Byte) = max frames per second.

Each frame can be a new connection (UDP), therefore max FPS = max CPS Here an overview of how many CPS a link can transport related to link speed:

Link SpeedMax CPS
100 Mbps148, 809
1,000 Mbps (1Gbps)1,488,906
10,000 Mbps (10Gbps)14,880,960

Maximum Concurrent Connections (MCC)

The number of concurrent connections is directly related to the max CPS number. When a Firewall hits it’s concurrent connection limits it does not accept new connections for any service and all services behind this firewall are not accessible for new requests. This number shows also the time a DDOS attack needs to take a firewall down and also the time the firewall has to take countermeasures against the attack. If for example, a firewall processes a DDOS mitigation run every 30 seconds but the firewall is overloaded in 10 seconds then it is too late for countermeasures.

So, why does it bother me? My Firewall does 40Gbps!

Well, what firewall vendors advertise is the throughput of the system for transferring large files. Unfortunately DDOS attacks do not use regular traffic. The frontend Internet facing firewall should be designed to handle the Internet facing threat potential. This is the reason why Administrators do not choose a 200 Mbps firewall to protect against a 1 Gig link. The same sizing guides should be taken into account for CPS.

Action Item for you: Go to your Firewall vendor product specification list and check the CPS numbers they publish.

What is the result?

Your Firewall cannot protect you. Even more: even if you upgrade to the strongest appliance model your Firewall vendor offers, it will not protect your datacenter because it can not handle the CPS threat. Please note, this post isn’t here to pick on your current firewall. At the end of the day, these are complementary solutions. Most likely you did not buy your NGFW for DoS/DDoS mitigation however advertised speeds tend to give a false sense of security.
Here are some real life examples (state of Dec 2015):

Vendor Name1 Gbps Threat Protection10 Gbps Threat Protection
Cisco ASA 5585-X CPS: 350,000
CC: 10M
23.5% threat protection Exhausted in 7 sec2.3% threat protection Exhausted in 0.7 sec
Juniper SRX 5800 CPS: 450,000
CC: 100M
30.2% threat protection Exhausted in 67 sec3% threat protection Exhausted in 6,7 sec
Checkpoint 61000 CPS: 3,000,000 CC: 210M100% threat protection Exhausted in 141 sec20.1% threat protection Exhausted in 14 sec
Fortinet Fortigate 5001D CPS: 565,000
CC: 23M
38% threat protection Exhausted in 16 sec3.8% threat protection Exhausted in 1.6 sec

Please note: all the Firewalls are High End Firewalls and partially marked as Carrier class devices, which means, they are also priced as carrier class devices.

How do I protect my perimeter firewall?

F5 is the only vendor that offers high speed Firewall protection at midsize appliances. Here an overview of possible F5 Firewall solutions:

BIG-IP 5205vBIG-IP 12250vVIPRION B2250VIPRION B4300
Throughput30 Gbps80 Gbps320 Gbps640 Gbps
CPS700k1.5M4.0M11.2M
CC24M80M192M288M
SYN Cookie40M80M240M640M

It’s interesting to note that 5250v (smallest appliance) is only a 2U  that is capable of cleaning just about anyone’s internet circuit. I am unaware of anyone in the southwest with pipe greater than 20Gbps.

Do I migrate my existing perimeter firewall to a F5 firewall?

In short, no. A F5 System could be installed in parallel with the existing Firewall. However, in recent efforts, I have deployed the F5 as a L2 Transparent DoS/DDoS mitigation device in front of the existing firewalls. The draw for this is the  deployment is simple, easy to manage, you keep your existing policy on your firewalls, and utilize the F5 for mitigation only.

 Credit: Vladimir Bojkovic

In 2015, I personally worked on two projects where customers used the F5 as a L2 Transparent DDoS mitigation device after suffering outages.

Project #1: Customer had a pair of PA-7050’s( App ID and Threat Detection enabled) on the perimeter and a 1 Gbps internet circuit. They were hit with a NTP reflection attack that caused an outage and the Palo Alto boxes to fall over. Post mortem, the NTP reflection attack was on 230 Mbps in size but exhausted the CPS on the PA. For those of you wondering, the box only had 478 Mbps running thru it at the time.

We positioned the 5250v box at the perimeter for mitigation. Currently the network and security team sees the F5 as their first line of security for any and all L3/L4 attacks.

Project #2: This customer has a mixture of technologies in their environment which lead to a false sense of security. At the perimeter, they had Cisco 5585-40’s along with 20Gbps internet circuits. Early in the fall, they were hit with a 3Gbps TCP SYN flood (3 million unique client IPs) that took the down the PA’s.

We positioned the VIPRION B2250 as a L2 transparent DDoS firewall.  The beautiful part of this solution was, it went directly into production and it did not associate a single helpdesk ticket; it truly went in as a bump on the wire.

If you have any questions or comments, feel free to leave your thoughts below.

Regards,

BD

iRules: Insert client certificate into HTTP Header

This iRule should be used when the back end server requires to see the client certificate presented to a VIP where SSL is being terminated and client authentication is being enforced. This iRule will do the following:

  • Check for existing HTTP Headers such as X-Forwarded-For and ssl.client_cert and remove them
  • Grab the client certificate and strip out any spaces or new lines
  • Insert the trimmed down client certificate into the HTTP Header ssl.client_cert
  • Insert the HTTP Header X-Forwarded-For with the client IP address
when HTTP_REQUEST {
	if { [HTTP::header exists "X-Forwarded-For"]} {
		HTTP::header remove X-Forwarded-For
		}
	if { [HTTP::header exists "ssl.client_cert"]} {
		HTTP::header remove ssl.client_cert
		}
	if { [SSL::cert count] > 0 } {
		set thecert [findstr [X509::whole [SSL::cert 0]] "-----BEGIN CERTIFICATE-----" 28 "-----END CERTIFICATE-----"]
		set certnospace [string map -nocase {" " "" \n "" \r ""} $thecert] 						  		
		HTTP::header insert ssl.client_cert $certnospace
		HTTP::header insert X-Forwarded-For [IP::client_addr]
	}
}

You may download a text version of the iRule here.

Regards,

BD

iRules: IP Reputation based on X-Forwarded-For HTTP Header

Recently I had a customer that wanted to use the IP Reputation Database on the F5 WAF however the client IP address was being proxied by an upstream device. Luckily for us, the client IP address was being sent in the X-Forwaded-For HTTP Header and we were able to hone in on that information and apply the IP Reputation logic via iRules.

The example below allows you to extract the client IP address from the X-Forwarded-For HTTP Header, check the IP Reputation Database, and either silently drop the traffic or respond with HTTP content.

when HTTP_REQUEST {
    # LOGGING OFF=0, LOGGING ON=1
    set DEBUG_LEVEL 1
    # SLIENT DROP BAD TRAFFIC=0, FRIENDLY DROP BAD TRAFFIC=1
    set BAD_ACTOR 1
    # Make sure XFF is present and the IP matches IPI
    if { ([HTTP::header exists "X-Forwarded-For"]) and not ( [IP::reputation [HTTP::header values "X-Forwarded-For"]] =="") } {
        set ip_reputation_categories [IP::reputation [HTTP::header values "X-Forwarded-For"]]
        set is_reject 0
        switch -glob $ip_reputation_categories {
            *Spam* { set is_reject 1  }
            *Proxy* { set is_reject 1 }
            *Denial* { set is_reject 1 }
            *Attacks* { set is_reject 1 }
            *Botnets* { set is_reject 1 }
            *Scanners* { set is_reject 1 }
            *Exploits* { set is_reject 1 }

        }
        if { ($is_reject)} {
            if { $BAD_ACTOR == "1"}{
                if { $DEBUG_LEVEL == 1} { log local0. "XFF:[HTTP::header values "X-Forwarded-For"] matched IPI Category:$ip_reputation_categories and was rejected with a page."}
                HTTP::respond 403 content "
                <HTML>
                <HEAD>
                <TITLE>Rejected Request</TITLE>
                </HEAD>
                <BODY>The request was rejected. <BR>Attempted access from malicious IP address</BODY>
                </HTML>"
                return
            }
            if { $BAD_ACTOR == "0"} {
                if { $DEBUG_LEVEL == 1} { log local0. "XFF:[HTTP::header values "X-Forwarded-For"] matched IPI Category:$ip_reputation_categories and was sliently dropped."}
                drop
                return
                }
            }
        }
        if { [HTTP::header exists "X-Forwarded-For"] } {
            if { $DEBUG_LEVEL == 1} {log local0. "XFF:[HTTP::header values "X-Forwarded-For"] and did not match any categories"}
            return
        }
    if { $DEBUG_LEVEL == 1} {log local0. "No XFF Sent and nothing was dropped"} 
}

You may also download a txt version of the iRule here.

Note: You can replace X-Forwarded-For to any HTTP Header that contains the client IP address, e.g, true-client-ip.

Regards,

BD