Thank you for the reply On Mon, 2008-06-09 at 12:36 -0300, Daniel Cid wrote: > 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)?
This was our problem. Switching to failures only (I have no idea why it was logging successes as well anyway) has OSSec agents behaving themselves. > 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? > >> >> > > >> > > >> > > > >
