Re: Snort++: Bugs?

[Sancho Panza <sancho () posteo de>]

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...

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;

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'.

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?

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!