[19712] in bugtraq
Re: TCP Timestamping and Remotely gathering uptime information
daemon@ATHENA.MIT.EDU (Ted U)
Mon Mar 19 18:04:54 2001
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.BSO.4.31.0103162107270.31657-100000@heorot.stanford.edu>
Date: Fri, 16 Mar 2001 21:20:38 -0800
Reply-To: Ted U <grendel@HEOROT.STANFORD.EDU>
From: Ted U <grendel@HEOROT.STANFORD.EDU>
X-To: Emre Yildirim <emre@srengineering.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <01031623075702.00707@buttercup>
On Fri, 16 Mar 2001, Emre Yildirim wrote:
> I might be completely wrong here but.... what about
>
> sysctl -w net.inet.tcp.rfc1323=0
no, that disables timestamps. rfc1323 support is needed (or will be) for
high speed networks, where the sequence numbers can roll over. then
delayed packets might be accepted when they shouldn't. the timestamp
prevents this from happening. for today's internet, you can turn rfc1323
off. but that's not a solution to the "problem", if indeed there is a
problem.
it's not a major issue if someone can determine your uptime, as has been
pointed out. darren doesn't think so, bret did. anyway, as bret pointed
out, it can be used to count the machines behind a load balancing system.
another area is nat detection. let's say i've got three servers running
irc, www, and ftp behind a nat firewall. by examing the timestamps, you
could determine that my.host.com:80 and my.host.com:21 are not the same
machine. usefulness? i don't know. but why advertise if you don't have
to?
it was pointed out to me that openbsd -current sets the initial timestamp
to a random number, so the uptime detected is incorrect. but this still
allows someone to count the machines behind a firewall. the way i did it,
every connection is at zero initially, so it's much harder to tell.
--
Ted Unangst - grendel@heorot.stanford.edu - http://heorot.stanford.edu/
"If you don't believe in the existence of evil, you have a lot to learn."
