[Bug 778] New: NFQUEUE --queue-bypass accepts all packets when no userspace application is available

bugzilla-daemon at bugzilla.netfilter.org bugzilla-daemon at bugzilla.netfilter.org
Mon Mar 19 22:06:15 CET 2012


http://bugzilla.netfilter.org/show_bug.cgi?id=778

           Summary: NFQUEUE --queue-bypass accepts all packets when no
                    userspace application is available
           Product: netfilter/iptables
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ip6_tables (kernel)
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: steve at icanhasserver.com
   Estimated Hours: 0.0


Created attachment 381
  --> http://bugzilla.netfilter.org/attachment.cgi?id=381
Additional value test for verdict

According to the NFQUEUE documentation "The packet will move on to the next
rule", the option "--queue-bypass" should indeed continue processing the
remaining rules and not stop and always accept a packet if no userspace
consumer is available. In the following test case, it causes the packet to be
accepted instead of merely bypassing the NFQUEUE rule:

1) NFQUEUE rule present, consumer started:
   kernel logs:
     NFQ-TEST DEBUG1
     NFQ-TEST DEBUG1
     NFQ-TEST DEBUG2
     NFQ-TEST DROP
   client packet is dropped

2) NFQUEUE rule present, consumer stopped:
   kernel logs:
     NFQ-TEST DEBUG1
   client packet is accepted

3) NFQUEUE removed:
   kernel logs:
     NFQ-TEST DEBUG1
     NFQ-TEST DEBUG2
     NFQ-TEST DROP
   client packet is dropped

The userspace application (suricata in repeat mode) is configured to reinject
the packets back into the chain.

As far as I can see, nfqueue_tg_v2() modifies the verdict to include the
NF_VERDICT_FLAG_QUEUE_BYPASS flag, while ipt_do_table() and ip6t_do_table()
expect that value to be XT_CONTINUE in order to proceed to the next entry, see
attached patch against kernel 3.3.


IPTables configuration:

# Whether IPv4 or IPv6, the behaviour is the same:
#
# INPUT -> IN_ETH0  -> IN_INSPECTION
#          IN_ETH0 <-

ip6tables -F
ip6tables -X

ip6tables -N IN_INSPECTION
ip6tables -A IN_INSPECTION -j LOG --log-prefix "NFQ-TEST DEBUG1 "
# begin of NFQUEUE 
ip6tables -A IN_INSPECTION -m mark ! --mark 1/1 -j NFQUEUE --queue-num 1
--queue-bypass
# end of NFQUEUE
ip6tables -A IN_INSPECTION -j LOG --log-prefix "NFQ-TEST DEBUG2 "

ip6tables -N IN_ETH0
# other rules
ip6tables -A IN_ETH0 -j LOG --log-prefix "NFQ-TEST DROP ETH0 "
ip6tables -A IN_ETH0 -j DROP

ip6tables -A INPUT -j IN_INSPECTION
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A INPUT -m state --state NEW -i eth0 -j IN_ETH0
ip6tables -A INPUT -j LOG --log-prefix "NFQ-TEST DROP "
ip6tables -P INPUT DROP

ip6tables -P OUTPUT ACCEPT
ip6tables -P FORWARD ACCEPT

-- 
Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.



More information about the netfilter-buglog mailing list