RE: Flow Established Help

["Ramon L. Fernandez" <buddy () uswebpc com>]

Jason,

Thank you for your input.

You mentioned the drawbacks to asynchronous mode. I am assuming the
drawbacks are limitations on the flexibility of rule writing? Or is more
like snort is not as accurate in stateful analysis in this mode? If neither,
could you give me an example?

My overall goal was to establish how effective snort would be if run
monitoring incoming traffic only. Because of this setup, I am attempting to
write some custom rules, and I wanted to know what modifiers would be useful
and which ones would prohibit the rule from ever being true, hence the
'flow:to_server' question.

Here is another one for you, in an incoming traffic only setup, are there
any pre-processors which can be considered useless to leave enabled? I have
been playing with this setup and it seems to work good so far, but then
again, there could be plenty I am missing and I do not even know it. From
what I have seen in the docs on snort, it seems to me that this could lead
to problems with the stream processor.

For example, certain rules just never went off when using the
'flow:to_server, established' keyword, and then once I removed it, those
rules began trigger without issue. This leads me to believe the
'flow:to_server, established' keyword in my setup is actually inhibiting
snort from triggering the rules because it cannot see the server-side,
outgoing traffic. It seemed even removing the established did not help. Only
when I removed the 'flow:' keyword all together did the sensor pick up the
rules.

Any more input you could offer would be appreciated and thank you for taking
the time to answer my questions. 

Cheers,

Ramon Fernandez


-----Original Message-----
From: Jason Brvenik [mailto:jason.brvenik () sourcefire com] 
Sent: Monday, January 09, 2006 12:12 PM
To: Ramon L. Fernandez
Cc: snort-users () lists sourceforge net
Subject: Re: [Snort-users] Flow Established Help



Ramon L. Fernandez wrote:
> Hello,
>
>  
>
> I had a question about the use of flow:established in the context of
> snort rules.
>
>  
>
> How does snort interpret an established session? Does it utilize traffic
> in both directions or can still understand an established connection
> from unidirectional traffic?

In the default operational mode state relies on traffic from both
systems to determine state. You can run in "asynchronous mode" which
will attempt to determine state but there are several drawbacks to this
method.

> A hypothetical situation would be a http connection negotiation where
> the part or all of the server response is dropped by snort. Would snort
> still be able to understand that the session was established based off
> unidirectional communications or would snort assume the session was not
> established and pass the packet with malicious content.

It is not hypothetical at all. This can happen if you do not have a
system capable of keeping up with the traffic it is presented.
Sourcefire has systems that scale to 8gig so it is certainly possible to
handle most situations. It usually comes down to a time and budget thing
when you get into high performance networks though.

>  
>
> If it did pass on the packet, would snort also pass if the
> flow:to_server option was instead substituted?

I am not sure I understand this question. If the server responses were
missed and you only had client side traffic that would qualify as
to_server. If flow:to_server, established were set then the traffic
would not be inspected in the default case.

>  
>
> From what I have read in the FAQ about switched environments, not being
> able to see RX and TX traffic causes a drawback of being unable to
> perform stateful analysis, but then it says a workaround is to monitor
> RX traffic only on a gigabit switch. This seems contradictory to me, so
> I am simply seeking clarification.

This depends on the network setup. In many cases if you are monitoring
all ports the traffic can traverse then the traffic will appear as an RX
for one of them and be properly presented to the system for inspection.
Without a network diagram and configuration it is difficult to say for
sure what the behavior would be.

>  
>
> If this question seems elementary, I apologize. I am new to utilizing
> snort, but I do research, and from plenty of time at google and reading
> what I found, I could not find a clear answer. Any help would be much
> appreciated!

no worries. We are all here to answer questions and help. If you had
asked something that was _clearly_ in the docs you might have just
gotten a link but that is really to save time and keep from answering
the same question several different ways.

>  
>
> Cheers,
>
>  
>
> Ramon Fernandez

-- 
Jason Brvenik - Sourcefire
PGP: 89C6 DE77 3B32 FC03 A5AE B5DD 11DF 4C8B 0D8E 3383
Key: http://cerberus.sourcefire.com/~jbrvenik/jason.brvenik.pgp.key




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users