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]

Date:	Thu, 08 Mar 2007 18:15:12 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
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

Jan Engelhardt 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;
>>>+	 * -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.

> 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.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb->mark and nfct->ctmark,
so I suggest you start by explaining what it really does.

>>>+++ 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.


I'd rather not add hacks to mildly annoy people anywhere.

>>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.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

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