[ntp:hackers] Security and binding to IP addresses
mayer at gis.net
mayer at gis.net
Mon Feb 28 11:28:49 PST 2005
Please use hackers at ntp.isc.org for the hackers mailing list.
----- Original Message Follows -----
> 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 220.127.116.11.123 *.*
> udp4 0 0 18.104.22.168.123 *.*
> udp4 0 0 22.214.171.124.123 *.*
> udp4 0 0 126.96.36.199.123 *.*
> udp4 0 0 188.8.131.52.123 *.*
> udp4 0 0 184.108.40.206.123 *.*
> udp4 0 0 220.127.116.11.123 *.*
> udp6 0 0 fe80:2::211:11ff.123 *.*
> udp4 0 0 18.104.22.168.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?
You apparently configured IPv6 on your system. the fe80:* address is the
autoconfigured link-local IPv6 address, ::1 is the localhost IPv6
You apparently don't have wildcards enabled.
> 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.
That's awaiting an enhancement to allow you to specify the address list
to which you want to bind.
> 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).
See above. Define intruder. It's always easy to spoof an address using
UDP. That's what firewalls are for.
> 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.
As I said before it's a protocol violation. There are also plenty of
problems with NAT devices which cannot be relied on to leave the
packets alone and interfere with authentication.
> 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.
More information about the hackers