Mes astuces pour sécuriser un serveur web
27 Apr 2020
On ne le répétera jamais assez, la sécurité sur Internet est une chose primordiale. Ce sujet devient prioritaire lorsque vous êtes éditeur ou fournisseur d’un service SaaS.
Si vous pensez pouvoir installer tranquillement votre serveur dédié dans votre coin et vous permettre de laisser l’aspect sécurité de coté vous faites une grosse erreur.
Pour reprendre une nouvelle fois mon analogie fétiche avec la voiture, je dirai que cela reviendrai à ce qu’un taxi ou un chauffeur Uber, prenne la route avec sa nouvelle voiture sans en avoir fait le tour, sans avoir vérifié ni la pression des pneus, ni l’état des plaquettes. Cela peut bien se passer, néanmoins il peut y avoir quelques surprises.
Nous avions vu dans un précédent article les risques liés à la publication d’un service web. Je vous propose ici les premières règles à mettre en place sur n’importe quel serveur, afin de respecter le niveau minimum de sécurité.
Mettons nous dans le cas ou vous venez de réserver un serveur dédié chez votre hébergeur habituel pour la mise en place de votre service en ligne (Intranet, Site vitre, Service SaaS…). Vous installez votre distribution Linux préférée et vous accédez au serveur avec les identifiants fournis par l’hébergeur.
SSH, la porte d’entrée
Pour accéder en ligne de commandes à votre serveur, vous allez utiliser le protocole SSH (Secure Shell). Ce protocole fonctionne de manière standard sur le port 22 de votre serveur. Vous allez vite vous rendre compte que vous ne serez pas le seul à tenter d’accéder au serveur via ce port 22.
Regardez par exemple cette carte ci-dessous, elle représente la localisation des IP ayant effectué une tentative de connexion échouée sur l’un de mes serveurs sur les 15 derniers jours. Le nombre total de tentatives de connexion est supérieur à 200 000! Soit une dizaine par minute en moyenne!
Il est impératif de protéger votre serveur contre toutes ces tentatives d’intrusion.
On mure la porte…
Première action donc, fermer la porte du port 22 et en faire une plus discrète sur un autre port non standard. Il est recommandé de choisir un port supérieur à 1024, qui ne soit donc pas réservé. Evitez également de choisir 2222 qui est un peu trop commun. Voici la directive à rajouter au fichier sshd_config :
Listen 34567
A partir de là tout est possible, il s’agira tout simplement de spécifier le port à la connexion.
… et on ferme les fenêtres
Nous avons donc traité de la visibilité du service SSH, permettant d’accéder au serveur. La seconde étape est de faire la même chose pour les services fonctionnels qui seront installés sur le serveur: un serveur web, une base de données etc. Si l’accès au serveur web doit se faire depuis l’extérieur, celui à la base de données doit être limité à l’usage local.
Il convient donc d’identifier et de restreindre l’accès au strict minimum de ces services, afin de diminuer la surface d’attaque sur le serveur.
Cela se fait très simplement avec quelques règles iptables. Attention toutefois de ne pas vous couper la patte et de préserver l’accès au serveur. Bien autoriser la connexion sur votre port SSH non standard :
# Politique par défaut : Interdire toute connexion entrante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P OUTPUT ACCEPT# Autorise les connexions déjà établies et les connexions relatives à une connexion déjà autorisée
iptables -t filter -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT# Autorise les connexions SSH
iptables -t filter -A INPUT -p tcp –dport 34567 -j ACCEPT
Ces règles, à faire évoluer en fonction des services hébergés sur votre serveur, vous permettront de garder la main sur ce qui est réellement publié sur Internet et donc de limiter la surface d’attaque sur votre serveur. Cela revient à fermer des fenêtres pour éviter que quelqu’un ne rentre.
Vous pouvez également spécifier des adresses IP source autorisées à se connecter sur le port SSH. Attention toutefois, cela peut se révéler bloquant en cas d’urgence si vous souhaitez accéder au serveur depuis une connexion inhabituelle, via la 4G de votre smartphone par exemple.
# Autorise la connexion SSH depuis l’adresse 10.11.12.13 uniquement
iptables -t filter -A INPUT -p TCP –source 10.11.12.13 –dport 34567 -j ACCEPT
Analyse dynamique des logs de connexion
Malgré l’offuscation du service SSH, il est reste toujours possible de frapper à la porte de votre serveur pour s’y connecter. Cependant, chaque tentative de connexion va générer une écriture dans un fichier de log et faire l’objet d’un rapport.
Des outils tels que fail2ban vont analyser ces rapports de tentative de connexion pour bloquer totalement l’accès au serveur à certaines adresses IP. Une fois installé sur votre serveur, ce démon va scruter ces fichiers de logs, en extraire les adresses émettrices et le cas échéant ajouter dynamiquement une règle de blocage de l’adresse.
Ainsi, un attaquant qui aurait découvert le port non standard sur lequel vous avez paramétré le service SSH serait limité dans le nombre de tentative de connexion pour deviner le mot de passe. La tâche commence à se compliquer.
Cette seconde carte présente les mêmes données mais pour un serveur bénéficiant de la configuration décrite plus haut, SSH paramétré un port non standard et fail2ban installé :
Nombre total de tentatives de connexion? 211
Sur la même période et avec le même type de serveur, c’est à dire sans visibilité particulière, n’hébergeant aucun service à attaquer.
La différence est flagrante!
Et les extras
Si vous voulez pousser le vice un peu plus loin sur la sécurisation de l’accès SSH de votre serveur, je vous conseille Knockd, qui est un service de Port Knocking. Par défaut la connexion SSH sur votre serveur est impossible, le port est fermé, mais knockd permet de l’ouvrir en utilisant une séquence de connexion paramétrée en avance.
Le démon va écouter les différents ports définit puis autoriser, toujours avec iptables, la connexion lorsqu’il reconnait la séquence entrante. A l’inverse, une fois déconnecté vous renvoyez la séquence inverse pour refermer la connexion!
Bien entendu il est recommandé de combiner l’utilisation de knockd avec les différentes configurations vues plus haut. Pas question de laisser la connexion accessible sur le port 22 le temps de votre manipulation sur le serveur.
Sans oublier…
…la sauvegarde! On sort un peu de la sécurisation de l’accès à votre serveur, mais cela doit rester primordial: mise en place de la politique de sauvegarde! Avec rétention sur plusieurs jours et externalisation des données sur un stockage externe.
Personnellement, en tant qu’utilisateur de Debian, je me sers de BackupManager pour la gestion des sauvegardes. Ce petit utilitaire permet de sauvegarder à la fois les systèmes de fichiers et les bases de données. Il gère l’externalisation des sauvegarde et permet de spécifier une rétention locale et une distance. Vous pouvez ainsi imaginer garder les deux dernières versions de vos fichiers localement et les 20 dernières sur le stockage distant.
L’externalisation peut se faire au travers d’une connexion SSH, vers un serveur FTP ou sur un stockage AmazonS3. J’ai écrit un petit patch pour utiliser également un stockage Openstack Object Storage. N’hésitez pas à me contacter si vous êtes intéressé.
Nécessaire mais pas suffisant
Tout ces tips ne représentent que l’entrée en matière pour la sécurisation de votre serveur dédié. Il y aurait encore beaucoup à dire sur l’authentification par clé, sur la supervision, cela viendra dans un second temps. Je reste à votre disposition pour étudier vos projets de sécurisation de vos serveurs.
Ecrit par Julien