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

[Claudio Kuenzler]

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20150302/656aedb4/attachment-0002.html>