[Snort-users] Question on port lists and negation

[Richard Bejtlich]

On 10/8/07, Matthew Watchinski <mwatchinski at ...1935...> wrote:
> Richard Bejtlich wrote:
> > Say I create this snort.conf:
> >
> > portvar MY_HTTP_PORTS [80,81,82,83,88,8000,8008,8080]
> > alert tcp any any -> any !$MY_HTTP_PORTS (msg:"Example Not"; sid:4;)
> >
>
> It alerts because
>
> 192.168.2.105:50970 -> 192.168.2.103:8000
> is no different than
> 192.168.2.103:8000 -> 192.168.2.105:50970
>
> cause you are running with any any -> any !PORTS
>
> any any matches both 192.168.2.105:50970 -> 192.168.2.103:8000
> and 192.168.2.103:8000 -> 192.168.2.105:50970
>

Hi Matt,

Thanks for your comments.  I don't understand why these packets are
"no different".  The MY_HTTP_PORTS variable includes 8000.  If I
negate MY_HTTP_PORTS in my rule, why do I get an alert on
192.168.2.105:50970 -> 192.168.2.103:8000?  Is it because port 8000 in
the packet is not other ports in the variable, like 80, 81, etc.?
>
> > Let's try another angle in a new snort.conf.
> >
> > portvar NOT_MY_HTTP_PORTS [!80,!81,!82,!83,!88,!8000,!8008,!8080]
> > alert tcp any any -> any $NOT_MY_HTTP_PORTS (msg:"Example Not"; sid:5;)
> >
> > This time, Snort reports only one alert.
> >
> > 10/08-17:00:07.050091  [**] [1:5:0] Example Not [**] [Priority: 0]
> > {TCP} 192.168.2.103:8000 -> 192.168.2.105:53298
>
> This I can't reproduce my test alerts on the same packets as the first
> rule.  Updating it with flow:to_server,established makes it behave as
> desired.
>

This doesn't make sense either.  I'm running

snort -V

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.8.0 IPv6 (Build 67)  FreeBSD
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/team.html
           (C) Copyright 1998-2007 Sourcefire Inc., et al.
           Using PCRE version: 6.6 06-Feb-2006

Before I ask any other questions, are you running the equivalent?

By the way, does your mention of adding "flow" mean the direction
identifier -> is actually just a placeholder, and not doing anything
these days?

Thank you,

Richard