[ntp:hackers] Security and binding to IP addresses

John Pettitt jpp at cloudview.com
Mon Feb 28 10:18:38 PST 2005


After a spirited discussion in a bug report
(http://bugzilla.ntp.org/show_bug.cgi?id=214)  Danny suggested I move
the discussion here.

The basic argument is that ntpd should not bind to interfaces that's
it's not been explicitly told to bind to.  For example my FreeBSD 5.3
box with the Feb06 development code -

gatekeeper# netstat -a | grep ntp
udp6       0      0  fe80:3::1.123          *.*                   
udp6       0      0  ::1.123                *.*                   
udp4       0      0  127.0.0.1.123          *.*                   
udp4       0      0  64.142.103.199.123     *.*                   
udp4       0      0  64.142.103.198.123     *.*                   
udp4       0      0  64.142.103.197.123     *.*                   
udp4       0      0  64.142.103.195.123     *.*                   
udp4       0      0  64.142.103.194.123     *.*                   
udp4       0      0  64.142.103.193.123     *.*                   
udp4       0      0  64.142.103.192.123     *.*                   
udp6       0      0  fe80:2::211:11ff.123   *.*                   
udp4       0      0  64.142.103.196.123     *.*                   
udp6       0      0  fe80:1::204:e2ff.123   *.*                   
udp4       0      0  192.168.2.254.123      *.*   

Nowhere in my ntp config is there an IPV6 address - why is it binding to
it?  Equally .199 and .192 are used by this system at tripwire addresses
for port scan detention - it's a royal PITA to have an application bind
to them without being asked.

On a higher level there is a general principle that applications should
not bind to network addresses without being told to - no matter how good
the internal controls in the app are (e.g restrict) it's always better
to not talk to the intruder at all rather then listen then try to ignore
(particularly with a spoofable protocol like UDP).

This brings up the issue of listening for replies from remote servers
that ntpd queries - there is no reason for the requests to come from 123
if ntp is only a client (not symmetric mode). A fact clearly
demonstrated by the lare number of servers behind NAT devices.

Danny makes the point that fixing this would require a major rewrite -
this may be true but it doen't change the underlying wisdom of doing
so.    I'm not sying this is a "drop everying and fix it" issue - just
that it should proably be fixed in the long term.

John




More information about the hackers mailing list