In general the overwriting seems to work, but doesn't really help, because I 
have no tools to EXCLUDE or NEGATE a hostname and I don't have a dstip :-(
the exclude or negate is also missing in category, user, program_name, …
It does follow reg exp syntax, but reg exp doesn't allow an exclude really.

of course I could create one rule with one hostname and another one with all 
other hostname, but if I forget a new server in that rule, it will not be 
protected by this rule.

for example with these two rules:
 <rule id="31151" level="10" frequency="120" timeframe="10" overwrite="yes">
   <if_matched_sid>31101</if_matched_sid>
   <same_source_ip />
   <hostname>no_dev_server_1</hostname>
   <hostname>no_dev_server_2</hostname>
   <hostname>no_dev_server_3</hostname>
   <description>Mutiple web server 400 error codes </description>
   <description>from same source ip.</description>
   <group>web_scan,recon,</group>
 </rule>

 <rule id="100103" level="10" frequency="120" timeframe="120">
   <if_matched_sid>31101</if_matched_sid>
   <same_source_ip />
   <hostname>development_server</hostname>
   <description>Mutiple web server 400 error codes </description>
   <description>from same source ip.</description>
   <group>web_scan,recon,</group>
 </rule>

Is there another solution to it? I hope and guess that this situation is quite 
common. Companies do have different security requirements for different servers.






On 28.11.2011, at 21:19, dan (ddp) wrote:

> 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!
>>>> 
>>>> 
>>>> 
>> 
>> 

Reply via email to