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

[Claudio Kuenzler]

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