[Snort-users] dr's futuresnort wish list

Geoff the UNIX guy galitz at ...247...
Mon Aug 21 16:10:27 EDT 2000

Sounds like you are asking for "stream reassembly."
I seem to recall seeing the doc's have this on tap
for a future version... of course the designers would
have better info than I.  ;)


Geoff Galitz, galitz at ...247...
Research Computing
College of Chemistry, UC Berkeley
     The laws of physics can be a harsh mistress...
        - Bender

On Mon, 21 Aug 2000, Robert E. Leever wrote:

> As long as we're creating a wish list....
> I'd like to see a way of capturing all
> traffic to and from a specific ip address
> WHEN a previous packet from that source address trips a rule.
> Possibly with an upper limit on the packet capture
> of "N" after the rule trip.  Since other posts to 
> this list have indicated the rules are a linked list,
> it should be relatively easy to insert a new rule
> something like:
> alert ANY specific ANY <> ANY ANY/24 any (limit: 100;)
> we could code the new rule into the 'tripped' rule.
> example:
> alert udp any any -> 22 (msg:"PCAnywhere"; content:"NQ";
> newrule:"alert ANY specific ANY <> ANY ANY/24 any (limit: 100;)")
> substituting the packet source address for "specific".
> Alternatively, being able to start snoop [or equiv] from a rule as 
> a seperate process would be acceptable if snort could substitute the
> source address into the command line for snoop.  
> If there is already a way of doing this I'd appreciate someone telling
> me how.  
> If the rules are ? a linked list, then it should be relatively easy to
> extend the list, and then break the link after the counter in the rule
> reached zero.
> If there was no limit: then the rule would just remain in effect.
> If you had a lot of 'trips' on a limit:-ed rule [the 'new' one that takes itself
> out of the linked list] you might have to do a cleanup on the linked list
> occassionally to prevent memory leaks.
> Also if the 'trip'-ing packet was repeated that could cause a problem; so there
> probably should be a way of disabling the 'trip'-ed rule until the limit
> in the 'new' rule was reached [for obvious reasons].  I suppose multiple 
> source's *could* launch the same attack at the same time, and you would only 
> catch the first one, but it's not very likely anyway.
> b;)
> ps.
> Of course, with a rule within a rule...the colon problem is going to HAVE 
> to be solved first (c:
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/snort-users

More information about the Snort-users mailing list