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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/