NFQUEUE target + queue-bypass option, expected behavior

NFQUEUE target + queue-bypass option, expected behavior

[Yoann Juet]

[-- 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 --]

Re: NFQUEUE target + queue-bypass option, expected behavior

[Eric Leblond]

[-- 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 --]

Re: NFQUEUE target + queue-bypass option, expected behavior

[Yoann Juet]

[-- Attachment #1.1: Type: text/plain, Size: 581 bytes --]

Bonjour Eric et merci de ta réponse !

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

Very good idea to pass through the mangle table. I'm not using it. It 
does the job, all is running perfectly with this "hack".

Thanks again,
Regards,
-- 
Université de Nantes - Direction des Systèmes d'Information

[-- 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 --]