← Toutes les règles
SOCLE-RUN-SVC-036// systemd servicesélevéeruntime effectif

Désactiver le service tftp

Garantit que le service tftp.service non authentifié est désactivé et arrêté afin que l'hôte n'agisse pas comme serveur TFTP.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

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

TFTP (Trivial File Transfer Protocol) n'offre aucune authentification ni chiffrement. Un serveur TFTP actif permet à quiconque sur le réseau de lire ou écrire les fichiers servis en clair, en faisant un vecteur fréquent pour récupérer des configurations, exfiltrer des données ou déposer des charges malveillantes. Conformément au principe de moindre fonctionnalité, le service doit être désactivé sauf besoin documenté et restreint au réseau (par exemple amorçage PXE).

Ce que vérifie Pavois

Pavois lit l'état effectif de l'unité via service('tftp.service') (systemctl is-enabled / is-active). TFTP est souvent activé par socket (tftp.socket), donc vérifier l'unité active/en cours, y compris les drop-ins, détecte un serveur à la demande qu'un balayage statique de /etc/default/tftpd-hpa ne révélerait pas.

describe service('tftpd-hpa.service') do
  it { should_not be_enabled }
  it { should_not be_running }
end

Comment vérifier qu’elle est appliquée

Exécutez systemctl is-enabled tftp.service (attendu disabled/masked/introuvable) et systemctl is-active tftp.service (attendu inactive). Vérifiez aussi le socket : systemctl is-active tftp.socket et confirmez que rien n'écoute sur UDP/69 avec ss -lunp | grep ':69' (attendu : aucune sortie).

Inspecter et investiguer

Les transitions du service et l'activité de transfert sont dans journalctl -u tftp.service (et journalctl -u tftp.socket). Les sockets en écoute se confirment avec ss -lunp | grep ':69'. Après désactivation, aucune nouvelle entrée de requête TFTP ne doit apparaître.

Remédiation

Le plan de durcissement de Pavois agit sur la ressource service nommée tftp : il exécute disable et stop pour que le serveur ne démarre pas au boot et soit arrêté maintenant. Il s'applique avec pavois harden apply. Pour empêcher totalement la réactivation par socket, désactivez/masquez aussi tftp.socket et envisagez de supprimer le paquet tftpd-hpa.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

actiondisable, stop
nametftpd-hpa.service
resourceservice
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Le principal risque de rupture concerne les environnements qui dépendent légitimement de TFTP, typiquement l'amorçage PXE/réseau ou le provisionnement de firmware d'équipements réseau. Précautions : confirmez qu'aucune infrastructure de boot, sauvegarde de commutateur/routeur ou flux d'imagerie ne dépend du TFTP de cet hôte avant de désactiver ; si PXE est requis, conservez TFTP uniquement sur le serveur de provisionnement dédié, liez-le au réseau d'administration et filtrez UDP/69 vers les clients autorisés.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS2.1.16directper OS, see the benchmark tablehaute
NISTCM-7(a), CM-7(b), CM-6(a)support800-53 Rev 5 · 800-171 Rev 2 (pinned)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.

Sources & références