Protéger un VMware vSphere contre les attaques DDoS NTP

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

Réinitialiser un compte machine sur un domaine Active Directory

Les machines inscrites sur un domaine Active Directory ont un mot de passe lié à elles, qui est renouvelé régulièrement (par défaut tous les 30 jours) de manière totalement transparente.
Lorsqu’on travaille sur des clichés de machines pour faire des tests (par exemple un serveur virtuel dont une copie est créée pour faire un test unitaire), il peut arriver que le mot de passe de la machine d’origine ait été réinitialisé depuis la prise du cliché utilisé pour créer la copie. Celle-ci n’étant plus en phase avec ce qui est stocké sur l’annuaire Active Directory, impossible d’ouvrir une session avec un utilisateur du domaine sur la machine copie.
Continuer la lecture de Réinitialiser un compte machine sur un domaine Active Directory

VMWare vcenter converter et serveur dédié soyoustart/ovh

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

Enregistrer un certificat d’une AC Windows dans un Synology

Pour pouvoir utiliser, dans un environnement de domaine Windows, un certificat généré depuis l’autorité de certification du domaine, il faut plusieurs brique.

D’une part, un accès au serveur faisant office d’autorité de certification de racine pour le domaine.

D’autre part, il faut avoir le logiciel openssl (dans mon cas, je l’ai récupéré ici, il n’y a pas d’installation… Je n’ai pas besoins des sources ici.) sur son poste local afin de travailler les certificats générés par l’AC Windows et les rendre compatibles avec les Synology.
Continuer la lecture de Enregistrer un certificat d’une AC Windows dans un Synology

Changer le nom d’hôte d’un serveur Windows ayant Oracle 11gR2 d’installé

Il y a un certain nombre de chose qu’il faut faire pour permettre le fonctionnement d’Oracle 11gR2 après le changement du nom d’hôte d’une machine, Oracle ayant la superbe idée d’utiliser ce nom de machine un peu partout…
Continuer la lecture de Changer le nom d’hôte d’un serveur Windows ayant Oracle 11gR2 d’installé

Redémarrer les services de gestion de Vmware ESXi 5

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

Mise en place de Munin sur Debian 7 Wheezy

Cet article a pour but de présenter les différentes étapes nécessaires à la mise en place d’une version récente de Munin sur Debian 7 Wheezy, donc plus récente que la version 2.0.6-4 présente actuellement dans le dépot « stable » de Debian :

munin (2.0.6-4+deb7u2)
munin-common (2.0.6-4+deb7u2)
munin-doc (2.0.6-4+deb7u2)
munin-node (2.0.6-4+deb7u2)
munin-plugins-core (2.0.6-4+deb7u2)
munin-plugins-extra (2.0.6-4+deb7u2)

La version 2.0.6-4 présente comme principal défaut, en tout cas dans mon cas, de ne tout simplement pas fonctionner… Aucun plugin ne se charge dans cette version, donc pas de monitoring…
Continuer la lecture de Mise en place de Munin sur Debian 7 Wheezy

Migrer un serveur dédié OVH vers une machine virtuelle Hyper-V

Nous avons un serveur dédié chez OVH depuis quelques années, dont le rapport configuration/prix n’est plus très intéressant si on compare aux serveurs actuellement disponible chez OVH.
Un problème qu’on n’a pas vu arriver est la migration des données d’une machine physique dédiée, à laquelle on n’a accès que par SSH, sur une autre machine.
Pour pallier à ce problème, nous avons choisi de convertir la machine en question en machine virtuelle qui sera donc indépendante du matos.
Continuer la lecture de Migrer un serveur dédié OVH vers une machine virtuelle Hyper-V

Individualiser une VM Hyper-V tournant sous Debian

Pour dupliquer une VM Debian et ne pas risquer d’avoir de problème, voici la procédure que je suis :
– Exporter depuis la console Hyper-V la VM qu’on souhaite dupliquer, éteinte (on va travailler en fait sur la VM déjà présente et ne modifier la configuration que de celle là. La VM exportée/importée sera en fait la VM d’origine).
– modifier le nom de la VM qui est déjà présente dans Hyper-V
– réimporter la VM qu’on avait exporté, en choisissant de « copier » la VM (donc en générant un nouvel ID). La raison est qu’on ne peut pas choisir le nom de la VM lorsqu’on l’importe, et il y avait risque de « collision »…
– une fois importée, on peut relancer la VM qu’on vient d’importer, rien de plus à prévoir sur celle-ci.
– sur l’autre VM (qui est donc celle qu’on avait exporté au départ), on supprime l’interface réseau (pour réinitialiser l’adresse MAC simplement) et on ajoute une nouvelle interface réseau
– on lance ensuite cette VM, on se connecte en prenant les droits root
– on lance la commande suivante pour lister les fichiers de configuration contenant le nom de l’ordinateur :

find /etc -type f -name "*" -exec fgrep -l "<ancien nom d'hôte de la machine>" {} \;

– on modifie le nom des fichiers (en excluant les fichiers de configuration ssh)
– on réinitialise ensuite la configuration ssh pour regénérer les clés :

rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server

– enfin arrêt de la machine
– configuration de la carte réseau pour la relier au commutateur virtuel
– éventuellement fixation de l’adresse MAC, bail DHCP fixe, enregistrement du nom de domaine sur le DNS…
– redémarrage et contrôle que tout va bien!

Restaurer des sauvegardes client de Windows Server 2012 Essentials avec PXE

C’est possible!
Pas très très simple mais pas non plus trop compliqué à mettre en oeuvre…
Si vous ajoutez « tel quel » les fichiers WIM du support de restauration dans WDS, vous risquez d’obtenir un message d’erreur laconique au démarrage :

test2

En fait, sur le support de restauration (depuis technet il se nomme « fr_client_restore_disc_windows_server_2012_essentials_x86_x64_cd_1022301 »), un dossier est « externe » au fichier WIM de démarrage, et contient le nécessaire pour lancer la restauration. Ce fichier porte un nom barbare, que certains appellent GUID. Dans mon cas il s’appelle : « 785AD7EA-0C16-4F43-8AB5-F2904D22483F »
Continuer la lecture de Restaurer des sauvegardes client de Windows Server 2012 Essentials avec PXE