[Openpacket-devel] Use cases and meta data
Brought to you by:
crazy_j,
taosecurity
|
From: Eric H. <li...@er...> - 2007-01-29 14:14:30
|
Dear Packet Fanatics, I'm going to talk out loud here in hopes that by not editing myself too much I will be freer to innovate. That means a lot of this could have been said before, but maybe I'll present a new twist. One of the things we'll need with packet captures is meta data to describe the packet flow. One of the way to determine what meta-data is necessary is to go through use cases and see what becomes necessary and desirable. My use case here will be testing Network Security Devices (NSD) as that is where the need for OpenPacket is extremely high and where my interest is. For testing NSDs, one will want to send a stream of packets past the NSD. For inline perhaps a stream separated into sides going through the NSD. This process should be automated, so that a program should be able to associate the flow with the desired outcome from the NSD. There should be normal flows as well as attack flows available. There may be 'false positive' flows that should not trip the NSD, but might, and these should be labeled normal and associated with the attack. The following elements are needed to support this. Each element may be either standardized if a value space is defined or normalized if it needs to be. For these purposes, I'll break out the flows into the client and the server, understanding that sometimes that is not appropriate, but mostly it is. Shoulds and musts are apply to this use case only. CVE, standardized, if may be that more than one CVE applies, but for now, if any apply, one must be filled in. Server Application vendor, normalized, must. Server Application version, normalized, must. Client Application vendor, normalized, should. Client Application version, normalized, should. Server OS vendor, normalized, should. Server OS version, normalized, should. Client OS vendor, normalized, should. Client OS version, normalized, should. Vulnerability exploited?, boolean, Vulnerable, boolean, for passive sensors. IP in data, boolean, must indicate if the IP address of either the client or server is represented in the data. If so, it would be nice to have a way to define where (for this particular flow) the IPs are in the data so that they can be changed. Something like packet 4, byte offset 54, client IP. Port in data, boolean, same as IP in data. Flow-pointer, normalized, a URL for the actual packet dump file. OpenPacket meta-data, such as reliability of the source or if verified by others. Meta-data URL, standardized, for getting updates to the meta-data, especially the open-packet portion of the meta-data. Not all elements need to be a part of the system as stored in the OpenPacket repository, however the method of creating the meta-data should support having all these elements. Sometimes the OS is what is vulnerable and sometimes it is just the application. Having the OS separate is nice. It may allow a sophisticated testing system to manipulate OS specific fingerprints in a flow, such as Source ports, sequence numbers, options etc. to simulate different OSs from one capture. Is that dreaming, or what. :) I don't recall if there has been a final decision regarding packaging of captures. In order to support meta-data, they probably need to be gzipped-tarballs that include both the meta-data and the packet capture. Alternatively, if the capture file names could be completely unique and normalized, then a testing system could look locally for a cached copy, by filename, and then use the full URL if not found. This is probably a feature for a later version of OpenPacket. A wonderful feature for tcpreplay that would support this use case is client-server mode. Here the tcpreplay client and server would 'play' their respective side of the conversation after receiving the packet from the other side. This would be very useful for inline NSD testing. The reason I have been thinking about this use case is that I am putting together a system that will be able to manage the automated testing. It's current functionality is limited. It can watch a log file, request a remote attack agent to attack, receive confirmation that the attack was made, and check to see if the attack was observed in the logs. The attack agent can only launch HTTP attacks or prewritten HPING attacks right now. It is all in Perl and extensible through plug-ins. I begun to think about a tcpreplay plug-in and that brought about this email. I hope to appease my employer's intellectual property demigods and clean up the functionality, code and docs enough to release the system to CPAN in the not too distant future. Regards, Eric Hacker, CISSP aptronym (AP-troh-NIM) noun A name that is especially suited to the profession of its owner I _can_ leave well enough alone, but my criteria for well enough is pretty darn high. |