Snort mailing list archives
Re: Flow Established Help
From: Jason Brvenik <jasonb () sourcefire com>
Date: Fri, 13 Jan 2006 12:05:55 -0500
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
Current thread:
- Flow Established Help Ramon L. Fernandez (Jan 08)
- <Possible follow-ups>
- RE: Flow Established Help Ramon L. Fernandez (Jan 12)
- Re: Flow Established Help Jason Brvenik (Jan 13)