Java Authors: Andreas Grabner, Liz McMillan, Tim Hinds, Elizabeth White, Cloud Ventures

Related Topics: Open Source, Java, SOA & WOA, Virtualization, Cloud Expo, Security

Open Source: Blog Feed Post

Creating a Self-Defending Network Using Open Source Software

You’ve got a firewall and a DMZ, you’re all set, right?

By: Steve McMaster

This past weekend, I presented the idea of a self-defending network at Ohio LinuxFest 2012. The accompanying slides are now available here. So let’s talk about network security. You’ve got a firewall and a DMZ, you’re all set, right? Not so fast slugger. We preach a theory called “defense in depth” here at Hurricane Labs. And that means you need something to defend you when your firewall admins make a mistake. And something to protect you when that layer fails. And so on. So what are these other layers? Well one of them is having a good IDS/IPS system. An IDS/IPS listens to network traffic, generally the traffic inside your firewall, and either alerts on (IDS) or drops/blocks altogether (IPS) traffic that meets specific rules defining “bad traffic”. But what else can you do?

A coworker and I put a couple pieces of open source software (OSSEC and Snort) together to respond to certain types of automated attacks we were seeing in our IDS (we use Snort in this case). Prior to this, an engineer would manually respond to alerts by logging into our firewall and blocking the IP address causing the alert. This process was tedious, repetitive, and time consuming. By the time the firewall change would be pushed, generally the scan (it was usually a scan) was over and the attacker had moved on. So we took advantage of a feature in OSSEC called “active response”, which is used to react to events on the network. OSSEC was configured to watch for Snort alerts, and would run a script on our Internet routers (running Vyatta core 6.3) to block the IP for 10 minutes. This response runs almost immediately. We hand selected alerts that we had associated with simple scans, such as FTP Brute Force attacks, and set them up to block the addresses. But this wasn’t enough for us.

We started to ponder what sorts of scans were happening that our firewall was dropping. For example SIP or SSH scans, which don’t ever pass through the firewall, that were at best sucking up bandwidth and at worst causing problems if our firewall rules ever let something slip. Granted, those sorts of slips are uncommon, but mistakes are always possible and it’s best to plan for every type of failure.

Coincidentally, we also wanted to test a new IDS on the market called Suricata. Suricata was designed from the ground up to be an “open source next generation intrusion detection and prevention engine”, and we wanted to run it through its paces (which is a different article entirely). So, we configured a server running Suricata, but this one was configured to watch traffic on a SPAN session watching traffic outside the firewall. What we found in preliminary testing was that we saw a few types of scans on a regular basis – NMAP ping scans, SSH brute force scans, and SIP scans. So, similarly to what we did with FTP brute forcing (which for multiple reasons is better detected on the sensor inside the network) we configured OSSEC to watch logs from Suricata (which was relatively simple, as it logs in a format compatible with Snort alerts anyways). Poof! A network that defends itself.

What we’ve done is similar in premise to the Team Cymru Darknet Project. According to their website, a darknet is “a portion of routed, allocated IP space in which no active services or servers reside.” It is then assumed that any packets entering the network are unsolicited and more than likely undesirable. This can be used to reliably build a list of known malicious hosts. Unlike a true darknet, we’re using IP space that hosts active services, however we’ve tuned our monitoring to look specifically for traffic we know, by design, not to expect. This allows us to gain many of the benefits of a darknet without the resource investment required.

The advantage of this method is that we can run the “active response” on multiple targets. So, for example, we run two Internet-facing routers on our colocated data center network, and another on the edge of our office network. By detecting scans on both networks, the other network is automatically protected as well. This could be propagated to several other mechanisms as well. It could be used to build a dynamic BGP feed, or DNS blacklist, of hosts that are known to be scanning the Internet maliciously.

I’ve attached a few snippets to this article to help get you started on the path to building a self-defending network. These include configuration examples and rule signatures for OSSEC, Snort and Suricata.

Read the original blog entry...

More Stories By Hurricane Labs

Christina O’Neill has been working in the information security field for 3 years. She is a board member for the Northern Ohio InfraGard Members Alliance and a committee member for the Information Security Summit, a conference held once a year for information security and physical security professionals.