Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,


On Mar 9 2007 11:54, Amin Azez wrote:
>> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
>> would increase the struct sizes, and that would penalize users who do
>> not intend to use xt_portscan.
>
>I understand what you say but it sounds a bit like saying: "but we didn't
>make it very good because so few people would use it anyway" which of
>course makes it even less attractive. I realise you have your own
>interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

>> I do not see why the packet/connection marks should not be used to record
>> additional information
>...
>> Almost never I required connection marking myself 
>I guessed as much. I use it heavily, with my xml rule generators.
>> except for this
>> portscanning automaton and perhaps a little MARK here and there for
>> finely-tuned SNAT. Again, things might look different on your side(s).
>
>There's too many things fighting over the same few bits of the mark, and
>in your case you are using it to track internal state of a connection
>that has no relevance to the rest of the iptables/ebtables rules.
>
>I'm suggesting that some of the people who would want to use the chaos
>match, won't because of the mark issue.
>
>This is not a new problem.
>
>http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

"""netfilter marks are the solution of last resort. This is
becoming very painful for those of us who produce general
Netfilter configuration tools.""" -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Petr Tesařík]

jimmy píše v Pá 09. 03. 2007 v 13:37 +0530:
> Alan Cox wrote:
> >> Also note that the word 'chaostables' does not even appear in the patch, 
> >> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
> >> can safely assume that CHAOS does what it says - make fun of nmap.
> > 
> > "entropy" ?
> > "randomness"
> 
> fuzztables?

confuztables!

Petr


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 09/03/07 10:19:
> Hello,
>
> On Mar 9 2007 09:35, Amin Azez wrote:
>   
>> * Jan Engelhardt wrote, On 08/03/07 20:26:
>> 
>>> xt_portscan needs to keep track of what packets the machine has already 
>>> seen. So on the first SYN, the connection is marked with "1". (Then we 
>>> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
>>> packet that is received will be an ACK or an RST. But it must come 
>>> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
>>> state which can be remembered is required. For that, an automaton is 
>>> used, whose state is saved in the connection mark.
>>>   
>> There would me more point in having this as a new match if it didn't
>> trample on the connection mark, but used it's own slot or flag-bit.
>> 
For the record, I support inclusion of this extension in general.
It is true to say "but a netfilter guru could craft together a sequence
of mark-consuming rules to do something somewhat similar" the same is
also somewhat true for connlimit (packet limits) and so on. The point of
this match is that people don't have to.
> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
> increase the struct sizes, and that would penalize users who do not intend
> to use xt_portscan.
>   
I understand what you say but it sounds a bit like saying: "but we
didn't make it very good because so few people would use it anyway"
which of course makes it even less attractive. I realise you have your
own interpretation but this is how it reads to me.
> I do not see why the packet/connection marks should not be used to record
> additional information
...
> Almost never I required connection marking myself 
I guessed as much. I use it heavily, with my xml rule generators.
> except for this
> portscanning automaton and perhaps a little MARK here and there for
> finely-tuned SNAT. Again, things might look different on your side(s).
>   
There's too many things fighting over the same few bits of the mark, and
in your case you are using it to track internal state of a connection
that has no relevance to the rest of the iptables/ebtables rules.

I'm suggesting that some of the people who would want to use the chaos
match, won't because of the mark issue.

This is not a new problem.

http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217
> From: Tom Eastep  shorewall.net>
> Subject: Re: RFC: Disable defered bridge hooks by default


>
> Once again, netfilter marks are the solution of last resort. This is
> becoming very painful for those of us who produce general Netfilter
> configuration tools. The situation is exacerbated by the fact that
> ebtables doesn't support modifying the mark value via logical AND/OR and
> the other fwmark consumers (tc, ip) don't allow a mask when testing the
> fwmark value.

I suggested one solution
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16244

and Patrick McHardy has suggested using ct_extend.

I've not looked into this further because I'm too busy doing xml
versions of iptables, ebtables, iproute anc tc.

[There's an ip route<->xml at:
http://mailman.ds9a.nl/pipermail/lartc/2007q1/020376.html
iptables now has xml<-> convertor ]

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Mar 9 2007 09:35, Amin Azez wrote:
>* Jan Engelhardt wrote, On 08/03/07 20:26:
>> xt_portscan needs to keep track of what packets the machine has already 
>> seen. So on the first SYN, the connection is marked with "1". (Then we 
>> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
>> packet that is received will be an ACK or an RST. But it must come 
>> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
>> state which can be remembered is required. For that, an automaton is 
>> used, whose state is saved in the connection mark.
>
>There would me more point in having this as a new match if it didn't
>trample on the connection mark, but used it's own slot or flag-bit.

Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
increase the struct sizes, and that would penalize users who do not intend
to use xt_portscan.

I do not see why the packet/connection marks should not be used to record
additional information. After all, that is what users use marks for.
xt_portscan can be precisely configured how to set its marks (mask is
supported), so that it only takes away 4 bits of the 32-bit connection
mark and 1 bit of the 32-bit packet mark.

Almost never I required connection marking myself except for this
portscanning automaton and perhaps a little MARK here and there for
finely-tuned SNAT. Again, things might look different on your side(s).
QoS, while primarily using CLASSIFY, is one point where MARK can be used.
I would assume that those who use xt_portscan should be fine with the
remaining 24 bits.


Thank you,

Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 08/03/07 20:26:
> xt_portscan needs to keep track of what packets the machine has already 
> seen. So on the first SYN, the connection is marked with "1". (Then we 
> send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
> packet that is received will be an ACK or an RST. But it must come 
> _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
> state which can be remembered is required. For that, an automaton is 
> used, whose state is saved in the connection mark.

There would me more point in having this as a new match if it didn't
trample on the connection mark, but used it's own slot or flag-bit.

Sam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[jimmy]

Alan Cox wrote:
Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


"entropy" ?
"randomness"


fuzztables?

:-)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[jimmy]

Alan Cox wrote:
Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


entropy ?
randomness


fuzztables?

:-)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 08/03/07 20:26:
 xt_portscan needs to keep track of what packets the machine has already 
 seen. So on the first SYN, the connection is marked with 1. (Then we 
 send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
 packet that is received will be an ACK or an RST. But it must come 
 _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
 state which can be remembered is required. For that, an automaton is 
 used, whose state is saved in the connection mark.

There would me more point in having this as a new match if it didn't
trample on the connection mark, but used it's own slot or flag-bit.

Sam

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Mar 9 2007 09:35, Amin Azez wrote:
* Jan Engelhardt wrote, On 08/03/07 20:26:
 xt_portscan needs to keep track of what packets the machine has already 
 seen. So on the first SYN, the connection is marked with 1. (Then we 
 send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
 packet that is received will be an ACK or an RST. But it must come 
 _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
 state which can be remembered is required. For that, an automaton is 
 used, whose state is saved in the connection mark.

There would me more point in having this as a new match if it didn't
trample on the connection mark, but used it's own slot or flag-bit.

Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
increase the struct sizes, and that would penalize users who do not intend
to use xt_portscan.

I do not see why the packet/connection marks should not be used to record
additional information. After all, that is what users use marks for.
xt_portscan can be precisely configured how to set its marks (mask is
supported), so that it only takes away 4 bits of the 32-bit connection
mark and 1 bit of the 32-bit packet mark.

Almost never I required connection marking myself except for this
portscanning automaton and perhaps a little MARK here and there for
finely-tuned SNAT. Again, things might look different on your side(s).
QoS, while primarily using CLASSIFY, is one point where MARK can be used.
I would assume that those who use xt_portscan should be fine with the
remaining 24 bits.


Thank you,

Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Amin Azez]

* Jan Engelhardt wrote, On 09/03/07 10:19:
 Hello,

 On Mar 9 2007 09:35, Amin Azez wrote:
   
 * Jan Engelhardt wrote, On 08/03/07 20:26:
 
 xt_portscan needs to keep track of what packets the machine has already 
 seen. So on the first SYN, the connection is marked with 1. (Then we 
 send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
 packet that is received will be an ACK or an RST. But it must come 
 _exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
 state which can be remembered is required. For that, an automaton is 
 used, whose state is saved in the connection mark.
   
 There would me more point in having this as a new match if it didn't
 trample on the connection mark, but used it's own slot or flag-bit.
 
For the record, I support inclusion of this extension in general.
It is true to say but a netfilter guru could craft together a sequence
of mark-consuming rules to do something somewhat similar the same is
also somewhat true for connlimit (packet limits) and so on. The point of
this match is that people don't have to.
 Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct would
 increase the struct sizes, and that would penalize users who do not intend
 to use xt_portscan.
   
I understand what you say but it sounds a bit like saying: but we
didn't make it very good because so few people would use it anyway
which of course makes it even less attractive. I realise you have your
own interpretation but this is how it reads to me.
 I do not see why the packet/connection marks should not be used to record
 additional information
...
 Almost never I required connection marking myself 
I guessed as much. I use it heavily, with my xml rule generators.
 except for this
 portscanning automaton and perhaps a little MARK here and there for
 finely-tuned SNAT. Again, things might look different on your side(s).
   
There's too many things fighting over the same few bits of the mark, and
in your case you are using it to track internal state of a connection
that has no relevance to the rest of the iptables/ebtables rules.

I'm suggesting that some of the people who would want to use the chaos
match, won't because of the mark issue.

This is not a new problem.

http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217
 From: Tom Eastep teastep at shorewall.net
 Subject: Re: RFC: Disable defered bridge hooks by default
http://news.gmane.org/find-root.php?message_id=%3c44AEFE20.3020307%40shorewall.net%3e


 Once again, netfilter marks are the solution of last resort. This is
 becoming very painful for those of us who produce general Netfilter
 configuration tools. The situation is exacerbated by the fact that
 ebtables doesn't support modifying the mark value via logical AND/OR and
 the other fwmark consumers (tc, ip) don't allow a mask when testing the
 fwmark value.

I suggested one solution
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16244

and Patrick McHardy has suggested using ct_extend.

I've not looked into this further because I'm too busy doing xml
versions of iptables, ebtables, iproute anc tc.

[There's an ip route-xml at:
http://mailman.ds9a.nl/pipermail/lartc/2007q1/020376.html
iptables now has xml- convertor ]

Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Petr Tesařík]

jimmy píše v Pá 09. 03. 2007 v 13:37 +0530:
 Alan Cox wrote:
  Also note that the word 'chaostables' does not even appear in the patch, 
  though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
  can safely assume that CHAOS does what it says - make fun of nmap.
  
  entropy ?
  randomness
 
 fuzztables?

confuztables!

Petr


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,


On Mar 9 2007 11:54, Amin Azez wrote:
 Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
 would increase the struct sizes, and that would penalize users who do
 not intend to use xt_portscan.

I understand what you say but it sounds a bit like saying: but we didn't
make it very good because so few people would use it anyway which of
course makes it even less attractive. I realise you have your own
interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

 I do not see why the packet/connection marks should not be used to record
 additional information
...
 Almost never I required connection marking myself 
I guessed as much. I use it heavily, with my xml rule generators.
 except for this
 portscanning automaton and perhaps a little MARK here and there for
 finely-tuned SNAT. Again, things might look different on your side(s).

There's too many things fighting over the same few bits of the mark, and
in your case you are using it to track internal state of a connection
that has no relevance to the rest of the iptables/ebtables rules.

I'm suggesting that some of the people who would want to use the chaos
match, won't because of the mark issue.

This is not a new problem.

http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

netfilter marks are the solution of last resort. This is
becoming very painful for those of us who produce general
Netfilter configuration tools. -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Thu, 08 Mar 2007 18:15:12 +0100, Patrick McHardy wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+   /* Equivalent to:
+* -A chaos -m statistic --mode random --probability \
+* $reject_percentage -j REJECT --reject-with host-unreach;
+* -A chaos -m statistic --mode random --probability \
+* $delude_percentage -j DELUDE;
[2nd one should have had -p tcp]
+* -A chaos -j DROP;
+*/
>>>
>>>What does this do that can't be done by simply adding those individual 
>>>rules?
>>
>>It "wraps it all up", reducing the overall number of rules and user 
>>chains required in the filtering tables to implement the wanted logic. 
>>Reducing the number of filtering rules also reduces the time process a 
>>packet. These two are, in my opinion, a good thing.
>
>By that argument we could just codify every ruleset and put it in the
>kernel. Its three simple rules. There is no chance I'm going to take
>this part.

While that is indeed true, I think users will have a judgement (perhaps 
call it "first impression") that puts a certain set of NF rules into 
either of the two categories "this is fundamental/generic enough to 
warrant its own module" and "this does not". While

  -A INPUT -s 134.76.0.0/16 -p tcp --dport 22 -j ACCEPT;
  -A INPUT -p tcp --dport 80 -j ACCEPT;
  -A INPUT -j REJECT;

is clearly something that only applies to one machine only, perhaps a
little subnet, or at best, the servers on the company network, it is not
"for everyone". xt_CHAOS on the other hand was meant - if you want so - as
a replacement for DROP/REJECT and the default policy, e.g.:

# Block all evil, even if from inside the house.
-A INPUT -m evil -j CHAOS;
# Ignore stray packets not directed at us
-A INPUT -d mybase -m this -j ACCEPT;
# Management console
-A INPUT -s yourbase -m that -j ACCEPT;
# Chain policy (instead, or supplemental to, -P INPUT DROP)
-A INPUT -j CHAOS;

(-m evil, -m this and -m that are placeholders and are not seriously
considered to get their own kernel module anytime.)

For me, this falls under generic-enough, but your (and other people's) mileage
migt vary.


Thank you for the comments,

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

On Mar 8 2007 18:15, Patrick McHardy wrote:
>
>> Take xt_portscan as an example, which would require a minimum of 23 
>> filtering rules (which cannot reproduce the module's action in its 
>> fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
>> a single packet, repeatedly checking for "-p tcp", i.e. calling into 
>> xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
>> are never examined in xt_portscan.
>
>
>I'm guessing xt_portscan tries to detect and match on portscans, but
>its not obvious why it looks at and changes skb->mark and nfct->ctmark,
>so I suggest you start by explaining what it really does.

xt_portscan needs to keep track of what packets the machine has already 
seen. So on the first SYN, the connection is marked with "1". (Then we 
send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
packet that is received will be an ACK or an RST. But it must come 
_exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
state which can be remembered is required. For that, an automaton is 
used, whose state is saved in the connection mark.

If you would like to find out more about the implementation, please have 
a look at http://jengelh.hopto.org/p/chaostables/fw.html section 3, 4, 
and perhaps 5.

As for the packet mark, refer to section 6. But for you: xt_portscan 
consists of "two" parts, one is "detect-and-mark" and the other is 
"match it". To have the following do the right thing

  -m portscan --cnscan  -j LOG --log-prefix "[evil user] "
  -m portscan --stealth -j LOG --log-prefix "[hideous evil user] "

the "detect-and-mark" code _must_ (in its common RFC meaning) only be 
executed once per packet.


>>>We already have the psd match for years, but decided against merging it.
>> 
>> On what basis? As far as I flew over psd's code, it uses a heuristic 
>> like "how often did that client recently connect" for match decision. 
>> (P2P clients randomly port knocking, anyone?) I would not think of that 
>> as a reliable way to tell portscans either. However, half-open TCP 
>> connect for example is a more clear action to define a portscan.
>
>The question is what we gain by being able to detect portscans.

You have a point with that. But then we could argue on hours about what 
we gain with life.

>So far my opinion is thats its close to nothing. Besides that,
>it should be possible to do this by using the recent match.

Perhaps. I'll just provide this little example of what is good for to 
check for portscans:

  -N block_it
  -A block_it -m recent --name block_it --update --seconds 60;

  -A INPUT -m portscan --cnscan -j block_it;
  -A INPUT -m recent --name block_it --rcheck -j DROP;

that is, to drop everything from evil hosts doing half-open scans for 
some time.

[ Ok, I used "recent", now I don't get what you meant by "Besides that,
  it should be possible to do this by using the recent match." -
  recent alone does not check for half-opens, nor connect-scans. It 
  checks for recentness of anything. I hope you can clarify. ]



Thank you,
Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:
>>>Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>>>+/* Equivalent to:
>>>+ * -A chaos -m statistic --mode random --probability \
>>>+ * $reject_percentage -j REJECT --reject-with host-unreach;
>>>+ * -A chaos -m statistic --mode random --probability \
>>>+ * $delude_percentage -j DELUDE;
>>>+ * -A chaos -j DROP;
>>>+ */
>>
>>What does this do that can't be done by simply adding those individual 
>>rules?
> 
> 
> It "wraps it all up", reducing the overall number of rules and user 
> chains required in the filtering tables to implement the wanted logic. 
> Reducing the number of filtering rules also reduces the time process a 
> packet. These two are, in my opinion, a good thing.


By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

> Take xt_portscan as an example, which would require a minimum of 23 
> filtering rules (which cannot reproduce the module's action in its 
> fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
> a single packet, repeatedly checking for "-p tcp", i.e. calling into 
> xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
> are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb->mark and nfct->ctmark,
so I suggest you start by explaining what it really does.

>>>+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>>
>>Looks like a copy of the REJECT target. What does it do,
>>why can't you use REJECT?
> 
> 
> Looking only at TCP,
> REJECT sends a RST for any packet (if requested), or ICMP otherwise.
> DELUDE sends a SYN-ACK on SYN, otherwise RST.
> (And TARPIT, for reference, keeps the connection open anytime. Its code
> is also quite a replication of REJECT.)
> 
> If you think it is better to merge the respond-with-SYNACK into REJECT 
> rather than having DELUDE, say so.


I'd rather not add hacks to mildly annoy people anywhere.

>>We already have the psd match for years, but decided against merging it.
> 
> 
> On what basis? As far as I flew over psd's code, it uses a heuristic 
> like "how often did that client recently connect" for match decision. 
> (P2P clients randomly port knocking, anyone?) I would not think of that 
> as a reliable way to tell portscans either. However, half-open TCP 
> connect for example is a more clear action to define a portscan.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Alan Cox]

> Also note that the word 'chaostables' does not even appear in the patch, 
> though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
> can safely assume that CHAOS does what it says - make fun of nmap.

"entropy" ?
"randomness"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

(I suspect a mailserver issue on my side, since I did not receive the 
replies from Alan or Patrick. But lkml.org has them, so I will be 
replying to both them there.)

On Mar 8 2007 09:55, James Morris wrote:
>On Thu, 8 Mar 2007, Alan Cox wrote:
>
>> Any chance of tweaking the name - it's just there is/was a chaosnet 
>> protocol/network system and you don't want people to assume that 
>> since its a chaosfilter its for chaosnet ?
>
>That's exactly what I thought it was from the subject line.

Suggest something. (And then convince everyone who already set 
chaostables in stone to use the new name, namely search engines, 
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet 
nowadays. And just because there is a "quicktables" project does not 
mean there is a quick protocol filter.

Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
>> @@ -0,0 +1,184 @@
>> +
>> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
>> +const struct net_device *in, const struct net_device *out,
>> +unsigned int hooknum, const struct xt_target *target, const void 
>> *targinfo)
>> +{
>> +/* Equivalent to:
>> + * -A chaos -m statistic --mode random --probability \
>> + * $reject_percentage -j REJECT --reject-with host-unreach;
>> + * -A chaos -m statistic --mode random --probability \
>> + * $delude_percentage -j DELUDE;
>> + * -A chaos -j DROP;
>> + */
>
>What does this do that can't be done by simply adding those individual 
>rules?

It "wraps it all up", reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

Take xt_portscan as an example, which would require a minimum of 23 
filtering rules (which cannot reproduce the module's action in its 
fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
a single packet, repeatedly checking for "-p tcp", i.e. calling into 
xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
are never examined in xt_portscan.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
>
>Looks like a copy of the REJECT target. What does it do,
>why can't you use REJECT?

Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)

If you think it is better to merge the respond-with-SYNACK into REJECT 
rather than having DELUDE, say so.


>> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>> ===
>> --- /dev/null
>> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c
>
>We already have the psd match for years, but decided against merging it.

On what basis? As far as I flew over psd's code, it uses a heuristic 
like "how often did that client recently connect" for match decision. 
(P2P clients randomly port knocking, anyone?) I would not think of that 
as a reliable way to tell portscans either. However, half-open TCP 
connect for example is a more clear action to define a portscan.



Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[James Morris]

On Thu, 8 Mar 2007, Alan Cox wrote:

> Any chance of tweaking the name - it's just there is/was a chaosnet
> protocol/network system and you don't want people to assume that since
> its a chaosfilter its for chaosnet  ?

That's exactly what I thought it was from the subject line.


- James
-- 
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:

> Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> ===
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
> @@ -0,0 +1,184 @@
> +
> +static unsigned int xt_chaos_target(struct sk_buff **pskb,
> +const struct net_device *in, const struct net_device *out,
> +unsigned int hooknum, const struct xt_target *target, const void 
> *targinfo)
> +{
> + /* Equivalent to:
> +  * -A chaos -m statistic --mode random --probability \
> +  * $reject_percentage -j REJECT --reject-with host-unreach;
> +  * -A chaos -m statistic --mode random --probability \
> +  * $delude_percentage -j DELUDE;
> +  * -A chaos -j DROP;
> +  */

What does this do that can't be done by simply adding those individual
rules?

> + const struct xt_chaos_info *info = targinfo;
> +
> + if((unsigned int)net_random() <= reject_percentage)
> + return xt_reject->target(pskb, in, out, hooknum, target,
> +_params);
> +
> + /* TARPIT/DELUDE may not be called from the OUTPUT chain */
> + if((*pskb)->nh.iph->protocol == IPPROTO_TCP &&
> +   info->variant != XTCHAOS_NORMAL && hooknum != NF_IP_LOCAL_OUT)
> + xt_chaos_total(info, pskb, in, out, hooknum);
> +
> + return NF_DROP;
> +}


> Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
> ===
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?

> Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
> ===
> --- /dev/null
> +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c

We already have the psd match for years, but decided against merging
it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Alan Cox]

On Thu, 8 Mar 2007 07:35:05 +0100 (MET)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> Hello netfilter-devel,
> 
> 
> I would like to submit chaostables (v0.5_svn23) for inclusion. Primary 
> use is to detect, spoof and slowdown various sorts of port scans.
> Implementation details can be found at http://jengelh.hopto.org/p/chaostables/


Any chance of tweaking the name - it's just there is/was a chaosnet
protocol/network system and you don't want people to assume that since
its a chaosfilter its for chaosnet  ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

(I suspect a mailserver issue on my side, since I did not receive the 
replies from Alan or Patrick. But lkml.org has them, so I will be 
replying to both them there.)

On Mar 8 2007 09:55, James Morris wrote:
On Thu, 8 Mar 2007, Alan Cox wrote:

 Any chance of tweaking the name - it's just there is/was a chaosnet 
 protocol/network system and you don't want people to assume that 
 since its a chaosfilter its for chaosnet ?

That's exactly what I thought it was from the subject line.

Suggest something. (And then convince everyone who already set 
chaostables in stone to use the new name, namely search engines, 
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet 
nowadays. And just because there is a quicktables project does not 
mean there is a quick protocol filter.

Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


 Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 @@ -0,0 +1,184 @@
 +
 +static unsigned int xt_chaos_target(struct sk_buff **pskb,
 +const struct net_device *in, const struct net_device *out,
 +unsigned int hooknum, const struct xt_target *target, const void 
 *targinfo)
 +{
 +/* Equivalent to:
 + * -A chaos -m statistic --mode random --probability \
 + * $reject_percentage -j REJECT --reject-with host-unreach;
 + * -A chaos -m statistic --mode random --probability \
 + * $delude_percentage -j DELUDE;
 + * -A chaos -j DROP;
 + */

What does this do that can't be done by simply adding those individual 
rules?

It wraps it all up, reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

Take xt_portscan as an example, which would require a minimum of 23 
filtering rules (which cannot reproduce the module's action in its 
fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
a single packet, repeatedly checking for -p tcp, i.e. calling into 
xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
are never examined in xt_portscan.


 Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?

Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)

If you think it is better to merge the respond-with-SYNACK into REJECT 
rather than having DELUDE, say so.


 Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c

We already have the psd match for years, but decided against merging it.

On what basis? As far as I flew over psd's code, it uses a heuristic 
like how often did that client recently connect for match decision. 
(P2P clients randomly port knocking, anyone?) I would not think of that 
as a reliable way to tell portscans either. However, half-open TCP 
connect for example is a more clear action to define a portscan.



Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Alan Cox]

 Also note that the word 'chaostables' does not even appear in the patch, 
 though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
 can safely assume that CHAOS does what it says - make fun of nmap.

entropy ?
randomness

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+/* Equivalent to:
+ * -A chaos -m statistic --mode random --probability \
+ * $reject_percentage -j REJECT --reject-with host-unreach;
+ * -A chaos -m statistic --mode random --probability \
+ * $delude_percentage -j DELUDE;
+ * -A chaos -j DROP;
+ */

What does this do that can't be done by simply adding those individual 
rules?
 
 
 It wraps it all up, reducing the overall number of rules and user 
 chains required in the filtering tables to implement the wanted logic. 
 Reducing the number of filtering rules also reduces the time process a 
 packet. These two are, in my opinion, a good thing.


By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

 Take xt_portscan as an example, which would require a minimum of 23 
 filtering rules (which cannot reproduce the module's action in its 
 fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
 a single packet, repeatedly checking for -p tcp, i.e. calling into 
 xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
 are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb-mark and nfct-ctmark,
so I suggest you start by explaining what it really does.

+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?
 
 
 Looking only at TCP,
 REJECT sends a RST for any packet (if requested), or ICMP otherwise.
 DELUDE sends a SYN-ACK on SYN, otherwise RST.
 (And TARPIT, for reference, keeps the connection open anytime. Its code
 is also quite a replication of REJECT.)
 
 If you think it is better to merge the respond-with-SYNACK into REJECT 
 rather than having DELUDE, say so.


I'd rather not add hacks to mildly annoy people anywhere.

We already have the psd match for years, but decided against merging it.
 
 
 On what basis? As far as I flew over psd's code, it uses a heuristic 
 like how often did that client recently connect for match decision. 
 (P2P clients randomly port knocking, anyone?) I would not think of that 
 as a reliable way to tell portscans either. However, half-open TCP 
 connect for example is a more clear action to define a portscan.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

On Mar 8 2007 18:15, Patrick McHardy wrote:

 Take xt_portscan as an example, which would require a minimum of 23 
 filtering rules (which cannot reproduce the module's action in its 
 fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
 a single packet, repeatedly checking for -p tcp, i.e. calling into 
 xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
 are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb-mark and nfct-ctmark,
so I suggest you start by explaining what it really does.

xt_portscan needs to keep track of what packets the machine has already 
seen. So on the first SYN, the connection is marked with 1. (Then we 
send our SYN-ACK... and the connection turns ESTABLISHED.) The next 
packet that is received will be an ACK or an RST. But it must come 
_exactly after_ the SYN, so just using --tcp-flags ACK will not work. A 
state which can be remembered is required. For that, an automaton is 
used, whose state is saved in the connection mark.

If you would like to find out more about the implementation, please have 
a look at http://jengelh.hopto.org/p/chaostables/fw.html section 3, 4, 
and perhaps 5.

As for the packet mark, refer to section 6. But for you: xt_portscan 
consists of two parts, one is detect-and-mark and the other is 
match it. To have the following do the right thing

  -m portscan --cnscan  -j LOG --log-prefix [evil user] 
  -m portscan --stealth -j LOG --log-prefix [hideous evil user] 

the detect-and-mark code _must_ (in its common RFC meaning) only be 
executed once per packet.


We already have the psd match for years, but decided against merging it.
 
 On what basis? As far as I flew over psd's code, it uses a heuristic 
 like how often did that client recently connect for match decision. 
 (P2P clients randomly port knocking, anyone?) I would not think of that 
 as a reliable way to tell portscans either. However, half-open TCP 
 connect for example is a more clear action to define a portscan.

The question is what we gain by being able to detect portscans.

You have a point with that. But then we could argue on hours about what 
we gain with life.

So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

Perhaps. I'll just provide this little example of what is good for to 
check for portscans:

  -N block_it
  -A block_it -m recent --name block_it --update --seconds 60;

  -A INPUT -m portscan --cnscan -j block_it;
  -A INPUT -m recent --name block_it --rcheck -j DROP;

that is, to drop everything from evil hosts doing half-open scans for 
some time.

[ Ok, I used recent, now I don't get what you meant by Besides that,
  it should be possible to do this by using the recent match. -
  recent alone does not check for half-opens, nor connect-scans. It 
  checks for recentness of anything. I hope you can clarify. ]



Thank you,
Jan
-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Jan Engelhardt]

Hello,

On Thu, 08 Mar 2007 18:15:12 +0100, Patrick McHardy wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+   /* Equivalent to:
+* -A chaos -m statistic --mode random --probability \
+* $reject_percentage -j REJECT --reject-with host-unreach;
+* -A chaos -m statistic --mode random --probability \
+* $delude_percentage -j DELUDE;
[2nd one should have had -p tcp]
+* -A chaos -j DROP;
+*/

What does this do that can't be done by simply adding those individual 
rules?

It wraps it all up, reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

While that is indeed true, I think users will have a judgement (perhaps 
call it first impression) that puts a certain set of NF rules into 
either of the two categories this is fundamental/generic enough to 
warrant its own module and this does not. While

  -A INPUT -s 134.76.0.0/16 -p tcp --dport 22 -j ACCEPT;
  -A INPUT -p tcp --dport 80 -j ACCEPT;
  -A INPUT -j REJECT;

is clearly something that only applies to one machine only, perhaps a
little subnet, or at best, the servers on the company network, it is not
for everyone. xt_CHAOS on the other hand was meant - if you want so - as
a replacement for DROP/REJECT and the default policy, e.g.:

# Block all evil, even if from inside the house.
-A INPUT -m evil -j CHAOS;
# Ignore stray packets not directed at us
-A INPUT -d mybase -m this -j ACCEPT;
# Management console
-A INPUT -s yourbase -m that -j ACCEPT;
# Chain policy (instead, or supplemental to, -P INPUT DROP)
-A INPUT -j CHAOS;

(-m evil, -m this and -m that are placeholders and are not seriously
considered to get their own kernel module anytime.)

For me, this falls under generic-enough, but your (and other people's) mileage
migt vary.


Thank you for the comments,

Jan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Alan Cox]

On Thu, 8 Mar 2007 07:35:05 +0100 (MET)
Jan Engelhardt [EMAIL PROTECTED] wrote:

 Hello netfilter-devel,
 
 
 I would like to submit chaostables (v0.5_svn23) for inclusion. Primary 
 use is to detect, spoof and slowdown various sorts of port scans.
 Implementation details can be found at http://jengelh.hopto.org/p/chaostables/


Any chance of tweaking the name - it's just there is/was a chaosnet
protocol/network system and you don't want people to assume that since
its a chaosfilter its for chaosnet  ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[Patrick McHardy]

Jan Engelhardt wrote:

 Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 @@ -0,0 +1,184 @@
 +
 +static unsigned int xt_chaos_target(struct sk_buff **pskb,
 +const struct net_device *in, const struct net_device *out,
 +unsigned int hooknum, const struct xt_target *target, const void 
 *targinfo)
 +{
 + /* Equivalent to:
 +  * -A chaos -m statistic --mode random --probability \
 +  * $reject_percentage -j REJECT --reject-with host-unreach;
 +  * -A chaos -m statistic --mode random --probability \
 +  * $delude_percentage -j DELUDE;
 +  * -A chaos -j DROP;
 +  */

What does this do that can't be done by simply adding those individual
rules?

 + const struct xt_chaos_info *info = targinfo;
 +
 + if((unsigned int)net_random() = reject_percentage)
 + return xt_reject-target(pskb, in, out, hooknum, target,
 +reject_params);
 +
 + /* TARPIT/DELUDE may not be called from the OUTPUT chain */
 + if((*pskb)-nh.iph-protocol == IPPROTO_TCP 
 +   info-variant != XTCHAOS_NORMAL  hooknum != NF_IP_LOCAL_OUT)
 + xt_chaos_total(info, pskb, in, out, hooknum);
 +
 + return NF_DROP;
 +}


 Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?

 Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c

We already have the psd match for years, but decided against merging
it.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] chaostables

[James Morris]

On Thu, 8 Mar 2007, Alan Cox wrote:

 Any chance of tweaking the name - it's just there is/was a chaosnet
 protocol/network system and you don't want people to assume that since
 its a chaosfilter its for chaosnet  ?

That's exactly what I thought it was from the subject line.


- James
-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/