* NFQUEUE target + queue-bypass option, expected behavior
@ 2014-02-13 16:20 Yoann Juet
2014-02-13 20:20 ` Eric Leblond
0 siblings, 1 reply; 3+ messages in thread
From: Yoann Juet @ 2014-02-13 16:20 UTC (permalink / raw)
To: netfilter
[-- Attachment #1.1: Type: text/plain, Size: 1700 bytes --]
Hi all,
I have two questions about NFQUEUE target and queue-bypass option. To
begin with, what is the expected behavior with iptables v1.4.14 ?
(*) extract from the manual page of iptables v1.4.14:
--queue-bypass
[...] When this option is used, the NFQUEUE rule is silently
bypassed instead. The packet will move on to the next rule.
(*) extract from the manual page of iptables-extensions v1.4.20+:
--queue-bypass
[...] When this option is used, the NFQUEUE rule behaves like
ACCEPT instead, and the packet will move on to the next table.
On a standard debian/stable machine (wheezy, iptables v1.4.14), all
packets are accepted if no userspace program is listening on an NFQUEUE.
Next iptables rules are never matched. A man-page mistake ?
Assuming that this is the expected behavior (ACCEPT), a second question
arises. I'd like to merge on a single machine firewall
(netfilter/iptables) and IPS (suricata) services. In case of suricata
failure, the firewall should run into a degraded state where packets
move on to the next rule (i.e. to L3/L4 firewall rules). Is it
technically possible with iptables v1.4.14 or higher versions ? In my
point of view, omitting queue-bypass option could be too disruptive for
a L7 firewall whereas inserting it is far too permissive.
---
Just to refine my setup, the following rule is added at the first
position of the table FORWARD:
iptables -I FORWARD -m mark ! --mark 1/1 -j NFQUEUE --queue-num 0
[--queue-bypass]
All next rules are L3/L4 traditional firewall rules.
Regards,
--
Université de Nantes - Direction des Systèmes d'Information
IM jabber: yoann.juet@univ-nantes.fr
[-- Attachment #1.2: yoann_juet.vcf --]
[-- Type: text/x-vcard, Size: 360 bytes --]
begin:vcard
fn:Yoann Juet
n:Juet;Yoann
org;quoted-printable:Direction des Syst=C3=A8mes d'Information
adr;quoted-printable:BP 92208;;2 Rue de la Houssini=C3=A8re;Nantes Cedex 3;;44322;France
email;internet:yoann.juet@univ-nantes.fr
tel;work:02.53.48.49.26
tel;fax:02.53.48.49.09
tel;cell:06.73.15.42.19
x-mozilla-html:FALSE
version:2.1
end:vcard
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3256 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: NFQUEUE target + queue-bypass option, expected behavior
2014-02-13 16:20 NFQUEUE target + queue-bypass option, expected behavior Yoann Juet
@ 2014-02-13 20:20 ` Eric Leblond
2014-02-14 12:44 ` Yoann Juet
0 siblings, 1 reply; 3+ messages in thread
From: Eric Leblond @ 2014-02-13 20:20 UTC (permalink / raw)
To: yoann.juet; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]
Bonjour,
On Thu, 2014-02-13 at 17:20 +0100, Yoann Juet wrote:
> Hi all,
>
> I have two questions about NFQUEUE target and queue-bypass option. To
> begin with, what is the expected behavior with iptables v1.4.14 ?
>
> (*) extract from the manual page of iptables v1.4.14:
> --queue-bypass
> [...] When this option is used, the NFQUEUE rule is silently
> bypassed instead. The packet will move on to the next rule.
>
> (*) extract from the manual page of iptables-extensions v1.4.20+:
> --queue-bypass
> [...] When this option is used, the NFQUEUE rule behaves like
> ACCEPT instead, and the packet will move on to the next table.
>
> On a standard debian/stable machine (wheezy, iptables v1.4.14), all
> packets are accepted if no userspace program is listening on an NFQUEUE.
> Next iptables rules are never matched. A man-page mistake ?
Yes, no code change in between but a fix in the man page.
>
> Assuming that this is the expected behavior (ACCEPT), a second question
> arises. I'd like to merge on a single machine firewall
> (netfilter/iptables) and IPS (suricata) services. In case of suricata
> failure, the firewall should run into a degraded state where packets
> move on to the next rule (i.e. to L3/L4 firewall rules). Is it
> technically possible with iptables v1.4.14 or higher versions ? In my
> point of view, omitting queue-bypass option could be too disruptive for
> a L7 firewall whereas inserting it is far too permissive.
Good analyse.
> ---
> Just to refine my setup, the following rule is added at the first
> position of the table FORWARD:
>
> iptables -I FORWARD -m mark ! --mark 1/1 -j NFQUEUE --queue-num 0
> [--queue-bypass]
> All next rules are L3/L4 traditional firewall rules.
Would it be possible for you to use the mangle table ? Something like:
iptables -A FORWARD -t mangle -m mark ! --mark 1/1 \
-j NFQUEUE --queue-num 0 --queue-bypass
If you have no accept rule in mangle table then adding this rule at the
end will guarantee that all packet are seen by Suricata.
By the way, if you want a bit more of performance you can use the queue
balance feature:
iptables -A FORWARD -t mangle -m mark ! --mark 1/1 \
-j NFQUEUE --queue-balance 0:4 --queue-bypass
Then you can start Suricata with option -q 0 -q 1 -q 2 -q 3.
BR,
--
Eric Leblond <eric@regit.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 173 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-02-14 12:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-13 16:20 NFQUEUE target + queue-bypass option, expected behavior Yoann Juet
2014-02-13 20:20 ` Eric Leblond
2014-02-14 12:44 ` Yoann Juet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox