I'll be traveling tomorrow to Louisville, Kentucky for the third DerbyCon security conference. If you're not familiar with it, Derbycon is security/hacker conference along the lines of DefCon (except smaller in scale) and has excellent presenters.
This years keynoters are H.D. Moore of Rapid7, author of Metasploit, and Ed Skoudis, Inguardians co-founder, SANS teacher and courseware author and speaker. There were over 1,700 attendees last year and over a 1,000 folks there for year one.
It's too late to get tickets (or a hotel room within 10 miles of the site) this year, but if you're interested in a low cost conference to attend, you might consider it for next year. Tickets are only $150.00 for all three days of the con, and there are two days of training prior to the conference for $1,000.00 per class.
This is mostly hacking/pentest/red team oriented but there are some blue team presentations, and being a good defender requires understanding the attacker and their tools. Well worth the relatively small cost. If you can't attend next year, all of the videos will be posted shortly after the conference on the Derbycon YouTube channel and on Iron Geek's web site (Adrian Crenshaw, Iron Geek, is the videographer for DerbyCon.)
Links:
DerbyCon: http://www.derbycon.com/
YouTube Channel: http://www.youtube.com/user/irongeek
Iron Geek Derbycon videos: http://www.irongeek.com/i.php?page=security/hackingillustrated
There is also a Roku channel for DerbyCon videos as well.
Wednesday, September 25, 2013
Tuesday, September 17, 2013
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.
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.
Subscribe to:
Posts (Atom)