[Snort-devel] New internal facility: packet cloning

James Hoagland hoagland at ...60...
Fri Oct 4 09:34:01 EDT 2002

Hello again,

Attached is an updated patch for the just released Snort 1.9.0.

I'm not sure if anyone has checked this out yet.  I got a couple 
encouraging private replies, but haven't heard from anyone that has 
tried it out yet.  If anyone has comments, let me know.

Best regards,


At 8:31 PM -0700 9/29/02, James Hoagland wrote:
>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: %packetcloning_addition.patch.gz
Type: application/applefile
Size: 141 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20021004/1aa75d4a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packetcloning_addition.patch.gz
Type: application/octet-stream
Size: 5757 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20021004/1aa75d4a/attachment.obj>

More information about the Snort-devel mailing list