[Oisf-users] Create a suricata pass rule for Nagios check_http

[Erich Lerch]

The suppress rules go to a different file (threshold.config,
referenced in suricata.yaml) for global threasholds, or need to be
added to the rule (rule based thresholds).
Look here:
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Rule-Thresholding
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Global-Thresholds

Don't worry about gen_id for the moment, set it to "1" (not sure if
this is just a compatibility issue with snort, or if it still has a
real meaning...).



2015-03-02 15:38 GMT+01:00 Claudio Kuenzler <ck at claudiokuenzler.com>:
> No prob :)
>
> Yes, they _should_ fire both. But they don't. It's still only the original
> SID from ET which fires. Mine isn't logged in fast.log. I'm trying to figure
> out why.
>
> I verified the action-order. It looks OK:
>
> # Set the order of alerts bassed on actions
> # The default order is pass, drop, reject, alert
> action-order:
>   - pass
>   - drop
>   - reject
>   - alert
>
> Thanks also for the hint about the suppress. That's more or less exactly
> what I want to do (still fire the ET SID but not when coming from my
> monitoring host).
> I have tried it with this rule (and removed my alert rule):
>
> suppress gen_id 1, sig_id 2013030, track_by_src, ip 144.76.83.23
>
> But I only get this alert when I restart suri:
>
> 2/3/2015 -- 15:27:58 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] -
> error parsing signature "suppress gen_id 1, sig_id 2013030, track_by_src, ip
> 144.76.83.23" from file /etc/suricata/rules/infiniroot.rules at line 3
> 2/3/2015 -- 15:27:58 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rules
> loaded from /etc/suricata/rules/myown.rules
>
> On the wiki page
> (https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ignoring_Traffic)
> I have no reference to gen_id. Maybe this has to be a different value? The
> sig_id is self explanatory.
>
>
> On 2015-03-02 15:32, Erich Lerch wrote:
>>
>> Oh, sorry... read too fast...
>> So now with "alert", they should fire both, I guess?
>>
>> In suricata.yaml, you have the action order:
>>
>> action-order:
>>   - pass
>>   - drop
>>   - reject
>>   - alert
>>
>> "pass" should come before "alert", maybe you can check this?
>>
>> erich
>>
>>
>> 2015-03-02 15:24 GMT+01:00 Claudio Kuenzler <ck at claudiokuenzler.com>:
>>>
>>> Hi Erich,
>>>
>>> Thanks for the hint, but I'm aware of this. As described, I have it
>>> currently set to "alert" so I know if my rule is being fired or not.
>>>
>>>
>>> On Mon, Mar 2, 2015 at 3:22 PM, Erich Lerch <erich.lerch at gmail.com>
>>> wrote:
>>>>
>>>>
>>>> Claudio,
>>>> You'll have to replace "alert" with "pass" to get a PASS rule:
>>>>
>>>> pass any 144.76.83.23 any -> $EXTERNAL_NET any ...
>>>>
>>>> Check this page to get more ideas about ignoring certain traffic:
>>>>
>>>>
>>>> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Ignoring_Traffic
>>>>
>>>> Cheers,
>>>> erich
>>>>
>>>>
>>>> 2015-03-02 15:09 GMT+01:00 Claudio Kuenzler <ck at claudiokuenzler.com>:
>>>> > Hello all,
>>>> >
>>>> > I'm trying to add my own rule so Nagios' check_http plugin are not
>>>> > creating
>>>> > alerts when coming from my fixed Nagios server.
>>>> >
>>>> > Currently the following alerts are logged (in fast.log):
>>>> >
>>>> > 03/02/2015-15:00:27.043197  [**] [1:2013030:3] ET POLICY libwww-perl
>>>> > User-Agent [**] [Classification: Attempted Information Leak]
>>>> > [Priority:
>>>> > 2]
>>>> > {TCP} 144.76.83.23:53905 -> 1.2.3.4:80
>>>> >
>>>> > Where 1.2.3.4 is the destination server I'm monitoring. The SID
>>>> > responsible
>>>> > for this alert is the following:
>>>> >
>>>> > alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY
>>>> > libwww-perl
>>>> > User-Agent"; flow:established,to_server; content:"User-Agent|3a|
>>>> > libwww-perl/"; nocase; http_header;
>>>> > reference:url,www.useragentstring.com/pages/useragentstring.php;
>>>> > classtype:attempted-recon; sid:2013030; rev:3;)
>>>> >
>>>> > The alert itself is ok, but I don't want to get alerts when this alert
>>>> > is
>>>> > triggered from my monitoring server. Therefore I created my own rule
>>>> > which
>>>> > hopefully would tell suricata to not alert when coming from my
>>>> > monitoring
>>>> > server. As of now I didn't add "pass" as the action but "alert" to see
>>>> > if
>>>> > the rule is being fired:
>>>> >
>>>> > alert any 144.76.83.23 any -> $EXTERNAL_NET any (msg:"Monitoring
>>>> > Check";
>>>> > flow:established,to_server; priority:1; sid:444888001; rev:3;)
>>>> >
>>>> > Unfortunately nothing happens. SID 2013030 is still being fired when
>>>> > my
>>>> > monitoring server runs the check_http.
>>>> >
>>>> > The new rules file was added into suricata.yaml and it is being read.
>>>> > I
>>>> > made
>>>> > a typo at the begin and this error was logged in suricata.log when I
>>>> > restarted suricata.
>>>> > And yes, suricata was restarted.
>>>> >
>>>> > Did I miss something? Did I make a mistake in the rule?
>>>> > Is it even possible to overwrite an existing SID the way I want?
>>>> >
>>>> > That's my first manual rule I'm trying to add, so have patience with
>>>> > me
>>>> > ;-)
>>>> >
>>>> > _______________________________________________
>>>> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>>> > Site: http://suricata-ids.org | Support:
>>>> > http://suricata-ids.org/support/
>>>> > List:
>>>> > https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>> > Training now available: http://suricata-ids.org/training/
>>>
>>>
>>>
>