[Openpacket-devel] Use cases and meta data

[Eric H. <li...@er...>]

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.