Article: 10592 of comp.protocols.time.ntp From: vjs@calcite.rhyolite.com (Vernon Schryver) Newsgroups: comp.protocols.time.ntp Subject: Re: what do i have to send to the ntp server to just get back the time? Date: 26 Oct 2000 09:35:59 -0600 Organization: Rhyolite Software Lines: 106 Message-ID: <8t9j0v$971$1@calcite.rhyolite.com> References: <8t46tf$ii1$1@calcite.rhyolite.com> NNTP-Posting-Host: localhost.rhyolite.com X-Trace: calcite.rhyolite.com 972574559 9442 127.0.0.1 (26 Oct 2000 15:35:59 GMT) X-Complaints-To: usenet@calcite.rhyolite.com NNTP-Posting-Date: 26 Oct 2000 15:35:59 GMT Path: news.meer.net!nntp1.ba.best.com!news2.best.com!news-hog.berkeley.edu!ucberkeley!enews.sgi.com!wlbr!rhyolite.com!not-for-mail Xref: news.meer.net comp.protocols.time.ntp:10592 In article , David Woolley wrote: >> UDP ports 13 and 37 are dangerously only when implemented badly, and then >> only with difficulty and luck, and little more than with any other UDP >> protocol including NTP. > >I must admit I've never seen a reason given for blocking them, other >than that they don't have benefits to compensate possible risks, but >unless inetd takes active steps against attacks, in the way that modern >systems do with ICMP, they ought to allow one fast site (student?) to >use another fast site, to saturate the link to a slow site in a way such >that the trail only leads to the second fast site. (The real cure lies >in sensible filtering at the first fast site.) > >It is this third party attack that I see as a potential problem, not >a direct attack. 3rd party or 333rd party, call it what you want. There are two dangers with any UDP service, and they have nothing to do with whether the service is implemented in inetd, xntpd, or any other daemon. The first danger is that a bad guy can forge your source address in any IP packet and send it to some machine that will respond. Your machine won't notice or be bothered unless the bad guy arranges for your system to get lots of responses, either by sending lots of forged packets or using amplifying mechanisms. The most common amplifier is a router that forwards so called directed broadcasts. This attack in principle works equally well with any IP packet, including NTP/UDP/IP and even TCP/IP (think of RST's and SYN-ACK's), not just the time protocols. The fix for this danger is not to turn off the service, but to turn off directed broadcasts (which never universal worked and never had much utility) and to modify servers to not respond to packets that arrive with a local (e.g. MAC) broadcast destination address. (The last is why no one worries about TCP RST's or SYN-ACK's.) The second danger is when a bad guy can forge your source address in a packet that will not only generate a response, but whose response will generate a second response, and so on forever. The most obvious is the UDP echo port 7, but a bad guy can use a pair of services that answer each others responses. It turns out that at some times one of the UDP time services will also understand its own output as a request. The sane, adult fix for this danger is also not to turn off the service (including Echo), but to rate limit responses and to randomly ignore perhaps 10% of requests. >> As with source routes and ICMP packets, zillions of people who know far >> less than they think they do turn them off on idiotic "security" grounds. > >I would rather have people playing over cautious when in doubt >than assuming no risk at all. I like the minimum privilege concept. That "reasoning" has many people turning off all ICMP, including Need Frag, and so causing black holes, as well as the unreachables, and so breaking traceroute and ping. >The problem with source routing is that you need rather more sophisticated >packet filtering than is normally the case to eliminate the hostile cases, >a more sophisticated system administrator to configure it, and more >sophisticated management to allow the adminstrator the time to do it. You are even more mistaken about the widely supposed but largely non-existent dangers of source routing, but routing nonsense seems too far off topic for comp.protocols.time.ntp. >> As for NTP servers blacklisting those who use them, who besides those >> dumb enough to swallow the PC blabber about "firewalls" that are really >> lame, essentially useless intrusion detection systems would notice an >> isolated UDP packet to port 13 or 37 or an ICMP timestamp? > >They do get noticed, Do you want to bet? Yes, a flood of any sort of packet will be noticed, but no one sand and running a busy server can afford to worry about isolated packets. There are too many ways that a few packets of any kind can be generated in error and sent to an unintended destination. It is only the ignorant suckers who buy useless intrusion detection systems, often labelled "personal firewalls" by snake oil vendors, that can worry about rare packets, partly because all packets sent to their PC's are rare, and partly for the same reasons that cause people to spend their lives listening to mundane chatter on radio scanners. > and whilst this case doesn't actually say they >get blacklisted, someone on this list certainly considers them a real >problem. I think there was an earlier article that actually mentioned >blocking sites noticed doing this. > > From: mark.martinec@ijs.si (Mark Martinec) > Newsgroups: comp.protocols.time.ntp > Subject: Greenwich Electronic Time (GeT) - NTP Request > Date: 2 Oct 2000 17:42:14 +0200 (CEST) > Message-ID: > > time servers to sync to our NTP serves though. I also don't like > misconfigured PCs banging on out firewall trying to access our > time server using other protocols than NTP, such as Time Protocol > (RFC868) or Daytime Protocol (RFC867). That's a classic example of how netnews wisdom is generated. One person makes a mild overstatement and someone else amplifies. In a few rounds, something like the perfectly reasonable notion of dealing with a smurf attack using port 37 becomes blacklisting any network that happens to send a single ICMP timestamp. Vernon Schryver vjs@rhyolite.com