Wednesday, October 12, 2011

IDS\IPS 101-6

Once your sensors are filtered and tuned, what you should have left are EOI's (events of interest), events that are either obviously malicious, suspicious, or enough of an anomaly to warrant investigation. How you investigate is dependent on a couple of factors. 1, What is your role? Or you strictly an intrusion analyst or do you do double duty as an incident responder as well? If  so, you'll need to go deeper in your analysis, possibly to the point of working directly on an affected server or desktop.
 But hopefully you're specialized as an intrusion analyst, and only touch alerts and the associated packets, and another team or person does the response and recovery.
Assuming that will be your role, what do you use to dig out the info you need to determine what happened?
Some IDS have a SIEM (security information event management) built in, like Enterasys' Dragon Defense, while others offer it as a separate, bolt on product (Symantec). Others are offered by SIEM-specific vendors such as Arcsight and LogRhythm. Log analysis tools like LogLogic and Splunk will also let you look at other data associated  with your alert.
But what if you work for a smaller company, and your IT security budget was just used  up with your IDS project? Fortunately there are lots of great open source tools you can implement to help you work through your alerts and determine what occurred (or didn't, as the case may more often be).
The first category of tools are the packet grabbers, the "packet auditing" tools. Your IDS will capture the packet or packets related to the alert, but not much else unless you specify it. Your IDS may not really be the place you want to collect more packets, as it's a busy box as it is. You can use another program on a separate host to do this for you, and do the analysis on that box as well, reducing the CPU cycles needed (it takes a while to decompress a 3 GB packet capture). I've mentioned many of these on this blog before, but I'll summarize them again here.
1. Daemonlogger (http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html) Written by Marty Roesch, author of snort, Daemonlogger will capture packets and write them out to a pcap file for you, or it can also act as a software-based tap, meaning it can capture on one interface and write back out to another. 
2. tcpdump - tcpdump has the ability to rotate pcap files based on size, doing the file naming for you, for x number of captures. Once you've reached the limit you specified, it will overwrite the oldest file with the newest. 
3. IDABench - based on SHADOW, IDABench is a perl based framework that captures packets into hourly pcap files, writes a summary of them out to a web page and allows you to search on multiple hours worth of captures using tcpdump, ethereal (yes it's old and outdated) and ngrep.Still a great tool. Contact me if you'd like a copy of it; it's no longer available anywhere on the Internet as far as I know.
Analysis Tools
1. Wireshark Wireshark (http://www.wireshark.org/) is one of the the most prolific protocol analyzers available. Wireshark supports hundreds of protocols and provides an interface that easily separates out the different headers to aid analysis, as well as allowing you to carve out content data.
2. Netwitness Investigator (http://netwitness.com/products-services/investigator) is a free form investigative tool that allows you to search and drill down into packets using contextual keywords instead of by header.
3. Network Miner (http://sourceforge.net/projects/networkminer/) Network Miner parses through pcap files or traffic on a network interface and identifies host names, operating systems, and open ports, as well as pulling out any files it identifies and filing them under directories for inspection.

No comments:

Blog Archive