[Snort-devel] New internal facility: packet cloning

James Hoagland hoagland at ...60...
Sun Sep 29 20:33:02 EDT 2002


Greetings all,

I have written some new Snort internal functionality that should help 
current and future Snort detectors (e.g., preprocessors) do better 
detection and/or more complete and standard reporting.  That 
functionality is creating a copy of a Packet.

Some background first, as I understand it (correct me if I am 
mistaken).  A Packet is the Snort data structure that contains the 
parsed fields of a packet that libpcap presents to Snort.  It is 
Snort's standard representation of a packet and so is used throughout 
the program.  It is given to preprocessors and Snort's signature 
based detector as one in a stream of packets.  When these detectors 
wish to report on a packet, they typically pass the Packet to the 
alert/log facilities (e.g., alert file or database) that the user has 
configured.  However, sometimes detectors use different output means 
than the standard ones that the user configured.  For example, 
spp_portscan and spp_portscan2 and their packet logs.  (There could 
be others.)

I cannot say for sure why these two do not use the standard output 
mechanism.  But one barrier is the combination of the fact that the 
output mechanisms can only output a Packet structure and the fact 
that the Packet that is given to the detectors does not persist 
beyond that call into that detector.  Specifically, there is only one 
Packet that Snort has in memory at a time.  Regardless of the reason, 
the effect is that the user does not have the control they might like 
over the place where packets are stored.  For example, they cannot 
have portscan packets (as reported by spp_portscan) be logged to the 
database.  So this suggests that in order to give this flexibility to 
the user, the simplest thing is to provide the detector with a means 
of holding onto a Packet beyond its invocation.  However, this 
functionality does not exist in Snort and, given the complexity, it 
can be daunting for the detector writer to do write it themselves.

The class of detectors that this will help is those that do not want 
to immediately report on a packet.  Often this will be because they 
want to wait for future information contained on the packet stream. 
For example, they want to eliminate a potential false positive.  And 
we know that false positives can be a barrier to effective use of 
Snort (and other IDSs).  So, providing the copying functionality, 
while not getting rid of false positives and promoting more standard 
packet reporting, can be enabling towards these goals.


Okay, enough for the motivational speech. :)  Its working code that 
gets things done in open source.  So, it is attached.  At least it is 
working in my tests; I need others to test it our as well since, 
e.g., I do not have access to FDDI network packet to try it on.  And 
I am not an expert on the Packet data structure.  But I know much 
more about it now, given frequent consultation with decode.[ch].

This is what is attached:

1) packets.c: the code that implements ClonePacket() and FreePacket().

2) packet.h:  I'll let you guess what role this serves. :)

3) snort+pclone.patch:  A patch against snort 1.9.0beta6 that puts 
packets.[ch] into the Snort source.  In addition, the patch includes 
a hack of a preprocessor, spp_pcopytest, that uses the cloning code. 
It makes clones of 100 packets on the packet stream at a time before 
pushing them to the standard output facilities.  For reference, the 
original packets are spit out as they are received.  The original 
should match the clone (as they do in all my tests).  Run it as 
"src/snort -c etc/pcopytest.conf".

Implementation notes.  There were other ways that this can be 
approached.  My goal was for it to be efficient and with only 
localized changes (e.g., no changes to Packet).  There are some other 
notes in the source.

Snort notes.  There might be a couple small snags when using cloned 
packets.  One that I noticed is an (now) incorrect assumption that 
there will only be one call to PrintNetData between each packet 
acquisition.  (The workaround it to manually flush its cache.)  If 
some output mechanism makes a hardcoded reference to "the" Packet, 
that will be broken.  And if anything else makes the assumption that 
PrintNetData did, that would be broken.


My main motivation for doing this is that the next generation version 
of Spade will need this functionality to reduce false positives and 
to accurately detect new scan types.  I could have this functionality 
internal to Spade, but I'd rather it be a general Snort internal 
facility that can be used anywhere in Snort.  If someone can 
implement this better, go for it.  But the functionality of a Packet 
persisting across calls to a preprocessor is something that I'll be 
needing in the not-too-distant future.

If anyone has any questions/concerns/comments/fixes, let me know.

Sorry for the length of this message.

Kind regards,

   Jim

P.s. I do not think that Packet cloning is covered by any US federal 
or state stature, so at least we are safe that way. :)

-- 
|*      Jim Hoagland, Associate Researcher, Silicon Defense      *|
|*            --- Silicon Defense: IDS Solutions ---             *|
|*  hoagland at ...60..., http://www.silicondefense.com/  *|
|*   Voice: (530) 756-7317                 Fax: (530) 756-7297   *|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: %packets.c
Type: application/applefile
Size: 1585 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packets.c
Type: application/octet-stream
Size: 5632 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: %packets.h
Type: application/applefile
Size: 1585 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packets.h
Type: application/octet-stream
Size: 130 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: %snort+pclone.patch.gz
Type: application/applefile
Size: 131 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort+pclone.patch.gz
Type: application/octet-stream
Size: 3166 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20020929/4b639638/attachment-0002.obj>


More information about the Snort-devel mailing list