SysAdmin

I. Les serveurs graphiques

1. À quoi sert le serveur graphique ?

Le serveur graphique donne la possibilité d’afficher une interface graphique dans GNU/Linux.

Une interface graphique est un ensemble de fenêtres avec barres, boutons et décorations. L’interface graphique permet l’usage de la souris. En anglais on dit GUI (= graphical user interface).

Dans GNU/Linux, le serveur graphique s’appelle X mais on dit aussi X window (attention, pas de s final, rien à voir avec le système, ou OS M$Windows).

De très nombreux logiciels ont une interface graphique (comme Firefox, LibreOffice…) mais il existe aussi de nombreux logiciels sans interface graphique qui sont «en ligne de commande».

En fait, quand GNU/Linux démarre, le serveur graphique ne se met en route que tardivement, au moment où apparaît l’écran de login. Ce dernier nous donne accès au bureau si on y met notre nom d’utilisateur et mot de passe.

Pour que le serveur graphique fonctionne, il faut qu’il y ait une carte graphique dans l'UC et qu’elle soit reconnue par le noyau Linux : pour ces matériels, il faut verifier la specification technique de la machine.

2. Sans serveur graphique

Le serveur graphique n’est pas indispensable dans GNU/Linux. Il est très possible de ne pas l’installer car GNU/Linux fonctionne très bien sans bureau, sans fenêtres, sans décorations et sans souris.

À ce moment-là, GNU/Linux démarre normalement (enfin comme sous Debian, avec tout un défilé de lignes blanches sur fond noir, Ubuntu cache tout ce défilé) mais ensuite l'écran reste noir. Juste quelques phrases affichées en blanc nous invitent à mettre notre nom d’utilisateur et mot de passe pour commencer à travailler.

L'écran tout entier est le terminal, le vrai, pas comme le petit terminal (qui est en fait un émulateur, faisant semblant d’en être un vrai) que vous voyez là-bas : Le terminal pour les débutants

En fait, par défaut, il y a 6 terminaux et vous pouvez passer au tty2 avec la combinaison de touches [Ctrl-Alt-F2] et ainsi de suite.

Depuis le terminal, il est possible d’installer le serveur graphique et de le démarrer pour accéder au bureau (grâce à la commande startx).

Depuis le bureau, il est aussi possible de passer derrière le serveur graphique dans n’importe quelle distribution GNU/Linux. Depuis le bureau décoré et avec la combinaison de touches [Ctrl-Alt-F1], on arrive sur le premier terminal tty1. Avec la combinaison de touches Ctrl-Alt-F7 on retourne sur le bureau.

Sans serveur graphique, on ne peut utiliser que des logiciels en ligne de commande mais on peut faire beaucoup de choses :

• Parcourir les fichiers, les déplacer, les renommer, etc.

• Faire des répertoires, en déplacer, en supprimer, etc.

• Rédiger, envoyer, recevoir, lire et classer les emails

• Surfer sur le web (on ne voit pas d’images, ce peut être reposant)

• Rédiger des textes avec un éditeur de texte ou faire du traitement de texte (avec Latex)

• Écouter de la musique

• …

On peut suivre sur Libre-Fan une installation de Debian sur un ordinosaure sans serveur graphique au départ.

Les serveurs, un ordinateur-routeur fonctionnent sans interface graphique car c’est inutile et ce sont des UC sans écran que l’on contrôle à distance, depuis un ordinateur complet.

ChatGPT

Un serveur graphique, dans le contexte de l'informatique, est un logiciel qui gère l'affichage graphique sur un ordinateur. Il agit comme une sorte d'interface entre le matériel graphique de l'ordinateur (carte graphique, écran, etc.) et les programmes qui ont besoin d'afficher des éléments graphiques à l'écran.

Voici une explication détaillée des composants et du fonctionnement d'un serveur graphique :

1. Affichage matériel : Le serveur graphique interagit avec le matériel graphique de l'ordinateur, tel que la carte graphique, les écrans et les périphériques d'entrée (souris, clavier, etc.). Il est chargé de communiquer avec ces composants pour afficher les graphismes à l'écran et gérer les entrées utilisateur.

2. Gestion des fenêtres : Le serveur graphique est responsable de la création, de la gestion et de la manipulation des fenêtres sur l'écran. Cela inclut le redimensionnement, le déplacement et la superposition des fenêtres, ainsi que la gestion des événements liés aux fenêtres (clics de souris, frappes de clavier, etc.).

3. Système de fenêtrage : Le serveur graphique utilise un système de fenêtrage pour organiser les fenêtres sur l'écran. Il existe différents systèmes de fenêtrage, tels que :

• le système de fenêtrage en cascade

• le système de fenêtrage en mosaïque

• le système de fenêtrage en pile.

Ces systèmes déterminent comment les fenêtres sont disposées et comment les utilisateurs interagissent avec elles.

1. Affichage des graphismes : Le serveur graphique est chargé d'afficher les éléments graphiques à l'écran, tels que les images, les icônes, les polices de caractères, les widgets d'interface utilisateur, etc. Il utilise des bibliothèques graphiques et des pilotes de périphériques pour convertir les données graphiques en signaux que l'écran peut afficher.

2. Gestion des événements : Le serveur graphique reçoit et traite les événements utilisateur, tels que les clics de souris, les mouvements de la souris, les frappes de clavier, etc. Il est chargé de transmettre ces événements aux programmes appropriés en fonction de la position de la souris et de l'état des fenêtres.

3. Protocoles de communication : Les serveurs graphiques utilisent souvent des protocoles de communication pour interagir avec les clients graphiques, tels que les applications et les environnements de bureau. Ces protocoles permettent aux clients graphiques de demander des services au serveur graphique, tels que la création de fenêtres, le dessin d'images, etc.

Les serveurs graphiques les plus couramment utilisés dans les systèmes d'exploitation modernes sont X.Org Server et Wayland. X.Org Server est un serveur graphique open source largement utilisé dans les systèmes Unix et Unix-like, tandis que Wayland est une nouvelle architecture de serveur graphique conçue pour remplacer X.Org Server dans certains environnements de bureau.

II. X.org

X.Org est un serveur X libre issu d'un fork de XFree86 en janvier 2004 à la suite d'un désaccord sur le changement de licence de XFree86. Il fonctionne avec la plupart des systèmes d'exploitation de type UNIX (GNU/Linux, dérivés de BSD, Solaris, etc.), mais aussi avec Microsoft Windows via Cygwin. Du fait de sa licence, il connaît une grande popularité au sein de la communauté du logiciel libre où il a remplacé XFree86.

La gouvernance du projet est assurée par la fondation X.Org, laquelle réalise à la fois les développements en conjonction avec la communauté Freedesktop.org tout en veillant à la cohérence de l'ensemble de ses projets.

X.org est un logiciel libre du type serveur X, la famille des systèmes de fenêtrage la plus connue, pour les systèmes d'exploitation de type UNIX. X.org est l'implémentation officielle du système graphique X Window System.

C'est donc un serveur graphique, c'est lui qui va faire en sorte que l'on dispose d'autre chose que les ttys sur le système, il va fournir une interface graphique. Seul, il est limité; il n'affiche en effet que des fenêtres, il faudra recourir à l'utilisation d'un gestionnaire de fenêtre ou d'un environnement de bureau si on veut un résultat plus agréable à l'oeil.

X.org est un programme basé sur une architecture serveur/client :

• le serveur X est lancé sur une machine possédant un écran, un clavier et une souris (ou d'autres périphériques)

• le client X se connecte au serveur afin de lui donner ses requêtes, ce sont des applications graphiques affichées dans une fenêtre du serveur X

• le protocole X qui permet l'échange de données entre le serveur et le client

Sans serveur graphique, impossible d'avoir un rendu autre que celui de la console.

III. KDump (Kernel dump ou Kernel core dump)

Kdump est une fonctionnalité présente dans le noyau Linux qui permet la capture de l'état du noyau en cas de panne système (kernel panic) ou de dysfonctionnement grave. Lorsqu'un système subit un kernel panic, il arrête brusquement toutes les opérations en cours, ce qui peut entraîner la perte de données importantes pour le diagnostic de la panne.

Kdump intervient pour résoudre ce problème en créant un noyau de secours minimal qui est chargé en mémoire lorsque le système principal rencontre une panne. Ce noyau de secours est lancé dans un environnement isolé, distinct du système principal, ce qui permet de capturer des informations sur l'état du système au moment de la panne sans risquer d'écraser les données existantes.

Voici comment fonctionne généralement Kdump :

1. Configuration du système : Pour utiliser Kdump, on doit configurer le système pour qu'il alloue de l'espace mémoire réservé pour le noyau de secours et pour les informations de débogage.

2. Déclenchement d'une panne système : Lorsqu'une panne système se produit, le noyau principal du système est incapable de récupérer et déclenche un kernel panic. À ce stade, le noyau de secours n'a pas été chargé.

3. Chargement du noyau de secours : Après le kernel panic, le noyau de secours est chargé en mémoire. Ce noyau est minimaliste, ne contenant que les éléments nécessaires pour capturer l'état du système et les informations de débogage.

4. Capture de l'état du système : Une fois que le noyau de secours est chargé, il capture l'état de la mémoire, les registres du processeur, les informations sur les pilotes et d'autres données pertinentes qui peuvent aider à diagnostiquer la panne.

5. Enregistrement des informations : Les informations capturées sont enregistrées sur un périphérique de stockage, tel qu'un disque dur ou un réseau. Ces données peuvent ensuite être utilisées pour analyser la panne et identifier sa cause.

Kdump est un outil précieux pour le débogage des problèmes système sur les serveurs Linux et les environnements critiques où la disponibilité et la fiabilité sont essentielles. Il permet aux administrateurs système et aux développeurs de diagnostiquer et de résoudre les problèmes système de manière efficace en fournissant des informations détaillées sur l'état du système au moment de la panne.

IV. SELinux (Security-Enhanced Linux)

ChatGPT

SELinux, ou Security-Enhanced Linux, est une technologie de sécurité qui vise à renforcer la sécurité des systèmes Linux en permettant un contrôle plus fin des politiques de sécurité au niveau du noyau. Contrairement à la sécurité traditionnelle basée sur les permissions des utilisateurs et des groupes, SELinux utilise des politiques de sécurité basées sur le contrôle d'accès obligatoire (MAC), ce qui signifie que les décisions de sécurité sont prises en fonction de règles définies par l'administrateur système, indépendamment des autorisations attribuées aux utilisateurs et aux processus.

En pratique, cela signifie que SELinux peut limiter les actions que les processus peuvent entreprendre en fonction de leur contexte de sécurité. Par exemple, même si un utilisateur dispose des autorisations pour modifier un fichier, SELinux peut empêcher un processus spécifique d'accéder à ce fichier en fonction de ses politiques de sécurité.

Bien que puissant, SELinux peut être complexe à configurer et à administrer en raison de sa nature granulaire. Cependant, il fournit un niveau de sécurité supplémentaire pour les systèmes Linux, ce qui en fait un outil précieux dans les environnements où la sécurité est une préoccupation majeure.

Pense à SELinux comme à un garde de sécurité très minutieux pour ton ordinateur. Il ne se contente pas de vérifier qui tu es (ton nom d'utilisateur), mais il examine aussi ce que tu veux faire et où tu veux aller sur ton ordinateur.

Imagine que tu veuilles ouvrir un fichier. SELinux ne se contente pas de vérifier si tu as la permission de l'ouvrir en tant qu'utilisateur, il regarde aussi d'autres choses comme le type de fichier, le programme que tu utilises pour l'ouvrir, et même d'autres détails. Cela lui permet de dire "Oui" ou "Non" à l'accès au fichier en fonction de règles très précises, même si ton utilisateur aurait normalement la permission de l'ouvrir.

Donc, SELinux renforce la sécurité de ton ordinateur en ajoutant une couche supplémentaire de contrôle très détaillé sur ce que les programmes peuvent faire, pour s'assurer qu'ils ne font que ce qu'ils sont censés faire, même si quelque chose d'autre essaie de les manipuler.

Wikipedia

Security-Enhanced Linux, abrégé SELinux, est un Linux security module (LSM), qui permet de définir une politique de contrôle d'accès obligatoire aux éléments d'un système issu de Linux.

Son architecture dissocie l'application de la politique d'accès et sa définition. Il permet notamment de classer les applications d'un système en différents groupes, avec des niveaux d'accès plus fins. Il permet aussi d'attribuer un niveau de confidentialité pour l'accès à des objets systèmes, comme des descripteurs de fichiers, selon un modèle de sécurité multiniveau (MLS pour Multi level Security). SELinux utilise le modèle Bell LaPadula complété par le mécanisme Type enforcement de contrôle de l'intégrité, développé par SCC (SeCure Computing). Il s'agit d'un logiciel libre, certaines parties étant sous licences GNU GPL et BSD3.

Utilisation

En pratique, la base de l'innovation est de définir des attributs étendus dans le système de fichiers. En plus de la notion de « droits de lecture, écriture, exécution » pour un usager donné, SELinux définit pour chaque fichier ou processus :

• Un usager virtuel (ou collection de rôles) ;
• Un rôle ;
• Un contexte de sécurité.

Les commandes « système » sont étendues pour pouvoir manipuler ces objets et définir des politiques (règles d'accès), et des statuts (niveau de confidentialité). Par exemple la commande « ls -Z » fait apparaître lesdits attributs étendus, soit :

ls -Z /etc/passwd

donne le résultat suivant:

-rw-r--r--  root root  system_u:object_r:etc_t  /etc/passwd

Une distribution Linux peut être livrée avec des politiques prédéfinies pour la totalité du système (mode strict), ou une partie des services/applications (mode ciblé ou targeted). Le réglage d'un certain nombre de variables booléennes prédéfinies permet de personnaliser le comportement des applications correspondantes.

Installation

Debian

~$ sudo apt install selinux-basics selinux-policy-default selinux-utils

CentOS

~$ sudo yum install policycoreutils policycoreutils-python selinux-policy selinux-policy-targeted libselinux-utils setroubleshoot-server setools setools-console mcstrans

Modes

• Enforcing (Appliquer) : C'est le mode par défaut dans lequel SELinux applique strictement les politiques de sécurité définies. Dans ce mode, SELinux bloque les actions qui ne sont pas autorisées par les politiques, ce qui renforce la sécurité du système.
• Permissive (Accorder une avertissement) : Dans ce mode, SELinux ne bloque pas les actions qui violent les politiques de sécurité, mais il enregistre ces violations dans les journaux système. Cela permet aux administrateurs de voir quelles actions seraient bloquées en mode Enforcing sans réellement les empêcher, ce qui peut être utile pour déboguer les problèmes de sécurité potentiels sans interrompre le fonctionnement normal du système.
• Disabled (Désactivé) : Dans ce mode, SELinux est complètement désactivé et ne s'applique pas du tout. Toutes les politiques de sécurité SELinux sont ignorées, ce qui signifie que le contrôle d'accès obligatoire (MAC) n'est pas utilisé. Bien que ce mode puisse être pratique pour résoudre des problèmes de compatibilité ou de performance, il est moins sécurisé que les modes Enforcing et Permissive, car il ne fournit aucune protection basée sur SELinux.

SELinux s'integre tres bien avec Rocky OS plutot qu'avec Debian. Debian utilise plutot une autre technologie de securite Linux Security Module appelee AppArmor, mais on peut utiliser SELinux sous Debian.

V. AppArmor

ChatGPT

AppArmor est un système de contrôle d'accès facultatif (DAC) qui vise à renforcer la sécurité des systèmes Linux en permettant aux administrateurs de définir des politiques de sécurité spécifiques pour les applications. Contrairement à SELinux, qui utilise un contrôle d'accès obligatoire (MAC), AppArmor utilise un modèle basé sur des profils pour spécifier quelles actions sont autorisées pour chaque application sur le système.

Voici comment fonctionne AppArmor et comment il est utilisé :

1. Profils de sécurité : AppArmor utilise des profils de sécurité pour définir les règles qui spécifient quelles ressources une application est autorisée à accéder et quelles actions elle est autorisée à effectuer. Ces profils sont généralement définis dans des fichiers de configuration texte qui décrivent les autorisations pour chaque application.

2. Restrictions basées sur le chemin d'accès : Les profils AppArmor peuvent inclure des règles qui limitent l'accès aux fichiers et aux répertoires en fonction de leur emplacement sur le système de fichiers. Par exemple, un profil AppArmor pour un serveur web peut spécifier que l'application est autorisée à lire des fichiers dans son répertoire de contenu web, mais pas à accéder aux fichiers système sensibles.

3. Contrôle des capacités : AppArmor peut également limiter les capacités des applications, telles que la capacité à se connecter à un réseau, à ouvrir des sockets réseau, à modifier des fichiers système, etc. Cela permet de réduire les risques en limitant les actions potentiellement dangereuses que les applications peuvent effectuer.

4. Mode de fonctionnement : AppArmor peut fonctionner en mode Enforcing, où il applique strictement les politiques de sécurité définies, ou en mode Audit, où il enregistre les violations des politiques de sécurité sans les bloquer effectivement. Cela permet aux administrateurs de surveiller les activités des applications et de corriger les politiques si nécessaire.

5. Utilité : AppArmor est utile pour renforcer la sécurité des systèmes Linux en limitant les actions que les applications peuvent entreprendre, ce qui réduit les risques d'exploitation et de compromission du système. Il est souvent utilisé dans des environnements où la simplicité de configuration est préférée, comme les serveurs web, les serveurs de bases de données et les conteneurs Docker.

En résumé, AppArmor est un outil de sécurité flexible qui permet aux administrateurs de définir des politiques de sécurité spécifiques pour les applications sur les systèmes Linux, en limitant leurs accès aux ressources du système et en réduisant les risques de sécurité.

Wikipedia

AppArmor (Application Armor) est un logiciel de sécurité pour Linux édité sous Licence publique générale GNU.

AppArmor permet à l'administrateur système d'associer à chaque programme un profil de sécurité qui restreint ses accès au système d'exploitation. Il complète le traditionnel modèle d'Unix du contrôle d'accès discrétionnaire (DAC, Discretionary access control) en permettant d'utiliser le contrôle d'accès obligatoire (MAC, Mandatory access control).

En plus des profils de spécifications manuels, AppArmor comprend un mode d'apprentissage (learning mode), où toutes les transgressions au profil sont enregistrées, mais pas empêchées. Ce fichier de suivi peut alors être incorporé au profil, se fondant alors sur le comportement typique du programme.

AppArmor est mis en place au sein du noyau Linux au moyen de l'interface de sécurité du noyau, LSM (Linux Security Modules).

AppArmor a été créé en partie comme une alternative à SELinux, critiqué pour être difficile à paramétrer et à maintenir par les administrateurs. À la différence de SELinux, qui s'appuie sur l'application d'indicateurs aux fichiers, AppArmor travaille avec les chemins. Les partisans d'AppArmor disent que c'est moins complexe et plus facile pour l'utilisateur moyen que d'apprendre SELinux. Ils prétendent aussi qu'AppArmor demande moins de modifications pour fonctionner avec les systèmes existants ; par exemple, SELinux demande d'utiliser un système de fichiers qui prend en charge les attributs étendus pour les fichiers, et ne peut donc pas gérer le contrôle d'accès pour les fichiers montés avec NFS.

Initialement développé par Crispin Cowan de la société Immunix, AppArmor fut repris par Novell lorsque cette dernière racheta Immunix. Novell abandonna cependant le projet et licencia les développeurs d'AppArmor. Canonical en a repris le développement et AppArmor est intégré au noyau Linux depuis la version 2.6.364.

AppArmor est installé par défaut sur Debian, openSUSE, Ubuntu et Parrot OS. Il est disponible sur Annvix, Arch Linux, Gentoo, Mandriva, NixOS, Pardus Linux et PLD.

AppArmor VS SELinux

Bien qu'ils partagent un objectif commun, SELinux et AppArmor diffèrent dans leurs approches de mise en œuvre et dans la manière dont ils définissent et appliquent les politiques de sécurité.

SELinux

• SELinux utilise un contrôle d'accès obligatoire (MAC) basé sur des règles
• Avec SELinux, les données qui sont inaccessibles peuvent devenir accessibles lorsque les applications mettent à jour le fichier en le remplaçant par une nouvelle version.

AppArmor

• AppArmor utilise un modèle de contrôle d'accès facultatif (DAC) basé sur des profils.
• Avec AppArmor, un fichier qui est inaccessible peut devenir accessible quand un lien est créé, alors que SELinux interdira l'accès à travers le nouveau lien créé

VI. Partition disque

En informatique, une partition, région ou un disque est une section d'un support de stockage (disque dur, SSD, carte-mémoire...). Le partitionnement est l'opération qui consiste à diviser ce support en partitions dans lesquelles le système d'exploitation peut gérer les informations de manière séparée, généralement en y créant un système de fichiers, une manière d’organiser l’espace disponible.

les systèmes Unix ou Gnu/Linux, les désignent par un identifiant sous la forme sdXN, avec X une lettre représentant le support et N le numéro de la partition sur le support (par exemple sdb3 pour la troisième partition du disque b).

Utilité

1. Résilience

Le partitionnement propose également d’autres avantages que la rapidité d’accès aux données. Imaginons un disque non-partitionné, celui-ci est considéré par le système d’exploitation comme une seule et unique unité.

Cette unité contiendrait votre installation Linux (ou n’importe quel autre système d’exploitation), vos logiciels, vos fichiers, les logs de vos applications, vos fichiers binaires.

Dans le cadre d’un serveur, imaginons que suite à une attaque virale, un crash Linux, ou toute autre raison vous deviez réinstaller le système d’exploitation.

Dans le cadre d’une réinstallation de système d’exploitation, le plus souvent le formatage de disque sur lequel se trouve l’installation actuelle est inévitable. Seulement, ce formatage a pour effet de supprimer toutes les données présentes sur la partition, et ce de manière irréversible si vous n’avez réalisé aucune sauvegarde. La partitionnement permet de remédier à ce problème, il suffit de réserver une partition à son système d’exploitation, ainsi, si une réinstallation est nécessaire, celle-ci n’effacera que les données sur cette partition, et conservera les données des autres partitions. Et ce même si elles se trouvent sur un même disque physique.

En plus de cela, le partitionnement propose beaucoup d’avantages en termes de sécurité.

2. Sécurité et bonnes pratiques sur un système Linux

La sécurité est un aspect capital de la gestion des systèmes d’informations, beaucoup de serveurs utilisent l’OS Linux et le partitionnement peut aider à les sécuriser.

Les lignes qui suivent sont tirées des mesures de sécurités recommandées par l’ANSSI pour les systèmes Linux.

Il est usuel de réserver des partitions dédiées aux services pouvant générer beaucoup de volumétrie afin d’éviter de saturer les partitions système. L’espace à réserver pour chaque partition dépend des cas d’usage : un serveur de fichiers aura besoin d’une volumétrie importante pour /srv ou /var/ftp/, tandis qu’un serveur de journaux sera plutôt concerné par la volumétrie utilisable pour /var/log.>

Le partitionnement doit ainsi permettre de protéger et d’isoler les différents composants du système de fichiers. Il est par défaut souvent insatisfaisant.

Il faut noter que suivant les systèmes et distributions, certaines des options de montage ne seront pas applicables transitoirement; par exemple des utilitaires, installeurs ou produits estimeront que les fichiers écrits dans /tmp ou /var peuvent être exécutables. Dans ces cas exceptionnels il est nécessaire d’adapter le partitionnement. Un de ceux les plus fréquemment rencontrés est celui des distributions dérivées de Debian dont le /var/lib/dpkg nécessite des droits d’exécution.

Une alternative est d’implémenter une procédure de maintenance durant laquelle les mises à jour sont installées, à l’image de ce que l’on trouve sur d’autres systèmes d’exploitation.

À noter :

• La partition /boot contient notamment le noyau de démarrage et des fichiers dans ce dossier sont souvent parcouru par différents programmes malveillants afin de construire plus facilement des « exploits » de code noyau.
• Lorsque c’est possible, la partition /boot ne doit pas être montée automatiquement. Dans tous les cas, l’accès au dossier /boot doit être uniquement autorisé pour l’utilisateur root.

3. Autres utilités

Le partitionnement de disque peut également être utile dans le cadre de la mise en place d’un chiffrement au repos de votre disque dur.

VII. LVM (Logical Volume Management)

Comment fonctionne le partitionnement sur Linux avec LVM ?

Mais LVM dans tout ça, à quoi ça sert ?

LVM est un gestionnaire de volumes logiques pour le noyau Linux. Le but de LVM est de fournir une couche d'abstraction entre l'espace de stockage physique et le système : il permet de créer des « partitions virtuelles » faciles à gérer (changements de taille, création et suppression...).

Les éléments qui composent LVM sont (4):

• Les volumes physiques (PV) : ce sont les espaces de stockage traditionnels (disques, partitions, éventuellement des fichiers montés en loopback), sur lesquels LVM crée ses volumes logiques. Il comprend un en-tête spécial et se divise en blocs physiques (extents).
• Les groupes de volumes (VG) : Ce sont des groupes de volumes physiques (PV) réunis par LVM en un seul « disque virtuel ». Un groupe de volumes contient des volumes logiques, ceux-ci sont répartis par LVM de manière transparente sur les différents volumes physiques : un volume logique peut même être dispersé à travers les disques disponibles.
• Les volumes logiques (LV) : ce sont des « partitions virtuelles » (logiques parce qu'elles sont produites par un logiciel sans forcément correspondre à une portion d'un disque matériel). Les volumes logiques sont constitués d'étendues de blocs physiques réunis en un seul espace de stockage et rendus lisibles par le système. On peut les utiliser comme des partitions ordinaires.
• Étendue physique (PE) : un petit bloc de disques (en général de 4 Mo) qui peut être affecté à un volume logique. Les étendues physiques se comportent comme les secteurs ou les cylindres des disques durs physiques.
• Étendue Logique (LE) : Les Logical Volumes sont divisés en Logical Extents, qui sont de taille égale aux Physical Extents. Les LE sont l'unité de base pour la création et l'allocation de l'espace dans un Logical Volume.

Prise en main de l'outil LVM

1. Scenario

Il est fort probable qu'on a déja rencontré le message "manque d'espace disque", et alors on doit commencer à passer en revue les téléchargements, supprimer tous les gros fichiers, supprimer les jeux ou autres. On doit penser à l'expansion de disque !

Alors, doit t-on ajouter un autre disque dur, y monter une partition personnelle et commencer à y déplacer des fichiers, ou doit t-on acheter un disque plus grand, copier toutes les partitions, puis étendre les partitions ?

L'un des meilleurs choix que à faire est d'installer la distribution Linux sur une partition LVM.

Lorsque vous vous renseignez pour la première fois des informations sur LVM, cela ressemble un peu à une matrice RAID (Redundant Array of Independent Disks ou Matrice redondante de disques indépendants en français) où on a plusieurs disques et où les données sont réparties sur ces disques d'une manière ou d'une autre. Cependant, LVM ne fournit aucune redondance, mais cela étend bien les partitions sur plusieurs disques physiques, comme le RAID. Et ce que l'on peut faire, c'est continuer à ajouter des disques pour continuer à étendre cette partition à la volée.

2. Quelques commandes basiques pour commencer à s’amuser avec LVM:

Note : Exécutez toutes les commandes en tant que root (en utilisant sudo) ou cela ne fonctionnera pas.

Exemple :

sudo lvs
# Permet de voir quels groupes de volumes sont sur le système

La commande la plus basique de LVM est l’affichage des différents volumes et groupes, pour cela nous disposons de :

• pvs : Afficher les détails succincts des volumes physiques
• vgs : Afficher les détails succincts des groupes de volumes
• lvs : Afficher les détails succincts des volumes logiques

sudo fdisk -l
# Permet d'afficher les noms de partition (ex : /dev/sdXX)

sudo lvdisplay
# Permet de trouver où se trouve le chemin d'accès au volume physique

3. Pour étendre les partitions à un nouveau lecteur

1. Créer une partition LVM vide sur le nouveau disque avec fdisk ou gparted.

2. Créer un volume physique sur le nouveau disque avec pvcreate /dev/sdXX- On peut vérifier le nom de la nouvelle partition avec sudo pvs qui devrait avoir une entrée vide sous VG.

3. Étendre le groupe de volume au nouveau disque avec vgextend my-virtual-group /dev/sdXX.

4. Étendre le volume logique et redimensionnez la partition à l'intérieur avec lvextend -l +100%FREE -r /dev/my-virtual-group/root
   

NOTE : On peut changer la valeur de +100%FREE
en fonction de l'espace que l'on veut que
le nouveau volume logique prenne sur le nouveau disque.

Exemple 1 :

sudo lvextend -l +50%FREE r /dev/my-virtual-group/root

Exemple 2 : éxtension d'une taille spécifique (+10G l'étend de 10 gigaoctets)

sudo lvextend -L +10G -r /dev/my-virtual-group/root

On peut également utiliser +500M pour 500 Mégaoctets et ainsi de suite.

NOTE : Si on spécifie des tailles, la commande
passe de -l minuscule à -L majuscule après lvextend.

VIII. aptitude et apt

Sur le système Debian, les opérations de gestion des paquets basées sur les dépôts peuvent être réalisées à l’aide de nombreux outils de gestion de paquets basés sur APT (Advanced Package Tool) et disponibles dans le système Debian. Nous décrirons ici les outils de base de gestion des paquets : apt, apt-get/apt-cache et aptitude.

Pour les opérations de gestion des paquets qui concernent l’installation des paquets ou les mises à jour des métadonnées des paquets, vous aurez besoin des privilèges de l’administrateur.

1. apt comparé à apt-get / apt-cache comparé à aptitude

a. aptitude (non recommandée)

⛔ Avertissements :

• Non recommandée pour une mise à niveau du système entre versions sur le système Debian stable après la sortie d'une nouvelle version.

  • L'utilisation de apt full-upgrade ou apt-get dist-upgrade est recommandée pour cela.

• Elle suggère parfois la suppression massive de paquets lors de la mise à niveau du système sur des systèmes Debian en testing ou unsable.

  • Cela est principalement causé par un biais de version parmi des paquets dépendants de, ou recommandés par, un méta-paquet tel que gnome-core
  • Solution :
    • 1. Sélecionner Annuler les actions en attente dans le menu de commande d'aptitude.
    • 2. Quitter aptitude.
    • 3. Utiliser la commande apt full-upgrade.

• Elle nécessite plus de ressources matérielles. Elle consomme plus de mémoire et fonctionne moins rapidement.

✅ Avantages :

• Interface utilisateur interactive en plein écran en mode texte.

• Interface utilisateur en ligne de commandes.

• Mieux adapté pour la gestion interactive journalière des paquets (ex : vérification des paquets installés, recherce de paquets disponibles).

• Recherche avancée basée sur des expressions rationnelles pour la recherche sur toutes les métadonnées des paquets.

• Gestion des versions multiples des paquets sans utiliser /etc/apt/preferences. Assez intuitif.

b. apt-get et apt-cache

Ces commandes sont les outils les plus basiques de gestion des paquets basés sur APT (Advanced Package Tool).

• Elles n'offrent qu'une interface utilisateur en ligne de commande

• Elles peuvent gérer des versions multiples des paquets en utilisant /etc/apt/preferences mais est assez lourd.

• apt-get est mieux adapté pour les mises à jour majeures du système entre les versions, etc.

• apt-get offre un système de résolution des dépendances entre paquets robuste.

• apt-get nécessite moins de ressources matérielles. Il consomme moins de mémoire et fonctionne plus rapidement.

• apt-cache offre une recherche basée sur des expressions rationnelles standard sur les noms et les descriptions des paquets.

c. apt (fortement recommandée)

Cette commande est une interface de haut niveau en ligne de commande pour la gestion de paquets. C'est basiquement une enveloppe d'apt-get, d'apt-cache et de commandes similaires, originellement destinée comme interface d'utilisateur final, et active quelques options mieux adaptées par défaut à un usage interactif.

• Elle fournit une barre de progression plaisante lors de l'installation de paquets avec apt install.

• Elle supprimera par défaut les paquets .deb mis en cache après une utilisation réussie de paquets téléchargés.

2. Opérations de base de gestion des paquets en ligne de commandes

apt/apt-get et aptitude peuvent mélangées sans inconvénients majeurs.

« aptitude why expression-rationnelle » peut afficher plus d’informations par « aptitude -v why expression_rationnelle ». On peut obtenir des informations similaires par «apt rdepends paquet» ou «apt-cache rdepends paquet».

Lorsque la commande aptitude est lancée en mode ligne de commande, et rencontre des problèmes tels que des conflits de paquets, on peut passer en mode plein écran en pressant ensuite la touche e à l'invite de commande.

Les options importantes de la commande aptitude

NOTE : Consultez aptitude(8) et le « manuel de l’utilisateur d’aptitude » à « /usr/share/doc/aptitude/README » pour en apprendre davantage.

3. Utilisation interactive d’aptitude

$ sudo aptitude -u
# Permet de mettre à jour la copie locale des informations
# de l'archive et afficher la liste des paquets en plein
# écran avec un menu.

$ sudo -H aptitude ...
# Permet d'utiliser la configuration de l'administrateur.

Fichier de configuration d'aptitude : ~/.aptitude/config

4. Raccourcis clavier d’aptitude

L’indication du nom de fichier sur la ligne de commandes et à l’invite du menu après avoir pressé « l » et « // » prend l’expression rationnelle d’aptitude telle que décrite ci-dessous.

Une expression rationnelle d’aptitude peut correspondre explicitement à un nom de paquet en utilisant une chaîne de caractères commençant par « ~n » et suivie du nom de paquet.

5. Vues des paquets sous aptitude

idA   libsmbclient    -2220kB 3.0.25a-1  3.0.25a-2

a. 1ère lettre : indicateur de l'état actuel.

• i : Installé. Le paquet est actuellement installé sur le système.

• p : Purgeable. Le paquet est installé mais marqué comme étant complètement supprimable.

• v : Virtuel. Le paquet est virtuel, ce qui signifie qu'il représente un groupe de paquets mais n'est pas en soi installable.

• c : Configuré. Le paquet est configuré, mais des fichiers de configuration supplémentaires peuvent être présents.

• u : Non installé. Le paquet n'est pas installé sur le système.

• B : Brisé. Le paquet est partiellement installé ou configuré, mais ne peut pas fonctionner correctement.

b. 2ème lettre : indicateur d'action prévue.

• i : Installer. Le paquet est marqué pour installation.

• d : Supprimer. Le paquet est marqué pour suppression.

• p : Purger. Le paquet est marqué pour une suppression complète.

• h : Tenir. Le paquet est marqué pour être maintenu dans son état actuel sans être mis à jour.

• v : Virtuel. Le paquet est un paquet virtuel.

• C : Nettoyer. Le paquet est marqué pour être nettoyé de tout résidu inutile sur le système.

• U : Mettre à niveau. Le paquet est marqué pour être mis à niveau vers une version plus récente.

c. 3ème lettre : indicateur automatique.

• A : Automatique. Le paquet a été installé automatiquement en tant que dépendance d'un autre paquet.

d. Nom du paquet.

e. Modification de l’utilisation du disque attribuée à l’« action prévue »

f. Version actuelle du paquet

g. Version candidate du paquet

6. Options de la méthode de recherche avec aptitude

a. Ligne de commande du shell.

• aptitude search 'expression_rationnelle_aptitude : permet d'afficher l'état d'installation, le nom du paquet et une courte description des paquets correspondants.

• aptitude show 'nom_paquet : permet d'afficher la description détaillée du paquet.

b. Mode interactif plein écran.

• l : limiter la vue des paquets à ceux qui correspondent.

• / : rechercher un paquet correspondant.

• ** : rechercher en arrière un paquet correspondant.

• n : rechercher le suivant.

• N : rechercher le suivant (en arrière).

7. Les formules d’expressions rationnelles d’aptitude (Extended Rational Expression ou ERE)

8. Résolution des dépendances par aptitude

La sélection d'un paquet dans aptitude récupère non seulement les paquets définis dans son champ "Depends:" mais aussi ceux définis dans le champ "Recommends:" si la configuration a été faite dans ce sens dans le menu "F10 -> Options -> Préférences -> Gestion des dépendances".

Ces paquets installés automatiquement seront supprimés automatiquement s'ils ne sont plus nécessaires sous aptitude.

Le drapeau contrôlant le comportement auto install de la commande aptitude peut aussi être manipulé en utilisant la commande apt-mark du paquet apt.

9. Journaux d’activité des paquets

IX. SSH (Secure SHell)

• Souvent utilisé dans le domaine de la cybersécurité.

• Méthode sécurisée d'accès à distance.

1. Qu'est-ce que le SSH ?

Le protocole Secure SHell est un standard de sécurité utilisé pour échanger des données de manière sécurisée sur un réseau, notamment sur Internet. Il garantit la confidentialité des données en les cryptant avant de les transmettre.

• Remplaçant de Telnet non chiffré.

• Utilise des techniques cryptographiques pour s'assurer que toutes les communications vers/depuis le serveur distant se produisent de manière chiffrée.

Il fournit un mécanisme pour :

• Authentifier un utilisateur distant.

• Transférer les entrées du client vers l'hôte.

• Relayer la sortie vers le client.

On peut exécuter des commandes shell de la même manière que l'on le faisait si on était en train d'utiliser physiquement l'ordinateur distant.

2. Fonctionnement de SSH.

Si on utilise Linux ou Mac, l'utilisation de SSH est très simple. Si on utilise un système d'exploitation Windows, on doit utiliser des outils Windows de connexion SSH. Le client SSH le plus populaire est PuTTY

La commande SSH se compose de 3 parties distinctes :

$ ssh {user}@{host}

Cette commande indique au système que l'on souhaite ouvrir une connexion Secure SHell cryptée.

• {user} : compte auquel on souhaite accéder. (ex : root)

• {host} : ordinateur auquel on souhaite accéder. Ceci peut être une adresse IP ou un nom de domaine.

Quand on appuie sur Entrée, on sera invité à entrer le mot de passe du compte demandé. Si c'est correct, alors on sera accueilli avec une fenêtre de terminal à distance.

3. À quoi sert SSH ?

SSH est un protocole réseau sécurisé permettant d'établir une connexion cryptée entre un client et un serveur. Il offre une multitude d'utilisations pratiques dans le domaine informatique :

• Gestion à distance des serveurs, de l'infrastructure et des ordinateurs collaborateurs : Les administrateurs systèmes peuvent se connecter de manière sécurisée à des serveurs distants pour effectuer des tâches de configuration, de maintenance et de surveillance à distance.

• Transfert de fichiers en toute sécurité : SSH propose des protocoles comme SFTP (SSH File Transfert Protocol) et SCP (Secure Copy Protocol) pour le transfert sécurisé de fichiers entre des ordinateurs distants, garantissant ainsi la confidentialité et l'intégrité des données.

• Accès à des services dans le cloud sans exposer les ports d'une machine locale à l'Internet : Les utilisateurs peuvent se connecter de manière sécurisée à des services dans le cloud via SSH sans avoir à exposer les ports de leur machine locale à Internet, renforçant ainsi la sécurité de leur infrastructure.

• Connexion à distance aux services d'un réseau privé : SSH permet aux utilisateurs de se connecter de manière sécurisée aux services d'un réseau privé depuis n'importe où dans le monde, assurant ainsi la confidentialité et la sécurité des communications.

• Contournement des restrictions d'un pare-feu : En utilisant le tunneling SSH, les utilisateurs peuvent contourner les restrictions d'un pare-feu en acheminant leur trafic à travers une connexion SSH sécurisée, offrant ainsi un accès sécurisée à des services normalement bloqués par le pare-feu.

4. Comprendre différentes techniques de cryptage.

Avantage de SSH par rapport aux autres : Utilisation du cryptage pour assurer le transfert sécurisé d'informations entre l'hôte et le client.

Host = serveur distant auquel on tente d'accéder.
Client = l'ordinateur que l'on utilise pour accéder à l'hôte.

Il existe 3 technologies de cryptage différentes utilisées par SSH :

• Cryptage symétrique.

• Cryptage asymétrique.

• Hashing.

4.1. Cryptage symétrique (clé partagée ou cryptage de secret partagé).

C'est une forme de cryptage où une clé secrète est utilisée pour le _cryptage et le décryptage d'un message par le client et l'hôte_.

Toute personne possédant la clé peut décrypter le message transféré.

Ce cryptage n'a habituellement qu'une seule touche qui est utilisée, ou parfois une paire de touches où une clé peut facilement être calculée à l'aide de l'autre clé.

Les clés symétriques sont utilisées pour chiffrer toute la communication lors d'une session SSH. Le client et le serveur dérivent la clé secrète en utilisant une méthode convenue, et la clé résultante n'est jamais divulguée à un tiers.

Le processus de création d'une clé symétrique s'effectue par un algorithme d'échange de clés.

Ce qui rend cet algorithme particulièrement sécurisé, c'est le fait que la clé n'est jamais transmise entre le client et l'hôte. Au lieu de cela, les deux ordinateurs partagent des données publiques, puis les manipulent pour calculer de manière indépendante la clé secrète. Même si une autre machine capture les données publiquement partagées, il ne sera pas capable de calculer la clé car l'algorithme d'échange de clés n'est pas connu.

La clé secrète est spécifique à chaque session SSH et est générée avant l'authentification du client.

Une fois la clé générée, tous les paquets qui se déplacent entre les deux machines doivent être cryptés par la clé privée. Cela inclut le mot de passe tapé dans la console par l'utilisateur, de sorte que les informations d'identification sont toujours protégées des sniffers de paquets réseau.

Il existe une variété de chiffrages symétriques :

• AES (Advanced Encryption Standard)

• CAST128

• Blowfish

• ...

Avant d'établir une connexion sécurisée, le client et un hôte décident quel chiffrage utiliser, en publiant une liste des chiffrages compatibles, par ordre de préférence.

Le chiffrage préféré des cybers clients pris en charge sur la liste de l'hôte est utilisé comme chiffrage bidirectionnel.

Exemple : Si 2 machines Ubuntu 14.04 LTS communiquent entre elles sur SSH, elles utiliseront aes128-ctr comme leur chiffrement par défaut.

4.2. Cryptage asymétrique.

Contrairement au cryptage symétrique, le cryptage asymétrique utilise 2 clés distinctes pour le cryptage et le décryptage. Ces 2 clés sont appelées clé publique et clé privée. Ensemble, ces 2 clés forment une paire de clés public-privé.

La clé publique est distribuée et partagée ouvertement avec toutes les parties. Bien qu'elle soit étroitement liée à la clé privée en termes de fonctionnalité, la clé privée ne peut pas être calculée mathématiquement à partir de la clé publique. La relation entre les 2 clés est très complexe.

Un message crypté par une clé publique d'une machine ne peut être déchiffré que par la clé privée d'une même machine. Cette relation à sens unique signifie que la clé publique ne peut pas décrypter ses propres messages, ni décrypter quelque chose crypté par la clé privée.

La clé privée doit rester privée, càd que la connexion doit être sécurisée, aucun tiers ne doit jamais la connaître. La force de l'ensemble de la connexion réside dans le fait que la clé privée n'est jamais révélée, car elle est le seul composant capable de décrypter des messages cryptés à l'aide de sa propre clé publique.

Par conséquent, toute partie ayant la capacité de décrypter des messages signés publiquement doit posséder la clé privée correspondante.

Le cryptage asymétrique n'est pas utilisé pour chiffrer toute la session SSH. Au lieu de cela, il n'est utilisé que pendant l'algorithme d'échange de clés de cryptage symétrique.

Avant de lancer une connexion sécurisée, les 2 parties génèrent des paires de clés public-privé temporaires et partagent leurs clés privées respectives pour produire la clé secrète partagée.

Une fois qu'une communication symétrique sécurisée a été établie, le serveur utilise la clé publique des clients pour générer et contester et transmettre au client une authentification. Si le client peut décrypter avec succès le message, cela signifie qu'il dispose de la clé privée requise pour la connexion. La session SSH commence alors.

4.3. Hashing (hachage).

Le hachage à sens unique est une autre forme de cryptographie utilisée dans les connexions Secure SHell. Les fonctions one-way-hash diffèrent des deux formes de cryptage ci-dessus en ce sens qu’elles ne sont jamais destinées à être déchiffrées. Elles génèrent une valeur unique d’une longueur fixe pour chaque entrée, dont aucune tendance claire ne peut être exploitée. Cela rend pratiquement impossible l’inversion.

Il est facile de générer un hachage cryptographique à partir d’une entrée donnée, mais impossible de générer l’entrée du hash. Cela signifie que si un client détient l’entrée correcte, il peut générer le hachage cryptographique et comparer sa valeur pour vérifier s’il possède la bonne entrée.

SSH utilise des hachages pour vérifier l’authenticité des messages. Ceci est fait en utilisant HMAC, ou Hash-based Message Authentication Codes. Cela garantit que la commande reçue n’est modifiée d’aucune manière que ce soit.

Même si l’algorithme de cryptage symétrique est sélectionné, un algorithme d’authentification de message approprié est également sélectionné. Cela fonctionne de manière similaire à la façon dont le chiffrage est sélectionné, comme expliqué dans la section sur le cryptage symétrique.

Chaque message transmis doit contenir un MAC, qui est calculé en utilisant la clé symétrique, le numéro de séquence de paquets et le contenu du message. Il est envoyé en dehors des données cryptées symétriquement comme la partie finale du paquet de communication.

5. Comment fonctionne SSH avec ces techniques de cryptage ?

Il utilise un modèle client-serveur pour permettre :

• l'authentification de deux sytèmes distants.
• le cryptage des données qui les traversent.

SSH fonctionne par défaut sur le port TCP 22 (modifiable à volonté) :

• L'hôte écoute le port et guette les connexions entrantes.
• L'hôte organise la connexion sécurisée en authentifiant le client et en ouvrant le bon environnement si la vérification est réussie.

Le client doit commencer la connexion SSH :

• Lancer le handshake TCP avec le serveur.
• Assurer une connexion symétrique sécurisée.
• Vérifier si l'identité affichée par le serveur correspond aux enregistrements précédents (habituellement enregistrés dans un fichier de stockage de clés RSA).
• Vérifier si l'identité affichée par le serveur présente les informations d'identification requises pour authentifier la connexion.

Il existe 2 étapes pour établir une connexion :

• Les systèmes doivent s'entendre sur les normes de cryptage pour protéger les communications futures.
• L'utilisateur doit s'authentifier.

5.1. Négociation de chiffrement de session.

Lorsqu’un client tente de se connecter au serveur via TCP, le serveur présente les protocoles de cryptage et les versions respectives qu’il prend en charge. Si le client possède une paire de protocoles et de versions correspondant, un accord est atteint et la connexion commence avec le protocole accepté. Le serveur utilise également une clé publique asymétrique que le client peut utiliser pour vérifier l’authenticité de l’hôte.

Une fois que cela est établi, les deux parties utilisent ce qu’on appelle un algorithme d’échange de clés Diffie-Hellman pour créer une clé symétrique. Cet algorithme permet au client et au serveur d’arriver à une clé de cryptage partagée qui sera désormais utilisée pour chiffrer toute la session de communication.

Principe de l'algorithme d'échange de clés de Diffie-Hellman :

Voici comment l'algorithme fonctionne à un niveau très basique :

• 1. Le client et le serveur se mettent d'accord sur un très grand nombre premier p, qui n'a bien sûr aucun facteur en commun. Cette valeur de nombre premier est également appelée valeur de départ.
• 1. Ensuite, les 2 parties conviennent d'un mécanisme de cryptage commun pour générer un autre ensemble de valeurs en manipulant les valeurs de base d'une manière algorithmique spécifique. Ces mécanismes, également appelés générateurs de cryptage, effectuent de grandes opérations sur les valeurs de base. Exemple : AES (Advanced Encryption Standard).
• 1. Les 2 parties génèrent indépendamment un autre nombre premier (a et b). Celui-ci est utilisé comme clé privée secrète pour l'intéraction.
• 1. Cette clé privée nouvellement générée (a et b), avec le numéro partagé (p) et l'algorithme de cryptage (ex. AES), sert à calculer une clé publique (A et B) qui est distribuée à l'autre ordinateur.
• 1. Les parties utilisent ensuite leur propre clé privée (a/b), la clé publique partagée (A/B) de l'autre machine et le numéro premier d'origine (p) pour créer une clé secrète partagée finale. Cette clé est calculée indépendamment par les 2 ordinateurs, mais créera la même clé de cryptage des 2 côtés.
• 1. Maintenant que les 2 côtés ont une clé partagée, ils peuvent chiffrer symétriquement toute la session SSH. La même clé peut être utilisée pour chiffrer et décrypter des messages.

Maintenant que la session sécurisée symétriquement cryptée a été établie, l’utilisateur doit être authentifié.

5.2. Authentification de l'utilisateur. (Phase finale)

La plupart des utilisateurs SSH utilisent un mot de passe. L'utilisateur est invité à entrer le nom d'utilisateur, suivi du mot de passe. Ces informations d'identification passent en toute sécurité par le tunnel crypté symétriquement, de sorte qu'il n'a aucune chance d'être capturé par un tiers.

Bien que les mots de passe soient cryptés, il n'est pas recommandé d'utiliser des mots de passe pour les connexions sécurisées. C'est parce que de nombreux robots peuvent simplement forcer des mots de passe faciles ou mots de passe par défaut, et accéder au compte. Au lieu de cela, l'alternative recommandée est SSH Key Pairs.

Le SSH Key Pairs est un ensemble de clés asymétriques utilisées pour authentifier l'utilisateur sans avoir à entrer de mot de passe.

6. Risque de sécurité associés au SSH et meilleures pratiques.

• Attaques par force brute visant les identifiants SSH.

• Vulnérabilités logicielles.

• Erreurs de configuration.

Pour atténuer ces risques, il est recommandé de suivre certaines meilleures pratiques de sécurité :

• Utilisation de clés SSH robustes plutôt que de mot de passe.
• Mise à jour régulière des logiciels SSH pour corriger les failles de sécurité connues.
• Configuration appropriée des paramètres de sécurité pour limiter l'accès non autorisé.
• Surveillance continue des journaux d'activié SSH -› aide à la détection de tentatives d'intrusion.

7. Qu'est-ce que SSH ? - FAQ

7.1. Pourquoi SSH est-il utilisé ?

Secure SHell (SSH en abrégé) est un protocole de communication réseau qui permet à 2 ordinateurs de communiquer entre eux. SSH permet également le transfert de données entre 2 ordinateurs.

7.2. Que signifie SSH ?

SSH est l'abréviation du protocole réseau Secure SHell, ou Secure Socket Shell.

7.3. Qu'est-ce que SSH par rapport à SSL ?

• SSH crée un réseau sécurisé entre ordinateurs qui permet le transfert de données.

• SSL (Secure Sockets Layer) crypte les données transférées, réduisant ainsi les tentatives de malveillance et d'hameçonnage.

X. Le pare-feu UFW (Uncomplicated FireWall).

UFW est une interface de gestion de pare-feu simplifiée qui masque la complexité des technologies de filtrage de paquets de niveau inférieur telles que iptables et nftables.

1. Installation.

$ sudo apt-get install ufw

2. Utilisation d'IPv6 avec UFW (facultatif).

Il faut s'assurer qu'UFW est configuré pour prendre en charge IPv6 afin de gérer les règles de pare-feu pour IPv6 en plus d'IPv4.

$ sudo nano /etc/default/ufw
# Il faut s'assurer que la valeur d'IPv6 est yes.
# IPV6=yes

Lorsque l'UFW est activé, il sera configuré pour écrire des règles de pare-feu IPv4 et IPv6.

Avant d'activer UFW, on veut s'assurer que le pare-feu est configuré pour nous permettre de nous connecter via SSH.

3. Mise en place des politiques par défaut.

Ce sont des règles qui contrôlent la manière de traiter le trafic qui ne correspond pas explicitement à d'autres règles.

Par défaut, UFW est configuré pour refuser toutes les connexions entrantes et autoriser toutes les connexions sortantes. Cela signifie que toute personne essayant d'atteindre le serveur ne pourra pas se connecter, tandis que toute application à l'intérieur du serveur pourra atteindre le monde extérieur.

Pour définir les valeurs par défaut utilisées par UFW, on peut utiliser la commande suivante :

# Refuser les connexions entrantes.
$ sudo ufw default deny incoming

# Autoriser les connexions sortantes.
$ sudo ufw default allow outgoing

Ces paramètres par défaut du pare-feu peuvent suffire pour un ordinateur personnel, mais les serveurs doivent généralement répondre aux demandes entrantes d'utilisateurs extérieurs.

4. Autoriser les connexions SSH.

Si on active le pare-feu UFW maintenant, il refuserait toutes les connexions entrantes. Cela signifie qu'on devra créer des règles qui autorisent explicitement les connexions entrantes légitimes (connexions SSH ou HTTP, par exemple) si on veut que le serveur réponde à ce type de demandes. Si on utilise un serveur cloud, on voudra probablement autoriser les connexions SSH entrantes afin de pouvoir se connecter à notre serveur et le gérer.

Pour configurer le serveur afin d'autoriser les connexions SSH entrantes, on peut utiliser la commande suivante :

# Création des règles de pare-feu qui autoriseront toutes les connexions sur le port 22 (port que le démon SSH écoute par défaut).
$ sudo ufw allow ssh

UFW sait quel port allow ssh désigne parce qu'il est listé comme un service dans le fichier /etc/services.

On peut aussi écrire une règle équivalente en spécifiant le port au lieu du nom du service.

$ sudo ufw allow 22

Si on a configuré le démon SSH pour utiliser un port différent, on devra spécifier le port approprié. Par exemple, si SSH écoute le port 2222, on peut utiliser cette commande pour autoriser les connexions sur ce port :

$ sudo ufw allow 2222

5. Activation d'UFW.

# Activation du pare-feu.
$ sudo ufw enable

On recevra un avertissement qui indique que la commande peut perturber les connexions SSH existantes. On a déjà mis en place une règle de pare-feu qui autorise les connexions SSH, donc on peut continuer. Il suffit juste de répondre à l'invite avec y et d'appuyer sur ENTER.

Pour connaître les règles fixées, on peut exécuter la commande suivante :

$ sudo ufw status verbose

6. Autoriser d'autres connexions.

À ce stade, on doit autoriser toutes les autres connexions auxquelles le serveur a besoin de répondre. Les connexions qu'on doit autoriser dépendent de nos besoins spécifiques.

# Pour autoriser le protocole HTTP sur le port 80 :
$ sudo ufw allow http
# ou
$ sudo ufw allow 80

# Pour autoriser le protocole HTTPS sur le port 443 :
$ sudo ufw allow https
# ou
$ sudo ufw allow 443

Il existe plusieurs autres moyens d'autoriser d'autres connexions, outre la spécification d'un port ou d'un service connu :

• Plages de ports spécifiques.

• Adresses IP spécifiques.

• Sous réseaux.

• Connexion à une interface réseau spécifique.

6.1. Plages de ports spécifiques.

On peut spécifier des plages de ports avec UFW. Certaines applications utilisent plusieurs ports, au lieu d'un seul.

# Pour autoriser les connexions X11 qui utilisent les ports 6000-6007, on peut utiliser les commandes suivantes :
$ sudo ufw allow 6000:6007 /tcp
$ sudo ufw allow 6000:6007 /udp

Lorsqu'on spécifie des plages de ports avec UFW, on doit spécifier le protocole (tcp ou udp) auquel les règles doivent s'appliquer.

Le fait de ne pas spécifier le protocole autorise automatiquement les 2 protocoles, ce qui est correct dans la plupart des cas.

6.2. Adresses IP spécifiques.

Si on souhaite autoriser les connexions à partir d'une adresse IP spécifique (professionnelle ou personnelle, ex: 203.0.113.4), on doit spécifier from, puis l'adresse IP :

$ sudo ufw allow from 203.0.113.4

On peut spécifier un port spécifique auquel l'adresse IP est autorisée à se connecter en ajoutant to any port suivi du numéro de port.

Ex : Si on souhaite autoriser 203.0.113.4 à se connecter au port 22 (SSH), on peut utilier la commande suivante :

$ sudo ufw allow from 203.0.113.4 to any port 22

6.3. Sous réseaux.

Si on souhaite autoriser un sous-réseau d'adresses IP, on peut le faire en utilisant la notation CIDR (Classless Inter-Domain Routing) pour spécifier un masque de réseau.

Si on souhaite autoriser toutes les adresses IP entre 203.0.113.1 à 203.0.113.254, on peut utiliser la commande suivante :

$ sudo ufw allow from 203.0.113.0/24
# Les 24 premiers bits permettent d'identifier le réseau.
# Les 8 derniers bits permettent d'identifier les hôtes sur ce réseau.

On peut également spécifier le port de destination auquel le sous-réseau 203.0.113.0/24 est autorisé à se connecter. Exemple :

$ sudo ufw allow from 203.0.113.0/24 to any port 22

6.4. Connexions à une interface réseau spécifique.

Si on souhaite créer une règle de pare-feu qui s'applique uniquement à une interface réseau spécifique (ex: eth0, eth1, enp3s2, ...), on peut le faire en spécifiant allow in on suivi du nom de l'interface.

On peut consulter les interfaces réseau avant de continuer, avec ip addr.

Output Excerpt
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
. . .
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
. . .

Si notre serveur a une interface réseau publique appelée eth0, on peut l'autoriser à recevoir du trafic HTTP (port 80) avec la commande suivante :

# Cette commande va permettre au sserveur de recevoir
# des requêtes HTTP de l'internet public.
$ sudo ufw allow in on eth0 to any port 80

Si on veut que notre serveur de base de données MySQL (port 3306) écoute les connexions sur l'interface de réseau privé eth1, on peut utiliser la commande suivante :

$ sudo ufw allow in on eth1 to any port 3306

Cela permettrait à d'autres serveurs du réseau privé de se connecter à notre base de données MySQL.

7. Refuser les connexions.

UFW est configuré pour refuser toutes les connexions entrantes. Cela simplifie le processus de création d'une politique de pare-feu sécurisée en obligeant à créer des règles qui autorisent explicitement le passage de ports et d'adresses IP spécifiques.

Au cas où on souhaite refuser des connexions spécifiques en fonction de l'adresse IP source ou du sous-réseau, on peut modifier la politique d'entrée par défaut (allow) en créant des règles deny pour tous les services ou adresses IP pour lesquels on ne souhaite pas autoriser les connexions.

# Si on veut refuser des connexions HTTP.
$ sudo ufw deny http

# Si on veut refuser toutes les connexions à partir de 203.0.113.4.
$ sudo ufw deny from 203.0.113.4

8. Suppression de règles.

Il faut savoir supprimer des règles de pare-feu xD.

Il existe 2 façons différentes de spécifier les règles à supprimer :

• Par le numéro de la règle (delete by rule number).

• Par la règle elle-même (de la même façon que les règles ont été spécifiées lors de leur création).

8.1. Par numéro de règle.

La première chose à faire c'est d'obtenir une liste des règles de pare-feu.

$ sudo ufw status numbered

Si on veut supprimer la règle 2 (celle qui autorise les connexions sur le port 80 [HTTP]), on peut la spécifier dans une commande de suppression UFW :

$ sudo ufw delete 2

Ça va afficher une demande de confirmation puis supprimera la règle 2, qui autorise les connexions HTTP.

Note : Si on a activé IPv6, on voudra également supprimer la règle IPv6 correspondante.

8.2. Par règle réelle.

L'alternative aux numéros de règle est de spécifier la règle réelle à supprimer. Par exemple, si on veut supprimer la règle allow http, on peut l'écrire comme ceci :

$ sudo ufw delete allow http
# ou
$ sudo ufw delete allow 80

Cette méthode supprimera les règles IPv4 et IPv6, si elles existent.

9. Vérification de l'état et des règles d'UFW.

On peut à tout moment vérifier le statut d'UFW :

$ sudo ufw status verbose

Si UFW est désactivé :

Si UFW est actif, la sortie indiquera qu'il est actif et énumérera toutes les règles qui sont définies.

On peut utiliser la commande status si on souhaite vérifier comment UFW a configuré le pare-feu.

$ sudo ufw status

10. Désactivation ou réinitialisation d'UFW (facultatif).

Si on souhaite désactiver UFW :

$ sudo ufw disable

Pour la réactiver :

$ sudo ufw enable

Pour supprimer toutes les règles qui ont été définies précédemment, désactiver UFW et repartir à zéro avec UFW :

$ sudo ufw reset

Il faut garder à l'esprit que les règles par défaut ne retrouveront pas leurs paramètres d'origine, si on les a modifiées à un moment quelconque.

XI. Le pare-feu firewalld pour Rocky

On va voir comment configurer le pare-feu firewalld pour le serveur Rocky Linux 8 et aborder les principes fondamentaux de la gestion du pare-feu avec l'outil d'administration firewall-cmd.

1. Révision des concepts de base dans Firewalld.

1.1. Zones.

Le service Firewalld gère des groupes de règles utilisant des entités appelées zones.

Les zones sont des ensembles de règles qui dictent le trafic qui doit être autorisé en fonction du niveau de confiance que l'on a dans le réseau.

Les interfaces réseau sont affectées à une zone pour dicter le comportement que le pare-feu doit autoriser.

Pour les ordinateurs susceptibles de se déplacer fréquemment entre les réseaux (ex: ordinateurs portables), ce type de flexibilité constitue une bonne méthode pour modifier les règles en fonction de l'environnement.

On peut avoir mis en place des règles strictes interdisant la plupart du trafic lorsqu'on travaille sur un réseau WiFi public, tout en autorisant des restrictions plus souples lorsqu'on est connecté à notre réseau domestique.

Il est toujours utile de se familiariser avec l'idée générale derrière chacune des zones prédéfinies pour firewalld.

Les zones prédéfinies à l'intérieur du pare-feu firewalld sont par ordre décroissant de confiance :
N.C. = Niveau de confiance.

• drop (N.C. 0) :

  • Toutes les connexions entrantes sont abandonnées sans réponse.
  • Toutes les connexions sortantes sont possibles.

• block (N.C. 1) :

  • Toutes les connexions entrantes sont abandonnées avec un message icmp-host-prohibited ou icmp6-adm-prohibited.
  • Toutes les connexions sortantes sont possibles.

• public (N.C. 2) : Représente des réseaux publics non fiables. On ne fait pas confiance aux autres ordinateurs.

  • On peut autoriser certaines connexions entrantes au cas par cas.
  • Toutes les connexions sortantes sont possibles.

• external (N.C. 3) : Réseaux externes dans le cas où on utilise le pare-feu comme passerelle. Il est configuré pour le masquage NAT afin que le réseau interne reste privé mais accessible.

• internal (N.C. 4) : C'est l'autre côté de la zone externe, utilisé pour la partie interne d'une passerelle. Les ordinateurs sont assez fiables et certains services supplémentaires sont disponibles.

• dmz (N.C. 5) : Utilisé pour les ordinateurs situés dans une DMZ (ordinateurs isolés qui n'auront pas accès au reste de notre réseau).

• work (N.C. 6) : Utilisé pour les machines de travail. Il fait confiance à la plupart des ordinateurs du réseau. Quelques services supplémentaires pourraient être autorisés.

• home (N.C. 7) : Un environnement familial. Il fait confiance à la plupart des autres ordinateurs. Quelques services supplémentaires seront acceptés.

• trusted (N.C. 8) : Il fait confiance à toutes les machines du réseau. C'est la plus ouverte des options disponibles et doit être utilisée avec parcimonie.

Pour utiliser le pare-feu, on peut :

• Créer des règles.

• Modifier les propriétés des zones.

• Attribuer les interfaces réseau aux zones les plus appropriées.

1.2. Permanence des règles.

Dans firewalld, les règles peuvent être appliquées à l'ensemble des règles d'exécution actuel ou devenir permanent.

Par défaut, lorsqu'une règle est ajoutée ou modifiée, seul le pare-feu en cours d'exécution est modifié.

Après le prochain redémarrage - ou rechargement du service firewalld - seules les règles permanentes resteront.

La plupart des opérations firewall-cmd peuvent prendre un indicateur --permanent pour indiquer que les modifications doivent être appliquées à la configuration permanente.

Le pare-feu en cours d'exécution peut être enregistré dans la configuration permanente avec la commande firewall-cmd --runtime-to-permanent.

Cette séparation entre l'exécution et la configuration permanente signifie que l'on peut tester en toute sécurité les règles de pare-feu actif, puis recharger pour recommencer en cas de problèmes.

2. Installation et activation de Firewalld.

Il est installé par défaut sur certaines distributions Linux comme Rocky Linux.

Il peut s'avérer nécessaire d'installer le pare-feu par nous-même.

$ sudo dnf install firewalld -y

Après ça, on peut activer le service avec systemctl

$ sudo systemctl enable firewalld
$ sudo systemctl start firewalld

On peut vérifier que le service est exécuté et accessible avec :

$ sudo firewall-cmd --state
# ou bien :
$ sudo systemctl status firewalld

2.1. Exploration des valeurs par défaut.

On peut voir quelle zone est actuellement sélectionnée par défaut avec :

$ sudo firewall-cmd --get-default-zone

Puisqu'on n'a pas donné à firewalld aucune commande pour s'écarter de la zone par défaut et qu'aucune des interfaces n'est configurée pour se lier à une autre zone, cette zone sera également la seule zone active (la zone qui contrôle le trafic de nos interfaces). On peut vérifier avec :

$ sudo firewall-cmd --get-active-zones

Sur cet exemple, on peut voir que le serveur dispose de deux interfaces réseau contrôlées par le pare-feu (eth0 et eth1). Ils sont tous deux actuellement gérés selon les règles définies pour la zone public.

On peut imprimer les règles liées à la configuration de la zone par défaut avec :

$ sudo firewall-cmd --list-all

On peut voir à partir de la sortie que cette zone est à la fois la zone par défaut et active, et que les interfaces eth0 et eth1 sont associées à cette zone. Sur la ligne services:, on peut également voir que cette zone autorise le trafic pour un client DHCP (pour l'attribution d'adresses IP), SSH (pour l'administration à distance) et Cockpit (une console Web).

2.2. Exploration des zones alternatives.

Pour obtenir lq liste des zones disponibles, on peut faire :

$ firewall-cmd --get-zones

Pour voir la configuration spécifique associée à une zone :

$ sudo firewall-cmd --zone=home --list-all

On peut afficher toutes les définitions de zone en utilisant l'option --list-all-zones.

3. Sélection des zones pour les interfaces.

Chaque interface sera mise dans la zone par défaut au démarrage du pare-feu.

3.1. Changer la zone d'une interface.

On peut déplacer une interface entre des zones au cours d'une session en utilisant le paramètre --zone= en combinaison avec le paramètre --change-interface=.

Ex : On peut déplacer l'interface eth0 vers la zone home.

$ sudo firewall-cmd --zone=home --change-interface=eth0

Remarque : À chaque fois qu'on déplace une interface vers une nouvelle zone, on doit savoir qu'on modifie les services qui seront opérationnels. Dans ce cas, on doit déplacer vers la zone home pour laquelle SSH est disponible. Cela signifie que la connexion ne devrait pas être interrompue. Certaines autres zones n'ont pas SSH activé par défaut, et le passage à l'une de ces zones pourrait entraîner une interruption de la connexion, nous empêchant de nous reconnecter à notre serveur.

Pour vérifier que le déplacement ait réussi :

$ firewall-cmd --get-active-zones

3.2. Ajustement de la zone par défaut.

Si toutes les interfaces peuvent être bien gérées par une seule zone prédéfinie, on doit désigner cette zone par défaut avec le paramètre --set-default-zone=.

$ sudo firewall-cmd --set-default-zone=home

4. Définition des règles pour les applications.

Exceptions du pare-feu.

4.1. Ajouter un service aux zones.

La méthode la plus simple consiste à ajouter les services ou les ports dont on a besoin aux zone qu'on utilise.

On peut obtenir une liste des définitions de services disponibles en utilisant l'option --get-services :

$ firewall-cmd --get-services

Output
RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

Remarque : On peut trouver plus de détails sur chacun de ces services en consultant leur fichier .xml associé dans le répertoire /usr/lib/firewalld/services.

Ex : Le service SSH est défini comme ceci :

/usr/lib/firewalld/services/ssh.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

Pour activer un service pour une zone, on peut utiliser le paramètre --add-service=.

Par défaut, cela ajustera uniquement la session actuelle du pare-feu et ne persistera pas au-delà des redémarrages ou des redémarrages du service.

Heureusement, on peut ajuster la configuration permanente du pare-feu en incluant le flag --permanent

Ex : Si on utilise un serveur Web servant du trafic HTTP conventionnel, on peut temporairement autoriser ce trafic pour les interfaces de la zone public

$ sudo firewall-cmd --zone=public --add-service=http
# On peut omettre le flag --zone pour modifier la
# zone par défaut.

Ensuite, on peut vérifier que l'opération a réussi en utilisant les flags --list-all ou --list-services :

$ sudo firewall-cmd --zone=public --list-services

Désormais, le trafic Web HTTP sur le port 80 est autorisé par notre zone public. Si le serveur Web est configuré pour utiliser SSL/TLS (Secure Sockets Layer / Transport Layer Security), on doit également ajouter le service https. On peut l'ajouter à la session en cours et à l'ensemble de règles permanent :

$ sudo firewall-cmd --zone=public --add-service=https
$ sudo firewall-cmd --zone=public --add-service=https --permanent

Les services inclus avec l'installation de firewalld représentent la plupart des applications les plus courantes auxquelles on doit peut-être autoriser l'accès. Cependant, il y aura probablement des scénarios dans lesquels ces services ne répondront pas à nos besoins. Dans cette situation, on a 2 options :

• Ouvrir un port pour les zones.

• Définir un service.

4.2. Ouverture d'un port pour les zones.

Le moyen le plus simple d'ajouter la prise en charge de notre application spécifique consiste à ouvrir les ports qu'elle utilise dans la/les zone.s appropriée.s. Cela se fait en spécifiant le port ou la plage de ports, ainsi que le protocole associé (TCP ou UDP) pour les ports.

TCP (Transmission Control Protocol) : C'est une norme de communication qui permet aux programmes applicatifs et aux dispositifs informatiques d'échanger des messages sur un réseau.

UDP (User Datagram Protocol) : C'est un protocole de communication utilisé sur Internet pour les transmissions particulièrement sensibles au facteur temps, telles que la lecture de vidéos ou les recherches DNS.

Par exemple, si notre application s'exécute sur le port 5000 et utilise TCP, on peut l'ajouter temporairement à la zone public à l'aide du paramètre --add-port. Les protocoles peuvent être désignés comme suit :

$ sudo firewall-cmd --zone=public --add-port=5000/tcp

On peut vérifier que cela a réussi en utilisant le flag --list-ports

$ sudo firewall-cmd --zone=public --list-ports

Il est également possible de spécifier une plage séquentielle de ports en séparant le port de début et de fin de la plage par un tiret. Par exemple, si notre application utilise les ports UDP 4990 à 4999, on peut les ouvrir publiquement avec :

$ sudo firewall-cmd --zone=public --add-port=4990-4999/udp

Après les test, on peut les ajouter au pare-feu permanent de 2 façons :

• Utiliser sudo firewall-cmd --runtime-to-permanent

• Réexécuter les commandes avec le flag --permanent
  

# Utiliser `sudo firewall-cmd --runtime-to-permanent`
$ sudo firewall-cmd --runtime-to-permanent
# Réexécuter les commandes avec le flag `--permanent`
$ sudo firewall-cmd --zone=public --permanent --add-port=5000/tcp
$ sudo firewall-cmd --zone=public --permanent --add-port=4990-4999/udp
$ sudo firewall-cmd --zone=public --permanent --list-ports

4.3. Définir un service.

Ouvrir des ports pour nos zones est une solution simple, mais il peut être difficile de savoir à quoi sert chacune d'entre elles. Si jamais on met hors service un service sur notre serveur, on aura peut-être du mal à cataloguer les ports ouverts qui sont encore requis. Pour éviter cette situation, on peut définir un noveau service.

Les services sont des collections de ports avec un nom et une description associés. La gestion du pare-feu à l'aide de services est généralement plus facile à gérer que le mappage de ports, mais nécessite une configuration initiale.

On peut commencer par copier un script existant dans /usr/lib/firewalld/services vers le répertoire /etc/firewalld/services où le pare-feu recherche les définitions non standard.

Par exemple, on peut copier la définition du service SSH à utiliser pour notre exemple de définition de service comme ceci. Le nom du service dans la liste des services de pare-feu sera le nom de ce fichier, moins le suffixe .xml :

$ sudo cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/example.xml

Ensuite, on doit ouvrir le fichier puis le modifier, car actuellement, elle ne contient que la configuration du service SSH :

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

La majorité de cette définition est constituée de métadonnées.

• On doit modifier le nom court du service dans les balises <short>.

• On doit ajouter une description afin d'avoir plus d'informations si jamais on a besoin d'auditer le service.

• La seule configuration qu'on doit effectuer et qui affecte réellement la fonctionnalité du service sera probablement la définition du port dans laquelle on identifie le numéro de port et le protocole à ouvrir.

• Plusieurs balises peuvent être spécifiées.

Pour notre service example, imaginons qu'on devait ouvrir le port 7777 pour TCP et 8888 pour UDP. On peut modifier la définition existante avec quelque chose comme ceci :

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Service Exemple</short>
  <description>C'est juste un exemple de service.</description>
  <port protocol="tcp" port="7777"/>
  <port protocol="udp" port="8888"/>
</service>

Ensuite, après enregistrement, on peut recharger le pare-feu pour accéder à notre nouveau service :

$ sudo firewall-cmd --reload

On peut constater qu'il figure désormais parmi la liste des services disponibles :

$ firewall-cmd --get-services

Output
RH-Satellite-6 amanda-client amanda-k5-client amqp amqps apcupsd audit bacula bacula-client bb bgp bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc bittorrent-lsd ceph ceph-mon cfengine cockpit condor-collector ctdb dhcp dhcpv6 dhcpv6-client distcc dns dns-over-tls docker-registry docker-swarm dropbox-lansync elasticsearch etcd-client etcd-server example finger freeipa-4 freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master git grafana gre high-availability http https imap imaps ipp ipp-client ipsec irc ircs iscsi-target isns jenkins kadmin kdeconnect kerberos kibana klogin kpasswd kprop kshell ldap ldaps libvirt libvirt-tls lightning-network llmnr managesieve matrix mdns memcache minidlna mongodb mosh mountd mqtt mqtt-tls ms-wbt mssql murmur mysql nfs nfs3 nmea-0183 nrpe ntp nut openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole plex pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy prometheus proxy-dhcp ptp pulseaudio puppetmaster quassel radius rdp redis redis-sentinel rpc-bind rsh rsyncd rtsp salt-master samba samba-client samba-dc sane sip sips slp smtp smtp-submission smtps snmp snmptrap spideroak-lansync spotify-sync squid ssdp ssh steam-streaming svdrp svn syncthing syncthing-gui synergy syslog syslog-tls telnet tentacle tftp tftp-client tile38 tinc tor-socks transmission-client upnp-client vdsm vnc-server wbem-http wbem-https wsman wsmans xdmcp xmpp-bosh xmpp-client xmpp-local xmpp-server zabbix-agent zabbix-server

On peut désormais utiliser ce service dans les zones comme on le fera normalement.

5. Création des zones.

Bien que les zones prédéfinies devraient fonctionner pour la plupart des utilisateurs, il peut être utile de définir nos propres zones qui décrivent davantage leur fonction.

Par exemple, on doit peut-être créer une zone pour notre serveur Web, appelée publicweb.

Cependant, on devra peut-être configurer une autre zone pour le service DNS qu'on fournit sur notre réseau privé. On peut créer une autre zone appelée privateDNS pour cela.

Lors de l'ajout d'une zone, on doit l'ajouter à la configuration permanente du pare-feu. On peut ensuite recharger pour importer la configuration dans notre session en cours.

On peut créer ces 2 zones en utilisant firewall-cmd --new-zone :

$ sudo firewall-cmd --permanent --new-zone=publicweb
$ sudo firewall-cmd --permanent --new-zone=privateDNS

Vérification :

$ sudo firewall-cmd --permanent --get-zones

Output
block dmz drop external home internal privateDNS public publicweb trusted work

On doit recharger le pare-feu pour intégrer ces nouvelles zones dans la configuration d'exécution active :

$ sudo firewall-cmd --reload
$ firewall-cmd --get-zones

Output
block dmz drop external home internal privateDNS public publicweb trusted work

On peut maintenant commencer à attribuer les services et ports appropriés à nos zones. C'est une bonne idée d'ajuster le pare-feu d'exécution, puis d'enregistrer ces modifications dans la configuration permanente après les tests.

Par exemple, pour la zone publicweb, on peut ajouter les services SSH, HTTP, HTTPS :

$ sudo firewall-cmd --zone=publicweb --add-service=ssh 
$ sudo firewall-cmd --zone=publicweb --add-service=http
$ sudo firewall-cmd --zone=publicweb --add-service=https
$ sudo firewall-cmd --zone=publicweb --list-all

Ensuite, on peut ajouter le service DNS à notre zone privateDNS :

$ sudo firewall-cmd --zone=privateDNS --add-service=dns
$ sudo firewall-cmd --zone=privateDNS --list-all

Ensuite, on peut basculer nos interfaces sur ces nouvelles zones pour les tester :

$ sudo firewall-cmd --zone=publicweb --change-interface=eth0
$ sudo firewall-cmd --zone=privateDNS --change-interface=eth1

À ce stade, on a la possibilité de tester notre configuration. Si ces valeurs nous conviennent, on doit ajouter ces règles à la configuration permanente.

• --permanent : on doit réexécuter toutes les commandes précédentes avec ce flag, sinon :

• --runtime-to-permanent : permet d'enregistrer définitivement l'intégralité de notre configuration d'exécution :
  

$ sudo firewall-cmd --runtime-to-permanent

Ensuite, on doit recharger le pare-feu pour tester que les modifications persistent :

$ sudo firewall-cmd --reload

Vérification des zones:

$ firewall-cmd --get-active-zones

Vérification des services appropriés pour chaque zone :

$ sudo firewall-cmd --zone=publicweb --list-services

$ sudo firewall-cmd --zone=privateDNS --list-services

Pour faire d'une de ces zones la zone par défaut pour les autres interfaces, on peut configurer ce comportement avec le paramètre --set-default-zone=

$ sudo firewall-cmd --set-default-zone=publicweb

À RETENIR : Le service firewalld permet de configurer des règles et des ensembles de règles maintenables qui prennent en compte notre environnement réseau. Il nous permet d'effectuer une transition transparente entre différentes politiques de pare-feu grâce à l'utilisation de zones. Acquérir une connaissance pratique de ce système nous permettra de profiter de la flexibilité et de la puissance qu'offre cet outil.

XII. Comment modifier le hostname dans le terminal

Sous Linux, la commande hostnamectl sert à gérer le nom d'hôte de la machine : elle est très pratique si l'on souhaite donner un autre nom à son serveur ou son poste de travail à partir de la ligne de commande.

Ici, nous prendrons l'exemple d'une machine Debian 11 mais elle fonctionne de la même façon sur les systèmes Linux où il y a systemd.

1. La commande hostnamectl.

Le hostname d'une machine correspond à son nom d'hôte.

La commande hostnamectl sert à gérer le nom d'hôte.

Sous linux, le nom d'hôte est stocké dans le fichier /etc/hostname du système. De ce fait, la commande var permettre de changer le nom d'hôte sans avoir à ouvrir et éditer manuellement ce fichier.

Cette commande est simple à utiliser, mais elle est indispensable pour toutes les personnes qui souhaitent apprendre l'administration de Linux.

2. Comment afficher le nom d'hôte actuel ?

Pour visualiser le nom actuel, on peut :

• lire le contenu du fichier /etc/hostname.

$ cat /etc/hostname

• utiliser la commande hostname.

$ hostname

• utiliser la commande hostnamectl.

# Pour l'affichage de tous les informations :
$ hostnamectl

# Pour l'affichage du nom d'hôte uniquement :
$ hostnamectl hostname

On peut aussi obtenir le nom de la machine en regardant le prompt du Terminal. Ex : root@debian signifie que l'on est connecté avec root sur la machine debian. [Parfois, ce nom n'est pas convainquant car il peut n'afficher qu'une partie du nom et non pas le nom au complet].

La commande hostnamectl retourne d'autres informations comme :

• le type de châssis.

• l'ID de la machine.

• le système d'exploitation.

• la version du noyau Linux.

• l'architecture.

• Le fabriquant du matériel.

• Le model du matériel, ...

3. Comment utiliser la commande hostnamectl ?

Sous Linux, la commande hostnamectl est capable de gérer 2 noms d'hôtes différents :

• Le nom d'hôte statique : c'est le nom d'hôte principal, indiqué dans le fichier /etc/hostname.

• Le nom d'hôte pretty : c'est le nom d'usage, qui est secondaire et qui sera inclus à /etc/machine-info.

L'objectif est de changer le nom d'hôte vers un nouveau nom :

$ hostnamectl set-hostname new-name
# ou
$ hostnamectl set-hostname new-name --static

Suite à cette commande, le contenu du fichier /etc/hostname est différent : il retourne "new-name"!

Maintenant, on va déterminer un nom secondaire (pretty) pour cette machine, où l'on va pouvoir être plus précis. Par exemple, le nom "new-name test.mg" en utilisant l'option --pretty à la place de --static :

$ hostnamectl set-hostname "My new host name new-name test.mg" --pretty

Ensuite, si l'on regarde le nom d'hôte avec hostnamectl, on peut voir l'apparition d'une nouvelle ligne!

Quant au fichier /etc/machine-info, il existe et contient bien cette information.

Pour afficher uniquement le nom statique ou le nom pretty, on peut utiliser l'une des 2 commandes suivantes :

$ hostnamectl --static status
$ hostnamectl --pretty status

4. Modifier le nom d'hôte dans Debian à l'aide de /etc/hosts.

Après avoir changé le nom d'hôte manuellement à partir du fichier /etc/hostname, il serait préférable de modifier aussi le fichier /etc/hosts en remplaçant l'ancien nom d'hôte par le nouveau :

127.0.0.1        localhost
12.0.0.1         new-hostname
...

N.B. : Si on n'effectue pas cette étape, on rencontrera le message d'avertissement "sudo: unable to resolve host" à chaque fois qu'on exécute sudo.

XIII. Comment creer, modifier, supprimer un utilisateur.

1. Définition.

Un utilisateur se définit comme suit dans le fichier /etc/passwd :

• Login
• Mot de passe
• UID
• GID du groupe principal
• Commentaire
• Répertoire de connexion
• Interpréteur de commandes (/bin/bash, /bin/nologin, ...).

Il existe 3 types d'utilisateurs :

• root : Administrateur du système.
• utilisateur système : Utilisé par le système pour la gestion des droits d'accès des applications.
• utilisateur ordinaire (ou utilisateur commun) : Autre compte permettant de se connecter au système.

Fichiers modifiés, ajout de lignes :

• /etc/passwd
• /etc/shadow

2. Types d'utilisateurs.

2.1. Utilisateur racine.

L'utilisateur root est l'administrateur du système d'exploitation et dispose de toutes les autorisations nécessaires pour effectuer des opérations. En général, seul l'utilisateur root peut installer/désinstaller ou mettre à jour les programmes et bibliothèques de base du système. Il s'agit d'un seul compte utilisateur disposant de privilèges sur l'ensemble du système.

L'utilisateur root est donc l'utilisateur le plus puissant du système.

2.2. Utilisateur spécial.

Il s'agit des utilisateurs qui n'ont pas d'identifiant. Ils ne disposent pas de tous les privilèges de l'utilisateur root. En fonction du compte, ils assument différents rôles spécialisés.

Ceux-ci sont créés automatiquement lors de l'installation d'une application. bin, sync, lp, mail, operator, squid sont quelques exemples d'utilisateurs spéciaux.

2.3. Utilisateurs ordinaires.

Les utilisateurs communs ne disposent de tous les privilèges que dans leur répertoire de travail, généralement leur répertoire personnel. Ils n'ont pas les privilèges nécessaires pour gérer le système ou installer le logiciel. Ils ne peuvent pas effectuer ces tâches sans disposer de privilèges spéciaux via sudo.

3. Ajout d'un utilisateur.

Sur un système basé sur Debian, il existe plusieurs options pour ajouter des utilisateurs à partir de l'interface de gestion. La première commande est adduser, qui est un script Perl et utilise la commande useradd dans le backend dont on verra l'utilisation plus tard.

Il faut utiliser la commande sudo comme préfixe et nom d'utilisateur comme argument.

3.1. La commande useradd (low level).

# Syntaxe
[ROOT]$ useradd [-u UID] -g [GID] [-d répertoire] [-s shell] login

# Exemple :
[ROOT]$ useradd -u 1000 -g 513 -d /home/GroupeA/asjosvah  -s /bin/sh asjosvah

Options de la commande useradd :

⚠⚠⚠ À la création, le compte ne possède pas de mot de passe et est verrouillé/inactif. Il faut assigner un mot de passe pour déverrouiller/activer le compte. Pour ce faire, on doit utiliser la commande passwd pour attribuer un mot de passe après le création du compte.

$ sudo passwd asjosvah

Règles de nommage des comptes :

• Pas d'accents, de majuscules ni caractères spéciaux : : " # , = \ / ? '
• Différents du nom d'un groupe ou fichier système existant.
• Définir les options -u, -g et -s à la création.

Un utilisateur peut faire partie de plusieurs groupes en plus de son groupe principal.

Pour les groupes secondaires, il faut utiliser l'option -G

[ROOT]$ useradd -u 500 -g GroupA -G GroupP, GroupC -d /home/GroupA/asjosvah -s /bin/sh - asjosvah

On peut modifier les valeurs par défaut de création d'utilisateur, en modifiant le fichier /etc/default/useradd avec la commande suivante :

[ROOT]$ useradd -D [-b répertoire_base_dir] [-g groupe] [-s shell]

# Exemple :
[ROOT]$ useradd -D -b /home -g 500 -s /bin/bash

Voici les options de la commande useradd pour modifier les valeurs par défaut :

3.2. La commande adduser (préférable).

$ sudo adduser johndoe

D'autres détails peuvent être spécifiés à l'invite. À l'exception du nom d'utilisateur et du mot de passe, les autres détails sont facultatifs.

On peut vérifier que l'utilisateur a été créé en utilisant la commande id.

$ sudo adduser johndoe
Ajout de l'utilisateur `johndoe' ...
Ajout d'un nouveau groupe `johndoe' (1003) ...
Ajout d'un nouvel utilisateur `johndoe' (1003) avec le groupe `johndoe' ...
Création du répertoire personnel `/home/johndoe' ...
Copie des fichiers de `/etc/skel' ...
Nouveau mot de passe :
Retapez le nouveau mot de passe :
passwd : password updated successfully
Modification des informations de l'utilisateur pour johndoe
Saisissez la nouvelle valeur ou appuyez sur ENTRÉE pour la valeur par défaut
        Nom complet [] : John Doe
        Numéro de chambre [] :
        Téléphone professionnel [] :
        Téléphone à domicile [] :
        Autre [] :
Les informations sont-elles correctes ? [O/n] O
$
$ id johndoe
uid=1003(johndoe) gid=1003(johndoe) groups=1003(johndoe)
$

4. Modification de l'utilisateur.

Il est souvent nécessaire de modifier certaines propriétés des utilisateurs existants en fonction des besoins de l'organisation, des demandes des utilisateurs ou des migrations du système.

La plupart de ces propriétés sont faciles à modifier, mais il faut s'assurer de l'impact sur l'environnement de l'utilisateur et sur l'accès aux fichiers qu'il possède ou auxquels il accède.

On peut modifier les propriétés suivantes :

• Shell par défaut
• Répertoire personnel
• ID de l'utilisateur
• Groupe par défaut
• Ajout/suppression de groupe
• Commentaire GECOS (General Electric Comprehensive Operating System).
• Nom d'utilisateur

4.1. Modification du shell par défaut.

L'interpréteur de commandes par défaut est l'interpréteur de commandes créé lorsqu'un utilisateur lance une nouvelle session d'interpréteur de commandes, soit localement, soit via SSH.

La plupart des systèmes modernes disposent d'un Bash utilisateur par défaut, bien qu'il puisse varier en fonction de la distribution Linux ou de l'environnement de l'utilisateur.

# sudo usermod -s new_interpreter

# Exemple :
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/newhome:/bin/sh
$ sudo usermod -s /bin/bash asjosvah
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/newhome:/bin/bash

Comme on peut le voir, le shell a été modifié de /bin/sh à /bin/bash pour l'utilisateur asjosvah.

4.2. Modification du répertoire personnel.

# sudo usermod -d [new_path_dir] [login]

# Exemple :
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/newhome:/bin/bash
$ sudo usermod -d /data/asjosvah asjosvah
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/asjosvah:/bin/bash

Comme on peut le voir, le répertoire personnel a été modifié de /data/newhome à /data/asjosvah pour l'utilisateur asjosvah.

IMPORTANT : Avant de procéder au changement, on doit s'assurer que le nouveau répertoire dispose des droits de propriété et des autorisations nécessaires. Dans le cas contraire, l'utilisateur risque de rencontrer des problèmes lors de la connexion ou du travail dans le nouveau répertoire personnel.

4.3. Modification de l'ID de l'utilisateur.

# sudo usermod -u [new_UID] [login]

# Exemple :
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/asjosvah:/bin/bash
$ sudo usermod -u 1010 asjosvah
$ getent passwd asjosvah
asjosvah:x:1010:1005::/data/asjosvah:/bin/bash

Comme on peut le voir, l'UID a été modifié de 1005 à 1010 pour l'utilisateur asjosvah.

IMPORTANT : La modification de l'UID change la façon dont le système de fichiers Linux attribue la propriété et l'autorisation à un fichier ou à un répertoire. On doit s'assurer que le répertoire personnel de l'utilisateur et son contenu, ainsi que tous les autres fichiers du système appartenant à l'origine à l'utilisateur (avec l'ancien UID), sont modifiés pour être mappés avec l'UID. Si on ne le fait pas, on risque de rencontrer des problèmes lors de la session CLI et de l'accès aux fichiers par l'utilisateur.

4.4. Modification du groupe par défaut.

C'est généralement l'ID de groupe par défaut de l'utilisateur, qui est créé lors de la création de l'utilisateur, à moins qu'un autre GID ne soit spécifié.

On peut modifier le groupe par défaut d'un utilisateur :

# sudo usermod -g [new_GID] [login]

# Exemple :
$ getent passwd asjosvah
asjosvah:x:1010:1005::/data/asjosvah:/bin/bash
$ sudo usermod -g 1001 asjosvah
asjosvah:x:1010:1001::/data/asjosvah:/bin/bash

Comme on peut le voir, le GID a été modifié de 1005 à 1001 pour l'utilisateur asjosvah.

IMPORTANT : On doit s'assurer que le nouveau GID est défini dans le répertoire personnel de l'utilisateur, dans son contenu et dans tous les autres fichiers ou répertoires applicables afin de migrer correctement leurs droits de propriété.

4.5. Ajout de groupe.

Un utilisateur peut faire partie de groupes secondaires. Il est possible d'ajouter ou de supprimer des groupes supplémentaires auxquels un utilisateur appartient :

# sudo usermod -a -G [group_name_to_add_to_login] [login]
# ou
# sudo gpasswd -a [login] [group_name_to_add_to_login]


# Exemple :
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah)
$ sudo usermod -a -G docker asjosvah
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah),1001(docker)

Comme on peut le voir, la liste des groupes secondaires a été modifié de groups=1005(asjosvah) à groups=1005(asjosvah),1001(docker) pour l'utilisateur asjosvah.

4.6. Suppression de groupe d'un utilisateur.

Pour supprimer un utilisateur de l'un des groupes secondaires, on peut utiliser la commande gpasswd :

# sudo gpasswd -d [login] [group_to_remove_from_login]
# ou
# sudo deluser [login] [group_to_remove_from_login]


# Exemple :
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah),1001(docker)

$ sudo gpasswd -d asjosvah docker
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah)

Comme on peut le voir, la liste des groupes secondaires a été modifié de groups=1005(asjosvah),1001(docker) à groups=1005(asjosvah) pour l'utilisateur asjosvah.

4.7. Modification du commentaire GECOS.

# sudo usermod -c [COMMENT_OR_USER_INFO]

# Exemple :
$ getent passwd asjosvah
asjosvah:x:1005:1005::/data/asjosvah:/bin/bash

$ sudo usermod -c "As Josvah - System Admin"
$ getent passwd asjosvah
asjosvah:x:1005:1005:As Josvah - System Admin:/data/asjosvah:/bin/bash

Comme on peut le voir, le commentaire GECOS a été modifié de à As Josvah - System Admin pour l'utilisateur asjosvah.

4.8. Modification du nom d'utilisateur.

# sudo usermod -l [new_login_username] [old_login_username]

# Exemple :
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah)

$ sudo usermod -l as_josvah asjosvah
$ id as_josvah
uid=1005(as_josvah) gid=1005(asjosvah) groups=1005(asjosvah)

IMPORTANT : Il ne faut pas oublier de mettre à jour les références de l'utilisateur en fonction du nouveau nom lorsqu'il est utilisé. Même dans des commandes comme id, le nouveau nom d'utilisateur doit être spécifié.

5. Suppression d'un utilisateur.

5.1. La commande userdel (préférable).

# sudo userdel [login]

# Exemple :
$ id asjosvah
uid=1005(asjosvah) gid=1005(asjosvah) groups=1005(asjosvah)

$ sudo userdel asjosvah
$ id asjosvah
id : 'asjosvah' : no such user

Pour supprimer un utilisateur ainsi que son répertoire personnel et son répertoire de courrier, on ajoute le flag -r

$ sudo userdel -r [login]

5.2. La commande deluser.

$ sudo deluser [login]

Pour supprimer le répertoire personnel et le spool de courrier, on ajoute le flag --remove-home

$ sudo deluser --remove-home [login]

6. Le fichier /etc/passwd

7. Le fichier /etc/shadow

XIV. Comment gérer les groupes ?

Un utilisateur faisant obligatoirement partie d'un groupe, il est préférable de créer les groupes avant d'ajouter les utilisateurs. Par conséquent, un groupe peut ne pas avoir de membres.

Chaque groupe possède un GID unique. Un groupe peut être dupliqué. Par convention, les GID des groupes systèmes vont de 0 (root) à 499.

1. Création d'un groupe dans le système.

[ROOT]$ groupadd -f [-g GID] [nom_groupe]

Règles de nommage des groupes :

• Pas d'accents, ni caractères spéciaux.
• Différents du nom d'utilisateur ou fichier système existant.

2. Modification de l'information du groupe existant.

[ROOT]$ groupmod [-g new_GID] [-n nouveau_nom] ancien_nom 

3. Suppression d'un groupe dans le système.

[ROOT]$ groupdel [nom_groupe]

4. Ajout d'un groupe existant à un utilisateur.

$ sudo adduser [login] [groupe]

$ sudo useradd -u [UID] -g [groupe_principal] -G [groupes_secondaires] [login]

$ sudo gpasswd -a [login] [groupe] 

5. Suppression d'un utilisateur dans un groupe.

$ sudo deluser [login] [groupe]

$ sudo gpasswd -d [login] [groupe]

6. Le fichier /etc/group.

7. Le fichier /etc/gshadow.

XV. Comment limiter le nombre d'essai d'authentification en utilisant sudo

Pour limiter le nombre d'essais d'authentification sous Debian, on peut utiliser le module PAM (Pluggable Authentication Modules) pam_tally2 ou pam_faillock. Voici comment procéder en utilisant pam_faillock, qui est une méthode moderne et souvent recommandée pour gérer les tentatives de connexion infructueuses.

PAM (Pluggable Authentication Modules) : c'est un framework flexible pour gérer les mécanismes d'authentification sur les systèmes Unix et Linux. Il permet d'ajouter, de supprimer ou de configurer les méthodes d'authentification de manière modulaire et centralisée sans avoir à modifier les applications elles-mêmes.

1. Étapes pour configurer pam_faillock.

1) Installer libpam-modules (si ce n'est pas déjà fait) :

$ sudo apt-get update
$ sudo apt-get install libpam-modules

2) Configurer PAM pour utiliser pam_faillock :
- Modifier le fichier /etc/pam.d/common-auth :

auth    required      pam_faillock.so preauth silent deny=3 unlock_time=600 # unlock_time=0 pour ne jamais verrouiller l'utilisateur.
auth    [default=die] pam_faillock.so authfail deny=3 unlock_time=600 # unlock_time=0 pour ne jamais verrouiller l'utilisateur.

Ces lignes signifient :

deny=3 : Bloque l'utilisateur après 3 tentatives échouées.
unlock_time=600 : Déverrouille l'utilisateur après 600 secondes (10 minutes).

- Modifier le fichier `/etc/pam.d/common-account` :

account required pam_faillock.so

3) Sauvegarder et fermer les fichiers.

4) Tester la configuration.

On peut maintenant tester la configuration en tentant de nous connecter avec un mot de passe incorrect plusieurs fois. Après le nombre de tentatives échouées spécifiées, le compte devrait être vérrouillé temporairement.

2. Recommandations.

• Sauvegarde : Avant de modifier les fichiers PAM, il est recommandé de créer une sauvegarde des fichiers de configuration actuels.

$ sudo cp /etc/pam.d/common-auth /etc/pam.d/common-auth.bak
$ sudo cp /etc/pam.d/common-account /etc/pam.d/common-account.bak

• Précautions : On doit toujours être prudent lors de la modification des fichiers PAM, car une mauvaise configuration peut entraîner des problèmes d'accès au système. On doit s'assurer de suivre les étapes attentivement.

XVI. Comment afficher un message en cas d'erreur d'authentification

Pour afficher un message personnalisé en cas d'erreur d'authentification sur Debian en utilisant PAM, on peut utiliser le module pam_echo.

1. Créer un fichier contenant le message d'erreur.

Créer un fichier qui contient le message d'erreur qu'on souhaite afficher.

ex : /etc/security/failed_auth_message

L'authentification a échoué -_-#. Vérifiez votre login et mot de passe s'il vous plaît!

2. Configurer PAM pour afficher le message en cas d'erreur d'authentification.

• Modifier le fichier /etc/pam.d/common-auth, en ajoutant la ligne suivante :

...
auth    [default=die] pam_echo.so file=/etc/security/failed_auth_message
...

3. Créer un fichier contenant le message d'erreur final.

Exemple : /usr/local/bin/final_message.sh

#!/bin/bash
echo "Vous avez échoué 3 fois!!! Veuillez réessayer plus tard!"

$ sudo chmod +x /usr/local/bin/final_message.sh

4. Configurer PAM pour afficher le message en cas d'echac des n tentatives d'authentification.

Ajouter les lignes suivantes pour configurer pam_faillock et pam_exec :

...
auth    [default=die] pam_exec.so /usr/local/bin/final_message.sh
...

Donc, au final, notre fichier /etc/pam.d/common-auth doit ressembler à ça :

auth    required      pam_faillock.so preauth silent deny=5 unlock_time=0
auth    [default=die] pam_echo.so file=/etc/security/failed_auth_message
auth    [default=die] pam_faillock.so authfail deny=5 unlock_time=0
auth    [default=die] pam_exec.so /usr/local/bin/final_message.sh

XVII. Comment archiver chaque action utilisant sudo dans /var/log/sudo

On doit configurer sudo pour qu'il enregistre toutes les commandes dans un fichier de journal dédié.

1. Configurer le fichier sudoers pour la journalisation.

$ sudo visudo

Ajouter cette ligne dans le fichier ouvert par visudo :

Defaults        logfile="/var/log/sudo.log"

2. Configurer les permissions et créer le fichier de journal.

On doit s'assurer que le fichier de journal existe et qu'il a les permissions appropriées pour que sudo puisse y écrire :

$ sudo touch /var/log/sudo.log
$ sudo chmod 640 /var/log/sudo.log
$ sudo chown root:adm /var/log/sudo.log

3. Vérifier la configuration.

Une fois les modifications apportées, on peut tester la configuration en exécutant quelques commandes avec sudo et en vérifiant que les actions sont bien enregistrées dans /var/log/sudo.log

4. Exemples et bonnes pratiques.

• Sécurité : On doit s'assurer que le fichier de journal des commandes sudo est protégé contre les modifications non autorisées en définissant des permissions strictes. Seuls les utilisateurs autorisés (typiquement root et les membres du groupe adm) devraient avoir accès à ce fichier.

• Rotation des journaux : Pour éviter que le fichier de journal ne devienne trop volumineux, on doit configurer la rotation des journaux à l'aide de logrotate :

On doit d'abord créer un fichier de configuration pour logrotate :

$ sudo nano /etc/logrotate.d/sudo

Ensuite, on ajoute le contenu suivant pour la rotation des journaux :

/var/log/sudo.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 640 root adm
    postrotate
        /usr/sbin/service rsyslog reload > /dev/null
    endscript
}

Ce fichier de configuration fait tourner le journal des commandes sudo tous les jours, garde 7 jours de journaux, et compresse les anciens fichiers.

XVIII. C'est quoi mode TTY (security)

1. Un peu d'histoire sur les ttys sur Unix.

Sur Unix, tty provient du mot anglais Tele*TYpewritter que l'on peut traduire par **téléimprimeur, **télétype* ou téléscripteurs.

À la fin du XIXème siècle et pendant tout une partie du XXème siècle, les communications à longue distance ont été effectués par téléscripteur. C'est un appareil d'I/O qui comprend :

• Un clavier alphanumérique.
• Un émetteur de signaux électriques commandé par les barres du clavier.
• Un traducteur des signaux reçus.
• Un dispositif d'impression sur page ou sur bande.

Cela permet d'envoyer et de recevoir des messages dactylographiés à travers divers canaux de communication tels qu'une liaison filaire ou onde radio. Les messages télégraphiées ont utilisé les téléscripteurs.

On les voit aussi souvent dans les films de la seconde guerre mondiale, dans les centres de communication de l'armée avec de nombreuses secrétaires sur des bureaux.

Dans les années 70 sont apparus, des téléimprimeurs ressemblant à des machines à écrire qui avait pour sortie une imprimante.

À la fin des années 70, les téléimprimeurs ont été largement remplacés par des terminaux informatiques entièrement électroniques qui ont généralement un moniteur d'ordinateur au lieu d'une imprimante.

Ces terminaux à base de CRT (Cathode-Ray Tube) commençaient à émerger, tels que la série VT de Dell. À l'origine, l'interface ne pouvait imprimer que le texte sur l'écran, qui utilisait 80 colonnes et 24 lignes. L'interface graphique évolue plus tard et a permis de dessiner des images et d'utiliser un dispositif de pointage tel qu'une souris.

Ainsi, dans de nombreux langages de programmation, le texte de sortie de l'affichage dans une fenêtre de terminal est appelé impression. À l'origine, ce n'était pas une métaphore mais un fait.

De ce fait, le terme tty correspond au téléimprimeur qui correspond aux terminaux utilisés au moment de la création d'Unix qui est un périphérique I/O.

Linux étant un descendant libre d'Unix, il hérite des terminologies. À noter que MacOSX étant aussi issu d'Unix, il utilise aussi ces terminologies.

2. Qu'est-ce que tty sur Linux ?

L'OS Linux représente tout dans un système de fichiers.

Les périphériques matériels que nous connectons sont également représentés en tant que fichiers grâce à udev.

Le terminal est également représenté comme un fichier. Il nous permet d'interagir avec le système en passant des données au système et en affichant la sortie produite par le système.

Dans la terminologie UNIX, une TTY est un type particulier de fichier de périphérique qui implémente un certain nombre de commandes supplémentaires (Input-Output Controls ou IOCTL) au-delà de la lecture et de l'écriture. Dans sa signification la plus courante, terminal = TTY.

Certaines TTYs sont fournies par le noyau pour le compte d'un périphérique matériel, par exemple avec l'entrée provenant du clavier et la sortie vers un écran en mode texte, ou avec l'entrée et la sortie transmises sur une ligne de série.

D'autres TTYs, parfois appelées pseudo-TTY, sont fournis (à travers une fine couche de noyau) par des programmes appelés émulateurs de terminaux, tels que Xterm (exécuté dans le système X Window), screen (qui fournit une couche d'isolement entre un programme et un autre terminal), SSH (qui relie un terminal sur une machine à des programmes sur une autre machine), expect (pour les interactions de terminal de script, etc.

Ainsi, notre terminal est représenté par le fichier /dev/tty. Copier des fichiers vers ce dernier montre ce que l'on obtient en sortie de ce fichier.

3. Qu'est ce qu'un pts ?

PTS (Pseudo Terminal Slave) est un type de terminal virtuel utilisé dans les systèmes Unix et Linux pour permettre à plusieurs sessions de terminal d'exécuter simultanément sur un seul système.

Ils jouent un rôle crucial dans la gestion des interactions utilisateur avec le système d'exploitation et entre les différents processus et applications.

Voici quelques points clés à retenir sur les PTS :

• Terminal Virtuel : Un PTS est un terminal virtuel, ce qui signifie qu'il n'est pas directement lié à un périphérique matériel spécifique comme un clavier ou un écran, mais qu'il est géré par le système d'exploitation.

• Émulation de Terminal : Les PTS émulent le comportement des terminaux physiques en permettant aux utilisateurs d'interagir avec le système via une interface de ligne de commande. Chaque PTS est associé à un processus ou à une session utilisateur.

• Attribution Dynamique : Les PTS sont généralement attribués dynamiquement par le système d'exploitation lorsque de nouveaux terminaux sont ouverts. Par exemple, lorsqu'on ouvre une nouvelle fenêtre de terminal ou établit une connexion SSH, un nouveau PTS est généralement créé pour cette session.

• Identification : Les PTS sont généralement identifiés par des nombres, tels que pts/0, pts/1, etc. Ces numéros sont attribués de manière séquentielle à mesure que de nouveaux terminaux sont ouverts.

• Communication : Les PTS sont utilisés pour permettre la communication entre les processus et les sessions de terminal. Par exemple, lorsqu'on exécute une application dans un terminal et que cette application nécessite une interaction avec un autre processus ou une autre application, elle peut utiliser un PTS pour communiquer avec cette autre entité.

XIX. Comment recuperer la signature du VM dans le fichier .vdi au format sha1

Pour récupérer la signature SHA1 d'un fichier VDI (VirtualBox Disk Image), on peut utiliser l'outil de hachage SHA1 fourni par notre système d'exploitation. Voici comment procéder en utilisant la ligne de commande :

1) Ouvrir le terminal

2) Utiliser la commande suivante pour calculer la signature SHA1 du fichier VDI :

$ sha1sum chemin_vers_le_fichier.vdi

Il faut s'assurer de remplacer chemin_vers_le_fichier.vdi par le chemin absolu ou relatif vers le fichier VDI.

Cette commande générera la signature SHA1 du fichier VDI spécifié. On peut utiliser cette signature pour vérifier l'intégrité du fichier ou pour toute autre utilisation qui nécessite une vérification de l'identité du fichier.

XX. C'est quoi le format SHA1

SHA1 (Secure Hash Algorithm 1) est un algorithme de hachage cryptographique. Un algorithme de hachage prend en entrée des données de taille variable et génère en sortie une valeur de hachage (ou empreinte) de taille fixe.

L'objectif principal d'un algorithme de hachage est de produire une empreinte unique pour chaque ensemble de données d'entrée, de sorte que des données différentes produisent généralement des empreintes différentes, et qu'il est difficile de trouver deux ensembles de données différents qui produisent la même empreinte.

SHA1 produit une empreinte de 160 bits (20 octets), généralement représentée sous forme hexadécimale.

XXI. Comment dupliquer une VM

1. Arrêter la VM.

On doit s'assurer que la machine virtuelle qu'on souhaite dupliquer est arrêtée.

2. Copier le fichier VDI.

On doit localiser le fichier VDI de la machine virtuelle qu'on souhaite dupliquer. Ce fichier contient le disque dur virtuel de la machine.

On doit copier ce fichier quelque part sur notre disque dur physique.

3. Ouvrir VirtualBox.

Il faut lancer VirtualBox sur l'ordinateur.

4. Importer la VM.

Dans virtualBox : Fichier > Importer un appareil virtuel > fichier_a_dupliquer.vdi

5. Suivre l'assistant d'importation.

On doit suivre les instructions de l'assistant d'importation pour importer la machine virtuelle. On peut choisir de garder les paramètres par défaut ou de les personnaliser selon nos besoins. On doit s'assurer de sélectionner Créer une nouvelle identité de disque dur si on souhaite que la machine virtuelle dupliquée utilise un nouveau disque dur virtuel.

6. Configurer la VM dupliquée (facultatif).

Une fois la VM importée, on peut modifier ses paramètres dans VirtualBox si nécessaire, comme son nom, sa quantité de mémoire, ses périphériques connectés, etc.

7. Démarrer la VM dupliquée.

Une fois qu'on a configuré la VM dupliquée comme on le souhaite, on peut la démarrer.

XXII. Comment utiliser les "save state"

L'option Save State dans VirtualBox permet de sauvegarder l'état actuel d'une machine virtuelle, y compris la mémoire de la machine virtuelle, l'état des périphériques et l'état du système d'exploitation. Cela nous permet de mettre en pause une machine virtuelle et de la reprendre ultérieurement exactement là où on l'a laissé, sans perdre aucune donnée ou état de fonctionnement.

1) Arrêter la machine virtuelle : On doit s'assurer que la machine virtuelle que l'on souhaite mettre en pause est arrêtée.

2) Sélectionner la machine virtuelle : Dans la fenêtre principale de VirtualBox, on sélectionne la machine virtuelle que l'on souhaite sauvegarder l'état.

3) Choisir l'option Save State : Dans la barre d'outils de VirtualBox, on clique sur le bouton Machine pour ouvrir le menu déroulant, puis sélectionner Sauvegarder l'état ou Save State. Alternativement, on peut faire un clic droit sur la machine virtuelle sélectionnée dans la liste des machines et choisir Sauvegarder l'état.

4) Attendre la sauvegarde de l'état : VirtualBox sauvegarde l'état de la machine virtuelle. Selon la taille de la mémoire de la machine virtuelle et la vitesse du système, cela peut prendre quelques instants.

5) Reprendre la machine virtuelle : Lorsqu'on souhaite reprendre le travail, on ouvre VirtualBox, puis on sélectionne la machine virtuelle qu'on a sauvegardée. On peut maintenant démarrer la machine virtuelle en appuyant sur le bouton Démarrer dans la barre d'outils de VirtualBox. La machine virtuelle reprendra exactement là où on l'a laissée avec tous les programmes ouverts et les documents en cours d'exécution.