Sécuriser l’administration de ses serveurs virtuels hébergés

Les ressources de calcul à la demande sont désormais peu coûteuses et rapides d’accès. Commander un serveur privé virtuel (VPS) se fait en quelques clics et pour quelques euros par moi. Sa mise à disposition est quasiment immédiate. Parfait, du moins en apparence, pour de nombreux projets, simples comme ambitieux. Mais voilà, la sécurité peut aisément être négligée. Le ver de cryptojacking Graboid récemment révélé par les équipes de l’unité 42 de Palo Alto Networks, n’en est qu’une illustration supplémentaire : il se propage entre hôtes exposant un démon Docker sur Internet sans mécanisme d’authentification approprié. Tant pis si Docker Engine n’est pas, par défaut, exposé sur Internet : pour les administrateurs de quelques milliers d’hôtes recensés, l’exposition directe du démon est probablement plus pratique.

De nombreux hébergeurs, à l’instar d’OVH en France, proposent des conseils de base pour sécuriser l’administration de son VPS sitôt sa mise à disposition. Mais encore faut-il prendre de suivre ces recommandations : changement du port d’écoute du service SSH, authentification par clé sur un compte dépourvu des droits d’administration, et désactivation de l’accès au compte root.

Rebondissant sur le récent retour d’expérience de Fleury Michon, où l’attaque de ransomware a commencé par la compromission d’un service RDP exposé directement sur Internet, Fabian Rodes, fondateur de Fasis Consulting, relève que le « RSP exposé n’est que ruine pour votre cybersécurité », ce qui « est aussi vrai en remplaçant RDP par SSH ».

Et l’expert d’identifier deux types de risques principaux : « les failles associées au serveur », et celles « inhérentes à l’authentification login/password ». Pour répondre au second point, le recours à l’authentification à facteurs multiples (MFA) peut être tentant, conjointement à une authentification par clé cryptographique plutôt que par nom d’utilisateur/mot de passe. Et Fabian Rodes de suggérer au passage le recours à Fail2ban afin d’éviter les attaques en force brute, « avec rétention sur au moins 72 h pour le ban au-delà de 5 échecs » d’authentification.

Mais cela ne vaut que pour certains cas précis où, par exemple, l’utilisation d’un client SFTP peut s’avérer nécessaire. Car pour Fabian Rodes, l’authentification à facteurs multiples présente au moins le défaut ne pas régler le premier point – ni même cacher « le démon en écoute sur un port exotique ».

L’approche privilégiée tant par cet expert, ainsi que par Alexandre Dulaunoy, du centre de réponse à incidents du Luxembourg, le Circl, consiste à recourir à un bastion intermédiaire. Fabian Rodes indique ainsi privilégier l’usage d’un bastion « via un VPN avec un secret partagé avant l’authentification ». Et dans le cas de plus de deux VPS, il recommande un « relais via deux d’entre eux », avec « verrouillage Netfilter ».

Alexandre Dulaunoy apparaît plus enclin à faire confiance à SSH, mais toujours avec une approche bastion : « j’ai une préférence pour un bastion OpenSSH avec authentification par clé uniquement et/ou TOTP matériel [mot de passe à usage unique à durée de vie limitée] sur le bastion », avec en prime journalisation « agressive ». De quoi surveiller les tentatives d’accès non autorisé. Plus loin, le bastion est déclaré comme correspondant autorisé « en filtrage IP » des machines à administrer effectivement, en SSH.