Messages in this thread | | | Date | Fri, 9 Mar 2007 08:54:53 +0100 (MET) | From | Jan Engelhardt <> | Subject | Re: [PATCH] chaostables |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |