Subject: Re: OT: netcraft & uptimes
To: Emre Yildirim <emre@asper.org>
From: Dave Huang <khym@azeotrope.org>
List: netbsd-users
Date: 12/25/2001 14:50:14
On Tue, 25 Dec 2001, Emre Yildirim wrote:
> DO any of you run a NetBSD webserver (im sure someone does)?  If so, does anyone know
> why Netcraft won't detect my www server's uptime?  On
> http://uptime.netcraft.com/up/accuracy.html it says that Netcraft can predict
> NetBSD/OpenBSD.  It seems like Netcraft was able to predict NetBSD uptimes at some
> point in time, but now with newer versions of NetBSD it doesn't.  Maybe I should
> e-mail them and ask, but does anyone on this list know why it's not working?

It was a bug in the RFC1323 timestamp stuff that the uptime was
predictable remotely... the commit message for rev 1.123 of
sys/netinet/tcp_input.c says:

Two changes, designed to make us even more resilient against TCP
ISS attacks (which we already fend off quite well).

1. First-cut implementation of RFC1948, Steve Bellovin's cryptographic
   hash method of generating TCP ISS values.  Note, this code is experimental
   and disabled by default (experimental enough that I don't export the
   variable via sysctl yet, either).  There are a couple of issues I'd
   like to discuss with Steve, so this code should only be used by people
   who really know what they're doing.

2. Per a recent thread on Bugtraq, it's possible to determine a system's
   uptime by snooping the RFC1323 TCP timestamp options sent by a host; in
   4.4BSD, timestamps are created by incrementing the tcp_now variable
   at 2 Hz; there's even a company out there that uses this to determine
   web server uptime.  According to Newsham's paper "The Problem With
   Random Increments", while NetBSD's TCP ISS generation method is much
   better than the "random increment" method used by FreeBSD and OpenBSD,
   it is still theoretically possible to mount an attack against NetBSD's
   method if the attacker knows how many times the tcp_iss_seq variable
   has been incremented.  By not leaking uptime information, we can make
   that much harder to determine.  So, we avoid the leak by giving each
   TCP connection a timebase of 0.
-- 
Name: Dave Huang         |  Mammal, mammal / their names are called /
INet: khym@azeotrope.org |  they raise a paw / the bat, the cat /
FurryMUCK: Dahan         |  dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 26 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++