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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Pine.LNX.4.61.0703081652310.2448@yvahk01.tjqt.qr>
Date:	Thu, 8 Mar 2007 17:39:16 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	James Morris <jmorris@...ei.org>
cc:	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>, kaber@...sh.net
Subject: Re: [PATCH] chaostables

(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 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/