Written by m4dz

Je vous ai récemment expliqué les choix qui vous reviennent dans le choix de votre hébergement. Dans les faits, ces choix concernent directement votre infrastructure technique, depuis votre OS et son paramétrage jusqu’à l’ensemble de votre architecture. Cela signifie que vous devez ajuster le curseur entre gérer vous-même certains aspects ou les confier à un partenaire. Tout est affaire de confiance, et de coûts.

Sécuriser l’accès à distance est l’un de ces éléments techniques à prendre en compte. Certains points sont triviaux ; d’autres nécessitent des compétences importantes en sécurité et cryptographie. Cet article est ici pour vous donner un aperçu des mesures à mettre en place pour bien sécuriser son accès distant. Il est parsemé de liens vers des contenus plus avancés vers certaines techniques pour vous permettre d’aller plus loin si vous le souhaitez¹⁾²⁾.

TL;DR : la sécurité est un vaste domaine de connaissances où il est facile de se perdre. Si vous souhaitez seulement savoir comment bien configurer votre accès distant aux serveurs d’alwaysdata, intéressez-vous simplement à la section concernant la sécurisation des méthodes d’accès.

Ne laissez pas n’importe qui s’introduire chez vous

Votre application s’exécute sur des machines distantes, pour vous permettre d’offrir un accès à votre service de n’importe où. Vous n’avez généralement pas d’accès physique à ces machines³⁾. Vous utilisez donc un accès distant pour y avoir accès. La plupart du temps, vous passerez par un shell distant : SSH. SSH vous fournit un accès à la fois à une invite de commande et à un navigateur de fichiers bas niveau sur la machine. Vous pouvez le voir comme une porte donnant sur votre salon. Ne pas vous en soucier est dangereux, voire inconscient.

Un point important en matière de sécurité est la manière dont vous sécurisez cet accès à vos serveurs de production. Là encore, vous pouvez vouloir le faire par vous-même, ou vous pouvez préférer vous appuyer sur l’expertise d’un partenaire qui saura le faire pour vous. Chez alwaysdata, nous restons convaincus que cette seconde solution est presque toujours la meilleure, mais il reste malgré tout certains points que vous devrez gérer seuls. Parce que ces points sont encore parfois obscurs, voici quelques conseils pour bien protéger votre accès distant.

Un bon niveau de sécurité est un niveau que vous comprenez, et que vous pouvez administrer seul·e. Pour être certains que vous disposerez de l’expertise de base nécessaire à la bonne compréhension de ces enjeux, nous allons voir ensemble quelques bases. Mon objectif n’est pas de faire de vous un expert en sécurité, seulement de vous donner de bonnes bases.

La plupart des serveurs SSH sont par défaut configurés avec un niveau de sécurité correct. C’est le cas d’OpenSSH, qui est le serveur SSH le plus couramment utilisé. Cependant, distribuer une configuration par défaut signifie que les mainteneurs des paquets sur les distributions doivent gérer le plus de cas d’usages possible, plutôt que de maintenir un niveau de sécurité maximal. Ces configurations par défaut permettent probablement de rejeter 90% des intrusions. Considérez ça comme installer une porte robuste à votre maison ; mieux que rien, mais pas une porte blindée non plus. Voyons comment renforcer ce niveau par défaut.

Be Safe, Be Smart

Sécuriser son accès distant implique de s’occuper d’hygiène numérique, notamment pour la partie client, qui reste à votre charge. Même si votre serveur est bien sécurisé, vous pouvez avoir des problèmes si vous n’avez pas une protection suffisante côté client.

Utilisez une clef SSH pour vous connecter

Nous vous recommandons d’utiliser une clef SSH pour vous connecter plutôt qu’un mot de passe. De cette façon, vous pourrez plus facilement gérer qui se connecte à votre serveur, depuis quel appareil, et révoquer finement les accès en cas d’urgence⁴⁾. Une bonne pratique consiste à avoir une paire de clefs⁵⁾ par utilisateur et par appareil. Cela vous donnera la flexibilité nécessaire à la révocation de l’appareil si celui-ci est perdu, volé, ou mis hors service, plutôt que révoquer l’accès complet de l’utilisateur.

Pour savoir comment générer une clef sécurisée à jour, reportez-vous à la section concernant le format ed25519.

Ne vous connectez pas via un mot de passe

Les mots de passe ne présentent pas une robustesse de protection suffisante pour éviter à vos accès distants une potentielle compromission. Vous devriez utiliser une authentification par clefs pour vous assurer que votre utilisateur distant est protégé contre une attaque par force brute qui tentera de trouver le mot de passe de votre utilisateur.

Chez alwaysdata, la connexion SSH par mot de passe est désactivée par défaut, et seules les connexions par clefs SSH sont autorisées. Vous devez entrer vous-même votre clef publique dans le fichier ~/.ssh/authorized_keys⁶⁾. Si vous avez besoin d’activer la connexion par mot de passe malgré tout (par exemple, pour transférer votre clef publique la première fois), vous pouvez le faire en cochant la case idoine dans la section SSH de votre interface d’administration. Gardez à l’esprit que cette méthode est peu sécurisée et ne devrait pas être activée en permanence.

Si vous configurez votre serveur personnel, après avoir copié votre clef publique sur le serveur, désactivez la connexion par mot de passe dans le fichier de configuration sshd.

Certains utilisateurs et administrateurs semblent croire que ne pas utiliser de mot de passe pour protéger l’accès à leur compte est une bonne pratique. Je pense personnellement que même un mot de passe très faible est une meilleure idée que pas de mot de passe du tout. Quoi qu’il en soit, interdisez à ces utilisateurs sans mot de passe de se connecter à distance sans aucune protection.

Les mots de passe vides sont rejetés en SSH chez alwaysdata.

Utilisez des phrases de sécurité

Utiliser des clefs robustes est essentiel, mais vous ne pouvez garantir leur sécurité sans les protéger. Cela signifie que chaque clef SSH doit avoir une phrase de sécurité unique et solide. Cela s’applique aussi à vos mots de passe utilisateur, j’utilise la même technique pour les générer.

Il existe (au moins) deux façons de générer des phrases aléatoires en ligne de commande⁷⁾ :

Vous devriez disposer de openssl rand ou de gpg (voire des deux) sur votre système d’exploitation. Je vous conseille de tester la robustesse de votre mot de passe ainsi généré avec l’outil How Secure Is My Password. Vous ne voudriez pas qu’un mot de passe un peu faible compromette toute votre sécurité, n’est-ce pas ?

Utilisez des clefs de chiffrement physique

Si vous êtes vraiment soucieux de la sécurité de votre accès distant, vous devriez considérer l’utilisation d’un certificat client pour vous connecter, couplé à une clef physique. De cette façon, vous conserverez le certificat en sécurité. Vous pouvez utiliser une clef de chiffrement physique comme les Nitrokey Pro ou YubiKey 4 pour stocker vos clefs et certificats d’authentification client.

Restez à jour

Gardez votre serveur SSH à jour

Des failles SSH sont régulièrement découvertes (personne n’est jamais exempt de bogues) et corrigées rapidement par les contributeurs des projets et distributions. C’est donc toujours une bonne idée de garder votre serveur à jour. Ceci implique également de conserver votre client SSH à jour. Au moment où j’écris ces lignes, la dernière version d’OpenSSH est la 7.6 sortie le 3 oct. 2017 ^en. Vous pouvez vérifier votre version facilement :

Utilisez le protocole SSH v2

SSH dispose de deux versions de son protocole ^en. La version moderne courante est la v2. Elle est plus sûre, plus robuste, plus souple, et utilise des méthodes de chiffrement plus récentes et plus fiables. La plupart des clients supportent la v2 depuis un bon moment maintenant, donc pensez à désactiver le support de la v1 sur votre propre serveur :

Pour des raisons de compatibilité, nous proposions encore le support de la v1 chez alwaysdata. Depuis la sortie d’OpenSSH 7.6, celle-ci est désormais totalement retirée du code source (elle n’est plus activable même par le biais d’une compilation personnalisée), vérifiez donc que vous êtes à jour.

Utilisez des clefs SSH ED25519 robustes

Il existe plusieurs formats de clefs SSH. De préférence, utilisez un algorithme ED25519, puisqu’il présente le meilleur choix actuellement ^en en termes de sécurité ^en. Il est relativement récent, mais assez bien supporté ^en en production à présent, et si vous gérez votre serveur (ou passez par un prestataire de qualité), assurer son support côté serveur reste trivial.

Cette commande va :
– générer une nouvelle paire de clefs
– -a en réglant le nombre de cycles de la fonction de dérivation employée à 1000, pour augmenter le niveau de sécurité et le temps de déchiffrement. Si la vitesse d’authentification est cruciale pour vous, vous pouvez diminuer cette valeur (par défaut à 16 ; 100 offrant une protection suffisamment robuste contre des attaques de force brute)
– -t régler le format à utiliser sur l’algorithme ed25519
– -C identifier cette clef sur le modèle « nom d’utilisateur »/« appareil »

La protection réseau

Cette section contient des méthodes principalement à destination des sysadmins qui souhaitent un haut niveau de sécurisation. Elles peuvent, ou pas, s’appliquer selon vos contextes et votre modèle de menaces. Dans les faits, les deux parties ci-dessus doivent suffire pour sécuriser proprement la plupart de vos accès distants. Mais vous pouvez avoir besoin d’augmenter votre sécurité d’un cran encore.

Filtrez l’accès au port TCP avec votre pare-feu

Si vous vous connectez toujours à vos serveurs depuis un parc d’IP dédié, il est inutile (voire dangereux) de laisser n’importe quelle connexion entrante tenter des authentifications. N’hésitez pas à restreindre l’authentification SSH aux adresses connues dans vos règles de pare-feu.

Ici, nous autorisons seulement l’IP 10.111.111.10 (évidemment, substituez la vôtre) à se connecter au port 22 en TCP sur l’adresse locale de la machine (192.168.1.12) en utilisant iptables ^en8). La gestion d’un pare-feu est souvent compliquée, mais c’est une de vos défenses les plus robustes contre les attaques que vous aurez à subir.

Certaines de nos machines alwaysdata, qui sont en charge de sections privées de notre architecture, ont leur accès public filtré de cette façon. Si vous avez un VPS ou un serveur dédié, vous pouvez activer ce filtrage IP dans l’interface d’administration pour vous assurer que seules vos IPs sont autorisées à se connecter à vos serveurs.

Rejetez les attaquants SSH

L’un des problèmes provoqués par des attaquants qui tenteraient de pénétrer votre système est le nombre important de requêtes qu’ils vont générer vers votre infrastructure. Même s’ils ne parviennent pas à obtenir un accès, ces tentatives vont surcharger votre serveur SSH, probablement ralentir votre système, et peut-être aboutir à un DDoS. Pour éviter cela, vous pouvez utiliser votre pare-feu pour bloquer les IPs des machines attaquantes. Bien entendu, il n’est pas question de les bloquer manuellement. Vous devriez plutôt vous appuyer sur des outils comme fail2ban, DenyHosts, ou sur des règles de pare-feu avec iptables ou ufw pour un bannissement temporaire automatique.

Chez alwaysdata, les serveurs SSH sont protégés par un filtrage fail2ban.

Modifiez le port SSH par défaut

OpenSSH écoute sur le port 22 par défaut. Ce réglage le rend vulnérable dans le sens où les attaquants vont d’abord essayer ce port pour tenter de cibler des failles SSH. Si vous n’avez pas besoin d’une compatibilité avec des clients externes, vous devriez changer ce port par défaut et les interfaces réseau sur lesquelles le serveur SSH écoute pour réduire sa surface d’attaque.

Port knocking

C’est l’une des techniques de prévention les plus amusantes.

Cette méthode consiste à forcer l’utilisateur qui souhaite se connecter au serveur SSH à se connecter avant à une série de ports dans un ordre précis pour déclencher une règle de pare-feu qui ouvrira alors temporairement l’accès au port SSH pour votre IP. En utilisant l’outil dédié knock, vous contacterez votre serveur sur une séquence de ports. Si la séquence est correcte, le pare-feu est mis à jour et une nouvelle règle est ajoutée pour votre IP vers le port SSH. Vous pouvez alors vous connecter. Simple, sobre, élégant⁹⁾). Cette technique utilise knockd ^en.

Divers

C’est la dernière section. Félicitations d’avoir lu cet article jusqu’ici ! Elle présente des astuces pour augmenter encore un peu votre sécurité. Elles sont souvent superflues, mais il est toujours bon de les connaître.

Validez les empreintes de clefs SSH du serveur

Pour s’authentifier auprès du client, un serveur SSH présente l’empreinte de sa clef pour pouvoir être reconnu. Cette clef est générée automatiquement et appartient à une unique instance de serveur SSH. Il y a une clef par algorithme supporté, et elles sont toutes présentées au client selon ses préférences. Vous pouvez comparer cette empreinte de clef à votre première connexion avec celle indiquée dans votre interface d’administration SSH pour vous assurer que vous contactez bien le bon serveur.

Les clients modernes supportant tous ED25519 ^en, vous pouvez uniquement servir cette clef serveur et désactiver les autres clefs / méthodes sur votre serveur :

Chez alwaysdata, pour d’évidentes raisons de compatibilité, nous continuons de présenter tous les formats disponibles.

Désactivez l’accès root

L’utilisateur root de votre machine est le super administrateur de votre système Unix. Cet utilisateur a tous les droits sur votre machine, y compris l’effacer complètement¹⁰⁾. La plupart du temps, vous n’avez pas besoin d’être rooté pour vos actions courantes sur votre machine, et vos permissions système sont là pour vous permettre d’exécuter vos commandes en toute sécurité. Désactiver l’accès distant à l’utilisateur root est donc un bon réflexe, tout comme le fait de le désactiver localement et toujours utiliser sudo pour exécuter des commandes root. Ainsi, même si un utilisateur malveillant réussit à avoir accès au serveur, il ne pourra pas s’octroyer facilement les privilèges root.

Diminuez le temps de déconnexion en cas d’inactivité

Limiter le temps d’inactivité d’un utilisateur est un bon moyen de prévenir l’utilisation malicieuse qui pourrait être faite de son compte. Diminuez le nombre maximum de connexions inactives simultanées et le temps maximum d’inactivité pour vous assurer que personne ne reste plus longtemps dans le système que nécessaire.

Enfermez les utilisateurs (chroot)

Les utilisateurs authentifiés via SSH peuvent accéder à l’intégralité du système de fichiers distant. Ils sont isolés par les contraintes du système et les permissions des fichiers. Les enfermer dans leur espace utilisateur peut être une bonne idée. Malheureusement, ce n’est pas toujours facile à mettre en pratique et cela requiert souvent de s’appuyer sur des outils comme rssh ^en. C’est une configuration complexe, mais si votre modèle de menaces implique des risques de fuites de données mal protégées, c’est sans doute à considérer.

J’espère que ce long billet de blog vous a permis de mieux comprendre les enjeux liés à la protection des accès à distance. Gérer l’ensemble de la sécurité de sa pile technique nécessite des compétences avancées, notamment en cryptographie. Les conseils de cet article sont destinés à mieux vous équiper, mais ne sous-estimez pas la difficulté de sécuriser tout votre système. Travailler avec des partenaires ayant plus d’expertise reste la meilleure façon d’assurer votre protection. C’est ce que nous faisons chez alwaysdata : nous nous assurons de gérer au mieux l’arbitrage flexibilité / sécurité.

Si vous avez envie de discuter de cybersécu, je serai au Breizhcamp de Rennes vendredi pour parler de cryptographie et de développement. Faites signe !