add gscan2pdf : 2026-03-13 12:45:33

vault backup: 2026-03-13 09:01:21
vault backup: 2026-03-12 21:19:17
2026-03-13 12:45:33 +01:00 · 2026-03-13 09:01:21 +01:00 · 2026-03-12 21:19:17 +01:00 · 2026-03-12 20:49:17 +01:00 · 2026-03-11 18:41:56 +01:00 · 2026-03-11 18:28:18 +01:00
18 changed files with 1953 additions and 1 deletions
--- a/.obsidian/graph.json
+++ b/.obsidian/graph.json
@@ -46,6 +46,6 @@
  "repelStrength": 10,
  "linkStrength": 1,
  "linkDistance": 250,
-  "scale": 1,
+  "scale": 0.9999999999999991,
  "close": true
 }
--- a/articles/2026/Comprendre
+++ b/articles/2026/Comprendre
@@ -0,0 +1,108 @@
+---
+title: Comprendre RemoveIPC
+description: "Comprendre le paramètre RemoveIPC dans logind.conf : pourquoi il provoque le crash de vos bases de données PostgreSQL ou Oracle et comment le configurer en production (DevOps)."
+tags: []
+date: 2026-03-10 08:09
+lastmod: 2026-03-10 08:14
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: terminé
+---
+**Par Cédrix** | _Date d'édition : 10 mars 2026_
+
+Dans l'écosystème Linux moderne, **systemd-logind** gère bien plus que de simples ouvertures de sessions. L'un de ses paramètres les plus discrets, mais potentiellement destructeurs, est `RemoveIPC`. Pour un ingénieur DevOps, comprendre ce réglage est crucial pour garantir la stabilité des bases de données et des applications haute performance.
+
+## 1. Qu'est-ce que l'IPC (Inter-Process Communication) ?
+
+Avant de parler de suppression, rappelons ce que nous protégeons. L'IPC est un ensemble de mécanismes permettant à des processus distincts de partager des données. Les deux formes les plus courantes gérées par `RemoveIPC` sont :
+
+- **System V IPC :** Inclut les segments de mémoire partagée (`shm`), les files d'attente de messages (`msg`) et les sémaphores (`sem`).
+    
+- **POSIX Shared Memory :** Une version plus moderne et normalisée du partage de mémoire.
+    
+
+Ces ressources ne sont pas des fichiers sur le disque, mais des segments résidant directement en **RAM**.
+
+## 2. Le rôle de `RemoveIPC`
+
+Le paramètre `RemoveIPC` se trouve dans le fichier `/etc/systemd/logind.conf`. Son rôle est binaire :
+
+### Scénario A : `RemoveIPC=yes` (Défaut sur la majorité des distros)
+
+Lorsqu'un utilisateur se déconnecte et qu'il n'a **plus aucune session active**, systemd parcourt la table des segments IPC. S'il trouve des segments appartenant à cet utilisateur, il les supprime immédiatement pour libérer la mémoire.
+
+**L'intention :** Éviter les fuites de mémoire (memory leaks) causées par des applications mal codées qui oublient de nettoyer leurs ressources après fermeture.
+
+### Scénario B : `RemoveIPC=no`
+
+Systemd ignore les segments IPC lors de la fermeture de session. La mémoire reste occupée jusqu'à ce qu'un processus les libère manuellement ou que le serveur redémarre.
+
+---
+
+## 3. Le "Piège" pour les Bases de Données
+
+C'est ici que le bât blesse pour les DevOps. Imaginons l'architecture suivante :
+
+1. Vous avez un serveur **PostgreSQL** qui tourne sous l'utilisateur système `postgres`.
+    
+2. Le service démarre au boot et alloue un large segment de **Shared Memory** pour ses opérations.
+    
+3. Un administrateur se connecte en SSH, fait un `sudo su - postgres` pour vérifier une configuration, puis quitte sa session.
+    
+4. **Le drame :** Au moment où l'admin se déconnecte, `systemd-logind` voit que l'utilisateur `postgres` n'a plus de session active. Il déclenche `RemoveIPC` et supprime la mémoire partagée... alors que le service de base de données est toujours en train de l'utiliser !
+    
+
+**Résultat :** Crash immédiat de la base de données avec des erreurs de type `Illegal storage access` ou `Bus error`.
+
+---
+
+## 4. Pourquoi est-ce le réglage par défaut ?
+
+On pourrait se demander pourquoi un paramètre aussi risqué est activé par défaut. La réponse tient en deux points :
+
+1. **Hygiène système :** Sur les serveurs multi-utilisateurs ou les environnements de développement, cela évite que la RAM ne soit saturée par des résidus de processus terminés.
+    
+2. **Protection des utilisateurs système :** Par défaut, systemd est censé ignorer les utilisateurs dont l'UID est inférieur à 1000 (utilisateurs système). Cependant, selon la manière dont les sessions sont ouvertes (via `su`, `sudo` ou `polkit`), cette protection peut parfois être contournée, provoquant le crash.
+    
+
+---
+
+## 5. Bonnes pratiques
+
+### Vérifier l'état actuel
+
+Pour voir si des segments IPC sont actuellement utilisés sur votre machine :
+
+```Bash
+ipcs -a
+```
+
+### Modifier la configuration
+
+Si vous gérez des serveurs de bases de données, il est souvent recommandé de désactiver cette option :
+
+1. Éditez le fichier : `sudo nano /etc/systemd/logind.conf`
+    
+2. Décommettez ou ajoutez la ligne :
+    
+    ```toml
+    [Login]
+    RemoveIPC=no
+    ```
+    
+3. Redémarrez le démon (attention, cela peut impacter les sessions en cours) :
+    
+    ```Bash
+    sudo systemctl restart systemd-logind
+    ```
+    
+
+### Alternative : Utiliser `KillUserProcesses`
+
+Si votre but est de nettoyer les ressources, préférez parfois jouer avec `KillUserProcesses=yes`. Cela tuera tous les processus restants de l'utilisateur à la déconnexion, ce qui forcera souvent un nettoyage plus "propre" que la suppression brutale de segments de mémoire.
+
+---
+
+ **Sur un serveur haute dispo passez `RemoveIPC` à `no`.**
--- a/articles/2026/Déploiement
+++ b/articles/2026/Déploiement
@@ -0,0 +1,135 @@
+---
+title: "Déploiement d'Apache Guacamole via Docker sur Debian 12 (Bookworm)"
+description:
+tags: []
+date: 2026-03-11 00:27
+lastmod: 2026-03-11 01:19
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: brouillon
+---
+
+# Déploiement d'Apache Guacamole via Docker sur Debian 12 (Bookworm)
+
+L'installation d'Apache Guacamole peut vite devenir un enfer de dépendances (Java, Tomcat, extensions JDBC). Le passage par Docker simplifie tout, à condition de bien gérer la persistance des données et l'initialisation de la base PostgreSQL.
+
+## 1. La Philosophie du Stack
+
+Nous utilisons un trio de conteneurs isolés :
+
+- **Guacamole Client** : L'interface Web (Java/Tomcat).
+    
+- **Guacd** : Le moteur natif (proxy RDP/SSH/VNC).
+    
+- **PostgreSQL** : Le cerveau (stockage des utilisateurs et connexions).
+    
+
+## 2. Préparation du terrain
+
+On commence par structurer notre projet sur l'hôte :
+
+```Bash
+mkdir ~/guacamole-docker && cd ~/guacamole-docker
+mkdir -p guacamole-home data init
+```
+
+## 3. Le Docker-Compose "Gagnant"
+
+Le secret d'une installation qui ne casse pas lors des mises à jour réside dans l'utilisation d'un fichier `guacamole.properties` externe.
+
+`nano docker-compose.yml`
+
+```YAML
+services:
+  # Moteur de protocoles
+  guacd:
+    image: guacamole/guacd
+    container_name: guacd
+    restart: always
+
+  # Base de données
+  postgres:
+    image: postgres:15
+    container_name: guac-postgres
+    restart: always
+    environment:
+      POSTGRES_DB: guacamole_db
+      POSTGRES_USER: guacamole_user
+      POSTGRES_PASSWORD: TonMotDePasseFort
+    volumes:
+      - ./data:/var/lib/postgresql/data
+      - ./init:/docker-entrypoint-initdb.d
+
+  # Interface Web
+  guacamole:
+    image: guacamole/guacamole
+    container_name: guacamole
+    restart: always
+    ports:
+      - "8080:8080"
+    environment:
+      GUACD_HOSTNAME: guacd
+      POSTGRESQL_HOSTNAME: postgres
+      POSTGRESQL_DATABASE: guacamole_db
+      POSTGRESQL_USER: guacamole_user
+      POSTGRESQL_PASSWORD: TonMotDePasseFort
+    volumes:
+      - ./guacamole-home/guacamole.properties:/etc/guacamole/guacamole.properties
+    depends_on:
+      - guacd
+      - postgres
+```
+
+## 4. Initialisation de la Base de Données
+
+C’est l'étape où 90% des installations échouent. Il faut générer le schéma SQL officiel de Guacamole et le donner à manger à Postgres.
+
+```Bash
+# Générer le script SQL
+docker run --rm guacamole/guacamole /opt/guacamole/bin/initdb.sh --postgresql > ./init/01_initdb.sql
+
+# Lancer les conteneurs (Postgres va lire le dossier ./init)
+docker-compose up -d
+```
+
+## 5. Configuration Fine (`guacamole.properties`)
+
+Pour éviter que Java n'ignore vos variables d'environnement, créez ce fichier :
+
+`nano guacamole-home/guacamole.properties`
+
+```Properties
+postgresql-hostname: postgres
+postgresql-port: 5432
+postgresql-database: guacamole_db
+postgresql-username: guacamole_user
+postgresql-password: TonMotDePasseFort
+# Optionnel : priorité à la DB
+extension-priority: postgresql
+```
+
+## 6. Le "Cheat Code" pour le premier accès
+
+Si `guacadmin` / `guacadmin` vous renvoie un "Identifiant incorrect" (souvent dû à un souci de hachage lors de l'init), créez un admin de secours directement en SQL :
+
+```Bash
+docker exec -i guac-postgres psql -U guacamole_user -d guacamole_db -c "INSERT INTO guacamole_entity (name, type) VALUES ('admin_devops', 'USER');"
+docker exec -i guac-postgres psql -U guacamole_user -d guacamole_db -c "INSERT INTO guacamole_user (entity_id, password_hash, password_salt, password_date) SELECT entity_id, decode('8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918', 'hex'), NULL, CURRENT_TIMESTAMP FROM guacamole_entity WHERE name = 'admin_devops';"
+docker exec -i guac-postgres psql -U guacamole_user -d guacamole_db -c "INSERT INTO guacamole_system_permission (entity_id, permission) SELECT entity_id, permission::guacamole_system_permission_type FROM guacamole_entity, (VALUES ('CREATE_CONNECTION'), ('CREATE_USER'), ('ADMINISTER')) AS p (permission) WHERE name = 'admin_devops';"
+```
+
+_Identifiants : `admin_devops` / `admin`_
+
+---
+
+## 🛠 Tips de DevOps :
+
+- **Logs** : Utilisez `docker logs -f guacamole` pour voir les extensions se charger. Vous devez voir `PostgreSQL Authentication loaded`.
+    
+- **Sécurité** : Une fois connecté, créez votre utilisateur final et **supprimez** les comptes par défaut ou de secours.
+    
+- **HTTPS** : Ne laissez jamais Guacamole en HTTP (8080). Posez un **Nginx Proxy Manager** ou un **Traefik** devant pour gérer le SSL.
+    
+
--- a/articles/2026/Déployer
+++ b/articles/2026/Déployer
@@ -0,0 +1,288 @@
+---
+title: Déployer DocuSeal sur Debian 13
+description: Procédure permettant de déployer DocuSeal sur une machine virtuelle Debian 13 (Trixie) hébergée dans Proxmox, en utilisant Docker Compose.
+tags: [docuseal, pdf, signature, autohebergement]
+date: 2026-03-12 20:26
+lastmod: 2026-03-12 20:55
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: brouillon
+---
+
+# Déployer DocuSeal sur Debian 13
+
+Ce document décrit la procédure complète permettant de déployer **DocuSeal** sur une machine virtuelle **Debian 13 (Trixie)** hébergée dans **Proxmox**, en utilisant **Docker Compose**.
+
+L’objectif est d’obtenir une instance **auto-hébergée et souveraine** du service de signature électronique accessible via le domaine `sign.a5l.fr`.
+
+L’utilisation de Docker permet :
+
+- d’isoler l’application du système hôte,
+    
+- de simplifier les mises à jour,
+    
+- de faciliter les sauvegardes et la portabilité de l’instance.
+    
+
+---
+
+# 1. Création du conteneur LXC dans Proxmox
+
+Créer une conteneur  Debian 13 dans Proxmox.
+
+Ressources recommandées :
+
+- **2 vCPU**
+    
+- **2 Go de RAM**
+    
+- **10 Go de stockage minimum**
+    
+
+DocuSeal reste relativement léger, mais la mémoire est utile lors du traitement de documents PDF.
+
+---
+
+# 2. Installation de l’agent Proxmox
+
+Se connecter au conteneur via SSH ou via la console Proxmox, puis mettre le système à jour :
+
+```bash
+sudo apt update
+sudo apt upgrade -y
+```
+
+Il est également conseillé d’installer quelques outils utiles :
+
+```bash
+apt install -y curl ca-certificates gnupg
+```
+
+---
+
+# 3. Installation de Docker
+
+Debian 13 utilise une gestion moderne des dépôts sécurisés.  
+La méthode recommandée consiste à utiliser le dépôt officiel Docker.
+
+## Ajout de la clé GPG Docker
+
+```bash
+sudo install -m 0755 -d /etc/apt/keyrings
+
+curl -fsSL https://download.docker.com/linux/debian/gpg \
+| sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
+
+sudo chmod a+r /etc/apt/keyrings/docker.gpg
+```
+
+## Ajout du dépôt Docker
+
+```bash
+echo \
+"deb [arch=$(dpkg --print-architecture) \
+signed-by=/etc/apt/keyrings/docker.gpg] \
+https://download.docker.com/linux/debian \
+$(. /etc/os-release && echo "$VERSION_CODENAME") stable" \
+| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
+```
+
+## Installation du moteur Docker
+
+```bash
+sudo apt update
+
+sudo apt install -y \
+docker-ce \
+docker-ce-cli \
+containerd.io \
+docker-buildx-plugin \
+docker-compose-plugin
+```
+
+## Autoriser l’utilisateur courant à utiliser Docker
+
+```bash
+sudo usermod -aG docker $USER
+```
+
+Une **déconnexion / reconnexion de session** est nécessaire pour que ce changement prenne effet.
+
+---
+
+# 4. Déploiement de DocuSeal
+
+Créer un répertoire dédié à l’application.
+
+```bash
+mkdir -p ~/docuseal/data
+cd ~/docuseal
+```
+
+Créer ensuite le fichier de configuration Docker Compose.
+
+```bash
+nano docker-compose.yml
+```
+
+Contenu recommandé :
+
+```yaml
+services:
+  docuseal:
+    image: docuseal/docuseal:latest
+    container_name: docuseal
+    restart: unless-stopped
+
+    ports:
+      - "3000:3000"
+
+    volumes:
+      - ./data:/data
+
+    environment:
+      HOST: sign.a5l.fr
+      DATABASE_URL: sqlite3:/data/docuseal.db
+      FORCE_SSL: true
+```
+
+Explications :
+
+- **ports 3000:3000**  
+    expose le service localement.
+    
+- **volume `./data`**  
+    contient :
+    
+    - la base SQLite
+        
+    - les documents PDF
+        
+    - les fichiers temporaires
+        
+- **HOST**  
+    doit correspondre au nom de domaine utilisé.
+    
+- **FORCE_SSL**  
+    impose l’utilisation de HTTPS lorsque l’application est derrière un reverse proxy.
+    
+
+---
+
+## Lancement de l’application
+
+```bash
+docker compose up -d
+```
+
+Vérifier que le conteneur fonctionne :
+
+```bash
+docker ps
+```
+
+L’application est alors accessible sur :
+
+```
+http://IP_DE_LA_VM:3000
+```
+
+---
+
+# 6. Sauvegardes et maintenance
+
+## Sauvegarde des données
+
+Les données importantes se trouvent dans :
+
+```
+~/docuseal/data
+```
+
+Ce dossier contient :
+
+- la base SQLite
+    
+- les documents signés
+    
+- les métadonnées.
+    
+
+Il est recommandé de :
+
+- sauvegarder ce dossier régulièrement
+    
+- utiliser les sauvegardes Proxmox.
+    
+
+---
+
+## Mise à jour de DocuSeal
+
+La mise à jour de l’application est simple :
+
+```bash
+cd ~/docuseal
+
+docker compose pull
+docker compose up -d
+```
+
+Avant toute mise à jour, il est recommandé de créer un **snapshot Proxmox**.
+
+---
+
+# 7. Configuration SMTP
+
+Pour que DocuSeal puisse envoyer les invitations à signer, un serveur SMTP doit être configuré dans les paramètres de l’application.
+
+Les informations à fournir :
+
+- serveur SMTP
+    
+- port
+    
+- utilisateur
+    
+- mot de passe
+    
+- chiffrement TLS ou SSL
+    
+
+Sans configuration SMTP, les invitations par email ne fonctionneront pas.
+
+---
+
+# 8. Points de sécurité recommandés
+
+Plusieurs bonnes pratiques améliorent la sécurité de l’instance :
+
+- limiter l’accès SSH à des clés publiques
+    
+- activer un pare-feu (`ufw` ou `nftables`)
+    
+- restreindre l’accès direct au port **3000**
+    
+- maintenir Debian et Docker à jour
+    
+- effectuer des sauvegardes régulières.
+    
+
+---
+
+# 9. Avantages de DocuSeal en auto-hébergement
+
+DocuSeal présente plusieurs avantages pour un déploiement auto-hébergé :
+
+- **Souveraineté des données** : les documents restent sur votre infrastructure.
+    
+- **Légèreté** : fonctionnement possible sur une petite VM.
+    
+- **Déploiement simple** grâce à Docker.
+    
+- **Maintenance limitée** : les mises à jour ne modifient pas le système hôte.
+    
+
+Cette architecture permet de disposer d’un service de signature électronique fiable, isolé et facilement maintenable dans une infrastructure Proxmox.
--- a/articles/2026/Installer
+++ b/articles/2026/Installer
--- a/articles/2026/Installer
+++ b/articles/2026/Installer
@@ -0,0 +1,206 @@
+---
+title: Installer un service ntfy dans votre domaine
+description:
+tags: []
+date: 2026-03-08 16:47
+lastmod: 2026-03-08 21:16
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: brouillon
+---
+Installer son propre serveur **ntfy** sur Proxmox est une excellente idée pour reprendre le contrôle de ses notifications sans dépendre de services tiers.
+
+Voici un tutoriel pas à pas pour configurer cela dans un conteneur **LXC Debian sur ProxMox**.
+
+---
+
+## 1. Création du conteneur LXC sur Proxmox
+
+1. Créez un nouveau conteneur :
+    
+    - **Hostname :** `ntfy`
+        
+    - **Ressources conseillées :** 1 vCPU, 512 Mo de RAM, et 8 Go de disque (ntfy est très léger).
+        
+    - **Réseau :** Attribuez une IP statique ou une réservation DHCP.
+        
+    - **Template :** Debian 13.
+        
+2. Démarrez le conteneur et connectez-vous en SSH ou via la console.
+    
+
+![](Pasted%20image%2020260308171916.png)
+
+
+---
+
+## 2. Installation de ntfy
+
+Nous allons utiliser le dépôt officiel pour faciliter les mises à jour.
+
+```Bash
+# Mise à jour du système
+sudo apt update && sudo apt upgrade -y
+
+# Installation des dépendances
+sudo apt install -y curl debian-archive-keyring
+
+# Créer le dossier pour les clés s'il n'existe pas
+sudo mkdir -p /etc/apt/keyrings
+
+# Télécharger la nouvelle clé
+sudo curl -L -o /etc/apt/keyrings/ntfy.gpg https://archive.ntfy.sh/apt/keyring.gpg
+
+echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/ntfy.gpg] https://archive.ntfy.sh/apt stable main" | sudo tee /etc/apt/sources.list.d/ntfy.list
+
+sudo apt update
+sudo apt install ntfy -y
+
+# Activation du service au démarrage
+sudo systemctl enable ntfy
+```
+
+---
+
+## 3. Configurer le reverseProxy avec le nom public
+
+### 1. Publication sur `mon-domaine.fr`
+
+Pour que cela fonctionne depuis l'extérieur, vous devez configurer votre **Reverse Proxy** (qui doit se trouver sur une autre machine ou un autre LXC) :
+
+1. **Pointage DNS :** Faites pointer `ntfy.mon-domaine.fr` vers votre IP publique.
+    
+2. **NAT/Port Forwarding :** Sur votre box/routeur, redirigez les ports **80** et **443** vers l'IP de votre Reverse Proxy.
+    
+3. **Config Proxy :** Redirigez les requêtes arrivant sur `ntfy.mon-domaine.fr` vers l'IP locale de votre LXC ntfy sur le port **8080**.
+    
+    - _Note importante :_ Assurez-vous d'activer le support des **WebSockets** et de passer les headers `Upgrade` et `Connection`, sinon les notifications sur smartphone ne seront pas instantanées.
+
+### 2. Le "piège" du Reverse Proxy (Headers)
+
+Comme vous publiez sur `mon-domaine.fr`, votre Reverse Proxy (Nginx, Traefik ou autre) doit impérativement transmettre l'IP réelle du visiteur à ntfy, sinon ntfy croira que toutes les requêtes viennent de votre proxy.
+
+Si vous utilisez **Nginx**, votre bloc de configuration devrait ressembler à ceci pour gérer les **WebSockets** (indispensables pour l'app Android/iOS) :
+
+```Nginx
+location / {
+    proxy_pass http://IP_DU_LXC_NTFY:80;
+    proxy_http_version 1.1;
+
+    # Ces lignes sont vitales pour les notifications en temps réel
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection "upgrade";
+    
+    proxy_set_header Host $host;
+    proxy_set_header X-Real-IP $remote_addr;
+    proxy_set_header X-Forwarded-Host $host;  
+	proxy_set_header X-Forwarded-Proto $scheme;
+    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    proxy_set_header X-Real-IP $remote_addr;
+    
+    proxy_connect_timeout 1h;
+    proxy_send_timeout 1h;
+    proxy_read_timeout 1h;
+}
+```
+
+## 4. Configuration de ntfy
+
+Avant de modifier la configuration, nous devons préparer l'environnement de stockage pour que **ntfy** puisse enregistrer ses utilisateurs et le cache des messages de manière persistante.
+
+Exécutez ces commandes pour créer le répertoire de données et attribuer les permissions correctes à l'utilisateur système `ntfy` :
+
+```
+sudo mkdir -p /var/lib/ntfy  
+sudo chown ntfy:ntfy /var/lib/ntfy
+sudo chmod 700 /var/lib/ntfy
+```
+
+
+Le fichier de configuration principal se trouve dans `/etc/ntfy/server.yml`.
+
+1. Ouvrez le fichier : `nano /etc/ntfy/server.yml`
+    
+2. Modifiez les lignes suivantes pour correspondre à votre domaine **ntfy.mon-domaine.fr** :
+    
+
+```YAML
+# L'URL de base est cruciale pour les liens dans les notifications
+base-url: "https://ntfy.mon-domaine.fr"
+
+# Écoute sur le port 80 (derrière un reverse proxy)
+listen-http: ":8080"
+
+# Lien avec votre broker MQTT existant
+mqtt-helper-url: "tcp://mqtt.workgroup.lan:1883"
+mqtt-helper-subscriptions:
+  - topic: "ntfy/#"
+
+# Recommandé : Activer l'authentification pour éviter les abus sur votre domaine
+auth-file: "/var/lib/ntfy/user.db"
+auth-default-access: "deny-all"
+enable-login: true
+
+# Permet de conserver les messages si le destinataire est hors ligne
+cache-file: "/var/lib/ntfy/cache.db"
+cache-duration: "12h" # Garde les messages 12h par exemple
+
+auth-file: "/var/lib/ntfy/user.db"
+```
+
+3. Redémarrez le service : `sudo systemctl restart ntfy`
+
+**Note :** Si le service refuse de démarrer, vérifiez les logs avec `journalctl -u ntfy -f`. Une erreur de syntaxe dans le fichier `.yml` (comme un espace en trop) est souvent la cause.
+
+### Gestion des utilisateurs (Sécurité)
+
+Puisque la directive `auth-default-access: "deny-all"` est activée, l'accès est verrouillé par défaut. Vous devez impérativement créer un compte administrateur via le terminal pour reprendre la main sur le serveur et commencer à envoyer des notifications.
+
+#### Création du premier administrateur
+
+Exécutez les commandes suivantes sur votre serveur :
+
+```Bash
+# Créer un utilisateur avec les privilèges d'administrateur
+ntfy user add --role=admin votre_nom_utilisateur
+
+# Redémarrer le service pour valider la nouvelle configuration
+sudo systemctl restart ntfy
+```
+
+#### Distinction importante : Interface Web vs CLI
+
+Il est crucial de ne pas confondre la gestion du serveur avec la gestion de la session locale :
+
+- **L'interface graphique (Web UI) :** Elle ne permet pas d'ajouter ou de supprimer des utilisateurs dans la base de données du serveur.
+    
+- **Menu "Paramètres" > "Gérer les utilisateurs" :** Cette option sert uniquement à **enregistrer vos identifiants de connexion** dans votre navigateur. Cela permet à l'interface web de s'authentifier auprès du serveur pour afficher vos sujets (topics) privés, mais cela ne crée en aucun cas un compte sur le système.
+    
+
+> **Note :** Toute modification structurelle des permissions ou des comptes doit être effectuée en ligne de commande (CLI) à l'aide de la commande `ntfy user`.
+
+---
+
+#### Résumé des droits d'accès
+
+Une fois votre utilisateur créé, vous pouvez affiner les droits selon vos besoins :
+
+|**Commande**|**Action**|
+|---|---|
+|`ntfy user list`|Voir tous les utilisateurs enregistrés.|
+|`ntfy access <user> <topic> read-write`|Donner un accès complet à un sujet précis.|
+|`ntfy user change-pass <user>`|Modifier le mot de passe d'un utilisateur.|
+
+## 5. Test de fonctionnement
+
+Une fois le domaine et le proxy configurés, vous pouvez tester l'envoi d'une notification via un simple `curl` depuis n'importe quel terminal :
+
+```Bash
+curl -u votre_user:votre_password \ -d "Test de notification sécurisée" \ https://ntfy.mon-domaine.fr/test
+```
+
+Si vous allez sur `https://ntfy.mon-domaine.fr/test`, vous devriez voir votre message apparaître.
+
+
--- a/articles/2026/convertir
+++ b/articles/2026/convertir
@@ -0,0 +1,42 @@
+---
+title: Convertir un fichier MKV en MP4
+description: Remuxing d'un fichier mkv en mp4 sous linux avec ffmpeg.
+tags:
+  - ffmpeg
+  - mp4
+  - mkv
+date: 2026-03-11 17:59
+lastmod: 2026-03-11 18:02
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: brouillon
+---
+
+# Convertir un fichier MKV en MP4
+
+Un fichier vidéo est comme une boîte (le **conteneur** : MKV, MP4) qui contient des objets (les **flux** : vidéo H.264/H.265, audio AAC/MP3). Comme le MKV et le MP4 acceptent souvent les mêmes types de flux vidéo, on peut simplement "transvaser" le contenu de l'un vers l'autre sans rien transformer.
+
+C'est ce qu'on appelle le **remuxing** (ou copie de flux). C'est instantané et il n'y a **aucune perte de qualité**.
+
+Sous Linux Mint, l'outil roi est **FFmpeg**. S'il n'est pas installé : `sudo apt install ffmpeg`.
+
+Pour changer le conteneur sans réencoder la vidéo ni l'audio, ouvrez un terminal dans votre dossier et tapez :
+
+``ffmpeg -i entree.mkv -codec copy sortie.mp4``
+
+- `-i entree.mkv` : votre fichier source.
+    
+- `-codec copy` : indique à FFmpeg de copier les flux tels quels sans les recalculer.
+    
+- `sortie.mp4` : le nouveau fichier.
+
+Bien que le changement de conteneur suffise 90% du temps, voici deux cas où cela pourrait coincer :
+
+1. **Le format audio :** Le MP4 est plus strict que le MKV. Si votre MKV contient de l'audio au format **FLAC** ou **Vorbis**, certains lecteurs MP4 ne l'aimeront pas. Il faudra alors convertir juste l'audio :
+    
+    - `ffmpeg -i entree.mkv -c:v copy -c:a aac sortie.mp4` (On copie la vidéo, on convertit l'audio en AAC).
+        
+2. **Les sous-titres :** Le MKV gère très bien les sous-titres intégrés (ASS/SSA). Le MP4 est beaucoup plus limité. Ils risquent de disparaître lors d'un simple "copy".
+
--- a/articles/2026/gscan2pdf
+++ b/articles/2026/gscan2pdf
@@ -0,0 +1,65 @@
+---
+title: "Linux Mint 22 et gscan2pdf : Pourquoi il faut \"briser\" la routine d'installation"
+description: Comment installer gscan2pdf sur Linux Mint 22 ?
+tags: [scan, ocr, scan2pdf, Mint, Linux]
+date: 2026-03-13 12:40
+lastmod: 2026-03-13 12:44
+type:
+  - article
+category:
+  - "[[Logiciels et Outils]]"
+  - "[[Guide]]"
+status: terminé
+---
+
+# Linux Mint 22 et gscan2pdf : Pourquoi il faut "briser" la routine d'installation
+
+![](Pasted%20image%2020260313124448.png)
+
+C'est un paradoxe classique du logiciel libre : la version d'une application incluse dans votre gestionnaire de logiciels n'est pas toujours la meilleure pour vous. Dans le cas de **gscan2pdf** sur **Linux Mint 22**, installer la version "standard" revient à installer un moteur en panne.
+
+## Le constat : Le piège du dépôt "Stable"
+
+Normalement, l'utilisateur Linux a un réflexe sain : utiliser les dépôts officiels. Mais sur Mint 22 (basée sur Ubuntu 24.04), le dépôt standard propose la version **2.13.2**.
+
+Pour gscan2pdf, c'est la version de trop. Elle se heurte à deux murs :
+
+1. **L'évolution de Perl :** Le système utilise un langage trop récent pour le vieux code de l'application, inondant l'utilisateur d'alertes de dépréciation.
+    
+2. **Le changement de structure de Mint :** L'application cherche un fichier là où Mint 22 a désormais placé un dossier (`/etc/upstream-release`), provoquant un crash immédiat.
+    
+
+Résultat ? L'installation standard est, au sens propre, inutilisable.
+
+## Contourner pour mieux régner
+
+Pour retrouver un scanner fonctionnel, la consigne est claire : **ne pas faire confiance au dépôt par défaut.** Il faut aller chercher la correction directement à la source, là où le développeur (Jeffrey Ratcliffe) a déjà colmaté les brèches.
+
+La solution ne passe pas par une interface graphique, mais par trois commandes décisives dans le terminal. On force le système à ignorer sa base de données habituelle pour adopter celle du développeur :
+
+1. **L'ajout de l'autorité (PPA) :** On crée un "tunnel" direct vers les mises à jour du créateur.
+    
+    ```Bash
+    sudo add-apt-repository ppa:jeffreyratcliffe/ppa
+    ```
+    
+2. **La synchronisation :** On force Mint à constater que, oui, il existe une version bien plus moderne (2.13.4 ou supérieure) ailleurs.
+    
+    ```Bash
+    sudo apt update
+    ```
+    
+3. **Le remplacement :** On écrase la version défaillante.
+        
+    ```Bash
+    sudo apt install gscan2pdf
+    ```
+    
+
+## L'OCR en français
+
+Une fois le logiciel "réanimé", il reste souvent muet face aux textes français. Par défaut, le moteur de reconnaissance **Tesseract** ne parle qu'anglais. Pour compléter cette installation, il est indispensable d'ajouter manuellement la brique linguistique :
+
+```Bash
+sudo apt install tesseract-ocr-fra
+```
--- a/articles/2026/maitriser_le_forwarding_avec_NPMplus_et_Apache.md
+++ b/articles/2026/maitriser_le_forwarding_avec_NPMplus_et_Apache.md
@@ -0,0 +1,75 @@
+---
+title: Maîtriser le Forwarding avec NPMplus et Apache
+description: Marre de voir l'IP de votre reverse proxy dans vos logs Apache ? Découvrez comment configurer NPMplus et le module mod_remoteip pour restaurer la visibilité de l'IP réelle de vos visiteurs. Un guide détaillé pour DevOps incluant la gestion du header X-Forwarded-For et les bonnes pratiques de sécurité.
+tags: []
+date: 2026-03-10 07:43
+lastmod: 2026-03-10 07:51
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: terminé
+---
+
+# Maîtriser le Forwarding avec NPMplus et Apache
+
+**Par Cédrix** | _Date d'édition : 10 mars 2026_
+
+Dans l'architecture moderne des micro-services, le **Reverse Proxy** est devenu la pierre angulaire de la sécurité et de la flexibilité. Que ce soit pour la terminaison SSL, le load-balancing ou la gestion des noms de domaine, des outils comme **NPMplus** (Nginx Proxy Manager Plus) facilitent grandement la vie des DevOps.
+
+Pourtant, un problème récurrent hante les administrateurs : **la disparition de l'adresse IP réelle du client dans les logs applicatifs.** Pourquoi votre serveur Apache ne voit-il que l'IP locale du proxy ? Comment restaurer la visibilité sans briser la chaîne de confiance ? Plongée au cœur des headers HTTP.
+
+## Le Problème : L'illusion de la connexion directe
+
+Lorsqu'un utilisateur consulte votre site, il ne parle pas directement à Apache. Il établit une connexion TCP avec **NPMplus**. Pour Apache, le "client", c'est le proxy.
+
+> **Le risque :** Si votre Apache croit que tout le trafic provient de `192.168.100.95` (votre proxy), vos outils d'analyse (Matomo, AWStats) sont aveugles, et vos outils de sécurité (Fail2Ban) risquent de bannir votre propre infrastructure au premier faux pas d'un utilisateur.
+
+## La Solution : Le Header `X-Forwarded-For`
+
+Pour pallier cela, le reverse proxy doit devenir un "messager". Avant de transmettre la requête à Apache, il ajoute une étiquette à l'enveloppe HTTP : le header `X-Forwarded-For` (XFF).
+
+### 1. La configuration du messager (NPMplus)
+
+NPMplus utilise Nginx sous le capot. Pour qu'il transmette l'identité du visiteur, il doit injecter ces directives dans la configuration du bloc `location` :
+
+```Nginx
+proxy_set_header X-Real-IP $remote_addr;
+proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+```
+
+_$proxy_add_x_forwarded_for_ est crucial car il conserve la trace de tous les proxys traversés (si l'utilisateur passe déjà par un VPN ou un CDN comme Cloudflare).
+
+## Le Récepteur : Configurer Apache avec `mod_remoteip`
+
+Côté Apache, il ne suffit pas de recevoir le header ; il faut lui donner une valeur légale. C'est ici qu'intervient le module **`mod_remoteip`**.
+
+### Étape A : Établir la relation de confiance
+
+Apache refuse par défaut de croire n'importe quel header XFF (car n'importe quel pirate pourrait injecter une fausse IP). Vous devez définir une liste blanche d'IP de confiance.
+
+Dans votre configuration (`/etc/apache2/conf-available/remoteip.conf`) :
+
+```Apache
+RemoteIPHeader X-Forwarded-For
+RemoteIPInternalProxy 192.168.100.95
+```
+
+**Point d'attention :** Une simple erreur de frappe ici, et Apache ignorera le header, revenant à l'affichage de l'IP du proxy.
+
+### Étape B : Réécrire le format de journalisation
+
+Par défaut, Apache utilise la variable `%h` (hostname) dans ses logs. Pour afficher l'IP "extraite" par le module remoteip, il faut passer à la variable **`%a`** (peer IP address).
+
+Modifiez votre `LogFormat` dans `apache2.conf` :
+
+Apache
+
+```
+# Remplacez %h par %a
+LogFormat "%a %l %u %t \"%r\" %>s %b" combined
+```
+
+## Vérification finale
+
+Un simple `tail -f /var/log/apache2/access.log` vous confirmera immédiatement si le réglage est opérationnel. Si vous voyez une IP publique au lieu de votre IP locale, vous avez réussi votre mise en production !
--- a/articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md
+++ b/articles/2026/maitriser_tcp_analyse_wireshark_flux_pertes_congestion_securite.md
@@ -0,0 +1,747 @@
+---
+title: "Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion"
+description:
+tags: []
+date: 2026-03-08 13:35
+lastmod: 2026-03-08 14:35
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: terminé
+---
+
+# Maîtriser TCP par l'Analyse Wireshark : Flux, Pertes et Congestion
+
+Le protocole **TCP (Transmission Control Protocol)** est le pilier de la fiabilité sur Internet (Web, SSH, Bases de données). Contrairement aux idées reçues, TCP ne compte pas des paquets, mais des **octets**. Comprendre cette nuance est la clé pour interpréter les comportements complexes : retransmissions, fenêtres de réception et fermetures de connexion.
+
+## La Fiabilité de TCP — Séquençage et Acquittement
+
+Le protocole **TCP (Transmission Control Protocol)** est souvent comparé à une conversation téléphonique polie : on ne se contente pas de parler, on s'assure que l'autre a bien entendu et compris chaque segment avant de poursuivre. Contrairement à UDP, TCP garantit que les données arrivent dans l'ordre et sans erreurs.
+
+---
+
+### 1. Les Fondations : SEQ et ACK
+
+TCP ne voit pas les données comme des fichiers distincts, mais comme un **flux continu d'octets**. Pour s'y retrouver dans ce flux, il utilise deux compteurs essentiels logés dans l'en-tête du segment :
+
+#### **A. Le Numéro de Séquence (SEQ)**
+
+Le champ **SEQ** indique la position du premier octet de données du segment actuel dans le flux global.
+
+- **Logique :** Si vous envoyez un segment contenant 500 octets et que votre SEQ actuel est $1000$, le segment couvre les octets $1000$ à $1499$.
+    
+- **Calcul du prochain SEQ :** $SEQ_{suivant} = SEQ_{actuel} + \text{Taille des données}$. Dans notre exemple, le prochain envoi commencera au SEQ $1500$.
+    
+
+#### **B. Le Numéro d'Acquittement (ACK)**
+
+Le champ **ACK** est une confirmation, mais surtout une **requête pour la suite**.
+
+- **Logique :** Il indique le numéro du _prochain_ octet attendu par le récepteur.
+    
+- **Exemple :** Si le récepteur renvoie un `ACK 1501`, il signifie explicitement : _"J'ai bien reçu tout ce qui précède l'octet 1501. Envoie-moi maintenant la suite à partir de 1501."_
+    
+
+Les flags `SYN` et `FIN` consomment virtuellement **1 unité de numéro de séquence**, même s'ils ne transportent pas de données réelles
+
+---
+
+### 2. L'Initialisation : L'ISN (Initial Sequence Number)
+
+Pourquoi ne pas commencer systématiquement à zéro ? Pour des raisons de sécurité et de robustesse, TCP utilise l'**ISN**.
+
+- **Définition :** Lors de la phase de connexion (_Three-Way Handshake_), chaque hôte choisit un numéro de départ **aléatoire** sur 32 bits.
+    
+- **Pourquoi l'aléatoire ?**
+    
+    1. **Éviter les collisions :** Si une ancienne connexion sur le même port traîne encore sur le réseau (paquets retardés), un numéro aléatoire évite que ces vieux paquets ne soient acceptés par erreur dans la nouvelle session.
+        
+    2. **Sécurité :** Si les numéros étaient prévisibles, un attaquant pourrait injecter de faux paquets dans une session en devinant le prochain SEQ.
+        
+
+---
+
+### 3. Application Pratique : L'Analyse Wireshark
+
+Lorsque vous capturez du trafic avec Wireshark, vous remarquerez que les numéros commencent souvent à $0$. Ce sont des **numéros relatifs**, simplifiés par le logiciel pour faciliter la lecture humaine.
+
+> **Manipulation Étudiante : Voir la réalité du réseau**
+> 
+> Pour observer les véritables numéros de 32 bits (les ISN réels) :
+> 
+> 1. Faites un clic droit sur un paquet TCP.
+>     
+> 2. Allez dans **Protocol Preferences** > **Transmission Control Protocol**.
+>     
+> 3. Décochez **"Relative sequence numbers"**.
+>     
+>     _Observez alors les chiffres massifs (ex: 3824910542) qui circulent réellement sur vos câbles._
+>     
+
+---
+
+### 4. Résumé du mécanisme
+
+| **Concept** | **Rôle principal**    | **Analogie**                                     |
+| ----------- | --------------------- | ------------------------------------------------ |
+| **SEQ**     | Identifie l'envoi     | "Voici les caractères n'°1000 à 1500"            |
+| **ACK**     | Confirme la réception | "Bien reçu, donne-moi la suite à partir de 1501" |
+| **ISN**     | Sécurise le départ    | Choisir un numéro au hasard pour commencer.      |
+
+---
+
+## 2. L'Établissement de la Connexion et la Négociation des Paramètres
+
+Dans l'architecture TCP/IP, une application ne peut pas simplement "jeter" des données sur le réseau. Avant tout échange, les deux hôtes doivent s'accorder sur un état commun. C'est le rôle du **Three-Way Handshake** (la poignée de main en trois temps), une procédure de synchronisation qui transforme un canal physique non fiable en une liaison logique robuste.
+
+---
+
+### 1. Le "Three-Way Handshake" (3WHS)
+
+L'établissement d'une session TCP suit un rituel immuable en trois étapes, permettant d'échanger les numéros de séquence initiaux (**ISN**) et de confirmer la disponibilité des ressources.
+
+1. **SYN (Synchronize) :** Le client envoie un segment avec le flag `SYN` activé. Il y insère son **ISN** (Initial Sequence Number) généré aléatoirement. C'est une déclaration d'intention : _"Je souhaite ouvrir une connexion et voici mon point de départ numérique."_
+    
+2. **SYN-ACK (Synchronize-Acknowledgment) :** Le serveur répond avec les deux flags activés.
+    
+    - Il choisit son propre **ISN**.
+        
+    - Il acquitte celui du client en envoyant un **ACK** égal à $ISN_{client} + 1$. Cela signifie : _"J'ai reçu ton SYN, j'attends l'octet suivant."_
+        
+3. **ACK (Acknowledgment) :** Le client finalise la boucle en acquittant l'ISN du serveur ($ACK = ISN_{serveur} + 1$). La connexion est alors déclarée **ESTABLISHED**.
+    
+
+---
+
+### 2. Négociation des Paramètres Critiques
+
+Le handshake n'est pas qu'une simple politesse ; c'est une phase de **négociation contractuelle**. Les hôtes y annoncent leurs limites techniques pour optimiser le transfert.
+
+#### **A. Le MSS (Maximum Segment Size)**
+
+Le MSS définit la quantité maximale de données utiles (le "payload") qu'un hôte peut accepter dans un seul segment TCP.
+
+- **Calcul :** Sur un réseau Ethernet standard, le MTU (Maximum Transmission Unit) est de 1500 octets. Si l'on retire l'en-tête IP (20 octets) et l'en-tête TCP (20 octets), il reste un **MSS de 1460 octets**.
+    
+- **Impact :** Si les deux hôtes ont des MSS différents, c'est la valeur la plus **petite** qui est retenue pour éviter la fragmentation IP, coûteuse en ressources.
+    
+
+
+---
+
+### B. Le Window Scale (L'extension de fenêtre)
+
+À l'origine, le champ **Window Size** dans l'en-tête TCP était codé sur 16 bits, limitant la fenêtre de réception à un maximum de **64 Ko** ($2^{16}$). Sur les réseaux modernes à très haut débit (Fibre, 10GbE), cette limite s'est transformée en goulot d'étranglement : l'émetteur passait plus de temps à attendre des acquittements qu'à envoyer des données.
+
+- **Le mécanisme du Bit Shift :** Pour dépasser cette limite sans modifier la structure de l'en-tête, on utilise l'option **Window Scale**. Elle définit un "facteur de décalage" (Shift Count). Par exemple, si le facteur est de **7**, chaque valeur de fenêtre annoncée est décalée de 7 bits vers la gauche, ce qui revient à multiplier la valeur par **128** ($2^7$).
+    
+- **Résultat :** Ce multiplicateur permet d'étendre virtuellement la fenêtre jusqu'à **1 Go**, une capacité indispensable pour saturer les liens à haut débit et forte latence, appelés **LFN** (_Long Fat Networks_).
+    
+
+---
+
+### C. Le SACK (Selective Acknowledgment)
+
+Dans le fonctionnement TCP standard (dit "Cumulative ACK"), si le segment n°3 est perdu mais que les n°4 et n°5 arrivent, le récepteur est incapable de signaler qu'il possède déjà la suite. Il ne peut que répéter : _"J'attends toujours le n°3"_. Par prudence, l'émetteur finit souvent par retransmettre inutilement tout le flux à partir du n°3.
+
+- **L'optimisation SACK :** Négocié via l'option _SACK Permitted_ lors du handshake, ce mécanisme permet au récepteur d'envoyer des informations précises sur les blocs de données déjà stockés en mémoire. Il dit explicitement : _"Il me manque l'octet n°3, MAIS j'ai déjà bien reçu et mis de côté les blocs allant du n°4 au n°6"_.
+    
+- **Gain de performance :** L'émetteur identifie immédiatement les "trous" dans le flux. Il ne retransmet que les segments manquants, préservant ainsi la bande passante et évitant de congestionner inutilement le réseau.
+    
+
+---
+
+### Résumé
+
+|**Paramètre**|**Phase de négociation**|**Utilité majeure**|
+|---|---|---|
+|**SYN / ACK**|Handshake|Synchronisation des ISN et état de la session.|
+|**MSS**|Handshake|Éviter la fragmentation en s'adaptant à la MTU.|
+|**Window Scale**|Handshake|Permettre des transferts haute performance (> 64 Ko).|
+|**SACK**|Handshake|Retransmission intelligente des segments perdus.|
+
+---
+
+Pour bien comprendre, rien ne vaut l'observation des "entrailles" d'un paquet. Nous allons simuler une analyse de trame comme si vous étiez devant votre écran, en nous concentrant sur le premier paquet d'une connexion (le **SYN**).
+
+### Travaux Dirigés : Analyse d'un segment SYN sous Wireshark
+
+Lorsqu'un client (PC) contacte un serveur (Web), le premier paquet envoyé contient toutes les "négociations" que nous avons vues. Voici comment les interpréter dans les couches protocolaires.
+
+---
+
+#### 1. L'anatomie du premier échange (Le SYN)
+
+Dans l'en-tête TCP de ce premier paquet, vous trouverez les champs suivants :
+
+- **Flags : 0x002 (SYN)** : Seul le bit de synchronisation est levé.
+    
+- **Sequence Number : 0** (Relatif) ou un nombre aléatoire comme `3824910542` (Réel).
+    
+- **Window Size : 64240** : La mémoire tampon initiale proposée par le client.
+    
+
+---
+
+#### 2. Le bloc "Options" : Le cœur de la négociation
+
+C'est ici que se joue la performance de la future connexion. Dans Wireshark, déployez l'arborescence **"Options"** sous l'en-tête TCP :
+
+##### **A. Maximum Segment Size (MSS)**
+
+- **Valeur type :** `1460 bytes`.
+    
+- **Interprétation :** Le client informe le serveur : _"Mes trames Ethernet font 1500 octets, donc ne m'envoie pas de segments de données brutes dépassant 1460 octets."_
+    
+
+##### **B. Window Scale (WS)**
+
+- **Valeur type :** `Shift count 7 (multiplier 128)`.
+    
+- **Interprétation :** Sans cette option, le débit serait bridé à cause de la latence. Ici, la fenêtre réelle sera calculée en multipliant la `Window Size` annoncée par 128. C'est l'accélérateur pour la fibre optique.
+    
+
+##### **C. SACK Permitted**
+
+- **Valeur :** `True`.
+    
+- **Interprétation :** Le client dit au serveur : _"Je supporte les acquittements sélectifs. Si tu perds un paquet au milieu de l'envoi, je te dirai exactement lequel, ne renvoie pas tout !"_
+    
+
+---
+
+#### 3. Le "Three-Way Handshake" complet en chiffres
+
+Imaginons un client (C) et un serveur (S) :
+
+1. **C → S [SYN]** : `SEQ = 1000`, `Options: MSS=1460, SACK=OK, WS=128`
+    
+2. **S → C [SYN, ACK]** : `SEQ = 5000`, `ACK = 1001`, `Options: MSS=1400, SACK=OK, WS=64`
+    
+    > _Note : Le serveur a un MSS plus petit (1400). Les deux utiliseront 1400 pour toute la session._
+    
+3. **C → S [ACK]** : `SEQ = 1001`, `ACK = 5001`.
+    
+
+---
+
+#### Synthèse : Pourquoi est-ce crucial pour un administrateur ?
+
+Si vous diagnostiquez une lenteur réseau ("Le réseau est lent"), vérifiez toujours ces options :
+
+- Un **MSS mal négocié** provoque de la fragmentation et fait chuter les performances.
+    
+- Un **Window Scale absent** (multiplicateur à 1) empêche d'utiliser la pleine bande passante sur des liens longue distance.
+    
+
+---
+
+## 3. La Gestion des Pertes — Résilience et Réactivité de TCP
+
+Dans un monde idéal, chaque paquet arrive à destination. Dans la réalité des réseaux (WiFi instable, encombrement des routeurs, câbles défectueux), des segments se perdent. TCP ne panique pas : il dispose de deux stratégies complémentaires pour boucher les "trous" dans le flux de données.
+
+---
+
+### 1. La Retransmission sur Timeout (RTO) : La roue de secours
+
+Le **RTO (Retransmission Time-Out)** est le mécanisme de base, fondé sur la patience. Lorsqu'un émetteur envoie un segment, il déclenche un chronomètre. S'il n'a reçu aucun acquittement (`ACK`) à l'expiration de ce délai, il considère le segment comme perdu et le renvoie.
+
+#### **Le concept du Backoff Exponentiel**
+
+Si le réseau est saturé, renvoyer frénétiquement des paquets ne ferait qu'aggraver la congestion (c'est l'analogie d'un bouchon sur l'autoroute : ajouter des voitures n'aide pas).
+
+- **Logique :** À chaque échec consécutif, TCP **double** le délai d'attente.
+    
+- **Exemple :** Si le premier timeout est de 1s, le suivant sera de 2s, puis 4s, 8s... jusqu'à abandonner la connexion si le lien est totalement coupé.
+    
+
+---
+
+### 2. La Fast Retransmission : La réactivité par les "Duplicate ACKs"
+
+Attendre un timeout est lent et pénalise les performances. TCP utilise donc une astuce basée sur les retours du récepteur : la **Fast Retransmission**.
+
+#### **Le mécanisme des "Acks en double"**
+
+Imaginons que l'émetteur envoie les segments 1, 2, 3, 4 et 5. Le segment **n°2 est perdu**.
+
+1. Le récepteur reçoit le n°1 : il renvoie `ACK 2` (J'attends le 2).
+    
+2. Le récepteur reçoit le n°3 (au lieu du 2) : il ne peut pas acquitter le 3. Il renvoie donc à nouveau **`ACK 2`**.
+    
+3. Le récepteur reçoit le n°4 : il renvoie encore **`ACK 2`**.
+    
+
+#### **La règle des 3 Duplicate ACKs**
+
+Dès que l'émetteur reçoit **3 acquittements identiques supplémentaires** (soit 4 fois le même ACK au total), il n'attend pas la fin de son chronomètre (RTO). Il comprend immédiatement que le segment n°2 est manquant et le renvoie sur-le-champ. C'est ce qu'on appelle la "Retransmission Rapide".
+
+---
+
+### 3. Comparaison des deux mécanismes
+
+|Caractéristique|Retransmission par Timeout (RTO)|Fast Retransmission|
+|---|---|---|
+|**Déclencheur**|Absence totale de réponse (Silence)|Réception de 3 Duplicate ACKs|
+|**Vitesse**|Lente (attend l'expiration du timer)|Très rapide (réaction immédiate)|
+|**Scénario type**|Coupure réseau ou perte massive|Perte isolée d'un segment dans un flux|
+|**Impact Débit**|Chute brutale du débit (Backoff)|Impact modéré sur la performance|
+
+Exporter vers Sheets
+
+---
+
+### Analyse Wireshark : Repérer les problèmes
+
+Dans Wireshark, ces événements sont mis en évidence par des couleurs spécifiques (souvent texte noir sur fond rouge ou inversement) :
+
+- **[TCP Retransmission]** : Indique un renvoi après un timeout.
+    
+- **[TCP Fast Retransmission]** : Indique un renvoi suite à des Duplicate ACKs.
+    
+- **[TCP Dup ACK]** : Les messages du récepteur signalant qu'il lui manque quelque chose.
+    
+
+> **Note d'expert :** Si vous voyez beaucoup de _Fast Retransmissions_, le réseau fonctionne mais "saigne" un peu (quelques pertes). Si vous voyez des _Timeouts_, la connexion est probablement en train de s'effondrer.
+    
+
+## 4. Le Contrôle de Flux — La Fenêtre Glissante (Sliding Window)
+
+La vitesse d'un transfert TCP ne dépend pas seulement de la puissance du processeur, mais de la capacité du récepteur à "digérer" les données. Le **Contrôle de Flux** empêche un émetteur rapide de submerger un récepteur lent ou occupé.
+
+---
+
+### 1. Le mécanisme de la Fenêtre de Réception (Win)
+
+Chaque segment TCP contient un champ **Window Size**. C'est une annonce faite par le récepteur : _"Voici l'espace (en octets) qu'il me reste dans mon buffer de réception"_.
+
+L'émetteur a le droit d'envoyer des données tant que la somme des octets non acquittés est inférieure à cette valeur. C'est ce qu'on appelle la **Fenêtre Glissante**.
+
+#### **A. TCP Window Full (Côté Émetteur)**
+
+C'est une alerte Wireshark qui indique que l'émetteur a épuisé le quota autorisé par le récepteur.
+
+- **Conséquence :** L'émetteur s'arrête net et attend un acquittement avant de renvoyer quoi que ce soit.
+    
+- **Diagnostic :** C'est souvent le signe que le réseau est très rapide, mais que le récepteur (ou l'application) ne suit pas la cadence.
+    
+
+#### **B. TCP Zero Window (Côté Récepteur)**
+
+Le récepteur envoie un segment avec une **Window Size = 0**.
+
+- **Signification :** _"Stop ! Mon buffer est totalement plein. Ne m'envoie plus un seul octet."_ * **Cause :** L'application (ex: un serveur de base de données ou un navigateur) est figée ou traite les données moins vite que le système d'exploitation ne les reçoit.
+    
+
+---
+
+### 2. Le déblocage : Window Update et Keep-Alive
+
+Une connexion ne peut pas rester indéfiniment à l'arrêt. TCP utilise deux mécanismes pour relancer la machine :
+
+- **Window Update :** Dès que l'application a libéré de l'espace dans le buffer, le récepteur envoie spontanément un segment (souvent sans données) avec une nouvelle valeur de fenêtre positive. C'est le signal de reprise : _"C'est bon, j'ai à nouveau 16 Ko de place !"_
+    
+- **TCP Keep-Alive (et Zero Window Probe) :** Si le message "Window Update" est perdu en chemin, la connexion resterait bloquée à jamais. Pour éviter cela, l'émetteur envoie régulièrement de petits segments de test (Keep-Alive) pour forcer le récepteur à répondre et à renvoyer son état de fenêtre actuel. Il est utile de préciser que c'est l'**émetteur** qui prend l'initiative du "Probe" (sonde) pour éviter un interblocage (_deadlock_) si le paquet "Window Update" du récepteur est perdu. Sans cela, les deux resteraient à attendre indéfiniment.
+    
+
+---
+
+### 3. Synthèse des états de saturation
+
+| **Message Wireshark** | **Qui parle ?** | **Signification**                                        |
+| --------------------- | --------------- | -------------------------------------------------------- |
+| **TCP Window Full**   | L'Émetteur      | "J'ai atteint la limite que tu m'as fixée, je m'arrête." |
+| **TCP Zero Window**   | Le Récepteur    | "Je suis saturé, ne m'envoie plus rien."                 |
+| **Window Update**     | Le Récepteur    | "J'ai vidé mon buffer, tu peux reprendre l'envoi."       |
+| **TCP Keep-Alive**    | L'Émetteur      | "Es-tu toujours là ? Ta fenêtre est-elle toujours à 0 ?" |
+
+---
+
+### Analyse de performance : Le "BDP" (Bandwidth-Delay Product)
+
+Pour un administrateur, la taille de la fenêtre est vitale. Si votre fenêtre est trop petite par rapport à la latence (ping) du réseau, vous ne pourrez jamais atteindre le débit maximal de votre fibre, même si le lien est vide. C'est ici que l'option **Window Scale** (vue au chapitre précédent) devient indispensable pour "gonfler" artificiellement la fenêtre au-delà de 64 Ko.
+
+## 5. La Terminaison de Connexion — Dire au revoir (ou raccrocher au nez)
+
+Une fois les données transférées, TCP doit libérer les ressources (mémoire, ports, sockets) utilisées par la session. Contrairement à l'ouverture qui se fait en 3 étapes, la fermeture "propre" nécessite généralement **4 étapes**, car TCP est un protocole **Full-Duplex** : chaque sens de communication doit être fermé indépendamment.
+
+---
+
+### 1. La Fermeture Propre : Le "Four-Way Handshake" (FIN)
+
+Lorsque l'une des applications (souvent le client) a fini d'envoyer ses données, elle initie une procédure de fermeture élégante en utilisant le flag **FIN** (_Finish_).
+
+1. **FIN (Client → Serveur) :** "J'ai fini d'envoyer mes données, je souhaite fermer mon sens de communication."
+    
+2. **ACK (Serveur → Client) :** "Bien reçu, je prends note que tu ne m'enverras plus rien."
+    
+    > _À ce stade, la connexion est dans un état "Semi-fermé". Le serveur peut encore envoyer des données s'il en a en attente._
+    
+3. **FIN (Serveur → Client) :** "De mon côté aussi, j'ai terminé."
+    
+4. **ACK (Client → Serveur) :** "Parfait, nous sommes d'accord. Adieu."
+    
+
+---
+
+### 2. La Fermeture Brutale : Le Reset (RST)
+
+Parfois, la politesse n'est plus de mise. Le flag **RST** (_Reset_) est utilisé pour interrompre immédiatement une connexion sans attendre d'acquittement. C'est l'équivalent de raccrocher le téléphone brusquement.
+
+#### **Les causes d'un paquet RST :**
+
+- **Port fermé :** Vous tentez de vous connecter à un port (ex: 8080) où aucun service n'écoute. Le serveur répond par un `RST`.
+    
+- **Crash applicatif :** L'application qui gérait la connexion a planté. Le système d'exploitation envoie un `RST` pour nettoyer la session devenue orpheline.
+    
+- **Action d'un Pare-feu (Firewall) :** Un équipement de sécurité décide de couper une connexion jugée suspecte ou interdite.
+    
+- **Incohérence de séquence :** TCP reçoit un paquet qui ne correspond à aucune session active ou dont le numéro de séquence est totalement aberrant.
+    
+
+---
+
+### 3. Comparaison : FIN vs RST
+
+|Caractéristique|FIN (Fermeture Propre)|RST (Fermeture Brutale)|
+|---|---|---|
+|**Analogie**|"Au revoir, à la prochaine."|"Erreur fatale, on coupe tout !"|
+|**Données en transit**|Sont transmises et acquittées avant l'arrêt.|Sont perdues immédiatement.|
+|**État Wireshark**|Suite logique de `FIN`, `ACK`, `FIN`, `ACK`.|Un seul paquet rouge marqué `[RST]`.|
+|**Utilisation**|Fin normale d'un transfert HTTP, FTP, etc.|Rejet de connexion, timeout sévère, sécurité.|
+
+Exporter vers Sheets
+
+---
+
+### 4. L'état critique : TIME_WAIT
+
+Après avoir envoyé le dernier `ACK`, l'initiateur de la fermeture ne libère pas son port immédiatement. Il entre dans l'état **TIME_WAIT**.
+
+- **Pourquoi ?** Pour s'assurer que le dernier `ACK` est bien arrivé au destinataire et pour éviter qu'un paquet "égaré" d'une ancienne session ne vienne perturber une nouvelle connexion qui réutiliserait le même port.
+
+---
+
+## Synthèse : Le Code de Communication TCP (Les Flags)
+
+Les flags sont des bits de 1 (activé) ou 0 (désactivé) situés dans l'en-tête TCP. Ils dictent la nature du segment envoyé.
+
+### 1. Les "Bâtisseurs" (Ouverture)
+
+- **SYN (Synchronize) :** Utilisé uniquement lors de l'établissement de la connexion. Il indique l'intention de synchroniser les numéros de séquence (**ISN**).
+    
+- **ACK (Acknowledgment) :** Le flag le plus courant. Une fois la connexion établie, presque tous les paquets l'ont activé pour confirmer la réception des données précédentes.
+    
+
+### 2. Les "Transporteurs" (Transfert)
+
+- **PSH (Push) :** Demande à la pile TCP du récepteur de transmettre immédiatement les données à l'application sans attendre que le buffer de réception soit plein. Très utilisé en SSH ou Telnet pour l'interactivité.
+    
+- **URG (Urgent) :** Indique que certaines données dans le segment sont prioritaires (rarement utilisé aujourd'hui).
+    
+
+### 3. Les "Démolisseurs" (Fermeture)
+
+- **FIN (Finish) :** Fermeture polie. L'émetteur n'a plus rien à dire mais attend que l'autre côté confirme et ferme aussi.
+    
+- **RST (Reset) :** Fermeture brutale. On coupe tout sans préavis suite à une erreur ou un rejet de sécurité.
+    
+
+---
+
+### Tableau Récapitulatif : Diagnostic Rapide
+
+|**Flag(s) visible(s)**|**Interprétation Wireshark**|**Scénario probable**|
+|---|---|---|
+|**SYN**|Tentative de connexion|Début d'un chargement de page Web.|
+|**SYN, ACK**|Acceptation du serveur|Le serveur est prêt à parler.|
+|**ACK**|Confirmation simple|Le transfert se passe bien.|
+|**PSH, ACK**|Envoi de données|L'application envoie un morceau de fichier.|
+|**FIN, ACK**|Demande de fermeture|L'utilisateur ferme l'onglet du navigateur.|
+|**RST**|Rejet / Erreur|Tentative sur un port fermé ou coupure pare-feu.|
+
+---
+
+### 💡 Le Conseil de l'Expert
+
+Lorsqu'on vous donne une suite de paquets à analyser, regardez toujours le **premier flag** :
+
+1. Si c'est un **SYN**, c'est une nouvelle session.
+    
+2. Si vous voyez **RST** dès le début, le service est inaccessible.
+    
+3. Si vous voyez des **Dup ACK** (souvent marqués en noir/rouge dans Wireshark), il y a de la congestion ou des pertes de paquets sur le lien.
+    
+
+---
+
+## Étude de cas : datagramme IPv4
+
+![](Pasted%20image%2020260308142720.png)
+
+Cette image est une représentation classique de l'**en-tête d'un datagramme IPv4**. C'est un document fondamental pour comprendre comment les données circulent sur Internet.
+
+### 1. Structure Générale
+
+L'image montre comment un paquet IP est organisé au niveau binaire.
+
+- **Les Lignes (Words) :** Chaque ligne numérotée de 1 à 6 représente un "mot" de **32 bits** (soit 4 octets).
+    
+- **La Largeur (Bits) :** L'échelle en haut indique la position des bits, de 0 à 31.
+    
+- **Le Header (En-tête) :** Les 5 premières lignes sont obligatoires (20 octets). La 6ème ligne (Options) est facultative.
+    
+- **Data :** Tout ce qui se trouve après l'en-tête est la charge utile (le message réel, souvent un segment TCP ou UDP).
+    
+
+---
+
+## 2. Analyse ligne par ligne
+
+#### Ligne 1 : Contrôle de base
+
+- **Version (4 bits) :** Indique la version du protocole (ici, `4` pour IPv4).
+    
+- **IHL (4 bits) :** _Internet Header Length_. Indique la longueur de l'en-tête. C’est crucial car la zone "Options" peut varier en taille.
+    
+- **Type of Service (8 bits) :** Utilisé pour la qualité de service (QoS), par exemple pour prioriser la voix sur IP (VoIP) par rapport à un email.
+    
+- **Total Length (16 bits) :** La taille totale du paquet (en-tête + données).
+    
+
+#### Ligne 2 : Fragmentation
+
+_C'est ici que l'IP gère les paquets trop gros pour certains réseaux._
+
+- **Identification (16 bits) :** Un numéro unique pour identifier tous les fragments d'un même paquet initial.
+    
+- **Flags (3 bits) :** Permettent de dire "ne pas fragmenter" ou "il y a d'autres fragments après celui-ci".
+    
+- **Fragmentation Offset (13 bits) :** Indique la position exacte de ce fragment dans le message d'origine.
+    
+
+#### Ligne 3 : Durée de vie et Protocole
+
+- **Time to Live (TTL - 8 bits) :** Un compteur de "sauts" (hops) entre routeurs. À chaque routeur, on retire 1. Si ça tombe à 0, le paquet est détruit. Cela évite que des paquets tournent en boucle indéfiniment.
+    
+- **Protocol (8 bits) :** Indique quel protocole de couche supérieure se trouve dans les données (ex: 6 pour TCP, 17 pour UDP, 1 pour ICMP).
+    
+- **Header Checksum (16 bits) :** Un code de vérification pour s'assurer que l'en-tête n'a pas été corrompu pendant le transport.
+    
+
+### Lignes 4 & 5 : L'adressage
+
+- **Source Address (32 bits) :** L'adresse IP de l'expéditeur.
+    
+- **Destination Address (32 bits) :** L'adresse IP du destinataire.
+    
+
+### Ligne 6 : Options et Bourrage
+
+- **Options :** Utilisé très rarement pour des tests ou de la sécurité.
+    
+- **Padding (Padding) :** Comme l'en-tête doit toujours se terminer sur un multiple de 32 bits, on ajoute des zéros si les options sont trop courtes.
+    
+
+---
+
+## 3. Pourquoi est-ce important en Cybersécurité ?
+
+Comprendre ce schéma vous permet de :
+
+1. **Analyser les logs :** Comprendre ce que vous voyez dans un outil comme **Wireshark**.
+    
+2. **Détecter des anomalies :** Un TTL anormalement bas peut indiquer une tentative de cartographie réseau (Traceroute).
+    
+3. **Comprendre l'IP Spoofing :** L'usurpation d'adresse consiste à modifier manuellement le champ _Source Address_.
+    
+
+> **Note aux débutants :** Retenez bien que l'IP ne garantit pas que le message arrive (c'est le rôle de TCP). L'IP s'occupe uniquement de l'adressage et de l'acheminement "au mieux" (_Best Effort_).
+
+## Étude de cas : datagramme TCP
+
+![](Pasted%20image%2020260308143044.png)
+
+On monte d'un étage dans le modèle OSI : après la couche Réseau (IP), voici l'en-tête du segment **TCP (Transmission Control Protocol)**, situé au niveau de la couche **Transport**.
+
+Si l'IP est l'enveloppe avec l'adresse de la maison, le TCP est la lettre recommandée avec accusé de réception qui s'assure que le contenu arrive intact et dans le bon ordre.
+
+---
+
+### 1. Les Ports : L'aiguillage des applications
+
+Contrairement à l'IP qui identifie une machine, le TCP utilise des **ports** pour identifier une application spécifique sur cette machine.
+
+- **Source Port (16 bits) :** Le port utilisé par l'application qui envoie les données (souvent un port aléatoire au-dessus de 1024).
+    
+- **Destination Port (16 bits) :** Le port de l'application réceptrice (ex: 80 pour HTTP, 443 pour HTTPS, 22 pour SSH).
+    
+
+### 2. La Fiabilité : Séquençage et Accusés
+
+C'est ici que réside la "magie" du TCP.
+
+- **Sequence Number (32 bits) :** Chaque octet envoyé reçoit un numéro. Cela permet au destinataire de reconstruire le message dans l'ordre, même si les paquets arrivent dans le désordre.
+    
+- **Acknowledgement Number (32 bits) :** C'est l'accusé de réception. Le récepteur dit : "J'ai bien reçu jusqu'à l'octet X, j'attends maintenant le X+1".
+    
+
+### 3. Gestion et Flux
+
+- **Header Length (4 bits) :** Comme pour l'IP, indique où s'arrête l'en-tête et où commencent les données.
+    
+- **Code Bits / Flags (6 bits) :** Ce sont les "interrupteurs" du TCP. Les plus connus en cyber sont :
+    
+    - **SYN :** Pour établir la connexion.
+        
+    - **ACK :** Pour accuser réception.
+        
+    - **FIN :** Pour terminer proprement la connexion.
+        
+    - **RST :** Pour réinitialiser brutalement une connexion (souvent vu lors d'un scan de port).
+        
+- **Window (16 bits) :** C'est le contrôle de flux. Le récepteur dit : "Ne m'envoie pas plus de X octets à la fois car ma mémoire tampon est pleine".
+    
+
+### 4. Intégrité et Urgence
+
+- **Checksum (16 bits) :** Vérifie que l'en-tête **et** les données n'ont pas été modifiés.
+    
+- **Urgent Pointer (16 bits) :** Très peu utilisé aujourd'hui, il servait à indiquer que certaines données dans le segment devaient être traitées prioritairement.
+    
+
+---
+
+### Le point de vue Cybersécurité 🛡️
+
+Le TCP est au cœur de nombreuses analyses :
+
+- **TCP Connect Scan :** Un attaquant tente d'ouvrir une connexion complète (SYN -> SYN/ACK -> ACK) pour voir si un port est ouvert.
+    
+- **SYN Flood :** Une attaque DoS (Déni de Service) consistant à envoyer des milliers de segments SYN sans jamais répondre au SYN/ACK, saturant ainsi les ressources du serveur.
+    
+- **Détournement de session (Hijacking) :** Si un attaquant arrive à deviner le prochain **Sequence Number**, il peut injecter des données malveillantes dans une connexion existante.
+    
+
+## Étude de cas : Anomalie et Sécurité (Le Scan "Christmas Tree")
+
+Sur cette capture, nous observons un comportement qui contredit tout ce que nous avons vu sur le cycle de vie normal de TCP.
+
+![](Pasted%20image%2020260308135822.png)
+Ce que vous voyez est une **violation flagrante de la RFC 793** (la spécification officielle de TCP).
+
+### 1. L'Anomalie des Flags (Le "Sapin de Noël")
+
+Regardez le cadre rouge dans les détails du paquet 2 :
+
+- **Flags : 0x03b (FIN, SYN, PSH, ACK, URG)**.
+    
+- **Le problème :** Dans une communication normale, ces flags ne sont **jamais** activés tous ensemble. Activer `SYN` (ouverture) et `FIN` (fermeture) simultanément est une contradiction logique pure.
+    
+- **Pourquoi ce nom ?** On l'appelle "Christmas Tree" car, comme un arbre de Noël, le paquet est "éclairé" par tous les flags possibles.
+
+- **Caractériser l'attaque :** C'est un _Xmas Scan_. L'attaquant cherche à contourner les pare-feu qui ne filtrent que les paquets `SYN`. Comme ce paquet n'a pas que le flag `SYN`, certains vieux équipements pourraient le laisser passer.
+    
+
+### 2. Le Comportement du Serveur (Le Reset)
+
+Observez les lignes sur fond rouge (paquets 1, 3, 5, etc.) :
+
+- **Source : 10.0.0.2** (Le serveur) répond systématiquement par un flag **[RST]**.
+    
+- **Interprétation :** Le serveur reçoit un paquet totalement incohérent. Sa pile TCP ne sait pas comment traiter une demande qui veut à la fois "commencer", "pousser des données" et "finir". La plupart des piles TCP répondent `RST` à un paquet invalide non pas par "sécurité", mais par **conformité à la norme**. La RFC 793 stipule qu'un segment arrivant sur une connexion inexistante ou fermée doit générer un `RST`. C'est précisément cette "obéissance" à la norme que l'attaquant exploite pour le fingerprinting.
+    
+
+### 3. Diagnostic de Cybersécurité
+
+Ce que vous voyez ici n'est pas un transfert de données, mais une tentative de **Fingerprinting (Reconnaissance)** :
+
+- Un attaquant envoie ces paquets bizarres pour voir comment le système d'exploitation du serveur réagit.
+    
+- Selon que le serveur répond par un `RST` ou qu'il ignore le paquet (Drop), l'attaquant peut deviner s'il s'agit d'un système Windows, Linux ou d'un pare-feu spécifique.
+    
+Notez que dans un vrai scan de type "Xmas", ce sont généralement les flags `FIN`, `URG` et `PSH` qui sont utilisés (les "lumières" de l'arbre). Le flag `SYN` est souvent **exclu** du scan Xmas classique, car un paquet avec `SYN` est traité différemment par les pare-feu. Si `SYN` est présent avec `FIN`, c'est une variante encore plus agressive.
+
+### 4. Actions Techniques (La Réponse)
+
+#### **A. Au niveau du Pare-feu (Firewall/IPS)**
+
+La meilleure réaction n'est pas de répondre `RST`, mais de devenir **invisible**.
+
+- **Passer en mode "Drop" (ou Deny) :** Configurez votre pare-feu pour qu'il jette silencieusement ces paquets invalides au lieu de laisser le serveur répondre.
+    
+- **Règle de filtrage :** Bloquer toute combinaison de flags TCP qui ne respecte pas la machine à états (ex: `SYN` et `FIN` ensemble, ou aucun flag du tout).
+
+#### **B. Au niveau du Système d'Exploitation (Hardening)**
+
+- **Limitation de débit (Rate Limiting) :** Si vous recevez trop de paquets `RST` ou de tentatives de connexion invalides en une seconde, bannissez temporairement l'IP source (via un outil comme _Fail2Ban_ ou une règle d'IPS).
+    
+- **Mise à jour de la pile TCP :** Les systèmes modernes ignorent ou bloquent mieux ces anomalies, mais une pile réseau mal configurée peut révéler trop d'informations sur sa version via ses réponses.
+
+## Configurer Fail2Ban contre les Scans Anormaux
+
+Pour que Fail2Ban réagisse, il faut d'abord que votre pare-feu (ici `iptables`) enregistre les paquets suspects dans un fichier log (généralement `/var/log/messages` ou `/var/log/syslog`).
+
+### 1. La règle de log (Préalable)
+
+Avant Fail2Ban, on demande au pare-feu de marquer les scans "Christmas Tree" :
+
+```toml
+# Log les paquets avec des combinaisons de flags invalides
+iptables -A INPUT -p tcp --tcp-flags ALL FIN,SYN,PSH,ACK,URG -j LOG --log-prefix "TCP-XMAS-SCAN: "
+```
+
+### 2. Le filtre Fail2Ban (`/etc/fail2ban/filter.d/tcp-scans.conf`)
+
+Ce fichier définit ce que Fail2Ban doit chercher dans les logs. On utilise une expression régulière (regex) pour repérer le préfixe que nous avons créé.
+
+```toml
+[Definition]
+# On cherche l'IP source (SRC=...) associée à notre préfixe de log
+failregex = TCP-XMAS-SCAN: .* SRC=<HOST>
+ignoreregex =
+```
+
+### 3. La "Jail" Fail2Ban (`/etc/fail2ban/jail.local`)
+
+C'est ici que l'on définit la punition (le bannissement).
+
+```toml
+[tcp-xmas-protection]
+enabled  = true
+filter   = tcp-scans
+logpath  = /var/log/messages
+port     = all
+# Si on détecte 3 tentatives (maxretry) en 1 minute (findtime)
+findtime  = 60
+maxretry  = 3
+# On bannit l'IP pendant 1 heure
+bantime   = 3600
+action    = iptables-multiport[name=TCP-XMAS, port="all", protocol=tcp]
+```
+
+
+- **Réactivité :** Dès que l'attaquant dépasse le seuil de 3 paquets suspects (comme on le voit sur votre capture où il y a plus de 10 échanges en 0.1 seconde), il est coupé.
+    
+- **Dissuasion :** Le `bantime` de 1 heure décourage les outils de scan automatisés qui cherchent des cibles faciles.
+    
+- **Protection des ressources :** En bannissant au niveau du pare-feu, le serveur ne perd plus de temps à générer des paquets `RST`, ce qui économise du CPU et de la bande passante.
+    
+
+| Étape         | Outil      | Rôle                                                        |
+| ------------- | ---------- | ----------------------------------------------------------- |
+| **Détection** | `iptables` | Identifie les flags anormaux et écrit dans le log.          |
+| **Analyse**   | `Fail2Ban` | Compte le nombre d'alertes par IP dans le temps.            |
+| **Sanction**  | `iptables` | Ajoute une règle de blocage automatique pour l'IP coupable. |
+
+### Synthèse de la posture de sécurité
+
+|Type de Réponse|Effet sur l'Attaquant|Recommandation|
+|---|---|---|
+|**Le serveur répond RST** (ce qu'on voit sur l'image)|L'attaquant sait que le serveur est **actif** mais que le port est peut-être fermé ou protégé.|**Moyen.** On donne trop d'infos.|
+|**Le Firewall "Drop" (silence)**|L'attaquant ne reçoit rien. Il ne sait pas si le serveur existe ou si le paquet a été perdu.|**Excellent.** C'est la posture de "discrétion".|
+|**Bannissement (Blacklist)**|L'IP de l'attaquant est bloquée pour 24h sur tous les services.|**Idéal.** Pour stopper la reconnaissance.|
+
+---
+
--- a/articles/2026/utiliser
+++ b/articles/2026/utiliser
@@ -0,0 +1,286 @@
+---
+title: "Utiliser PGP sous Linux : Signez vos fichiers avec Thunderbird"
+description: "Apprenez à utiliser votre clé OpenPGP Thunderbird pour signer des fichiers (PDF, archives) sous Linux. Guide complet : export, import GPG et signature détachée."
+tags: [OpenPGP, Thunderbird, Linux, GPG]
+date: 2026-03-13 08:36
+lastmod: 2026-03-13 09:01
+type:
+  - article
+category:
+  - "[[Guide]]"
+status: brouillon
+---
+
+# Utiliser PGP sous Linux : Signez vos fichiers avec Thunderbird
+
+## Introduction
+
+Imaginez que vous puissiez apposer un sceau de cire inviolable sur chacun de vos documents numériques, garantissant à la fois votre identité et l'intégrité de vos fichiers. Longtemps réservée aux experts de la cryptographie, cette sécurité — portée par le standard **OpenPGP** — est désormais à la portée de tous.
+
+Si vous utilisez **Thunderbird**, vous détenez peut-être déjà cette puissance sans le savoir. Depuis sa version 78, le célèbre client mail a intégré nativement les outils de chiffrement, transformant une configuration autrefois laborieuse en une simple formalité.
+
+### Pourquoi sauter le pas aujourd'hui ?
+
+Posséder une clé GPG dans Thunderbird, c'est un peu comme avoir un stylo plume de haute sécurité : c'est élégant, c'est gratuit, et cela devient vite indispensable une fois qu'on a goûté à la tranquillité d'esprit qu'elle procure. Si votre clé n'est pas encore créée, c'est le moment idéal pour forger votre identité numérique.
+
+Avant de passer à la signature concrète de vos fichiers, assurons-nous que votre arsenal est prêt. Voici comment vérifier en un clin d'œil si votre clé sommeille déjà dans les réglages de Thunderbird.
+
+## Vérifier la présence de votre clé dans Thunderbird
+
+Avant de passer à la pratique, la première question à se poser est simple : Thunderbird a-t-il déjà une clé en mémoire pour vous ? Depuis que le logiciel gère OpenPGP par défaut, il se peut que vous en ayez configuré une sans même vous en souvenir.
+
+Pour voir si une clé est déjà associée à votre compte :
+
+1. Ouvrez Thunderbird et allez dans les **Paramètres du compte** (clic droit sur votre adresse mail dans la colonne de gauche).
+    
+2. Dans le menu latéral, cliquez sur **Chiffrement de bout en bout**.
+    
+3. Regardez la section **OpenPGP**.
+    
+    - Si vous voyez une suite de chiffres et de lettres (une "empreinte" ou Fingerprint) sous "Technologies de chiffrement", c'est que vous avez déjà une clé configurée.
+        
+    - Si c'est vide, vous n'avez pas encore de clé active pour ce compte.
+        
+
+## Gérer vos clés (Le gestionnaire OpenPGP)
+
+Une fois votre clé identifiée, vous pouvez en gérer les détails via le **Gestionnaire de clés OpenPGP**. C'est ici que Thunderbird centralise vos propres clés et celles de vos correspondants.
+
+Pour y accéder :
+
+1. Allez dans le menu principal (les trois barres horizontales **≡**).
+    
+2. Sélectionnez **Outils** puis **Gestionnaire de clés OpenPGP**.
+    
+
+## Créer votre première clé OpenPGP
+
+Pour générer votre identité numérique directement dans Thunderbird, suivez ces étapes :
+
+1. **Lancez l'assistant :** Retournez dans les **Paramètres du compte** > **Chiffrement de bout en bout**.
+    
+2. **Ajouter une clé :** Cliquez sur le bouton **Ajouter une clé...**.
+    
+3. **Générer :** Sélectionnez l'option **Créer une nouvelle clé OpenPGP** puis cliquez sur **Continuer**.
+    
+4. **Configuration :**
+    
+    - **Identité :** Vérifiez que votre adresse e-mail est la bonne.
+        
+    - **Validité :** Par défaut, Thunderbird propose une durée de 3 ans. Vous pouvez la modifier selon vos besoins.
+        
+    - **Paramètres avancés :** Le type de clé par défaut (ECC) est moderne et recommandé.
+        
+5. **Confirmer :** Cliquez sur **Générer la clé**. Une fenêtre de confirmation apparaîtra : validez pour terminer l'opération.
+    
+
+### À savoir après la création
+
+Une fois la clé générée, elle apparaît avec son **empreinte numérique** dans vos paramètres. Thunderbird gère désormais cette clé en interne.
+
+Cependant, comme nous l'avons vu précédemment, cette clé reste pour l'instant confinée au logiciel de messagerie. Pour l'utiliser avec la commande `gpg` dans votre terminal et signer des fichiers locaux, il faudra passer par l'étape d'exportation.
+
+## Le cloisonnement des clés
+
+Il est important de noter une distinction technique : **Thunderbird et votre système d'exploitation ne partagent pas la même base de données.**
+
+- **Thunderbird** utilise son propre stockage interne.
+    
+- **Le terminal (la commande `gpg`)** utilise généralement le dossier système `~/.gnupg`.
+    
+
+Par défaut, ces deux environnements sont étanches. Si vous souhaitez utiliser une clé créée dans Thunderbird pour signer des fichiers via votre terminal, il est nécessaire de créer un pont : vous devrez **exporter la clé** depuis Thunderbird pour l'**importer** manuellement dans votre trousseau système.
+
+## Exporter la clé vers le système
+
+Pour que vos commandes `gpg` (comme `--clearsign`) fonctionnent dans votre terminal, vous devez extraire la clé de Thunderbird pour l'intégrer à votre trousseau système.
+
+### Côté Thunderbird
+
+L'objectif est de créer un fichier temporaire contenant votre identité numérique :
+
+- Allez dans **Outils** > **Gestionnaire de clés OpenPGP**.
+    
+- Faites un **clic droit** sur votre clé personnelle.
+    
+- Choisissez **Exporter la ou les clés secrètes vers un fichier**.
+    
+- Enregistrez le fichier sous le nom `ma_cle_privee.asc`.
+    
+
+> **Attention :** Ce fichier est extrêmement sensible. Il contient votre clé secrète. Ne le partagez jamais et ne l'envoyez pas par e-mail.
+
+###  Côté Terminal
+
+Il faut maintenant importer ce fichier dans votre environnement GPG système :
+
+- Ouvrez votre terminal et lancez la commande suivante :
+    
+    ```Bash
+    gpg --import ma_cle_privee.asc
+    ```
+    
+- Une fois l'importation réussie, **supprimez immédiatement le fichier .asc** pour ne pas laisser traîner une copie de votre clé secrète sur votre disque dur.
+    
+
+### Vérification
+
+Pour confirmer que la manipulation a fonctionné, demandez à GPG la liste des clés privées disponibles :
+
+```Bash
+gpg --list-secret-keys
+```
+
+Si votre nom et votre adresse e-mail s'affichent, votre terminal est désormais prêt à signer des documents avec votre clé Thunderbird.
+
+## Signer vos fichiers sans les modifier
+
+Maintenant que votre terminal reconnaît votre clé Thunderbird, vous pouvez signer n'importe quel document (un PDF, une image ou une archive) sans toucher au fichier original. Pour cela, nous allons utiliser la méthode de la **signature détachée**.
+
+### La commande de signature
+
+Ouvrez votre terminal dans le dossier où se trouve votre document et lancez la commande suivante :
+
+```Bash
+gpg --armor --detach-sign mon_fichier.pdf
+```
+
+### Le résultat : deux fichiers valent mieux qu'un
+
+Après avoir saisi votre mot de passe (celui de votre clé Thunderbird), GPG va générer un second fichier nommé `mon_fichier.pdf.asc`.
+
+- **Le fichier original :** `mon_fichier.pdf` reste intact et parfaitement lisible par n'importe quel lecteur PDF.
+    
+- **La signature :** `mon_fichier.pdf.asc` est un petit fichier texte qui contient la preuve mathématique de l'authenticité du premier.
+    
+
+Cette technique est idéale pour le partage de documents officiels ou techniques :
+
+1. **Intégrité préservée :** Vous ne modifiez pas l'octet de votre fichier source.
+    
+2. **Liberté pour le destinataire :** Votre correspondant télécharge le fichier original normalement. S'il souhaite vérifier que vous en êtes bien l'auteur, il lui suffit d'utiliser le petit fichier `.asc` joint.
+    
+3. **Compatibilité totale :** Cela fonctionne avec tous les types de fichiers, pas seulement le texte.
+
+## Comment votre destinataire vérifie-t-il la signature ?
+
+Une fois que vous avez envoyé le fichier original (`mon_fichier.pdf`) et sa signature (`mon_fichier.pdf.asc`), votre correspondant peut vérifier l'intégrité du document en une seule commande.
+
+### La commande de vérification
+
+Le destinataire doit placer les deux fichiers dans le même dossier et taper :
+
+```Bash
+gpg --verify mon_fichier.pdf.asc mon_fichier.pdf
+```
+
+### Comprendre le résultat
+
+Le terminal renverra alors un message indiquant l'état de la signature :
+
+1. **"Bonne signature" (Good signature) :** C'est le signal vert. Le fichier est exactement celui que vous avez signé, aucun octet n'a été modifié. Le terminal affichera également votre nom et votre adresse e-mail.
+    
+2. **"MAUVAISE signature" (BAD signature) :** Alerte rouge. Soit le fichier a été altéré après votre signature (corruption de données ou tentative de modification), soit la signature ne correspond pas à ce document.
+    
+
+### Une précision importante : la confiance
+
+Si c'est la première fois que votre correspondant vérifie l'une de vos signatures, il verra probablement un message d'avertissement indiquant que la clé n'est pas "certifiée par une autorité de confiance".
+
+C'est normal : cela signifie simplement que GPG a bien vérifié la **validité mathématique** de la signature, mais qu'il ne peut pas encore confirmer à 100 % que cette clé appartient bien à "Jean Dupont" sans une étape supplémentaire de certification. Pour un usage courant et grand public, le message "Bonne signature" est déjà la preuve que le fichier n'a pas été piraté.
+
+## Partager votre clé publique
+
+La clé publique est votre "carte d'identité numérique". Sans elle, votre ami peut voir que le fichier est signé, mais il ne peut pas prouver que c'est _vous_ qui l'avez signé.
+
+### Exporter la clé publique depuis Thunderbird
+
+Le processus est presque identique à l'export de la clé secrète, mais sans le danger :
+
+1. Retournez dans **Outils** > **Gestionnaire de clés OpenPGP**.
+    
+2. Faites un clic droit sur votre clé.
+    
+3. Choisissez cette fois : **Exporter la ou les clés publiques vers un fichier**.
+    
+4. Enregistrez-le sous le nom `ma_cle_publique.asc`.
+    
+
+### Envoyer la clé
+
+Vous pouvez maintenant envoyer ce fichier `.asc` à votre ami par e-mail, par messagerie instantanée, ou même le publier sur votre site web. Il n'y a aucun risque de sécurité à diffuser ce fichier.
+
+### Côté destinataire : l'importation
+
+Pour que votre ami puisse vérifier vos futurs documents, il doit intégrer votre clé à son propre système. Il lui suffit d'ouvrir son terminal et de taper :
+
+```Bash
+gpg --import ma_cle_publique.asc
+```
+
+Une fois cette manipulation faite, son ordinateur "connaît" officiellement votre identité numérique. Désormais, chaque fois qu'il lancera la commande `gpg --verify` sur l'un de vos fichiers, le terminal ne se contentera plus de dire que la signature est mathématiquement correcte : il affichera explicitement votre nom, confirmant que le document provient bien de vous.
+
+## Vérifier l'identité : Le "Fingerprint" (Empreinte)
+
+Envoyer une clé par e-mail, c'est bien, mais comment votre ami peut-il être sûr qu'un pirate n'a pas intercepté l'envoi pour remplacer votre clé par la sienne ? Pour lever le doute, on utilise l'**empreinte numérique** (le _Fingerprint_).
+
+### La rencontre de vive voix (Le top de la sécurité)
+
+Si vous voyez votre ami physiquement, c'est la méthode infaillible.
+
+- Ouvrez chacun votre terminal ou votre gestionnaire Thunderbird.
+    
+- Comparez de vive voix la suite de chiffres et de lettres qui compose l'**empreinte** de votre clé.
+    
+- Si les deux suites sont identiques, votre ami peut "signer" votre clé sur son ordinateur pour confirmer qu'il vous fait confiance à 100 %.
+    
+
+### Le croisement des canaux (La méthode pratique)
+
+Si vous ne pouvez pas vous voir, utilisez la stratégie du **multicanal**. C'est une technique simple pour éviter les interceptions :
+
+- Envoyez le fichier de votre clé (`.asc`) par **e-mail**.
+    
+- Envoyez l'empreinte de la clé (le texte court de 40 caractères) via un **autre canal** : un SMS, une boucle Signal/WhatsApp, ou même l'afficher sur votre profil LinkedIn ou votre site personnel.
+    
+
+Si un attaquant parvient à pirater votre boîte mail, il peut remplacer votre fichier de clé. Mais il est extrêmement improbable qu'il puisse _aussi_ pirater votre téléphone pour modifier le SMS que vous envoyez au même moment.
+
+En comparant l'empreinte reçue par mail avec celle reçue par SMS, votre ami a la certitude absolue qu'il possède votre **véritable identité numérique**.
+
+## Comment afficher une empreinte
+
+L'empreinte est une suite unique de 40 caractères qui résume votre clé. C'est elle que vous devez comparer avec votre ami.
+
+### Option 1 : Via l'interface de Thunderbird
+
+C'est la méthode la plus simple pour la lire à haute voix ou faire une capture d'écran :
+
+1. Allez dans **Paramètres du compte** > **Chiffrement de bout en bout**.
+    
+2. Sous la section **OpenPGP**, vous verrez directement votre clé s'afficher avec une suite de caractères du type : `0x1234 5678 90AB...`
+    
+3. Cliquez sur **Détails de la clé** pour l'afficher en grand et pouvoir la copier-coller.
+    
+
+### Option 2 : Via le Terminal (plus rapide pour un copier-coller)
+
+Si vous avez déjà importé votre clé dans votre système (comme vu précédemment), tapez simplement cette commande :
+
+```Bash
+gpg --fingerprint votre@email.com
+```
+
+Le terminal affichera alors un bloc d'informations. La ligne qui nous intéresse est celle intitulée **Empreinte de la clé** (ou _Key fingerprint_). Elle ressemble à ceci : `A1B2 C3D4 E5F6 G7H8 I9J0 K1L2 M3N4 O5P6 Q7R8 S9T0`
+
+---
+
+## Le test de vérité
+
+Une fois que vous avez cette suite de caractères, transmettez-la à votre ami (par SMS, Signal, ou de vive voix). Votre ami, de son côté, tape la même commande sur son ordinateur :
+
+```Bash
+gpg --fingerprint votre@email.com
+```
+
+**Si les deux suites sont rigoureusement identiques, la sécurité est totale.** Votre ami sait que la clé publique qu'il a importée est bien la vôtre, et non celle d'un imposteur.
--- a/20260308135822.png
+++ b/20260308135822.png
--- a/20260308142720.png
+++ b/20260308142720.png
--- a/20260308142917.png
+++ b/20260308142917.png
--- a/20260308143044.png
+++ b/20260308143044.png
--- a/20260308171916.png
+++ b/20260308171916.png
--- a/20260308172102.png
+++ b/20260308172102.png
--- a/20260313124448.png
+++ b/20260313124448.png
Author	SHA1	Message	Date
Cédrix	036bd6c995	add gscan2pdf : 2026-03-13 12:45:33	2026-03-13 12:45:33 +01:00
Cédrix	e50f900ba9	vault backup: 2026-03-13 09:01:21	2026-03-13 09:01:21 +01:00
Cédrix	ed2a6e0ab2	vault backup: 2026-03-12 21:19:17	2026-03-12 21:19:17 +01:00
Cédrix	0d66cc8991	vault backup: 2026-03-12 20:49:17	2026-03-12 20:49:17 +01:00
Cédrix	e177166362	vault backup: 2026-03-11 18:41:56	2026-03-11 18:41:56 +01:00
Cédrix	c0b6d77a42	vault backup: 2026-03-11 18:28:18	2026-03-11 18:28:18 +01:00
Cédrix	d9b5947a3d	vault backup: 2026-03-11 01:42:22	2026-03-11 01:42:22 +01:00
Cédrix	8330c2ff9e	vault backup: 2026-03-11 00:42:21	2026-03-11 00:42:21 +01:00
Cédrix	6b38351bc6	vault backup: 2026-03-10 08:14:50	2026-03-10 08:14:50 +01:00
Cédrix	1158950ba6	vault backup: 2026-03-10 08:12:18	2026-03-10 08:12:18 +01:00
Cédrix	5ffb7346bf	vault backup: 2026-03-10 07:59:48	2026-03-10 07:59:48 +01:00
Cédrix	081fcafcfb	vault backup: 2026-03-10 07:51:11	2026-03-10 07:51:11 +01:00
Cédrix	2f3b27e894	vault backup: 2026-03-08 21:46:41	2026-03-08 21:46:41 +01:00
Cédrix	237f95b0cb	vault backup: 2026-03-08 21:16:41	2026-03-08 21:16:41 +01:00
Cédrix	4c253e2ce5	vault backup: 2026-03-08 18:46:36	2026-03-08 18:46:37 +01:00
Cédrix	67bfdd7378	vault backup: 2026-03-08 18:16:35	2026-03-08 18:16:35 +01:00
Cédrix	7776689c23	vault backup: 2026-03-08 17:46:34	2026-03-08 17:46:34 +01:00
Cédrix	c27a1fae2e	vault backup: 2026-03-08 17:16:34	2026-03-08 17:16:34 +01:00
Cédrix	bd17601b11	add tcp article: 2026-03-08 14:35:24	2026-03-08 14:35:24 +01:00
Cédrix	6b7b830b78	vault backup: 2026-03-08 14:35:16	2026-03-08 14:35:16 +01:00
Cédrix	a9f7dac640	vault backup: 2026-03-08 14:05:16	2026-03-08 14:05:16 +01:00