| 📰 La Revue de TheRaphit.com | Article n° 38 [26 décembre 2025] |
[Article au hasard 🎲]
[Précédent]
Dernier
|
| 📰 La Revue de TheRaphit.com | Article n° 38 [26 décembre 2025] |
[Article au hasard 🎲]
[Précédent]
Dernier
|
![[Trafic Internet : Humains vs. Bots]](images/rev38/humans-vs-bots.jpg)
Si je vous parle de scan de ports, de recherches de vulnérabilité et de compromission de serveurs, d'exécution de code malveillant ou de vol de mots de passe, il y a des chances que vous allez vous imaginer ceci :
Ahhhhh l'imaginaire collectif du 21ème siècle, c'est magnifique ! Pourquoi on les représente toujours avec un ordinateur portable d'ailleurs ? (Vraie question, je n'en sais rien). Mais en réalité, ce qu'il se passe véritablement dans la Matrice, c'est que ce ne sont que des robots qui vont tenter de se connecter à vos services.
Bien qu'ils soient idiots, les bots ne dorment ni ne se fatiguent jamais. Ils vont sonder des milliards d'adresses IP à répétition, afin de découvrir d'éventuelles vulnérabilités, et par là de nouvelles possibilités pour eux de se répliquer, afin de trouver toujours davantage d'autres serveurs à compromettre.
Une attitude dangereuse consisterait à penser que votre serveur personnel ne présente « rien d'intéressant pour un hacker » et d'ignorer ces problématiques. Mais les bots ne sont pas assez intelligents pour s'en rendre compte. S'ils détectent un service connu pour être facilement exploitable sur votre machine, et même si vous l'avez correctement sécurisée, ils peuvent tenter de se connecter dessus en boucle, vous consommant des ressources pour rien tout en pourissant vos logs au passage.
Ce n'est qu'après avoir compromis un nombre suffisamment important de machines via leurs bots infatiguables que les véritables hackers entrent en scène, constituant des botnets qui leur permettent d'attaquer ensuite les gros poissons qu'ils visent. Vous-même, vous ne les croiserez jamais.
Le Web est bien évidemment populaire, et probablement le service accessible au public le plus répandu sur Internet.
Un serveur Web « lâché » sur le réseau mondial se fait repérer par des robots en une demi-journée tout au plus. Particulièrement en raison des ports TCP utiliés qui sont toujours les 80 et 443, et il est difficile de les changer sur un serveur hébergeant un site destiné à être référencé sur les moteurs de recherche.
Les robots ciblant les serveurs HTTP/HTTPS peuvent se classer en trois catégories :Le risque principal avec un serveur HTTP et ces bad bots, c'est le contenu dynamique et d'une manière générale celui qui est « administré » par un logiciel de type CMS (Content Management System). Je peux citer notamment le fameux Wordpress, qui est un des trucs les plus troués qui soient (n'installez bien pas ça). Un risque similaire est lié aux « WebUI », les interfaces de configuration parfois pré-installées par un hébergeur. Il est clairement préférable de les protéger en changeant cette fois le numéro de port (car ne sont censé y accéder que ceux qui connaissent l'URL) ou en ne les rendant accessibles qu'uniquement via un VPN.
- Les « bienveillants », tels que les robots d'exploration légitimes. Ils se déclarent correctement en tant que tels, et respectent les directives de votre fichier
robots.txt. A noter que tous ne vous apportent pas spécialement de bénéfices, comme ceux qui se contentent d'analyser la structure des sites pour produire toutes sortes de rapports ou surveys concernant le Web. Mais il vous est donc toujours possible de d'interdire l'exploration de votre site à un robot de ce type s'ils vous ennuient.- Ceux de la « zone grise », qui ne se déclarent pas (en se faisant passer pour un navigateur ordinaire) et ignorent le
robots.txt. Ce peut-être pour voler du contenu tout comme le promouvoir : certains moteurs de recherche extraient en effet une partie de votre site (notamment les images) pour agrémenter la présentation des liens. Néanmoins comme il n'est souvent pas possible de déterminer ce que leurs opérateurs souhaitent réellement, c'est à eux que l'on doit la généralisation des CAPTCHA, comprenant entre autres les fameuses cases à cocher « je ne suis pas un robot » dont je parle dans l'introduction.- Les scanneurs de vulnérabilités malveillants, qui vont rechercher des versions de serveur ou des types de contenu qu'ils savent exploitables - le but est souvent de stocker du contenu temporaire sur le serveur ainsi compromis, ou de pouvoir s'en servir comme relais ou proxies pour lancer d'autres attaques.
Je recommanderais également d'éviter de nommer les sous-répertoires de votre site de manière un peu trop « commune », tels que/blogou/backup, activement recherchés par les robots. S'ils en repèrent un sur votre machine, ils vont s'acharner dessus en recherchant des vulnérabilités plus spécifiques correspondant aux CMS qui utilisent ces noms par défaut.
Enfin, dans l'idée de minimiser la charge et les transferts de données supplémentaires induits par les attaques ou tentatives de récupération de contenu, il est préférable de renvoyer de véritables erreurs 404 (avec une page d'erreur légère) lorsqu'un accès à un URL inexistant est tenté, plutôt que de rediriger vers la page d'accueil de votre site. Je peux également vous signaler qu'un bon nombre de robots malveillants n'accèdent jamais à la page cible d'une redirection permanente (code 301).
J'ai commencé à établir plusieurs listes de filtrage visant à bloquer les robots les plus bruyants s'attaquant aux serveurs Web. Certains réseaux en hébergent des palanquées...
Aceville Pte Ltd.
Ancien fournisseur d'accès singapourien, depuis racheté par Tencent, le conglomérat chinois. Un nombre incalculable de bots se faisant passer pour des iPhone sont hébergés sur ce réseau, et sur toutes leurs plages d'adresses IPv4, très nombreuses... Je soupçonne ces robots d'alimenter des « IA » chinoises, et ils semblent clairement vouloir maximiser leurs chances de capter du contenu. Ils ne lisent jamais lerobots.txt, ne chargent que les pages HTML ainsi que les fichiers que vous mettez à disposition en téléchargement (même si vous avez bien spécifié lenofollow), en parcourant l'intégralité de ce à quoi ils ont accès via les liens internes de votre site.
Ils reviennent très souvent, et sont littéralement « hungry for data ». De la vraie saleté de bridé. Voici les plages d'adresses IP que j'ai repérées :Ah oui, ça fait du monde... Un accès type ressemblera à ceci dans vos logs :43.128.0.0/10
49.51.128.0/17
58.48.0.0/21
101.33.0.0/17
101.80.0.0/17
120.68.0.0/14
124.156.0.0/16
125.94.0.0/10
129.226.0.0/16
150.109.0.0/16
162.62.0.0/16
170.106.0.0/16
175.0.0.0/12 182.32.0.0/12
Ils semblent « bloqués » sur un124.156.157.91 www.theraphit.com - [19/Dec/2025:11:14:01 +0100] "GET / HTTP/1.1" 301 0 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1"User-Agentd'iPhone sous iOS 13.2.3, version qui leur est spécifique : c'est une bonne manière de les repérer.
Bezeq International
Ahhh alors eux ils sont magnifiques car ils permettent bien de comprendre ce dont il retourne. A la base, c'est simplement une société israélienne exploitant des datacenters. Mais ils y hébergent des robots agressifs qui chargent absolument tout le contenu d'un site une fois repéré, images comprises.
Ces robots sont liés à picrights.com, un site de « copyright claim » :
![[Capture site Web picrights.com]](images/rev38/picrights.jpg "PicRights.com, de la bonne saloperie")
Ah oui, comme vous le voyez c'est de la bonne saloperie.
Ils sont l'illustration parfaite de ce que les robots « zone grise » peuvent chercher à obtenir avec votre site : de quoi vous emmerder. Prenez une pauvre image déjà en accès libre partout sur Internet et intégrez-là à votre contenu, et vous pourriez recevoir des requêtes vous demandant de la retirer de la part de cette entreprise. Avec je-ne-sais-quelles conséquences en cas de refus. Ca vient d'Israel, ce sont les mecs qui ont réussi à mettre des bombes dans les pagers de milliers de terroristes, il faut se méfier d'eux. De la grosse shitasse bien malodorante que j'ai immédiatement filtrée dès que je l'ai repérée.
En effet lors d'une de leurs requêtes, ils ont inséré leur nom de domaine en tant queHTTP_REFERER, et j'ai pu le voir grâce aux statistiques d'accès à mon site (d'où l'intérêt d'en tenir). Par suite je suis remonté jusqu'à leur requête d'origine dans mes logs :Ahhhh la petite erreur fatale. :-) A côté de ça, il était quasi-impossible de voir qu'il s'agissait d'un robot, leur2a06:c701:7275:b600:20ca:9315:2d4b:4560 www.theraphit.com - [23/Apr/2025:09:29:08 +0200] "GET / HTTP/2.0" 200 16636 "https://ops.picrights.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0"User-Agentet leur motif d'accès imite parfaitement celui d'un Firefox sous Windows.
Ils utilisent assez peu d'adresses :Hé oui, il y a même de l'IPv6, c'est Israel donc cay modayrn !82.80.240.0/21
2a06:c701:6000::/32
3XK Tech
Alors là attention, terrain miné !
Ce réseau abrite tout un tas de robots extrêmement agressifs pour les serveurs Web, on est littéralement sur du « bombardement » de requêtes, à la limite du déni de service. Situé en Allemagne, ce réseau a l'air tout ce qu'il y a de plus respectable, mais il n'en est rien.
Je recommande vivement le filtrage de toutes les plages d'adresses IP depuis lesquelles j'ai détecté des attaques, et il y en a un certain nombre :Allez hop, ça dégage.45.3.32.0/20
45.3.48.0/21
65.111.0.0/19
104.207.32.0/19
209.50.160.0/19
216.26.224.0/19
Babbar
Tiens donc, une boîte française ! Remarquez ça change un peu des chinois et des russes.
Celle-ci exploite un robot d'exploration, censé être un indexeur pour un moteur de recherche. Cependant, sur leur page dédiée ils n'en donnent aucunement l'adresse, ce qui est particulièrement suspect. Généralement ce type de service est promu au passage.
Bon, ça pourrait encore passer... Si leur biniou n'était pas totalement codé avec les pieds. Le robot accède en effet de multiples fois aux mêmes pages, en utilisant des chemins alternatifs. Quelques exemples :Ah oui, c'est du grand art... Vous allez me dire que, comme avec tout robot ne se dissimulant pas, il est normalement possible de lui refuser l'accès via le fichier217.113.196.214 www.theraphit.com - [19/Dec/2025:11:58:05 +0100] "GET /math/groupe_sym.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.224 www.theraphit.com - [19/Dec/2025:12:02:20 +0100] "GET /../../math/tenseurs.html HTTP/1.1" 200 31253 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.234 www.theraphit.com - [19/Dec/2025:12:08:39 +0100] "GET /../math/tenseurs.html HTTP/1.1" 200 31253 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.195 www.theraphit.com - [19/Dec/2025:12:09:29 +0100] "GET /math/hp-48gx.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.195 www.theraphit.com - [19/Dec/2025:12:41:39 +0100] "GET /../../math/hp-48gx.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.209 www.theraphit.com - [19/Dec/2025:12:42:03 +0100] "GET /../../math/groupe_sym.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
217.113.196.206 www.theraphit.com - [19/Dec/2025:12:46:46 +0100] "GET /../math/hp-48gx.html HTTP/1.1" 304 0 "-" "Mozilla/5.0 (compatible; IbouBot/1.0; +bot@ibou.io; +https://ibou.io/iboubot.html)"
robots.txtpour s'en débarrasser... Oui mais « petit » problème : il en ignore cordialement les directives. Ce qui ne fait encore qu'ajouter aux nombres de requêtes effectuées par ce parasite. Pas le choix, il faut filtrer au niveau inférieur.
La société ne dispose visiblement que d'un unique/24:L'intégralité de celui-ci semble utilisé pour les requêtes de ce robot. Ahhhh elle est magnifique la « startup nation » n'est-ce pas ? C'est non. Au gnouf !!217.113.196.0/24
J'ai regroupé toutes les plages d'adresses IPv4 (et IPv6 pour Bezeq) listées ci-dessus dans un unique fichier, que je vous mets à disposition :TheRaphit's Web Baddies BlacklistCelle-ci n'est pas mise à jour régulièrement vu que je n'ai pas fait de script automatique pour l'alimenter. Les mises à jour seront donc signalées via ma page des nouveautés.
Notez que je n'ai pas placé de commentaires dans le fichier, pour ne pas perturber l'utilisation directe de celui-ci par un système automatique d'ajout de règles. Les préfixes sont regroupés par fournisseur, dans le même ordre que sur cette page.
Vous pourrez trouver sur Internet plusieurs listes vous permettant de bloquer les connexions depuis les gros hébergeurs (AWS, Azure, ...) si cela vous intéresse. Néanmoins ce n'est pas quelque chose que je recommande pour un serveur public, car il existe un certain nombre de robots bienveillants hébergés sur ces énormes réseaux. Ce type de liste est plutôt destinée aux serveurs hébergeant justement des WebUI, ou un portail d'extranet.
Le saviez-vous ? OpenSSH, l'implémentation SSH du projet OpenBSD, est le logiciel le plus utilisé au monde. Il n'est pas employé que sur cet OS, mais sur tous. Windows 10 et 11 sont livrés avec OpenSSH ! Et tout comme les systèmes Microsoft, ce programme a été historiquement sujet à de nombreuses vulnérabilités... SSH est donc une cible de choix pour les robots malveillants et leurs maîtres issus de râclures de fonds de chiottes.
Etant donné que de nombreux petits équipements embarqués utilisent aussi SSH pour l'accès distant, il existe un grand nombre de combinaisons de nom d'utilisateur et de mot de passe par défaut, et bien évidemment les robots vont se faire un plaisir de tout essayer en boucle, générant parfois un nombre important de connexions TCP pour cela.
C'est véritablement casse-bonbons, et tout spécialement parce que la plupart de ces robots sont programmés absolument n'importe comment. Même si vous avez désactivé l'authentification par mot de passe, ce que le serveur SSH indiquera clairement au premier échec de connexion, cela ne vous protègera en rien. Les robots ne tiennent jamais compte des messages d'erreur qu'ils reçoivent, et peuvent continuer de tenter de se connecter des jours entiers une fois qu'ils ont repéré votre machine.
Pour cette raison, si vous ouvrez un serveur SSH to da weurld, je vous conseille vivement de changer le port d'écoute afin de ne plus utiliser le port 22. Si vous ne le faites pas, votre machine sera probablement repérée dans les heures qui suivent sa mise en ligne, et le nombre de tentatives de connexions sera rapidement conséquent.
J'ai mené plusieurs expériences sur le sujet, et voici ce que j'ai constaté :Je me sers d'une de mes machines en tant qu'« appât » pour attraper ces robots stupides comme les pieds de leurs programmeurs. Il est bien sûr configuré pour écouter sur le port 22, et pour bannir immédiatement l'adresse IP source d'une tentative de connexion. Ceci me permet de constituer une liste d'adresses IP de robots auxquels j'interdis par suite l'accès à l'ensemble de mon réseau une fois qu'ils se sont fait piéger.
- Utiliser les numéros de ports « alternatifs » classiques - Soit les 2022, 2222, 4022, 8022 ou accabits. Il y a clairement du mieux, mais ces ports sont généralement connus des bots et votre machine finira par se faire repérer. En ayant même testé avec le 7022, je peux vous dire que tout ce qui se termine par '22' est à éviter.
- Opter pour un numéro de port exotique - Comme 11043, 32502 et plus généralement des numéros de ports à cinq chiffres. Etonnamment, là de suite ça n'a rien à voir. Une fois ou l'autre vous verrez sûrement passer quelques scans, mais il s'agit le plus souvent de robots qui ne recherchent pas spécialement de serveur SSH, et qui ne vont même pas voir (grâce à la bannière) qu'ils viennent d'en trouver un. Après avoir laissé tourner
tcpdumpsur des serveurs SSH ouverts avec des ports de ce type pendant plusieurs mois, je n'ai vu passer que quelques scans, et aucune réelle tentative de connexion.- N'accepter les connexions SSH qu'en IPv6 - Alors là c'est magique, vous n'aurez carrément même plus aucun scan. Il y a suffisamment à faire avec IPv4 pour nos amis les robots, et le nombre élevé d'adresses IPv6 rend la recherche de serveurs n'utilisant que ce protocole très inefficiente, et ce même en restreignant aux blocs connus des hébergeurs. Si vous disposez d'une connexion IPv6 aux différents endroits où vous pourriez avoir besoin de vous connecter à votre machine à distance, c'est la solution idéale.
Cette liste est triée, retraitée avec CIDR Aggregate, et si cela vous intéresse, vous pouvez la récupérer ici :TheRaphit's fail2ban SSH BlacklistJe l'utilise au quotidien depuis des mois, sans m'être retrouvé face à un site ou service inaccessible sur Internet. Elle est mise à jour automatiquement toutes les nuits !
Si vous mettez en ligne un serveur DNS, sachez que celui-ci peut se faire repérer parfois encore plus vite qu'un nouveau serveur SSH. Les robots vont notamment tenter quelques requêtes basiques pour déterminer si le serveur est un « résolveur ouvert », à l'image des fameux8.8.8.8de Google ou1.1.1.1de Cloudflare.
Le but recherché par les pirates, c'est de pouvoir réaliser des attaque par amplification DNS, un type particulier de déni de service distribué (DDoS).
![[Schéma d'une attaque par amplification DNS]](images/rev38/dns-amplification-attack.jpg)
Etant donné que cette attaque n'utilise un résolveur qu'en relais, et que la cible n'a généralement rien à voir, vous pourriez tout à fait me dire « est-ce que c'est mon problème ? » Le fait est que, bien que ce ne soit en effet pas votre serveur qui soit directement visé, le nombre de résolveurs ouverts sur Internet à un instant donné reste plutôt faible. Les requêtes spoofées dirigées vers votre serveur risquent donc déjà de constituer un déni de service à elles toutes seules.
C'est la raison pour laquelle je ne propose pas un tel service de résolveur ouvert via mon site, pour contourner les DNS menteurs par exemple.
Si vous avez choisi d'héberger vous-même vos noms de domaine, assurez-vous donc que la fonction de résolveur est désactivée dans votre logiciel serveur DNS. Par exemple sur BIND, cela se fait très simplement, tout au début dunamed.conf:Certains autres logiciels, comme NSD, n'ont tout simplement pas de fonction de récursion. Cela vous met à l'abri de toute dinguerie potentielle !// Main configuration
options {
directory "/var/named";
(...)
recursion no;
(...)
listen-on { any; };
};
Honnêtement, faire tourner un serveur SMTP, c'est un peu le nid à emmerdes. De nos jours, il est bien plus pratique de faire héberger sa messagerie en SaaS.
Néanmoins, le faire reste aujourd'hui pratiquement le seul moyen de disposer d'adresses e-mail pseudo-anonymes et « jetables » facilement, sans même avoir besoin d'un nom de domaine dédié. Une adresse de typemoi-meme@serveur.domaine.tld(sans avoir a spécifier un MX) fonctionnera toujours, et aucun système vous demandant une adresse e-mail valide ne vous la refusera !
Les spammeurs recherchent en permanence de nouveaux serveurs SMTP « ouverts » (plus exactement open relay) pour pouvoir envoyer leur merde. Au contraire du DNS, il n'y a aucune bonne raison de maintenir un tel serveur, et personne de censé ne le fait. Comme il n'est pas possible de changer le port SMTP (25), les options de mitigation sont peu nombreuses, et vous devrez subir les scans...
Il y a toutefois une manière assez simple et inattendue d'avoir relativement la paix : refuser les connexions SMTP depuis les adresses IP ne disposant pas de DNS inverse. Sur le logiciel Postfix que j'utilise, cela se fait très simplement en rajoutant la directivereject_unknown_reverse_client_hostnamedans le fichiermain.cf, au niveau de la lignesmtpd_recipient_restrictions. Elle ressemblera alors à ceci :Un très grand nombre de robots testant les serveurs SMTP sont évidemment une fois de plus situés dans des pays tendancieux et sont hébergés sur des machines dont les adresses IP n'ont presque jamais de nom DNS associé. Cela a donc l'avantage mettre rapidement fin à l'échange SMTP, avec un minimum de ressources dépensées de votre côté.smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unknown_reverse_client_hostname reject_unauth_destination
L'autre astuce assez magique consiste à bloquer les connexions depuis les relais de sortie Tor vers votre serveur SMTP. Ce réseau n'est pas un mal en soit, j'ai même écrit un guide sur Tor, mais c'est malheureusement très utilisé par les spammeurs pour se cacher.
Vous pouvez par exemple utiliser cette liste publique :Tor Exit - Daniel Austin (clic-droit puis « enregistrer sous... » depuis le nouvel onglet)Sachez que même en restreignant la distribution de vos adresses e-mail à des tiers pourtant à priori dignes de confiance vous receverez du spam. Vous n'êtes jamais à l'abri d'une vente de données, et même une organisation 100 % honnête (s'il en existe encore) peut se faire pirater ses bases.
Webzine : La Revue
[Manga Pink Zone]
[Mathématiques]
![[Hacker des temps modernes]](images/rev38/21s_hacker.jpg)