Packet Auditing versus Packet Capturing

If you're new to network security, you might hear the terms "packet auditing" and "packet capturing" used interchangeably. These are two related but different concepts.

The idea behind packet auditing is to have a packet log of every connection. You want to capture enough of the packets to log the IP addresses, ports and protocols. In order to successfully do this you need a snaplength (capture size) large enough to get complete headers at their maximum size. The largest an IP header can be is 60 bytes; that is the same for a TCP header. DNS can use TCP instead of UDP for large answers to queries or zone transfers and has a header size of 12 bytes. The Ethernet header is 14 bytes. So at as minimum, you probably want to set the snaplength to at least 150 bytes or so if packet auditing is all you need to accomplish. If you have the storage space, you might want to set it higher and have at least the first several bytes of data to assist you in identifying what kind of session you're looking at.

Packet capturing, usually FULL packet capture, is intended to capture the data as well as the headers and allow for session reconstruction. Having the full packet data allows you to reconstruct the entire session, including documents and binaries for examination.

Obviously if you're doing full packet captures, you'll need a lot more storage space than doing packet auditing. When implementing your first packet capture box, you should do sample captures at various times of the day to get an idea of what a full days worth of captures will take, determine how many days, weeks or months you'll want to capture and then add a good percentage for future growth.

Since you will be storing full session data, your packet captures themselves will be repositories of a lot of confidential and proprietary data. Harden the box as you would any high value asset, keep it patched, minimize the services to what you actually need and restrict access to only those who actually need it.