Subject: Re: OT: netcraft & uptimes
To: None <email@example.com>
From: Emre Yildirim <firstname.lastname@example.org>
Date: 12/25/2001 15:07:30
Ah-hah! I was thinking of that. I was playing around with sysctl earlier today and
changing net.inet.tcp.rfc1323 to 1 and then to 0 again. But it really didn't make a
difference to Netcraft. I guess it's not a big deal; if it makes uptimes harder to
predict, it's a good thing.
(PS, am I seeing double, or are you also on the squirrelmail mailinglist? Or maybe my
mail filters are messed up)
> 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
> 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.