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] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.61.0703091523200.8799@yvahk01.tjqt.qr>
Date:	Fri, 9 Mar 2007 18:30:32 +0100 (MET)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Amin Azez <azez@...mechanic.net>
cc:	Patrick McHardy <kaber@...sh.net>,
	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 Mar 9 2007 11:54, Amin Azez wrote:
>> Adding a member to the ip_conntrack/nf_conntrack and sk_buff struct
>> would increase the struct sizes, and that would penalize users who do
>> not intend to use xt_portscan.
>
>I understand what you say but it sounds a bit like saying: "but we didn't
>make it very good because so few people would use it anyway" which of
>course makes it even less attractive. I realise you have your own
>interpretation but this is how it reads to me.

I just gave the reason why I designed it the way it is now. If you 
really feel it needs to be changed, well, I don't really object to that. 
chaostables has only seen like.. 1 1/2 version announcements (urls to 
tarballs, no patches) to mailing lists, and except for the few users who 
definitely tried it (based on questions I received), there have not been 
any suggestions for changes yet, which either tells me that nobody is 
interested or everything is fine.

>> I do not see why the packet/connection marks should not be used to record
>> additional information
>...
>> Almost never I required connection marking myself 
>I guessed as much. I use it heavily, with my xml rule generators.
>> except for this
>> portscanning automaton and perhaps a little MARK here and there for
>> finely-tuned SNAT. Again, things might look different on your side(s).
>
>There's too many things fighting over the same few bits of the mark, and
>in your case you are using it to track internal state of a connection
>that has no relevance to the rest of the iptables/ebtables rules.
>
>I'm suggesting that some of the people who would want to use the chaos
>match, won't because of the mark issue.
>
>This is not a new problem.
>
>http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/16217

	"""netfilter marks are the solution of last resort. This is
	becoming very painful for those of us who produce general
	Netfilter configuration tools.""" -Toam Eastep

I see. Thank you for the link. I think you are on the way to have me 
convinced.



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/