Optimiser et sécuriser le processus SystemD de démarrage des machines Linux

I. Présentation

Dans ce billet, je vous propose d’explorer le processus de démarrage SystemD de vos machines, utilisant des distributions GNU/Linux. En effet, depuis les dernières versions des distributions Red Hat7 ou CentOS7 (ou même Debian), le processus de démarrage SystemD exécutent toute sorte de démons et de services lors de leur phase d’initialisation. Parmi ceux-ci, certains ne sont pas forcément indispensables et peuvent être soit masqués, parce que trop critiques, soit désactivés.

Commençons par lister les principaux services visibles sur notre système. Pour se faire, on va utiliser l’instruction suivante :

# systemctl list-unit-files --type=service

Cela devrait alors vous faire apparaître une liste où chaque service apparaît alors soit en vert (lorsqu’il est activé) soit en rouge (lorsqu’il n’est pas initialisé ou masqué) :

REMARQUE : les services ou daemons ‘static’ sont des dépendances d’autres fonctionnalités présentes sur SystemD. Ils ne sont pas prévus pour être exécutés. On ne peut donc les activer ou les désactiver librement.

L’objectif ici doit viser à améliorer la sécurité du système d’exploitation et de son processus de démarrage. En effet, moins on aura de fonctionnalités inutiles d’activées sur nos serveurs, moins il y aura de possibilité d’intrusion.

II. Masquer ou désactiver un service

En effet, certains services, même désactivés, peuvent être démarrés par un autre service l’utilisant comme dépendance. Si l’on souhaite les laisser sans les désinstaller, on peut masquer ces démons et les empêcher de démarrer quelque soient les circonstances.

Pour désactiver un service que l’on ne souhaite pas utiliser, on va devoir exécuter les instructions suivantes :
# systemctl stop bluetooth.service
# systemctl disable bluetooth.service

Maintenant, pour masquer un service sans le désinstaller, on doit exécuter la commande ci-dessous :
# systemctl mask accounts-daemon.service

ATTENTION : lorsque l’on est convaincu que le démon une fois masqué n’empêche pas le bon fonctionnement du système, il est même possible de supprimer la fonctionnalité ou le service sous-jacent en le stoppant et en le désactivant. L’objectif est de ne conserver que les services vraiment nécessaires à notre système.

III. Services à masquer ou à désactiver

Maintenant que l’on sait comment masquer ou désactiver des services, il est temps de lister ceux dont on peut se passer.

REMARQUE : la liste ci-dessous n’est pas exhaustive et est dépendante de la distribution CentOS7. Je vous invite à regarder plus particulièrement les démons liés à votre distribution et de vous faire votre propre liste.

• Le service accounts-daemon.service: il s’agit d’un démon faisant partie de la suite AccountsService, permettant aux programmes d’obtenir et de manipuler les informations des comptes utilisateur du système. On peut le masquer, sans le désactiver.
• Le service avahi-daemon.service: il s’agit d’une découverte du réseau sans configuration et rendant également la recherche d’imprimantes ou de périphériques du réseau très aisée. Il est fortement conseillé de désactiver ce service.
• Le service bluetooth.service: il s’agit du service de connexion sans fil de type BlueTooth. Il n’est pas nécessaire d’insister sur le fait qu’il est conseillé de désactiver ce démon (à moins d’en avoir vraiment l’utilité), pour des raisons évidentes de sécurité.
• Le service debug-shell.service: il s’agit d’un Shell root sans mot de passe, permettant de debugger les problèmes survenant sur le processus SystemD. Il est donc, là aussi, conseillé de désactiver ce démon pour des raisons de sécurité.
• Le service ModemManager.service: il s’agit d’un démon activé par le processus DBus contrôlant les interfaces large bande mobile telles que 2G, 3G et même 4G. Si l’on ne dispose de telles interfaces couplées à un téléphone portable, il est conseillé de désactiver ce service.
• Le service rtkit-daemon.service: même si cela suggère un rootkit effrayant, il n’en n’est pas moins un service utile. Il s’agit du planificateur temps-réel du noyau. Il vaut donc mieux le laisser activé.
• Le service cups.service: il s’agit du service d’impression. Si le serveur ne fournit pas ce genre de fonctionnalité, on peut le désactiver.
• Le service qemu-guest-agent.service: il s’agit d’un démon d’aide utilisé pour échanger des informations entre hôtes et machines virtuelles. Lorsque l’on n’utilise aucun service de virtualisation, on peut désactiver cette fonctionnalité.

Pour rappel, afin de connaître l’état d’un service, il suffit d’interroger le système via l’une des commandes suivantes :

# systemctl status <Service>

ou

# systemctl is-active <Service>

Pour ceux qui, comme moi, apprécient d’économiser leur temps, je vous propose le module Puppet init.pp suivant :

class services {
  service { 'accounts-daemon.service':
    ensure => 'running',
    enable => 'false',
  }
  service { 'avahi-daemon.service':
    ensure => 'stopped',
    enable => 'false',
  }
  service { 'bluetooth.service':
    ensure => 'stopped',
    enable => 'false',
  }
  service { 'cups.service':
    ensure => 'stopped',
    enable => 'false',
  }
  service { 'rtkit-daemon.service':
    ensure => 'running',
    enable => 'true',
  }
  service { 'debug-shell.service':
    ensure => 'stopped',
    enable => 'false',
  }
  service { 'qemu-guest-agent.service':
    ensure => 'stopped',
    enable => 'false',
  }
  service { 'ModemManager.service':
    ensure => 'stopped',
    enable => 'false',
  }
}

RAPPEL : Puppet est un logiciel de déploiement automatique (au même titre qu’Ansible ou Chef), permettant d’uniformiser les serveurs, en termes de logiciels ou de programmes déployés. Ici, on s’assure que les services mentionnés possèdent bien les propriétés souhaitées (à savoir masqués ou désactivés). Puppet fera d’ailleurs l’objet ultérieurement d’un article présentant ce service.

Il ne reste plus alors qu’à intégrer cette classe ou ce module dans le fichier site.pp décrivant les machines gérées par Puppet :

…
node srv-linux01 {
  class{'::common':}
  include services
  …
}

IV. Processus de démarrage

Une fois que l’on a filtré les différents processus ou démons à activer, on peut alors s’intéresser à la phase de démarrage à proprement parlé. Afin de visualiser ce qui se passe réellement lors de ce démarrage, il suffit d’exécuter la commande suivante :

# journalctl -b

REMARQUE : si l’on souhaite visualiser ce qui s’est passé lors d’un démarrage précédent, il suffit de faire varier la valeur du paramètre après l’option -b :

# journalctl -b -2

Toutefois, pour que cela puisse fonctionne, il faut que l’option de journalisation permanente ait été activée. Dans le cas contraire, on recevra le message ci-dessous :

Specifying boot ID has no effect, no persistent journal was found

Pour modifier le paramétrage par défaut (où le mode de stockage des journaux est configuré en automatique), il faut éditer le fichier /etc/systemd/journald.conf pour ajouter la ligne suivante :

Il est également possible de filtrer les informations par numéro de processus, en fournissant le paramètre _PID de la façon suivante (par exemple, pour le processus père _PID=1) :

# journalctl _PID=1

REMARQUE: il est important que durant la phase d’initialisation du système il n’y ait aucun message d’erreur. Dans le cas contraire, il faut analyser la cause et y remédier.

Pour finir, si l’on souhaite optimiser le processus de démarrage et détecter les tâches les plus consommatrices durant la phase d’initialisation, on peut faire appel à la commande systemd-analyze avec l’une des deux options ci-dessous:

• blame : fournissant une vue globale des temps d’exécution des processus au démarrage.
• critical-chain : fournissant les goulots d’étranglement des processus au démarrage.

Exemple : liste des processus et des temps d’exécution au démarrage avec l’option blame :

V. Conclusion

Vous avez ainsi un bref aperçu des possibilités offertes par les fonctions de SystemD, tant sur le plan de la sécurité du système, que sur celui de son optimisation et de son exécution. Les commandes systemctl, journalctl sont beaucoup plus vastes et possèdent plus d'options que ce qui est édité ici. Je vous conseille de lire attentivement le manuel en ligne pour aller plus loin dans l’exploitation de ces fonctionnalités.

Mais, on dispose ainsi d'un minimum pour sécuriser le processus de démarrage SystemD et d'en affiner les processus à activer. J'espère que cela pourra vous être utile au niveau de vos infrastructures ou de vos installations futures.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio