[Oisf-devel] Suricata multiplying alerts with NFQUEUE

[Eric Leblond]

Hello,

On Thu, 2015-04-09 at 21:53 +0100, Duarte Silva wrote:
> On Thursday 09 April 2015 16:40:25 Duarte Silva wrote:
> > On Thursday 09 April 2015 17:17:03 Victor Julien wrote:
> > > On 04/09/2015 05:14 PM, Duarte Silva wrote:
> > > > Hi guys,
> > > > 
> > > > I'm seeing multiple alerts for the same event in the log files when
> > > > using
> > > > NFQUEUE. I have the following in the server to be protected:
> > > > 
> > > > (No other filtering rules)
> > > > # iptables -t filter -A INPUT -j NFQUEUE --queue-balance 0:1
> > > > --queue-bypass
> > > > # iptables -t filter -A OUTPUT -j NFQUEUE --queue-balance 0:1
> > > > --queue-bypass
> > > > 
> > > > (File to return to client)
> > > > # cat index.html
> > > > HTTP/1.1 OK
> > > > 
> > > > uid=0(root) gid=0(root) groups=0(root)
> > > > 
> > > > (Listen for connections)
> > > > #ncat -l 0.0.0.0 80 < index.html
> > > > 
> > > > Then in the client I do:
> > > > 
> > > > $ curl http://xxx.xxx.xxx.xxx
> > > > uid=0(root) gid=0(root) groups=0(root)
> > > > 
> > > > This should trigger two alerts due to the following rules (ET free rule
> > > > set):
> > > > 
> > > > - ET ATTACK_RESPONSE Output of id command from HTTP server
> > > > - GPL ATTACK_RESPONSE id check returned root
> > > > 
> > > > But I'm receiving 4 alerts for each rule. When running Suricata against
> > > > the
> > > > packet dump I only get 2 alerts as expected (traffic captured is 10
> > > > packets in length).
> > > > 
> > > > Kernel is 3.10.23 and I tested with Suricata latest from git, 2.1Beta3
> > > > and
> > > > 2.0.7 (same behavior in all).
> > > > 
> > > > Am I doing something wrong?

Your ruleset is not correct because you are getting all packets twice.
Client send packet which is catched by the output chain, then it reaches
the input chain (second capture). Same for the server. Basically you
just need to use one rule in input for the local trafic.

BR,

> > > 
> > > Wonder if you perhaps get alerts on retransmissions?
> > > 
> > > If you enable alert-debug log you should get info on where suri found
> > > the alerts, could be packet vs stream as well?
> > 
> > Don't know how to answer your question :( This is what I get in alert-debug
> > log.
> 
> I have also tried with the new NFTABLES and the problem is the same. I'm not 
> seeing this behavior on rules that are triggered in client to server.
> 
> _______________________________________________
> Suricata IDS Devel mailing list: oisf-devel at openinfosecfoundation.org
> Site: http://suricata-ids.org | Participate: http://suricata-ids.org/participate/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel
> Redmine: https://redmine.openinfosecfoundation.org/

-- 
Eric Leblond <eric at regit.org>
Blog: https://home.regit.org/