daemonlogger, fpcgui, Information, OpenSourceSoftware, Security, Sguil, Snort

Full packet capture…

I was on a seminar today, where one of the key focus was full packet capture of network traffic.

It was rather strange to me, that it seem to be presented as something new, exiting and “must have”…

IDS/IPS without full packet capture – is time consuming if you try to investigate an incident. All analysts knows that, and there is nothing new about that. Richard Bejtlich has preached this for years ( Read Tao of Network Security Monitoring, Beyond Intrusion Detection ).

As a happy Sguil user, I always have full packet capture of my network traffic, and can drill down in all the network data from an event. Meaning that I save tons of time investigating events, and can better tune down my false positives also. Most commercial vendors don’t integrate any “full packet capture appliances”, and don’t even support 3rd parties packet capture services. In my earlier days, I brought this to among IBM and Juniper, where they just look strangely at me and replied more or less the same – “Full packet capture is just to much data to handle… you need big disk and lots of CPU/RAM… We are not sure how to integrate this…”

Well, there is a free and open source way to implement such a device. A standard Linux host with daemonlogger is one example. (There are other tools that also does packet capture, but daemonlogger really aim just at packet capture, and nothing more, and does it in a way that I want it.)

Now that you can get 67 terabyte of storage for about $7,800 USD, there should not be a problem storing your data 🙂

You can split up sguil to run different services on different hardware, so if you have a Network Tap that can mirror traffic to more than one devices, you can run IDS on one server, pcap on another, network statistics on a third and asset detection on a forth example vis. Basic overview of Sguil with all services running on one sensor:
If you want to, or need more juice from your snort sensor etc. you can split it up, so that one sensor takes the traffic from X most used services, and the other sensor take the rest. Or even split it up more!

Since I started using Sourcefire 3D system, I have planed to make a way for me to easily integrate my package capture server with the Defense Center. My thoughts are on using Firefox with Greasemonkey and some perl-cgi on the pcap server to carve out the the right portion of the pcaps. Capture has some nice ideas and I might reuse some code from there. If Sourcefire don’t beat me to it, I might have something of my own in a near future…

If you don’t capture packets today, you should look into a way of doing it. It saves you time, and it saves you lots of work. I would not be without mine 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s