Full Packet Capture and Analysis Solutions

[deanwebb]

Curious as to what anyone out there is using for full packet capture and analysis. I'm looking at FireEye + Gigamon, wondering who else is out there in that space that scales well to the enterprise.

[Otanx]

I have tried a few, and am partial to using a generic Linux host and tcpdump. Cheap and easy. Add in pf_ring once you get close to 10G if you need the performance. The problem becomes storage. Whatever you are using needs to be able to write as fast as you are capturing. So if you have an iSCSI array connected at 10G you obviously can't capture at 10G speeds. The way to handle that is have enough fast local storage for a few days, and then compress and offload older data to cheaper storage. A pcap will compress pretty well so you save a ton of space at the cost of easy searches.

Once you go over 10G then start expanding east/west. Build more capture boxes, and load balance them. Gigamon can do this easily. So at 40G you would have four capture boxes. Then throw a script in to query the data that accepts a tcpdump filter, logs into all four boxes, searches the captures, and returns the results. There are some downsides depending on what traffic patterns and use cases you have.

Gigamon is a solid choice for the tap aggregation side. Bring in everything, run it through their packet dedup engine and forward a copy to the capture box, and a copy to whatever other tools want it. While technically not full packet capture, but you can also use the Gigamon to filter out stuff you don't care about. For example, only keep the first 64 bytes of any TCP/443 or TCP/22 traffic. The traffic is going to be encrypted anyway, and by keeping the first 64 bytes you will still have all the sequence numbers so you can calculate how much data was transferred without having to store data you can't read anyway.

-Otanx

[deanwebb]

Looking at Gigamon for the capture and FireEye for the analysis and Splunk to store and index all the long-term metadata.

The requirement is to also do decryption, so that would be done on the FireEye side. Gigamon can just throw all the traffic at the FireEyes.

[Otanx]

I think I miss understood when you said full packet capture. I thought you were trying to just capture everything and save to disk. I think now that you mean to capture everything and supply monitoring tools to analyze the data, and generate alerts or other meta data about the traffic. That is a much easier problem in some ways.

Gigamon is still a good choice for the capture/aggregation side. You can still do a the dedup stuff, and they can also generate Netflow style meta data on the traffic it sees. Then feed whatever tools you want. The benefit of Gigamon is that you can duplicate the traffic to multiple tools so you don't need to have just one tool that can do everything. You can add tools to cover weak areas of your other tools. I have not looked at the Fireeye solutions recently so I can't really comment on them.

For the back end analysis Splunk is always a good choice if you can afford it. Their pricing can get a little crazy sometimes. However, a lot of people know Splunk, and customizing dashboards, and Splunk apps to do what you want shouldn't be hard assuming there isn't one in the Splunk Marketplace. It does require at least one full time engineer to keep up with even a medium sized deployment. It can take a lot of work to keep it operational.

For decryption you will need to be inline. These days doing out of band decryption does not work with current protocols. They way this is normally done is using some kind of ssl inspection device, and then forward the decrypted traffic to the Gigamon to feed the tools. Palo can do this pretty easily using the port mirror feature. I think both A10 and F5 can as well for inbound web stuff.

-Otanx

[deanwebb]

Looks like packet decryption would be the trickiest bit, as they have the link basically going from the Cisco core switch to the Juniper SRX perimeter firewall. So if the device needs to be inline, that sounds to me like they'd have to do an outage and then link up the redundant links to the inline devices and have them run from there. I'd imagine the Gigamon would be key for doing de-dupes of the decrypted traffic.

Although... Gigamon also offers a decryption solution... hmmm...

[Otanx]

Gigamon does have a decryption solution, but you have to put the Gigamon inline. Also the last time I looked at it there was a limitation of 12 private keys for decryption. I don't know if that has changed. If you can't go inline then you have to restrict the encryption algorithms and block the use of PFS.

-Otanx