NFQUEUE verdicts - adding non-termination

NFQUEUE verdicts - adding non-termination

[Andrew Watts]

Hi.

The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4 post is very interesting.

NF_CONTINUE would provide the NFQUEUE target the added flexibility of, say, partial handling in userspace. A queue-handler could have a set of criteria that, when satisfied, would result in an immediate drop or accept. One could then leave the rest of the packets to find their fate in the chains/rules left to traverse.

I would be interested in helping to add this verdict if someone will take the lead (assuming a patch hasn't already been written - has it?).

Your comments appreciated.

~ Andy


      

Re: NFQUEUE verdicts - adding non-termination

[Patrick McHardy]

On 11.11.2010 10:01, Andrew Watts wrote:
> Hi.
> 
> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4 post is very interesting.
> 
> NF_CONTINUE would provide the NFQUEUE target the added flexibility of, say, partial handling in userspace. A queue-handler could have a set of criteria that, when satisfied, would result in an immediate drop or accept. One could then leave the rest of the packets to find their fate in the chains/rules left to traverse.
> 
> I would be interested in helping to add this verdict if someone will take the lead (assuming a patch hasn't already been written - has it?).

There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
Queueing happens outside of the ruleset context, so in either case the
packet would continue through the network stack directly, not after
the NFQUEUE rule.

Re: NFQUEUE verdicts - adding non-termination

[Andrew Watts]

--- On Thu, 11/11/10, Patrick McHardy <kaber@trash.net> wrote:

>On 11.11.2010 10:01, Andrew Watts wrote:
>> Hi.
>> 
>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4
>> post is very interesting. NF_CONTINUE would provide the NFQUEUE
>> target the added flexibility of, say, partial handling in
>> userspace. A queue-handler could have a set of criteria that,
>> when satisfied, would result in an immediate drop or accept. One
>> could then leave the rest of the packets to find their fate in the
>> chains/rules left to traverse. I would be interested in helping
>> to add this verdict if someone will take the lead (assuming a patch
>> hasn't already been written - has it?).

>There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
>Queueing happens outside of the ruleset context, so in either case the
>packet would continue through the network stack directly, not after
>the NFQUEUE rule.

I see. Is there a way to achieve this result under the current
infrastructure?

~ Andy



      

Re: NFQUEUE verdicts - adding non-termination

[Patrick McHardy]

Am 12.11.2010 12:01, schrieb Andrew Watts:
> --- On Thu, 11/11/10, Patrick McHardy <kaber@trash.net> wrote:
> 
>> On 11.11.2010 10:01, Andrew Watts wrote:
>>> Hi.
>>>
>>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4
>>> post is very interesting. NF_CONTINUE would provide the NFQUEUE
>>> target the added flexibility of, say, partial handling in
>>> userspace. A queue-handler could have a set of criteria that,
>>> when satisfied, would result in an immediate drop or accept. One
>>> could then leave the rest of the packets to find their fate in the
>>> chains/rules left to traverse. I would be interested in helping
>>> to add this verdict if someone will take the lead (assuming a patch
>>> hasn't already been written - has it?).
> 
>> There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
>> Queueing happens outside of the ruleset context, so in either case the
>> packet would continue through the network stack directly, not after
>> the NFQUEUE rule.
> 
> I see. Is there a way to achieve this result under the current
> infrastructure?

Having the packet continue after the NFQUEUE rule? No, once the packet
is reinjected, that rule might not even be there anymore.

Re: NFQUEUE verdicts - adding non-termination

[Patrick McHardy]

On 12.11.2010 12:11, Patrick McHardy wrote:
> Am 12.11.2010 12:01, schrieb Andrew Watts:
>> --- On Thu, 11/11/10, Patrick McHardy <kaber@trash.net> wrote:
>>
>>> On 11.11.2010 10:01, Andrew Watts wrote:
>>>> Hi.
>>>>
>>>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4
>>>> post is very interesting. NF_CONTINUE would provide the NFQUEUE
>>>> target the added flexibility of, say, partial handling in
>>>> userspace. A queue-handler could have a set of criteria that,
>>>> when satisfied, would result in an immediate drop or accept. One
>>>> could then leave the rest of the packets to find their fate in the
>>>> chains/rules left to traverse. I would be interested in helping
>>>> to add this verdict if someone will take the lead (assuming a patch
>>>> hasn't already been written - has it?).
>>
>>> There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
>>> Queueing happens outside of the ruleset context, so in either case the
>>> packet would continue through the network stack directly, not after
>>> the NFQUEUE rule.
>>
>> I see. Is there a way to achieve this result under the current
>> infrastructure?
> 
> Having the packet continue after the NFQUEUE rule? No, once the packet
> is reinjected, that rule might not even be there anymore.

Actually, what you can do is use NF_REPEAT as verdict and have the
packet continue at the next rule based on marks. Something like this:

Chain INPUT:
-m mark --mark 0 -j NOT_QUEUED
-m mark --mark 1 -j BACK_FROM_QUEUE

Chain NOT_QUEUED:
... rules ...
-j NFQUEUE

[ nfqueue: return NF_REPEAT, set mark = 1 ]

Chain BACK_FROM_QUEUE:
... further rules ...

Re: NFQUEUE verdicts - adding non-termination

[Stig Thormodsrud]

On 11/11/2010 02:50 AM, Patrick McHardy wrote:
> On 11.11.2010 10:01, Andrew Watts wrote:
>> Hi.
>>
>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4 post is very interesting.
>>
>> NF_CONTINUE would provide the NFQUEUE target the added flexibility of, say, partial handling in userspace. A queue-handler could have a set of criteria that, when satisfied, would result in an immediate drop or accept. One could then leave the rest of the packets to find their fate in the chains/rules left to traverse.
>>
>> I would be interested in helping to add this verdict if someone will take the lead (assuming a patch hasn't already been written - has it?).
> 
> There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
> Queueing happens outside of the ruleset context, so in either case the
> packet would continue through the network stack directly, not after
> the NFQUEUE rule.

I've been interested in this thread since I recently converted our
version of snort inline to use NFQUEUE instead of QUEUE.  One of driving
factors was that I needed to have multiple QUEUE targets.  While I was
doing the work I was hoping there was a verdict like NF_RETURN, so that
if it passed the snort inspection then I could have another NFQUEUE
target that would do https domain filtering.  From reading this thread I
now understand why I can just continue, but I wondering what is that the
recommended approach for this type of use case?  As it is now, I think I
would need to have the 2nd NFQUEUE target on a different hook.

stig

Re: NFQUEUE verdicts - adding non-termination

[Andrew Watts]

--- On Fri, 11/12/10, Patrick McHardy <kaber@trash.net> wrote:

> From: Patrick McHardy <kaber@trash.net>
> Subject: Re: NFQUEUE verdicts - adding non-termination
> To: "Andrew Watts" <akwatts@ymail.com>
> Cc: netfilter-devel@vger.kernel.org
> Date: Friday, November 12, 2010, 11:19 AM
> On 12.11.2010 12:11, Patrick McHardy
> wrote:
> > Am 12.11.2010 12:01, schrieb Andrew Watts:
> >> --- On Thu, 11/11/10, Patrick McHardy <kaber@trash.net>
> wrote:
> >>
> >>> On 11.11.2010 10:01, Andrew Watts wrote:
> >>>> Hi.
> >>>>
> >>>> The NF_CONTINUE verdict that Darryl Miles
> brings up in his 11/4
> >>>> post is very interesting. NF_CONTINUE
> would provide the NFQUEUE
> >>>> target the added flexibility of, say,
> partial handling in
> >>>> userspace. A queue-handler could have a
> set of criteria that,
> >>>> when satisfied, would result in an
> immediate drop or accept. One
> >>>> could then leave the rest of the packets
> to find their fate in the
> >>>> chains/rules left to traverse. I would be
> interested in helping
> >>>> to add this verdict if someone will take
> the lead (assuming a patch
> >>>> hasn't already been written - has it?).
> >>
> >>> There's no difference between returning
> NF_ACCEPT or a new NF_CONTINUE.
> >>> Queueing happens outside of the ruleset
> context, so in either case the
> >>> packet would continue through the network
> stack directly, not after
> >>> the NFQUEUE rule.
> >>
> >> I see. Is there a way to achieve this result under
> the current
> >> infrastructure?
> > 
> > Having the packet continue after the NFQUEUE rule? No,
> once the packet
> > is reinjected, that rule might not even be there
> anymore.
> 
> Actually, what you can do is use NF_REPEAT as verdict and
> have the
> packet continue at the next rule based on marks. Something
> like this:
> 
> Chain INPUT:
> -m mark --mark 0 -j NOT_QUEUED
> -m mark --mark 1 -j BACK_FROM_QUEUE
> 
> Chain NOT_QUEUED:
> ... rules ...
> -j NFQUEUE
> 
> [ nfqueue: return NF_REPEAT, set mark = 1 ]
> 
> Chain BACK_FROM_QUEUE:
> ... further rules ...
> 

Yes, that works quite well. If the fork is placed near the
start of the chain, you reduce the amount of redundant
traversing since it seems it goes back to square one.
I initially misunderstood the NF_REPEAT verdict after
looking at the libnetfilter_queue source "NF_REPEAT
iterate the same cycle once more".

~ Andy


      

Re: NFQUEUE verdicts - adding non-termination

[Patrick McHardy]

On 12.11.2010 20:54, Stig Thormodsrud wrote:
> On 11/11/2010 02:50 AM, Patrick McHardy wrote:
>> On 11.11.2010 10:01, Andrew Watts wrote:
>>> Hi.
>>>
>>> The NF_CONTINUE verdict that Darryl Miles brings up in his 11/4 post is very interesting.
>>>
>>> NF_CONTINUE would provide the NFQUEUE target the added flexibility of, say, partial handling in userspace. A queue-handler could have a set of criteria that, when satisfied, would result in an immediate drop or accept. One could then leave the rest of the packets to find their fate in the chains/rules left to traverse.
>>>
>>> I would be interested in helping to add this verdict if someone will take the lead (assuming a patch hasn't already been written - has it?).
>>
>> There's no difference between returning NF_ACCEPT or a new NF_CONTINUE.
>> Queueing happens outside of the ruleset context, so in either case the
>> packet would continue through the network stack directly, not after
>> the NFQUEUE rule.
> 
> I've been interested in this thread since I recently converted our
> version of snort inline to use NFQUEUE instead of QUEUE.  One of driving
> factors was that I needed to have multiple QUEUE targets.  While I was
> doing the work I was hoping there was a verdict like NF_RETURN, so that
> if it passed the snort inspection then I could have another NFQUEUE
> target that would do https domain filtering.  From reading this thread I
> now understand why I can just continue, but I wondering what is that the
> recommended approach for this type of use case?  As it is now, I think I
> would need to have the 2nd NFQUEUE target on a different hook.

Look at my second response to Andrew, you can use NF_REPEAT and some
mark based jumps to do this. You can also return NF_QUEUE from userspace
directly and encode the queue number in the upper 16 bits.

Re: NFQUEUE verdicts - adding non-termination

[Andrew Watts]

--- On Mon, 11/15/10, Patrick McHardy <kaber@trash.net> wrote:

> From: Patrick McHardy <kaber@trash.net>
> Subject: Re: NFQUEUE verdicts - adding non-termination
> To: "Stig Thormodsrud" <stig@vyatta.com>
> Cc: "Andrew Watts" <akwatts@ymail.com>, netfilter-devel@vger.kernel.org
> Date: Monday, November 15, 2010, 10:34 AM
> On 12.11.2010 20:54, Stig Thormodsrud
> wrote:
> > On 11/11/2010 02:50 AM, Patrick McHardy wrote:
> >> On 11.11.2010 10:01, Andrew Watts wrote:
> >>> Hi.
> >>>
> >>> The NF_CONTINUE verdict that Darryl Miles
> brings up in his 11/4 post is very interesting.
> >>>
> >>> NF_CONTINUE would provide the NFQUEUE target
> the added flexibility of, say, partial handling in
> userspace. A queue-handler could have a set of criteria
> that, when satisfied, would result in an immediate drop or
> accept. One could then leave the rest of the packets to find
> their fate in the chains/rules left to traverse.
> >>>
> >>> I would be interested in helping to add this
> verdict if someone will take the lead (assuming a patch
> hasn't already been written - has it?).
> >>
> >> There's no difference between returning NF_ACCEPT
> or a new NF_CONTINUE.
> >> Queueing happens outside of the ruleset context,
> so in either case the
> >> packet would continue through the network stack
> directly, not after
> >> the NFQUEUE rule.
> > 
> > I've been interested in this thread since I recently
> converted our
> > version of snort inline to use NFQUEUE instead of
> QUEUE.  One of driving
> > factors was that I needed to have multiple QUEUE
> targets.  While I was
> > doing the work I was hoping there was a verdict like
> NF_RETURN, so that
> > if it passed the snort inspection then I could have
> another NFQUEUE
> > target that would do https domain filtering. 
> From reading this thread I
> > now understand why I can just continue, but I
> wondering what is that the
> > recommended approach for this type of use case? 
> As it is now, I think I
> > would need to have the 2nd NFQUEUE target on a
> different hook.
> 
> Look at my second response to Andrew, you can use NF_REPEAT
> and some
> mark based jumps to do this. You can also return NF_QUEUE
> from userspace
> directly and encode the queue number in the upper 16 bits.
> 

Patrick, many thanks for the guidance on this. Your
advice was right on.

Stig, something to consider in addition to Patrick's
comment is that you can make the mark-based decision
more complex than just binary. Then a single queue
handler can process according to different mark values
and increment the mark on each return (until a 
termination value is reached).

~ Andy


      
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html