Date: 06 Jun 1999 00:06:16 -0500 From: Joel Ray Holveck <joelh@gnu.org> To: Scott Michel <scottm@cs.ucla.edu> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, freebsd-current@FreeBSD.ORG Subject: Re: net.inet.tcp.always_keepalive on as default ? Message-ID: <86iu91dik6.fsf@detlev.UUCP> In-Reply-To: Scott Michel's message of "Sat, 05 Jun 1999 18:27:17 -0700" References: <199906060127.SAA00862@mordred.cs.ucla.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>> This wouldn't help the poor sod whose connection gets shot down every >> eight days while he's not there and doesn't know what hit him. > One thing that no one points out is that this "idle" connection > is potentially a security threat. Even if the physical connection > is iced and is reconnected later using the same IP and the TCP > connection is restored because it was kept alive, this presents a > whole new world of interesting exploits. It's non-trivial, but > that doesn't stop people like Network Associates' Labs from > publishing papers on the subject. Keepalives are not particularly useful against connection hijacking, as far as I can tell, except perhaps that a keepalive packet may disclose the current TCP sequence number to the new assignee of a dynamic IP. (This, of course, presents an argument for the opposite stance.) As near as I can tell, you're saying that if a transient outage is restored, then after it's restored, an idle connection may be used by an intruder. How does the transient outage affect this? If the transient outage has the side effect of changing routing, then an attacker (or somebody else) is moving cables around, or a dynamic link with a dynamic IP is being changed. In the former case, then the long delay between keepalive packets should not make them a valid protection. (If it takes an attacker more than a week to move a cable, then may I suggest your attacker needs to refine his technique.) In the latter case, then the attacker who now holds the destination IP can respond to the keepalive packets masquerading as the legitimate recipient as easily as they can do any other work involved in hijacking your connection. If the outage did not cause a reconfiguration, then the attacker generally has no different access to your network than before, and no more means to hijack an open connection than before. I've got some whiskey in me right now, so I may be unclear on what you're saying. Am I missing something here? Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86iu91dik6.fsf>