[Snort-users] question about paf

Russ Combs (rucombs) rucombs at ...589...
Thu Dec 18 17:13:12 EST 2014


________________________________
From: hyunseok.chang at ...11827... [hyunseok.chang at ...11827...] on behalf of Hyunseok [hyunseok at ...6185...]
Sent: Thursday, December 18, 2014 4:16 PM
To: Russ Combs (rucombs)
Cc: snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] question about paf

Thanks for your reply and clarification.

On Thu, Dec 18, 2014 at 11:35 AM, Russ Combs (rucombs) <rucombs at ...589...<mailto:rucombs at ...589...>> wrote:

________________________________

* There are ways to deal with the limits though.  If a PDU must be split, Snort shifts the split point by a random amount to make it less predictable.  Also, the issue you bring up could be handled by setting a flow bit on an earlier PDU or PDU part and checking that when detecting a later PDU or PDU part.  Also, preprocessors check for any conditions that must be detected before the PDU is assembled.

As you said, flowbits could be one way to correlate detections across blocks.  But I'm still not sure whether that's a real solution.  Might be a contrived example, but say there is a known attack string of 48K length in http payload.  Then with 16K max-paf, the attack string will split over upto 4 consecutive PDU blocks.  Maybe I am not an expert snort rule writer, but it's doesn't seem trivial or possible to write detection rules to match such consecutive blocks that hold a long string using flowbits.

* If you really mean a contiguous 48K data sequence then it sounds more like a file and could be processed using those methods.  For processing a flow in real time, the signature is typically comprised of a sequence of checks on much smaller strings for which flowbits are well suited.

-HS





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20141218/5b98ba6a/attachment.html>


More information about the Snort-users mailing list