An alchemists view from the bar

Network Security Alchemy

Posts Tagged ‘IDS

Big OpenFPC release – 0.6

with 2 comments

Pushing forwards closer to a 1.0 release for OpenFPC, one of the major components has now been updated – The GUI.

To introduce this new release I’ve put together a short screen-cast of OpenFPC to show the installation, setup procedure, and a bit of general usage. So if you’re tasked with rolling together your own full packet capture/network traffic recorder/forensics system, perhaps you may want to take a look below.


For those who don’t want to sit through five minutes of video to see what the new GUI looks like, here are a few screenshots of the system in action.

Version 0.6 is now available at . Expect a few bugs, and if you report them, Ill own the task of fixing them.


Written by leonward

June 13, 2011 at 12:37 pm

Posted in OpenFPC, Security, snort, Uncategorized

Tagged with , , ,

OpenFPC – An update: v0.2.97 available (woohoo!)

with 4 comments

It’s been a couple of months since I first posted about the OpenFPC project, so I thought it’s time that I provided a little update.

Firstly, I need to throw some karma over to Edward Fjellskål (, so… Edward++.

Edward and I have merged the OpenFPC and FPCGUI projects, it makes way more sense to combine our efforts as our goals are similar while our approaches have been from different angles. We both see a need to unify all of the home-brew full-packet-capture/network forensics tools we see out there in the wild.

OpenFPC now has a new home,  So, if you’re looking for a distributed wrapper for your daemonlogger instances, or if you’re still trying to get tcpdump to log in a ringbuffer and share access over multiple analysts, devices, and tools, head on over to to read all about it. Here are a couple of quick links for those who want to jump right in:

I’m looking for people to help test and provide feedback now so I can fix problems and tweak things ahead of a full release.

Good luck, and please let me know your feedback.


Written by leonward

August 2, 2010 at 9:53 pm

Posted in OpenFPC, Security

Tagged with , , , , , , ,

Geographic Representation of Intrusion Events

with 4 comments

Snort events and Google Earth Mashup. They say a picture is worth a thousand words, so I guess the below is all I need to show to explain.

SQL Worms represented in Google EarthSQL Worms represented in Google Earth

Firstly, karma goes to James Tucker for hacking together an early PoC.

I looked into hooking Google Earth into Sourcefire’s Defense Center about a year ago, but ran into issues with finding a good *free* geolocation perl module that I could use.  After a chat with Jim a few weeks back, he pointed me to Maxmind and provided a quick sample of plotting a Snorty pig.

I jumped right into making the integration glue for Sourcefire’s real-time event feed (EStreamer), making it plot the location of your current attacker as the events flood in.

The Good: It worked!

The Bad: It made dizzy!

The world would spin way too fast to keep up with all the nasty stuff out there.  I finally decided on a more mature approach of parsing either a snort alert file, or a Sourcefire CSV report.  This way the user gets more control of  the data being rendered.

To see a real example, download and take a look at the below KML file (open in Google Earth). I re-enabled SQL worm detection in my snort config on a publicly accessible device to find out what country is being the slowest to patch.  It provided an immediately interesting trend. Well done Europe and America for patching against a 8 year old problem,  shame on the rest of you!  Open the attached KML file in Google Earth to inspect in detail on your own local system.

Download SQL Worm KML file

Because Sourcefire 3D uses a advanced method of alert prioritization (impact flags), when used with a Sourcefire report you get an output like the below.

Impact Flag based events

Impact Flag based events

Update: The code can be downloaded from Jason’s blog on, it’s simple to use and get working, up but Ill knock up some instructions when I get a moment.


Written by leonward

March 15, 2009 at 11:37 am

Posted in Security, Sourcefire

Tagged with , ,

Defining achievable IDS/IPS deployment goals

leave a comment »

A network intrusion detection (and prevention) system is a flexible tool that can be used in many different ways. Let’s outline some of the most common deployment types I see in use today on *real* networks, and look them in no particular order. The reason for looking at these deployment type is to encourage more common compartmentalization (or segmentation) of monitoring tasks.

Firstly let’s don’t not forget that I[DP]S is all about access controls, which controls are implemented are your choice.

a) Tactical threat suppression
b) Business link risk mitigation
c) Security event detection
d) Network audit controls

Tactical threat suppression (Provides a preventative access control)
This is normally seen as the deployment of IPS at key access gateways of a protected network, the policy deployed is set to prevent specific malicious traffic flows from gaining entry. This design meets the “virtual patch” ideas to protect assets from key threats that concern the security team. Think “sploit de jour”.

Security event detection (Provides a detective access control)
Deployment of an IDS to detect network events that could impact the traditional security goals of the network (think network security 101 goals here (C, I & A)).
This is probably the most commonly planned IDS deployment from the out-set, it defines a system that is inspects network data flow, and when a security event occurs a team of analysts is there do their “job”. Following analysis, some form of incident response policy would be followed that should lead to the event being resolved. The main requirement for this type operation is a tuned IDS system to detect events that matter to the organization where something can be done in response to them.

Business link risk mitigation (Provides a preventative access control)
The use of an IPS can decrease the risk associated with a network link, therefore allowing the organization to potentially conduct business with higher risk 3rd party networks. The IPS policy acts as a traffic scrubber to prevent potentially harmful flows from entering the network from less-trusted parties.

Network event recording (Provides an audit control)
Deployment of an IDS that monitors the network for potential security events and supporting information. This is sometimes seen as a failed “Security Event Detection” deployment, where an IDS just logs event data but isn’t inspected by an analyst in anything close to real-time. A report may be run once in a while, but the data is stored for future reference should it be needed.
I see this is as a very valid deployment goal, and those who want “all rules enabled” generally fit into this category.

Problems can appear when designs attempt mix requirements between these achievable goals, for example:

Security event detection + Network event recording:

This combination leads to access and audit controls being enabled in the same policy. Those who are interested in audit requirements commonly want “all rules enabled” and therefore create an un-tunable policy that cannot hope to provide accurate security event detection (read bucket loads of F+).

The methods used to analyze, store, and work with event data may vary across the deployment goals. For example, if a user wants to place a device outside of a firewall to provide audit records, keeping event data in a live event analysis system may be overkill. Maybe a better solution would be an event feed to a SAN in a flat-file system. This would remove the burden to keep event data in an analysis database for real-time access.

Splitting an IDS/IPS deployment into logical chunks, each with specific requirements makes makes a far more manageable and valuable deployment as these goals can be segmented and managed on their own. When I get time I will put more effort into explaining my ideas around this, but in the short term I wanted to throw some ideas out there.

Written by leonward

July 8, 2008 at 6:12 pm

Posted in Security

Tagged with ,

The natural habitat of a network security appliance

leave a comment »

…Challenging the black art of tuning.

Living things have a natural habitat, an environment where they thrive because it provides all that’s needed for their survival. The evolution, and more importantly extinction of species has shown us that once the habitat of a creature changes substantially, it must either adapt to its new surroundings or it can quickly become extinct.

The natural habitat of a network security device, such as a firewall or an intrusion prevention system is the modern enterprise network. From the outside this habitat looks to be volatile and hazardous where only the strongest technologies survive.

When an organisation is seeks to adopt a new security technology, they commonly go through a process of product selection based on a key criteria, for example.

Does the product meet business goals assigned to the project
Cost of ownership & return on investment
How well does the product integrate with the operating environment
How will it perform its function on our network rather than someone else’s

Integration questions and tests are particularly important as no two enterprise networks resemble each other, however one point that commonly gets overlooked is that the modern network rarely resembles itself a few months further along the line. How well security technologies deal with this rapid rate of change can be linked to how successful their deployment will be a few months along the line.  Will the new device adapt as the environment changes? Alternatively, will it continue in a pointless attempt to enforce extinct policies that has no relevance to the state of the organisation as it is now.

When introduced to a new network, an Intrusion Prevention System needs to be configured for the environment, this is so the device can better understand the habitat it operates in and is therefore better equipped to detect or prevent intrusions. In the world of IPS this is known as the black art of tuning. A tuning process can be broken down into a couple of logical steps.
Deploying vulnerability based network attack detection or prevention capabilities for assets that require protection.
Mapping the organisations acceptable usage policy into the devices configuration.

Both of these steps provide their own challenges, for the initial configuration of a system and also it’s adaption as the network it protects evolves. Lets take a look at each one in turn and discuss methods that can employed to improve the accuracy of detection, speed of response, and adaption to the network as it and associated business goals change.

Vulnerability based attack detection and prevention.

IPS is commonly considered the current generation of network intrusion detection systems, the new kid on the block that has the ability to prevent the exploitation of network vulnerabilities or violations of acceptable use as well as alert to the presence of an attack. Deciding on what vulnerabilities the device needs to detect or protect from exploitation has traditionally been based on user input. It is assumed that the security or network team within an organization is aware of the assets and services offered by the network, and therefore in a position to decide what vulnerabilities the IPS should mitigate. Unfortunately I commonly find this assumption to be flawed.

Many organizations I speak to incorrectly believe that they have a unique problem. Not knowing what assets and services are operating on the network, and therefore not knowing what needs to be protected for which vulnerabilities. This is clearly not a unique issue as I run into it all the time, and the impact of this problem turns out to be high. Missed attacks or false alarms.

Here at Sourcefire we designed a technology back in 2003 that provides information to make this task much easier, we call it RNA – Real-time Network Awareness. RNA provides a map of what the protected network looks like right now, based on how assets and services behave or are accessed. This real-time network map provides good answers to key questions before and after security events occur.

Before an event.
What devices are currently on the protected network?
What services do these devices offer?
What vulnerabilities may exist on these systems?
What detection or prevention capabilities do I need to employ to best protect this network?

After an event.
Was the attack relevant to the device or service?
E.g. Would the target have been vulnerable to the attack. Was it an Apache attack against an IIS Webserver.
Following the attack, did the network or asset change in any way?  2E.g. Did a new service start, or a new client application communicate to the internet for the first time.

Having this real-time map of assets on the network allows us to quickly adapt to changes in the environment. For example, take the current running IPS policy, maybe one that is designed to protect public facing assets from known attacks and overlay it onto a map of what the network is right now. Are there any gaps in the defenses? Has a new service been deployed on the network without the security team being made aware of it?
Has the version of Apache been updated on our production systems? Therefore mitigating the risk of some attacks being successful.

This real-time, constantly adapting map of the network is the key component of enabling the IPS to evolve as its habitat changes. It prevents it from becoming a dinosaur and churning out useless extinct log data.

Monitoring and Enforcing an Acceptable Use

Detecting violations of the organizations acceptable usage policy at a network level is a commonly desired function of Intrusion Prevention. Although we instinctively think of Firewalls, IPS and other network access control devices preventing communications between specific computers and protocols, these communications most likely occur at the request of a user. A laptop for example is not intrinsically a malicious device as its functions are controlled by a user, so if an acceptable usage policy is violated through an instant messaging chat session, do we blame the device or the user?

Tracking down the sources of AUP violations can traditionally be tricky in dynamic environments, and as it happens these are the most common source of AUP violations. Large DHCP ranges are commonly associated with call centres or groups of office staff who will gladly whittle their work day away by abusing network resources. In these environments it can be hard to find something static to associate with an event to allow investigation. The IP address of the source has since changed, knowledge of the original MAC address has been lost due to the network topology, a user was “hot-desking”, the only static in this habitat is the person that violated policy.  This is why it is important to associate these types of events with the user of the system at the time of the violation.

This unique combination of user and network awareness providing an up-to-date map of who is accessing what on the network is invaluable when it comes to actually enhancing the security. Network information has its most value at the time of discovery, constant discovery means providing constant value.

Written by leonward

March 14, 2008 at 6:00 pm

Posted in Security

Tagged with , ,