Cet article a été rédigé et testé sous un serveur installé sous Debian 9 & Ubuntu 18.04. Ce contenu devrait sans problème pouvoir s'appliquer à d'autres OS sur la base Linux, mais certains paramètres peuvent être amenés à changer.

La vaste majorité de nos serveurs Linux (VPS ou Serveurs Dédiés) sont livrés "nus", c'est à dire, avec une configuration très similaire à ce que vous auriez eu en installant l'OS par vous même. 

De base cette configuration ne comporte pas d'éléments visant à assurer la sécurité du serveur. Il est donc fortement recommandé de suivre ces quelques petites règles afin de renforcer la sécurité de votre VPS.

Vous êtes seul administrateur de votre VPS, et êtes donc responsable des actions effectués sur ce dernier. Si votre VPS est utilisé par un tiers à votre insu (hack, fuite du mot de passe, etc) vous pourrez être tenu pour responsable des actions effectuées par ces derniers. Il est donc essentiel d'assurer la sécurité de votre VPS pour éviter toute utilisation anormale de ce dernier.

Cet article se concentrera volontairement sur la protection de l'accès root de votre VPS (qui est le plus vulnérable à sa livraison, et le plus souvent attaqué). D'autres aspect de la sécurité de votre VPS peuvent également être explorés (mise en place d'un pare-feu, mises à jour régulière de l'OS, analyse des logs régulière, sauvegarde, etc).

1/ Renforcer son mot de passe root

Lors de la livraison, si vous ne l'avez pas défini vous-même, votre VPS est créé avec un mot de passe root aléatoire de 6 caractères, afin de vous faciliter le premier accès à votre VPS. Ce mot de passe, bien qu'aléatoire, est très faible (moins d'une heure de brute force nécessaire pour accéder à votre VPS). Il est donc impératif de le modifier par un autre mot de passe, beaucoup plus long.

Sous la vaste majorité des OS Linux, il suffit d'une seule commande (en root) : "passwd root"

root@HelpDesk:~# passwd root
Enter new UNIX password:
Retype new UNIX password:


L'utilitaire vous demandera de saisir deux fois le nouveau mot de passe root que vous souhaitez mettre en place. Lorsque vous taperez ces mots de passe, rien ne s'affiche à l'écran : C'est normal. Linux, contrairement à Windows, n'affiche pas d'étoiles ou de caractère lorsqu'un mot de passe est saisi dans le terminal. 

2/ Empêcher les attaques par BruteForce

Les adresses IP de serveurs sont très régulièrement la cible d'attaques par Brute Force. Même si généralement, un mot de passe bien renforcé est inattaquable (cela prendrait des siècles), la mise en place d'une protection contre le BruteForce est très simple et ne prend que quelques minutes et protègera davantage votre VPS.

La protection de base contre ces attaques est fournie à l'aide du paquet "fail2ban", capable de surveiller les logs de très nombreux service de votre VPS, et de bloquer temporairement les IP ui apparaissent régulièrement dans ces logs. 

Ce paquet s'installe donc tout simplement avec la commande "apt install fail2ban"

root@HelpDesk:~# apt install fail2ban
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
fail2ban python3-pyinotify python3-systemd whois
0 upgraded, 4 newly installed, 0 to remove and 64 not upgraded.
Need to get 424 kB of archives.
After this operation, 1967 kB of additional disk space will be used.
Do you want to continue? [Y/n]


Une fois fail2ban installé, il ne vous reste plus qu'a configurer ce dernier, à l'aide de la commande suivante : 

root@HelpDesk:~# printf "[ssh] \nenabled = true \nport = ssh \nfilter = sshd \naction = iptables[name=SSH, port=ssh, protocol=tcp] \nlogpath = /var/log/auth.log \nmaxretry = 3 \nbantime = 900\n" > /etc/fail2ban/jail.d/ssh.conf


Cela créera automatiquement le fichier "/etc/fail2ban/jail.d/ssh.conf", avec le contenu suivant

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 3
bantime = 900


Ce fichier sert à spécifier l'emplacement où se trouvent les logs du service SSH (/var/log/auth.log) par défaut, le nombre d'essai (maxretry=3) qu'une IP a le droit de réaliser dans le temps de détection (10 minutes par défaut), et la durée du bannissement de cette IP du serveur (bantime = 900 → 15 minutes)

Il ne vous reste plus qu'a relancer le service fail2ban à l'aide de la commande suivante, et votre protection brute-force sera active. 

root@HelpDesk:~# service fail2ban restart


Si par mégarde vous vous faites bloquer de votre serveur, et que vous ne souhaitez pas attendre le délai de 15 minutes, vous pouvez vider la liste des IP bannies via la commande "iptables -F". Il faudra pour cela accéder au shell de votre VPS via la console disponible sur votre panel de contrôle, puis rentrer le mot de passe root de votre VPS.

3/ Modifier le port SSH par défaut

La modification du port d'écoute de votre serveur SSH ne vous protègera pas des tentatives d'attaques ciblées (il est très facile pour quelqu'un de retrouver sur quel port écoute réellement votre serveur SSH), mais cela vous permettra d'éviter les attaques de bots/robots qui parcourent les IP de serveurs, à la recherche de serveurs simples à pirater. 

Pour effectuer cette modification, il vous suffit de modifier le fichier /etc/ssh/sshd_config, et de remplacer la ligne "**Port 22**", par "**Port 8822**". Vous pouvez bien évidemment remplacer 8822 par n'importe quel autre numéro de port qui n'est pas utilisé sur votre serveur. Vérifiez également qu'aucun "#" n'est présent devant cette ligne. Si un # est présent, retirez le, sinon cette ligne ne sera pas prise en compte. 

Il vous suffit ensuite de redémarrer votre service ssh via la commande

root@HelpDesk:~# service ssh restart


Après toute modification sur SSH, veillez à tester votre nouvelle configuration dans une nouvelle console (gardez bien l'ancienne console ouverte). Si jamais pour une quelconque raison, votre configuration était incorrect et que vous n'arriviez plus à vous connecter, la session toujours ouverte dans la première console vous permettrait de réparer votre erreur. La modification de la configuration SSH ne touche pas aux sessions déjà ouvertes. Même si vous arrêtez le service SSH, les sessions en cours resteront ouvertes.
Cet article a-t-il répondu à vos questions ?
Annuler
Merci !