[ntp:hackers] i think it's time to review ntp's default acl's

Hal Murray hmurray at suespammers.org
Sat Mar 25 09:35:09 UTC 2006


This discussion started out with using DNS as a reflector/amplifier.

I see two reasons why the bad guys would do that.  The reflector makes it 
harder to track them down.  The amplifier reduces the number of bots and 
reflectors they need to produce a given level of traffic.

How important is the amplification?

Can the bad guys use TCP connection setup as a reflector?  It doesn't 
amplify, but it does reflect.  How about traceroute?  Do current 
implementations have any rate limiting?

Assuming either is a useful attack, how important is it to work on NTP?

---------

> it's possible that T/TCP or SCTP should be used instead of UDP for
> transaction based services like DNS.  but the timing characteristics
> of either are so much sloppier than UDP, that i don't imagine either
> being usable by NTP.  so, no. 

I think there are two issues here.

One is setting up a connection so you know you are talking to somebody who 
wants to talk to you.  That takes 3 packets.  You can piggy back data on the 
3rd one.  That would roughly double the network traffic on a well behaved NTP 
setup.  Without authentication, it would roughly double the server CPU load.

You can avoid the extra network traffic if you keep the connections around 
long enough, but that takes memory.  The Soekris net4801 has a max of 256 
MBytes.  Assume the cache gets half of it and 100 bytes per cache entry.  
That's a million clients.  So if we need them, long lived caches don't seem 
silly.

The other issue is rate limiting the connection responses so they can't be 
used for an attack.

Assuming we magically find/invent and implement and deploy a lightweight 
connection setup protocol, what sort of rate limiting would be necessary to 
keep NTP below the radar?

NTP doesn't need a lot of traffic.  Would simple rate limiting of the current 
protocol be good enough?  Say 1 packet per minute with an initial burst of 10?

It might be appropriate to permit a few times that in order to allow a few 
systems behind a NAT box to access the same server.

There is already code in ntpd to do rate limiting.  (I've never used it.)  It 
might be appropriate to make sure the default is on and/or tweak the default 
parameters.

----------

> it costs money to train staff for, write policies for, debug, and
> handle customer complaints about, BCP38.  the ISP who does this will
> save no money (since the pain caused by not doing it is felt by
> others, not by them)  ...

In theory, those costs should change when an ISP gets block/black listed.  
But judging by the spam/virus mess, that doesn't work very well.

If you set something up to block DNS traffic from poorly managed sites, I 
think it would be good to get NTP to piggyback on that work.  A little more 
publicity might help.

Would that happen in the application or at the routers?  Is there any need 
for code in the ntp package?

--------

> # For NTP, it seems possible to allow access only by previous
> # arrangements.   The administrative overhead would probably eliminate
> # public servers as they are currently used.  That would encourage/
> # require ISPs to setup NTP servers for their customers.

> the way you say that doesn't make it sound bad.  is it actually bad
> and you're just really good at the kind of spin control that i find
> attractive, or is it really as good as you imply? 

I was probably thinking out loud.  Maybe just daydreaming.

One of my gripes is that most (retail?) ISPs don't provide any NTP servers 
for their customers.  I assume it's typical bean counters at work.  Are 
server hosting places any more responsible?

If running a NTP server creates a serious opportunity for getting abused, I'd 
expect many of open access servers to go off the air.  It would be sad to see 
that level of cooperation dying out because assholes are taking over the net. 
 I wish I could do something about it.

On the other hand, part of me hopes that crap like this will get worse, much 
worse.  Maybe if it gets bad enough the net will split into two.  I'll bet 
there is plenty of content on the good side of the wall to keep me happy.



-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.





More information about the hackers mailing list