Re: snort 1.9.0 memleaking ?

[Jason <security () brvenik com>]

pilsl () goldfisch at wrote:
>
> Any place to find "reasonable" numbers for these settings. I have two
> snort-daemons and each one (in default-config) eats up to 60MB Ram
> which is imho too much.  If I reduce them to 10MB : would this
> decrease securitylevel then cause less conversations can be monitored
> ?  And after all : what values should I set to gain maximum
> performance and using not more than 10-15MB. (Or do I ask for the
> impossible ?)

A bunch of semi random thoughts on the subject.

All statements are my own and not that of my employer... yada yada yada

Decreasing memory usage could hurt performance and make false positives
more likely.

To explain this a little more:
Lowering the memcap will limit the amount of RAM used and it could also
cause the engine to scram more often. By scram I mean randomly pick
sessions to drop. Not tracking sessions could allow anyone to cause an
alert with a stray packet or slip something past you in the midst of a
lot of alerts that you cannot possibly analyze. Snort attempts to
balance all this, it would be difficult, when properly tuned, to evade
it at all but there are trade offs. More memory eliminates these tradeoffs.

This ultimately depends on your environment. 60MB of ram can track a
good bit of state. 60MB of ram isn't bad at all. What is your address? I 
will send a check for 60MB of ram, it is less than a night of drinking. 
I think I can suffer through that, it will have to be a good day though 
:-) 1 gig of ram can be had for ~$300 these days (KVR266X64C2/512) so 
put the donation towards that please.

Limiting the number of sessions being tracked serves no purpose. You
could say that session tracking is more a function of limiting false
positives and performance than it is a function of detecting intrusions.

Think about it, the products out there that are heavily state based have
to worry about all these funky ways of debunking state, this opens up
greater evasion potential. ( Especially if the attacker has done some
homework and knows the target) At the same time this heavy reliance on
state increases performance under concerted attack. Not worrying about 
the ways to debunk state will ultimately take you to a system that is 
more stateless than stateful and all the potentials around that would go 
back up. The advantage is that they will stand up better under attack 
from a potential intruder who could innundate them with bad data but 
there are a more potential ways to make it ( the IDS ) ignore the 
traffic. I would bet on the ability to identify a concerted attack 
against your IDS over the ability to identify a lone session that evades 
your IDS in any environment where security is a true concern.

Now the flip side is that session tracking enables stream reassembly, 
this has some purpose in detecting intrusions by recombining attacks 
that could have been split across different packets for different 
protocols... The reality is that this type of attack is thwarted by 
reassembly in the frag and stream portions of the engine. The reality 
also is that the engine can be configured to pick these things up mid 
stream so even if sessions are scramed the engine will catch them. Since 
the majority of traffic out there will not need to be handled this way 
then you are pretty safe tuning to the environment and letting the 
preservation and intelligence of the engine handle it. If you have an 
environment where the traffic is _abusive_ such as a concerted attack 
against the IDS with a smartbits, agilent, or a home grown random 
traffic generation tool then you likely have little to no control of the 
environment and have greater architectural concerns in the deployment of 
your IDS as well as the security you can expect to maintain. Snort can 
still be deployed here, it just takes some proper tuning to the daily 
environment.

If you abandon state completely then there is no debunking. You may,
depending on environment and tuning, be innundated with false positives
by abandoning state and increase to a degree the chance that you will be 
evaded. Since it would be an abusive environment I would again say that 
you need to look at the deployment strategy. Snort can still live here 
and perform well, decisions just need to be made about the goals before 
deployment and tuning. There is still no better engine for this than Snort.

Another issue is that by ignoring state you would consider every packet
valid. This could also be a biach for the inspection engine in saturated
environments. I would bet that in most cases packets on the wire are
valid and would be inspected in the normal course of business so it 
becomes a scalability question to be addressed in deployent. In 
environments where there are a lot of packets on the wire that are not 
valid more consideration needs to be given to the case in question and 
the IDS needs to be tuned to that case. ( change at the network level 
does not happen that often to that degree )

You will always have the potential for bad data on the wire and you will
always have the potential for attacks that could evade the state engine. 
Mix it all up and all bets are off, I have not seen a proposed solution 
yet that could cover everything all the time. Unless of course you 
deploy Snort configured on different systems for the different cases.

Your decision becomes how well you have implemented your security and do
you have confidence in the implemented solution.

The benefit is that Snort ultimately lets you make that decision. You
can make anything happen with the options available to you.

It is truely a decision you have to make.

Do you track everything?
Do you risk losing packets?
Can you manage large amounts of data?
Do you mind being innundated?
Do you trust your people?
Do you have confidence in your security as a whole?
Can you afford to do it up the different ways?
...

Regards,
Jason.

>
> thnx,
> peter
>
>




-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
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