On Tue, Jan 11, 2011 at 5:40 PM, Patrick Melvin <[email protected]> wrote: > Adjusted the level for rootcheck/syscheck rules to 15 and I have in my > ossec.conf to only log level 15 rules that trip. Would I throw all > rules I need to modify into local_rules.xml? Will local_rules.xml > take priority over a duplicate rule found in ossec_rules.xml? > > Thanks, > Patrick >
If you're modifying a stock rule you can use the overwrite="yes" option. For example: <rule id="554" level="10" overwrite="yes"> <category>ossec</category> <decoded_as>syscheck_new_entry</decoded_as> <description>File added to the system.</description> <group>syscheck,</group> </rule> This would overwrite the stock rule of 554, which is normally level 0. For other things, a preferred method is to use the <use_sid> option: <rule id="110000" level="0"> <if_sid>5716</if_sid> <user>bob</user> <srcip>192.168.1.23</srcip> <description>Ignore bob</description> </rule> The above rule says that if rule ID 5716 (SSHD authentication failed) fires, but the user is bob coming from 192.168.1.23 fire rule 110000 instead. The if_sid method is helpful if the stock rules change so you won't have to go through and modify your rule changes to match. > On Tue, Jan 11, 2011 at 4:17 PM, dan (ddp) <[email protected]> wrote: >> On Tue, Jan 11, 2011 at 5:13 PM, Patrick Melvin >> <[email protected]> wrote: >>> Hi Dan, as I was typing answers to your questions, I investigated >>> something and found the issue. When I performed a re-install to >>> increase the max agents, I told ossec not to overwrite the existing >>> rules (as I had made modifications to ossec_rules.xml). I looked at >>> that file and it had been set back to it's original spec. After >>> making my changes, and restarting ossec, logs started being produced >>> (both in alerts.log and sent to my log collector). >>> >>> Thanks, >>> Patrick >>> >> >> What change was necessary in ossec_rules.xml? >> If it's just a local change, you should make it in local_rules.xml so >> it won't be overwritten during upgrades. >> >>> >>> On Tue, Jan 11, 2011 at 3:38 PM, dan (ddp) <[email protected]> wrote: >>>> On Tue, Jan 11, 2011 at 3:24 PM, Patrick Melvin >>>> <[email protected]> wrote: >>>>> Hi Dan, thanks for the help. >>>>> >>>>> Q: Are you receiving alert emails? >>>>> A: No, I don't have that configured. >>>>> >>>> >>>> So it's entirely possible there are no alerts being generated. >>>> >>>>> Q: What are the permissions for /var/ossec/log? >>>>> A: drwxr-x--- 5 ossec ossec 4096 2011-01-05 09:21 logs >>>>> >>>>> Q: What are the permissions for the files within /var/ossec/log? >>>>> A: >>>>> $ sudo ls -l /var/ossec/logs/ >>>>> drwxr-x--- 4 ossec ossec 4096 2011-01-11 00:00 alerts >>>>> drwxr-x--- 4 ossec ossec 4096 2011-01-11 00:00 archives >>>>> drwxr-x--- 4 ossec ossec 4096 2011-01-11 00:00 firewall >>>>> -rw-rw-r-- 1 ossec ossec 748041 2011-01-11 15:12 ossec.log >>>>> >>>>> $ sudo ls -l /var/ossec/logs/alerts >>>>> drwxr-x--- 4 ossec ossec 4096 2010-12-01 00:01 2010 >>>>> drwxr-x--- 3 ossec ossec 4096 2011-01-01 00:01 2011 >>>>> -rw-r----- 2 ossec ossec 0 2011-01-11 00:00 alerts.log >>>>> >>>> >>>> That looks close enough to what I have (might be exactly the same). >>>> >>>>> Q: What ossec processes are running? >>>>> A: >>>>> $ ps -ef | grep ossec >>>>> ossecm 14581 1 0 Jan05 ? 00:00:02 >>>>> /var/ossec/bin/ossec-csyslogd >>>>> root 14587 1 0 Jan05 ? 00:00:00 /var/ossec/bin/ossec-execd >>>>> ossec 14591 1 0 Jan05 ? 00:19:55 >>>>> /var/ossec/bin/ossec-analysisd >>>>> root 14596 1 0 Jan05 ? 00:00:05 >>>>> /var/ossec/bin/ossec-logcollector >>>>> ossecr 14601 1 0 Jan05 ? 00:38:46 >>>>> /var/ossec/bin/ossec-remoted >>>>> root 14608 1 0 Jan05 ? 00:00:20 >>>>> /var/ossec/bin/ossec-syscheckd >>>>> ossec 14611 1 0 Jan05 ? 00:00:24 >>>>> /var/ossec/bin/ossec-monitord >>>>> >>>>> Q: Is SELinux installed/enabled? >>>>> A: I don't believe so, is there a command I can run to verify? >>>>> >>>> >>>> "cat /selinux/enforce" might work. >>>> >>>> Try setting the <logall> option in ossec.conf on the manager to make >>>> sure log messages are making it to the manager. These alerts will be >>>> recorded in /var/logs/archives/archive.log (I think). >>>> More info: http://www.ossec.net/doc/syntax/head_ossec_config.reports.html >>>> >>>> Posting the ossec.conf (changing anything sensitive like passwords or >>>> IP addresses) might be helpful in tracking this down. Also check the >>>> ossec.log on the manager for any errors or messages that might provide >>>> a hint. >>>> >>>>> Thanks, >>>>> Patrick >>>>> >>>>> >>>>> On Tue, Jan 11, 2011 at 2:02 PM, dan (ddp) <[email protected]> wrote: >>>>>> Hi Patrick, >>>>>> >>>>>> On Tue, Jan 11, 2011 at 11:54 AM, Patrick Melvin >>>>>> <[email protected]> wrote: >>>>>>> Hello, I've run into another issue after "resolving" the last one. >>>>>>> The OSSEC server is not sending logs remotely to a log collector. >>>>>>> ossec-csyslogd shows in the logs that it starts ok, and is configured >>>>>>> to forward logs via syslog to the IP address specified in the >>>>>>> ossec.conf. I've verified that the OSSEC server has connectivity to >>>>>>> the log collector over 514/udp. I've also made file changes, etc. to >>>>>>> monitored files/directories on a Windows appliance that has an agent >>>>>>> running to test logging, and no logs. >>>>>>> >>>>>>> Not sure if this is relevant or not, but alerts.log has been blank >>>>>>> every day. I'm also getting an odd log from remoted: >>>>>>> >>>>>>> 2011/01/11 11:38:53 ossec-remoted: INFO: Event count after '20000': >>>>>>> 15594243->6353696 (40%) >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Patrick >>>>>>> >>>>>> >>>>>> It looks like you're having more issues than sending syslog. You'll >>>>>> need to track down why the alerts.log file isn't being logged to. >>>>>> Are you receiving alert emails? >>>>>> What are the permissions for /var/ossec/log? And the files inside? The >>>>>> ossec processes will need write access to the log files. >>>>>> What ossec processes are running? >>>>>> Is SELinux installed/enabled? Is it blocking ossec somehow? >>>>>> >>>>> >>>> >>> >> >
