Yes, Michael's suggestion is the best one. In the <srcip> we support
the "!", but
not on our pattern/regex matching library.
So, instead of doing this rule (and ignoring changes for all servers, except
sles10-docs):
<rule id="100500" level="0">
<if_sid>550, 551, 552</if_sid>
<match>mdas</match>
<match>sgsdas</match>
<hostname>!sles10-docs</hostname>
<description>Ignoring changes</description>
</rule>
You could do:
<rule id="100500" level="0">
<if_sid>550, 551, 552</if_sid>
<match>mdas</match>
<match>sgsdas</match>
<description>Ignoring changes</description>
</rule>
<rule id="100501" level="7">
<if_sid>100500</if_sid>
<hostname>sles10-docs</hostname>
<description>Changes to sles-docs</description>
</rule>
It requires one extra rule, but works.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
On Thu, May 13, 2010 at 9:44 PM, Michael Starks
<[email protected]> wrote:
> Swartz, Patrick H wrote:
>> I was using the example from the Ossec book “OSSEC HIDS Guide” on page
>> 123 where they used the “!” for the <srcip> tag to say that if a source
>> IP didn’t come from within the subnet then to alert. Was hoping to be
>> able to use the same logic with the <hostname> tag.
>>
>>
>>
>> Here is the example from the book:
>>
>> <rule id=”100126” level=”12”>
>>
>> <if_sid>100124</if_sid>
>>
>> <group>authentication_failure</group>
>>
>> <hostname>main_sys</hostname>
>>
>> <srcip>!192.168.2.0/24</srcip>
>>
>> <description>Severe SSHD password failure.</description>
>>
>> </rule>
>>
>>
>>
>> Is the book wrong? Or does that expression only work for the <srcip>
>> tag? I can use the <srcip> tag work if that is the case.
>
> Hello Patrick,
>
> I haven't tried to negate an IP, but I can say for sure that trying to
> negate a hostname would not work. It would be interpreted literally.
>
> What you can do is write two rules, one dependent on the other. The
> dependent rule can have the hostname with a lower severity if the intent
> is to not alert on/block that host. When the rules are evaluated, if the
> hostname matches, then the logic will flow all the way through to the
> dependent rule.
>
> --
> Michael Starks
> [I] Immutable Security
> http://www.immutablesecurity.com
>
