HIDS CPU usage

[Court Campbell]

OS: 11.11
HIDS B.04.00.01
Patch PHKL_34466 is installed
IDDS_MODE 3

Religiously the HIDS idscor process will chew up one CPU. I usually stop and start the process to clear the situation. I have searched the forums but have found no resolution or reason as to why this is happening. Anyone have any ideas or insights?

[Tommy_6]

Check out the following forum

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=870556

Hope it helps

Tommy

[Court Campbell]

Seen it but thanks.

[Tommy_6]

How about this:

http://docs.hp.com/en/7001/HIDS3.1SizingandTuningPrimer.pdf

It mentions:

For the majority of deployments, the performance bottleneck for HIDS will typically occur at CPU, primarily from the idscor process. The idscor process is multi-threaded and can therefore utilize over 100% CPU. HIDS will generally reach the CPU limit before other constraints such as disk or memory are realized.

Tommy

[Court Campbell]

thanks for the pdf Tommy, but that is for an older version of HIDS.

[Court Campbell]

Closing thread as it seems no one has an answer. I guess I would have better luck figuring out how many licks it takes to get to the center of a tootsie roll tootsie pop.

[Tommy_6]

HIDS is an intrusion detection software. Are you noticing any odd network traffic going to your server?

From http://docs.hp.com/en/5991-6775/ch01s05.html are you noticing any of the following:

Vulnerability: Unauthorized File Modification

Monitors: Critical system and application programs and configuration files

System and application log files

File additions and deletion

Critical files made world writable

Privileged â setuidâ programs created

Files modified by non-owners

Vulnerability: Poorly written privileged programs

Monitors: Buffer overflows and Race conditions

Vulnerability: Weak password or unauthorized access

Monitors: Logins/Logouts

Vulnerability: Password guessing

Monitors: Failed logins and failed su attempts

[Pierre Pasturel]

Hi Court -

Just saw your post. It sounds like you were never successful in root causing the high CPU usage. Information that would be helpful:

1) The number of alerts being generated per minute, hr, day, or week. Before starting idsagent/idscor and the schedule, run wc -l /var/opt/ids/alert.log to see how many alerts you have. Then start the schedule and run top so you can detect when idscor chews up a CPU, at which point run wc -l /var/opt/ids/alert.log again and let me know the number of new alerts and the time elapsed. If the schedule is not tuned properly, you might be generating alerts at a high rate, and that can cause the high CPU usage by idscor from frequently constructing alert strings.

2) The contents of /var/opt/ids/schedule on the agent where idscor is using up a CPU.

3) The rate at which idscor is processing events between the time you start a schedule and when you see the CPU spike by idscor. See http://docs.hp.com/en/5991-6776/apes03.html . So, you need to run top to keep an eye on idscor and wait until idscor spikes the CPU usage and then you need to look in /var/opt/ids/error.log where the event rate is captured. I also would like to know if the CPU does *not* spike when running idscor using the -t option.

That should be enough to start root causing this.

Pierre