NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to use in a distributed denial-of-service (DDoS) attack. Please also take this opportunity to defeat denial-of-service attacks by implementing ingress and Egress filtering through BCP38. See VMWareNTPDev for discussion of this topic.
The final two security bugs reported by Google's Security Team have been fixed as of ntp-4.2.8p1.
A new set of mode 6 vulnerabilities has been discovered and, while these vulnerabilities can be reduced by making sure you have
restrict default … noquery in your
ntp.conf file, the best and most complete way to avoid these vulnerabilities is to install and deploy
ntp-4.2.8p1 which was released on 04 February 2015.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
13.6. VMware and NTP
13.6.1. General Notes
VMWare ESX server includes a version of the reference implementation ntpd running as a service in the VMware service console. As of ESX version 3.5u1, the ntpd version included is fairly old: ntpd version 4.1.2. By default, it is configured to synchronize to the local clock, but can be configured with the graphical VI Client to use other NTP servers.
As it is a branched version of the reference implementation ntpd, it can also act as a server, although this configuration must be done through the service console. Documentation can be found here
Note that it is generally not useful to run ntpd (or other NTP implementations such as Windows Time Service) inside of virtual machines. This is because the ESX server intercepts and maniplates timer interrupts to perform load-sharing amongst virtual machines. Instead, the recommended configuration is to run the included ntpd on the host ESX machine, disable any clock-steering software in the guest virtual machine, and finally configure guest virtual machines to obtain their time from the host using VMware Tools. VMware tools runs as a daemon or service inside the guest operating system (Windows, Linux, and Solaris are supported as of ESX 3.5).
Note that, in general, all timing inside of virtual machines may not reflect "real time". This leads to some interesting effects with performance counters and other timing-dependent applications. Even a simple CPU utilization monitoring utility will report data that appears incorrect inside of a VM if there are other VMs running. A VMware whitepaper
on this topic explains these effects and their workarounds in greater detail.
13.6.2. Configuration Examples
18.104.22.168. ESX Server 3.0.3
- Make sure that NTP is working on the ESX Server (i.e. ESXhost)
- Install, but turn off, NTP on the guest VM; ensure that the ntp.conf is valid
- Install VMWare tools on the guest VM and set
timesync = true (see below)
- Edit /boot/grub/grub.conf(or whatever your boot config is called) to have the kernel line include clock=pit
- You will need to reboot the VM to get the above change to take effect.
- Put a short shell script in /etc/cron.hourly and make it chmod 755 owned by root:
You can enable timesync on a GNU/Linux host with a Guest OS command shown below:
vmware-guestd --cmd "vmx.set_option synctime 0 1"
Run the above command TWICE. The second time (or possibly the first even) should produce
an error if in-fact it is turned on correctly.
If you want to disable timesync on a GNU/Linux host with a Guest OS command you can run with similar results as above:
I vmware-guestd --cmd "vmx.set_option synctime 1 0"