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

Mon Mar 2 14:59:04 UTC 2015

Oh! Thanks for that hint!

So I activated threshold.config in suricata.yaml:

# You can specify a threshold config file by setting "threshold-file"
# to the path of the threshold config file:
threshold-file: /etc/suricata/threshold.config

And set the following content into /etc/suricata/threshold.config:

suppress gen_id 1, sig_id 2013030, track_by_src, ip 144.76.83.23

Restarted suri and got the following error:

<Error> - [ERRCODE: SC_ERR_PCRE_MATCH(2)] - pcre_exec parse error, ret 
-1, string , track_by_src, ip 144.76.83.23

Oops - typo. Should be "track by_src", not "track_by_src". Fixed in 
/etc/suricata/threshold.config:

suppress gen_id 1, sig_id 2013030, track by_src, ip 144.76.83.23

Restarted suri.
Followed fast.log and launched the nagios check_http check. No alerts 
logged anymore!

Thanks a lot for your help, Erich!

On 2015-03-02 15:45, Erich Lerch wrote:
> 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/
>>>> 
>>>> 
>>>> 
>> 