Catégorie : PHASE 1 : Hardening du Serveur

Ce que j’ai fait

1. Pourquoi UFW ?

Un serveur exposé sur Internet a tous ses ports accessibles par défaut. N’importe qui peut tenter de se connecter sur n’importe quel service.

UFW (Uncomplicated Firewall) permet de fermer tous les ports par défaut et de n’ouvrir que ceux dont on a besoin.

2. Installation

# Installation de UFW
sudo apt install ufw -y

3. Configuration

Avant d’ouvrir quoi que ce soit, on bloque tout le trafic entrant et on autorise le trafic sortant.

# Bloquer tout le trafic entrant
sudo ufw default deny incoming

# Autoriser tout le trafic sortant
sudo ufw default allow outgoing

Pourquoi bloquer le trafic entrant mais autorisé le trafic sortant ?

Car si mon serveur a initié une connexion sortante, alors les réponses entrantes à cette connexion sont automatiquement autorisées. c’est un Pare-feu intelligent.

J’ai ensuite ouvert uniquement les ports dont j’ai besoin :

# Autoriser SSH sur mon port personnalisé
sudo ufw allow ****/tcp

# Autoriser HTTP (pour le site web)
sudo ufw allow 80/tcp

# Autoriser HTTPS (pour le site web sécurisé)
sudo ufw allow 443/tcp

⚠️ Étape critique : il faut absolument autoriser le port SSH avant d’activer UFW, sinon on se retrouve complétement bloquer sans possibilité sans possibilité de se reconnecter.

4. Activation

# Activer le pare-feu
sudo ufw enable

# Vérifier les règles en place
sudo ufw status verbose

Résultat attendu :

Status: active

To                         Action      From
--                         ------      ----
****/tcp                   ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere

Seuls les ports que j’ai choisis sont ouverts. Tout le reste est bloqué.

5. Pour aller plus loin

# Supprimer une règle (exemple : fermer le port 80)
sudo ufw delete allow 80/tcp

# Voir les règles numérotées (utile pour supprimer une règle précise)
sudo ufw status numbered

# Supprimer une règle par son numéro
sudo ufw delete [numero]

UFW travaille en complément de Fail2Ban : le pare-feu filtre les ports autorisés, et Fail2Ban bannit les IP qui abusent sur ces ports.

Ce que j’ai fait

1. Pourquoi Fail2Ban ?

Même avec une clé SSH et un port personnalisé, des bots continuent de tenter des connexions sur le serveur.

Fail2Ban surveille les logs en temps réel et bannit automatiquement les IP qui échouent trop de fois.

2. Installation

# Installation de Fail2Ban
sudo apt install fail2ban -y

3. Configuration

Fail2Ban utilise deux fichiers :

• jail.conf → fichier par défaut
• jail.local → fichier qui contient les règles de bannissement

# Éditer le fichier de configuration
sudo nano /etc/fail2ban/jail.local

J’ai modifié la section [DEFAULT] pour l’adapter à ce dont j’avais besoin.

# Durée de bannissement
bantime  = 1h

# Fenêtre d'observation
findtime = 10m

# Nombre de tentatives avant ban
maxretry = 3

J’ai également dû modifier la section [sshd] car le port utilisé dessus ne correspond plus à celui que j’utilise.

[sshd]
enabled = true
port    = ****
filter  = sshd
logpath = /var/log/auth.log

Les différentes sections sont aussi appelées des « jails » qu’on peut activer ou désactiver (enabled = true/false) et qui ici sont toutes en relation avec la section [DEFAULT] pour les bannissements.

Cela aura pour effet que si une personne ou un bot essaie 3 fois de se connecter sur n’importe quel port où une jail est active et échoue 3 fois sur une période de 10 minutes, alors il sera banni 1h.

4. Application

# Redémarrer pour appliquer les modifications
sudo systemctl restart fail2ban

# Vérifier que la jail SSH est active
sudo fail2ban-client status

5. Pour aller plus loin

# Détail de la jail SSH (IP bannies, tentatives échouées...)
sudo fail2ban-client status sshd

# Débannir une IP manuellement
sudo fail2ban-client set sshd unbanip 1.2.3.4

# Voir les tentatives échouées dans les logs
sudo grep "Failed" /var/log/auth.log | tail -10

Fail2Ban pourra également être utilisé pour sécuriser n’importe quel service que je mettrai en place sur mon serveur en créant/modifiant des jails.

Sécurisation et mise en place du serveur debain :

Ce que j’ai fait

1. Création d’un utilisateur non-root

Pourquoi ?

Le compte root, ayant les permissions absolues, représente une menace en cas de faille de sécurité.

J’ai donc créé un utilisateur avec les droits sudo, puis j’ai désactivé la connexion root.

# Créer un nouvelle utilisateur
adduser "user"

# Donne les permissions sudo a l'utilisateur
usermod -aG sudo "user" 

# affiche les groups d'un utilisateur
groups "user"

Une fois l’utilisateur créer je me connecte en ssh avec et je désactive la possibilité de se connecter avec root.

sudo nano /etc/ssh/sshd_config

-> PermitRootLogin no

2. Authentification par clé SSH Ed25519

J’ai remplacé l’authentification par mot de passe par une paire de clés SSH afin d’améliorer la sécurité et de mieux se protéger contre les bots.

Pourquoi est-ce plus sécurisé ?

Les bots tentent généralement des attaques par brute force en essayant des mots de passe.
Avec une clé Ed25519, la connexion nécessite :

Une phrase de passe (passphrase) qui protège la clé privée

La présence de la clé privée sur la machine cliente

La clé publique correspondante sur le serveur

# Générer la paire de clés dans POWERSHELL
ssh-keygen -t ed25519 -C "user@IP_SERVEUR" -f "$env:USERPROFILE\.ssh\id_ed25519_srv"

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): ********
Your identification has been saved in C:\Users\"user"\.ssh\id_ed25519_srv
Your public key has been saved in C:\Users\"user"\.ssh\id_ed25519_srv.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx user@IP_SERVEUR

Deux clés sont alors générées :

Clé privée (à conserver sur sa machine) :

id_ed25519_srv

Clé publique (à copier sur le serveur) :

id_ed25519_srv.pub

Préparation du serveur :

# Création du dossier
mkdir -p /home/"user"/.ssh 

# Création du fichier qui aura les clés autorisé
touch /home/"user"/.ssh/authorized_keys

Une fois le répertoire préparé, j’envoie la clé publique sur le serveur.

# Envoyer la clé publique vers le serveur
scp "$env:USERPROFILE\.ssh\id_ed25519_srv.pub" "user"@IP_SERVEUR:/home/"user"/.ssh/uploaded_key.pub

# Ajouter la clé publique aux clés autorisées
cat /home/"user"/.ssh/uploaded_key.pub >> /home/"user"/.ssh/authorized_keys

# Supprimer le fichier temporaire
rm /home/"user"/.ssh/uploaded_key.pub

# Vérifier le contenu
cat /home/"user"/.ssh/authorized_keys

3. Modification de la configuration SSH

Pour l’instant, les changements n’ont pas encore d’impact sur la méthode de connexion.
Il faut modifier la configuration SSH pour la sécuriser davantage.

# Modifier la configuration
sudo nano /etc/ssh/sshd_config


J'ai modifié les lignes suivante :

# Changement du port ssh basique de 22 a **** car le port 22 est une cible privilégié 
Port ****

# Connexion par mot de passe désactivé
PasswordAuthentication no

# Connexion par clé activé
PubkeyAuthentication yes

# Répertoire ou trouver les clés autorisé
AuthorizedKeysFile .ssh/authorized_keys

# Vérifier que la config SSH n'a pas de faute de syntaxe
sudo sshd -t

⚠️ C’est la partie critique.

Pour appliquer les modifications, il faut redémarrer le service SSH.
En cas d’erreur de configuration, la connexion SSH pourrait devenir inutilisable.

Démarche a suivre :

Fermer le premier terminal uniquement si la connexion fonctionne

Garder le premier terminal ouvert

Redémarrer le service SSH

Tester la connexion depuis un second terminal

# Redémarrer le service SSH
sudo systemctl restart sshd

# Dans un nouveau terminal ⚠️
ssh -i "$env:USERPROFILE\.ssh\id_ed25519_srv" -p**** "user"@IP_SERVEUR

Cette fois-ci, une phrase de passe est demandée (et non plus un mot de passe).

4. Pour aller plus loin.

# Tentative de connexion en root
ssh -p**** root@IP_SERVEUR

# Forcer la connexion par mot de passe
ssh -p**** -o PubkeyAuthentication=no "user"@IP_SERVEUR