An alchemists view from the bar

Network Security Alchemy

Posts Tagged ‘IPS

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 (http://gamelinux.org), 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, http://www.openfpc.org.  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 www.openfpc.org 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.

-Leon

Advertisements

Written by leonward

August 2, 2010 at 9:53 pm

Posted in OpenFPC, Security

Tagged with , , , , , , ,

Planing for infosecurity 2010 (London) – VRT Workshop

leave a comment »

It’s that time of year again. Infosecurity Europe is upon us. If you’re going to be there and have a strong interest in the inner-works of intrusion prevention engines, have I got a treat for you lucky lucky people 🙂

Sourceifre’s own Lurene Grenier (@pusscat) and Matthew Olney (@kpyke) are running a workshop!

Here’s the official blurb

Sourcefire VRT Workshop
Register here
– 11:00 – 12:00, Wednesday 28th April 2010 –  Mayfair Room, Earls Court.
The VRT team will demonstrate the power and flexibility of the engine by unveiling a new multi-faceted, scalable detection methodology targeted at addressing the most difficult detection problems facing security professionals today.

So if that gets your interest going, make sure you register here.

As a bonus for you all, Sourcefire are also running an “Intelligent Network Security” Workshop.

Sourcefire Intelligent Network Security Workshop
Register here | 15:00 – 16:00am, Wednesday 28th April 2010 | Mayfair Room, Earls Court
In the age of the advanced persistent threat of cloud computing and of new economic realities, how can companies ensure their networks are monitored and protected securely and cost-effectively? Find out how Sourcefire, the leader in context-aware Intrusion Prevention Systems has addressed the limitations of current generation IPS to provide true intelligent network security solutions.

And I’ll be stuck on the Sourcefire stand for most of the three days, pop buy if you want to say “oh hai”.

-Leon

Written by leonward

April 1, 2010 at 9:13 am

Posted in Sourcefire

Tagged with , ,

ET RBN Blacklists with Snort and DumbPig

leave a comment »

I spent a few minutes updating DumbPig to work with Marty’s latest blacklist patch, with some great results. It looks like Marty has done a great job in keeping packet performance high while providing a rich blacklist configuration. DumbPig for the as yet unenlightened, processes Snort rulesets and offers advice when a “dumb” rule is detected. Blacklist snort rules are a good example if dumbness so I thought I would focus in a bit on why and how to use these tools.

Before digging into the tech, let me tease you with some performance numbers. My test below was basic, but should provide some relation to the real world.

Test 1) Stock snort.conf and VRT subscription release (processing approx 1.2GB of pcap files)

$ snort –pcap-dir /var/local/pcaps/defcon-2004/ -A fast -l /tmp -c /etc/snort/snort.conf

Run time for packet processing was 46.994580 seconds
Snort processed 2752654 packets.

Test 2) Stock snort.conf, with the “emerging-rbn.rules” (20/july/2009) added

$ snort –pcap-dir /var/local/pcaps/defcon-2004/ -A fast -l /tmp -c /etc/snort/snort.conf

Run time for packet processing was 89.749301 seconds
Snort processed 2752654 packets.

Test 3) Stock snort.conf, but using a DumbPig created blacklist file from the same “emerging-rbn.rules”

$ snort –pcap-dir /var/local/pcaps/defcon-2004/ -A fast -l /tmp -c /etc/snort/snort.conf

Run time for packet processing was 48.348535 seconds
Snort processed 2752654 packets.

So that’s a whopper of a performance increase while maintaining the same IP based detection ability. I don’t claim you will see the same performance in the wild, but an increase like this should get your attention. Feel free to re-create the tests on your own network and let me know the results (for my interst only).

Configuring Snort 2.6.4.1 with the Blacklist patch (v2)

I have seen a few posts on the internet where people have run into issues configuring and using the blacklist patch. Below are the steps I took to build a system in prep for this weeks Snort Users webinar on DumbPig and other tools so I thought I would share the configuration here.

Starting platform: Debain Lenny – base installation + ssh and sudo (with lward in the sudoers)

1) Install the debs we know will be needed for the compile of Snort

lward@webexprep:~$ sudo apt-get install libpcap0.8 libpcap0.8-dev libdumbnet-dev build-essential libpcre3-dev automake autoconf libtool

2) Download and extract the snort 2.8.4.1 source

lward@webexprep:~$ wget http://dl.snort.org/snort-current/snort-2.8.4.1.tar.gz
lward@webexprep:~$ tar -zxvf ./snort-2.8.4.1.tar.gz

3) Download and extract the Blacklist patch

lward@webexprep:~$ cd snort-2.8.4.1/
lward@webexprep:~/snort-2.8.4.1$ wget http://www.snort.org/users/roesch/code/iplist.patch.v2.tgz
lward@webexprep:~/snort-2.8.4.1$ tar -zxvf ./iplist.patch.v2.tgz

4) Read the README.iplist

5) Pactch your Snort source tree

lward@webexprep:~/snort-2.8.4.1$ patch -p1 < iplist.patch

6) Rerun aclocal / automake/ autoconf

lward@webexprep:~/snort-2.8.4.1$ aclocal -I m4
lward@webexprep:~/snort-2.8.4.1$ automake
lward@webexprep:~/snort-2.8.4.1$ autoconf

7) Configure Snort (and enable IP listing).

lward@webexprep:~/snort-2.8.4.1$ ./configure –enable-iplist

(note there should be no errors , if you have m4 prelude messages, see the comment at the bottem of this post).

8) Compile  / install

Debain / Ubuntu users: You will have to “fix” the dnet/dumbnet fsckup created by the decnet libraries poluting the debian package namespace. A simple symlink will suffice.

lward@webexprep:~/snort-2.8.4.1$ sudo ln -s /usr/include/dumbnet.h /usr/include/dnet.h
lward@webexprep:~/snort-2.8.4.1$ make
lward@webexprep:~/snort-2.8.4.1$ sudo make install

9) Set up your snort configuration.

lward@webexprep:~/snort-2.8.4.1$ sudo mkdir /etc/snort
lward@webexprep:~/snort-2.8.4.1$ sudo chown lward /etc/snort/
lward@webexprep:~/snort-2.8.4.1$ cp etc/* /etc/snort/
lward@webexprep:~/snort-2.8.4.1$ vi /etc/snort/snort.conf

(Change your RULE_PATH to /etc/snort/rules)

10) Grab the VRT snort ruleset from snort.org, and stuck it in your home directory. This exact process will depend on your subscription level.

11) Set up the VRT snort rules

lward@webexprep:~/snort-2.8.4.1$ cd
lward@webexprep:~$ pwd
/home/lward
lward@webexprep:~$ ls
snort-2.8.4.1  snort-2.8.4.1.tar.gz  snortrules-snapshot-2.8.tar.gz
lward@webexprep:~$ tar -zxf ./snortrules-snapshot-2.8.tar.gz
lward@webexprep:~$ cp -r rules/ /etc/snort/

12) Grab yourself a pcap to test and play with

lward@webexprep:~$ wget http://rm-rf.co.uk/downloads/Honeynet-RFP-iis.tgz
lward@webexprep:~$ tar -zxvf ./Honeynet-RFP-iis.tgz

13) Test snort

lward@webexprep:~$ snort -c /etc/snort/snort.conf -A fast -l /tmp -r ~/Honeynet-RFP-iis.pcap

14) Enable, and test the blacklist functions

lward@webexprep:~$ echo preprocessor iplist: blacklist TestBlacklist /etc/snort/rules/test.blacklist >> /etc/snort/snort.conf
lward@webexprep:~$ echo 172.16.0.0/16 > /etc/snort/rules/test.blacklist
lward@webexprep:~/snort-2.8.4.1$ snort -c /etc/snort/snort.conf -A fast -l /tmp -r ~/Honeynet-RFP-iis.pcap

<Check that your are getting blacklist events in your /tmp/alert file. Make sure you add a CIDR that exists in your pcap test data!>

15) Install dumbpig

Install required perl modules from CPAN

lward@webexprep:~$ sudo cpan -e “Parse::Snort”
lward@webexprep:~$ sudo cpan -e “LWP::Simple”
lward@webexprep:~$ wget http://rm-rf.co.uk/downloads/dumbpig
lward@webexprep:~$ chmod +x ./dumbpig

16) Grab the latest Emerging threats RBN list

lward@webexprep:~$ wget http://www.emergingthreats.net/rules/emerging-rbn.rules

17) Convert the rule file into a blacklist

lward@webexprep:~$ ./dumbpig -q -r emerging-rbn.rules -b /etc/snort/rules/rbn.blacklist

DumbPig will detect rules that will work best in a blacklist, and add them to the file “rbn.blacklist”. For more usage inforamtion, take a look at the dumbpig page.

lward@webexprep:~$ head -n 5 /etc/snort/rules/rbn.blacklist
# Autogenerated blacklist by DumbPig from emerging-rbn.rules
# Contact leon.ward@sourcefire.com
# For more information about dumbPig visit http://rm-rf.co.uk
114.80.67.30/32 114.80.67.32/32 <snip>    # From Sid 2406000 : “ET RBN Known Russian Business Network IP TCP (1)” : emerging-rbn.rules
114.80.67.30/32 114.80.67.32/32 <snip>    # From Sid 2406001 : “ET RBN Known Russian Business Network IP UDP (1)” : emerging-rbn.rules

18) Reconfigure your snort.conf to the the rbn.blacklist

Something like this should work for you” “preprocessor iplist: blacklist RBN_Hosts /etc/snort/rules/rbn.blacklist”

And that’s it, the rest is up to you to use/abuse as you need.

Troubleshooting

Troubleshooting build problems. If you are having fun with one of the below, start with a clean source tree, re-patch, and follow step 6 (note the aclocal command).

undefined reference to `SetupIpList'
configure.in:1050: warning: macro `AM_PATH_LIBPRELUDE' not found in library

Happy Snorting - Leon

Written by leonward

July 20, 2009 at 12:06 pm

Posted in Security, snort

Tagged with ,

TweetYard – Sourcefire and Snort alerts to Twitter

with 4 comments

Update: – You can download tweetyard here.

There has been some of discussion of late on the snort-* lists of late regarding Unified alerting vs direct DB access.

I stopped storing events in a DB years back when I stopped using ACID (and yes that was back-in-the-day before BASE came into being). My personal Snort requirements are pretty simple and fast output has always worked well for me linked with a load of swatch-foo and custom perl scripts. After hanging my head in shame for not converting to unified yet (cobblers children clearly have no shoes over here) I thought it would be wise to put some effort in.

I used to receive all of my Snort IDS events via email, but email is *so* web 1.0. So I thought I would hook into Twitter for real-time alerting 🙂

So far, so good, and it only took about an hour to build. Kudos to Jason Brvenik for his snort-unified.pm and sample barnyard replacement, it was a good base for what I wanted to hack together. Because I put this together more than fun more than anything else, feel free to follow a censored Twitter feed of my IPS events (If you didn’t have enough to deal with already).  I have blanked the IPs of my protected systems in an attempt to raise the smarts-to-abuse bar up 0.2 inches above short skiddie tall.

I will upload the code when I get a spare couple of minutes, but as I will be attached to the Sourcefire booth @ Infosecurity London for the next three days it may take a while. Hooking it into Sourcefire’s Estreamer is also on the cards the next time I get some down-time.

If anyone is at the show, feel free to drop by the Sourcefire booth and say hi (and to bring me a Coffee at the same time).

-Leon

Written by leonward

April 27, 2009 at 6:35 pm

Posted in Security, snort, Sourcefire, Uncategorized

Tagged with , , ,

Snort and VoIP – Thoughts on IPS in a modern voice network

leave a comment »

I have been putting some thought into the subject of voice over IP (VoIP) and the fact it presents a particularly interesting security challenge. Communication line convergence was one of the big pushes in the early 2000’s due to the cost savings it advertised, this unification of network and voice communications also seeded the uptake of then emerging VoIP technologies into enterprise networks. Many years on VoIP is now widely accepted as a technology mature enough to be provided to a wider consumer market but still lacks some of the security features expected in a mature system.

The reason I find this security challenge interesting is that it brings together two distinct threat and concern types; one of voice communication services and one of IP networks. Those implementing or maintaining a VoIP network are commonly from one of these two backgrounds, and therefore may initially see only half of a security objective.

Stock IP threats

These are the concerns that are picked up by the regular IP networking person and probably the threats that they think about daily. For example;

  • Remote Code Execution
  • Denial of Service
  • Traffic interception

Because the Voice platform is now on an IP connected and integrated network, all of these now also exist in your voice infrastructure. In fact, all of these concerns existed before, however inward connections were far more limited than on your nice new VoIP system and attacks were less likely.

Voice specific threats

Those who maintain large non-IP voice networks have similar problems keeping them awake at night. Commonly these concerns fall into one of the following categories:

  • Service theft (toll fraud)
  • Evesdroping (wiretapping)
  • Service Disruption / Outage (read Denial of Service)

The most common VoIP signalling protocol I see in use  SiP, and it is pretty simple to understand from an observers point of view. This means that it IP based security threat monitoring tools could be converted to the voice world, IDS/IPS on VoIP networks could offer discovery and mitigation of both traditional IP network threats along with the voice specific. I recommend that those maintaining a VoIP infrastructure take a look at a modern IDS system to determine  if it can help them discover and protect against many of the threats that concern them.

Snort obvoiusly has a bucket of rules specific to voice networks put together by the Sourcefire VRT, and there are also additional offerings from the Bleeding Threats.

Written by leonward

August 27, 2008 at 12:07 pm

Posted in Security

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 ,

Leon’s tips for Ips event classification and analysis

leave a comment »

… and more tuning ideas

So here I am, stuck in another hotel bar, this time at the dark-end of Cornwall, sipping (carefully I may add) at the local tipple (Skinners Press gang cider). I have been taking some time to sift through snort forum postings and following the discovery of the normal “what the hell do I do about this alarm” calls for help, I thought I would take time-out to compile a list of top-tips to  better deal with intrusion alarms.

We all know the situation, you are being alerted to new “stuff” happening on the network, you don’t recognize the alarm as obviously bad, or even obviously dismissible and are desperately trying to work out how much, or even if you should be concerned.

There are certain things you can do to enhance the process of dealing with and understanding new alarms you haven’t any experience in, and due to the shifting threat spectrum (/me slaps self around the face for extreme buzzword abuse, and to mitigate the effect of the cider) new alarms arrive all the time.

Without wanting to write a book on incident analysis, ill split this over a couple of blog postings as some of this advice is conceptual and some introduces methods of approaching the problem, and other tips are tool specific.

First, the bleeding obvious (if you don’t do this already, pick up your security hat and coat and head for the door).

Understand the alarm.

This is such an important point that I must state it even though it sounds obvious. What does the event message really represent? Be sure to read all documentation associated with the alarm. If your IDS is Snort, and used the VRT rules, you have luck on your side as Nigel does a good job of writing and keeping rule documentation current. It is essential that you understand what the writer of the rule wanted to bring to your attention. Your reaction should vary depending on what has occurred, and one hopes that they would have attached a realistic event message. If you consider a regular server-side attack, all of the following may be raised in separate alarms associated with a single flow.

Access, or discovery of a potentially vulnerable system on the protected network
Exploitation of a vulnerability
Discovery of a specific exploit
Malformed network packets
Successful attack response

One of the things that you should have in your favor (and unfortunately, or rather shockingly, this isn’t always the case with many commercial tools) is the ability to look at the detection “source”. This provides an undeniable method of knowing what was being searched for, and may yield more clues to the writers intent (if not already obvious).

Understand the source and target devices in the context of the alarm.
Is it an attack response coming from your network? or someone else’s? How this is evaluated is specific to the event.

Take a look at the packet(s) that raised the alarm for supporting evidence of suspicion.

Without access to the packet that triggered the event(s) you’re dead in the water here and you are flying blind. Was this alarm real or a “programming error” on behalf of the detection system. Take a look at the decoded packet, inspect it, check for the presence of supporting evidence that the alarm may be real. A NOOP sled or a shell call are trivial examples.

Understand the quality of the rule/signature that generated the event.
Check out how the rule was written, if your IDS doesn’t provide you with the detection source, you are dead in the water. Being able to justify WHY an event triggered a rule is imperative.

The slightly less than obvious … the “C” word.

Understand the alert in the context of the systems involved.
To qualify the potential impact of an “attack” against a target system we need to know what the target system is. In turns out that this can be a harder job than discovering the attack itself, evaluate the alarm against the Operating System, Services, and applications provided by the target.

Evaluate the event in the context of the organization.
What was the “application” being attacked. By application I refer the the purpose of the target system in the operation of the organization. IIS alone means nothing, what is being served over HTTP from this device, and how does it’s compromise effect the operation of the company.

Following the completion of this process TUNE! Can you automate this effort the next time this event is raised on …
This target
A group of targets
Your whole network

Written by leonward

May 2, 2008 at 6:01 pm

Posted in Security

Tagged with ,