[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-security] raq3 ns kernel: VM: do_try_to_free_pages fa iled error messages
- Subject: RE: [cobalt-security] raq3 ns kernel: VM: do_try_to_free_pages fa iled error messages
- From: Graeme Fowler <graeme.fowler@xxxxxxxxxxxxxx>
- Date: Thu, 6 Dec 2001 09:32:28 -0000
- List-id: Mailing list for users to address network security on Cobalt products. <cobalt-security.list.cobalt.com>
Gerald Waugh wrote:
> Snort is a resource hog! You need to fill the RaQ up, memory
> is cheap at the moment.
...after Render-Vue wrote:
> Just did a search through the archive and found that it was a
> lack of memory and swap space...this server is a RaQ3i with
> 128Mb. I'm just wondering if SNORT could have caused the
> problem when analysing logs ????
Ah, snort is only as much of a resource hog as you tell it to be. Running
snort on a RaQ means you can drop all the IIS/Windows rulesets, and there
are a *lot* of other rules which churn out false positives like there's no
tomorrow.
I suspect that this isn't snort itself being a resource hog, but from the
number of 'perl' entries in the list output from 'ps' that this RaQ is
running snortsnarf or somesuch perl-based log processor, right?
There are a number of ways to approach this one:
1. Cut down the rulesets so you get less meaningless guff in your alerts.
Like, do you really care if someone tries to do a web GET for
"/scripts/MSADC/root.exe"? Thought not.
2. Process the logs more often - smaller logs == less memory usage
3. Try a different log processor, like ACID or something. Of course this
relies on a database backend which has other implications!
The ruleset line is the important one. Only run rules you need.
Any more about this, mail me off-list as it's not really a Cobalt issue,
more Snort itself.
Graeme
--
Graeme Fowler
System Administrator
Host Europe Group PLC