Rognotudju : Mais qui supprime mon ifcfg-ens160 ?

Salut les gens 🙂. Cette semaine, une carte réseau toute bête nous a fait un peu nous arracher les cheveux : une VM Oracle Linux 8 dont la config réseau disparaissait à chaque reboot. Pas d’erreur, pas de message, juste un fichier ifcfg-ens160 qui s’évapore dans le /etc/sysconfig/network-scripts. Au final, l’enquête m’a fait découvrir (et utiliser) deux outils que je connaissais mal : le mode debug de NetworkManager et surtout auditd. C’est d’eux que je veux vous parler aujourd’hui. Spoiler : auditd est monstrueusement puissant.

Rappel du contexte

La VM en question était la suivante :

• Oracle Linux 8.10, noyau UEK (5.4.17-2136.x), NetworkManager 1.40.16
• VM VMware, carte vmxnet3 nommée ens160, importée à partir d’une OVA (gardez ça en tête, ça aura son importance)
• auditd actif et verrouillé en mode immutable (-e 2), signe d’un durcissement de type STIG/CIS (l’OVA vient d’un de nos fournisseurs, et déjà soupçonner un hardening CIS, c’est pas mal : tout le monde ne le fait pas).

Les symptômes

Dans l’ordre, voilà comment se comportait la VM :

1. On boote la VM. La carte ens160 est bien vue par le noyau, mais n’a pas d’adresse IPv4.
2. nmtui, option « Activer une connexion » : liste vide.
3. nmcli device connect ens160 : quelques secondes, aucune erreur.
4. Retour dans nmtui : la connexion existe maintenant (chouette), on la configure, on l’active, et ça marche.
5. Un petit reboot pour checker (toujours une règle de base : rebooter après un changement de configuration)
6. Heu … ifcfg-ens160 a disparu, la carte est de nouveau déconnectée (et nmtui se comporte comme si on n’avait rien fait, du coup).

Un petit détail explique le point 2 : nmtui liste des profils de connexion, pas des cartes. Liste vide, donc aucun profil associé à ens160. Et nmcli device connect, lui, crée un profil à la volée quand il n’en trouve pas. Du coup si vous relancez nmtui juste après, vous vous retrouvez avec une carte vierge, mais présente.

Les fausses pistes (et comment on les a écartées)

Avant de sortir le panzer et la grosse Bertha, on a vérifié les suspects habituels :

Hypothèse	Test	Verdict
Disque restauré à chaque boot (snapshot, mode non persistant)	Le disque de la VM est un delta …-000001.vmdk (donc un snapshot existe), mais une copie du fichier placée dans /root survivait à chaque reboot	Écarté : un revert aurait aussi emporté /root, or on l’utilisait comme backup de nos fichiers importants
Profil hérité de l’initramfs	cat /proc/cmdline : ni ip=, ni rd.neednet	Écarté
cloud-init / customisation VMware qui réécrit le réseau	Pas de trace dans le journal	Écarté … vraiment ? pourtant …

Bref, quelque chose supprime bien le fichier. Et là, on change de braquet ou on démarre l’assistance électrique ^^… oui parce que je ne vous le dirai qu’une fois mais j’étais aussi avec mon Jarvis, ce qui a grandement accéléré le passage en revue de toutes les pistes possibles.

Auditd, la boîte noire du Kernel

Vous connaissez auditd ? C’est le démon d’audit de Linux : il enregistre les événements que le noyau lui remonte (appels système, accès à des fichiers, etc.) selon des règles que vous définissez. Sur le principe c’est simple mais ça se révèle énorme pour savoir qui touche à un fichier. C’est même l’outil idéal : le noyau lui-même vous donne le nom du processus, son PID, son utilisateur d’origine, et même la ligne de commande.

Poser une surveillance

Une règle de type « watch » surveille un fichier ou un répertoire :

avec -w, le chemin à surveiller, -p wa, les événements à tracer (allez voir dans la doc, c’est tout bien espiké) 🙂 … et enfin -k nicprof : une clé, une étiquette libre qui permet de retrouver facilement ces événements ensuite.

On vérifie les règles chargées avec :

Le piège : le mode immutable

Chez nous, la première commande a répondu :

The audit system is in immutable mode

Un auditctl -s plus tard : enabled 2. C’est le mode immutable (-e 2). Une fois activé, les règles ne peuvent plus être modifiées avant le prochain reboot (rtfm auditctl). C’est un durcissement volontaire, très courant dans les profils de sécurité.

Pour s’en sortir proprement, il faut déclarer la règle de façon persistante, avant la ligne -e 2, puis rebooter. Sur Oracle Linux/RHEL 8, les règles vivent dans /etc/audit/rules.d/*.rules, lues dans l’ordre alphabétique et assemblées par augenrules dans /etc/audit/audit.rules (qui compile tout cela dynamiquement). Le -e 2 se trouve en général dans 99-finalize.rules, donc un fichier 50-… passe avant, bref vous avez compris.

Deux pièges croisés en route : si vous éditez audit.rules directement, il sera régénéré à partir de rules.d/ au prochain démarrage. Mettez toujours vos règles dans rules.d/. Après le reboot, vérifiez que la règle est bien dans le noyau (auditctl -l | grep nicprof) et pas seulement dans le fichier.

Lire les événements avec ausearch

Un événement d’audit n’est pas une ligne mais un bloc de plusieurs lignes (PROCTITLE, PATH, CWD, SYSCALL…) qui partagent le même identifiant. D’où un piège classique : un grep ligne à ligne coupe l’événement, et le nom du processus (dans la ligne SYSCALL) ne se retrouve pas à côté du nom du fichier (dans la ligne PATH). Laissez plutôt ausearch filtrer, il affiche l’événement en entier : ausearch -i -f ifcfg-ens160 -ts boot (par exemple)

Les options qui m’ont le plus servi :

Option	Rôle
-i	interprète les valeurs (noms au lieu de numéros)
-k <clé>	filtre sur la clé de la règle
-f <fichier>	filtre sur un nom de fichier
-sc <syscall>	filtre sur un appel système (unlink, rename…)
-p <pid>	tous les événements d’un processus
-m <type>	filtre sur un type d’enregistrement (USYS_CONFIG…)
-ts boot	depuis le dernier démarrage (existe aussi today, recent, une date…)

Après un reboot avec la règle chargée :

Le fichier est supprimé par NetworkManager lui-même (syscall=unlink, nametype=DELETE). Notre coupable, donc ? Pas si vite : l’exécutant n’est pas forcément le demandeur (merci Jarvis). NM peut très bien supprimer un profil parce qu’un autre processus le lui a demandé via D-Bus. L’audit nous dit qui a exécuté, pas pourquoi.

Le mode debug de NetworkManager

NetworkManager sait être très bavard, à condition de le lui demander. On peut le faire à chaud : nmcli general logging level DEBUG domains ALL ou de façon persistante, dans /etc/NetworkManager/conf.d/99-debug.conf :

Trois choses à savoir :

• level et domains règlent la verbosité et les sous-systèmes tracés.
• audit=true fait écrire à NM ses propres événements dans le sous-système d’audit (type USYS_CONFIG). Chez nous, NetworkManager --print-config montrait # audit=false, donc c’était désactivé. Sans ce réglage, impossible de voir qui demandait la suppression.
• Le DEBUG est verbeux : pensez à retirer le fichier une fois l’enquête terminée.

On redémarre, on relit le journal (journalctl -b -u NetworkManager -o short-precise), et on suit la vie de notre profil grâce à son UUID. Voici la séquence utile, anonymisée :

Le fichier est donc bien présent et bien lu au démarrage de NM, et la carte s’active sans souci. Environ 190 ms plus tard, le profil est supprimé alors qu’il est actif. C’est beaucoup trop rapide pour un humain ou un cron : il y a un déclencheur automatique quelque part.

Qui a demandé la suppression ?

C’est là que audit=true nous a aidés. L’enregistrement USYS_CONFIG de NM contient le PID du demandeur :

(pid=1025 en tête de ligne est NM ; pid=1311, dans msg=, est le client qui a envoyé la requête.)

Le coupable : un script de first boot

On remonte donc le processus 1311 : ausearch -i -p 1311 -ts boot

Les enregistrements PROCTITLE nous donnent la ligne de commande exacte :

Les règles d’audit durcies déjà présentes sur la machine avaient capturé des appels système de ce processus, et PROCTITLE en profite pour nous livrer sa commande. Il reste à trouver son parent (ppid=1310). Le journal général, sur la même fenêtre de temps, répond tout de suite :

Un service xxx-vapp-firstboot.service lance un script ootb.sh, embarqué dans l’OVA par son fournisseur.

Le reste est facile à trouver dans le script. Il y a un bug dans ce script. Si net.gateway est vide, la variable non quotée disparaît de la ligne de commande, qui devient gw4 ipv4.method manual .... NetworkManager prend alors ipv4.method pour la valeur de la passerelle, d’où le message « adresse de passerelle « ipv4.method » non valide ». Le script s’arrête après avoir tout supprimé et avant d’avoir recréé quoi que ce soit.

Joli bug messieurs (on va les appeler ne vous inquiétez pas 🙂 ). Ceci dit, ma réserve vis-à-vis des ingénieurs ou techniciens qui ont pondu ce script m’interdit de vous dire de qui il s’agit, mais sachez juste que le fournisseur en question fait partie des gros pourvoyeurs d’applications médico/administratives dans la Santé …

Root-cause et remédiation

À l’import de l’OVA, la propriété vApp net.gateway n’avait pas été renseignée (notre faute, pour le coup). Le script de first boot interprète mal cette absence : plutôt que de s’arrêter proprement, il supprime tous les profils réseau, plante à la création du nouveau, et laisse la VM sans configuration. Tant qu’il échoue, il se relance à chaque démarrage, et c’est exactement ce qu’on observait.

Au passage, un détail qui m’a fait perdre du temps : dans le vSphere Client récent, les vApp Options ne sont plus dans Edit Settings mais dans VM → Configure → Settings → vApp Options …. et dix minutes de perdues en plus !

J’ai donc corrigé la cause, puis repris la main sur le script. Côté données : renseigner les propriétés vApp, VM éteinte, gateway ajoutée dans les vApp Options, VM relancée. Côté script : le service systemd qui le lance est désactivé, et je l’ai exécuté une fois, à la main. Cette fois il est allé au bout et a finalisé toute la VM. Petit tip si vous ne connaissez pas : on peut vérifier ce que la VM reçoit réellement avec vmtoolsd --cmd "info-get guestinfo.ovfEnv".

Pourquoi ne pas simplement laisser le service tourner une fois la gateway corrigée ? Parce qu’un script qui supprime tout le réseau avant de planter, je préfère le lancer moi-même plutôt que de le laisser s’exécuter à chaque boot. Et pourquoi ne pas se contenter de désactiver le service sans le lancer ? Parce que ce script ne fait sans doute pas que du réseau : il applique probablement des configurations « métier » propres à la VM, et on serait passé à côté.

Bilan : on sait pourquoi ens160 disparaissait (salopiaud !), et la configuration prévue par l’OVA a bien été appliquée. La preuve par l’absurde : une fois le service désactivé, ifcfg-ens160 n’est plus supprimé au reboot, et le script ne repassera plus derrière.

Conclusion

Cette histoire était passionnante même si elle m’a occupé une après-midi entière. Les enseignements sont évidents, je pense. Usez et abusez même d’auditd. Cet outil est tout simplement génial notamment dans un troubleshooting avancé de ce type. Ensuite, un « first boot » ne tourne pas forcément qu’une seule fois : allez lire le(s) script(s) et faites-vous une idée ! Et enfin, quand une VM issue d’une OVA se comporte bizarrement, regardez ses propriétés vApp avant de chercher ailleurs. RTFM, logs, et un peu de paranoïa, comme toujours 🙂

Bref, épuisé mais content, car j’ai appris des choses ce mercredi ! Un grand merci à Brieuc pour m’avoir aidé pendant la première heure et surtout m’avoir laissé investiguer même si ce n’était pas gagné au départ !

Références
– RTFM Kernel, auditd, Linux etc … vous savez