I have a couple of questions just to make sure I understood your scenario correctly.
Can you confirm if this is correct - 1. You manually inserted the test log event into your audit.log file and OSSEC successfully alerted on the event. 2. You manually inserted the test log event into your mailbox.log file (on the same server where Zimbra is running) and OSSEC successfully alerted on the event (?) 3. The Zimbra server logged the exact same message to the mailbox.log file and OSSEC does not alert on the event. Question - where did you get the test log event from? Was it manually created, or did you copy/paste from the log that the Zimbra server wrote out? I am still suspecting that there are some hidden characters/non-printable characters in the log that is making it work on one system and not the other, hence my line of questions. Can you paste the exact log that the Zimbra server wrote into the mailbox.log file over here. On Thu, Jul 7, 2011 at 5:33 PM, blacklight <[email protected]> wrote: > I am using the same decoder for both log files (that's log4j above) > > I did paste the log entry into a text file, whose contents I then > piped through a Linux command into the target log, be it audit.log or > mailbox.log. I mad sure that the log entry was free of tabs. What gets > me is that the zimbra server spontaneously restarted the zimbra > service and generated its own startup log entry in mailbox.log. Had > the zimbra server written the startup log entry into audit.log, I am > 97&-100% confident that OSSEC wiould have detected the zimbra startup > log entry. Unfortunately, the zimbra server writes this log entry into > mailbox.log and OSSEC is not detecting this entry - That's what gets > me :) > > Vietnhi Phuvan > > > On Jul 7, 4:38 pm, Christopher Moraes <[email protected]> wrote: > > Just guessing here, but the issue could be the use of spaces v/s tabs. > > > > Which decoders are being used for mailbox.log and audit.log? > > > > I faced a similar issue when I copied and pasted a log into a test file > (the > > tabs got copied over). However when I ran a script to insert the logs > into > > a log file, the shell script implicitly replaced the tabs with spaces, > and > > the event did not generate an alert. > > > > HTH. > > > > > > > > > > > > > > > > On Thu, Jul 7, 2011 at 3:52 PM, blacklight <[email protected]> wrote: > > > Hello Folks, > > > > > I am at wits' end with an issue: I have written up an OSSEC rule that > > > detects whether a Zimbra mail server is acting up. > > > > > There is no issue with the syntax of the rule: it passes the ossec- > > > logtest with flying colors. The rule works 100% when I deliberately > > > insert for testing purposes into /opt/zimbra/log/audit.log the log > > > entry that the rule is designed to detect: the rule immediately shows > > > up in the OSSEC GUI as: > > > > > 2011 Jul 07 13:06:06 Rule Id: 100111 level: 7 > > > Location: (flanders.inv.anglerlabs.com) 10.80.80.3->/opt/zimbra/log/ > > > audit.log > > > Zimbra startup detected > > > 2011-07-07 13:06:38,180 INFO [main] [] misc - version=7.1.1_GA_3213 > > > release=20110624102500 builddate=20110624-1027 buildhost=zre- > > > rhel4.eng.vmware.com <-- test by V. > > > > > For reference, the dummy log entry is > > > > > 2011-07-07 13:06:38,180 INFO [main] [] misc - version=7.1.1_GA_3213 > > > release=20110624102500 builddate=20110624-1027 buildhost=zre- > > > rhel4.eng.vmware.com <-- test by V. > > > > > and is stored in a file v.4.txt > > > > > It is inserted into /opt/zimbra/log/audit.log by running the command > > > > > cat /tmp/v.4.txt >> /opt/zimbra/log/audit.log > > > > > My problem is that when I insert the same log entry (after adjusting > > > the time) into /opt/zimbra/log/mailbox.log, the OSSEC GUI does not > > > show the entry at all. > > > > > (1) I checked in /var/ossec/logs/ossec.log that OSSEC on the mail > > > server is actually writing to /opt/zimbra/log/mailbox.log: > > > > > 2011/04/14 21:56:36 ossec-logcollector(1950): INFO: Analyzing file: '/ > > > opt/zimbra/log/mailbox.log'. > > > 2011/06/25 08:17:18 ossec-logcollector(1950): INFO: Analyzing file: '/ > > > opt/zimbra/log/mailbox.log'. > > > > > Lest you think that OSSEC somehow stopped reading mailbox.log, I > > > checked that OSSEC is currently reading /opt/zimbra/log/audit.log: > > > > > 2011/04/14 21:56:36 ossec-logcollector(1950): INFO: Analyzing file: '/ > > > opt/zimbra /log/audit.log'. > > > 2011/06/25 08:17:18 ossec-logcollector(1950): INFO: Analyzing file: '/ > > > opt/zimbra /log/audit.log'. > > > > > Note that the date and times for mailbox.log and audit.log. > > > > > (2) I checked the file permissions for audit.log and mailbox.log - > > > they match: > > > > > [root@mailserver log]# ls -l mailbox.log audit.log > > > -rw-r----- 1 zimbra zimbra 2586778 Jul 7 15:35 audit.log > > > -rw-r----- 1 zimbra zimbra 94811342 Jul 7 15:35 mailbox.log > > > > > Let's summarize: the logs files have identical permissions, the OSSEC > > > agent on the mail server reports that is reading both /opt/zimbra/log/ > > > audit.log and /opt/zimbra/log/mailbox.log> Yet, the OSSEC GUI shows > > > the rule being triggered when the dummy log entry is inserted in > > > audit.log but not triggered when the same rule is inserted in > > > mailbox.log. I am losing my mental grip: what's going on? > > > > > For reference, > > > > > decoder > > > > > <decoder name="log4j"> > > > <prematch>^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d,\d\d\d </prematch> > > > </decoder> > > > > > Rule:: > > > > > <decoded_as>log4j</decoded_as> > > > <description>Log4J Container</description> > > > </rule> > > > > > <rule id="100102" level="0"> > > > <if_sid>100101</if_sid> > > > <regex>ERROR|FATAL|INFO|WARN \S+ [\S+] \S+ - </regex> > > > <description>filter out the message categories</description> > > > </rule> > > > > > <rule id="100111" level="7"> > > > <if_sid>100102</if_sid> > > > <regex>buildhost=</regex> > > > <description>Zimbra startup detected</description> > > > </rule> > > > > > Again, I am at my wits' ends: this is a situation where it should > > > work, must work and yet doesn't work. Do you have any ideas for > > > diagnostics, further investigation or resolution? > > > > > Thanks, > > > > > Vietnhi Phuvan >
