Gestion des serveurs Linux : application de correctifs, surveillance et sécurité pour les prestataires de services gérés (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 back-ends 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 parc informatique. Ils appliquent la même discipline 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, depuis la même console lorsque cela est possible. Les MSP qui ne parviennent pas à respecter ces principes se retrouvent avec des serveurs Linux gérés selon un savoir-faire empirique, mis à jour manuellement quand quelqu’un y pense, surveillés à l’aide des 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 responsable 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 prestataires de services gérés (MSP) peuvent gérer ces deux systèmes d'exploitation à partir d'un modèle opérationnel unifié.

Gérez les terminaux Linux et Windows à partir d'une seule console.

Kaseya VSA 10 assure la gestion automatisée des correctifs, la surveillance et l'administration à distance des serveurs Linux, étendant ainsi au milieu Linux le même modèle opérationnel que celui utilisé pour les terminaux Windows.

Découvrez Kaseya VSA 10

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

La gestion des serveurs Linux consiste à veiller à ce que ceux-ci soient correctement mis à jour, surveillés, sécurisés, sauvegardés et maintenus en bon état de fonctionnement tout au long de leur cycle de vie. Elle couvre aussi bien les serveurs physiques que virtuels, hébergés sur site ou dans le cloud, ainsi que les environnements utilisant une seule distribution ou mixtes, exécutant des systèmes allant d'Ubuntu Server à RHEL, en passant par Debian et 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, celles des applications et la résolution des dépendances à partir d'un seul outil. Le processus de mise à jour est différent, les dépôts de paquets sont différents, et les conséquences d'une mise à jour qui échoue sont différentes.

Le deuxième aspect concerne la culture de gestion de la configuration. Les environnements Windows reposent largement sur une interface graphique et sont gérés par des stratégies de groupe. Les environnements Linux s’appuient quant à eux fortement 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 lit 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 constitue l'aspect le plus fréquent et le plus critique en matière de sécurité de cette discipline. 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 un impact sur un grand nombre d’applications qui en dépendent. Une vulnérabilité 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 consiste à suivre ce qui a été 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 utilisent souvent des dépôts fournis par les éditeurs ou des images de conteneurs qui doivent faire l'objet d'un suivi distinct.

Les utilitaires système présentant un historique de vulnérabilités (sudo, polkit, glibc, systemd) sont souvent la cible d'exploits visant à l'élévation de privilèges. Ils font l'objet de correctifs selon des cycles normaux, 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 des 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 concernant 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 donc effectuer une vérification externe pour détecter la défaillance. Les vérifications HTTP, de connexion à la base de données et de port TCP constituent la base de référence.

La surveillance des journaux porte sur 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, invocations de sudo, tentatives de connexion SSH). Les schémas anormaux observés dans ces journaux constituent souvent le premier signe d'une intrusion.

La surveillance de l'intégrité des fichiers permet de détecter les modifications non autorisées apportées aux fichiers système critiques. Des outils tels qu'AIDE ou Tripwire établissent un état de référence 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 où la surveillance est minimale.

Kaseya VSA 10 assure la surveillance de Linux grâce à 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 des correctifs. 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 appliquées comme norme de référence.

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`, le paramètre `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 intrusions par force brute réussies sur des serveurs Linux sont dues au fait que l'authentification par mot de passe reste activée sur SSH, souvent sur le port par défaut 22.

Les services et ports inutiles 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. La réduction de la surface d’exposition des services à l’écoute limite les voies d’accès dont dispose un attaquant pour pénétrer dans l’hôte.

L'accès à sudo doit respecter le principe du « moindre privilège ». Accorder un droit 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 via 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 les prend en charge. Il s'agit dans les deux cas de cadres de contrôle d'accès obligatoire qui limitent les actions autorisées aux processus, au-delà des permissions de fichiers traditionnelles. Leur configuration n'est pas simple pour les applications personnalisées, mais pour les services fournis par défaut par la distribution, ils augmentent considérablement le coût d'une exploitation réussie.

Kaseya SIEM collecte les flux syslog provenant 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 autant de signaux qui passent inaperçus lorsque les journaux de chaque serveur restent isolés sur l’hôte. Grâce à la corrélation inter-surfaces, une tentative SSH infructueuse 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 : sauvegarde au niveau de l'image, capture cohérente au niveau des applications, tests réguliers de restauration, ainsi qu'une copie hors site ou répliquée dans le cloud à des fins de reprise après sinistre.

Datto BCDR assure une sauvegarde au niveau de l'image pour les machines virtuelles Linux et les serveurs Linux « bare-metal », en offrant les mêmes fonctionnalités de capture cohérente au niveau des applications et de virtualisation instantanée que celles proposées par la plateforme pour la sauvegarde des machines virtuelles Windows. Une même appliance « 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 la solution Datto BCDR pour la sauvegarde des serveurs Linux.

Gestion des serveurs Linux pour les prestataires de services gérés (MSP) : gestion d'environnements mixtes

La plupart des MSP n'ont pas le choix entre Windows et Linux. Ils ont affaire soit à un client dont l'infrastructure principale repose sur Windows mais dont la pile web destinée aux clients fonctionne sous Ubuntu, soit à un client du secteur industriel dont le backend ERP est sur RHEL, soit à 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 exemple typique de ce problème. 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. La partie Windows est entièrement gérée dans le cadre du service standard du MSP. La partie Linux est « couverte », mais les correctifs sont appliqués manuellement dès que quelqu’un y pense, sans aucune surveillance au-delà 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 avec celle-ci, et l’attaquant se déplace latéralement vers la machine virtuelle Linux non patchée, qui devient alors le point de persistance. La partie Windows a tenu bon. La partie 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 planning de sauvegarde. Le plus difficile est de reconnaître qu'un serveur Linux semi-géré constitue un risque qui doit soit être géré correctement, soit être explicitement exclu du périmètre de gestion, et non se situer quelque part entre les deux.

Comment « Kaseya Intelligence » transforme l'exploitation de 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 des actions autonomes au sein de la plateforme Kaseya 365 . L'évolution consiste à passer de la simple proposition de recommandations à l'exécution et à la validation des résultats sans intervention manuelle.

Dans les environnements de serveurs Linux, c'est notamment le cas pour l'application des correctifs : la planification manuelle et la vérification après application ont, depuis 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 artificielle, comble cet écart. Les mêmes avantages opérationnels qui permettent à l'application des correctifs sous 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 le pirate.

Points clés à retenir

• La gestion des correctifs sous Linux s'appuie sur des gestionnaires de paquets propres à chaque distribution (apt, dnf, yum, zypper). Kaseya VSA 10 automatise ce processus pour les principales distributions, parallèlement à la gestion des correctifs sous Windows.
• L'authentification par clé SSH, l'exposition minimale des services, l'utilisation de « sudo » selon le principe du moindre privilège, ainsi que SELinux ou AppArmor constituent les pratiques de renforcement de la sécurité qui réduisent considérablement la surface d'attaque sous Linux.
• La fonctionnalité d'ingestion des fichiers syslog de Kaseya SIEM intègre les événements de sécurité Linux dans la couche de corrélation, aux côtés des données issues des terminaux, du réseau et du cloud, éliminant ainsi l'angle mort généré par une gestion isolée des journaux.
• Pour les prestataires de services de gestion (MSP), le serveur Linux semi-géré constitue un risque. Il faut soit l'aligner sur les mêmes normes opérationnelles que le parc Windows, soit le définir clairement comme un cas à part : c'est la position intermédiaire qui ne fonctionne pas.