linux-kernel - Re: [PATCH] chaostables

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Mar 2007 08:54:53 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	kaber@...sh.net
cc:	James Morris <jmorris@...ei.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Netfilter Developer Mailing List 
	<netfilter-devel@...ts.netfilter.org>
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/