Internet n’est plus un refuge sûr

 (brainbaking.com)
9 points par GN⁺ 2025-11-17 | 1 commentaires | Partager sur WhatsApp
  • Des cas de serveurs personnels mis hors service par un volume excessif de requêtes provenant de bots de scraping IA ont été signalés
  • L’analyse des logs a confirmé des tentatives d’accès intensives depuis la plage d’IP hébergée à Singapour (47.79.*) de Alibaba(US) Technology
  • Des User-Agent falsifiés au format Mozilla/5.0 ont neutralisé les systèmes classiques de détection de bots
  • Les systèmes de blocage automatique de Fail2ban et Nginx ont été surchargés, rendant nécessaire un blocage manuel de toute la plage d’IP
  • À force d’attaques répétées, les exploitants de serveurs personnels voient leur environnement d’auto-hébergement se fragiliser, poussés vers des plateformes centralisées

Cause de la panne du serveur et première réponse

  • Il y a quelques jours, le petit serveur qui hébergeait le site a été temporairement interrompu par une attaque de bots de scraping
    • Des attaques similaires s’étaient déjà produites, et l’adoption d’outils de défense plus robustes comme Anubis est à l’étude
    • Les attaques répétées réduisent chez les développeurs indépendants l’envie de créer et le plaisir du hobby
  • Après des lenteurs d’accès au serveur, une vérification avec la commande top a montré que Gitea et Fail2ban occupaient presque tout le CPU
    • Même après l’arrêt du processus Gitea, la charge de Fail2ban n’a pas diminué, et les logs d’accès Nginx explosaient

Analyse des logs et schéma de l’attaque

  • Les logs ont enregistré de nombreuses requêtes HTTP 502 visant le chemin /commit/
    • Les en-têtes de requête utilisaient des User-Agent se faisant passer pour des navigateurs ordinaires, comme Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
    • La plupart des outils d’inspection des User-Agent les ont considérés comme du trafic normal, permettant une évasion de la détection
  • Les IP attaquantes provenaient de plusieurs adresses et non d’une source unique, mais avaient en commun l’usage de la plage 47.79.*
    • Une recherche via ipinfo.io a montré que cette plage appartient à Alibaba(US) Technology Co., Ltd.
    • Des cas d’attaque signalés impliquant la même plage d’IP existent aussi sur des forums comme PhpBB

Mesures défensives et limites

  • Fail2ban analysait les logs Nginx en temps réel pour appliquer des règles de blocage, mais l’explosion du volume de logs a provoqué des retards de traitement
    • Un script a été lancé pour bloquer immédiatement les IP tentant d’accéder à /commit/, mais il existait des limites de vitesse
    • Au final, toute la plage 47.79.0.0/16 a été bloquée manuellement via la commande iptables
  • Ce type de réponse n’est qu’un palliatif temporaire, et les attaques depuis de nouvelles plages d’IP risquent de continuer
    • L’utilisation de services de protection externes comme Cloudflare ou de systèmes de défense avancés comme Anubis est envisagée
    • Mais leur adoption reste hésitante, notamment en raison du refus de passer par des serveurs américains dotés de fonctions de traçage

Les difficultés de l’exploitation d’un serveur personnel

  • Le transfert de l’instance Gitea vers Codeberg est à l’étude
    • Sous la pression d’attaques répétées, les opérateurs de serveurs personnels ont tendance à abandonner l’auto-hébergement pour migrer vers des plateformes centralisées
    • Cette dynamique contribue à affaiblir la décentralisation et l’autonomie d’Internet
  • D’autres blogueurs signalent eux aussi des attaques similaires, ce qui en fait un problème qui touche l’ensemble des petits exploitants web

Autres anomalies de trafic observées

  • Des en-têtes Referer falsifiés pointant vers des domaines de grandes entreprises comme bioware.com, mcdonalds.com et microsoft.com ont été observés
    • En réalité, ces sites ne fournissaient aucun lien, et l’on constate une hausse de trafic dont l’objectif reste flou
  • Même si les attaques se répètent, l’auteur affirme sa volonté de ne pas renoncer à l’auto-hébergement
    • La fin de l’article insiste sur cette détermination avec la formule « Get Hostin’ Or Die Tryin’ »

À lire aussi

1 commentaires

 
GN⁺ 2025-11-17
Avis Hacker News

  • J’ai l’impression qu’Internet n’est plus vraiment un espace sûr pour les développeurs amateurs de logiciels
    J’administre mes propres serveurs depuis environ 2005, et ils ont toujours été attaqués dès qu’ils étaient mis en ligne
    Surtout quand on leur attribue un nom DNS ou qu’on utilise un certificat TLS, car l’exposition dans les journaux de transparence des certificats semble aggraver les attaques
    Dès qu’un site web est rendu public, le trafic malveillant afflue, et si on met une certaine organisation en colère, on a l’impression qu’elle paie quelqu’un pour tenter un DDoS
    Entre les crawlers, les botnets, les attaques automatisées et les gens furieux, c’est devenu une routine annuelle
    J’ai essayé plusieurs hébergeurs, mais le résultat était globalement le même

    • Avant, mon livre d’or PHP bricolé se transformait en site de spam XSS en quelques jours
      Une fois, je n’avais pas mis WordPress à jour et il a été infecté par du spam SEO en quelques heures ; une autre fois, j’ai exposé Redis par erreur sur Internet et un RAT de botnet y a été installé
      Mais je ne pense pas que cela veuille dire qu’Internet est « dangereux »
      Au contraire, c’étaient des expériences qui m’ont montré ce que je devais apprendre
      Depuis, j’utilise des star-cert pour éviter d’apparaître dans les journaux de certificats, j’ajoute une authentification de base, je maintiens des sauvegardes et j’exploite mes services avec prudence
      Le vrai danger, à mon avis, c’est quand des gens qui ne comprennent pas la technique installent n’importe quel .exe et livrent toutes leurs informations à Facebook ou TikTok
    • J’exploite moi aussi un domaine personnel, que personne ne visite à part moi, et pourtant les attaques de bots ne s’arrêtent jamais
      La plupart des requêtes visent des failles WordPress, alors que je n’ai jamais utilisé WordPress
      La première fois que j’ai vu les logs, ça m’a choqué, mais aujourd’hui je considère ça comme la routine
    • Pour me moquer des attaquants, j’ai créé un « HTTP Adventure » que j’ai installé sur des chemins d’administration connus
      Exemple : https://www.masswerk.at/wp-admin
    • Vers 2008, j’exploitais un site professionnel avec un PageRank 6, et c’est à ce moment-là que les attaques de Script Kiddies ont explosé
      C’était l’époque où se diffusaient les outils qui scannaient des plages IP et trouvaient automatiquement les vulnérabilités
      Le web de 1995 à 2008 me manque, l’époque des Web Rings, de Technorati et des fansites
      Référence : Wiki Script Kiddie
    • Plutôt que de dire « j’ai toujours été attaqué », il serait peut-être plus juste de dire que le trafic a en pratique été « monétisé »

  • J’utilisais autrefois une zipbomb pour bloquer les bots, et c’était efficace
    Mais après en avoir parlé sur HN, de nouveaux bots ont afflué et mon serveur à 6 $ n’a pas tenu le coup
    Il était impossible de servir 100 000 requêtes par jour avec des payloads de 1 à 10 Mo
    Ensuite, je me suis mis à ne cibler que certains bots, à créer un honeypot pour collecter des IP et à répondre en 403
    Au bout de quelques mois, le trafic est revenu à un niveau normal

    • Ce type de technique anti-bots semble avoir un potentiel commercial
      Cela dit, je ne sais pas qui serait le client cible. La plupart des utilisateurs en auto-hébergement n’ont pas beaucoup d’argent

  • Mon serveur cgit est lui aussi visité depuis un an par des scrapers
    Cela dit, ils ne font que 2 ou 3 requêtes par minute, donc c’est un bot plutôt « poli »
    Ce qui est drôle, c’est que le code que j’y publie peut être cloné directement depuis l’upstream, donc ce scraping est complètement superflu
    Quand on regarde les logs, c’est vraiment une automatisation inefficace

  • En configurant directement la limitation de débit de Nginx, on peut régler ça plus simplement qu’avec Fail2ban
    Billet de blog de référence : https://blog.nginx.org/blog/rate-limiting-nginx

  • C’est difficile à appliquer à un service public comme un blog, mais pour de l’auto-hébergement personnel, je recommande de configurer une authentification mTLS sur le reverse proxy
    Les requêtes sans certificat sont bloquées immédiatement, et seuls mes appareils peuvent accéder au service
    Une fois en place, on n’a presque plus à s’en occuper

    • Mais je pense que Wireguard est encore mieux
      La configuration est simple et ça fonctionne bien sur Android et iOS
      Aujourd’hui, tous mes services auto-hébergés ne sont accessibles qu’à l’intérieur d’un VPN Wireguard, et le pare-feu ne laisse ouvert que le port de Wireguard
    • En revanche, pour un service comme un blog auquel d’autres personnes doivent accéder, mTLS est peu réaliste

  • Anubis se débrouille bien dans ce jeu du chat et de la souris avec les bots
    Mais seules des plateformes comme Cloudflare, qui disposent de données massives sur le trafic, savent vraiment bien bloquer sur la base de la réputation IP
    Les petits opérateurs n’ont souvent d’autre choix que de bloquer des plages IP entières, ce qui est inefficace
    Il faudrait une solution qui, comme Crowdsec, partage des données de réputation pour bloquer les IP malveillantes et fournisse un défi simple sans JS
    Avec ce genre d’approche, il deviendrait peut-être plus facile pour les développeurs amateurs d’exploiter à nouveau leurs services

  • Mon instance Gitea a elle aussi récemment subi du scraping via des IP et ASN distribués
    Si ce sont des entreprises d’IA bien financées, Anubis aura probablement du mal à les bloquer
    J’envisage donc un poisoning pour scrapers : servir des données poubelles au lieu du vrai code

    • On voit maintenant apparaître des services proxy qui prétendent fournir des IP « approvisionnées de façon éthique (résidentielles) »
      Ce genre de service rend le scraping encore plus difficile à contrer

  • Ce qui devient populaire finit toujours par se retrouver entre les mains du grand public puis se dégrader
    J’ai donc l’impression que la seule solution est de continuer à migrer vers de nouveaux espaces

  • Depuis que j’ai migré mon DNS vers Cloudflare, je reçois en continu d’étranges paquets SYN
    Il arrive une requête par seconde sur les ports 443 ou 22, mais après le SYN-ACK, il n’y a aucune réponse
    La plupart semblent venir d’hébergeurs VPS pour serveurs de jeux, souvent basés au Brésil
    Je capture donc les paquets SYN, je fais des requêtes RDAP, puis je bloque des sous-réseaux entiers de ces organisations
    Je ne garde que Google en liste blanche
    Digital Ocean semble être l’une des principales sources de trafic malveillant

    • Il s’agit d’une forme d’attaque par réflexion SYNACK
      La pile réseau réessaie, ce qui amplifie le trafic envoyé à la victime
    • C’est probablement lié à des attaques de jeu comme des DDoS sur serveurs Minecraft
      Comme l’IP source est souvent usurpée, je recommande de régler rp_filter en mode strict 
      net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
    • En revanche, il est dangereux que les FAI surveillent ou censurent le comportement des utilisateurs
      De la même manière qu’un fournisseur d’électricité n’interdit pas les ampoules rouges, il n’est pas souhaitable que les fournisseurs de services contrôlent le trafic

  • Si ce texte m’a parlé, ce n’est pas parce qu’Internet est sûr, mais parce qu’il documente cette réalité
    Moi aussi, je bloque Alibaba /16 et toute la plage AWS

    • Plutôt que de bloquer directement des plages IP, il est plus efficace de bloquer au niveau ASN
      J’utilise un script qui récupère chaque jour les données de RouteViews via cron et les applique à iptables
      Exemple de code : 
      iptables -A BAD_AS -s $ROUTE -j DROP;
    • À noter qu’AWS publie ses plages IP en JSON depuis 2014
      J’aimerais que les autres clouds fassent de même