Le contexte
Fin 2021, suite à la réinstallation d’Apache sur mon serveur de développement à mon domicile et à l’expérimentation du pointage d’un nom de domaine sur celui-ci, je me suis interrogé au sujet des moyens de le sécuriser.
Dans un premier temps, je me suis tourné vers Cloudflare pour atténuer les potentielles attaques DDOS et masquer mon IP fixe mais l’observation des logs d’Apache me laissait comprendre que beaucoup de requêtes malveillantes continuaient à s’accumuler quotidiennement.
De fait, j’ai d’abord penser à installer le puissant logiciel Crowdsec sur mon poste. Malheureusement, Crowdsec ne fonctionne pas avec macOS. J’ai bien essayé de basculer mon serveur Apache dans une image Linux avec Docker et d’y ajouter Crowdsec mais cela s’est révélé impossible.
En effet, contrairement à la version Linux de docker, la version macOS ne permet pas de mise en réseau en mode –net=host. Cela a pour conséquence de limiter l’usage de Docker au transfert de port (port forwarding) en mode bridge, puis d’empêcher que les logs Apache reportent les IP réelles des émetteurs de requête. Les logs reportent l’IP de l’hôte local et Crowdsec devient dès lors inutilisable.
Je n’ai découvert que récemment Docker Mac Net Connect qui aurait pu me permettre de contourner ce problème car il permet de connecter directement une IP à un container. Dommage !
Fail2ban sur Mac, ça marche !
C’est ainsi que je me suis tourné vers le logiciel Fail2ban. Conçu pour fonctionner sur Linux, il est tout de même possible de l’installer sur Mac. Le moyen de le plus simple de le faire est d’utiliser Homebrew avec la commande suivante :
brew install fail2banFail2ban en bref
Fail2ban surveille l’activité réseau de serveurs, notamment sur les ports de communication dédiés au SSH, FTP et HTTP, en analysant, en temps réel, les logs des applications qui utilisent ces services. S’il détecte une activité suspecte de la part d’une IP en particulier, il transfère l’adresse IP à un firewall et lui interdit ainsi l’accès au serveur pendant une durée déterminée.
Si vous souhaitez mieux comprendre le principe de fonctionnement de Fail2ban et apprendre sa configuration avec Linux, notamment la rédaction de filtres via expressions régulières, je vous conseille cet excellent tutoriel de Graphikart : https://www.youtube.com/watch?v=-rmK50PbqCY&t=100s
PF firewall
Bien entendu, comme jamais rien n’est aussi facile qu’on peut se l’imaginer, beaucoup des logiciels fonctionnant potentiellement en combinaison avec Fail2ban pour gérer la partie firewall ne fonctionnent pas avec macOS. C’est notamment le cas d’iptables. Je le cite parce qu’il semble être celui qui est le plus couramment utilisé en combinaison avec Fail2ban sur Linux. Le premier firewall qui s’est avéré utilisable sous macOS en combinaison avec Fail2ban a été pour moi PF (Packet Filter).
PF est livré avec macOS dans le dossier /private/etc/pf.conf.
Comme pour Fail2ban, PF se pilote via lignes de commande. Il n’est donc pas du tout convivial ! Pour corser le tout, sous macOS Monterey, je n’ai pas trouvé le moyen de créer une table d’IP fonctionnelle par simple lignes de commande. J’ai du bricoler en utilisant un fichier texte que je mettais à jour via un shell script. C’est un peu rudimentaire car je dois procéder à un redémarrage de PF à chaque ajout ou suppression d’IP dans le fichier texte mais l’essentiel est que cela fonctionne !
Je vous passe également l’étape de configuration d’Apache et de Cloudflare afin de récupérer la véritable IP de l’émetteur de la requête dans les logs d’Apache.
Le projet f2b Admin
Comment ça marche ?
C’est pour pallier à ce problème de convivialité de Fail2ban que je me suis engagé dans la conception d’un dashboard d’observation de son activité. En effet, je rencontrais des difficultés pour :
- évaluer l’efficacité des patterns de détection mises en place sur le long terme,
- avoir une vue d’ensemble des motifs de requêtes indésirables récurrents,
- quantifier le nombre des attaques quotidiennes,
- identifier les IP selon leurs origines géographiques.
Le principe de fonctionnement du dashboard est simple : à chaque fois qu’une IP est interceptée par Fail2ban, les informations collectées sont automatiquement dupliquées dans une base de données MySQL en même temps que les données de WHOIS de l’IP bannie, récupérées elles via une commande Shell.
L’interface de monitoring f2b admin s’occupe ensuite :
- d’afficher les informations collectées dans la base de données MySQL sous forme de tableau paginé et paramétrable,
- d’organiser ces données sous forme de statistiques graphiques,
- de permettre la lecture des logs de Fail2ban, des Shell scripts et du serveur Apache.
La technologie
Pour réaliser ce projet, l’intention était de faire appel le moins possible à des frameworks de développement externes afin de mettre à l’épreuve mes connaissances du PHP et du Javascript natifs, d’apprendre quelques notions de Shell script et d’aboutir à un projet léger et facilement accessible.
Il s’agissait également de réaliser un dashboard responsive moderne sans avoir à trop me préoccuper de l’intégration front-end. C’est pourquoi je me suis appuyé sur le modèle d’admin responsive SNEAT basé sur Bootstrap (Il est également disponible dans le cadre d’un développement avec Laravel). Il réunit, selon moi, toutes les qualités pour proposer une bonne expérience utilisateur.
Ce projet comporte certainement beaucoup d’imperfections dans son écriture et pourrait évoluer pour proposer de nouvelles fonctionnalités mais il a au moins le mérite d’exister ! Après de nombreuses recherche sur le Web, je n’ai rien vu de tel qui soit adapté à un serveur Web personnel hébergé sur macOS.
La prochaine étape de ce projet est de le proposer sur GitHub. To be continued!
Retour d’expérience
Au delà de l’exercice de programmation qu’elle représente, la conception de cette interface m’aura permis de disposer d’un véritable outil d’analyse du trafic sur mon serveur Web.
Après 6 mois d’utilisation, je suis en mesure de dégager les informations suivantes :
15 IP exclues en moyenne quotidiennement
Fail2ban exclue en moyenne 15 IP quotidiennement sur mon serveur, avec un minimum de 6 et un maximum de 34 alors que ce poste n’est qu’un simple serveur de développement dont aucun des domaines n’est référencé sur les moteurs de recherche. C’est à la fois peu et beaucoup pour un serveur anonyme mais cela n’est significatif que si on prend en compte la sévérité des règles mises en place avec Fail2ban.
Des attaques ciblant l’IP
La majeure partie des requêtes sont faites directement sur mon adresse IP tandis qu’une très petite partie se dirige vers le principal domaine pointant sur mon serveur : ctrlclic.com. De fait, je présume que beaucoup de ces robots scannent continuellement toutes les IP actives sur le Web et très peu s’intéressent directement à des noms de domaine sans référencement.
La moitié des IP bannies ne sont pas anonymes
Il est facilement possible d’associer un bonne moitié des IP bannies à un nom de domaine. Autrement dit, les robots ne cherchent pas particulièrement à se cacher. Certains, tels que Stretchoid, s’annoncent d’ailleurs sur leur page d’accueil comme des plateformes d’identification de services en ligne. De mon côté, je dois préciser que je bannis systématiquement toute requête directe sur mon IP et que je suis plus souple avec les requêtes concernant le domaine et les sous-domaines en permettant 4 requêtes consécutives aboutissant à des erreurs dans une plage de temps de 10 minutes.
Les requêtes se concentrent sur les Web services
Une bonne partie des requêtes se concentrent sur OWA (Outlook Web Access), WordPress, PhpMyAdmin, Microsoft Exchange et, dans une moindre mesure, Git et AWS (Amazon Web Services). L’utilisation de ces services nécessite donc d’être particulièrement attentif à leur sécurisation.
Les robots recourent à des plages d’IP
Les organisations les plus structurées opèrent en faisant appel à des plages d’IP. Dès qu’une de ses IP est bannie, un robot pourra envoyer ensuite plusieurs requêtes successives différentes en utilisant une autre IP.
Les attaques semblent surtout provenir des USA
Environ 60% des exclusions concernent des IP enregistrées aux USA ! Arrivent ensuite les IP originaires des Pays-Bas avec presque 13%. Viennent seulement après (dans l’ordre) la Chine, le Royaume Uni, l’Australie, la Russie, l’Allemagne et la France avec moins de 5% de leurs IP excluent.
Il est difficile de tirer des conclusions de cette information car si ce sont les robots d’origine états-unienne qui explorent manifestement le plus le Web, il est impossible d’évaluer le nombre d’organisations d’origine réellement états-unienne qui se cachent derrière ces robots.
La législation des USA est suffisamment permissive pour permettre à des organisations étrangères aux USA d’opérer avec des IP enregistrées sur leur territoire. Il en va visiblement de même pour les Pays-Bas. On peut cependant émettre l’hypothèse plausible que l’origine géographique réelle des organisations dissimulées derrière des IP états-uniennes et néerlandaises est relativement proportionnelle à celle des organisations qui la révèle directement.
1/3 des pays du monde se livrent à des activités suspectes sur le Web
65 origines géographiques différentes sont concernés par les exclusions d’IP. Autrement dit, un tiers des pays du monde semble utiliser des robots pour explorer le Web, si l’on évalue le nombre de pays dans le monde à 195 selon la reconnaissance officielle de l’ONU.
Cette information doit elle aussi être relativisée mais cela signifie tout de même qu’une grande majorité des pays du monde n’a pas d’activité d’exploration sur le Web ou sinon de façon exclusivement anonyme ou dissimulée.
1/3 des requêtes proviennent d’organisations structurées
72% des IP exclues ne sont jamais revenues sur mon serveur. Inversement, 28% des IP y ont une activité récurrente. Je doute que les auteurs des activités d’exploration aient mis en place des dispositifs afin de ne jamais s’adresser plusieurs fois à un même serveur en utilisant la même IP. Cela ne me semble pas applicable à toute l’étendue des adresses IP liées à un serveur Web. Par conséquent, j’en déduis que seulement 28% des “attaques” correspondent à des activités structurées. La grande majorité des auteurs seraient donc des sortes de hackers amateurs.
Pour savoir qui se cache réellement derrière une IP, il faut creuser !
Dans le classement des IP uniques excluent le plus grand nombre de fois arrivent en tête et dans l’ordre des IP d’origine néerlandaise, russe, anglaise et états-unienne. S’en suivent quelques IP turques, panaméennes, seychelloises, chinoises, hongkongaises, australiennes et européennes.
La majorité des IP de ce classement demeure d’origine états-unienne et néerlandaise. Je note que même si quelques IP russes arrivent en tête, elles sont très peu présentes dans le classement. D’autant qu’après une brève recherche au sujet des 3 premières, il semble que la première IP russe du classement appartienne à une entreprise d’électronique taïwanaise ! Cette même entreprise semble être également liée à l’IP néerlandaise arrivant en tête de classement ! Cette dernière IP renvoyant désormais des informations de WHOIS la rattachant à la Russie mais avec une adresse d’enregistrement à Chypre ! Tout est fait pour brouiller les pistes, à l’instar des procédés d'”optimisation” ou d’évasion fiscale.
Bilan
L’expérience confirme qu’un serveur exposé au Web, même anonymement, est l’objet de requêtes continuelles et qu’il est essentiel de se préoccuper de sa sécurisation sans laquelle on peut s’attendre, un jour ou l’autre, à une mauvaise surprise. Mon analyse s’est cantonnée à la surveillance des ports 80 et 443 mais on pourrait tout autant se pencher sur les activités des ports SSH, FTP ou RDP qui sont également très sollicités. Cette exercice donne la mesure des risques encourus par les serveurs professionnels et grand public dans le monde.