When was the last time you went into a travel agent or actually bought a ticket at the airport? If AA.com goes down they start canceling flights. In one catastrophic single day server outage, last April American Airlines canceled 970 flights and delayed 1,078 more.  Internet server availability is just as critical to your business.

An industry report published last week stated that over the past 12 months the bandwidth consumed by Distributed Denial of Service (DDoS) attacks worldwide had grown by 72%.  How is this even possible? Simple, the percentage of total cloud & infrastructure servers that have been compromised and turned into bot nets has soared. As recently as last week Amazon’s cloud service had been comprised.  So what chance do any of us have in protecting the servers we use to run our business?

In addition to the traditional defense in depth technologies, one can add another layer of protection by placing a hardware firewall on the server itself. This is not a new concept, back in 2002 3Com sold the 3CR990 which offered an optional firewall on their current 10/100Mbps ethernet controller. Few companies employ this technique because the hardware is rare, and providing a quality firewall at 10GbE & 40GbE speeds if often believed to be expensive. Today only two companies offer this capability in their 10/40GbE server network adapters in the form of a packet filtering engine, and Solarflare is the leader.  Both take a slightly different approach to solving the problem, but the ultimate objective is the same:  providing a server with the last line of defense. So how do these systems work?

Solarflare leverages specialized packet filtering circuits designed into their Ethernet Controller ASIC on their network server adapter. They then crafted a complete distributed solution called SolarSecure that leverages both their ASIC & their user space driver. Through examples, we’re now going to take a brief tour of what Solarflare offers with SolarSecure, and how it can be used to protect your servers.

SolarSecure relies on a pseudo-microcode to define filters and load them into the distributed solution, some filtering is done in the network adapter while other filtering is handled in the user space driver. To learn how SolarsSecure works we’ll explore the following three areas: rate limiting, white/black listing, and SYN cookie support.  There are a number of other interesting options on which one can filter, but these are the most commonly requested, for more examples you’re welcome to check out chapter 7 of the User’s Guide.

Here is a complete example of a configuration file for rate limiting written using this pseudo-microcode, the User’s Guide explains each line of this program, its shown here though to provide a complete example:

set_max_channels 4
set_default_action accept
set_max_objects 30
set_max_minaddrs 30

start_code
accept:
load 1 r0
stop
reject:
load 0 r0
stop
start_rate_limit:
inline_state p1 rate_limit –
test_rate_le p1 0 10pkts 10ms
jmp_if_not reject
jmp accept
end_code

That the majority of the magic for this configuration file happens in this single line:

test_rate_le p1 0 10pkts 10ms

In this example every sender “p1” is limited to transmitting up to 1000 packets/second, anything over that in any given second will be dropped.  To be exact this really means 10 pkts ever 1/100th of a second. This will dramatically reduce the impact of unknown bad actors on your infrastructure.

For white or black lists you can simply define a lookup table with the following structure, note this is a line from a typical black list:

ip4tbl_insert badnets172.16.128.0/21 reject

Then when this line of pseudo-code is executed:

lookup bad_nets pkey

If the inbound IP address and port “pkey” matches any entry in the “bad_nets” table, say 172.16.128.0/21 the packet will be dropped.

If you’re only white listing a port on the server you might use:

ip4tbl_insert ourservers 10.1.1.200/22 accept

In the report mentioned above, over 25% of the attacks that occur are SYN based.  To thwart this you can define a configuration file that will easily drop attackers using this attack vector.  Here are several lines of pseudo-code that demonstrate this point:

load_tcp_flags r2
test_mask_match r2 syn syn
jmp_if_not accept
jmp reject

Note that “test_mask_match” is used to see if the “syn” flag is set for this packet, and if it is, then register “r1” is set to true. Then the conditional “jmp_if_not” uses register “r1” to make the jump.

The SolarSecure filter engine is extremely powerful, and these samples just scratch the surface of what it is capable of. If you find this really interesting you should seriously consider looking reading the User’s Guide.

If you’re interested in taking SolarSecure out for a test drive, or just want to learn more feel free to contact me, or reach out directly to Solarflare.