Friday, January 28, 2011

Enterasys Dragon IDS

I've managed a Dragon IDS system for ten years now. When the company I worked for tasked me with researching and evaluating intrusion detection, some of the major players today didn't even exist yet, and snort had not yet been rolled into the commercial Sourcefire product.We looked at a number of the available offerings back then and settled on Dragon.
At the time, Dragon was winning IDS "bake-offs" and garnering a number of awards, and it seemed to be a decent choice. We did all of our own testing; there were no monies for calling in a security consultant to evaluate our needs and pair us with a product.

Dragon was written by Ron Gula, who is now the CTO of Tenable Network Security. Ron had just sold Dragon to Enterasy, which made some of the early support calls interesting.
But some of Ron's staff had gone with him to Enterasys (like Rick Olesek) and were excellent folks to deal with and very knowledgeable. We started out with Dragon 5, which by today's standards, had a rather primitive management interface. Changes were made by editing the various configuration files directly, either through the browser or using vi on the server itself (I actually missed that, once the interface became sophisticated enough to not require it anymore. Gave you a degree of confidence the changes you were making were actually getting made).

Over the last ten years, I've maintained a love/hate relationship with the Dragon (the original version we used called the HIDS component a "Squire" and the tools were in the sorcery directory. The product was originally named "Dragon Fire IDS). It's fairly easy to maintain, signatures are released for new vulnerabilities in a timely manner, the reporting is easy to set up and filter, and the newest interface has a really nice looking console that is easy to drill down into.

I also remember, however, the early versions of version 7, when I spent days on end on the phone with their developers, with them remoted into my desktop as they tried to fix issue after issue. I remarked more than once that I didn't remember signing on to be a beta tester, but I evidently was one anyway. Fortunately, as of version 7.4.1, all of the bugs have seemingly scurried back into the darkness, and the systems are running without intervention again. Which allows the intrusion analyst to spend his time actually investigating alerts, as well as tuning and filtering. What a concept.

Enterasys was merged with the Siemens Group in 2008.

Friday, January 14, 2011

Practicing Packet Analysis

Here's one way to get started quickly practicing packet analysis, using nothing but open source, free tools.

You'll need a Linux box with sufficient drive space to store your capture packets and a monitoring interface patched to the network you wish to capture from (use your own network, or make sure you have permission to monitor the network you'll be using).

Packet Capturing

You can several different tools to produce packet captures.

1. First is Daemonlogger, written by Marty Roesch of Snort fame. Daemonlogger can write packets to disk (what we want here) or act as a software tap, rewriting the packets it captures to a second interface.

2. If you have Wireshark installed, you can use the command line utility tshark to sniff. tshark, like Wireshark, is a network  analyzer that can display tons of information on the packets it receives, not what you want here.  The options are many, and if you're just starting out, tshark may not be the best choice. Make sure you use quiet mode so the capture isn't displayed to the screen (you'll drop packets as that slows things down considerably) and set the snaplength (the size of the capture) to 0 or 65535. If you're going to analyze packets, you need full packet captures unless you're just doing statistical analysis/trending. -x will capture the hex and ascii data.

3. If the box already has snort installed, you can simply run snort in packet logging mode. After all, that was the whole reason Marty wrote snort in the first place. He didn't like the sniffers that were available at the time, so he wrote his own. It developed into an IDS later.

4. IDABench. IDABench is a now defunct packet auditing tool written by George Bakos. Even though development ended on it several years ago, it's still a wonderful tool that I use daily. Apart from the Perl framework that runs various tools and creates web pages of summaries, the first thing IDABench does is simply run tcpdump and create packet captures, one for each hour of the day. For what we're doing here, its overkill just to get dumps, so unless you want to use the toolbox IDABench provides you, that leads us to number 5.

5. Just use tcpdump itself. There is a parameter (-C) you can pass that tells tcpdump to roll over according to the size of the capture. Whatever you pass to -w (write to file) will be used along with a number as the filename (if you use “-w capture”, you'll end up capture1, capture2, and so forth).

Analysis Tools

Obviously, there are many, many tools available to analyze packets. I'm just going to mention a few that I use or have used in the past here to allow you to drill down into the packets and inspect either the header fields or payload, or both. Once you have a (libpcap compatible) packet capture, you can use any or all of these tools to start digging.


1. Wireshark. Wireshark is the most complete network analysis tool that I know of, at least of the free tools, and has dissectors, or decoders, for literally thousands of protocols. Open your packet capture in Wireshark and you can drill down to any level in the protocol fields, examine the payload, follow a TCP stream, save off reassembled files that are contained in it (including VOIP traffic that can be saved as a .wav file and replayed). It’s an excellent tool. It may also be yet another case of overkill, though, depending on what you're looking for. If all you want to do is extract any login authentication pairs found in the packet stream, for example, it may not be the tool to use.

2. dsniff suite. dsniff, however, IS the tool to find clear text logins. There are also tools that will capture email traffic (mailsnarf), older versions of instant messaging (msgsnarf), extract URL's (urlsnarf), files (filesnarf), and even surf along with a user in the stream using webspy, which will redirect any URL's it finds to your web browser (more fun than functional).

3. ngrep is a command line program that will search for content in a packet stream or capture, much the way that grep does text files. It supports regex and is a powerful way to quickly find strings in packet captures.

4. Netwitness Investigator. Investigator is a Windows GUI that performs "free form contextual analysis" of your packets. Install the software, create a new collection, import your pcap file into it and load it. You'll be presented with a visual screen of things like alerts, hostnames, user accounts, ports, protocols, even countries of origin, that have categorized info below them you can drill down to find the exact information you need, and finally look at the raw packet capture of. A very nice tool to experiment with.
You can capture new traffic on the box it's installed on , as long as WinPcap is installed, which is very handy to get up and practicing quickly.

5. chaosreader - chaosreader is a big perl script that takes your packet capture and parses it down to TCP/UDP sessions and application data. It will pull telnet and ftp sessions, HTTP, email. etc. and index it all in html files that you can feed to your web server, or open directly into your browser. Be warned, though, that parsing of large files will take a long time and use up all of your available resources on your machine. It's better to use smaller packet captures, or use filters to pull traffic of interest out and write it to a separate dump file and then feed that to chaosreader.

6. snort. Snort can be run in stand-alone mode, which means you can feed it a packet capture as a parameter and run the traffic through all of snorts pre-processers and signature libraries. You might want to do this to get a second opinion on events captured by another IDS or to find alerts to drill down to practice your analytical skills. Or if you're doing network forensics for someone else, you may only have access to the raw packet capture and need to regenerate the alerts for your use.

7. xtractr - xtractr is a tool provided by MuDynamics that takes a packet capture, indexes it and writes it out to an html file. The free version has a limit of 10 million packets or 1Gb of pcaps. That’s plenty enough to practice your analytical skills.

Packet Capture Tools
1. Daemonlogger
2. Wireshark
3. Snort
4. IDABench Sorry, links are no longer active. I have the install files if interested.
5. tcpdump

Analysis Tools:

1. Wireshark 
2. dsniff
3. ngrep
4. NetWitness Investigator
5. chaosreader 
6. Snort
7. xtractr

Monday, January 10, 2011

SANS Google Cheat Sheet

Yet another cheat sheet for those who want to power user Google.. but this one's from SANS and is from a defense of Goggle as a hacking tool perspective (to check your own site and see what data is bleeding out unintentionally).  This sheet will also help those who just want to get tight and relevant results and aren't familiar with some of the operators Google offers. (Note: the phonebook, rphonebook and bphonebook operators have been retired.)

Blog Archive