You can stop the exploit/DOS with restrictions in the "ntp.conf" file,
while continuing to receive or serve time. You must stop NTP demon
configuration and statistics queries. See the ntpd access control man page:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/accopt.htm
Also, quoting from the man page:
>While this facility may be otherwise useful for keeping unwanted or broken
>remote time servers from affecting your own, it should not be considered an
>alternative to the standard NTP authentication facility. Source address
>based restrictions are easily circumvented by a determined cracker.
See the ntpd authentication control man page:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/authopt.htm
Partial examples of what we use below (restrictions, no authentication).
I'm not an NTP guru, maybe someone else can do better, but these
restrictions stopped the remote exploit without a reply on various stock
Solaris systems; removing the restrictions caused a core dump upon attack.
Even after the buffer overflow is plugged, hosts running ntp should have
appropriate restrictions in the ntp.conf file.
-- Rex
# Unix time client add:
#
# Don't serve time or stats to anyone else
restrict default ignore
# Prefer to get time from local GPS server
server clock.example.com prefer
restrict 10.1.1.12 nomodify
# Backup server
server clock2.example.com
restrict 10.1.1.13 nomodify
==========
# Unix time server add:
#
# Don't serve time or stats to anyone else
restrict default ignore
# Serve time to local subnets
restrict 10.1.1.0 mask 255.255.255.0 noquery notrust nopeer
restrict 10.1.2.0 mask 255.255.255.0 noquery notrust nopeer
# Prefer to get time from local GPS server
server clock.example.com prefer
restrict 10.1.1.12 nomodify
