[Snort-devel] Snort Detection (Stream4 and Flow)

Joel Ebrahimi jebrahimi at ...2857...
Tue Feb 7 12:14:01 EST 2006


Thanks Steve! This conversation seemed to get off track with some confusion (not on my part :) ) and thats the answer I needed.

Steve how about the do_detect is that possible to be reset to 1? If not wouldnt exiting the loop on a 0 improve performance?

>I guess i will leave it to you to understand your own bogus way of doing.
>And sorry , i am not waying anything about causing Denial of Service on snort , rather than tcpreplay is just a >wrong statment.
>As of having variables to ANY ...guess you have other issues there.
>And to leave it as it is you removed all SYN from the pcap file? and you wonder why you dont have any state >>detected?
 
>did my best to understand, but i guess there is a gap betwen what you express,what i understand,what i express >and what you understand.
 
Um, not sure where my lack of understanding is but basically this was all testing not an enterprise deployment. My variables are set to ANY on purpose.  And I removed part of the 3 way handshake on purpose. I think you may want to reread eveything. Thanks for trying though.  

-----Original Message-----
From: Steven Sturges [mailto:steve.sturges at ...402...] 
Sent: Tuesday, February 07, 2006 11:59 AM
To: Joel Ebrahimi
Cc: Eric Lauzon; snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] Snort Detection (Stream4 and Flow)

The 'enforce_state' option for Stream4 causes Snort to require a full 3-way handshake before marking a session as "established".

This would only affect rules with flow:established (or from_client, from_server, etc).  It eliminates creating a session from a TCP stream picked up mid-stream (ie, Snort missed the SYN or something).

The check in question in Stream4 (line 2100) checks that the packet includes a SYN (no RST).  If so, it turns off detection, but only when enforce_state is turned on.  No enforce_state, we still do the rule processing.  Unfortunately, this turns off ALL detection -- where we meant to turn off only detection of content rules, as they have flow:established (or something simlar).

There is a fix coming that resolves this -- still perform rule detection of non-content rules (like the one you mention).

NOTE: The -z option is going away, per warning in 2.4.2 and higher.
Use config stateful.

Cheers.
-steve

Joel Ebrahimi wrote:
>  
> I dont think this is the case at all. Bascially your saying I can use 
> mangled pcap files through tcpreplay to dos Snort.My variables are 
> basically all anys and Im replaying real network traffic.The pcap I am 
> using is one that I made and then modified to to remove the syn/syn 
> ack. Like I said it will not trigger if enforce_state is in stream4 but will without it.
>  
>  
> ----------------------------------------------------------------------
> --
> *From:* Eric Lauzon [mailto:eric.lauzon at ...1967...]
> *Sent:* Tuesday, February 07, 2006 11:46 AM
> *To:* Joel Ebrahimi
> *Cc:* rt-devel at lists.sourceforge.net
> *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and Flow)
> 
> Ok tcpreplay will kind-of break everything ...
> i was assuming tcpreplay in one of the reply.
>  
> use ./snort -z -r file.pcap. you should have better results.
>  
> if you need to have some kind of testbed and mabey the addresses in 
> the pcap file does not match your snort configuration , i suggest you 
> change the snort configuration rather then relying on tcpreplay to 
> rewrite packets for you.
>  
>  
> -elz
>  
>  
>  
> 
>     ------------------------------------------------------------------------
>     *From:* Joel Ebrahimi [mailto:jebrahimi at ...2857...]
>     *Sent:* 7 février 2006 14:42
>     *To:* Eric Lauzon
>     *Cc:* snort-devel at lists.sourceforge.net
>     *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and Flow)
> 
>     Im actaully replaying the pcap file on the network , Snort does not
>     read in the pcap file.
>      
>     But why would states not exist when reading in the file? Its still a
>     full packet being analyed.
>      
>     If this is the case than I could easily make a Snort dos tool and
>     just replay mangled pcaps on the network.
>      
>     // Joel
> 
>     ------------------------------------------------------------------------
>     *From:* Eric Lauzon [mailto:eric.lauzon at ...1967...]
>     *Sent:* Tuesday, February 07, 2006 11:35 AM
>     *To:* Joel Ebrahimi
>     *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and Flow)
> 
>     thats normal
>     because when reading pcap files , states does not exist. ;)
>      
>     try on the wire.
>      
>     -elz
>      
> 
>         ------------------------------------------------------------------------
>         *From:* Joel Ebrahimi [mailto:jebrahimi at ...2857...]
>         *Sent:* 7 février 2006 14:35
>         *To:* Eric Lauzon
>         *Cc:* snort-devel at lists.sourceforge.net
>         *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and 
> Flow)
> 
>         Ok well then here is the other thing I am seeing. If I remove
>         enforce_state and use only the -z (or config stateful), I am
>         trigger on a pcap where I removed the syn and syn ack out of the
>         3 way handshake. When enforce_state is in there it does not trigger.
>          
>          
> 
>         ------------------------------------------------------------------------
>         *From:* Eric Lauzon [mailto:eric.lauzon at ...1967...]
>         *Sent:* Tuesday, February 07, 2006 11:17 AM
>         *To:* Joel Ebrahimi
>         *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and 
> Flow)
> 
>         Sure will . dont worry about depricated options as of now it
>         still work well and has been since 2.0.
>          
>         But be sure that all your other settings are good two.
>          
>         Getting the sensor up is one thing , getting what you expect is
>         an other one.
>          
>         -elz
>          
> 
>             ------------------------------------------------------------------------
>             *From:* Joel Ebrahimi [mailto:jebrahimi at ...2857...]
>             *Sent:* 7 février 2006 14:17
>             *To:* Eric Lauzon
>             *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and 
> Flow)
> 
>             Well since the -z option is about to become depriciated I
>             use config stateful.
>              
>             So would this change anything though with the below
>             scenario? Meaning will this prevent stick/snot attacks and
>             allow me to still trigger on stateless scan rules?
>              
>             // Joel
>              
>             Joel Ebrahimi
>             jebrahimi at ...2857... <mailto:jebrahimi at ...2857...>
>              
>              
> 
>             ------------------------------------------------------------------------
>             *From:* Eric Lauzon [mailto:eric.lauzon at ...1967...]
>             *Sent:* Tuesday, February 07, 2006 11:09 AM
>             *To:* Joel Ebrahimi
>             *Cc:* snort-devel at lists.sourceforge.net
>             *Subject:* RE: [Snort-devel] Snort Detection (Stream4 and 
> Flow)
> 
>             Actualy if you want to be full stream4 compatible
>              
>             where_ever_path/snort -z ......
>              
>             should get you on track
>              
>             -elz
>              
>              
> 
>                 ------------------------------------------------------------------------
>                 *From:* snort-devel-admin at lists.sourceforge.net
>                 [mailto:snort-devel-admin at lists.sourceforge.net] *On
>                 Behalf Of *Joel Ebrahimi
>                 *Sent:* 7 février 2006 14:04
>                 *To:* snort-devel at lists.sourceforge.net
>                 *Subject:* [Snort-devel] Snort Detection (Stream4 and 
> Flow)
> 
>                 Hi,
>                  
>                 I've been trying to research some of the stream4
>                 preprocessor and rule options. Basically I  noticed a
>                 number of scan rules were not triggering and I looked
>                 into it further. For example here is a simplified
>                 NULL scan rule  :
>                  
>                 alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN
>                 NULL no seq"; flow:stateless; ack:0; flags:0;
>                 reference:arachnids,4; classtype:attempted-recon; )
>                  
>                 This was not triggering when I was running 'nmap -sN' ,
>                 even though I could see on the wire it should be. I then
>                 removed the enforce_state from the stream4 preprocessor
>                 and the rule fired off just like it should. Now my part
>                 of my confusion comes from the current docs. Here is
>                 what is said about flow: stateless
>                  
>                 'stateless Trigger regardless of the state of the stream
>                 processor (useful for packets that are designed to cause
>                 machines to crash)'
>                  
>                 So to me it would seem that even if enforce_state is set
>                 in stream4 these rules should trigger. If that is not
>                 the case what is the point of even adding flow:
>                 stateless to a rule?
>                  
>                 I traced what was happening through the code (I am not a
>                 Snort detection expert so forgive any misconceptions I
>                 have). So in the Preprocess function do_detect will be
>                 set in this loop to 0 in this case
>                  
>                 while(idx != NULL)
>                  {
>                          assert(idx->func != NULL);
>                          idx->func(p, idx->context);
>                          idx = idx->next;
>                  }
>                  
>                 when it is evaluating the stream4 preprocessor settings
>                 and goes into ReassembleStream4 function in
>                 spp_stream4.c . In ReassembleStream4 (around line 2100),
>                 this would be what is setting do_detect to 0 here
>                  
>                  if(!InlineMode())
>                  {
>                              if((p->tcph->th_flags & (TH_SYN|TH_RST)) !=
>                 TH_SYN)
>                              {
>                                  do_detect = 0;
>                                  p->preprocessors = 0;
>                  
>                                  return;
>                              }
>                 }
>                  
>                 So really what this means is every single TCP rule will
>                 need to have flow with it in order to enforce state and
>                 prevent stick/snot attacks and to also be able to detect
>                 stateless scan attacks at the same time . Which seems to
>                 go against what the original design of stream4 was
>                 about, explained here:
>                 http://www.snort.org/docs/faq.html#3.14
>                  
>                 Like I said I'm no detection expert, but I was also
>                 curious if do_detect that can be set to 0 depending on
>                 criteria in the loop from the Preprocess function above,
>                 can then be set back to 1. If not it would seem like you
>                 could gain some valuable cpu cycles by changing
>                  
>                 while(idx != NULL)
>                  
>                 to
>                  
>                 while(idx != NULL && do_detect != 0)
>                  
>                  
>                  
>                  
>                 Thanks,
>                  
>                 // Joel
>                  
>                 Joel Ebrahimi
>                 jebrahimi at ...2857... <mailto:jebrahimi at ...2857...>

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 2/6/2006
 




More information about the Snort-devel mailing list