Cours Linux / Protéger un serveur avec le pare-feu, les comptes et les mises à jour

Protéger un serveur Linux consiste à limiter les comptes, les privilèges et les ports aux seuls besoins réels, puis à appliquer les mises à jour de sécurité tout en gardant un moyen de récupération. Avant de modifier SSH ou le pare-feu à distance, conservez la session ouverte, vérifiez l’accès à la console et testez une nouvelle connexion après chaque changement.

Les exemples visent une machine virtuelle Ubuntu 26.04 LTS ou Rocky Linux 9 disposant de SSH, d’un compte administrateur et d’une console accessible. Un conteneur, WSL ou un serveur hébergé peut présenter d’autres services et des règles réseau supplémentaires. Préparez la console de votre machine virtuelle et vérifiez d’abord la connexion SSH depuis un autre terminal : la session déjà établie ne prouve pas qu’une nouvelle session passera.

Relever l’état initial et prévoir le retour arrière

Identifiez l’utilisateur courant, ses groupes, les ports réellement à l’écoute et les unités en échec. Ces commandes observent la machine ; elles ne retirent aucun accès :

id
getent group sudo
getent group wheel
sudo ss -lntup
systemctl --failed

Ubuntu utilise souvent le groupe sudo et Rocky Linux le groupe wheel, mais ce sont les règles sudoers effectives qui déterminent les privilèges. Un port à l’écoute n’est pas forcément accessible depuis Internet : confrontez le processus, l’interface d’écoute, le pare-feu de l’hôte et, le cas échéant, le groupe de sécurité du fournisseur cloud. Décidez quel service doit rester joignable avant de modifier ses règles. Ne désactivez un service inutilisé qu’après avoir établi sa fonction et son éventuelle dépendance pour l’administration.

Ouvrez réellement la console locale ou la console de secours du fournisseur. Notez les règles initiales, le port SSH, l’emplacement des fichiers de configuration et les changements envisagés ; sauvegardez les fichiers concernés selon votre procédure habituelle. Le diagnostic réseau aidera à distinguer une écoute absente d’un blocage de trafic. Si la nouvelle connexion échoue, utilisez la session préservée ou la console pour restaurer la configuration précédente et recommencer les vérifications avant de fermer quoi que ce soit.

Vérifier la clé et les droits avant de durcir SSH

Connectez-vous avec une clé comme utilisateur administratif dans une nouvelle session et vérifiez que cet utilisateur peut effectuer les actions sudo nécessaires. Vous pouvez ensuite envisager de limiter l’accès direct de root et l’authentification par mot de passe. Examinez d’abord sshd_config, ses fichiers inclus, ses blocs Match et toute configuration initiale cloud : ajouter une ligne sans connaître l’ordre et la portée des réglages peut produire un résultat différent de celui attendu.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep -E '^(port|permitrootlogin|passwordauthentication|pubkeyauthentication) '

sshd -t contrôle la validité de la configuration et des clés hôte ; sshd -T affiche les valeurs effectives. Si une directive Match dépend de l’utilisateur ou de l’adresse source, utilisez aussi sshd -T -C avec les paramètres correspondant à la connexion visée : la sortie générale seule peut être trompeuse. Le manuel de sshd décrit ces options.

Après édition et vérification réussie, rechargez le véritable service SSH de cette distribution, puis testez une autre connexion par clé et les droits sudo. Le nom de l’unité peut varier ; identifiez-le sur votre machine avant le rechargement. En cas d’échec, revenez au fichier sauvegardé depuis la session encore active ou la console, revérifiez avec sshd -t et retestez. Ne fermez l’ancienne session qu’une fois la nouvelle validée.

Ubuntu : ouvrir l’accès d’administration avant d’activer UFW

Uncomplicated Firewall (UFW) gère des règles simples de pare-feu sur Ubuntu. L’exemple ci-dessous suppose que le serveur SSH écoute réellement sur TCP 22 et que cette VM est sous votre contrôle. Si le port diffère, remplacez chaque occurrence de 22 par le port confirmé dans la configuration et dans l’écoute. Lisez l’état, prévisualisez la règle, ajoutez-la et activez UFW seulement avec une session et une console de secours disponibles :

sudo ufw status verbose
sudo ufw --dry-run allow 22/tcp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status numbered

--dry-run affiche les règles envisagées sans les appliquer ; il ne teste ni la connectivité réelle ni les éventuels filtres du fournisseur. La règle allow 22/tcp accepte cette connexion de toutes les sources : elle sert ici à préserver l’accès pendant la transition, pas à définir une politique finale pour un serveur exposé. Le guide officiel Ubuntu sur UFW montre aussi la restriction à une adresse ou à un sous-réseau.

Dans un autre terminal, confirmez une nouvelle connexion SSH. Si vous connaissez l’adresse de sortie fiable de votre VPN ou de votre poste, ajoutez ensuite une règle limitée à cette source, testez-la depuis cette source et retirez seulement la règle large que vous aviez ajoutée. Une adresse NAT ou VPN mal identifiée peut vous exclure ; gardez l’ancien accès jusqu’à la vérification. Comparez sudo ufw status numbered à l’état initial avant toute suppression, car les numéros de règle changent après une modification. Si l’activation coupe l’accès, utilisez la console ou la session conservée pour rétablir la règle nécessaire ou revenir à l’état initial.

Rocky Linux : choisir la zone firewalld et distinguer les règles

Sur Rocky Linux, firewalld associe des interfaces ou sources à des zones ; la zone par défaut n’est pas toujours celle de l’interface administrée. Lisez l’état et repérez la zone réellement active avant de modifier les règles :

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone

Remplacez le texte REPLACE_WITH_ACTIVE_ZONE par la zone de l’interface qui reçoit votre connexion. Vérifiez que la définition du service ssh correspond au port SSH effectif ; si le port a été personnalisé, n’utilisez pas aveuglément ce service prédéfini. Contrôlez aussi si la règle existe déjà. Ajoutez d’abord l’autorisation dans la configuration d’exécution (runtime), testez une nouvelle connexion, puis enregistrez uniquement cette règle dans la configuration permanente :

zone=REPLACE_WITH_ACTIVE_ZONE
sudo firewall-cmd --info-service=ssh
sudo firewall-cmd --zone="$zone" --list-all
sudo firewall-cmd --zone="$zone" --add-service=ssh
sudo firewall-cmd --zone="$zone" --list-all
sudo firewall-cmd --permanent --zone="$zone" --add-service=ssh
sudo firewall-cmd --permanent --zone="$zone" --list-all

Les règles runtime agissent immédiatement mais peuvent disparaître après redémarrage ou rechargement de firewalld ; les règles permanentes sont celles conservées. Le guide officiel firewalld sur les ports et services distingue ces deux états. Un simple --reload peut effacer des modifications runtime non enregistrées ; ne copiez pas non plus l’ensemble des règles temporaires vers le permanent par réflexe. Pour revenir en arrière, retirez seulement la règle que vous avez ajoutée et seulement après avoir validé une autre voie d’administration. Une règle préexistante ou nécessaire à la connexion actuelle doit rester en place.

Mettre à jour sans perdre le contrôle du service

Le pare-feu et SSH ne remplacent pas les correctifs. Sur Ubuntu, actualisez l’index puis affichez les paquets susceptibles d’être mis à niveau ; sur Rocky Linux, vérifiez les mises à jour et l’état SELinux. Ce sont des commandes de consultation et de préparation, pas un ordre d’installation à l’aveugle :

sudo apt update
apt list --upgradable

sudo dnf check-update
getenforce

Dans le second bloc, dnf check-update peut renvoyer le code de sortie 100 lorsque des mises à jour sont disponibles ; ne l’assimilez pas automatiquement à une erreur. Examinez les paquets et services touchés, la sauvegarde disponible, la fenêtre de maintenance et l’éventuel redémarrage avant d’installer. Après installation, vérifiez la version attendue, la réponse des services concernés et leur état après un redémarrage requis. Le cours APT et DNF détaille les commandes d’installation et de contrôle ; le cours sur systemd aide à lire l’état des services.

Security-Enhanced Linux (SELinux) ajoute sur Rocky Linux des règles d’accès fondées notamment sur les contextes des fichiers et processus. Si un service ne lit plus un fichier, examinez les permissions classiques, les contextes et les journaux d’audit avant de désactiver SELinux. Pour un chemin non standard, une politique de contexte persistante suivie de restorecon peut être nécessaire ; la bonne étiquette dépend du service et du chemin. Le cours SELinux sur Rocky Linux explique cette vérification, et la documentation officielle Rocky Linux fournit le cadre. SELinux, le pare-feu et les droits des comptes contrôlent des accès différents ; vérifiez chacun dans son contexte.