Hi Sean, I was thinking about your issue today and have a few questions:
-Do you have object access auditing enabled on the 2003 system (for success operations)? I remember someone saying a while ago that if you have this enabled on 2003, every time ossec tries to monitor/read the registry, it will generate an audit event. Depending on your system it can create quite a few events. -How big is your security log? (related to question above) -If that's not it, can you share the log you have with the windows debug to 2? It might reveal something .. Thanks, -- Daniel B. Cid dcid ( at ) ossec.net On Mon, Jun 2, 2008 at 1:50 PM, Sean Brown <[EMAIL PROTECTED]> wrote: > > No changes with the snapshot. > > This is running on Windown 2003 standard. We also have Windows 2003 SBS > and Windows 2000 in addition to Linux and Solaris. > > The agent is well behaved on Linux, Solaris and Windows 2000. It's only > on 2003 that it seems to freak out. Single processor systems are pegged > at 100%, a quad-core machine we have averages around 75% when idling > with OSSec running. Both fall to 1-2% when the OSSec service is stopped. > > On Fri, 2008-05-23 at 16:52 -0400, Daniel Cid wrote: >> >> Hi Sean, >> >> That should not be happening at all. At least, it never happened in >> any of my systems before. What >> version of Windows do you have? Can you update to our latest snapshot >> just to see if it changes >> anything (remember to re set the internal_options.conf after): >> >> http://www.ossec.net/files/snapshots/ossec-win32-080520.exe >> >> If none of this helps, let me know and I will generate a debug version >> of the agent for you >> to try (which hopefully will show us what is going on). >> >> Thanks, >> >> -- >> Daniel B. Cid >> dcid ( at ) ossec.net >> >> On Wed, May 21, 2008 at 4:20 PM, Sean Brown <[EMAIL PROTECTED]> >> wrote: >> > >> > Ok, setting the following: >> > >> > syscheck.sleep=20 >> > syscheck.sleep_after=15 >> > >> > There is a brief spike of CPU usage, then it seems to behave >> properly >> > for a bit, but within 5 minutes (it's random, sometimes it's much >> > sooner) the CPU is pegged at 100% until the service is stopped. >> > >> > Setting Debug to 2 does not log any errors. I really have no idea >> what >> > to do as OSSec does not react this way on our Linux or Solaris >> machines. >> > It is however seeming like we can not run the Windows agent, which >> quite >> > frankly sucks. >> > >> > On Tue, 2008-05-20 at 14:24 -0300, Daniel Cid wrote: >> >> Hi Sean, >> >> >> >> Actually, no, the internal_options file is unique from each >> agent... >> >> However, it sounds like a good >> >> feature request for next version. >> >> >> >> >> >> Thanks, >> >> >> >> -- >> >> Daniel B. Cid >> >> dcid ( at ) ossec.net >> >> >> >> On Fri, May 16, 2008 at 4:48 PM, Sean Brown <[EMAIL PROTECTED]> >> wrote: >> >> > >> >> > On Fri, 2008-05-16 at 14:42 -0300, Daniel Cid wrote: >> >> >> Hi Sean, >> >> >> >> >> >> When OSSEC starts it sends all the integrity checking messages >> to the >> >> >> server (basically all the >> >> >> monitored file names and checksums), so it can use a lot of >> bandwidth. >> >> >> So make sure it runs >> >> >> the integrity checking slowly, take a look at: >> >> >> >> >> >> http://www.ossec.net/wiki/index.php/Know_How:Syscheck_Perf >> >> >> >> >> >> Specially changing the values of syscheck.sleep and sleep_after >> to >> >> >> something like: >> >> >> >> >> >> syscheck.sleep=5 >> >> >> syscheck.sleep_after=5 >> >> >> >> >> >> Should use much less CPU/bandwidth. >> >> > >> >> > Am I correct in assuming that editing the internal_options.conf >> on the >> >> > server, all the agents will recieve the updated settings? >> >> > >> > >> > >
