On Tue, Nov 29, 2011 at 9:55 AM, Oliver Müller <[email protected]> wrote: > 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. > >
You could try using a cdb list, but there isn't really any negation options. > > > > > 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! >>>>> >>>>> >>>>> >>> >>> >
