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.
