On Tue, Nov 22, 2011 at 8:07 AM, Oliver Müller <[email protected]> wrote:
> Yes, in my case 100103 is triggered and 31151 is "disabled", but 100102 is
> not triggered after that anymore.
> The problem that I see is, that I am trying to define all my customized rules
> in local_rule.xml, so in case of an update I know which ones has been chanced
> by myself.
>
> In order to define a rule before 31151, I have to put it in web_rules.xml,
> which is not a good idea, I guess.
>
This is totally untested (and if you test it you should report back
;)), but you could add 31151 to local_rules.xml with the overwrite
option:
<rule id="31151" level="10" frequency="10" timeframe="120" overwrite="yes">
<if_matched_sid>31101</if_matched_sid>
<same_source_ip />
<description>Mutiple web server 400 error codes </description>
<description>from same source ip.</description>
<group>web_scan,recon,</group>
</rule>
I'm not sure that will "fix" the order, but it's worth a shot.
>
>
> On 17.11.2011, at 21:33, dan (ddp) wrote:
>
>> On Mon, Nov 14, 2011 at 7:58 AM, Oliver <[email protected]> wrote:
>>> I need help configuring my agents.
>>>
>>> My rules are working fine for most of our server, but there are some
>>> exceptions to them. E.g. our development server cannot be handled as
>>> strict as the production server.
>>>
>>> To explain the problem I will choose some of the problematic default
>>> rules:
>>>
>>> <rule id="31101" level="5">
>>> <if_sid>31100</if_sid>
>>> <id>^4</id>
>>> <description>Web server 400 error code.</description>
>>> </rule>
>>>
>>> AND
>>>
>>> <rule id="31151" level="10" frequency="10" timeframe="120">
>>> <if_matched_sid>31101</if_matched_sid>
>>> <same_source_ip />
>>> <description>Mutiple web server 400 error codes </description>
>>> <description>from same source ip.</description>
>>> <group>web_scan,recon,</group>
>>> </rule>
>>>
>>> These rules basically work find. I get an email if someone is
>>> responsible for a 4xx error 12 times within 120 seconds. What I like
>>> to do now is, turn that rule OFF on a single server and override it
>>> with a weaker rule. So I did the following in the local_rule.xml:
>>>
>>> <!-- we need to disable this rule first before overriding it --
>>>>
>>> <rule id="100103" level="0">
>>> <if_sid>31151</if_sid>
>>> <hostname>my_server</hostname>
>>> </rule>
>>>
>>
>> So on my_server alert 31151 is triggered which then triggers 100103,
>> and those log messages are discarded.
>>
>>> <!-- WEAKEN standard rule on my_server -->
>>> <rule id="100102" level="10" frequency="20" timeframe="120">
>>> <hostname>my_server</hostname>
>>> <if_matched_sid>31101</if_matched_sid>
>>> <same_source_ip />
>>> <description>Mutiple web server 400 error codes </
>>> description>
>>> <description>from same source ip.</description>
>>> <group>web_scan,recon,</group>
>>> </rule>
>>>
>>
>> They never make it to this rule. You probably need to have this rule
>> in the set before 31151.
>>
>>> I would have though, that this has to work, but as long as the
>>> frequency in the last rule is higher then in rule 31151, the ossec-
>>> logtest does not work. After 12 occurrences it will just fire:
>>>
>>>
>>> 192.168.1.22 - user [11/Nov/2011:17:08:49 +0100] "OPTIONS /mypath HTTP/
>>> 1.1" 401 710 "-" "Microsoft-WebDAV-MiniRedir/6.1.7601"
>>>
>>>
>>> **Phase 1: Completed pre-decoding.
>>> full event: '192.168.1.22 - user [11/Nov/2011:17:08:49 +0100]
>>> "OPTIONS /mypath HTTP/1.1" 401 710 "-" "Microsoft-WebDAV-MiniRedir/
>>> 6.1.7601"'
>>> hostname: 'my_server'
>>> program_name: '(null)'
>>> log: '192.168.1.22 - user [11/Nov/2011:17:08:49 +0100]
>>> "OPTIONS /mypath HTTP/1.1" 401 710 "-" "Microsoft-WebDAV-MiniRedir/
>>> 6.1.7601"'
>>>
>>> **Phase 2: Completed decoding.
>>> decoder: 'web-accesslog'
>>> srcip: '192.168.1.22'
>>> url: '/mypath'
>>> id: '401'
>>>
>>> **Phase 3: Completed filtering (rules).
>>> Rule id: '100103'
>>> Level: '1'
>>> Description: '(null)'
>>> **Alert to be generated.
>>>
>>>
>>> But at this point everything just repeats itself instead of of hitting
>>> my customized rule 100102. It never occur even after a hundred bad
>>> requests.
>>>
>>> Does someone has an explanation to this or even better a solution?
>>>
>>> thnx in advance!
>>>
>>>
>>>
>
>
