Obiyo Online

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)… 🙂

Lorsqu’on doit migrer une machine d’un serveur Hyper-V (par ex chez OVH) vers un autre serveur de virtualisation type VMWare esxi, il *faut* passer par leur outil vcenter converter.
Sinon impossible de démarrer la vm!

Or cet outil, pour fonctionner, démarre une vm sur la machine de destination avec une interface particulière, qui dans notre cas pose problème parce qu’il n’y a pas de DHCP chez OVH/soyoustart.

Pire, pour avoir une IP publique et être joignable, il faut que la machine virtuelle finale ait une adresse MAC définie manuellement et donnée par OVH/soyoustart.

Enfin, la passerelle qui doit être configurée ne fonctionne pas simplement en l’indiquant dans l’outil converter. Elle n’est pas appliquée sur la VM après le lancement de la migration, et la VM n’obtient donc pas d’accès au net… Ceci du fait que la passerelle sur VM avec une IP failover, doit être définir avec la même valeur que la passerelle de la machine hôte, et du fait du masque en 255.255.255.255, la passerelle est en dehors de la plage réseau théoriquement accessible (qui ne contient qu’une IP, la failover attribuée à la VM!).
Continuer la lecture de VMWare vcenter converter et serveur dédié soyoustart/ovh

Il arrive qu’un serveur VMware ESXi 5.0.0 refuse d’ouvrir la session sur sa console, alors que les VMs tournent toujours correctement. Les accès SSH sont eux toujours disponibles.

Un symptôme classique est que la commande suivante (qui permet d’obtenir tout plein d’infos sur les VMs sur le serveur), en SSH, n’aboutit pas :
vim-cmd vmsvc/getallvms

On obtient alors le message laconique :
Failed to login: Connection reset by peer

Plus ennuyant, dans ce cas les sauvegardes des VMs ne passent plus (avec ghettoVCB et mksbackup par exemple…).
Continuer la lecture de Redémarrer les services de gestion de Vmware ESXi 5