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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]