vmware esxi 4.1 and ntp attacks
Hello, in
short - we received a letter of happiness from Hetzner, the IP address is involved in the attack, it was
surprising that the address belonged to the vmware esxi 4.1 host.
The letter clearly indicated that the culprit was ntp
and indeed esxi briskly responded to utility requests:
ntpq --peers myesxi.example.com
remote refid st t when poll reach delay offset jitter
=================================== ==================
nsx.customer 192.0.2.1 2 u 1024 64 1 9.057 1015598 0.001
I was certainly surprised, because I did not think that esxi was working in ntp server mode
to fix enough add to the config /etc/ntp.conf
restrict default ignore
and restart the service
The essence of the attack is similar to the dns amplification attack:
the victim’s spoofed address is the source of the ntp request,
and all the responses come to the victim thereby clogging the channel
with esxi 5.1 this problem is not observed (due to the presence of the built-in farvola)
short - we received a letter of happiness from Hetzner, the IP address is involved in the attack, it was
surprising that the address belonged to the vmware esxi 4.1 host.
The letter clearly indicated that the culprit was ntp
and indeed esxi briskly responded to utility requests:
ntpq --peers myesxi.example.com
remote refid st t when poll reach delay offset jitter
=================================== ==================
nsx.customer 192.0.2.1 2 u 1024 64 1 9.057 1015598 0.001
I was certainly surprised, because I did not think that esxi was working in ntp server mode
to fix enough add to the config /etc/ntp.conf
restrict default ignore
and restart the service
The essence of the attack is similar to the dns amplification attack:
the victim’s spoofed address is the source of the ntp request,
and all the responses come to the victim thereby clogging the channel
with esxi 5.1 this problem is not observed (due to the presence of the built-in farvola)