[Oisf-devel] Suricata multiplying alerts with NFQUEUE

[Duarte Silva]

On Thursday 16 April 2015 18:08:54 Eric Leblond wrote:
> 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.

The client isn't local, it's remote (this isn't the case were I'm reverse 
proxying internally). I double checked and this time I only tried with the 
output rule, and the behavior is the same.

Cheers,
Duarte

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