[Snort-users] A question now that I have nfq working

James Lay jlay at ...13475...
Tue Apr 15 08:54:03 EDT 2014


On Thu, 2014-04-10 at 08:35 -0600, James Lay wrote:

> On 2014-04-08 18:19, James Lay wrote:
> > On Tue, 2014-04-08 at 16:49 -0600, James Lay wrote:
> >
> >> So...it appears that that snort using nfq pass the packet along, if
> >> it's not dropped by the IDS, regardless of other rules. Example:
> >>
> >> Let's say I have a rule:
> >>
> >> drop tcp any any -> any 80 (msg:"Test 80"; sid:10000053;)
> >>
> >> I send all my traffic to my INPUT with:
> >>
> >> sudo /sbin/iptables -I INPUT -p tcp --dport 80 -j NFQUEUE
> >> --queue-num 1
> >>
> >> But I also have a block rule say to 445:
> >> pkts bytes target prot opt in out source
> >> destination
> >> 699 57925 NFQUEUE all -- * * 0.0.0.0/0
> >> 0.0.0.0/0 NFQUEUE num 1
> >> 0 0 DROP tcp -- * * 0.0.0.0/0
> >> 0.0.0.0/0 tcp dpt:445
> >>
> >> So even though I have this drop rule above to 445, I see:
> >>
> >> telnet 192.168.1.6 445
> >> Trying 192.168.1.6...
> >> Connected to 192.168.1.6.
> >> Escape character is '^]'.
> >>
> >> I've found that after passing through the nfqueue as not dropping,
> >> it
> >> appears the packet is sent along, but not to the next iptables rule.
> >>
> >> Can someone confirm this behavior? Thank you.
> >>
> >> James
> >
> >  This is an interesting situation. Here's a sample...I have a 
> > firewall
> > that looks like:
> >
> >  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target prot opt in out source destination
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
> >  10751 640K DROP all -- * * 0.0.0.0/0 0.0.0.0/0
> >
> >  So this is a whitelist approach....allow just want I want, and block
> > the rest, with the bottom rule the catch all. My issue is that any
> > rules AFTER the queue rule are disregarded. So if I do like so:
> >
> >  Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >  pkts bytes target prot opt in out source destination
> >  39 2940 NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 1
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
> >  0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
> >  10751 640K DROP all -- * * 0.0.0.0/0 0.0.0.0/0
> >
> >  Then any packets that snort doesn't drop, never reach the next rule.
> > Is there a way to change this behavior? Thanks.
> >

Well this has been an interesting exercise.  Basically it boils down to
this:  either a packet in the Snort nfqueue is accepted and sent on, or
it's dropped.  Now dropped is self evident, but "accepted and sent on"
means exactly that...sent up the stack, NOT to the next rule in the
table..the packet is treated just like it had hit an iptables ACCEPT
rule.   My setup, in this case, was a device, two nics bridged to br0,
internal hosts on one side, internet on the other.  The FORWARD chain
had all the firewall rules for the internal hosts, and my idea was just
to put the Snort queue at the top and that would be fine....yea no.  My
workaround for this behavior was to instead put the snort queue in the
PREROUTING nat table.  This makes it so once that packet is ACCEPT'd, it
goes to either the INPUT or FORWARD chain...which is just where I want
it and can manipulate it further.  I hope this helps someone out.

James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20140415/89e14d52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20140415/89e14d52/attachment.sig>


More information about the Snort-users mailing list