I am sorry Michael but I need another push to get me going. You suggested to “show an alert that happens when someone modifies the administrator’s group”. My agent is on a Windows 7 machine and I have tried changing a couple of administrator policies using gpedit.exe. I have also changed or deleted the adminstrator’s password. It seems that if an alert is generated with either of these actions it is a “Windows Logon Success”. This doesn’t help me much. Do I need to create or change a rule to generate an alert that is more descriptive?
It seems to me that Ossec should be able to alert on an added, modified, or deleted file in the Windows\System32 directory and also alert on a change in administrator policies without a configuration change. If there is a configuration modification that has to be made, it must be simpler than I am making it out to be. Do I need to add <directories check_all="yes">%WINDIR%</directories> to the agent’s ossec.conf to make Ossec check the system32 directory? I thought it was supposed to do that anyway. I apologize for not picking this up quicker. But I must be missing something fundamental. Thanks again. Doug On Thursday, August 8, 2013 8:27:03 AM UTC-7, Doug Kelly wrote: > > Thank you Michael, everything worked as you suggested. I enabled logall > and can see the events the agent is producing. And by changing the > password, I can see the alert it generates. I am currently working on your > suggestions from my second question. I really appreciate your help and how > quickly you responded. > > Thanks again, > Doug > > On Wednesday, August 7, 2013 4:12:13 PM UTC-7, Michael Starks wrote: >> >> On 07.08.2013 16:24, djkelly38 wrote: >> > QUESTION 1: Is there a place where I can see the events generated by >> > the Agent on the Manager side? >> > - The reason for this question is that the ossec.log file shows >> > entries that I can't prove show up as events to the manager. Like the >> > following log: >> >> If you enable logall, then all events sent by the agent will be in >> archives.log on the manager. >> >> > "2013/08/07 10:10:23 ossec-agent: WARN: Error opening directory: >> > 'C:boot.ini': No such file or directory" >> >> Hmm, I guess we'll have to look at that. >> >> > When I run the ossec-logtest with the above log entry, rule 1002 >> > fires because of the word "Error": >> > >> > **Phase 3: Completed filtering (rules). >> > Rule id: '1002' >> > Level: '2' >> > Description: 'Unknown problem somewhere in the system.' >> > **Alert to be generated. >> >> Don't take entries from ossec.log and try to run them through >> ossec-logtest. ossec.log entries are just for ossec-related >> troubleshooting purposes. They are not where the alerts are stored. All >> of the alerts are in alerts.log. >> >> > QUESTION 2: I am trying to create a simple demo showing: >> > 1. How a file added to Window's system32 directory would generate an >> > alert >> > 2. How modifying an existing or adding a new Registry key would >> > generate an alert >> >> Start with getting an alert to work for a modified monitored file. A >> couple of notes: >> 1. You'll have to wait for real-time monitoring to start after the >> agent starts. This can take awhile. Watch ossec.log. >> 2. You'll need to make sure the rule that hits on the modified file is >> set to a level high-enough to alert you. Check alerts.log. >> 3. New files and new registry keys will not be alerted in real-time. >> You'll have to force a syscheck scan or wait for the next scheduled one. >> >> > I am not having much luck with either task. I have tried my hand at >> > writing decoders and rules. Apparently, I don't fully understand the >> > process. Am I going about this all wrong? Is there an easier way to >> > demonstrate Ossec's ability to alert for added or changed system >> > files >> > or registry items? I want to generate alerts by doing something >> > harmless to my PC. I don't want to load a virus onto my desktop. Any >> > help would be appreciated. >> >> Don't mess with decoders just yet. That's too advanced right now and >> not needed. Start with learning how to write child rules and overwrite >> rules. >> >> So you don't want to put a virus on there, eh? Oh, c'mon, where's your >> spirit?! :) That's OK. OSSEC is not really the right tool for virus >> detection, anyway. >> >> In order to demonstrate value to management you need to find out what >> they value. What are the requirements for the project? What audit >> finding are they trying to remedy? Match the tool to the requirements or >> the deficiency. IMHO, the best part of OSSEC is the log analysis and >> maybe also the integrity checking (since they like to save lots of money >> on Tripwire). Focus on something like showing an alert that happens when >> someone modifies the administrator's group, if you have a problem with >> lax admin rights, for example. >> > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
