S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

[Tuto] Renforcer la sécurité de son VPS avec fail2ban, clés SSH, What’s Up Docker…

Des choses de prévues ce week-end ?

[Tuto] Renforcer la sécurité de son VPS avec fail2ban, clés SSH, What’s Up Docker…

Illustration : Flock

Vous utilisez un VPS, mais vous n’avez pas encore configuré sa sécurité ? C’est un problème à prendre au sérieux puisque votre serveur est attaqué plusieurs milliers de fois par jour. Next vous donne quelques bases pour mettre à jour les composants, les conteneurs Docker, surveiller les tentatives de connexions, etc.

Le 13 mars à 16h11

Les VPS ont l’avantage de vous permettre, pour quelques euros par mois, de reprendre la main sur la gestion de certaines de vos données. Nous avons déjà expliqué comment installer un gestionnaire de mots de passe. D’autres tutos arrivent avec un serveur VPN dès la semaine prochaine.

Un VPS, c’est aussi un serveur hébergé chez une société tierce et directement exposé sur Internet. Il mérite donc une attention particulière au niveau de la sécurité, surtout s’il dispose de vos données (personnelles). À titre d’exemples, nos VPS sont attaqués en moyenne 10 000 fois par jour sur le port 22 (SSH).

Dans ce tuto, nous allons passer en revue quelques règles simples à mettre en place pour les mises à jour et bloquer ceux qui tenteraient de passer. Attention, cela ne remplace pas l’expertise d’un sysadmin car il existe évidemment de nombreuses autres bonnes pratiques à mettre en place, notamment une surveillance constante des logs, du fonctionnement du serveur et des applications.

Suivant l’importance des données que vous souhaitez mettre sur un serveur exposé sur Internet, il faudra passer la seconde avec des serveurs « gérés » (managed) avec des professionnels, s’occupant de l’installation et des mises à jour.

Le problème des versions non-LTS de Ubuntu (9 mois de support)

Dans notre cas, nous sommes avec Ubuntu 25.04 (la dernière disponible chez OVHcloud actuellement pour notre gamme de VPS), un problème car cette version n’est plus officiellement maintenue. Nous devons donc passer en 25.10, en attendant la 26.04 LTS qui sera maintenue plusieurs années.

Le choix d’une version LTS est intéressant pour cela, car les versions classiques ne sont maintenues que pendant neuf mois). Une solution aurait été d’installer le serveur dès le début en 24.04 (LTS), une version proposée par OVHcloud. Si vous installez votre VPS pour la première fois, partir sur une LTS peut être une bonne idée.

La commande sudo do-release-upgrade permet de se mettre à jour notre Ubuntu… sauf que non, le système nous répond : « Your Ubuntu release is not supported anymore. For upgrade information, please visit: http://www.ubuntu.com/releaseendoflife. Please install all available updates for your release before upgrading ».

Pour passer à Ubuntu 25.10, nous devons donc d’abord mettre à jour toutes nos applications, avec les commandes sudo apt update && sudo apt upgrade, puis relancer sudo do-release-upgrade pour le système d’exploitation en lui-même. Cette fois-ci ça marche !

Attention, à la fin nous avons eu un message : « System upgrade is complete. Restart required. To finish the upgrade, a restart is required ». Un reboot plus tard, retour à PuTTY et nous voilà bien avec Ubuntu 25.10. Reste maintenant plus qu’à attendre Ubuntu 26.04 LTS pour migrer sur cette version, et rester ensuite quelques années dessus (cinq ans actuellement, avec une LTS tous les deux ans).

Des mises à jour (de sécurité) installées automatiquement

Il reste 83% de l'article à découvrir.

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (53)

votre avatar
Merci pour cet article. Directement utilisable sous Trixie ou spécifique Ubuntu ?
votre avatar
J’ai fais touts les manips sous Ubuntu, je pense pas que ça change grand chose sur Debian, mais peut etre des commandes à ajuster (config docker and co ca doit rien changer)
votre avatar
Sur debian, c’est nftables qui est utilisé plutôt qu’ufw et il fonctionne bien avec Docker (pour la version docker.io).

Et perso, j’utilise les tuto d’howtoforge, exemple :
https://www.howtoforge.com/ispconfig-autoinstall-debian-ubuntu/
votre avatar
1) Sur le port SSH, c'est une bonne idee de mettre une limite.
ufw limit 22/tcp plutot que ufw allow 22/tcp
Eventuellement un restriction des IP entrantes
ufw allow from 192.168.1.0/24 to any port 22 proto tcp

2) Dans ce genre de setup je conseille de mettre un reverse proxy pour faire la terminaison SSL et aussi pour se prendre tous le trafic HPPT moisi et ne passer que ce qui est un minimum ok.
Cela permet aussi d’agréger les confs TLS et les logs des différents containers web.

3) Pour aller plus loin, il y a les benchmark CIS qui sont gratuit.
https://www.cisecurity.org/benchmark/ubuntu_linux
votre avatar
En auto-hébergèrent, la redirection de port étant coté routeur, le firewall coté serveur à un intérêt limité (si on ouvre pas n'importe quoi) ?
Si il y a compromission d'un truc sur le LAN, Firewall ou pas, j'imagine que la sécurité du serveur est de toute façon morte ?
votre avatar
Pas nécessairement. C’est le principe du zero-trust. Ce n’est pas parce que tu es sur le LAN que tu es de confiance. Et vu que ce qui est sur le LAN sert vraisemblablement à aller sur le net, ça me semble indispensable.
votre avatar
Si il y a compromission d'un truc sur le LAN, Firewall ou pas, j'imagine que la sécurité du serveur est de toute façon morte ?
C'est pas pour ce que ça coûte! On n'est jamais à l'abris d'une erreur. Et truc bête: avec un firewall sur le serveur, tu peux limiter l'accès du LAN aussi (quitte à mettre un bastion ou à passer par internet pour accéder à ton propre serveur).

Silo, moindre privilège, limiter l'exposition et sauvegarder.
votre avatar
Ce n'est pas le cas si tu as configuré une adresse en zone démilitarisée. Dans ce cas, la box envoie vers l'adresse de DMZ toutes les demandes qu'elle ne traite pas elle-même. En l’occurrence, si tu héberge un serveur, il est plus simple de le mettre en DMZ que d'ouvrir une flopée de port à rediriger.

Ce n'est pas non plus le cas si l'universal plug and play (uPNP), est actif sur la box, ce qui est le cas par défaut sur toutes les box il me semble. Avec l'uPNP, un logiciel peut demander l'ouverture d'un port sur la box et une redirection vers une machine du réseau local, sans ton intervention. Un régal pour les logiciels malveillants.
votre avatar
Le firewall a un intérêt depuis pas mal d'années en Europe, principalement depuis l'épuisement des anciennes adresses v4.

Je n'ai plus rien en v4, uniquement du v6.
votre avatar
Je sais pas si c'est fait exprès mais en voyant l'image, j'ai plutôt pensé à un cerveau hurlant "TUT !" à travers l’entonnoir plutôt que le tuto entrant dans le cerveau. Ça m'a fait marrer :D
Tuto intéressant en tout cas, j'ai appris des trucs. Notamment que je suis pas prêt de connecter une machine un tout petit peu sensible à Internet. J'ai pas le niveau et les risques sont trop élevés à mon goût, c'est vraiment un métier :D
votre avatar
et dans ce cas-là, "TUT !" est donc le bruit d'un pet de cerval :pet:
votre avatar
Pfff... Tant de temps passé à faire ce genre de choses et vous résumez cela de main de maître au nécessaire en quelques pages...

Bravo pour cet article essentiel.

Perso j'ai un petit soft local qui met à jour des autorisations IPv4 avec l'IP de ma freebox pour certains services. J'ai mis un nom à ma freebox et je le fais résoudre toutes les 4h.

Je commence aussi un truc: n'autoriser que IPv6 sur certains services. La plupart des attaques restent en IPv4. Ca durera ce que ça durera.

Enfin, j'ai de l'auth via un certificat client généré par moi-même depuis mon propre certificat racine sur des services web (ma visio familiale notamment - que mamie n'aie pas besoin de login).

J'ai tenté de mettre un bastion docker, mais je tremblais un peu à l'idée de me scier l'herbe sur laquelle j'étais assis :)
votre avatar
Sur un desktop, je comprends que certains préfèrent Ubuntu, mais sur un serveur, Debian semble quand même plus adapté (cycle de vie, sécurité, etc.)
votre avatar
15 ans pour Ubuntu Pro (gratuit si personnel). Debian fait mieux ?
https://ubuntu.com/about/release-cycle
votre avatar
10 ans chez Debian, et chez Ubuntu Pro ils annoncent 15 ans pour l'avenir, mais en ce qui concerne le passé (et qui est donc la seule information fiable), c'était aussi 10 ans (14.04 LTS jusqu'en 2024, pas 2029).
votre avatar
Ça ne sert pas trop de comparer des durées, il faut aussi comparer les périmètres. Perso, je laisserai pas une debian LTS avec des services internet actifs. Il y a tellement de chance que ça dépende d’une lib qui, elle, est hors-périmètre, que ça n’en vaut pas la peine. Mieux vaut migrer.

Je ne sais pas quelle est la situation pour ubuntu, je suppose qu’elle est assez similaire. Le support à 15 ans doit s’arrêter au kernel et deux trois trucs. Je l’imagine plutôt pour l’indus (avec du coup une vraie gestion de sbom et une des exécutables où tout est linké en statique) que pour un serveur web.
votre avatar
C'est la même base. Ubuntu c'est une debian
votre avatar
Ubuntu est dérivé de Debian, ce n'est pas une Debian.
Regardons ce qu'ils en pensent chez Ubuntu :
https://doc.ubuntu-fr.org/debian_ubuntu_comparaison
Ubuntu possède une documentation francophone collaborative, importante sur le plan du volume et orientée vers le débutant : c'est celle que vous êtes en train de consulter…
Ubuntu prévoit des choses assez User Friendly que n'a pas Debian, comme la liste des utilisateur quand on se connecte, ou bien encore, l'installation par défaut avec un environnement de bureau…
Les versions stables de Debian ne sortent qu'une fois qu'elles sont prêtes, ce qui entraine par conséquent qu'une nouvelle version est toujours extrêmement stable
Debian s'adresse à un public un peu plus initié : il est personnalisable à souhaits mais à condition de « mettre les mains dans le cambouis » pour tout installer.
Pour un serveur, donc a priori quelqu'un qui sait ce qu'il fait, qui veut un truc stable, et qui n'a pas besoin d'un truc user-friendly pour le desktop, je ne vois pas l'intérêt d'Ubuntu.
votre avatar
C’est vrai que c’est par habitude, elle était sur mon desktop. Mais la version serveur, à réfléchiR pour le prochain VPS
votre avatar
Regardons ce qu'ils en pensent chez Ubuntu
Chez les utilisateurs francophones d'Ubuntu, mais c'est juste pour être précis sur ce point, le reste est OK.
votre avatar
Je suis déçu, pas même un I use Arch, BTW, pour le moment.

(mon serveur associé au NAS chez moi l'est presque, sous Manjaro - ça peut amener des surprises par moment, mais pas plus que ça)
votre avatar
Je pense q'il y a une erreur :
Il y a la phrase : "Voici enfin une série de commandes qui permettent de bloquer tout le trafic entrant et sortant par défaut, puis d’ouvrir certains ports."
Puis l'exemple :
sudo ufw default deny incoming
sudo ufw default allow deny outgoing
non ?
Je continue ma lecture.
votre avatar
Oui,
Pour moi en out j’autoriserais rien par défaut, puis autoriser les ports aléatoires (si le firewall n’est pas stateful), le DNS, https et éventuellement http, ntp, icmp éventuellement.
votre avatar
J'utilise aussi ipset pour créer une table pays autorise et je recupéres la liste des IP francaise que j'autorise. depuis www.ipdeny.com

Et une autres table pour les IP pas tres sympa que je bloque direct. liste créé a partir de iplists.firehol.org et de www.spamhaus.org.

Et psad pour bannir les IP (jusqu'au reboot).
votre avatar
Tu peux même restreindre encore plus en virant les IP qui n'appartiennent pas à un FAI. J'imagine qu'un serveur chez ovh a peu de chance de venir consulter une page web chez toi ou tenter une connexion ssh pour une raison valable.

Pour cela, tu peux te faire une liste des ASN autorisés et utiliser geoip2
votre avatar
Bonne idée, je vais regarder ça.
Merci
votre avatar
Est ce que ovh distingue les abonnés FAI des serveurs ?
Si quelqu’un est abonné chez ovh en fibre et que tu bloque toutes les Ip ovh peut être qu’il ne pourra pas consulter ton site auto hébergemé.
votre avatar
Est ce que ovh distingue les abonnés FAI des serveurs ?
Bonne remarque et la réponse est oui:

  • AS35540 OVH-TELECOM, FR

  • AS16276 OVH, FR



Une bonne adresse pour ce type de recherches: https://hackertarget.com/as-ip-lookup/
votre avatar
C'est dommage pour ceux qui se font un VPN avec serveur chez OVH, comme va nous l'expliquer @SébastienGavois dans un prochain tuto.

À mon avis, c'est donc à éviter.
votre avatar
Perso, j'aurai tendance à bloquer toute source de résurgence VPN sur mes machines. Mais cette politique dépend clairement du type de client que tu attend chez toi.

Si le blocage est fait par nginx, il y a toujours le moyen de créer des logs dédiés à certaines règles pour pouvoir analyser les conséquences d'un filtrage.
votre avatar
Avant de lire, ya le tuto pour se deban après la première install de fail2ban ? Vous savez, celle où après être tout content de l'avoir installé, in se retrouve bloqué dehors 😅
votre avatar
Je ne me souviens pas, vous avez parlé de reverse proxy ? Parce que pour exposer des services, c'est tout même mieux. Et une seule porte a bien sécuriser.
votre avatar
Oui j’en parle via Caddy. Mais j’en parle surtout lors des tutos pour installer Vaultwarden (et Wiregard à venir, je spoil un peu) et redigirer le ndd vers l’IP et ensuite à charge de Caddy de rediriger vers le bon port
votre avatar
Quelle sécurisation attends-tu d'un reverse proxy ? cherches-tu un blocage de plages IP ou de pays ?
votre avatar
Sécuriser une entrée plutôt que plusieurs
votre avatar
Une bonne règle de base aussi est de bannir IPv4 sur tous les ports ou cela est possible.

A noter qu'utiliser un pare-feux comme nftable permet aussi de faire du géoblocage mais cela génère certainement une charge de travail importante.

UFW, c'est vraiment le service minimum. Sur une machine cliente qui ne propose aucun service, cela suffit bien mais sur un serveur, je trouve cela limite.
votre avatar
La bonne règle c’est de tout interdire par défaut et ensuite on voit au cas par cas 😂
votre avatar
Je suis bien d'accord avec toi.

Perso, je limite aussi les écoutes inutiles de mes services et le nombre de services. A ce titre, il y a pas mal de mauvais élèves parmi les logiciels courant, qui écoutent sur toutes les interfaces réseau, sans vergogne. Ce n'est pas toujours simple de les faire rentrer dans les rangs.

Pour ce qui est local, je privilégie les socket unix à l'écoute sur localhost
votre avatar
voila, et la premiere rules c'est géneralement celle de réouvrir ssh à partir d'une console kvm emergency
votre avatar
Pour un serveur à usage privé où majoritairement privé, quand le provider fournit des security Group (scaleway, aws,…) qui sont des règles firewall que l’on peut attacher à son instance, et bien ça permet de déléguer la gestion du firewall et des flux à ce niveau.
Ainsi, un serveur web ? Le ssh peut être autorisé que vers son ip en inbound et le web depuis tout le monde en inbound.
Ça évite d’ouvrir des ports vers tout internet.

J’ai une Vm chez scaleway, ipv6 (ça coûte moins cher), j’ai ouvert les flux depuis les préfixes IPv6 de chez moi et basta, ça fonctionne. C’est simple, et c’est secure.
votre avatar
[Edith: c'est ssh sur IPv4 que je propose d'interdire] :
Pourquoi ne pas avoir conseillé d'interdire les connexions ssh en IPv4. ssh, c'est principalement pour de l'administration distante donc si on a IPv6 chez soit, on peut se contenter de ce type de connexion. Pour l'instant, ça élimine beaucoup d'attaques.
votre avatar
interdire les connexions ssh en IP v4, je suppose.
votre avatar
Merci. J'ai corrigé mon texte.
votre avatar
Nextcloud AIO sur APU et Caddy sur OPNSense
votre avatar
Merci pour le boulot ! Un tuto en poche.

Après fail2ban… si Docker est déjà installé, on peut mettre en place Crowdsec plutôt, non ?
Plus innovant, plus intéressant d’un point de sécu.
votre avatar
Super tuto. Tu me régales en ce moment @SébastienGavois :)

Comme d'autres l'ont soulevé dans les commentaires, Iptables est quand même un peu (beaucoup) merdique (fonctionnalités et performances) dès que tu as un peu de règles et/ou du volume/charge.
Ipset (indispensable) améliore un peu les choses mais tu peux vite atteindre ses limites également.

Nftables (ré-écriture complète de l'auteur de Iptables est dispo depuis... 15 ans ?) est incomparablement plus
performants.
La gestion des tables avec les priorités permet d'isoler tes sets (Sur Iptables c'est l'ordre des règles qui jouent, bonne chance quand tu as des process qui les modifient à la volée).
Ex : listes blanche d'abord -> géoban -> Honeypots -> ban manuel -> Crowdsec -> rules générales

Avec Nftable les honeypots sont triviaux, pas besoin de trucs en plus genre Portsentry. Et je jeux te garantir que ton port SSH custom il va pas être si simple à trouver :)

Fail2ban fait le job et est largement suffisant pour du SSH par exemple. Mais pour un site Web avec un peu de trafic les perfs et les détections ne sont plus du tout au niveau (surtout dans cettes nouvelle ère IA).
Crowdsec est bien meilleurs. Oui je sais c'est une boite (Française) qui est derrière et tu as des truc payant (très très cher).

Très bon point pour unatended-upgrade que je met aussi en auto pour les upgrade sécu (sauf kernel + reboot je veux être là).
Ajouter le paquet needrestart rend aussi bien service, car oui, tu es a jour d'après apt mais les vielles versions tournent toujours jusqu’au reload/restart hein ;)
votre avatar
Perso pour Docker, je ne fais pas de mises à jour automatique des images. Trop de risques je trouve. Je préfère être notifié et faire moi même les updates.
Actuellement j'utilise 2 solutions pour être notifié d'une nouvelle image :

  • diun

  • Change Detection : je check les nouvelles releases sur github. J'utilise aussi Change Detection pour tout un tas de trucs à surveiller.


Sinon j'utilisais Portainer pour gérer mes containers, etc. Mais depuis peu je test Dockhand, qui intègre tout un tas de fonctions, dont la recherche d'update, les update auto, les notifications, etc.
votre avatar
Je viens de regarder Dockhand et il a l'air bien, mais sa licence ne l'est pas du tout (Business Source License), dommage.
votre avatar
Oh sympa Change Detection, ça pourrait être un moyen de faire du RSS aussi sur des sites qui n'en proposent pas et sont trop complexes pour RSS Bridge on dirait.
votre avatar
Je récupère un vieux PC de mes parents pour faire mon premier homelab. Les conseils ici sont ils OK pour de l'auto hébergement ?
votre avatar
Merci pour le tuto,

y'a un truc que je ne saisis pas: à quoi sert docker ici ?
ça pose deux problèmes de sécurité :

  • le docker peut tourner avec des versions de lib ou logiciel complètement obsolètes : tu ne le verras pas facilement,

  • on ne maîtrise pas bien la provenance (je ne serais pas surpris qu'il y'ait (aura) des images incluant leur propre porte dérobée, malware), : il suffit d'un "FROM" un peu foireux dans la succession de Dockerfile qui s'empilent pour que ton image docker contienne n'importe quoi...



Je ne vois pas l'apport de docker en usage perso ? Pour moi l'intéret de docker et de pouvoir dupliquer rapidement une config (par ex déployer un soft avec sa config pré-paramétrée) on en est très loin là non ?
votre avatar
@SébastienGavois
Tiens, j'ai vu passer ça sur un Shaarli aujourd'hui : https://vpskit.pro/
Je n'ai pas testé, je partage juste la découverte ^^
votre avatar
ha je ne connaissais pas non plus…