Re: Snort++: Bugs?

[Russ <rucombs () cisco com>]

See comments below.

On 5/4/15 1:31 PM, Sancho Panza wrote:
> Hello,
>
> the issues I mentioned look good now, thanks!
>
> I didn't yet have time to try out everything as I keep updating our 
> patches to every new source released on the website so they stay in 
> sync, but there are three little issues I haven't yet mentioned:
>
> 1) In SDropAction() : actions/actions.cc, the "Active_DropSession(p)" 
> statement still within the "ifdef DEBUG_MSGS" branch looks wrong to 
> me, doesn't it? Maybe I don't get it, but intuitively I would say 
> whether or not the packet is dropped shouldn't depend on DEBUG_MSGS...
D'oh!  Good catch.
> 2) Already in Snort 2.9.x I noticed that packet IP matching wouldn't 
> work if a rule went like: "alert ip 0.0.0.0/0 any -> 0.0.0.0/0 any ( 
> msg:"Alert Test"; classtype:trojan-activity; sid:424242; rev:5; )". My 
> guess was that no one seemed to care as you could just as well write 
> "any" instead of "0.0.0.0/0", but I found the culprit to be 
> sfip_fast_cont4() : sfip/sf_ip.h. The first two lines read
>
> u_int32_t shift = 32 - sfip_bits(ip1);
> u_int32_t ip = ntohl(*ip2->ip32);
>
> Alas at least for my compiler, (int32 >> 32) is a noop, which is why I 
> made that line read:
>
> u_int32_t shift = 32 - sfip_bits(ip1);
> if (shift == 32) return 1;
Thanks, will investigate.
> 3) In our product, the IDS/IPS engine (i.e. Snort) is configured via a 
> WebUI in a way that more or less depends on the way the configuration 
> is ultimately written out into snort.conf. I am currently trying to 
> figure out how our product-internal configuration items could possibly 
> translate into snort.lua. I know there will have to be compromises, 
> but currently one of my big worries is this:
>
> In Snort 2.9.x you would be able to define more than one policy for 
> some preprocessors, e.g.:
>
> preprocessor stream5_tcp: timeout 10, policy bsd, ..., ports client 12 34
> preprocessor stream5_tcp: timeout 30, policy linux, ..., ports client 
> 21 43
>
> I used snort2lua to see how that would be expressed in snort.lua and 
> saw that the port binding part is translated into binder-when-use 
> clauses all referring to use type = 'stream_tcp'.
Sounds like a snort2lua bug.
> But then stream_tcp is only a single policy with either "policy = bsd" 
> or "policy = linux", which seems to make it impossible to define 
> different stream_tcp policies for different ports. Has this been 
> "stripped down" on purpose or is this something still to be implemented?
You need to name the table instances differently and then tell the 
binder how to use it:

stream = { }
stream_tcp = { policy = 'linux' }
stream_tcp_bsd = { policy = 'bsd' }

binder =
{
     { when = { proto = 'tcp', ports = '12 34' }, use = { name = 
'stream_tcp_bsd', type = 'stream_tcp' } },

     { when = { proto = 'tcp' }, use = { type = 'stream_tcp' } },
}

In this case the fact that stream_tcp_bsd is a flavor of stream_tcp is 
only known because of the binding.  There is no constraint on the naming.
> Many thanks
>
> Sancho
>
>
>
> Am 30.04.2015 17:41 schrieb Russ:
> > Give it a go with the latest (build 150) and let us know what you find.
> >
> > Thanks
> > Russ
> >
> > On 4/29/15 11:57 AM, Sancho Panza wrote:
> > > I just found out it's probably got to do with the other bug that 
> > > doesn't properly initialise "alerts.stateful".
> > > It occurs *only* after you define alerts = {} in your snort.lua.
> > > I'm referring to the source in snort-3.0.0-a1-144-auto.tar.gz.
> > >
> > > Regards
> > >
> > > Sancho
> > >
> > > Am 29.04.2015 16:02 schrieb Russ:
> > > > Unable to reproduce the second issue below.  Can you provide more
> > > > details (like conf, command line, pcap)?
> > > >
> > > > Thanks
> > > > Russ
> > > >
> > > > On 4/27/15 8:04 AM, Russ wrote:
> > > > > Thanks, comments below.
> > > > >
> > > > > On 4/27/15 7:39 AM, Sancho Panza wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I've noticed some strange things which I think are bugs:
> > > > > >
> > > > > > 1: Running Snort in Inline Mode, I have to specify an interface 
> > > > > > so as to
> > > > > > let Snort know I don't just want to perform a test run (which Russ
> > > > > > already said is a bug). But: The interface name provided is later
> > > > > > written into DAQ_Config_t cfg.name (see DAQ_New() in packet_io). 
> > > > > > Alas,
> > > > > > the daq_nfq.c module won't accept that (nfq_daq_initialize in
> > > > > > os-daq-modules/daq_nfs.c):
> > > > > >
> > > > > >        if(cfg->name && *(cfg->name))
> > > > > >        {
> > > > > >            snprintf(errBuf, errMax, "The nfq DAQ module does not 
> > > > > > support
> > > > > > interface or readback mode!");
> > > > > >            return DAQ_ERROR_INVAL;
> > > > > >        }
> > > > > Not surprised there.  We'll get this one fixed ASAP.
> > > > > > 2) After fixing (1) for myself, I wanted to test the Inline Mode. I
> > > > > > defined a rule as simple as:
> > > > > >
> > > > > > drop ip any any -> any any ( msg:"Drop Test"; 
> > > > > > classtype:trojan-activity;
> > > > > > sid:424242; rev:5; )
> > > > > >
> > > > > > Then I tried to send ICMP ECHO REQUEST packets from host A to 
> > > > > > host B.
> > > > > > The packets were indeed dropped, but I wouldn't see the alert. After
> > > > > > adding some debug statements, I came across the following piece 
> > > > > > of code
> > > > > > in fpLogEvent(...) (file fpdetect.cc):
> > > > > Will look into this.
> > > > > >        if ((p->packet_flags & PKT_STREAM_UNEST_UNI) &&
> > > > > >            ScAssureEstablished() &&
> > > > > >            (!(p->packet_flags & PKT_REBUILT_STREAM)) &&
> > > > > >            (otn->stateless == 0))
> > > > > >        {
> > > > > >            // We still want to drop packets that are drop rules.
> > > > > >            // We just don't want to see the alert.
> > > > > >            if ( block_action(rtn->type) )
> > > > > >                Active_DropSession(p);
> > > > > >
> > > > > >            fpLogOther(p, rtn, otn, rtn->type);
> > > > > >            return 1;
> > > > > >        }
> > > > > >
> > > > > > It turns out my ICMP echo request packets weren't considered
> > > > > > "established". So after some more searching in the code, I came 
> > > > > > across
> > > > > > the two possibilities I had to avoid this code path.
> > > > > > The first consists of adding "flow: stateless" to the rule 
> > > > > > definition -
> > > > > > that works fine.
> > > > > > The second consists of setting the "stateful" parameter of the 
> > > > > > "alerts"
> > > > > > module to "false". Just looking at the definition of 
> > > > > > alerts_params in
> > > > > > main/modules.cc, you would think the "stateful" option is 
> > > > > > disabled by
> > > > > > default:
> > > > > >
> > > > > >        { "stateful", Parameter::PT_BOOL, nullptr, "false",
> > > > > >          "don't alert w/o established session (note: rule action 
> > > > > > still
> > > > > > taken)" },
> > > > > This is a known issue.
> > > > > > Alas, the default "false" definition seems to have no effect at all!
> > > > > > What's worse, in your snort.lua, you can't even say:
> > > > > >
> > > > > > alerts = { stateful: false }
> > > > > >
> > > > > > Well, you CAN say it, but a quick look at AlertsModule::set (file
> > > > > > main/modules.cc) reveals that no matter what actual *value* you 
> > > > > > specify,
> > > > > > the option will always be enabled:
> > > > > >
> > > > > >        else if ( v.is("stateful") ) {
> > > > > >     //NOTE: no check for true or false!!!
> > > > > >            sc->run_flags |= RUN_FLAG__ASSURE_EST;
> > > > > > }
> > > > > >
> > > > > > ------------------------------------------------------------------------------ 
> > > > > > One dashboard for servers and applications across 
> > > > > > Physical-Virtual-Cloud
> > > > > > Widest out-of-the-box monitoring support with 50+ applications
> > > > > > Performance metrics, stats and reports that give you Actionable 
> > > > > > Insights
> > > > > > Deep dive visibility with transaction tracing using APM Insight.
> > > > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > > > > _______________________________________________
> > > > > > Snort-devel mailing list
> > > > > > Snort-devel () lists sourceforge net
> > > > > > https://lists.sourceforge.net/lists/listinfo/snort-devel
> > > > > > Archive:
> > > > > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
> > > > > >
> > > > > > Please visit http://blog.snort.org for the latest news about Snort!
> > > > >
> > > > > ------------------------------------------------------------------------------ 
> > > > > One dashboard for servers and applications across 
> > > > > Physical-Virtual-Cloud
> > > > > Widest out-of-the-box monitoring support with 50+ applications
> > > > > Performance metrics, stats and reports that give you Actionable 
> > > > > Insights
> > > > > Deep dive visibility with transaction tracing using APM Insight.
> > > > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > > > _______________________________________________
> > > > > Snort-devel mailing list
> > > > > Snort-devel () lists sourceforge net
> > > > > https://lists.sourceforge.net/lists/listinfo/snort-devel
> > > > > Archive:
> > > > > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
> > > > >
> > > > > Please visit http://blog.snort.org for the latest news about Snort!


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!