Gestion des serveurs Linux : application de correctifs, surveillance et sécurité pour les MSP

La plupart des MSP fonctionnent sous Windows. La plupart des clients utilisent Windows. Mais le parc de serveurs qui soutient ces clients est de plus en plus hétérogène : Linux alimente discrètement les serveurs web, les backends d'applications, les serveurs de bases de données, les plateformes de conteneurs et les charges de travail natives du cloud dont dépendent les clients Windows. Que le MSP souhaite ou non gérer Linux, ce système d'exploitation est présent dans l'environnement.

Les MSP qui maîtrisent ce sujet considèrent Linux comme un élément à part entière de leur infrastructure de gestion. Ils appliquent la même rigueur en matière de correctifs, la même couverture de surveillance, les mêmes mesures de renforcement de la sécurité et la même stratégie de sauvegarde sur les deux systèmes d’exploitation, si possible à partir d’une seule et même console. Les MSP qui ne parviennent pas à mettre cela en place se retrouvent avec des serveurs Linux gérés selon un savoir-faire empirique, corrigés manuellement quand quelqu’un s’en souvient, surveillés par les scripts Bash écrits par le dernier ingénieur en date, et sauvegardés selon la configuration mise en place il y a des années par le propriétaire de l’application.

Ce guide présente les aspects pratiques de la gestion des serveurs Linux, les différences entre cette discipline et celle de Windows, ainsi que la manière dont les MSP peuvent gérer ces deux systèmes d'exploitation à partir d'un modèle opérationnel unifié.

Qu'est-ce que la gestion des serveurs Linux ?

La gestion des serveurs Linux consiste à veiller à ce que ces derniers soient correctement mis à jour, surveillés, sécurisés, sauvegardés et en bon état de fonctionnement tout au long de leur cycle de vie. Elle s'applique aussi bien aux serveurs physiques qu'aux serveurs virtuels, qu'ils soient hébergés sur site ou dans le cloud, ainsi qu'aux environnements utilisant une seule distribution ou un parc mixte, qu'ils fonctionnent sous Ubuntu Server, RHEL, Debian ou Amazon Linux.

Le champ d'application reprend en principe celui de la gestion des serveurs Windows. Il faut appliquer les correctifs. Il faut surveiller les services. Il faut examiner les journaux. Il faut vérifier les sauvegardes. Il faut renforcer les configurations. Les mécanismes sont toutefois différents, et c'est là que les MSP habitués à des environnements exclusivement Windows rencontrent des difficultés.

En quoi la gestion des serveurs Linux diffère-t-elle de celle des serveurs Windows ?

Trois différences sont particulièrement importantes.

Le premier concerne la gestion des paquets. Les mises à jour Windows sont fournies via Windows Update ou WSUS, un canal de mise à jour unique pour le système d'exploitation et les applications Microsoft. Les distributions Linux utilisent des gestionnaires de paquets (apt pour Debian et Ubuntu, dnf ou yum pour RHEL, CentOS et Fedora, zypper pour SUSE) qui gèrent les mises à jour du système d'exploitation, les mises à jour des applications et la résolution des dépendances à partir d'un seul outil. Le processus de correction est différent, les dépôts de paquets sont différents et les conséquences d'une mise à jour échouée sont différentes.

Le deuxième aspect concerne la culture de gestion des configurations. Les environnements Windows s’appuient largement sur une interface graphique et sont gérés par des stratégies de groupe. Les environnements Linux s’appuient quant à eux largement sur des fichiers de configuration et sont souvent gérés via Ansible, Puppet, Chef ou des scripts shell. Un MSP qui ne dispose pas d’une base de référence de configuration documentée pour un serveur Linux hérite de l’état laissé par le propriétaire précédent, sans pouvoir s’appuyer sur l’équivalent d’une stratégie de groupe.

Le troisième est le silence de l'échec. Un service Windows défaillant se manifeste généralement via l'Observateur d'événements, le SCM ou un signal clair dans l'interface utilisateur. Un service Linux défaillant écrit dans un fichier journal, se termine avec un code d'état différent de zéro, puis reste silencieux. Si personne ne consulte ces journaux, personne ne sait que le service a cessé de fonctionner. La rigueur en matière de surveillance est plus importante sous Linux que sous Windows, car le système d'exploitation lui-même fait moins d'efforts pour signaler un problème.

Gestion des correctifs sous Linux

La gestion des correctifs sous Linux est l'aspect le plus fréquent et le plus critique en matière de sécurité. Kaseya VSA 10 prend en charge la gestion des correctifs sur les principales distributions Linux, en automatisant les processus de détection, de planification, de validation et de déploiement que nécessitent les mises à jour manuelles des paquets.

Certains points méritent une attention particulière.

Les mises à jour du noyau nécessitent un redémarrage et doivent être programmées pendant les fenêtres de maintenance, parallèlement aux vérifications de redémarrage des services. Les options de correction à chaud du noyau, telles que Canonical Livepatch ou kpatch, peuvent réduire la fréquence des redémarrages sur les hôtes critiques, mais elles ne remplacent pas les redémarrages planifiés : elles ne font que les reporter.

Les mises à jour d'OpenSSL et des bibliothèques cryptographiques ont des répercussions sur un grand nombre d'applications qui en dépendent. Une faille de sécurité de type Heartbleed dans OpenSSL affecte tous les services qui y sont liés, et un correctif déployé sans redémarrer ces services laisse l'ancienne version de la bibliothèque chargée en mémoire. La gestion des correctifs sous Linux implique de suivre ce qui est corrigé sur le disque et ce qui est réellement en cours d'exécution.

Les serveurs Web, les bases de données et autres logiciels d'application (Apache, Nginx, MySQL, PostgreSQL, Redis) s'appuient sur le système d'exploitation, mais suivent leur propre rythme de mise à jour et disposent de leurs propres flux CVE. Les gestionnaires de paquets des distributions gèrent les paquets de base, mais les environnements de production ont souvent recours à des dépôts fournis par les éditeurs ou à des images de conteneurs qui doivent être suivis séparément.

Les utilitaires système présentant un historique de vulnérabilités (sudo, polkit, glibc, systemd) sont souvent la cible d'attaques visant à l'escalade de privilèges. Ils font l'objet de correctifs selon des cycles réguliers, mais il convient de les signaler dans le cadre de la gestion des changements, car une mise à jour manquée concernant une vulnérabilité CVE de sudo peut transformer un point d'ancrage à faibles privilèges en un accès root complet.

Surveillance et observabilité sous Linux

La surveillance des serveurs Linux couvre quatre domaines : les ressources système, la disponibilité des services, l'activité des journaux et l'intégrité des fichiers.

La surveillance des ressources système permet de suivre la charge du processeur, la pression sur la mémoire, l'utilisation du disque (tant en termes d'espace que d'E/S), l'utilisation de l'espace d'échange et le débit réseau. Le remplissage du disque est la cause la plus fréquente de défaillance des services sous Linux ; les répertoires de journaux ou les journaux de transactions de bases de données qui saturent le volume racine peuvent provoquer la panne de l'ensemble du système hôte sans avertissement préalable. La mise en place d'alertes de seuil pour l'utilisation du disque est indispensable.

La surveillance de la disponibilité des services permet de vérifier que les processus que le serveur est censé exécuter sont bien en cours d'exécution et répondent aux requêtes. Un service systemd répertorié comme actif mais qui a cessé de répondre aux requêtes n'apparaît pas dans la commande `systemctl status` ; il faut alors effectuer une vérification externe pour détecter la défaillance. Les vérifications HTTP, de connexion à la base de données et des ports TCP constituent la base de référence.

La surveillance des journaux couvre les journaux système (journald, /var/log/syslog, /var/log/messages), les journaux d'application (journaux d'accès et d'erreurs du serveur web, journaux des requêtes lentes de la base de données) et les journaux de sécurité (événements d'authentification, exécutions de sudo, tentatives de connexion SSH). Les anomalies détectées dans ces journaux constituent souvent le premier signe d'une intrusion.

La surveillance de l'intégrité des fichiers permet de détecter toute modification non autorisée des fichiers système critiques. Des outils tels qu'AIDE ou Tripwire établissent une base de référence de l'état attendu des binaires et des fichiers de configuration du système, et émettent une alerte en cas de modification inattendue. Il s'agit d'un contrôle qui distingue les environnements Linux bien rodés des environnements à surveillance minimale.

Kaseya VSA 10 assure la surveillance de Linux via des interrogations SNMP et des contrôles basés sur des agents, avec la possibilité de déployer des scripts personnalisés pour surveiller des indicateurs de santé spécifiques aux applications que la surveillance générique ne couvre pas.

Sécurité et renforcement de la sécurité sous Linux

Le renforcement de la sécurité sous Linux repose sur une politique rigoureuse de mise à jour. Au-delà de la mise à jour régulière des paquets, les pratiques qui réduisent considérablement la surface d'attaque sont bien connues et méritent d'être adoptées comme norme de base.

SSH devrait exiger une authentification par clé, et non par mot de passe. Le paramètre PasswordAuthentication doit être défini sur « no » dans le fichier sshd_config, PermitRootLogin doit être défini sur « no », et la connexion doit s'effectuer via des comptes sans privilèges permettant une élévation de privilèges via sudo. La plupart des attaques par force brute réussies contre des serveurs Linux sont dues au fait que l'authentification par mot de passe est activée sur SSH, souvent sur le port par défaut 22.

Les services et ports superflus doivent être désactivés. Un serveur web n'a pas besoin d'un relais de messagerie en fonctionnement, un serveur de base de données n'a pas besoin d'un serveur web, et un agent de compilation n'a besoin ni de l'un ni de l'autre. En réduisant la surface d'exposition des services à l'écoute, on limite les points d'accès dont dispose un attaquant pour pénétrer dans l'hôte.

L'accès via sudo doit respecter le principe du moindre privilège. Accorder un accès sudo général au groupe wheel à tous les utilisateurs administratifs est pratique sur le plan opérationnel, mais présente un risque pour la sécurité. Les entrées sudo spécifiques à chaque commande, enregistrées par auditd, permettent de savoir quelles commandes privilégiées ont effectivement été exécutées et par qui.

SELinux ou AppArmor doivent être activés lorsque la distribution le permet. Il s'agit dans les deux cas de systèmes de contrôle d'accès obligatoire qui limitent les actions autorisées aux processus, au-delà des permissions de fichiers classiques. Leur configuration n'est pas simple pour les applications personnalisées, mais pour les services fournis par la distribution, ils augmentent considérablement la difficulté de mener à bien une attaque.

Kaseya SIEM collecte les données syslog des serveurs Linux et met en corrélation les événements de sécurité Linux avec les données de télémétrie issues des terminaux, du réseau et du cloud provenant de plus de 60 sources de données. Les échecs d'authentification, les événements d'escalade de privilèges et l'exécution de processus inhabituels sur les serveurs Linux sont des signaux qui passent inaperçus lorsque les journaux de chaque serveur sont isolés sur l'hôte. Grâce à la corrélation inter-surfaces, une rafale SSH ayant échoué suivie d'une connexion réussie puis d'une connexion sortante vers une destination inhabituelle apparaît comme une seule chaîne d'attaque, et non comme trois événements sans rapport les uns avec les autres.

Sauvegarde et reprise après sinistre pour les serveurs Linux

Les serveurs Linux nécessitent les mêmes mesures de reprise que les serveurs Windows. Cela comprend la sauvegarde au niveau de l'image, la capture cohérente avec les applications, des tests de restauration réguliers, ainsi qu'une copie hors site ou répliquée dans le cloud pour la reprise après sinistre.

Datto BCDR offre une sauvegarde au niveau de l'image pour les machines virtuelles Linux et les serveurs Linux « bare-metal », avec les mêmes fonctionnalités de capture cohérente au niveau des applications et de virtualisation instantanée que la plateforme propose pour la sauvegarde des machines virtuelles Windows. Un même SIRIS peut héberger à la fois des environnements Windows et Linux protégés, ce qui simplifie les opérations de restauration dans les environnements mixtes.

Découvrez Datto BCDR pour la sauvegarde des serveurs Linux.

Gestion des serveurs Linux pour les MSP : gestion d'environnements mixtes

La plupart des MSP n'ont pas le choix entre Windows et Linux. Ils ont affaire à un client dont l'infrastructure principale repose sur Windows, mais dont la pile web destinée aux clients fonctionne sous Ubuntu, ou à un client du secteur industriel dont le backend ERP est sur RHEL, ou encore à un client du développement logiciel dont l'ensemble de l'infrastructure de compilation repose sur des conteneurs Linux.

Ce qui distingue un MSP, ce n’est pas tant le fait qu’il prenne en charge Linux, mais plutôt qu’il y applique la même rigueur opérationnelle. Prenons un cas de figure courant. Un client du secteur des services professionnels, comptant 40 utilisateurs, dispose de deux machines virtuelles Linux hébergeant son site web public et son wiki interne. Le volet Windows est entièrement géré dans le cadre du service standard du MSP. Le volet Linux est « couvert », mais les correctifs sont appliqués manuellement dès que quelqu’un y pense, sans autre surveillance que des vérifications par ping. Une vulnérabilité CVE du noyau est publiée, un poste de travail est compromis par une voie sans rapport, et l’attaquant se déplace latéralement vers la machine virtuelle Linux non corrigée, qui devient alors le point de persistance. Le volet Windows a tenu bon. Le volet Linux, que le MSP ne gérait pas vraiment, a cédé.

Le travail technique nécessaire pour mettre Linux au même niveau n'est pas très important. Il suffit de déployer l'agent VSA, de planifier l'application des correctifs, de définir des seuils de surveillance, d'intégrer les journaux syslog dans le SIEM et d'ajouter les hôtes au calendrier de sauvegarde. Le plus difficile est de reconnaître qu'un serveur Linux semi-géré constitue un risque qui doit être soit correctement géré, soit explicitement exclu du périmètre de gestion, et non pas se situer quelque part entre les deux.

Comment Kaseya Intelligence la gestion des systèmes Linux

Kaseya Intelligence s'appuie sur plus de trois exaoctets de données agrégées et anonymisées et sur plus de 17 millions de terminaux gérés, permettant ainsi une action autonome sur l'ensemble de la Kaseya 365 . Le changement consiste à passer de la simple formulation de recommandations à l'exécution et à la validation des résultats sans intervention manuelle.

Dans les environnements de serveurs Linux, c'est un aspect crucial pour la gestion des correctifs, où la planification manuelle et la vérification post-application ont toujours rendu Linux disproportionnellement plus chronophage que Windows. Le déploiement automatisé des correctifs via Kaseya VSA 10, associé à une validation des workflows basée sur l'intelligence, comble cet écart. Les mêmes avantages opérationnels qui permettent à la gestion des correctifs Windows de s'étendre à des milliers de terminaux commencent à s'appliquer à Linux. Découvrez Kaseya Intelligence.

Un serveur Linux mis à jour, surveillé, sécurisé et sauvegardé selon les mêmes normes que les serveurs Windows qui l'entourent n'est pas un projet technique hors du commun. Il s'agit simplement de la même discipline de gestion appliquée à un gestionnaire de paquets différent. Les MSP qui intègrent cette approche et exploitent Linux comme un élément à part entière de leur parc informatique sont ceux dont les clients ne sont pas pris au dépourvu par un incident lié à Linux. Les MSP qui ne le font pas sont ceux qui doivent expliquer à un client, après coup, pourquoi la machine dont ils ne connaissaient pas bien l'existence est celle qui a laissé entrer l'attaquant.