[ntp:questions] Re: wireless routers beating on NTP servers

David L. Mills mills at udel.edu
Sun Jan 18 16:11:46 UTC 2004


Wolfgang,

I had a look at the ntpclient.c source published at the Linksys site. I
do really congratulate them for publishing the source code. The client
program is driven by a bunch of command-line options, including the
interval between polls and the maximum number of polls. I assume that
program is called from a script somewhere and it's the script that
invites zombie persuasion. A more persistent critic might dig further to
find that script, if it is included in the sources, but the sheer size
of the lot is intimidating this side of a dinky ISDN circuit.

If the client is not synchronized, the reference timestamp in packets it
sends can be anything, so that's not a reliable signature. The monstats
LRU list now implemented in ntpd is a very effective call-gap provision,
but where it's needed the most the packet flux is so large that it
overflows the list and thus becomes ineffective for interarrivals more
than a few seconds. Nevertheless, the call-gap does deflect the real
ornery ones in the order of a second or two.

Obviously, Linksys has not seen the ID now in the RFC pipeline. There is
explicit guidance on best practices, including DNS, poll interval and
kiss-o'-death. I see none of these practices in the ntpclient.c source,
but it would take only a line or two to respond to KoD and the rest is
in the scripts.

Dave

"Wolfgang S. Rupprecht" wrote:
> 
> "David L. Mills" <mills at udel.edu> writes:
> > Can you reveal the UDP source port number? Very likely it is the same in
> > all units, at least in the same version. This is how the perps were
> > detected in the Netgear incident. We should add a blacklist feature to
> > the ntpd access controls where known perps would be discarded on the
> > basis of UDP source port number.
> 
> I'm now running the hacked firmware from http://www.sveasoft.com/ .
> The port I'm seeing now is 2048/udp .  That number almost certainly is
> determined by the startup order of the processes in the box.  The
> ntpclient source code I downloaded from Linksys's site simply opens an
> ephemeral port.
> 
> Another way of detecting the NTP requests from the current firmware is
> to note the reference timestamp in the ntp packet.  If the reference
> is consistently off by some multiple of 3600 seconds then you can
> safely drop the packet.  The way I see it, somebody that is
> consistently off by 3600 seconds has no business talking to a stratum
> 1 anyway.  (My guess is that they botch UTC vs. local time.  If I set
> the timezone to 0 I get a reference that is close to correct.)
> 
> > A skeptic might come to suspect this and the Netgear incident might be
> > more sinister than first suspected and might conceivably be a terrorist
> > plot. There might be a design team contracted by Linksys to construct an
> > otherwise innocent program but actually indended to create a million
> > zombies. A small number of these perps that light up a few times per
> > minute might not be noticed, but the Netgear incident involved some
> > 750,000 perps all imploding on the same server.
> 
> It is good to keep things like this in the back of one's mind.  The
> current spam war has already escalated to the point that the spammers
> are commanding large numbers of trojaned windoze boxes to focus a DOS
> attack on anti-spam sites.  Any US adversary could do the same without
> the risk of embedding some "smoking gun" software in a home router.
> 
> Lets home the critical infrastructure can be convinced to buy their
> own GPS based stratum-1's to supplement external time sources.
> 
> -wolfgang
> --
> Wolfgang S. Rupprecht                http://www.wsrcc.com/wolfgang/
>        The above "From:" address is valid.  Don't mess with it.
> Gripe to your senators about spam:  http://www.wsrcc.com/spam/senators.html



More information about the questions mailing list