Vous avez créé votre 1er site internet personnel, vous découvrez internet et le monde des serveurs hébergés. Vous allez être surpris ! Internet, c’est la guerre ouverte, sans règle, avec une toute petite police désarmée, sans moyen et donc les actions font souvent plus de mal que de bien.

C’est la guerre sur l’internet

Oui, c’est la guerre. On entend aux informations régulièrement que des « méchants Russes » ont piraté tel ou tel service occidental.

Le quotidien est différent : Tout serveur, même le petit Raspberry sur lequel vous avez mis un petit WordPress chez vous est immédiatement attaqué dès qu’il est accessible par internet . Pas besoin pour cela d’être une grande entreprise ou un service gouvernemental.

Et contrairement à ce qu’on nous faire croire, actuellement, sur le serveur de Mr tout le monde 25 % des attaques viennent des USA. 10% de la Chine,  L’inde 8%, Israël, 5% la Russie arrive en 10ième position avec moins de 3%, le reste est réparti sur l’ensemble des pays du globe quelque soit sa taille.

Voici un exemple de répartition des attaques par Pays et par méthodes sur une durée d’un mois. Sur un serveur typique de « Monsieur tout le monde » : 7500 ip bannies (soit plus de 21 000 attaques car le bannissement se fait à la 3ième dans ce cas)

 

Quand au trafic internet, on pensait avec l’augmentation du débit gagner en confort. On n’a pas gagné grand chose :

80% du débit internet est utiliser pour diffusé du streaming (youtube, netflix, amazon , la TV par internet, les Replay). 15% sont des tentatives de piratages, de l’envoi de mails indésirables (SPAM). Reste 5% de débit réellement utilisé pour aller consulter les informations que l’on recherche sur internet.

Que cherchent donc ces méchants pirates

En général à exploiter une faille, pour cela, il vont tenter de savoir quels sont les services accessibles par internet que vous avez mis en place :

• La recherche de mot de passe ssh, pour prendre la main sur votre serveur représente 90% des attaques.
• 1% pour la recherche de mots de passe FTP
• Les autres services concernés sont plus rares.

Mais si vous avec mis en place un site internet , c’est la cata , les pirates vont tenter de savoir

• si vous utilisez Worpdress, Joomla, Wix. Si oui, tenter de trouver le mot de passe administrateur et faire passer pour une mise à jour de plugin, un code php malveillant.
• ils vont se jeter comme des mouches sur une motte de beure sur l’installation éventuelle de phpmyadmin
• ils vont tenter de savoir quelles version de php , apache, nginx vous utilisez par cela leur permettra de connaitre les failles connues qu’ils pourraient tenter d’utiliser

Qu’est-ce que je risque si je ne fais rien ?

• Qu’un pirate détruise votre site
• Qu’un pirate détruise votre base de données.
• Qu’un pirate dépose un fichier malveillant qui infecte votre serveur, lequel tentera sans que vous le sachiez d’en attaquer d’autres.
• Qu’un pirate « casse » le système d’exploitation de votre serveur.
• Qu’à force de devoir répondre à des milliers de demande, le CPU de votre serveur soit en surcharge et ne puisse plus faire ce qu’il est supposer faire : mettre à disposition le site web aux internautes.
• Que votre serveur soit infecté puis identifié comme pirate et black-lister

Comment me protéger ?

Il y a plusieurs niveaux de protections possibles  :

Protections préventives :

Exemple de protections par fichiers de paramétrage des services :

• ne pas utiliser le numéro de port habituel (mettre ssh sur un autre port que le 22. Pour le web, ce n’est pas vraiment possible)
• interdire de se loguer en tant que super admin (root) via ssh
• N’autoriser l’accès à phpmyadmin qu’à une ou plusieurs ip via un fichier htaccess (ou ne pas utiliser phpmyadmin !)

Exemple de protection par le pare-feu :

• Fermer tous les ports sauf ceux que vous souhaitez réellement rendre accessible par internet.
• n’autoriser l’accès aux services très sensibles  qu’à votre ip si cette dernière est fixe (comme  ssh et ftp)

Exemple de protection par tunnel :

• N’autoriser l’accès à certains service qu’en local et utiliser un tunnel ssh pour y accéder à distance.

Protection curatives

• L’auto bannissement : après détection qu’une personne a tenté et échoué à plusieurs reprise d’aller là ou elle n’est pas supposée aller , on peut lancer automatiquement une commande du pare-feu qui va bannir cette ip soit temporairement, soit pour toujours.
• détection de malware : des logiciels tels maldet existent sous Linux pour scanner tous les fichiers de vos sites à la recherche de signature de code malveillant qui se seraient glissés dedans.

Les paramétrages de ssh, ftp et l’utilisation des pare-feux sont largement documentés sur internet. Je ne vais m’interresser qu’au système d’auto bannissement.

Mais avant d’en parler, voyons un peu ce qui se passe réellement sur notre serveur hébergé.

Comment je sais si des robots malveillants recherchent une faille sur mon serveur ?

Les fichiers de logs, les journaux systèmes sont là pour ça. Et les consulter fait peur.

Les distributions Linux utilisaient jusqu’il y a quelques années exclusivement des fichiers journaux facilement accessibles (des fichiers texte).  Mais nous sommes à un tournant ou selon les services et selon la version de votre Linux, ces informations seront tantôt dans un journal système, tantôt dans un fichier de log. Le nom du fichier peu aussi changer d’une version de Linux à une autre.

Commençons par le service ssh. Sur un Linux moderne, il stocke les tentatives de connexions dans un journal système accessible par cette commande :

sudo journalctl -u sshd --since "12 jours ago"

journalctl est la commande d’accès au journal
-u signifie « unit », sshd est le nom du service, « since » veut dire depuis et « 12 hoursago » les 12 dernières heures.

Et cela donne des centaines de lignes comme ça :

Jul 07 19:19:39 sshd[1807941]: pam_unix(sshd:auth): authentication failure; tty=ssh ruser= rhost=165.227.42.197 user=adm
Jul 07 19:19:43 sshd[1807941]: Received disconnect from 165.227.42.197 port 40034:11: Bye Bye [preauth]
Jul 07 19:19:43 sshd[1807941]: Disconnected from authenticating user adm 165.227.42.197 port 40034 [preauth]
Jul 07 19:40:24 sshd[1815763]: Invalid user admin from 61.220.155.154 port 36569
Jul 07 19:40:24 sshd[1815763]: pam_unix(sshd:auth): authentication failure; tty=ssh ruser= rhost=61.220.155.154
Jul 07 19:40:27 sshd[1815763]: Connection closed by invalid user admin 61.220.155.154 port 36569
Jul 07 19:43:27 sshd[1816109]: pam_unix(sshd:auth): authentication failure; ruser= rhost=178.62.78.84 user=administrator

Vous avez compris ?

Ces adresses ip (tant pis si certains se reconnaissent) ont tenté d’accéder à mon serveur en ssh (service volotairement non limité à mon ip pour faire cette démonstration) avec des noms d’utilisateurs tels adm, admin, administrator

Et il y a des milliers de tentatives comme celle-ci.

Sur d’autres linux, vous trouverez ces informations dans /var/log/auth.log

Maintenant intéressons-nous aux accès sur le site web (regardez les fichiers access_log dans /var/log/httpd ou /var/log/apache2)

Je regarde juste ceux qui pensent qu’il y a un wordpress à la racine avec la commande

sudo cat /var/log/httpd/access_log | grep wp
2a00:d680:20:50::4a10 - - [26/Jun/2022:09:15:45 +0200] "GET /wp-login.php HTTP/1.1" 404 36
2a00:d680:20:50::4a10 - - [26/Jun/2022:09:15:45 +0200] "GET /wp-login.php HTTP/1.1" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96"
194.242.10.226 - - [27/Jun/2022:18:05:47 +0200] "GET /wp-login.php HTTP/1.1" 404 36
194.242.10.226 - - [27/Jun/2022:18:05:47 +0200] "GET /wp-login.php HTTP/1.1" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96"
161.35.114.17 - - [29/Jun/2022:03:02:05 +0200] "GET /wp-login.php HTTP/1.1" 404 36
161.35.114.17 - - [29/Jun/2022:03:02:05 +0200] "GET /wp-login.php HTTP/1.1" 404 36 "http://acpn.aeroinfo.fr" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36"
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /wordpress/wp-login.php HTTP/1.1" 404 196
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /wordpress/wp-login.php HTTP/1.1" 404 196 "http://acpn.aeroinfo.fr" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36"
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /blog/wp-login.php HTTP/1.1" 404 196
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /blog/wp-login.php HTTP/1.1" 404 196 "http://acpn.aeroinfo.fr" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36"
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /wp/wp-login.php HTTP/1.1" 404 196
161.35.114.17 - - [29/Jun/2022:03:02:06 +0200] "GET /wp/wp-login.php HTTP/1.1" 404 196 "http://acpn.aeroinfo.fr" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36"
185.175.45.32 - - [30/Jun/2022:02:03:30 +0200] "GET /wp-login.php HTTP/1.1" 404 36
185.175.45.32 - - [30/Jun/2022:02:03:30 +0200] "GET /wp-login.php HTTP/1.1" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96"
162.214.145.74 - - [02/Jul/2022:05:57:51 +0200] "GET /wp-login.php HTTP/1.1" 404 36
162.214.145.74 - - [02/Jul/2022:05:57:51 +0200] "GET /wp-login.php HTTP/1.1" 404 36 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96"

Il faut bannir tout ce petit monde

Problème : quand on veut se connecter en ssh, on peut aussi se tromper de mot de passe. Donc il faut une certaine tolérance : On peut tolérer par exemple 3 tentatives de connexions ssh. Ou bannir toute tentative ne provenant par de France. Et /ou faire un bannissement temporaire. Ou encore s’exclure de tout bannissement.

Pour les accès au service web, on peut être plus méchant.

Pour cela, plusieurs options possibles :

• Utiliser un produit existant et gratuit (c’est bien Linux pour ça) tel fail2ban
• Ou développer un ensemble de scripts qui fera cela
• On peut aussi développer un système qui fera des statistiques sur le nombre d’ip bannies et leur répartition par pays.

Fail2Ban

fail2ban est un outil très complet, gratuit qui s’installe simplement via les commandes apt, yum ou dnf selon votre distribution Linux.

Il sait presque tout faire mais plus vous lui en demandez, plus sa configuration se complexifie et ça peut vite devenir une usine à gaz.

Principes de fonctionnement de fail2ban

• fail2ban est un service qui tourne tout le temps
• il scanne les logs et les journaux en recherchant les actions que vous surveillez (ex : tentative de connexion ssh)
• dans les journaux, il recherche les erreurs (échec de connexion pour cause de mot de passe erroné)
• il peut exclure de sa recherche une liste d’ip (dont la votre car vous avez le droit de vous tromper de mot de passe)
• Il compte le nombre d’échec de connexion par ip (ex telle ip s’est trompée 2 fois de mot de passe dans les 3 dernière minutes pour tel service qu’il surveille)
• Arrivé à un nombre d’échec de votre choix, il lance une commande de votre pare-feu (peu importe que ce soit iptable ou firewalld)
• Cette commande va bannir l’ip, soit totalement, soit juste pour le service qu’elle tentait d’accéder et soit de manière permanente, soit pour x minutes (x paramétrable)
• Le bannissement, même permanent est temporaire : au reboot du serveur, les ips bannies ne le sont plus et c’est très bien comme ça (imaginez, vous pourriez vous bannir définitivement , ce serait dommage !)
• En parallèle, il surveille les bannissement et peut débannir automatiquement une ip au bout d’un certain temps (temps paramétrable)
• Il peut (je le déconseille fortement sauf à vouloir remplir sa boite mail en 2 jours), vous envoyer un email à chaque action.

En plus de ces principe de bases, vous pouvez y ajouter vos règles et actions en les développant vous même (mais c’est loin d’être simple) ou en en trouvant sur internet.

Il existe des dizaines de règles et actions  de bases fournies par défaut, vous pouvez activer celles qui vous intéressent.

Ce qu’il ne fait pas par défaut :

• il ne s’intéresse pas aux tentatives d’accès à des pages web qui n’existent pas (ex : tentatives d’accès à phpmyadmin que vous n’auriez pas installé)
• il ne s’intérresse pas aux tentatives d’accès à des pages web dont vous avez interdit l’accès par d’autres moyens (ex: interdiction par fichier htaccess)
• Il ne peut pas surveiller la saisie de mauvais mot de passe sur votre site si ce dernier est propriétaire (à vous de développer alors votre système de protection, par exemple, avec un captcha dans un premier temps)
• Il ne s’intéresse pas au pays d’origine de l’IP
• Nous sommes en 2022 et il  a encore quelques difficultés avec la gestion de l’ipv6 (le mieux est encore de désactiver l’ipv6 sur votre serveur, jusqu’à ce que fail2ban sache correctement les gérer).

Voici une documentation en Français de Fail2ban qui permet de démarrer sereinement avec

Documentation Fail2ban pour Ubuntu

Vos scripts en complément à fail2ban

En complément à fail2ban, on peut développer son propre système de surveillance (ex bannir ceux qui tentent d’accéder à des pages web qui n’existent pas ou qui tentent d’envoyer des scripts shell dan l’url).

Voici un petit exemple que j’ai développé pour m’amuser, pour l’exemple , il est vrai « à la va vite » détaillons ce qu’il sait faire:

L’idée consiste à scanner tous les fichiers de /var/log/httpd dont le nom contient « access » : ce sont les fichiers qui tracent les accès aux sites web hébergés sur le serveur.

On y recherche dans les 10 dernières minutes, certains mots clés par exemple :

• qui s’est pris un http 404 (page inexistante)
• qui s’est pris un http 403 (page d’accès interdit)
• qui a mis ./env dans l’url
• qui a mis du shell dans l’url
• qui veut accéder à xmlrpc.php
• qui cherche à lire la variable XDEBUG_SESSION_START
• etc….

On exclut de cette recherche : notre ip , l’ip locale et l’ip publique du serveur

On compte le nombre de fois pour chaque action ou chaque ip est concernée.

Si ce nombre dépasse une limite de notre choix, on recherche son pays d’origine, (dans le script, je suis plus tolérant avec les tentatives qui viennent de France) on stocke cette ip dans un fichier avec le pays

Pour les critère de notre choix (pays, nombre de tentatives), on va chercher à bannir cette ip définitivement. Pour cela, on regarde si on l’a déjà fait ou non en interrogeant le pare-feu. Si ce n’est déjà fait, on prépare dans un script un fichier qui demandera demande au pare-feu de la bannir en lançant une commande de paramétrage, puis, à la fin, on demande au pare-feu de relire son paramétrage pour prendre en compte les nouvelles règles.

A noter : ce script suppose que vous utilisez firewalld comme pare-feu et que vous avez téléchargé le script getipcountry.py pour récupérer le pays d’origine de chaque ip. Script disponible et expliqué sur ce site ici

Télécharger le script autoban.txt (à renommer en autoban.sh)