ULOG vs. NFQUEUE

ULOG vs. NFQUEUE

[Gilad Benjamini]

I read about ULOG and NFQUEUE in the man page, and there is something
I don't understand, and that is, why is NFQUEUE needed.
If I understand this correctly, a ULOG target with no prefix, that
sends the entire packet to userland, and is followed by an equivalent
DROP rule, does the same thing as NFQUEUE.
Doesn't it ?
I admit that I am no big expert on nfnetlink_queue. Could I be missing
something there ?

Re: ULOG vs. NFQUEUE

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

Hi,

Le vendredi 30 novembre 2007 à 15:06 -0800, Gilad Benjamini a écrit :
> I read about ULOG and NFQUEUE in the man page, and there is something
> I don't understand, and that is, why is NFQUEUE needed.
> If I understand this correctly, a ULOG target with no prefix, that
> sends the entire packet to userland, and is followed by an equivalent
> DROP rule, does the same thing as NFQUEUE.
> Doesn't it ?
> I admit that I am no big expert on nfnetlink_queue. Could I be missing
> something there ?

You're missing the whole thing.

NFQUEUE is a terminal target where the userspace take the decision on
accepting or dropping the packet. It is used by project like
snort-inline (http://snort-inline.sourceforge.net/) or nufw
(http://www.nufw.org) to improve Netfilter filtering capabilities.
Snort-inline adds IPS capabilities to Netfilter and NuFW add
identity-based rules.

ULOG (or NFLOG) is a non-terminal target which is used for logging
purpose. Packet is sent to user space but there is no user space to
kernel space interaction.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ULOG vs. NFQUEUE

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

Hi,

Le samedi 01 décembre 2007 à 10:33 -0800, Gilad Benjamini a écrit :
> Thanks.
> If I wouldn't be missing the whole thing, I wouldn't have asked this question.
> Your example implies that the packets need to be "injected" back into
> the packet flow.
> How is this done ?

This is done by calling nfq_set_verdict or nfq_set_verdict_mark in
userspace.

kernel gives a id to the packet before sending it to userspace via
[nf]netlink. It then waits for a [nf]netlink message from userspace
which will tell them what to do with the packet identified by its id.

As you may guess, the packet id is an argument of the verdict function.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]