Date: Mon, 17 Dec 2001 20:53:21 -0800 (PST) From: Lamont Granquist <lamont@scriptkiddie.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: "Tim J. Robbins" <tim@robbins.dropbear.id.au>, <freebsd-security@FreeBSD.ORG> Subject: Re: options TCP_DROP_SYNFIN Message-ID: <20011217203955.K4651-100000@coredump.scriptkiddie.org> In-Reply-To: <200112171803.fBHI3kA35513@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Dec 2001, Garrett Wollman wrote: > > T/TCP (RFC 1644) speeds up transactions by not using the standard three- > > way handshake. I gather that it's more efficient if you have lots of > > quick connects and disconnects as you do with HTTP when not using the > > keepalive features. > > However, it's almost entirely irrelevant to this discussion, since the > only Web client which ever used T/TCP was FreeBSD 3.0's `fetch' > program. Transaction TCP turned out to be a bad idea, for a few > fundamental reasons, but might make a comeback some day in a world > with stronger security for TCP connections (e.g., host identity > payload). DES and I have discussed a more appropriate behavior for > this option which does not violate the TCP standard. What about using T/TCP for back-end data center traffic? Put it into an environment where you basically trust your host identities? (of course most of the time in this kind of environment you can just use a persistant TCP connection...) Anyway, more to the point of the original poster, if you're turning on TCP_DROP_SYNFIN in order to block nmap host identification, you really have too much free time on your hands. Most attackers are driven not by which hosts they want to exploit but which exploits they have to use. They tend to scan large blocks of addresses with automated attack tools which don't bother to do any osdetection and just look for the service, attempt to exploit it and return if the exploit was successful or not. And if you're threat model includes people who are going to target you specifically and who are very skilled then you have to include the possibility that they'll know enough to do host identification even in the presence of TCP_DROP_SYNFIN. Hence, for either threat model (scriptkiddie or determined attacker) you gain nothing from this option while you break your RFC compliance. (and i'm not religiously against security-through-obscurity, i just think that this isn't a good application of it) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011217203955.K4651-100000>