Can NFQUEUE accept/continue when there is no userspace listener registered ?

Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Darryl Miles]

Hi,

Is there any mechanism which would allow additional options to NFQUEUE 
target to instruct the kernel what to do:

  --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being 
the default)
  --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP 
being the default)

Where CONTINUE would in effect ignore the existence of the "-j NFQUEUE" 
rule in the chain and continue to the next rule.  I guess this is 
possible if the packet never made it to user-space.


Would there be any objections to providing a patch to kernel and 
userspace tooling to provide this configurable behavior ?   Is it 
obviously useful to others ?


I am writing a non-critical userspace tool to fire Wake-on-LAN magic 
packets, if incoming TCP SYN "-p tcp --syn" is matched (and presumably 
forwarded).  The SYN packet is always allowed to pass but the userspace 
tools then goes into monitoring mode in the period after each SYN 
packet, it looks for either a valid IPv4 or IPv6 neighbour entry 
(/sbin/ip neigh) and/or Echo Reply.  As well as periodically monitoring 
the last known MAC address for each destination IP/IP6 to auto-learn.

This is not a critical application, I am looking for a minimal CPU 
overhead on the router and a best-effort service.  It should never be 
the cause of a failure (to connect i.e. pass SYN packets) should it 
crash / not be running.


Your comments appreciated,

Darryl

Re: Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Patrick McHardy]

On 04.11.2010 04:52, Darryl Miles wrote:
> Is there any mechanism which would allow additional options to NFQUEUE
> target to instruct the kernel what to do:
> 
>  --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being
> the default)
>  --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP
> being the default)

--action-no-listener is hard to do because the rule has no direct
connection to the queue and backend queueing mechanism and thus
it can't determine whether a listener exists. There's also currently
no way to propagate that information to the backend. Well, maybe
you could encode it in the verdict, similar to the queue number.

--action-backlog-overflow should be pretty easy to add to the
queueing backend itself (nfnetlink_queue), however when the packet
reaches the backend, it has already left the ruleset, so it won't
continue in the chain but instead continue as if a verdict of
NF_ACCEPT had been issued.

> Where CONTINUE would in effect ignore the existence of the "-j NFQUEUE"
> rule in the chain and continue to the next rule.  I guess this is
> possible if the packet never made it to user-space.
> 
> 
> Would there be any objections to providing a patch to kernel and
> userspace tooling to provide this configurable behavior ?   Is it
> obviously useful to others ?

Having the packet continue when the queue overflows has been requested
a couple of times for hung snort processes, so yes, this sounds useful.
If you can implement the no-listener feature in a reasonable way that
also sounds useful.

Re: Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Pablo Neira Ayuso]

On 04/11/10 05:37, Patrick McHardy wrote:
> On 04.11.2010 04:52, Darryl Miles wrote:
>> Is there any mechanism which would allow additional options to NFQUEUE
>> target to instruct the kernel what to do:
>>
>>   --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being
>> the default)
>>   --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP
>> being the default)
>
> --action-no-listener is hard to do because the rule has no direct
> connection to the queue and backend queueing mechanism and thus
> it can't determine whether a listener exists. There's also currently
> no way to propagate that information to the backend. Well, maybe
> you could encode it in the verdict, similar to the queue number.
>
> --action-backlog-overflow should be pretty easy to add to the
> queueing backend itself (nfnetlink_queue), however when the packet
> reaches the backend, it has already left the ruleset, so it won't
> continue in the chain but instead continue as if a verdict of
> NF_ACCEPT had been issued.

We can add two new netlink attributes like:

* NFQA_CFG_NO_LISTENER_VERDICT
* NFQA_CFG_OVERFLOW_VERDICT

These can be used to send messages from user-space to configure the 
instance, these will remain per-process parameters. It's similar to what 
we do with NFQA_CFG_QUEUE_MAXLEN.

Re: Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Patrick McHardy]

On 05.11.2010 01:08, Pablo Neira Ayuso wrote:
> On 04/11/10 05:37, Patrick McHardy wrote:
>> On 04.11.2010 04:52, Darryl Miles wrote:
>>> Is there any mechanism which would allow additional options to NFQUEUE
>>> target to instruct the kernel what to do:
>>>
>>>   --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being
>>> the default)
>>>   --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP
>>> being the default)
>>
>> --action-no-listener is hard to do because the rule has no direct
>> connection to the queue and backend queueing mechanism and thus
>> it can't determine whether a listener exists. There's also currently
>> no way to propagate that information to the backend. Well, maybe
>> you could encode it in the verdict, similar to the queue number.
>>
>> --action-backlog-overflow should be pretty easy to add to the
>> queueing backend itself (nfnetlink_queue), however when the packet
>> reaches the backend, it has already left the ruleset, so it won't
>> continue in the chain but instead continue as if a verdict of
>> NF_ACCEPT had been issued.
> 
> We can add two new netlink attributes like:
> 
> * NFQA_CFG_NO_LISTENER_VERDICT
> * NFQA_CFG_OVERFLOW_VERDICT
> 
> These can be used to send messages from user-space to configure the
> instance, these will remain per-process parameters. It's similar to what
> we do with NFQA_CFG_QUEUE_MAXLEN.

Well, no listener can't be configured in nfnetlink_queue since the
instance goes away with the listener :) That's why I was saying that
this information needs to be included in the NF_QUEUE verdict.

Re: Can NFQUEUE accept/continue when there is no userspace listener registered ?

[Pablo Neira Ayuso]

On 05/11/10 10:29, Patrick McHardy wrote:
> On 05.11.2010 01:08, Pablo Neira Ayuso wrote:
>> On 04/11/10 05:37, Patrick McHardy wrote:
>>> On 04.11.2010 04:52, Darryl Miles wrote:
>>>> Is there any mechanism which would allow additional options to NFQUEUE
>>>> target to instruct the kernel what to do:
>>>>
>>>>   --action-no-listener NF_ACCEPT|NF_DROP|CONTINUE  (with NF_DROP being
>>>> the default)
>>>>   --action-backlog-overflow NF_ACCEPT|NF_DROP|CONTINUE   (with NF_DROP
>>>> being the default)
>>>
>>> --action-no-listener is hard to do because the rule has no direct
>>> connection to the queue and backend queueing mechanism and thus
>>> it can't determine whether a listener exists. There's also currently
>>> no way to propagate that information to the backend. Well, maybe
>>> you could encode it in the verdict, similar to the queue number.
>>>
>>> --action-backlog-overflow should be pretty easy to add to the
>>> queueing backend itself (nfnetlink_queue), however when the packet
>>> reaches the backend, it has already left the ruleset, so it won't
>>> continue in the chain but instead continue as if a verdict of
>>> NF_ACCEPT had been issued.
>>
>> We can add two new netlink attributes like:
>>
>> * NFQA_CFG_NO_LISTENER_VERDICT
>> * NFQA_CFG_OVERFLOW_VERDICT
>>
>> These can be used to send messages from user-space to configure the
>> instance, these will remain per-process parameters. It's similar to what
>> we do with NFQA_CFG_QUEUE_MAXLEN.
> 
> Well, no listener can't be configured in nfnetlink_queue since the
> instance goes away with the listener :)

Oh, I forgot that this is a chicken-egg problem :-(.

> That's why I was saying that
> this information needs to be included in the NF_QUEUE verdict.

Indeed, that seems to me the good choice :-).