[Snort-users] ack!@

Martin Roesch roesch at ...421...
Mon Jan 29 10:45:10 EST 2001


It's all just bitmasking, so there's not speed impact whatsoever apart
from the extra AND op in some of the rules.  Realisticly this should
mean that there's no impact apart from a few clock cycles difference
between the different operations.  W0rd to the code
(sp_tcp_flags_check.c):

    switch((flagptr->mode))
    {
        case M_NORMAL:
            if(flagptr->tcp_flags == p->tcph->th_flags) /* only these
set */
            {
                return fp_list->next->OptTestFunc(p, otn_idx,
fp_list->next);
            }
            break;

        case M_ALL:
            /* all set */
            if((flagptr->tcp_flags & p->tcph->th_flags) ==
flagptr->tcp_flags)
            {
                return fp_list->next->OptTestFunc(p, otn_idx,
fp_list->next);
            }
            break;

        case M_NOT:
            if((flagptr->tcp_flags & p->tcph->th_flags) == 0)  /* none
set */
            {
                return fp_list->next->OptTestFunc(p, otn_idx,
fp_list->next);
            }
            break;

        case M_ANY:
            if((flagptr->tcp_flags & p->tcph->th_flags) != 0)  /*
something set */
            {
                return fp_list->next->OptTestFunc(p, otn_idx,
fp_list->next);
            }
            break;

        default:  /* Should never see this */
            break;
    }


As you can see, it's just different ways of manipulating the same bit
fields.  Whenever possible in Snort I try to make sure the rules data is
converted to look the same way that the network traffic will look so
that data manipulation is kept to a minimum when Snort's doing it's
heavy lifting tasks.

There are some other tricks that Snort can do these days that aren't
documented (or documented well anyway) that will be sneaking into the
rules document around version 1.7.1.

   -Marty


Brian Caswell wrote:
> 
> Max Vision wrote:
> >
> > These are all "fixed".  http://whitehats.com/ids/
> >
> > I should note that I didn't mean to imply that the rules using "flags:
> > AP;" were useless - just that they were too specific and could be easily
> > evaded by skilled attackers.  As most of your know, there is a tight
> > shortage of skilled attackers so this change has minimal (but necessary)
> > impact.
> >
> > There are no longer any tcp rules in arachNIDS that flag for the specific
> > PSH+ACK flags.  I can't think of any attack where these flags (and only
> > these flags) must be present.  All appication level attacks that fit into
> > this category that I can think of can be supplemented by extra flags to
> > evade IDS.
> >
> > I also wanted to clarify (correct me if you know otherwise) that by
> > broadening the tcp flags search we are not going to slow down Snort.
> 
> I've done a bit of testing and I don't see a difference.  Technically,
> it
> should be faster.  "If it has A, good. else skip" is much faster than
> "if it has A AND B, good. else skip"
> 
> + just means anything else is ok.  we only care if A is set or not and
> thats it.
> 
> -brian
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> http://lists.sourceforge.net/lists/listinfo/snort-users

--
Martin Roesch
roesch at ...421...
http://www.snort.org




More information about the Snort-users mailing list