Le durcissement d’un serveur Linux consiste à renforcer et à sécuriser un serveur Linux afin de le protéger contre les vulnérabilités et les menaces. Même si la sécurité totale est une course sans fin, cet article présente quelques mesures fondamentales que vous pouvez prendre pour assurer la sécurité de vos serveurs.
Aucun risque de sécurité n’est trop petit pour être pris en compte
Malheureusement, même les plus petites vulnérabilités peuvent se transformer en graves menaces pour la sécurité. Il est important de se rappeler que tout code exécuté sur votre système peut potentiellement contenir des failles permettant à des intrus d’accéder à un shell de commande ou à des utilisateurs légitimes d’élever leur accès pour avoir des droits de superutilisateur. Quel que soit le niveau de risque, il est toujours préférable de traiter les petits risques de sécurité avant qu’ils ne se transforment en menaces de cybersécurité majeures, en suivant un processus de durcissement de serveur. Grâce au durcissement des serveurs Linux, les équipes informatiques peuvent renforcer leurs défenses avant que des problèmes ne surviennent, ce qui permet d’éviter des incidents majeurs.
Mises à jour du système et correctifs de sécurité
La mise à jour régulière de votre serveur Linux est essentielle au maintien de sa sécurité et de son intégrité, d’autant plus que 57% des compromissions externes proviennent de systèmes qui ne sont pas à jour. Les logiciels et les systèmes d’exploitation sont constamment améliorés et perfectionnés pour remédier aux vulnérabilités et aux points faibles. En appliquant rapidement les mises à jour, vous vous assurez que les failles de sécurité connues sont éliminées, ce qui réduit les cybermenaces. De plus, les mises à jour comprennent souvent des corrections de bugs et des améliorations des performances, ce qui permet d’obtenir un environnement de serveur plus stable et plus efficace. Le fait de ne pas procéder à des mises à jour régulières peut exposer le système à des attaques et compromettre son intégrité.
Utiliser des logiciels obsolètes et avoir des vulnérabilités non corrigées présente des risques importants pour vos serveurs Linux. Les cybercriminels ciblent activement les vulnérabilités connues pour obtenir un accès non autorisé, compromettre des données ou perturber des services. Lorsque des vulnérabilités sont divulguées publiquement, des personnes malveillantes peuvent les exploiter pour compromettre des systèmes qui n’ont pas reçu de mises à jour. Retarder les mises à jour augmente les possibilités pour les attaquants d’exploiter les faiblesses des défenses de vos serveurs, c’est pourquoi la mise à jour régulière une mesure de défense essentielle.
Choisir les bonnes stratégies de gestion des correctifs et les bonnes pratiques pour la gestion des correctifs de votre serveur est crucial pour maintenir la sécurité d’un serveur Linux. Les distributions Linux actuelles destinées aux entreprises disposent généralement toutes d’un service de gestion automatisée des correctifs, qu’il s’agisse d’un service d’abonnement payant ou d’efforts de la part de la communauté. Les services payants ne se contentent souvent pas de patcher les fichiers de votre système pour en assurer la sécurité; certains de ces services incluent également une solution pour patcher en direct votre noyau (kernel) en cours d’exécution, ce qui permet à vos systèmes en cours d’exécution de rester patchés avant même que vous n’ayez besoin de les redémarrer.
Introduction aux gestionnaires de paquets
Les gestionnaires de paquets diffèrent d’une distribution à l’autre, mais tendent à utiliser deux formats de paquets principaux : DEB et RPM. DEB est utilisé sur les systèmes basés sur Debian et est géré par apt; RPM signifie Redhat Package Manager et est géré par dnf ou yum pour les systèmes basés sur Red Hat/Enterprise Linux ou par zypper pour SUSE. Tous les gestionnaires de paquets facilitent l’installation, la mise à jour et la suppression des paquets logiciel, en plus de résoudre les dépendances. Utilisez les gestionnaires de paquets pour gérer efficacement les logiciels et optimiser le processus de mise à jour. Tous les principaux gestionnaires de paquets sont également pris en charge par des dépôts à distance, ce qui vous permet de centraliser le contrôle des mises à jour et des déploiements de logiciels.
Configuration des mises à jour automatiques pour les correctifs de sécurité critiques
Configurer votre serveur Linux pour qu’il installe automatiquement les correctifs de sécurité critiques garantit que les mises à jour prioritaires sont appliquées rapidement sans intervention manuelle, ce qui minimise la fenêtre de vulnérabilité et réduit la charge de travail des administrateurs. Les distributions d’entreprise permettent généralement de configurer cette fonction lors de l’installation. Voir les paquets de configuration ci-dessous, si vous souhaitez mettre cela en place sur votre système existant :
Ubuntu : sudo apt install unattended-upgrades
Red Hat/CentOS : sudo yum install dnf-automatic
SUSE : sudo zypper install yast2-online-update-configuration -> ouvrez YaST, sélectionnez Software -> Online Update Configuration, puis configurez-le selon vos préférences.
Il convient toutefois d’être prudent lors de l’activation des mises à jour automatiques, qui peuvent avoir un impact sur la stabilité du système ou nécessiter des tests de compatibilité. Les tests sont particulièrement importants lors de l’utilisation d’outils d’administration de masse à distance tels qu’ansible ou puppet pour effectuer des mises à jour de serveurs dans un environnement informatique hétérogène.
Configuration de l’élévation sudo et de l’accès au shell
Il est essentiel de configurer correctement les comptes d’utilisateurs et les autorisations pour disposer d’un système sécurisé qui permette l’accès à tous les utilisateurs. Les permissions qui n’ont pas été configurées correctement peuvent créer des problèmes, il est donc préférable de s’assurer qu’elles sont configurées correctement dès le départ.
L’utilisation de la commande sudo à son plein potentiel avec la bonne configuration /etc/sudoers, vous permet de limiter et d’autoriser les droits d’accès à la racine sans mot de passe pour chaque application. Utilisez toujours la commande visudo pour modifier /etc/sudoers afin de maintenir les autorisations correctes sur ce fichier critique:
sudo visudo
Effectuez des modifications similaires à celles-ci, en remplaçant « ninja » par votre nom d’utilisateur et en adaptant la liste des commandes autorisées, séparées par des virgules, à votre cas d’utilisation :
someuser ALL=(ALL:ALL) ALL
en
someuser ALL = NOPASSWD : /bin/systemctl restart nginx, /bin/kill, /usr/sbin/reboot
Ensuite, enregistrez et quittez. Notez que sudo lit effectivement le fichier /etc/sudoers de bas en haut, donc si vos modifications ne semblent pas efficaces, essayez de déplacer la ligne que vous avez modifiée vers le bas du fichier sudoers.
A propos des shells (interpreteurs de commandes)
Vous pouvez définir l’interpréteur de commandes par défaut d’un utilisateur en exécutant la commande chsh en tant que super-utilisateur, ou en masse en modifiant le fichier /etc/passwd en tant qu’utilisateur root ou superuser (super-utilisateur). C’est utile et souhaitable dans certains cas, par exemple pour modifier l’interpréteur de commandes (shell) par défaut d’un compte FTP en /sbin/nologin; car un tel compte ne devrait jamais avoir besoin d’exécuter des commandes de terminal. Dans ce cas, la suppression de l’accès au shell réduirait la surface d’attaque potentielle du système.
Sécuriser l’accès SSH avec des clés et désactiver le login root
Secure Shell (SSH) est un protocole réseau standard qui permet l’accès à distance à un système au niveau de la ligne de commande. Il est donc essentiel de permettre l’accès SSH uniquement aux utilisateurs nécessaires et de s’assurer que seuls les bons utilisateurs peuvent effectuer des opérations en tant qu’utilisateur root ou superuser (super utilisateur).
Bonnes pratiques pour sécuriser l’accès SSH aux serveurs Linux
Il est généralement conseillé de désactiver complètement la connexion root via SSH et l’accès SSH par mot de passe. Bien que le texte du mot de passe dans l’authentification par mot de passe soit transmis de façon chiffrée par les clés hôte SSH qui sont échangées lors de la poignée de main client/serveur SSH avant l’ouverture de session, le mot de passe est néanmoins transmis sur plusieurs réseaux d’une manière ou d’une autre. Il s’agit d’un autre aspect de la surface d’attaque : si les clés d’hôte de votre serveur SSH ont été générées à l’aide d’un algorithme ancien/non sécurisé, par exemple, il est possible d’espionner vos mots de passe.
Les connexions par clé SSH ne sont pas vulnérables à ce type d’attaque; vos clés publiques sont les seules parties qui sont transmises en « texte clair », et elles ont été conçues pour être distribuées publiquement. Tout comme votre clé privée, la phrase secrète (ou « phrase de passe ») que vous utilisez pour la déverrouiller lors de la connexion à la clé SSH n’est pas transmise sur le réseau.
Utiliser les clés SSH pour l’authentification
À noter que les extraits de code ci-dessous sont annotés par les commentaires de l’auteur, qui sont indiqués par « ## » pour plus de visibilité.
- Générez une clé SSH à l’aide de la commandessh-keygen. Par défaut, le format de clé de chiffrement RSA standard est utilisé, mais il est recommandé d’utiliser le chiffrement à courbe elliptique ed25519, plus rapide et plus sûre.
user@host:~> ssh-keygen -t ed25519 Génération d'une paire de clés publiques/privées ed25519. Saisissez le fichier dans lequel vous souhaitez enregistrer la clé (/home/user/.ssh/id_ed25519) : Saisissez la phrase secrète d'authentification (laisser vide en cas d'absence de phrase secrète) : Saisissez à nouveau la même phrase secrète d'authentification : Votre identification a été sauvegardée dans /home/user/.ssh/id_ed25519 Votre clé publique a été enregistrée dans /home/user/.ssh/id_ed25519.pub L'empreinte de la clé est : SHA256:NjPk3GbSIL6wdITiSrEQ3U9uXqqaYJdtS62cwCahKoM user@host L'image randomart de la clé est : +--[ED25519 256]--+ |.. . | | .. ... | | ... .+o o | .. |..o. o+=.+ |.. | +. ooooS = | |o.o.o++o B | |=o *.=.. | |E.+.* + | |o.o. = | +----[SHA256]-----+ user@host:~>
- Copiez votre clé publique sur votre plateforme d’hébergement en ligne. Si vous avez toujours un accès par mot de passe au serveur en question, vous pouvez utiliser la commande ssh-copy-id pour configurer automatiquement les fichiers de configuration SSH de votre compte avec votre clé SSH nouvellement générée copiée aux bons endroits:
ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@remotehost
- Différentes façons d’utiliser les clés SSH pour se connecter :A) Directement dans la ligne de commande :
ssh -i ~/.ssh/id_ed25519 remoteuser@remotehost:port
OU en utilisant le fichier ~/.ssh/config :
- Editez votre fichier ~/.ssh/config avec n’importe quel éditeur de texte. Faites-le en tant que compte/utilisateur qui utilisera la configuration SSH pour se connecter à distance.
- Ajoutez des lignes avec le format suivant :
Host server1 ## Arbitrary label/handle for easy usage Hostname server1.example.com ## Real hostname/IP User remote_user_1 ## Remote Linux username Port 12345 ## Remote port, default 22 IdentityFile ~/.ssh/id_ed25519 ## NB! Private key file ForwardX11 yes ## Optional, forwards remote GUI apps Host server2 Hostname server2.example.com User remote_user_2 Port 34567 IdentityFile ~/.ssh/id_ed25519
Les stanzas doivent être séparés par des espaces verticaux. - Vous pouvez maintenant utiliser le SSH en tapant simplement :
ssh serveur1
Puisque tout le reste est spécifié sous cette étiquette de stanza dans votre fichier .ssh/config. Astuce : si vous avez adopté la complétion tabulaire de Linux (alias la complétion bash), vous serez heureux d’apprendre que votre fichier de configuration SSH se branche automatiquement sur les systèmes de complétion bash de la plupart des distros Linux modernes.
Désactiver la connexion root SSH et l’authentification par mot de passe
- Assurez-vous IMPERATIVEMENT que vous pouvez vous connecter avec votre clé SSH. Vous pouvez potentiellement vous bloquer hors de votre système si cela ne fonctionne pas correctement.
- Utilisez votre éditeur favori en tant que root pour modifier les lignes suivantes dans /etc/ssh/sshd_config avec les paramètres suivants:
PermitRootLogin no ChallengeResponseAuthentication no PasswordAuthentication no KbdInteractiveAuthentication no
- Il est possible de faire fonctionner votre serveur SSH sur un port non standard :
Port 12345
- Enregistrez ce fichier et relancez votre service SSH :
sudo systemctl restart sshd
- Essayez maintenant de vous connecter via SSH sans la clé SSH :
ssh remote_user_1@server1 [-p port]
Si vous ne pouvez pas vous connecter sans spécifier de clé SSH, vous avez effectué cette étape correctement.
Implémentation d’un pare-feu sur les serveurs Linux
Si vous exploitez un serveur Linux de production et que votre distribution est livrée avec un pare-feu préconfiguré, vous avez pris un bon départ. Lorsque les données d’un serveur de production sont exposées à l’internet, il est préférable de les protéger avec un pare-feu. Les variantes Enterprise Linux/Red Hat ont tendance à être livrées avec firewalld, tandis que Debian/Ubuntu sont livrées avec ufw (« Uncomplicated Firewall »). Consultez la page de manuel de firewall-cmd ou la page de manuel de ufw pour plus de détails.
Configuration des règles et des politiques de pare-feu
Une fois que l’on a dépassé les détails, les règles et politiques de pare-feu devraient se résumer à « bloquer tout, sauf ce que j’autorise spécifiquement ». Encore une fois, ces règles sont généralement préconfigurées par défaut sur les systèmes Linux modernes, en particulier sur les variantes d’Enterprise Linux. Tout cas d’utilisation non couvert par ces valeurs par défaut n’entre pas dans le champ d’application du présent document.
Surveillance et gestion de pare-feu
- Firewalld et ufw se branchent tous les deux sur les principaux systèmes de journalisation journald et/ou [r]syslog.
- Outre les outils de gestion de pare-feu en ligne de commande firewall-cmd et ufw, , d’autres frontends de gestion à distance tels que Cockpit, WebMin et YaST proposent des modules qui permettent de gérer les pare-feu. D’autres outils de gestion à distance, comme ansible et puppet, disposent également de modules pour la configuration et la gestion automatiques des pare-feux.
Sécurisation des services en contact avec le réseau
Bonnes pratiques pour sécuriser les services en contact avec le réseau :
- Il doit y avoir le moins de code possible sur votre système.
- Exécutez le minimum de services possible.
- N’exécutez pas un service grand public en tant qu’utilisateur root.
- Les serveurs n’ont pas besoin d’une interface graphique. Code étranger et services en cours d’exécution = augmentation de la surface d’attaque.
- Les services Linux reposent sur la sécurisation du système par des certificats de chiffrement. Certbot/Let’s Encrypt propose la procédure la plus simple pour générer des certificats de chiffrement gratuits.
- La plupart des services Linux écoutent sur des ports distincts pour leurs connexions sécurisées et non sécurisées. Pour plus de détails sur la sécurité et les autres options de configuration, veuillez consulter les pages de manuel de ces services.
- Vous pouvez utiliser la commande netstat -tulpen pour voir les ports que votre système écoute (que ces ports soient ou non bloqués par votre pare-feu; cette commande affiche les ports d’écoute en fonction des processus)
Le minimalisme est aussi important que l’action pour la sécurité des serveurs Linux
Il vaut mieux faire les bons choix dès le départ et dans le monde actuel, connecté au cloud, choisir la bonne distribution de serveurs Linux et de solutions de gestion à distance est plus important que jamais. Le logiciel de gestion à distance Linux intégré de NinjaOne vous donne la liberté d’utiliser n’importe quelle plateforme de système d’exploitation tout en restant sécurisé et à jour.
On peut affirmer sans hésiter que l’infrastructure technologique de la majorité des PME comprend quelques serveurs Linux dans le cadre de leur infrastructure critique. Si vous avez un site web, il y a de fortes chances qu’il tourne sur un serveur Linux; si vous utilisez des services bancaires en ligne, il y a de fortes chances qu’ils dépendent de la sécurité de dizaines de serveurs Linux. Étant donné qu’Android lui-même est (en simplifiant à l’extrême) un noyau Linux surmonté d’une interface graphique, si vous lisez ceci sur un smartphone, la question de la sécurité de Linux peut être littéralement plus proche de vous que vous ne le pensez.
