Les VMware vSphere peuvent être utilisé comme relais pour faire une attaque DDoS contre un service NTP (par exemple pool.ntp.org), avec leur configuration par défaut.
C’est en tout cas ce qui ressort d’un mail que nous avons reçu de la part d’OVH cette nuit :
Bonjour, Une activité anormale a été détectée sur votre serveur nsxxxxxx.ip-xx-xx-xx.eu. N'hésitez pas à vous rapprocher du support technique afin que cette situation ne devienne pas critique. Vous pourrez retrouver ci-dessous les logs remontés par notre système qui ont conduit à cette alerte. - DEBUT DES INFORMATIONS COMPLEMENTAIRES - Your IP is used in a NTP Amplification attack. You should update your NTP server, or fix its configuration, so that it won't respond to 'monlist' queries. You can check your server's configuration here : https://www.ovh.co.uk/cgi-bin/tools/ntp_security.cgi Attack detail : 3Kpps/12Mbps dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason 2016.03.24 06:16:48 CET xx.xx.xx.xx:123 yy.yy.yy.yy:9091 UDP --- 324 ATTACK:NTP 2016.03.24 06:16:48 CET xx.xx.xx.xx:123 yy.yy.yy.yy:9091 UDP --- 468 ATTACK:NTP [...]
Comme dit dans le mail, il suffit de se rendre ici pour voir si notre serveur est vulnérable.
J’ai trouvé une KB qui traite du sujet chez VMware, ici.
Il faut modifier le fichier /etc/ntp.conf, qui en version 5.0.0 build 623860 contient ceci :
restrict default kod nomodify notrap nopeer
restrict 127.0.0.1
server pool.ntp.org
driftfile /etc/ntp.drift
en ceci :
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server pool.ntp.org
driftfile /etc/ntp.drift
Après, il faut relancer le service NTP sur le serveur, et vérifier ici si le problème est corrigé…
L’autre solution est bien évidemment de passer sur une version non vulnérable de VMware vSphere (la version 6.0.0 build 2715440 par exemple)… 🙂
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.