> On Thu, Feb 14, 2019 at 8:52 AM Dominik <[email protected] <javascript:>> > wrote: > > > > > >> > >> That's really weird. Make sure `/var/log/syslog` is configured in the > >> agent's ossec.conf. > >> I'm not sure if turning on debugging will help, but it might log what > >> is being sent to the server. Poke around in logcollector I guess. > >> You could also try turning on the syslog remoted options on in the > >> ossec server and point the syslog there. > >> > >> > > > > Dan, > > thank you very much for your response. I did a work-around for the first > issue by sending the remote logs to a different log-file. > > > > I'm still struggling with my second problem. > > > > The rules seem not to work the same in ossec-testrule and the "real" > ossec. > > > > If I test a message from the archive, I get the following results in > ossec-testrule: > > > > ossec-testrule: Type one log per line. > > > > 2019-02-14T02:54:39.696151+00:00 PRIMUS-HSM-69 Config Process: DMU > Event: 2019-02-14 02:54:12 RNG Status: GOOD (test duration: 4 msecs) > > > > > > **Phase 1: Completed pre-decoding. > > full event: '2019-02-14T02:54:39.696151+00:00 PRIMUS Config Process: > DMU Event: 2019-02-14 02:54:12 RNG Status: GOOD (test duration: 4 msecs)' > > hostname: 'PRIMUS' > > program_name: '(null)' > > log: 'Config Process: DMU Event: 2019-02-14 02:54:12 RNG Status: GOOD > (test duration: 4 msecs)' > > > > **Phase 2: Completed decoding. > > No decoder matched. > > > > **Phase 3: Completed filtering (rules). > > Rule id: '100200' > > Level: '5' > > Description: 'Message from PRIMUS not further specified' > > **Alert to be generated. > > > > So the message should arrive with Rule 100200. But it does not (I did > add the alert_by_email option). > > > > The only messages that do arrive are messages with errors e.g. > > > > OSSEC HIDS Notification. > > 2019 Feb 12 14:26:30 > > > > Received From: (Kreuzdorn) 10.33.34.2->/var/log/auth.log > > Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system." > > Portion of the log(s): > > > > Feb 12 13:28:45 PRIMUS FSM Process: DSO error in slot S1 - PIN WRONG - > ID: USER1 [01] > > > > > > --END OF NOTIFICATION > > > > > > My guess is that the hostname is decoded differently in ossec-testrule > compared to the "real" server. > > > > Any hint on how to modify the rule, so that it matches the messages? > > > > It's possible, I don't know if I've ever used "hostname" in a rule. > > So I took the log (in /tmp/logmessage): > 2019-02-14T02:54:39.696151+00:00 PRIMUS-HSM-69 Config Process: DMU > Event: 2019-02-14 02:54:12 RNG Status: GOOD (test duration: 4 msecs) > > And the rule: > <rule id="400000" level="1"> > <hostname>PRIMUS</hostname> > <description>primus</description> > </rule> > > I added /var/log/test.log as a syslog <localfile> to my ossec.conf, > and ran `cat /tmp/logmessage | tee -a /var/log/test.log` > It worked for me, I got the alert. > So I'm not sure what's different between our installs. I'm using a > post-3.2 version of OSSEC, and I don't think I have done much > customization. > > > Thanks Dan for testing. I did some further tests myself.
If I do the test you described on the system where the OSSEC-server runs, I do get the alerts as expected. Howerver, if I do the same test on a remote client, the message makes it to the archives, but no alert is generated. So I strongly assume that the hostname is not evaluated as expeceted. Is it fair to consider this as a bug? Shall I report it on the git? Kind regards Dominik -- --- 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/d/optout.
