La sécurité des serveurs est un enjeu majeur pour les entreprises. En effet, étant un élément central dans le fonctionnement de toutes les composantes d’un système d’information (applications, réseau, infrastructure, collaborateurs, etc.), les serveurs sont souvent les cibles privilégiées d’attaques.
Par ailleurs, des vulnérabilités côté serveur peuvent avoir des conséquences sévères. En cas de mauvaise configuration ou de défaut de contrôle, ces failles peuvent être exploitées et conduire à la compromission des données qui y transitent, voire à la prise en main du serveur par des personnes malveillantes.
Pourquoi la sécurité des serveurs est importante ?
Les cas d’attaques de serveurs sont quotidiens car, très souvent, de nombreuses brèches existent. En effet, des applications vulnérables à des injections SQL hébergées sur un serveur, des utilisateurs peu sensibilisés aux risques d’ingénierie sociale ou, tout simplement, de mauvaises pratiques en matière de mises à jour et de gestion des correctifs du système d’exploitation et des services d’un serveur, permettent facilement aux attaquants de parvenir à leurs fins : vol de données, accès à des informations sensibles, paralysie de l’activité d’une entreprise, etc.
Sécuriser un serveur est donc vital et cela passe nécessairement par l’implémentation des meilleures pratiques en termes de configuration, de contrôle, de suivi et de tests sécurité.
Cet article ne vise pas l’exhaustivité. Il abordera la sécurité des serveurs uniquement sous l’angle des bonnes pratiques, avec quelques informations complémentaires sur les risques, les types d’attaques et les vulnérabilités qui peuvent être exploitées par des attaquants pour compromettre un serveur.
Politique de mise à jour et de gestion des correctifs, hardening, contrôle et sécurité des accès et de l’administration (via SSH notamment), bonnes pratiques de logging et de monitoring, tests d’intrusion, etc., nous présentons ici les mesures principales pour renforcer la sécurité la sécurité de vos serveurs.
Mettre en œuvre une politique de mise à jour et de gestion des correctifs des serveurs
Mettre en œuvre une politique de gestion des mises à jour des systèmes d’exploitation et des services est essentiel pour maintenir un bon niveau de sécurité. En effet, de nouvelles vulnérabilités sont découvertes et publiées régulièrement. Et si les correctifs de sécurité ne sont pas appliqués à temps, les risques d’attaques et de compromission des serveurs augmentent.
Les nombreuses attaques subies par les entreprises, via des malwares notamment, suite à la publication d’un patch d’un protocole, un logiciel, d’un système d’exploitation, etc., doivent pousser tout type d’organisation à adopter une posture proactive, d’autant plus que les informations sur les vulnérabilités et exploitations sont publiées et donc accessibles à des attaquants internes comme externes.
Par ailleurs, il est vrai qu’il est recommandé de faire preuve de prudence lorsqu’il s’agit d’installer des mises à jour logicielles, car des tests sont toujours nécessaires, voire indispensables. Cependant, il est généralement peu judicieux car plus risqué de retarder ce processus, car une attitude passive mène très souvent à la compromission des systèmes d’information.
Ainsi, il est donc important de définir et mettre en œuvre une politique de mise à jour et de gestion des correctifs des serveurs et de toutes les composantes logicielles et matérielles du SI. Cela passe par une documentation des procédures et un suivi continu via une veille sur les différentes releases de patchs ou de nouvelles versions.
Désactiver ou supprimer les services inutiles
Tout logiciel et composants installés sur un système d’exploitation augmente la surface d’attaque, donc le risque de compromission. Cependant, renforcer la sécurité des serveurs passe impérativement par une réduction de cette surface d’attaque. Pour ce faire, il est nécessaire de désactiver voire de supprimer (dans la mesure du possible) tous les services, applications, protocoles réseau, composants tiers, etc. qui ne sont pas essentiels au fonctionnement de votre serveur.
Supprimer ou désactiver les systèmes inutiles renforce la sécurité d’un serveur de plusieurs façons. En premier lieu, ils ne peuvent ni être compromis, ni servir de vecteurs d’attaques pour altérer les services essentiels au fonctionnement du serveur. Il faut en effet garder à l’esprit que chaque composant ajouté à un serveur augmente le risque de compromission de ce dernier. De plus, le serveur peut être configuré pour mieux répondre aux exigences d’un service particulier, tout en améliorant les performances et le niveau global de sécurité. Enfin, réduire les services c’est limiter le nombre de journaux et d’entrées de logs, ce qui facilite le monitoring donc la détection d’événements inhabituels.
Contrôler et sécuriser les accès au serveur : Focus sur SSH
Présentation de SSH : outil incontournable pour assurer une bonne gestion et une administration sécurisée du serveur
SSH (Secure Shell) est à la fois un protocole de communication et un programme informatique permettant l’administration en local et à distance d’un serveur. Son implémentation la plus couramment rencontrée est OpenSSH, que l’on retrouve sur un grand nombre de systèmes, aussi bien des serveurs (Unix, Linux, Windows) que des postes de travail ou des équipements réseau.
En effet, OpenSSH est une suite d’outils offrant de nombreuses fonctionnalités, avec notamment : un serveur (sshd), plusieurs clients – connexion shell distante (ssh) / transfert et téléchargement de fichiers (scp et sftp), un outil de génération de clés (ssh-keygen), un service de trousseau de clés (ssh-agent et ssh-add), etc.
Par ailleurs, SSH existe aujourd’hui en deux versions : SSHv1 et SSHv2. SSHv1 contient des vulnérabilités qui ont été corrigées dans la version 2. Ainsi, pour une sécurité renforcée seule la version 2 du protocole SSH doit être autorisée.
La fonctionnalité de SSH la plus utilisée est l’administration à distance, qui consiste à se connecter à une machine distante et à lancer une session shell suite à une authentification. Sur ce point, l’avantage apporté par SSH est sa sécurité. Une autre fonctionnalité couramment utilisée concerne le transfert et le téléchargement de fichiers, à la fois d’un client vers un serveur et d’un serveur vers un client. Pour ce faire, SSH propose deux mécanismes : SCP et SFTP, qui doivent toujours être préférés aux anciens protocoles tels que RCP et FTP.
Authentification par clé publique / certificat
Ne pas s’assurer de l’authenticité d’un serveur peut avoir de nombreux impacts sur la sécurité, notamment l’impossibilité de vérifier que l’on communique bien avec le bon serveur, avec des risques d’usurpation donc, et l’exposition aux attaques Man in The Middle.
SSH repose sur le chiffrement asymétrique pour l’authentification, et permet donc de s’assurer de la légitimité du serveur contacté avant de poursuivre l’accès. Par ailleurs, ce contrôle se fait de plusieurs façons avec OpenSSH. Soit en s’assurant que l’empreinte de la clé publique obtenue préalablement avec ssh-keygen et présentée par le serveur est la bonne, ou en vérifiant la signature du certificat présenté par le serveur avec une autorité de certification reconnue par le client.
Algorithmes et tailles de clés recommandés
La qualité des clés est un aspect important de la sécurité d’un serveur. Il existe plusieurs algorithmes et tailles de clés exploitables par SSH. Cependant, tous ne se valent pas en matière de sécurité.
Dans la pratique, notons que les clés permettant d’authentifier un serveur SSH sont souvent peu renouvelées. Il est donc important de choisir dès le départ des clés de taille suffisamment grande. Cependant, l’implémentation DSA présente dans OpenSSH est limitée à une taille de clé de 1024 bits, ce qui est insuffisant. De fait, l’usage de clés DSA n’est pas recommandé car la taille de clé minimale doit être de 2048 bits pour les clés RSA ou de 256 bits pour les clés ECDSA.
Pour plus d’informations, nous vous renvoyons vers le guide de selection d’algorithmes de chiffrement de l’ANSSI.
Droits d’accès et diffusion des clés
Les clés d’authentification SSH peuvent être regroupées en deux catégories : celles utilisées pour l’authentification d’utilisateurs et celles dédiées à l’authentification du serveur. Et comme son qualificatif l’indique, une clé privée doit être secrète et protégée pour éviter la diffusion à une personne non autorisée. En effet, elle ne doit être connue de l’entité qui cherche à prouver son identité à un tiers et éventuellement d’une autorité de confiance.
Par ailleurs, les mesures de sécurité applicables vont légèrement varier suivant qu’il s’agisse d’une clé serveur ou d’une clé utilisateur. Ainsi, une clé privée d’authentification serveur ne doit être lisible que par le service sshd, tandis qu’une clé privée d’authentification utilisateur ne doit être lisible que par l’utilisateur auquel elle est associée. Et comme le risque d’une utilisation frauduleuse de la clé privée générée pour un utilisateur est réel, le stockage de cette clé doit être sécurisé, donc chiffré.
Choix des algorithmes symétriques
Suite à une authentification réussie, le canal de communication doit être protégé, donc chiffré. L’algorithme de chiffrement des données doit reposer sur de l’AES 128, AES 192 ou AES 256. Et pour assurer l’intégrité, des algorithmes de hash tels que HMAC SHA-1, SHA-256 ou SHA-512 doivent être utilisés.
Par ailleurs, le choix des algorithmes étant établi suivant une négociation entre le client et le serveur, la liste des algorithmes doit être fixée des deux côtés et les algorithmes considérés comme faibles doivent être retirés.
Sécurité de l’authentification et contrôle des accès utilisateurs
Les utilisateurs d’un système disposent toujours de droits, aussi minimes soient-ils. Il est donc important de protéger leurs accès via un mécanisme d’authentification sécurisé et de déjouer autant que possible les attaques brute force.
En premier lieu, chaque utilisateur doit disposer de son propre compte afin d’assurer une meilleure traçabilité et l’attribution des droits d’accès doit toujours suivre le principe du moindre privilège. De plus, les accès à un service doivent être restreints aux utilisateurs qui en ont un besoin justifié et qui sont explicitement autorisés.
Concernant les utilisateurs autorisés à configurer le système d’exploitation des serveurs, ils doivent être limités à un petit nombre d’administrateurs désignés.
Par ailleurs, il est fortement déconseillé d’utiliser des mécanismes d’authentification dans lesquels les informations d’authentification sont transmises en clair sur un réseau, car ces informations peuvent être interceptées, via des attaques Man In the Middle et utilisées par un attaquant pour se faire passer pour un utilisateur autorisé.
Enfin, pour assurer une authentification sécurisée des utilisateurs, les mesures suivantes doivent être appliquées :
- Suppression des comptes par défaut car la configuration par défaut du système d’exploitation comprend souvent des comptes invités, des comptes administrateur et des comptes associés aux services. Les noms et les mots de passe de ces comptes sont connus des attaquants.
- Implémentation d’une bonne politique de mots de passe. Tous les mots de passe doivent être complexes et difficiles à deviner. Ils doivent surtout être longs (supérieur à 15 caractères). Pour ce faire, rien de mieux que l’implémentation d’un gestionnaire de mots de passe.
Configurer et contrôler les accès aux ressources
Tous les systèmes d’exploitation de serveurs permettent de configurer les privilèges d’accès aux fichiers, répertoires, périphériques et autres ressources.
Pour sécuriser votre serveur, il est indispensable de définir minutieusement les contrôles d’accès et de refuser automatiquement tout accès non autorisé afin de réduire les failles de sécurité intentionnelles et non intentionnelles. Par exemple, refuser l’accès en lecture aux fichiers et aux répertoires contribue à protéger la confidentialité des informations, et le fait de refuser l’accès en écriture peut contribuer à maintenir l’intégrité des informations.
Implémenter fail2ban pour contrer les attaques brute force
Un attaquant qui souhaite obtenir un accès à un serveur dispose de plusieurs options pour parvenir à ses fins. L’une des techniques les plus simples à mettre en œuvre et les plus courantes est l’attaque par brute force. Dans ce cas de figure, un attaquant utilise des outils pour envoyer un flux continu de valeurs d’identifiant et de mots de passe afin de tester toutes les combinaisons possibles, via un processus d’essais et d’erreurs pour espérer deviner juste.
Cependant, la mise en œuvre d’une bonne politique de mots de passe rend facilement cette technique d’attaque inopérante. Au-delà de cette mesure, une autre option essentielle doit être implémentée : l’outil Fail2ban. En effet, un aspect important de la sécurité des serveurs concerne l’enregistrement et la gestion des logs. Dans cette optique, chaque tentative de connexion doit être enregistrée et traitée dans des journaux de logs du serveur.
Ainsi, Fail2ban permet de vérifier les logs, de détecter les comportements inhabituels et de bloquer l’adresse IP des utilisateurs suspects.
Logging et monitoring des événements serveurs
La journalisation (logging) est un aspect central dans une stratégie sécurité. Il s’agit d’un mécanisme de contrôle qui permet de surveiller le réseau, les systèmes et les serveurs ; et surtout d’assurer la traçabilité de tous les événements normaux comme suspects. En effet, les fichiers de logs peuvent être utilisés pour suivre les activités d’un attaquant et ainsi détecter des événements inhabituels ou des tentatives d’intrusion échouées ou réussies.
Pour faciliter la gestion et l’exploitation des logs, il convient de les centraliser sur un serveur dédié. Ceci est d’autant plus important car, dans l’éventualité de compromission d’une machine, il est probable que les logs soient détruits ou altérés par l’attaquant. Centraliser, sauvegarder régulièrement et dupliquer les logs permettra alors de toujours garder une copie. Et étant donné leur importance, il est essentiel de restreindre l’accès aux logs aux seules personnes autorisées.
Pour plus d’informations sur le principe et les bonnes pratiques de logging et monitoring, vous pouvez consulter notre article : Logging et Monitoring : définition et bonnes pratiques.
Sécuriser les APIs, sites et applications web hébergés sur un serveur
Les APIs, sites et applications web hébergés sur un serveur doivent également être sécurisés. En effet, ces derniers peuvent servir de vecteurs d’attaques pour compromettre le serveur s’ils sont vulnérables à des injections SQL par exemple.
Nous avons longuement traité la question de la sécurité des applications dans un article précédent. Nous vous invitons à le consulter pour avoir une vision d’ensemble des bonnes pratiques à implémenter, en termes de réduction de surface d’attaque, de sécurité de l’authentification, de protection des données, etc. : comment sécuriser un site ou une application web ?
Et pour plus d’informations sur les failles inhérentes aux applications web, nous vous renvoyons vers notre article : comment renforcer la sécurité de vos applications web pour contrer les attaques les plus courantes ?
Enfin, concernant les vulnérabilités spécifiques aux APIs, vous pouvez consulter notre article : comment renforcer la sécurité de vos APIs pour contrer les attaques les plus courantes ?