Earlier this year Solarflare released a software driver for their line of Flareon adapters called SolarSecure. SolarSecure is a stateless packet filtering engine with a rich set of features that maps almost perfectly into what Wikipedia has defined as a first generation packet filtering firewall. This is meant to separate it from the more common second generation state-full firewall & third generation application level firewalls that have become the more commonly accepted definition of a firewall today.

Earlier this morning someone asked me how SolarSecure might help a huge cloud service provider, say one embroiled in a celebrity scandal.  To fully leverage SolarSecure to make production Internet servers more secure there are at least five potential use cases, and they are:

1. SolarSecure could be used to augment existing firewalls by providing a high bandwidth front end method for rate limiting inbound traffic from chatty address, ex. no more than 10 packets in 10 milliseconds from any specific source (anything over that will be dropped) while also filtering by TCP address. Here is a sample configuration file that one could use to do just this.

2. On all Internet facing interfaces, one should also check the TCP flags to thwart a SYN flood attack. SYN floods make up just over 30% of the attack traffic every day. Another configuration example can be found here that addresses this use case.

3. Also for all Internet facing ethernet interfaces, one should use SolarSecure in conjunction with Norse’s Darklist, or a similar provider, to do blacklist filtering to ensure that known bad actors on the Internet can’t impact my systems at all by dropping their traffic immediately. Again here is some code demonstrating IP address filtering.

4. As a method within the DMZ to tightly control what every server port can be used for.  For example, Internet facing ports should only pass traffic for permitted UDP/TCP ports that are specific to the service that system offers, if it is a web server then white list the system to deny (drop all traffic) on that port that is NOT port 80.  Also for backend service interfaces on that same system white list both the addresses & ports permitted on each & every ethernet interface to ensure that sideways attacks from other DMZ systems that might have been compromised is locked out. Here is an example of how to drop SSH requests to an interface.

5. Finally, HTTP request filtering. Looking at the actual requests coming into the server & only accepting ones that meet the objectives of the server itself.  Hackers will attempt to get in via the web server interface, if SolarSecure is only passing the web server specific types of pre-approved requests then the web server is much less exposed. One final example is here.

If you have any additional questions or comments, don’t hesitate to reach out to me.