Re: [PATCH] chaostables

From: Jan Engelhardt
Date: Fri Mar 09 2007 - 02:58:31 EST


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/