SysAdmin
Tags: systems, devops
Published: 2024-05-09 13:58:55

![Progression](https://geps.dev/progress/100)

## I. <u>Les serveurs graphiques</u>

### 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 **_<u>n’est pas indispensable</u>_** 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](https://vive-gnulinux.fr.cr/terminal-debutants/)

En fait, **<u>par défaut, il y a 6 terminaux</u>** 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] (ou [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 **<u>_inutile_</u>** et ce sont des UC **<u>_sans écran_</u>** 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.

4. **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.

5. **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.

6. **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 **_<u>X.Org Server</u>_** et **_<u>Wayland</u>_**. 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. <u>X.org</u>

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 **<u>fondation X.Org</u>**, 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.


![Schéma des couches de l'interface graphique](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vmdgd9sgt0okfne2cikl.png)

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 <u>X Window System<u>**.

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 :

- **<u>le serveur X</u>** est **lancé sur une machine possédant un écran, un clavier et une souris (ou d'autres périphériques)**

- **<u>le client X</u>** 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

- **<u>le protocole X</u>** 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. <u>KDump</u> (_Kernel dump_ ou _Kernel core dump_)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ndrx8o10416sslnh7lzr.png)

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 **<u>créant un noyau de secours minimal</u>** qui est chargé en mémoire lorsque le système principal rencontre une panne. Ce noyau de secours est **<u>lancé dans un environnement isolé</u>**, 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. <u>SELinux</u> (_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é _<u>au niveau du noyau</u>_**. Contrairement à la sécurité traditionnelle basée sur les permissions des utilisateurs et des groupes, SELinux utilise des **_<u>politiques de sécurité basées sur le contrôle d'accès obligatoire (MAC)</u>_**, ce qui signifie que les décisions de sécurité sont prises en fonction de **<u>règles</u>** 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 _<u>empêcher un processus spécifique d'accéder à ce fichier en fonction de ses politiques de sécurité</u>_.

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 **<u>examine aussi ce que tu veux faire et où tu veux aller</u>** 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 <u>_**le type de fichier, le programme que tu utilises pour l'ouvrir**_</u>, 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 **<u>en ajoutant une couche supplémentaire de contrôle très détaillé sur ce que les programmes peuvent faire</u>**, 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 **<u>_définir une politique de contrôle d'accès obligatoire aux éléments d'un système issu de Linux_</u>**.

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 <u>groupes</u>**, avec des niveaux d'accès plus fins. Il permet aussi d'**attribuer un niveau de confidentialité pour l'accès à des <u>objets</u> systèmes**, comme des descripteurs de fichiers, selon un **modèle de sécurité <u>multiniveau</u> (MLS pour Multi level Security)**. SELinux utilise le **<u>_modèle Bell LaPadula_</u>** complété par le mécanisme **<u>_Type enforcement_</u>** 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 :

```sh
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

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

```

#### CentOS

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

```

### Modes

- **<u>Enforcing (Appliquer)</u>** : C'est le **mode par défaut** dans lequel SELinux applique strictement les politiques de sécurité définies. Dans ce mode, SELinux **<u>_bloque les actions qui ne sont pas autorisées par les politiques_</u>**, ce qui renforce la sécurité du système.
- **Permissive (Accorder une avertissement)** : Dans ce mode, SELinux **<u>_ne bloque pas les actions qui violent les politiques de sécurité, mais il enregistre ces violations dans les journaux système_</u>**. 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 **<u>_complètement désactivé et ne s'applique pas du tout_</u>**. Toutes les politiques de sécurité SELinux sont ignorées, ce qui signifie que **<u>_le contrôle d'accès obligatoire (MAC) n'est pas utilisé_</u>**. 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. <u>AppArmor</u>


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/za7z1slqaf2g8h3hb30b.png)

### 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 <u>transgressions</u> au profil sont **_<u>enregistrées, mais pas empêchées</u>_**. Ce fichier de suivi peut alors être incorporé au profil, se fondant alors sur le comportement typique du programme.

AppArmor est **<u>_mis en place au sein du noyau Linux au moyen de l'interface de sécurité du noyau, LSM (Linux Security Modules)_</u>**.

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 <u>chemins</u>**. 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 <u>Debian</u>, 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tmiiy78qecvyfc6hub0y.png)

- SELinux utilise un **_contrôle d'accès obligatoire (MAC)_** basé sur des **_<u>règles</u>_**
- 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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/893r1cngu9gwdidsvg4v.png)

- AppArmor utilise un modèle de **_contrôle d'accès facultatif (DAC)_** basé sur des **_<u>profils</u>_**.
- 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. <u>Partition disque</u>

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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vffre8mjn95qqb1joiy7.png)

À 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’<u>utilisateur root</u>_**. 

#### 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. <u>LVM</u> (_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 »_** _<u>faciles à gérer</u>_ (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 <u>loopback</u>), <u>sur lesquels LVM crée ses volumes logiques</u>. Il comprend un **<u>en-tête spécial </u>**et **<u>se divise en blocs physiques</u>** (extents).
- **Les groupes de volumes (VG)** : Ce sont des **groupes de volumes physiques (PV) réunis par LVM en un seul _<u>« disque virtuel »</u>_**. Un groupe de volumes _<u>contient des volumes logiques</u>_, 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 <u>volume logique</u>**. Les étendues physiques se comportent **_<u>comme les secteurs ou les cylindres des disques durs physiques</u>_**.
- **É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** : 

```sh
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_**

```sh
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 :

```sh
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)

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

**On peut également utiliser <u>+500M</u> pour <u>500 Mégaoctets</u> et ainsi de suite.**

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

## VIII. <u>aptitude et apt</u>

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 <u>stable</u>** 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 **<u>testing</u>** ou **<u>unsable</u>**.
    - 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 **<u>assez lourd</u>**.

- **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 _<u>expressions rationnelles standard</u>_ sur les _<u>noms</u>_ et les _<u>descriptions des paquets</u>_**.

#### c. apt (fortement recommandée)

Cette commande est une **_<u>interface de haut niveau</u>_ 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 **<u>barre de progression</u>** plaisante lors de l'installation de paquets avec `apt install`.

- Elle **supprimera par défaut les paquets _<u>.deb</u>_ mis en cache** après une utilisation réussie de paquets téléchargés.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x4eujzx87647rhh7tbnz.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7cntikf1f9sgljtygnrr.png)

> 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1o1j94rt52dcrxjcdwkn.png)

**Les options importantes de la commande _<u>aptitude</u>_**

| Option de la commande | Description                                                                              |
|---|---|
| -s | Simuler le résultat de la commande. |
| -d | Télécharger seulement les paquets sans les installer ni les mettre à jour. |
| -D | Afficher une courte explication avant les installations ou les suppressions automatiques. |

> 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

```sh
$ 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**


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cjfk84fco0ks57f96ty7.png)

### 4. Raccourcis clavier d’aptitude


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7xs87urkm1ttnp9o54zk.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mj5440ahnyeedxqhehz7.png)

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

#### a. <u>Ligne de commande du shell.</u>

- `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. <u>Mode interactif plein écran.</u>

- **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).

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0ovqxxjup7qj2xswb5x3.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x8w2eukdv8y441hdpu5b.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0okz61j8m810oz8f5t9p.png)

### 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 <u>installés automatiquement</u> seront **<u>supprimés automatiquement</u>** 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

| Fichier | Contenu |
|---|---|
| **/var/log/dpkg.log** | Enregistrement des actions au niveau de **dpkg** pour l'activité de tous les paquets.|
| **/var/log/apt/term.log** | Journal de l'activité générique d'APT. |
| **/var/log/aptitude** | Journal des actions de la commande **aptitude**. |

## IX. <u>SSH</u> (Secure SHell)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jhmx8ytzvt96wtdn0tw4.png)

- 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 **<u>protocole</u> Secure SHell** est un _<u>standard de sécurité</u>_ 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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z3o42a9q14f85t9y0n7i.png)

### 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 **_<u>PuTTY</u>_**

La commande SSH se compose de 3 parties distinctes :

```sh
$ 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_** **<u>à distance</u>**.

- **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é _<u>depuis n'importe où dans le monde</u>_**, assurant ainsi la **confidentialité** et la **sécurité** des communications.

- **Contournement des restrictions d'un pare-feu** : En utilisant le <u>tunneling SSH</u>, 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é.**

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/edtwxnmsdj9gjow12jah.png)

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 <u>calculer de manière indépendante la clé secrète</u>._** _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, **<u>tous les paquets</u> qui se déplacent entre les deux machines <u>doivent être cryptés par la clé privée</u>**. 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 _<u>cybers clients</u>_ 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é**.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/235f8h6vowlkevioqcv0.png)

> 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 _<u>décrypter des messages signés publiquement</u>_ 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'<u>échange de clés de cryptage symétrique</u>_**.

> Avant de lancer une connexion sécurisée, les 2 parties génèrent des paires de clés public-privé **<u>temporaires</u>** 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 _<u>authentification</u>_**. _<u>Si le client peut décrypter avec succès le message</u>_, cela signifie qu'_<u>il dispose de la clé privée requise pour la connexion</u>_. **<u>La session SSH commence alors</u>**.

#### 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 _<u>valeur unique d’une longueur fixe</u>_ pour chaque entrée**, dont aucune tendance claire ne peut être exploitée. Cela rend pratiquement impossible l’inversion.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gbkyvo5jid0jjq4ot68k.png)

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 **<u>port TCP 22</u>** (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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gbbsbgpnzy7ixmmra1au.png)

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 **<u>clé publique asymétrique</u>** 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 :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rvjvuybz4wena4xgde3u.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/qrn6dl9zcu45a07ugmse.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/55ropg0ezitma39ij93f.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ans980mjer9q6bxam2ev.png)

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_**.

- 2. 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 **_<u>générateurs de cryptage</u>_**, effectuent de grandes opérations sur les valeurs de base. **Exemple : AES (Advanced Encryption Standard).**

- 3. Les 2 parties génèrent indépendamment un autre nombre premier **_(a et b)_**. Celui-ci est utilisé comme **_<u>clé privée secrète</u>_** pour l'intéraction.

- 4. 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.

- 5. 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.

- 6. 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 **_<u>chiffrer et décrypter</u>_** 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 **<u>SSH Key Pairs</u>**.

> 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c02fjmfgug2tg5jttnlk.png)

## X. <u>Le pare-feu UFW</u> (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.

```sh
$ 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.

```sh
$ 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 :

```sh
# 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 :

```sh
# 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.

```sh
$ 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 :

```sh
$ sudo ufw allow 2222
```

### 5. Activation d'UFW.

```sh
# 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 :

```sh
$ 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.

```sh
# 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.

```sh
# 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 (_<u>tcp</u>_ ou _<u>udp</u>_)** 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 :

```sh
$ 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 :

```sh
$ 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 :

```sh
$ 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 :

```sh
$ 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`.

```sh
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 :

```sh
# 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 :

```sh
$ 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 **_<u>tous les services ou adresses IP pour lesquels on ne souhaite pas autoriser les connexions</u>_**.

```sh
# 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.

```sh
$ sudo ufw status numbered
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vz96ittge99zewmmy6ih.png)

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 :

```sh
$ 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 :

```sh
$ 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 :

```sh
$ sudo ufw status verbose
```

Si UFW est désactivé :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pjkd1m3bqdktmdydu14e.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uh8g2yzsx4y4ru4tizzj.png)

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

```sh
$ sudo ufw status
```

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

Si on souhaite désactiver UFW :

```sh
$ sudo ufw disable
```

Pour la réactiver :

```sh
$ 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 :

```sh
$ 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. <u>Le pare-feu firewalld pour Rocky</u>

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 **_<u>ensembles de règles</u>_** qui dictent le trafic qui doit être autorisé en fonction du **_<u>niveau de confiance</u>_** 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 **<u>autorisant des restrictions plus souples lorsqu'on est connecté à notre réseau domestique</u>**.

Il est toujours utile de se familiariser avec l'idée générale derrière chacune des **<u>zones prédéfinies</u>** 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 **<u>masquage NAT</u>** 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 **<u>fiables</u>** 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 _<u>pare-feu en cours d'exécution</u>_ 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 **_<u>appliquées à la configuration permanente</u>_**.

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 **<u>recharger pour recommencer en cas de problèmes</u>**.

### 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.

```sh
$ sudo dnf install firewalld -y
```

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

```sh
$ sudo systemctl enable firewalld
$ sudo systemctl start firewalld
```

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

```sh
$ 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 :

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/otiis7kvef7v0gku7gov.png)

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 :

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ob3qeb5hbpdjt7cdc6bk.png)

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 :

```sh
$ sudo firewall-cmd --list-all
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kdwlyuq5fnn2f42d046d.png)

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 :

```sh
$ firewall-cmd --get-zones
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n6mkr3q04nim1cfzpso6.png)

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

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/13qdp1x9zqx7yp8cft2y.png)

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 **<u>zone par défaut</u>** 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**.

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2qlmjbnicahks5eh43zm.png)

> **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 <u>home</u> 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 :

```sh
$ firewall-cmd --get-active-zones
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bv5tgxx0edwy2c0ypma3.png)

#### 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 _<u>par défaut</u>_** avec le paramètre `--set-default-zone=`.

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/diofif78jutozmke0byr.png)

### 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` :

```sh
$ 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
<?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**

```sh
$ 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` :

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/z6xtd2toop1yni5js6v4.png)

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 :

```sh
$ 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 _<u>les ports qu'elle utilise</u>_ 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 :

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t9n55f9jyuyot9qf62b1.png)

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

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9kijmk2e8upxcfbw6n2h.png)

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 :

```sh
$ 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`

```sh
# 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
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/un3ydmuufnkodlgvuibw.png)

#### 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, **_<u>on peut définir un noveau service</u>_**.

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 **_<u>nécessite une configuration initiale</u>_**.

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` :

```sh
$ 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
<?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 **_<u>métadonnées</u>_**. 

- 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 <port/> 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
<?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 :

```sh
$ sudo firewall-cmd --reload
```

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

```sh
$ 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 **_<u>recharger</u> pour importer la configuration dans notre session en cours_**.

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

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

Vérification :

```sh
$ 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 :

```sh
$ 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 _<u>services</u>_ et _<u>ports</u>_** 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 :

```sh
$ 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
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/095lqnpo8389jutadvs4.png)

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

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1ajorh2u98jkpxa1ujjh.png)

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

```sh
$ 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 :

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

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

```sh
$ sudo firewall-cmd --reload
```

Vérification des zones:

```sh
$ firewall-cmd --get-active-zones
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/95b2khrpgorlsf8tlszu.png)

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

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/81vvx2boa3okojxyxk9j.png)


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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5jlz34tyiukkvnp2wxeo.png)

> 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=`

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

> **<u>À RETENIR</u> :** Le service firewalld permet de **_configurer des règles et des ensembles de règles maintenables_** qui prennent en compte notre **<u>environnement réseau</u>**. Il nous permet d'**_effectuer une transition transparente entre différentes politiques de pare-feu_** grâce à l'utilisation de **_<u>zones</u>_**. 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. <u>Comment modifier le hostname dans le terminal</u>

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`.

```sh
$ cat /etc/hostname
```

- utiliser la commande `hostname`.

```sh
$ hostname
```

- utiliser la commande `hostnamectl`.

```sh
# 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 :

```sh
$ 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` :

```sh
$ 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 :

```sh
$ 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. <u>Comment creer, modifier, supprimer un utilisateur</u>.

### 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 _<u>toutes</u>_ 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 **<u>_créés automatiquement</u> 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 <u>gérer le système</u> ou <u>installer le logiciel</u>_**. 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).

```sh
# 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 :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/07vfiu7waew7ncdshsio.png)

> ⚠⚠⚠ **_À la création, le compte <u>ne possède pas de mot de passe</u> et est <u>verrouillé/inactif</u>_**. 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.

```sh
$ 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w2bx5buhrcog2jgg5q67.png)

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

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

```sh
[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 :

```sh
[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 :

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gd9ddqdmonaflqw0dsfl.png)

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

```sh
$ 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`.

```sh
$ 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 <u>propriétés</u>_** 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_**.

```sh
# 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.

```sh
# 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.

```sh
# 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 :

```sh
# 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 :

```sh
# 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` :

```sh
# 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.

```sh
# 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.

```sh
# 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).

```sh
# 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`

```sh
$ sudo userdel -r [login]
```

#### 5.2. La commande `deluser`.

```sh
$ sudo deluser [login]
```

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

```sh
$ sudo deluser --remove-home [login]
```

### 6. Le fichier `/etc/passwd`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ou8erb20uwcxz7qkg2n6.png)

### 7. Le fichier `/etc/shadow`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fvkqpux0lt3qi2z1wqae.png)

## XIV. <u>Comment gérer les groupes ?</u>

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.

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g37fsdfdc9g2n1g7hgin.png)

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.

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

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

```sh
[ROOT]$ groupdel [nom_groupe]
```

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

```sh
$ 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.

```sh
$ sudo deluser [login] [groupe]

$ sudo gpasswd -d [login] [groupe]
```

### 6. Le fichier `/etc/group`.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bnjfzhincjk24it3cgti.png)

### 7. Le fichier `/etc/gshadow`.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/v5aj4ff1cn4ymkv02e9q.png)

## XV. <u>Comment limiter le nombre d'essai d'authentification en utilisant sudo</u>

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 **_<u>d'ajouter, de supprimer ou de configurer les méthodes d'authentification</u>_** 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) :

```sh
$ 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` :

```txt
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` :

```txt
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.

```sh
$ 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. <u>Comment afficher un message en cas d'erreur d'authentification</u>

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`

```txt
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 :

```txt
...
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

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

```sh
$ 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` :

```txt
...
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 :

```txt
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. <u>Comment archiver chaque action utilisant sudo dans /var/log/sudo</u>

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.

```sh
$ sudo visudo
```

Ajouter cette ligne dans le fichier ouvert par `visudo` :

```txt
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 :

```sh
$ 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` :

```sh
$ sudo nano /etc/logrotate.d/sudo
```

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

```sh
/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 **_<u>tous les jours</u>_**, garde 7 jours de journaux, et **_<u>compresse les anciens fichiers</u>_**.

## XVIII. <u>C'est quoi mode TTY (security)</u>

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

Sur Unix, **tty** provient du mot anglais **T**ele**TY**pewritter 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wxvd8khsrkx9iyvx6axh.png)

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nrbri7n9y4pmr69qs1wx.png)

À 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nv8ejcj2dtg4lkezubf.png)

> 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 <u>terminal</u> 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 <u>clavier</u>_** et la **_sortie vers un <u>écran</u> en mode texte_**, ou avec l'**_entrée et la sortie transmises sur une <u>ligne de série</u>_**.

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 <u>nouvelle fenêtre de terminal</u> ou établit une <u>connexion SSH</u>, 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. <u>Comment recuperer la signature du VM dans le fichier .vdi au format sha1</u>

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 :

```sh
$ sha1sum chemin_vers_le_fichier.vdi
```

Il faut s'assurer de remplacer `chemin_vers_le_fichier.vdi` par le **_<u>chemin absolu ou relatif</u>_** 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. <u>C'est quoi le format SHA1</u>
**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 **_<u>produire une empreinte unique</u>_** 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. <u>Comment dupliquer une VM</u>

### 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. <u>Comment utiliser les "save state"</u>

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.