netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* NFQUEUE target with --treat-accept-as-continue?
@ 2012-03-31 14:09 Amm Snort
  2012-04-01 17:51 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 5+ messages in thread
From: Amm Snort @ 2012-03-31 14:09 UTC (permalink / raw)
  To: netfilter-devel@vger.kernel.org

Hello all,

I would like to suggest a feature (additional parameter) for NFQUEUE target.

I am basically trying to use snort with NFQUEUE.

Basic iptables rule is somewhat like this:

iptables -A INPUT -i ppp1 -j NFQUEUE
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

Idea is to pass all packets to snort first and then if snort detects trojan signature then
it can DROP (IPS) the packet (drop rule of snort). If snort detects port scan it can
LOG but still ACCEPT (IDS) (alert rule of snort). If snort ACCEPTs the packet then
continue processing next rule.

On side note, this idea also reduces load on snort as it does not have to sniff every
packet coming on network card and also we can pass only selected packets to snort.


This idea however, DOES NOT work because currently when QUEUE program (snort)
gives verdict as NF_ACCEPT, iptables STOPS processing further rules and
ACCEPTs the packet.

This actually becomes security risk because default snort rules DO NOT DO port blocking.
and ACCEPTs everything that is not EXPLICITLY dropped.

And hence NFQUEUE target indirectly becomes ACCEPT target for all packets and
full system gets exposed.

So my request and suggestion is to add additional parameter to NFQUEUE
say, --treat-accept-as-continue (or rule not matched)


which means, if QUEUE program returns NF_ACCEPT then instead of ACCEPTing
the packet, continue processing next rule. (as if rule did  not match)


I know there is NF_REPEAT, but that will PASS packet through all procesing again
and I will also have to do packet marking etc. Which is more like HACK instead of
sensible approach.

And to use NF_REPEAT I will need to change whole snort code and rules. Which is
impossible.

So please consider my suggestion. As it opens up many other possibilities as well.

Thank you,


PS:
We can also extend this suggesion further with one more parameter as
--treat-accept-as-return which becomes equivalent to RETURN target.

This way NF_QUEUE target becomes a place holder for ACCEPT, DROP,
RETURN, CONTINUE (rule not matched). This can have lots of possible use
with wide flexibility.

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NFQUEUE target with --treat-accept-as-continue?
  2012-03-31 14:09 NFQUEUE target with --treat-accept-as-continue? Amm Snort
@ 2012-04-01 17:51 ` Pablo Neira Ayuso
  2012-04-02  3:11   ` Amm Snort
  0 siblings, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2012-04-01 17:51 UTC (permalink / raw)
  To: Amm Snort; +Cc: netfilter-devel@vger.kernel.org

On Sat, Mar 31, 2012 at 10:09:42PM +0800, Amm Snort wrote:
> Hello all,
> 
> I would like to suggest a feature (additional parameter) for NFQUEUE target.
> 
> I am basically trying to use snort with NFQUEUE.
> 
> Basic iptables rule is somewhat like this:
> 
> iptables -A INPUT -i ppp1 -j NFQUEUE
> iptables -A INPUT -p tcp --dport 22 -j ACCEPT
> iptables -A INPUT -j DROP
> 
> Idea is to pass all packets to snort first and then if snort detects trojan signature then
> it can DROP (IPS) the packet (drop rule of snort). If snort detects port scan it can
> LOG but still ACCEPT (IDS) (alert rule of snort). If snort ACCEPTs the packet then
> continue processing next rule.
> 
> On side note, this idea also reduces load on snort as it does not have to sniff every
> packet coming on network card and also we can pass only selected packets to snort.
> 
> 
> This idea however, DOES NOT work because currently when QUEUE program (snort)
> gives verdict as NF_ACCEPT, iptables STOPS processing further rules and
> ACCEPTs the packet.
> 
> This actually becomes security risk because default snort rules DO NOT DO port blocking.
> and ACCEPTs everything that is not EXPLICITLY dropped.
> 
> And hence NFQUEUE target indirectly becomes ACCEPT target for all packets and
> full system gets exposed.
> 
> So my request and suggestion is to add additional parameter to NFQUEUE
> say, --treat-accept-as-continue (or rule not matched)
> 
> 
> which means, if QUEUE program returns NF_ACCEPT then instead of ACCEPTing
> the packet, continue processing next rule. (as if rule did  not match)
> 
> 
> I know there is NF_REPEAT, but that will PASS packet through all procesing again
> and I will also have to do packet marking etc. Which is more like HACK instead of
> sensible approach.
> 
> And to use NF_REPEAT I will need to change whole snort code and rules. Which is
> impossible.
>
> So please consider my suggestion. As it opens up many other possibilities as well.

That will not be straight forward to implement. The existing code does
not provide a way to resume packet filtering just after the rule that
enqueued the packet to user-space.

[...]
> PS:
> We can also extend this suggesion further with one more parameter as
> --treat-accept-as-return which becomes equivalent to RETURN target.

Same thing with RETURN.
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NFQUEUE target with --treat-accept-as-continue?
  2012-04-01 17:51 ` Pablo Neira Ayuso
@ 2012-04-02  3:11   ` Amm Snort
  2012-04-02  9:13     ` Pablo Neira Ayuso
  2012-04-03 12:25     ` Jan Engelhardt
  0 siblings, 2 replies; 5+ messages in thread
From: Amm Snort @ 2012-04-02  3:11 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel@vger.kernel.org





----- Original Message -----
> From: Pablo Neira Ayuso <pablo@netfilter.org>

>>  So my request and suggestion is to add additional parameter to NFQUEUE
>>  say, --treat-accept-as-continue (or rule not matched)
>> 
>> 
>>  which means, if QUEUE program returns NF_ACCEPT then instead of ACCEPTing
>>  the packet, continue processing next rule. (as if rule did  not match)


> 
> That will not be straight forward to implement. The existing code does
> not provide a way to resume packet filtering just after the rule that
> enqueued the packet to user-space.

Umm. so how does NFLOG (libnetfilter_log) do it?

From man page: (for NFLOG)
    Like LOG, this is  a  non-terminating  target, i.e. rule traversal continues at the next rule.

If I am not wrong, NFLOG and NFQUEUE are much similar. If NFLOG can allow to continue to
next rule, may be NFQUEUE can, as well.

We already have --queue-bypass option which bypasses to next rule of QUEUE is not present.
May be we can have modification to code, which bypasses when NF_ACCEPT is received from
userspace.

Just a suggestion, I am not sure if this would need changes at kernel level.

Thanks
AMM

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NFQUEUE target with --treat-accept-as-continue?
  2012-04-02  3:11   ` Amm Snort
@ 2012-04-02  9:13     ` Pablo Neira Ayuso
  2012-04-03 12:25     ` Jan Engelhardt
  1 sibling, 0 replies; 5+ messages in thread
From: Pablo Neira Ayuso @ 2012-04-02  9:13 UTC (permalink / raw)
  To: Amm Snort; +Cc: netfilter-devel@vger.kernel.org

On Mon, Apr 02, 2012 at 11:11:34AM +0800, Amm Snort wrote:
> ----- Original Message -----
> > From: Pablo Neira Ayuso <pablo@netfilter.org>
> 
> >>  So my request and suggestion is to add additional parameter to NFQUEUE
> >>  say, --treat-accept-as-continue (or rule not matched)
> >> 
> >> 
> >>  which means, if QUEUE program returns NF_ACCEPT then instead of ACCEPTing
> >>  the packet, continue processing next rule. (as if rule did  not match)
> 
> 
> > 
> > That will not be straight forward to implement. The existing code does
> > not provide a way to resume packet filtering just after the rule that
> > enqueued the packet to user-space.
> 
> Umm. so how does NFLOG (libnetfilter_log) do it?
> 
> From man page: (for NFLOG)
>     Like LOG, this is  a  non-terminating  target, i.e. rule traversal continues at the next rule.
> 
> If I am not wrong, NFLOG and NFQUEUE are much similar. If NFLOG can allow to continue to
> next rule, may be NFQUEUE can, as well.

NFLOG delivers the log using netlink multicast and it doesn't wait
for user-space to issue any verdict on the log message.

> We already have --queue-bypass option which bypasses to next rule of QUEUE is not present.
> May be we can have modification to code, which bypasses when NF_ACCEPT is received from
> userspace.

I know, but that's a completely different situation.

> Just a suggestion, I am not sure if this would need changes at kernel level.

As said, this is not straight forward. Look at the code at you'll see
why I'm telling you this.
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: NFQUEUE target with --treat-accept-as-continue?
  2012-04-02  3:11   ` Amm Snort
  2012-04-02  9:13     ` Pablo Neira Ayuso
@ 2012-04-03 12:25     ` Jan Engelhardt
  1 sibling, 0 replies; 5+ messages in thread
From: Jan Engelhardt @ 2012-04-03 12:25 UTC (permalink / raw)
  To: Amm Snort; +Cc: Pablo Neira Ayuso, netfilter-devel@vger.kernel.org


On Monday 2012-04-02 05:11, Amm Snort wrote:
>
>>From man page: (for NFLOG)
>
>    Like LOG, this is  a  non-terminating  target, i.e. rule
>traversal continues at the next rule.

Traversal continues after a copy of the packet has been queued
for userspace. It does not mean traversal continues after
userspace has rendered a verdict.
--
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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-04-03 12:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-31 14:09 NFQUEUE target with --treat-accept-as-continue? Amm Snort
2012-04-01 17:51 ` Pablo Neira Ayuso
2012-04-02  3:11   ` Amm Snort
2012-04-02  9:13     ` Pablo Neira Ayuso
2012-04-03 12:25     ` Jan Engelhardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).