Désinstaller le paquet xinetd s'il n'est pas utilisé par des services réseau
Garantit que le paquet super-serveur historique xinetd n'est pas installé lorsqu'aucun service ne l'exige.
Vérifié sur ce qui est installé ou enregistré, paquets présents/absents, bases de comptes.
Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.
Pourquoi cette règle
xinetd est un super-serveur historique qui écoute sur des ports et lance des démons réseau à la demande. Il est largement obsolète, remplacé par l'activation par socket de systemd, et sert aujourd'hui surtout à encapsuler de vieux services non sécurisés (telnet, rsh, tftp). Le garder installé n'apporte rien et augmente le risque d'exposer accidentellement ou intentionnellement ces services hérités. Retirer le paquet élimine ce risque et réduit la surface d'attaque.
Ce que vérifie Pavois
Pavois interroge la base de paquets via la ressource InSpec package('xinetd') (rpm -q / dpkg -s). Vérifier le paquet garantit que le super-serveur ne peut pas être réactivé pour lancer des démons hérités encapsulés ; si le paquet est absent, aucun service géré par xinetd ne peut être démarré.
describe package('xinetd') do
it { should_not be_installed }
endComment vérifier qu’elle est appliquée
Sur famille RHEL : rpm -q xinetd → package xinetd is not installed. Sur Debian/Ubuntu : dpkg -s xinetd → dpkg-query: package 'xinetd' is not installed.
Inspecter et investiguer
- État du paquet :
rpm -q xinetd/dpkg -s xinetd; suppression dans/var/log/dnf.rpm.logou/var/log/dpkg.log. - Activité passée du super-serveur (avant suppression) :
journalctl -u xinetd.
Remédiation
Le plan de durcissement de Pavois déclare une ressource package pour xinetd avec l'action remove, donc pavois harden apply le désinstalle (dnf remove xinetd / apt-get purge xinetd). Retirer le paquet supprime aussi l'unité xinetd, aucun redémarrage n'est donc nécessaire.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| action | remove |
|---|---|
| name | xinetd |
| resource | package |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si xinetd reste installé, tout service hérité configuré sous /etc/xinetd.d/ peut être (ré)exposé sur le réseau. Avant d'appliquer : comme l'indique le titre, vérifiez qu'aucun service n'est réellement lancé par xinetd, inspectez /etc/xinetd.d/ pour les entrées activées et ss -lntp pour les ports auxquels xinetd est lié. Si un service nécessaire en dépend encore, migrez-le d'abord vers une unité systemd native ou l'activation par socket, puis retirez le paquet. La suppression n'affecte pas SSH, il n'y a donc aucun risque de verrouillage de l'administration à distance.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R62 | direct | 2.0 | haute |
| CIS | 2.1.19, 2.2.4, 2.1.20 | direct | per OS, see the benchmark table | haute |
| NIST | CM-6(a), CM-7(a), CM-7(b) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 2.2.4 | support | 4.0.1 | moyenne |
Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.