[19692] in bugtraq
Re: TCP Timestamping and Remotely gathering uptime information
daemon@ATHENA.MIT.EDU (Stephen White)
Mon Mar 19 14:00:50 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID: <20010317003122.A15097@benji.the-roost>
Date: Sat, 17 Mar 2001 00:31:22 +0000
Reply-To: Stephen White <swhite@OX.COMPSOC.NET>
From: Stephen White <swhite@OX.COMPSOC.NET>
X-To: Bret <bret@REHOST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200103142243.RAA11917@rehost.com>; from bret@REHOST.COM on Wed,
Mar 14, 2001 at 05:43:54PM -0500
On Wed, Mar, 2001, Bret wrote:
> either by creating a new 'timestamp clock' for
> each TCP session (that uses timestamps)
You can't do this .. it breaks the use of such timestamps for things
like TCP Sequence number wrap-around protection on fast networks
(gigabit).
> or by starting the timestamp clock off with some random number.
I don't think this breaks any rules or functionality and shouldn't even
hit performance. A series of observations would still enable you to
obtain uptime information, since the readings would be linear until a
reboot. If you sampled timestamps from a machine periodically you could
work out it's probably uptime to within the length of that
period. Obviously you're readings would be meaningless until you
witness a reboot, but beyond that point you should still be able to
tell.
There is a slight issue over whether you actually care that people know
your system uptime.
--
Stephen White \ OU Compsoc System Administration Team
PGP Key ID: 0xC79E5B6A \ System Administration Co-ordinator
<swhite@ox.compsoc.net> \ http://ox.compsoc.net/~swhite/
