Hi, there is no "agentID" tag for rules. It seems that in your case, the *hostname* is the same that the *agent name*, so it could work. But, remember that some events have the *hostname *field empty.
Usually, it is better to use the field *srcip *to ignore rules due to is unique and it is more difficult to spoof (anyone can change the hostname of his machine). In case you need it, you could create a decoder to extract the IP of your logs. Regards. On Thursday, August 18, 2016 at 5:52:11 PM UTC+2, Cliftyman wrote: > > I just realized I use <hostname> to reference the agent name in most all > of my rules (and 95% of them work). Am I using that incorrectly? Isn't > there a rule field to reference the name of the sending agent... perhaps > <agentID> or something of that nature? > > > Totally forgot about the logtest utility... thanks much on making me aware >> of that! >> >> It looks like I could using the hostname type and specify the source IP >> inside of <hostname></hostname> in my rule and the suppression rule will >> work. Will try that now. >> >> >> >> On Thursday, August 18, 2016 at 8:30:59 AM UTC-5, dan (ddpbsd) wrote: >>> >>> On Thu, Aug 18, 2016 at 9:09 AM, Cliftyman <clif...@gmail.com> wrote: >>> > I'm confused about how to use the rule types built into the OSSEC log >>> rule >>> > syntax. >>> > >>> > I have a localfile declared in my /var/ossec/etc/shared/agent.conf.... >>> > >>> > agent_config name="centrallogger"> >>> > <localfile> >>> > <location>/var/log/LOC/*.log</location> >>> > <log_format>syslog</log_format> >>> > </localfile> >>> > </agent_config> >>> > >>> > This is a central logging "catchall" server that I send multiple >>> systems >>> > logs to and I run an OSSEC agent on that syslog server to watch all >>> the >>> > logs. So all .log files in /var/log/LOC on server1 should be syslog >>> > format.... I'm receiving alerts from these logs just fine. Alerts >>> come >>> > from "centrallogger" but the first line states the location so I know >>> which >>> > server the alert is referencing. There are some scripting errors on >>> one of >>> > the servers sending logs to "centrallogger" and I want to filter them >>> out. >>> > So I wrote a rule in local.rules on my OSSEC server that included a >>> <srcip> >>> > declaration: >>> > >>> > <rule id="100073" level="0"> >>> > <if_sid>5720</if_sid> >>> > <srcip>192.168.1.5</srcip> >>> >>> Using the logs below, I get this with ossec-logtest: >>> ossec-testrule: Type one log per line. >>> >>> Aug 18 07:30:25 192.168.1.5 sshd[20247]: [ID 800047 auth.notice] >>> Failed none for root from 192.168.1.1 port 36942 ssh2 >>> >>> >>> **Phase 1: Completed pre-decoding. >>> full event: 'Aug 18 07:30:25 192.168.1.5 sshd[20247]: [ID >>> 800047 auth.notice] Failed none for root from 192.168.1.1 port 36942 >>> ssh2 ' >>> hostname: '192.168.1.5' >>> program_name: 'sshd' >>> log: 'Failed none for root from 192.168.1.1 port 36942 ssh2 ' >>> >>> **Phase 2: Completed decoding. >>> decoder: 'sshd' >>> >>> **Phase 3: Completed filtering (rules). >>> Rule id: '5716' >>> Level: '5' >>> Description: 'SSHD authentication failed.' >>> **Alert to be generated. >>> >>> So srcip isn't being decoded. >>> >>> > <hostname>centrallogger</hostname> >>> > <description>scripted maint failing on interconnect >>> links</description> >>> > </rule> >>> > >>> > To suppress the alert I was receiving below......... >>> > >>> > OSSEC HIDS Notification. >>> > >>> > 2016 Aug 18 08:36:29 >>> > >>> > >>> > >>> > Received From: (centrallogger) >>> 10.147.130.0->/var/log/LOC/loggedserver1.log >>> > >>> > Rule: 5720 fired (level 10) -> "Multiple SSHD authentication >>> failures." >>> > >>> > Portion of the log(s): >>> > >>> > >>> > >>> > Aug 18 07:30:25 192.168.1.5 sshd[20247]: [ID 800047 auth.notice] >>> Failed none >>> > for root from 192.168.1.1 port 36942 ssh2 >>> > Aug 18 07:30:24 192.168.1.5 sshd[20227]: [ID 800047 auth.notice] >>> Failed none >>> > for root from 192.168.1.1 port 36941 ssh2 >>> > Aug 18 07:30:23 192.168.1.5 sshd[20205]: [ID 800047 auth.notice] >>> Failed none >>> > for root from 192.168.1.1 port 36939 ssh2 >>> > >>> > And the suppression is not working. I've also attempted a <match> on >>> ASCII >>> > text "Failed none for root". I've historically had issues getting >>> matching >>> > to work in log messages and I'm wondering if this has something to do >>> with >>> > using a wildcard, or if my syslog log format decoder is not working >>> > properly? If I'm using <srcip> OSSEC has to recognize where the SRCIP >>> is in >>> > the syslog string? >>> > >>> > >>> > -- >>> > >>> > --- >>> > 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 ossec-list+...@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >> -- --- 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
