L'administration système n'est pas quelque chose d'évident pour tout le monde, c'est d'ailleurs un sujet qui, lorsqu'il trait plus aux bases du réseau et de Linux, peut sembler beaucoup plus rébarbatif que l'apprentissage des dernières technologies à la mode (Docker, Terraform, Kubernetes…).
Aussi, avec le bombardement d'informations et la facilité d'accès à des contenus et tutoriaux informatiques souvent plus intéressant que les cours magistraux "classiques", les étudiants sont de moins en moins attentifs, présents ou participants.
Pour la direction des études, je devais mettre sur pied un cours d'administration système Linux, niveau avancé, à destination d'étudiants déjà familiers avec la ligne de commande, qui avaient des connaissances théoriques de réseaux et de bonnes bases en termes de programmation Unix.
Lorsque l'on prépare un cours, il est important de définir les objectifs pédagogiques que l'on cherche à atteindre.
Pour moi ici, il s'agissait d'une part de faire pratiquer du réseau concrètement (sans DHCP) et de les amener à déboguer divers problèmes courants pour un administrateur système Linux (tant au niveau système que réseau).
Bien évidemment, un certain nombre de sujets d'ouverture sont également survolés en même temps que l'on passe par les différentes étapes d'apprentissage.
Durant les quelques heures du cours, les étudiants incarneront donc un de leur héros favori, dans son univers, avec pour but ultime de: «se connecter à Internet pour rejoindre Zion».
Au contraire, je constate que lors de cet exercice, ce sont principalement les étudiants qui se débrouillent le mieux qui ont tendance à demander de l'aide sur les parties bonus, évidemment plus ardues.
Lors de travaux pratiques, la principale source de décrochage que j'ai observée intervient lorsque l'enseignant est en avance sur l'étape de l'étudiant: non seulement il doit se dépêcher pour rattraper son retard, mais en plus il ne peut bénéficier des conseils donnés oralement par le professeur.
On peut déplorer qu'il n'interrompe pas le cours pour demander de l'aide, mais voilà, de nombreux étudiants n'osent pas.
- Cela me permet de suivre l'avancement global et individuel: je peux aller voir ceux qui sont en retard pour gérer individuellement leurs difficultés; et quand c'est toute la classe qui bloque sur une étape, je peux intervenir sans qu'aucun étudiant ne se sente en retard: on réfléchit collectivement sur le point bloquant, ce qui favorise la réflexion individuelle, y compris de ceux qui ne participent pas oralement.
- Alors que la notation est habituellement une corvée, ici en monitorant l'avancement des étudiants, il est aisé de connaître les objectifs pédagogiques que chacun a acquis, afin de le noter en conséquence.
![Le tableau de bord pour suivre chaque étudiant](dashboard.webp)
Dans une entreprise, il peut arriver que l'on se retrouve à devoir intervenir sur une machine installée il y a très longtemps ou par un stagiaire qui n'était pas au fait des procédures et des mots de passe à utiliser, et pourtant il faut en récupérer les accès.
C'est une action "courante" qui ne fait appel à aucune vulnérabilité, il suffit d'avoir accès au programme de chargement du système d'exploitation.
Si pour beaucoup d'étudiants l'aspect théorique du "rootage" est bien présent, ils sont très peu à l'avoir expérimenté (et à avoir conscience que c'est si simple, qu'ils pourraient vouloir prendre des mesures pour contrer cette possibilité une fois dans le monde du travail).
### Le bac à sable pour les apprenants
L'ensemble du cours se déroule dans une salle machine préparée spécialement pour l'occasion et chaque machine est un bac-à-sable pour l'étudiant qui l'utilise.
Les étudiants sont sur un poste de travail piloté par un serveur (techniquement, les machines sont tout simplement configurées pour démarrer sur le réseau, en PXE).
Le système démarré est un véritable système GNU/Linux standard, basé sur la distribution Alpine afin d'être le plus léger possible.
Aussi, afin de limiter les actions inopportunes (écrasement du disque de l'hôte par exemple), le noyau est spécialement compilé pour avoir un nombre limité de pilotes.
Les postes clients n'étant pas démarrés avec un disque physique ou distant attaché, il n'y a aucune donnée persistante: en cas de redémarrage, l'étudiant retrouve la situation initiale.
L'exercice ne nécessitant pas de redémarrer volontairement, cela n'est donc généralement pas un problème, mais cela garanti de retrouver un état sain/connu de l'enseignant s'il doit aider un étudiant qui a détruit son système.
Il y a une exception, car dans la vraie vie, après avoir démarré notre machine en mode `single` pour écraser le mot de passe `root`, on redémarre pour retrouver le mode classique.
Quel que soit le mode dans lequel la machine a été démarrée, un programme tourne en tâche de fond pour surveiller les modifications faites sur le fichier `/etc/shadow`, contenant les mots de passe des comptes de la machine.
Aussitôt qu'un changement est effectué, le fichier est transmis au serveur démarrant les machines.
Afin de ne pas surcharger le serveur au moment où tous les étudiants changent leur mot de passe, au lieu de recréer l'image complète du système, je tire parti d'une astuce liée au format d'archive utilisé: il n'y a pas d'en-tête ni d'index global des fichiers, on peut donc ajouter un nouveau fichier à la fin de l'archive, dans le format attendu:
L'opération est peu coûteuse en ressources, il faudra simplement avoir suffisamment dimensionné l'espace disque du serveur puisque chaque étudiant aura sa propre archive complète du système (de l'ordre de 30Mo par étudiant).
Après avoir passé l'écran de connexion, l'étudiant fait donc face à un shell complet, avec lequel il peut lancer toutes les commandes installées qu'il souhaite.
Il n'y a pas d'interface graphique, les étudiants savent utiliser un shell, on leur montre ici que le terminal brut est une option.
Cette démarche est normalement acquise lors d'une pratique courante des systèmes Unix, mais il est important de rappeler ces commandes car certains, plus à l'aise avec les interfaces graphiques auraient cherché Firefox ou la boîte de dialogue de Network Manager.
Cette situation peut être l'occasion de revenir sur les mécaniques de démarrage, expliquer le rôle du chargeur de système d'exploitation pour bien montrer la différence.
L'objectif de cette étape est de faire découvrir les modules noyau et la commande `modprobe` pour les charger.
Selon l'affinité de l'auditoire, on peut les laisser tâtonner avec `lspci` pour explorer le matériel, s'approprier le nom des constructeurs et rechercher dans l'arborescence `/lib/modules` les pilotes qui peuvent correspondre.
Pour les étudiants qui se demandent comment un système classique charge automatiquement les modules, il faut bien sûr leur parler de `udev` et `mdev`.
Car pour démarrer en réseau une machine, il est nécessaire d'avoir sur le réseau un service de configuration automatique.
Dans le cadre de cet exercice, il s'agit d'un sous-réseau dédié exclusivement au démarrage des machines, il ne donne pas accès à Internet, ce qui peut perturber les étudiants à ce stade: normalement on obtient une IP et donc Internet!
La seule voie est donc de configurer le réseau manuellement.
Ils ont à leur disposition la véritable topologie du réseau, ainsi qu'une adresse IP à utiliser.
![Topologie du réseau qui est fournie aux étudiants pour se repérer](topology.png)
Le risque d'un tel exercice est que plusieurs étudiants prennent la même adresse et créent des conflits d'IP, ce qui rendrait l'exercice bien trop difficile.
Pour annihiler tout risque de conflit, chaque étudiant se voit confier une adresse protégée: cette adresse est inscrite dans la table ARP du serveur pour qu'elle ne puisse communiquer qu'avec son poste exclusivement.
Lorsque leur interface réseau est configurée, il est utile de leur parler des protocoles d'attribution d'adresse tels que DHCP, Neighbor Discovery Protocol, Router Advertisement…
Sauf qu'en faisant cela, l'étudiant va déclencher un *kernel panic*: un programme spécialement conçu pour exploiter un bug du noyau va faire planter la machine.
Parfois avec un peu d'aide sur la terminologie anglaise du verbe *to set*, l'étudiant comprend qu'en fait il s'agit d'un paramètre particulier du noyau, que l'on pourrait sans doute inverser, faire qu'il ne soit plus définit et ne cause donc plus le plantage.
Outre l'intérêt d'appréhender un *kernel panic*, le redémarrage forcé du poste que cela induit, alors que l'environnement n'est pas persistent, oblige l'étudiant à refaire la configuration réseau.
Comme il s'agit de la compétence clef retenue pour ce cours, le fait d'obliger l'étudiant à refaire une deuxième fois cette étape permet de mieux fixer la méthode dans sa mémoire.
Avant de tester à nouveau de valider le premier jeton, et afin d'éviter un nouveau *kernel panic*, l'étudiant doit désactiver la fonctionnalité activée dans le noyau qui provoque ce comportement.
On commence ici à rentrer dans des aspects de Linux inconnus des étudiants.
Pourtant de nombreuses fonctionnalités avancées (telles que les `cgroups` utilisés par Docker) sont conçus autour des mêmes principes de configuration: par une arborescence de fichiers virtuels.
Guidés par le sujet, les étudiants explorent donc le dossier `/proc/sys`, à la recherche du fameux fichier `panic_on_oops` dont il convient de changer le contenu afin de désactiver la fonctionnalité.
Enfin, ça y est, l'étudiant peut désormais valider son premier token, avec la satisfaction d'avoir appris et découvert de nombreuses choses importantes.
De retour sur notre fil conducteur, afin d'accéder à Internet, une IP seule n'est pas suffisante, il faut indiquer à notre système l'adresse de notre routeur qui sera chargé d'acheminer nos paquets vers l'Internet.
Néanmoins la topologie ne nous donne que le nom de domaine du routeur par défaut.
Mais impossible de résoudre un nom de domaine à ce stade.
Pour ce faire, le sujet suggère de terminer la configuration de notre système en tirant parti des services locaux: un résolveur de noms ainsi qu'un serveur de temps sont accessibles dans une DMZ que l'on peut joindre avec une route réseau dédiée.
En réseaux, il est très souvent question de routage.
Pour un étudiant, le routage consiste à laisser la box ou le routeur de l'entreprise gérer cette tâche.
Pourtant ce sera bientôt à lui de gérer ces routeurs, d'où l'important de montrer ici un exemple d'un routage "complexe", avec à la fois une route par défaut et une route statique vers notre DMZ.
Un second jeton est attendu pour valider le bon fonctionnement du routage.
Certains étudiants auront à ce stade créé une route par défaut et cela fonctionnera, mais ils verront plus tard que cela leur posera des problèmes.
Dans tous les cas c'est une étape d'apprentissage utile.
Alors que jusqu'à maintenant tous les jetons devaient être envoyés vers un serveur web au travers d'une connexion non chiffrée (en HTTP en clair), il est maintenant demandé de valider un jeton sur une adresse utilisant le protocole HTTPS.
Si jusque-là tout semblait être cohérent, cette étape qui avait pourtant l'air simple: passer du protocole HTTP au HTTPS, va révéler un problème pour le moins inattendu:
curl: (60) SSL certificate problem: certificate is not yet valid
More details here: https://curl.haxx.se/docs/sslcerts.html
```
Il se trouve qu'au démarrage, une date aberrante est aléatoirement attribuée à la machine.
L'étudiant doit alors prendre conscience que le certificat est bien valide et que le problème vient de l'horloge de sa machine.
Il n'est pas rare, en tant qu'administrateur système, de rencontrer une machine dont l'horloge est repartie à 0 à cause d'une pile vide ou défectueuse.
Encore une fois, le point clef de l'étape consiste à prendre le temps de lire le message d'erreur.
Beaucoup d'étudiants se précipitent à ajouter l'option `-k` pour ignorer les erreurs de certificats, cependant le jeton de validation est basé sur l'horloge.
On a vu que l'on avait besoin de résoudre des noms de domaine pour obtenir l'adresse de notre routeur par défaut (mais aussi les noms de domaines de manière générale).
Une fois que le système de l'étudiant peut joindre la DMZ, il peut accéder aisément au serveur résolveur.
Pour que le système et tous les programmes de sa machine soient en mesure d'utiliser des noms de domaine, l'étudiant apprend à manipuler le fichier `/etc/resolv.conf`.
À la marge de cette étape, afin d'éveiller l'intérêt du DNS, un jeton est à retrouver dans la zone utilisée pour le cours.
Le jeton à valider à cette étape nécessite d'avoir à la fois accès à la DMZ et à la route par défaut.
Les étudiants qui n'avaient pas procédés ainsi à ce stade seront contraints de le faire, car ils ne peuvent pas encore accéder à Internet malgré la route par défaut…
Il s'avère qu'à chaque fois que j'ai donné ce cours, de nombreux étudiants ont choisi l'IP du routeur plutôt que de choisir une IP aléatoire ou similaire à celle qui leur avait été attribuée sur le sous-réseau initial.
Pour que tous les étudiants sans exception soient confrontés à ce problème, le serveur réalise de l'*ARP poisoning* sur toutes les adresses qui cherchent à le contacter.
En ouverture, il est intéressant d'expliquer que ce nombre maximal de routeurs à traverser peut-être utilisé pour reconnaître le système d'exploitation d'une cible.
Certains étudiants curieux seront allés lire les scripts mis à leur disposition dans le système, notamment le fameux script `adlin`, causant le *kernel panic*.
Un jeton bonus est caché dans le script, afin de récompenser la curiosité.
### 2. Prendre conscience du monitoring
Chaque étudiant est activement monitoré pour enregistrer sa progression.
La présence en ligne/hors ligne de sa machine pouvant soulever un besoin d'aide.
Les paquets ICMP envoyés à chaque étudiant contenait une chaîne hexadécimale particulière qu'ils peuvent observer en analysant le trafic de leur carte Ethernet.
### 3. Fichier disparu sur le disque
Un disque virtuel est créé au démarrage du système, un fichier est créé avec un jeton unique, puis supprimé.
Ce bonus vise à montrer à l'étudiant averti l'usage d'outils de récupération de fichiers.
## Variantes
Je montre ici une trame standard de l'exercice que j'ai conçu. Selon les besoins attendu il est possible de dévier de ce scénario.
On peut notamment ajouter des VLAN (si le réseau sous-jacent ne les filtre pas), une technologie de tunnel, de l'IPv6, une connexion SSH finale nécessitant de générer des clefs sûres…
Ils sont reconnaissants d'une part pour tous les apprentissages qu'ils n'avaient pas eu l'occasion de pratiquer avant ou même qu'ils ignoraient.
D'autre part ils sont reconnaissants de l'originalité du format, qui les stimule et les mets face à des problèmes concrets qu'ils doivent dépasser, avec une frustration réduite du fait de l'accompagnement personnalisé qui peut être réalisé avec la remontée en direct de la progression.