Cours Linux RHEL — abonnement, dnf, systemd, stockage, réseau, firewalld, SELinux et SSH

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. enregistrer un système RHEL, vérifier ses dépôts et dire ce que l'abonnement conditionne ;
2. installer, mettre à jour, retirer des paquets avec dnf, et lire l'historique ;
3. piloter les services avec systemctl et lire les journaux avec journalctl ;
4. gérer utilisateurs, groupes, sudo et comprendre le rôle de PAM ;
5. lire et changer permissions et ACL, et expliquer pourquoi chmod -R est risqué ;
6. décrire la pile de stockage (partition, LVM, XFS) et étendre un volume logique ;
7. configurer le réseau avec NetworkManager (nmcli) sans perdre l'accès ;
8. ouvrir un service dans firewalld en distinguant configuration d'exécution et permanente ;
9. lire l'état de SELinux, corriger un contexte ou un booléen, diagnostiquer un refus sans passer en désactivé ;
10. durcir sshd en gardant une porte de secours ;
11. appliquer les correctifs de sécurité (errata) et lire l'audit ;
12. faire une sauvegarde de base et dire ce qu'elle ne prouve pas.

Prérequis

• Savoir ouvrir un terminal et lire une commande avant de la valider (cours « Terminal macOS » pour les réflexes de lecture ; ici la machine est une VM RHEL, pas le Mac).
• Notions de fichiers, de processus et de réseau IP : cours « Réseau » (section Exploitation).
• Une machine virtuelle jetable RHEL, avec un compte Red Hat valable pour l'enregistrer. Si Stéphane n'en a pas, tous les exercices se lisent sans exécution.

Parcours et chapitres

Ce schéma sert de fil rouge : quand « ça ne marche pas », se demander quelle couche refuse. Les chapitres 6, 9 et 10 traitent chacun une couche ; le chapitre 12 donne la méthode de diagnostic.

1. Abonnement, enregistrement et dépôts

Un RHEL reçoit ses paquets et ses correctifs depuis les dépôts de Red Hat, accessibles une fois le système enregistré avec subscription-manager. D'après la documentation d'installation de RHEL 9, il faut un compte du portail client Red Hat et soit un identifiant et un mot de passe, soit une clé d'activation et un identifiant d'organisation ; une fois enregistré, le système a accès aux mises à jour continues, aux dépôts et au support selon l'abonnement (les conditions précises : non vérifiées).

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo subscription-manager register --activationkey=CLE_DEMO --org=ORG_DEMOsudo subscription-manager statussudo subscription-manager repos --list-enabled

• Contexte : VM RHEL jetable ; CLE_DEMO et ORG_DEMO sont des valeurs à remplacer par les vôtres, jamais écrites dans un fichier versionné ; l'option --username demande un mot de passe : ne pas le taper en argument.
• Droits : sudo (ou root).
• Effet : register associe la machine à un compte chez Red Hat (compte d'un abonnement consommé : à vérifier) ; status et repos --list-enabled ne modifient rien.
• Vérification : status indique un état global cohérent ; dnf repolist liste les dépôts BaseOS et AppStream.
• Retour arrière : sudo subscription-manager unregister retire l'enregistrement (la VM perd l'accès aux dépôts).

Différence 9 / 10 : les dépôts s'appellent rhel-9-for-<arch>-baseos-rpms / …-appstream-rpms et leur équivalent rhel-10-… ; noms exacts non vérifiés (lister avec repos --list).

2. Installation, en principe

L'installation se fait depuis une image ISO avec l'installateur Anaconda (graphique ou texte) ; il permet de choisir la langue, la destination (partitionnement automatique ou personnalisé), le réseau, le profil de sécurité, l'utilisateur administrateur et l'enregistrement (« Connect to Red Hat »). Ce cours ne détaille pas l'installation : les guides « Interactively installing RHEL » de la documentation Red Hat y sont consacrés (RHEL 9 : page d'enregistrement lue ; le reste du guide n'a pas été lu).

Points de décision à documenter avant d'installer : schéma de partitionnement (chapitre 6), chiffrement du disque, nom d'hôte, profil de sécurité, sélection de logiciels minimale. Différence 9 / 10 : RHEL 10 impose un niveau de processeur plus récent que RHEL 9 (microarchitecture x86-64-v3) : information de mémoire, non vérifiée ici ; à lire dans les notes de version de la version choisie. Même remarque pour le mode FIPS, qui d'après le guide d'adoption de RHEL 10 se configure à l'installation (voir chapitre 11).

3. dnf, paquets, Application Streams et modules

dnf installe, met à jour et supprime les paquets RPM à partir des dépôts. La documentation de RHEL 9 organise le sujet en : distribution du contenu (dépôts, Application Streams, modules, profils), configuration de dnf, recherche, installation, mise à jour (dont les correctifs de sécurité), mises à jour automatiques (dnf-automatic avec des minuteurs systemd), suppression, historique, dépôts personnalisés et versions de flux.

dnf repolistdnf search chronydnf info chronydnf list --installed | headdnf history list

• Contexte : VM RHEL enregistrée ; commandes en lecture.
• Droits : utilisateur ordinaire pour la plupart (dnf peut demander sudo pour rafraîchir les métadonnées).
• Effet : aucun changement du système.
• Vérification : les dépôts attendus s'affichent ; dnf info donne version et dépôt d'origine.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut supprimer ou retirer des éléments, créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo dnf install chronysudo dnf history info lastsudo dnf history undo lastsudo dnf remove chrony

• Contexte : VM jetable ; chrony sert d'exemple (synchronisation d'horloge).
• Droits : sudo.
• Effet : install ajoute le paquet et ses dépendances ; history undo last annule la dernière transaction ; remove supprime le paquet et les dépendances devenues inutiles : relire la liste avant de confirmer, ne jamais ajouter -y sans l'avoir lue.
• Vérification : rpm -q chrony ; dnf history list montre la transaction.
• Retour arrière : dnf history undo <id> (ou rollback pour plusieurs transactions) ; sur une VM, restaurer l'instantané reste le plus sûr.

Modules. Sous RHEL 9, un module regroupe des versions parallèles d'une application (flux ou stream) : on les liste avec dnf module list, on en active un avec dnf module enable <module>:<flux>, on installe avec un profil (dnf module install <module>:<flux>/<profil>), et on change de flux en le réinitialisant (dnf module reset) ; ces commandes sont citées par la structure de la documentation, non relues une à une.

Différence 9 / 10. Le guide d'adoption de RHEL 10 indique : « la modularité est dépréciée et sera retirée dans une prochaine version majeure » et RHEL 10 ne distribue aucun contenu modulaire. Les commandes dnf module ne s'appliquent donc qu'à RHEL 9 (et 8). Le même guide mentionne que les métadonnées filelists ne sont plus chargées par défaut, que le greffon de débogage (dnf debug-dump) est retiré, et que RPM 4.19 vérifie les signatures avec Sequoia PGP.

Mises à jour automatiques. dnf-automatic s'active par un minuteur systemd ; décider quoi automatiser (sécurité seulement ou tout) est un choix de politique, voir chapitre 11.

4. systemd : unités, cibles, journald

systemd démarre le système et gère des unités : services (.service), minuteurs (.timer), cibles (.target, états du système comme multi-user.target), montages, sockets. journald collecte les journaux, lus avec journalctl. La documentation RHEL consacre un guide à la personnalisation des unités (« Using systemd unit files to customize and optimize your system ») ; son contenu détaillé n'a pas été lu ici.

systemctl status sshdsystemctl list-units --type=service --state=failedsystemctl get-defaultjournalctl -u sshd --since "1 hour ago"journalctl -p err -b

• Contexte : VM RHEL ; lecture seule.
• Droits : utilisateur ; journalctl complet demande l'appartenance à un groupe de lecture des journaux ou sudo.
• Effet : aucun.
• Vérification : status affiche active (running) ; -p err -b liste les erreurs depuis le démarrage courant.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut créer ou modifier une configuration, s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo systemctl enable --now chronydsudo systemctl restart chronydsudo systemctl disable --now chronydsudo systemctl edit chronyd

• Contexte : VM jetable ; chronyd est le service du paquet chrony. Ne jamais arrêter ni désactiver sshd sur une machine accessible seulement par SSH.
• Droits : sudo.
• Effet : enable --now active au démarrage et lance ; disable --now fait l'inverse ; edit crée un fichier de surcharge dans /etc/systemd/system/chronyd.service.d/ (le fichier d'origine n'est pas modifié).
• Vérification : systemctl is-enabled chronyd et systemctl is-active chronyd.
• Retour arrière : l'action opposée ; pour une surcharge, supprimer le fichier créé puis sudo systemctl daemon-reload.

Journaux persistants. Par défaut le journal peut rester en mémoire ; la conservation sur disque dépend de la configuration de journald (Storage=persistent dans /etc/systemd/journald.conf) et du répertoire /var/log/journal : comportement par défaut de RHEL non vérifié, à contrôler par journalctl --list-boots.

5. Utilisateurs, groupes, sudo et PAM (principes)

Chaque compte a un identifiant (UID) et appartient à un groupe principal et à des groupes secondaires. Les fichiers /etc/passwd, /etc/group et /etc/shadow (hachages, lisibles par root seulement) les décrivent. Sous RHEL, le groupe wheel donne l'accès à sudo par défaut (règle de /etc/sudoers : à confirmer sur la version installée). PAM (Pluggable Authentication Modules) est la pile de modules qui décide comment un service authentifie : en principe, on ne modifie pas /etc/pam.d à la main, on passe par authselect (outil cité de mémoire, non vérifié dans la documentation lue).

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo useradd -m -G wheel demosudo passwd demoid demosudo usermod -aG wheel demosudo visudo -c

• Contexte : VM jetable ; demo est un compte de démonstration.
• Droits : sudo.
• Effet : useradd crée le compte et son répertoire personnel ; passwd demande un mot de passe (saisi au clavier, jamais en argument) ; usermod -aG ajoute un groupe : sans -a, usermod -G remplace tous les groupes secondaires ; visudo -c vérifie la syntaxe de sudoers sans rien changer.
• Vérification : id demo montre wheel ; sudo -l -U demo liste ses droits.
• Retour arrière : sudo userdel -r demo (supprime aussi le répertoire personnel : définitif) ; sudo gpasswd -d demo wheel retire du groupe.

Garde-fou : modifier /etc/sudoers uniquement avec visudo (il refuse une erreur de syntaxe), toujours avec une session root ou administrateur restée ouverte.

6. Système de fichiers, permissions et ACL

Chaque fichier a un propriétaire, un groupe et trois jeux de droits (propriétaire, groupe, autres) en lecture (r), écriture (w), exécution (x), écrits en lettres (rwxr-x---) ou en octal (750). Pour un répertoire, x signifie « traverser ». Le bit setgid sur un répertoire fait hériter le groupe. Les ACL ajoutent des droits pour des utilisateurs ou groupes précis sans changer le propriétaire (getfacl, setfacl) ; leur prise en charge par le système de fichiers est à confirmer (XFS en dispose d'après les usages courants : non relu dans la documentation).

ls -l /etc/ssh/sshd_configstat -c '%A %U %G %n' /etc/ssh/sshd_configgetfacl /etc/ssh/sshd_configls -Z /etc/ssh/sshd_config

• Contexte : VM RHEL ; lecture seule. ls -Z affiche le contexte SELinux (chapitre 9).
• Droits : utilisateur.
• Effet : aucun.
• Vérification : les colonnes propriétaire, groupe et droits sont lisibles ; getfacl annonce l'absence d'ACL ou en liste.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut supprimer des fichiers, s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

mkdir -p ~/essai/partage && touch ~/essai/partage/note.txtchmod 750 ~/essai/partagesudo setfacl -m u:demo:rx ~/essai/partagechmod -R g-w ~/essairm -r ~/essai

• Contexte : uniquement dans un répertoire d'essai de la VM ; jamais chmod -R ni rm -r sur /, /etc, /usr ou un répertoire personnel réel.
• Droits : utilisateur propriétaire (sudo pour setfacl sur un compte qui n'est pas le sien).
• Effet : chmod 750 retire tous les droits aux autres ; setfacl -m ajoute une ACL ; chmod -R modifie récursivement tout l'arbre ; rm -r supprime définitivement.
• Vérification : ls -l ~/essai, getfacl ~/essai/partage avant et après.
• Retour arrière : setfacl -x u:demo ~/essai/partage retire l'ACL ; pour les droits, noter stat avant et remettre la valeur ; rm -r est irréversible sans sauvegarde (instantané de la VM).

7. Stockage : partitions, LVM et XFS

La pile type de RHEL : disque → partition → volume physique (PV) → groupe de volumes (VG) → volume logique (LV) → système de fichiers. D'après la documentation LVM de RHEL 9 : « les volumes physiques sont les périphériques bruts regroupés en groupe de volumes ; dans ce groupe, LVM alloue de l'espace pour créer des volumes logiques ». Les guides « Configuring and managing logical volumes » et « Managing file systems » existent pour RHEL 9 et 10 ; le détail des commandes n'a pas été relu dans ces pages, les exemples ci-dessous sont à confronter à man lvcreate, man xfs_growfs. XFS est le système de fichiers par défaut cité par la documentation de RHEL ; un XFS peut être agrandi mais pas réduit (principe connu, non vérifié ici).

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

lsblkdf -hTsudo pvssudo vgssudo lvs

• Contexte : VM avec un disque supplémentaire vide pour les exercices ; lecture seule.
• Droits : sudo pour pvs, vgs, lvs.
• Effet : aucun.
• Vérification : lsblk montre l'arborescence disque/partition/LV et les points de montage.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut effacer ou formater un volume, créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo pvcreate /dev/vdbsudo vgcreate vg_demo /dev/vdbsudo lvcreate -n lv_donnees -L 2G vg_demosudo mkfs.xfs /dev/vg_demo/lv_donneessudo mkdir /mnt/donnees && sudo mount /dev/vg_demo/lv_donnees /mnt/donneessudo lvextend -r -L +1G /dev/vg_demo/lv_donnees

• Contexte : VM jetable ; /dev/vdb est le disque vide de test : vérifier le nom avec lsblk, car pvcreate et mkfs détruisent le contenu du périphérique visé. Jamais sur le disque système.
• Droits : root (sudo).
• Effet : crée PV, VG, LV et un système de fichiers XFS, le monte, puis agrandit LV et système de fichiers (-r redimensionne aussi le système de fichiers).
• Vérification : lvs, df -hT /mnt/donnees.
• Retour arrière : sudo umount /mnt/donnees, sudo lvremove vg_demo/lv_donnees, sudo vgremove vg_demo, sudo pvremove /dev/vdb (suppression des données : définitive) ; sur une VM, restaurer l'instantané.

Pour un montage permanent, on ajoute une ligne à /etc/fstab (UUID plutôt que nom de périphérique, relevé par blkid) ; une ligne erronée peut empêcher le démarrage : tester avec sudo mount -a avant de redémarrer, et garder l'accès à la console de la VM.

8. Réseau avec NetworkManager (nmcli)

NetworkManager gère les interfaces ; nmcli est sa commande. Une connexion (profil) s'applique à un périphérique (interface). La documentation « Configuring and managing networking » (RHEL 9 et 10) décrit la configuration d'une connexion Ethernet par nmcli. Le schéma général d'une adresse statique est : nmcli connection modify <profil> ipv4.method manual ipv4.addresses <adresse/préfixe> ipv4.gateway <passerelle> ipv4.dns <serveur> puis nmcli connection up <profil> (forme tirée d'un résumé de page, à confronter à man nmcli-examples).

nmcli device statusnmcli connection shownmcli -p device showip -br addressip routeresolvectl status

• Contexte : VM RHEL ; lecture seule. Voir le cours « Réseau » (section Exploitation) pour la théorie (CIDR, routage, DNS).
• Droits : utilisateur.
• Effet : aucun.
• Vérification : l'interface est connected ; l'adresse et la route par défaut attendues apparaissent.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut créer ou modifier une configuration, s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo nmcli connection modify "Wired connection 1" ipv4.method manual \    ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1 ipv4.dns 192.0.2.53sudo nmcli connection up "Wired connection 1"sudo hostnamectl set-hostname srv1.example.test

• Contexte : console de la VM, pas SSH : changer l'adresse coupe la session SSH en cours. Wired connection 1 est un nom par défaut possible, à relever avec nmcli connection show. Adresses synthétiques RFC 5737.
• Droits : sudo.
• Effet : passe l'interface en adresse fixe ; connection up applique tout de suite ; hostnamectl change le nom d'hôte.
• Vérification : ip -br address, ping -c 3 192.0.2.1 si la passerelle existe, resolvectl query example.test.
• Retour arrière : sudo nmcli connection modify "Wired connection 1" ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns "" puis connection up ; sinon restaurer l'instantané.

Différence 9 / 10. Le guide d'adoption de RHEL 10 indique que les fichiers au format ifcfg de /etc/sysconfig/network-scripts/ ne sont plus pris en charge : les profils sont au format keyfile dans /etc/NetworkManager/system-connections/. Il retire aussi teamd (utiliser le bonding du noyau) et dhclient (client DHCP interne de NetworkManager). Sous RHEL 9 les deux formats coexistent (non relu en détail).

9. Pare-feu firewalld

firewalld filtre le trafic par zones (une interface appartient à une seule zone ; la zone par défaut à l'installation est public, d'après la documentation de RHEL 9). Deux jeux de règles coexistent : la configuration d'exécution (immédiate, perdue au rechargement ou au redémarrage) et la configuration permanente (survit, mais n'est appliquée qu'au rechargement avec --reload). La documentation recommande de relire la zone par défaut et de désactiver les services inutiles.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo firewall-cmd --statesudo firewall-cmd --get-active-zonessudo firewall-cmd --list-allsudo firewall-cmd --list-all --permanentsudo firewall-cmd --get-services | tr ' ' '\n' | head -20

• Contexte : VM RHEL ; lecture seule.
• Droits : sudo.
• Effet : aucun.
• Vérification : running, zone active et services attendus (ssh y figure normalement : à confirmer).
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo firewall-cmd --add-service=httpsudo firewall-cmd --list-servicessudo firewall-cmd --runtime-to-permanentsudo firewall-cmd --permanent --remove-service=httpsudo firewall-cmd --reload

• Contexte : VM jetable ; garder une seconde session SSH ouverte et vérifier que le service ssh reste listé : retirer ssh d'une zone coupe l'accès distant.
• Droits : sudo.
• Effet : --add-service ouvre http en exécution seulement (idéal pour tester) ; --runtime-to-permanent rend la configuration d'exécution permanente ; --permanent --remove-service modifie la configuration durable, appliquée au --reload.
• Vérification : firewall-cmd --list-services puis --list-services --permanent ; test depuis une autre machine avec curl http://srv1.example.test/ si un serveur écoute.
• Retour arrière : --remove-service=http en exécution, ou --reload qui recharge le permanent (efface l'exécution non enregistrée) ; restaurer l'instantané en dernier recours.

Différence 9 / 10. D'après le guide d'adoption de RHEL 10, firewalld gagne les policy sets (collections de politiques prédéfinies, par exemple pour une passerelle) et nftables des crochets netdev par nom avec jokers. Le fonctionnement par zones décrit ici est supposé identique : non vérifié.

Voir aussi : cours « Réseau » (filtrage, NAT) et « Sécurité des systèmes » (défense en profondeur).

10. SELinux : modes, contextes, booléens, refus

SELinux est un contrôle d'accès obligatoire (MAC) : même si les permissions classiques acceptent, la politique peut refuser. Chaque processus et chaque fichier a un contexte (utilisateur:rôle:type:niveau) ; en pratique on raisonne sur le type. Trois modes : enforcing (applique et journalise), permissive (journalise sans bloquer), disabled. Ne jamais désactiver SELinux pour « réparer » : diagnostiquer et corriger (voir ci-dessous).

La page de dépannage de la documentation RHEL 9 propose cette démarche, rapportée ici d'après un résumé : identifier le refus dans l'audit (ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent) ; l'analyser avec sealert -l "*" (paquet setroubleshoot) ; puis corriger selon la cause : étiquette (semanage fcontext -a -t <type> "<chemin>" puis restorecon -R -v <chemin>), booléen (setsebool -P <booléen> on ; liste getsebool -a | grep <service>), port (semanage port -a -t <type> -p tcp <numéro>). Passer en permissive (setenforce 0) ne sert qu'à vérifier que SELinux est bien la cause.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

getenforcesestatusls -Z /var/www /etc/ssh/sshd_configps -eZ | grep sshdgetsebool -a | grep httpd | headsudo ausearch -m AVC -ts recent

• Contexte : VM RHEL ; lecture seule. ausearch suppose le démon d'audit actif.
• Droits : utilisateur pour getenforce, ls -Z ; sudo pour ausearch.
• Effet : aucun.
• Vérification : getenforce renvoie Enforcing ; ausearch liste les refus récents, éventuellement aucun.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo setenforce 0sudo setenforce 1sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"sudo restorecon -R -v /srv/sitesudo setsebool -P httpd_can_network_connect on

• Contexte : VM jetable ; /srv/site est un répertoire de démonstration ; semanage vient du paquet policycoreutils-python-utils (nom à confirmer). Le type httpd_sys_content_t et le booléen sont des exemples courants (à confirmer avec semanage fcontext -l, getsebool -a).
• Droits : root (sudo).
• Effet : setenforce 0 passe en permissif jusqu'au redémarrage (la protection est suspendue) ; fcontext -a enregistre une règle durable ; restorecon -R réétiquette tout l'arbre ; setsebool -P rend le booléen permanent (et ouvre une capacité : en connaître la portée).
• Vérification : getenforce, ls -Z /srv/site, semanage fcontext -l | grep /srv/site, getsebool httpd_can_network_connect.
• Retour arrière : setenforce 1 ; semanage fcontext -d "/srv/site(/.*)?" puis restorecon -R -v /srv/site ; setsebool -P httpd_can_network_connect off.

Désactivation : passer en disabled demande un redémarrage et, à la réactivation, une réétiquette complète du système de fichiers : à éviter, procédure non lue ici.

Différence 9 / 10. Le guide d'adoption de RHEL 10 indique que la règle d'équivalence de contexte pour /var/opt écrase les règles personnalisées lors d'une mise à niveau vers RHEL 10.2, et que des modules de politique liés à EPEL passent dans des sous-paquets -extra du dépôt CodeReady Linux Builder.

11. SSH et durcissement

La documentation de RHEL 9 (« Securing networks ») décrit l'authentification par clé : ssh-keygen -t ecdsa pour créer la paire, ssh-copy-id <utilisateur>@<hôte> pour installer la clé publique, puis ssh -o PreferredAuthentications=publickey <utilisateur>@<hôte> pour vérifier. Réglages recommandés dans /etc/ssh/sshd_config : PasswordAuthentication no, PubkeyAuthentication yes, KbdInteractiveAuthentication no, PermitRootLogin no, éventuellement AllowUsers/AllowGroups et X11Forwarding no. La documentation insiste : vérifier qu'on peut déjà se connecter par clé avant de restreindre les méthodes, valider la syntaxe avec sshd -t, puis recharger (systemctl reload sshd).

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

ssh-keygen -t ed25519 -C "demo@example.test"ssh-copy-id demo@srv1.example.testssh -o PreferredAuthentications=publickey demo@srv1.example.testsudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|pubkeyauthentication'

• Contexte : poste client puis VM srv1.example.test (adresse 192.0.2.10) ; la clé est protégée par une phrase de passe ; ed25519 est un choix courant (la documentation citée donne ecdsa : choix à confirmer).
• Droits : utilisateur côté client ; sudo pour sshd -T.
• Effet : ssh-keygen crée la paire dans ~/.ssh ; ssh-copy-id ajoute la clé publique à ~/.ssh/authorized_keys de la VM ; les autres commandes ne modifient rien.
• Vérification : la connexion par clé réussit sans demander le mot de passe du compte.
• Retour arrière : retirer la ligne correspondante de authorized_keys sur la VM ; supprimer la paire côté client.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo cp -p /etc/ssh/sshd_config /root/sshd_config.avantsudo vi /etc/ssh/sshd_configsudo sshd -tsudo systemctl reload sshd

• Contexte : VM jetable ; deux sessions SSH ouvertes (une reste ouverte tant qu'une nouvelle connexion n'a pas réussi) et la console de la VM sous la main. Valeurs à saisir : PasswordAuthentication no, PermitRootLogin no. Ne jamais les appliquer avant d'avoir testé la clé.
• Droits : sudo.
• Effet : modifie le comportement de sshd pour les nouvelles connexions ; sshd -t ne change rien, il échoue si la syntaxe est fausse ; reload applique.
• Vérification : depuis un autre terminal, une connexion par clé fonctionne, une connexion par mot de passe est refusée.
• Retour arrière : sudo cp -p /root/sshd_config.avant /etc/ssh/sshd_config && sudo systemctl reload sshd, depuis la session restée ouverte ou la console.

Différence 9 / 10. Le guide d'adoption de RHEL 10 indique que les clés d'hôte SSH passent de 0640 à 0600 ; les politiques cryptographiques deviennent plus strictes (échanges RSA refusés en TLS par la politique DEFAULT, SHA-1 retiré de LEGACY pour TLS, FUTURE en hybride ML-KEM) et fips-mode-setup est retiré (FIPS se décide à l'installation). Les options ci-dessus ne sont pas affectées d'après ce qui a été lu : non vérifié.

Voir aussi : cours « Sécurité des systèmes » (menaces, défense en profondeur).

12. Journaux, audit et méthode de diagnostic

Trois sources complémentaires : journalctl (chapitre 4), les fichiers de /var/log, et le système d'audit de Linux. La documentation RHEL 9 décrit auditd (démon noyau), auditctl (règles), ausearch (recherche), aureport (synthèses) et augenrules (compilation des règles de /etc/audit/rules.d/) ; le journal par défaut est /var/log/audit/audit.log. L'audit découvre, il ne protège pas : il aide à repérer les violations à corriger.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo systemctl status auditdsudo ausearch -m USER_LOGIN -ts todaysudo aureport --auth --summarysudo tail -n 20 /var/log/audit/audit.log

• Contexte : VM RHEL ; lecture seule. Le journal d'audit contient des données sensibles : ne pas le copier hors de la VM.
• Droits : sudo.
• Effet : aucun.
• Vérification : auditd est active ; les connexions SSH de test apparaissent.
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo auditctl -w /etc/passwd -p wa -k passwd_changessudo ausearch -k passwd_changessudo auditctl -W /etc/passwd -p wa -k passwd_changes

• Contexte : VM jetable ; règle donnée en exemple par la documentation (surveille les écritures et changements d'attributs de /etc/passwd).
• Droits : sudo.
• Effet : ajoute une règle d'audit en mémoire (perdue au redémarrage ; pour la persister, un fichier dans /etc/audit/rules.d/ puis augenrules --load) ; le volume du journal croît.
• Vérification : sudo auditctl -l liste la règle.
• Retour arrière : la troisième commande retire la règle.

Méthode « quelle couche refuse ? » : (1) le service tourne-t-il (systemctl, journalctl) ; (2) le réseau (nmcli, ip) ; (3) le pare-feu (firewall-cmd --list-all) ; (4) les permissions (ls -l, getfacl) ; (5) SELinux (ausearch -m AVC, ls -Z) ; (6) l'application. On ne passe à la couche suivante que si la précédente est écartée.

13. Mises à jour et sécurité : errata, dnf updateinfo

Red Hat publie des errata (avis de sécurité, de correction de bogue, d'amélioration). La documentation dnf de RHEL 9 traite de la mise à jour, y compris des correctifs de sécurité seuls ; la commande dnf updateinfo et l'option --security sont citées de mémoire, non confirmées dans les pages lues.

dnf check-updatednf updateinfo list --securitydnf updateinfo info --security | head -40dnf needs-restarting -r

• Contexte : VM RHEL enregistrée ; lecture seule. needs-restarting peut dépendre d'un paquet de dnf-utils (à confirmer).
• Droits : utilisateur (sudo pour rafraîchir).
• Effet : aucun.
• Vérification : la liste des avis correspond aux paquets installés ; un code de retour 100 de check-update signifie « des mises à jour existent ».
• Retour arrière : sans objet.

Attention, effet notable. Cette commande peut créer ou modifier une configuration, s'exécuter avec des droits élevés. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo dnf upgrade --securitysudo dnf upgradesudo dnf history undo lastsudo reboot

• Contexte : VM jetable, instantané pris avant ; sur un vrai serveur : fenêtre de maintenance, sauvegarde, test préalable. Un nouveau noyau n'est actif qu'après redémarrage.
• Droits : sudo.
• Effet : met à jour les paquets (le premier, seulement ceux couverts par un avis de sécurité) ; peut redémarrer des services ; reboot coupe la machine.
• Vérification : rpm -q kernel et uname -r ; dnf history list ; services critiques active.
• Retour arrière : dnf history undo last (limites : certains changements de configuration et de noyau ne se défont pas proprement) ; instantané de la VM.

FIPS et durcissement : le profil de sécurité (SCAP) et le mode FIPS se choisissent surtout à l'installation, d'après le guide d'adoption de RHEL 10 ; détails non lus. Voir le guide « Security hardening » (RHEL 9 et 10).

14. Sauvegarde de base

Une sauvegarde de base d'un RHEL = configuration (/etc), liste des paquets, données applicatives, copiées hors de la machine, et restauration testée. Le détail (règle 3-2-1, restauration, plan de reprise) est dans le cours « Sauvegarde et reprise » (section Exploitation) : ne pas le recopier ici. Les outils natifs cités par la documentation RHEL (par exemple rear ou instantanés LVM) n'ont pas été consultés : non vérifiés.

Attention, effet notable. Cette commande peut s'exécuter avec des droits élevés, écrire ou écraser un fichier. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

sudo tar --acls --selinux --xattrs -czf /tmp/etc-sauvegarde.tar.gz /etcsudo tar -tzf /tmp/etc-sauvegarde.tar.gz | headrpm -qa --qf '%{NAME}\n' | sort > /tmp/paquets.txt

• Contexte : VM jetable ; --acls --selinux --xattrs conservent ACL et contextes (options à confirmer avec man tar) ; copier ensuite l'archive hors de la VM (le dossier /tmp n'est qu'un exemple, une sauvegarde au même endroit que les données n'en est pas une).
• Droits : sudo pour lire tout /etc.
• Effet : crée deux fichiers ; l'archive contient des fichiers sensibles (hachages de /etc/shadow) : droits stricts, pas de partage.
• Vérification : tar -tzf liste le contenu ; tester une restauration dans un répertoire vide.
• Retour arrière : rm /tmp/etc-sauvegarde.tar.gz /tmp/paquets.txt (sur les copies d'essai seulement).

15. Cockpit et Podman, en mention

• Cockpit (console web de RHEL) : la documentation « Managing systems in the RHEL web console » existe pour RHEL 9 et 10. Il s'active par sudo systemctl enable --now cockpit.socket et écoute sur le port 9090 (de mémoire, non vérifié ; l'ouvrir sur le pare-feu élargit la surface d'attaque, à n'exposer qu'en réseau d'administration).
• Podman : la documentation « Building, running, and managing containers » existe pour RHEL 9 et 10. Podman exécute des conteneurs sans démon, en mode « sans racine » possible. Pour les notions d'images, de conteneurs et de volumes, voir le cours Docker (section Poste et outils de développement) : les commandes podman sont, d'après l'usage courant, proches de celles de docker (équivalence non vérifiée ici).

16. Renvois vers les autres cours de la bibliothèque

Exercices

1. Carte des couches. Pour trois pannes imaginées (page web inaccessible, Permission denied, sshd qui ne démarre pas), dire quelle couche du schéma est probablement en cause et la commande qui le prouve.
2. Dépôts. Sur la VM enregistrée, lister les dépôts activés ; dire à quoi sert chacun (BaseOS, AppStream).
3. Transaction. Installer chrony, lire dnf history info, annuler, vérifier avec rpm -q.
4. Service. Activer puis désactiver chronyd ; expliquer la différence entre active et enabled.
5. Compte. Créer demo dans wheel, vérifier avec id et sudo -l, supprimer.
6. ACL. Donner à demo la lecture d'un répertoire d'essai par ACL ; vérifier avec getfacl, retirer.
7. LVM. Sur le disque de test : PV, VG, LV 1 Go, XFS, montage, extension, démontage, suppression.
8. Réseau. Sur console, passer une interface en adresse 192.0.2.10/24, vérifier, revenir en DHCP.
9. Pare-feu. Ouvrir http en exécution seulement, vérifier, recharger pour l'effacer ; puis le rendre permanent et le retirer.
10. SELinux. Provoquer puis corriger un refus d'étiquette avec semanage fcontext et restorecon, sans setenforce 0 définitif.
11. SSH. Installer une clé, tester, durcir sshd, vérifier avec deux sessions, revenir à la copie.
12. Errata. Lister les avis de sécurité en attente ; classer les commandes du cours en lecture, ajout, suppression irréversible.

Critères de réussite

• Nommer la couche (firewalld, permissions, SELinux) qui refuse d'après le symptôme.
• Dire pourquoi on ne désactive pas SELinux et comment on diagnostique un refus.
• Expliquer pourquoi on garde une session ouverte avant de modifier sshd, firewalld ou le réseau.
• Distinguer configuration d'exécution et permanente de firewalld.
• Citer trois différences entre RHEL 9 et 10 et dire que la version de Stéphane reste à confirmer.
• Dire pourquoi pvcreate, mkfs, chmod -R et rm -r ne se lancent qu'après vérification de la cible.