SSH et Firewall

La gestion d'un serveur peut faire peur (et c'est bien d'avoir peur, ça permet de faire les choses de façon sécurisée), mais la peur n'évite pas le danger, par contre on peut réduire le risque.

Un serveur, par le seul fait d'être en ligne subit constamment des attaques. En règle générale ce sont des bots d'utilisateurs malveillants qui aléatoirement scannent les ports des IPs.

Par jour ton serveur recevra environ entre 100 et 100 000 tentatives de connexion SSH. Dans ce volume, seul 0.1% proviendront de chez toi ! Voila pourquoi on va faire les choses bien pour que tu sois tranquille et que tu oses franchir le pas !

On va voir dans cet article comment s'occuper de la majorité des attaques que peut subir un serveur.

A partir de maintenant, je suppose que l’hébergeur a installé ta distribution linux (moi ce sera Debian pour le tuto) et qu'il t’a communiqué ton user, le mot de passe et l’IP du serveur.

Première chose à faire, ouvre un terminal et connecte toi en SSH dessus :

ssh user@ipserveur (Il va te demander ton password)

Voila, on est chez nous !

Mais chez nous avec des portes en bois et des vitres transparentes.

Coucou admin !

On va sécuriser un peu tout ça parce que la connexion via mot de passe … c’est pas top.

1. Sécurisation de l'accès SSH

Si ton hébergeur a installé la distribution linux avec uniquement le compte root, on va ajouter un compte "de tous les jours" car la connexion via root doit vraiment être exceptionnelle.

useradd tonnomdeuserpasswd tonnomdeuser

Choisis un bon password.

Grâce à ça, tu disposes maintenant d'un compte avec un /home/tonnomdeuser.

On va update le système (car on l’a installé mais pas forcément avec un OS à jour) :

apt update && apt upgrade

(En général ça prend quelques minutes)

Ensuite ouvre un nouveau terminal depuis ton PC puis crée une clé ssh (avec ton compte non root) (mon tuto ssh dispo ici).

Essaye ensuite de te connecter via la clé avec la commande :

ssh -i ~/.ssh/taclé tonUser@ipServeur​

Si tu as réussi à t’y connecter sans que le système te demande ton password, c’est ok, sinon réessaye bien les étapes pas à pas.

Rends toi ensuite dans le fichier de configuration ssh de ton serveur :

nano /etc/ssh/sshd_config​

Change la ligne #Port22 pour le port de ton choix et décommente en enlevant le #.

ça permet d’éviter d’être trop prévisible sur le port classique ssh (totalement useless mais bon, c’est tellement simple de le changer).

Descends un peu dans le fichier de configuration jusqu’à trouver #PasswordAuthentication yes. Décommente le et change le à no.

ça permettra de désactiver la connexion ssh via mot de passe et de ne passer que par ta clé privée.

On ne doit utiliser root que dans des cas très précis (ici c'est pas gênant car on est justement dans des tâches de supervision donc on a besoin de root, mais ce doit être l'exception) par conséquent, passes à "no" le PermeiRootLogin, ça permettra d'éviter des ennuis.

Si c'est ta première fois avec nano, tu fais "crtl + x" pour quitter et le système te demande si tu veux sauvegarder tu fais "y" puis "entrée".

Et pour que le système prenne en compte les changements, exécute cette commande ci-dessous pour relancer le service.

/etc/init.d/ssh restart

Tente de te connecter avec un nouveau terminal afin d’être certain que tu puisses te connecter via ta clé. Sinon si tu te déconnectes, tu perdras ton accès.

A présent, quand tu veux te connecter, tu auras juste à spécifier le port que tu as renseigné ainsi que ta clé privée et le tour est joué.

C’est une première étape pour sécuriser ton serveur.

A présent, on va utiliser un pare-feu pour justement anticiper et ne pas exposer inutilement notre serveur.

N’oublie pas qu'une bonne protection c’est limiter sa surface d’attaque.

On va installer ufw (uncomplicated firewall) qui est un pare-feu sympa :

apt install ufw

Normalement il est automatiquement enable, mais prends l’habitude de toujours checker un peu les services avec le systemctl :

systemctl status ufw

Activons maintenant le pare-feu, attention petit moment délicat car c’est le meilleur moyen pour te retrouver jeté de ton propre serveur donc suis bien les étapes dans l’ordre et ne te déconnectes pas du ssh tant que tu n’es pas certain que les règles sont bonnes :

ufw default deny incoming ufw default allow outgoing

Ici on fait quoi ? On deny toutes les connexions entrantes mais on autorise les sortantes.

En d’autres termes, si on active maintenant le firewall, t’es jeté de ta propre maison pour tes prochaines connexions.

Donc on va éviter ça avec une nouvelle règle :

ufw allow from tonip to any port 2200

Tu vois l’intérêt de l’ip fixe ? Le jour où ton ip change, tu perds l’accès à ton serveur. (Si ton FAI ne te propose une IP fixe en tant que particulier, tu peux toujours t’orienter vers une offre VPN te proposant une option d’IP fixe, comme ça tu autorises celle là).

Ok donc maintenant on va activer le firewall :

systemctl start ufw && ufw enable​​

Si t’as encore accès à ton terminal via une nouvelle connexion, félicitation tu as survécu !

Tu peux checker les ports ouverts et fermés :

ufw status

Vu qu’on a mis une politique deny > allow, quand on fait ufw status, on voit uniquement les règles explicites.

On peut regarder en détail les ports et la politique associée avec la commande ci-dessous :

ufw status verbose

On voit bien notre politique : deny incoming (entrant) et allow outgoing (sortant).

Tu peux aussi bannir une IP si jamais tu vois quelque chose de suspect dans tes logs d’applications ou de serveur :

ufw deny from ipsuspecte

Bannir une ip sans spécifier de “to any port 2200” (par exemple), permet de bannir une IP sur l’ensemble des ports s'il n’y a pas de règle de contournement (ufw allow from ip to any port 2200 par exemple).

Cette partie là a été réalisée via ce site.

Tu peux aussi vérifier les ports qui sont à l'écoute via la commande netstat.

Sur Debian netstat n'est pas inclus de base alors on va l’installer car ça nous permettra plus tard de debug la partie Web.

apt install net-tools​

On va pouvoir voir facilement quels sont les ports qui écoutent (pas forcément ceux qui sont open bar mais au moins voir lesquels sont à l’écoute, et à toi ensuite de décider si tu les fermes ou pas via ufw).

netstat -tulpn​​

-tulpn permet de voir les ports TCP et UDP et les programmes qui utilisent les ports.

La colonne Adresse distante te permet de voir sur quelle interface le port écoute. 0.0.0.0 indique qu’il écoute sur le web entier donc n’importe qui peut se connecter MAIS ça c’était avant que ufw ne le bloque !

Netstat te montre TOUT les ports qui écoutent donc no panic, ton pare-feu est bien fonctionnel. La commande est utile pour vérifier si un service écoute ou n’écoute pas, utile plus tard pour la partie Web par exemple.

Voila, à présent on peut s’octroyer une petite pause bien méritée ! Ton serveur est plus en sécurité qu’au début.

C’est bien mais on va continuer un peu (Ok... la pause était pas folle).

On reste motivé !

Si jamais ton IP de chez toi n’est pas fixe (prends une ip fixe !) on va installer un outil qui permet sans bloquer le port ssh, de le rendre un peu plus secure.

C'est un petit outil de répression si jamais quelqu’un tente de se montrer un peu insistant sur un service (ici bruteforcer le ssh).

Il y a plusieurs outils à dispo et notamment le plus connu d’entre eux : Fail2ban. Mais on ne va pas utiliser celui-ci.

J’ai récemment découvert un outil écrit en GO (les prochaines versions seront en Rust) et qui en plus est français #cocorico.

Cet outil c’est Reaction et il est vraiment sympa et plus user-friendly que fail2ban.

On suit l’étape d’installation ici :​

curl -o /usr/local/bin/reaction https://static.ppom.me/reaction/releases/$VERSION/reaction
chmod 755 /usr/local/bin/reaction   

(vérifies bien que dans le dépôt des versions vous prenez bien une realease et pas une version en cours de développement).

Puis on va créer un service pour qu’il soit load automatiquement au démarrage (et ça permet aussi d’avoir des logs dispo dans le journalctl et ça c’est cool).

​​nano /etc/systemd/system/reaction.service

Et ajoute ceci à l'intérieur :

[Install]
WantedBy=multi-user.target
[Service]
ExecStart=/usr/local/bin/reaction start -c /etc/reaction.yml
StateDirectory=reaction
RuntimeDirectory=reaction
WorkingDirectory=/var/lib/reaction

On crée ensuite notre fichier de configuration (l’équivalent des jails dans fail2ban) :

nano /etc/reaction.yml

patterns:
 ip:
   regex: '(?:(?:[0-9]{1,3}\.){3}[0-9]{1,3})'streams:
 ssh:
   cmd: ['journalctl', '-fu', 'ssh.service']
   filters:
     fail:
       regex:
         - 'authentication failure;.*rhost=<ip>'
       retry: 5
       retryperiod: '24h'
       actions:
         ban:
           cmd: ['ufw', 'deny', 'from', '<ip>', 'to', 'any', 'port', '2200', 'comment', 'ban-reaction']
         unban:
           after: "8760h"
           cmd: ['']

Pour l’explication détaillée je te laisse aller voir la documentation de Reaction mais en raccourci c’est un surveillant de logs.

Les streams : ce sont les services sur lesquels tu veux qu’il écoute.

Donc nous, ssh et il écoutera sur le canal journalctl -fu ssh.service (car c’est là que les logs sont gérés).

On lui donne ensuite la target avec le regex qu’il doit surveiller.

Tu trouveras ici un exemple pour les regex.

Retry c’est le nombre de chances qu’on donne à l’utilisateur (l’erreur est humaine).

Et retryperiod c’est intervalle au cours duquel le user peut se tromper 5 fois.

Action c’est ce que Reaction va faire au bout des 5 retry atteints sur 24h (ici on ban l’ip sur le port ssh avec un commentaire dispo sur ufw).

On peut faire une action unban au bout d’un délai (ici une année en heure). Je n’ai cependant pas trouvé comment ne pas mettre de unban (j’ai une erreur quand je n'en mets pas) car je n’ai pas envie que Reaction unban un user qui a tenté 5 fois. Je préfère regarder un peu de mon côté sur ufw et unban moi même si un user m’avertit d’une erreur de connexion par exemple.

Edit du 03/05/2025: Suite à un échange avec Ppom à propos de la possibilité d'enlever le unban, il suffit de ne pas mettre les 3 lignes unban, after et cmd.

Tu peux lancer un script lors d'un ban aussi, par exemple pour te prévenir par mail, sur un canal slack ou discord etc ...

On lance donc le service :

• systemctl enable reaction.service

• systemctl start reaction.service

Pour voir le nombre de retry actuel d'un user on fait :

Le user a tenté pour l’instant 3 fois.

Pour la partie unban je te laisse aller voir sur le blog de Ppom ! (mais genre ... vraiment, vas'y ! c'est une pépite cette doc).

Reaction c'est bien si déjà ton port est accessible à d’autres ips que la tienne (pour ssh dans notre cas c’est overkill car seule ton ip est autorisée, mais pour des cas d’ips volatiles, c’est intéressant).

A chaque nouveau service, on ira update ufw et Reaction pour être au top niveau surveillance.

Niveau pare-feu, on est bons, mais un système qui est outdated c’est pas foufou, surtout pour les failles.

Donc déjà, mettons à jour notre serveur :

• apt update

• apt-get upgrade

• apt autoremove

Autoremove permet de supprimer des packages qui seraient inutiles au système.

On va à présent faire en sorte d’avoir les mises à jour automatiques pour éviter d’avoir à y penser !

apt install unattended-upgrades

Puis on va décommenter quelques lignes du fichier de conf :

nano /etc/apt/apt.conf.d/50unattended-upgrades

Cherches les lignes :

• // Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

• // Unattended-Upgrade::Remove-Unused-Dependencies "false";

et décommentes les comme sur le screen, ça permet de faire une sorte d'autoremove finalement.

Ensuite on va copier le modèle de mise à jour que l’on souhaite appliquer au système :

cp /usr/share/unattented-upgrades/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades

/usr/share/unattented-upgrades/20auto-upgrades est un fichier de template, on vient le copier dans le /etc/apt/apt.conf.d/20auto-upgrades puis on le modifie :

On fait un nano de ce fichier et on y met tout ça :

// équivalent à un apt update
APT::Periodic::Update-Package-Lists "1";
// Lancera un unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";
// Téléchargera les paquets de sécurité
APT::Periodic::Download-Upgradeable-Packages "1";
// Supprimera les paquets obsolètes (presque un autoremove)
APT::Periodic::AutocleanInterval "7";

La mise à jour se lancera entre 6h00 et 7h00 du matin.

Personnellement ça me va bien. Cependant si tu veux fixer plus finement l’horaire tu peux suivre la fin de ce tuto.

Pour résumer voici ce que tu as fais sur cette première partie :

• Sécurisation de l’accès SSH via paire de clé privée/publique

• Désactivation du SSH par mot de passe

• Changement du port par défaut SSH

• Installation de UFW et paramétrage (à peaufiner au fil du temps en fonction des services que tu souhaites mettre à dispo)

• Installation et paramétrage de Reaction

• Mise en place des mises à jour de sécurité automatiques

C'est terminé pour ce 1er article sur cette série consacrée à la gestion d'un serveur.

Pour le prochain on abordera les backups et le monitoring.