[prev in list] [next in list] [prev in thread] [next in thread] 

List:       snort-users
Subject:    Re: [Snort-users] Flow Established Help
From:       Jason Brvenik <jasonb () sourcefire ! com>
Date:       2006-01-13 17:05:55
Message-ID: 43C7DDF3.6050308 () sourcefire ! com
[Download RAW message or body]



Ramon L. Fernandez wrote:
> 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?

The drawbacks are that async tries to figure out what side of a
conversation it has with the traffic it has and can get it wrong. In the
case where the system gets mostly server replies you could end up
inspecting that traffic as a client side flow. async essentially creates
an established flow with direction based on the information is has
available and does not try to validate it based on the cooperative
conversation.

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

Using async you hsould be pretty good using the rules if you know that
it is client only data. There would be additional evasion cases,
potential event insertion, and a potential performance hit if you end up
with server side data getting tagged as client data but the system
should work just fine. I am only aware of one network that operates in
this mode but I've not heard of any complaints there either. Sourcefire
does not offer it as an option or routinely test the code branch for it
since there are often commercial solutions to the visability problem.

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

No preprocessors would be made useless with client only traffic. stream4
would be the most critical and moving to async should fis that up pretty
well for your described situation.

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

This is the intent of async. You will want to have plenty of memory
available for stream as it will not know proper stream teardowns and you
will end up keeping state for a number of extra streams for a while.

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

using async this should still work. I've not looked at the code for
async in a while but it is a function of stream to handle the
established capability and a finction of flow to handle direction.

Try adding asynchronous_link to the config.

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

This would be expected behavior.

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


-------------------------------------------------------
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
[prev in list] [next in list] [prev in thread] [next in thread]