Sommaire
- Mauvais timing (comme toujours)
- Analyser le souci
- Explorer les solutions
- Faire vite et mal
- Faire un peu moins vite et quand même mal
- Et demain ?
- Ce que j’en retiens
La semaine dernière, j’ai constaté un fort ralentissement sur un des sites web que je gère, au point où accéder au site était par moment impossible. Je me suis donc connectée au serveur, et j’ai rapidement trouvé le souci : apache qui saturait à cause du nombre de connexion.
Ce n’est pas la première fois que je rencontre ce souci depuis deux ans, sur un serveur ou un autre. À chaque fois, j’applique une rustine ou une autre dans l’urgence, en me promettant de faire les choses correctement une fois l’attaque passée. Quant au souci en question, beaucoup de sysadmin y ont été confrontés : une armée de bot qui a soudainement décidé que ce domaine devait être harcelé.
De façon intéressante, alors que le serveur en question héberge 5 domaines différents (et pas mal de sous-domaine), un seul était la cible de l’attaque, d’après les logs Apache. De façon tout aussi intéressante, ce flood (sur les diverses attaques que j’ai eu) ne concerne que le web (ports 80 et 443). Enfin, ça ne veut pas dire que les autres services ne sont pas floodés de bots aussi, mais pas dans des proportions à faire tomber le serveur, et je les gère avec un bazooka un peu moins excessif.
TL:DR : ceci est un roman, ça n’a aucun intérêt en version courte, puisqu’il s’agit plus de raconter une histoire que de partager des astuces techniques. Bon sang, ne suivez pas les astuces partagées ici. Mais si le TL:DR vous est réellement nécessaire : je me suis retrouvée à bannir quasi tout internet à cause des bots. Le titre suffit presque.
Mauvais timing (comme toujours)
Avant que j’entre un peu plus dans les détails techniques, commençons par les détails humains, qui ont toujours leur importance, dans toutes les structures.
On ne fait pas face aux problèmes avec les mêmes contraintes et possibilités suivant qu’on est tout seul, dans une petite association, dans une entreprise. Et il y a forcément quelques différences d’approche entre le sysadmin de métier, vénérable baroudeur des réseaux, et la hobbyiste du dimanche qui tatouille de la ligne de commande à l’occasion.
Lors de ma première attaque de ce genre, ça n’impactait quasi que moi : j’avais une page web sur mon serveur mail pour dire « c’est un serveur mail, voici les contacts en cas de souci » et un petit service pour gérer les alias. J’ai juste coupé le web, ça a réglé le souci (et je le rallumais le temps de régler mes questions d’alias à l’occasion). Enfin, ce n’est pas tout ce que j’ai fait, en réalité je me suis débattu longuement avec Nftables, Fail2ban, Reaction, etc, avant d’arriver à cette solution basique mais efficace. Pas de web, pas de DdoS.
Dans le second cas, cela concernait un serveur qui héberge des sites à moi et ceux de mon cher époux. J’ai aussi bataillé quelques jours, j’ai fini par faire un montage crasseux que j’ai évidemment oublié de documenter, l’attaque s’est épuisée, et ça n’a pas impacté grand monde.
Ces deux gros coups de speed (et les diverses “petites” attaques entre-temps) m’avaient déjà bien motivée à lire la doc et à réfléchir aux solutions ; je lisais aussi avec intérêt les retours des autres sysadmins par rapport à ce souci.
Cette fois, le serveur en question héberge plusieurs sites et services associatifs, dont une instance forgejo qui était déjà tombée plusieurs fois à cause de ce genre de souci, sur laquelle on a mis diverses rustines, dont l’efficacité était relative.
Il y avait un peu plus d’enjeux : une des assos est en plein dans une de ses campagnes de communication (argh), une autre avait besoin du site ce week-end là pour faire un achat groupé (re-argh, ceci dit ça, je l’ai appris après la crise, donc ça ne m’a pas mis de pression durant la gestion de l’incident). Difficile de dire « tout est down, osef ».
Ce qui n’a pas changé, c’est la sysadmin motivée à se bagarrer avec les bots : moi. Qui est toujours :
- juste une passionnée qui s’est formée sur le tas, ce qui veut dire que j’ignore plein de choses basiques ;
- qui n’est pas payée pour ça (c’est un loisir en principe !) ;
- plus ou moins profond dans le gouffre de l’épuisement, ce qui est l’histoire d’une vie mais qui, ces temps, se caractérise en particulier par une incapacité totale à gérer le moindre ajout de charge mentale. Pour donner le niveau, j’ai réussi à engueuler quelqu’un qui me demandait ce que je préférais manger. Je ne suis pas fière de ça. Mais depuis de longs mois, les choix les plus basiques sont trop lourds, alors commencer à mobiliser le cerveau pour décider comment remettre le serveur up…
Bref ; ça a beau faire un moment que je suis consciente que nos défenses sont trop légères, j’ai repoussé le moment de m’y attaquer à demain, et puis finalement, demain, c’était il y a une semaine. Dans ce genre de moment, après le sentiment de se faire écraser par une montagne, après s’être enroulé dans sa cape cthulhoïde la plus douillette et avoir invoqué l’apocalypse sur les agents IA du monde entier, il vient le moment de se frotter réellement à l’indicible, parce qu’il n’y a pas réellement le choix, et personne d’autre pour faire le taf.
Pourquoi je vous parle de tout ça ? Pas juste pour me plaindre en mode Caliméro (même si ça soulage), mais surtout en guise d’avertissement : ne faites pas ce que j’ai fait, parce que mes choix étaient uniquement liés à cette situation assez pourrie, et que je suis certaine qu’il y a mieux à faire. J’avais noté les bonnes idées ici et là et j’ai tout un sac de marque-pages de gens plus doués que moi qui envisagent de vraies solutions (mais qui me semblent aussi un peu désespérés, je l’avoue). Je ne suis pas un exemple. Vraiment pas. Mais les contre-exemples, ça a aussi un intérêt didactique, donc je partage. Et puis ça vous permettra de vous moquer (avec gentillesse), et c’est important de rigoler.
Je ne suis pas toute seule à gérer ces serveurs associatifs. Nous sommes actuellement deux sysadmins à avoir accès à tout. L’un est vigneron de profession, l’autre cuisinière : je trouve toujours fantastique tout ce qu’on arrive à faire, vu nos parcours. Mais y’a des jours, on galère pas mal. Là, ça a été ce genre de jours, et comme je suis celle qui a le plus bossé sur ce genre de souci et qui avait le temps (à défaut de l’énergie) à ce moment, c’est moi qui ai géré.
Analyser le souci
C’est en théorie la première chose à faire.
Donc, j’ai coupé Apache histoire de pouvoir bosser sur le serveur. Puis j’ai essayé de discerner les patterns dans les logs avec mes petits yeux d’humain, ce qui s’est vite révélé foireux. J’ai donc installé goaccess, j’ai bataillé pour le faire marcher, j’ai constaté que le format de mes logs Apache était totalement foireux, j’ai modifié Apache, relancé le service le temps d’avoir une nouvelle fournée de log, et constaté que c’était le moment où les bots floodent à fond.
Habituellement, Fail2ban et/ou Reaction sont très bons contre les bots. On détermine les patterns qui signent les badbot, et on bannit dès qu’ils arrivent, et voilà. Mon meilleur filtre, jusque-là, était assez simple et facile à mettre en place avec Reaction : s’il y a une erreur 404 sur un lien ayant le motif “admin”, on bannit. Au premier coup. Un mois. Mon filtre liste quelques autres mots-clés testés pour voir les fails sur les serveurs, et je n’ai rien inventé, vous le trouverez dans les exemples officiels, même si ma façon de l’appliquer est un coup de bambou direct.
J’avoue : je n’avais configuré ni Fail2ban, ni Reaction sur ce serveur. En fait, j’avais surtout une version hyper basique d’Iptable sur le Proxmox, avec tout le trafic web dirigé sur un container proxy, lequel re-dispatchait ensuite aux bons containers suivant les services demandés. Le serveur n’était pas complètement à poil, mais quand même honteusement peu protégé face aux évidentes menaces. Ça faisait partie des trucs à faire “demain”. Même que j’avais déjà bien bossé en coulisse (et pas sur le serveur de prod) à affiner des playbooks Ansible, et même si mon serveur de test était depuis longtemps une forteresse foireuse où je m’auto-bannissais régulièrement. Mais la prod ? Wouah, qui oserait toucher à la prod ? Ça Marche™ !
On se demande même comment ça n’avait pas tourné mal plus tôt. Ça faisait un moment que je faisais des prières aux dieux du chaos pour qu’ils m’oublient, et mon co-sysadmin avait géré son lot de galères et de rustines et a évité les pires scénarios.
Là, j’ai donc installé Fail2ban et lancé mon script de paramétrage de nftables avant de réfléchir plus. Non, je ne me suis pas trompée de chapitre : je suis bien en train d’expliquer que j’ai tenté d’appliquer une solution de tech avant d’avoir compris le souci. Sans surprise, ça a été absolument inutile, mais j’ai perdu quelques heures à ne pas comprendre pourquoi Fail2ban était aussi inutile. Rien que ça, déjà : pourquoi Fail2ban ? Alors que je sais qu’il n’arrive pas à la cheville de Reaction, sauf que je me suis dit que Fail2ban avait déjà ses filtres tout prêts, que peut-être il avait pris en compte ce genre de souci qui, je le sais, est classique, et que ça allait être aussi rapide qu’un apt install suivi de la déclaration de 5 jails.
J’adore Reaction, il est tout simplement parfait quand on veut ajouter ses propres regex, mais justement, il faut les écrire et s’assurer que celles qu’on a écrit l’année dernière sont bonnes pour le serveur du moment (surtout quand on change la façon dont les logs s’écrivent). Alors qu’avec Fail2ban, il suffit d’y croire très fort, et de ne jamais aller vérifier à quel point les filtres déjà proposés sont en réalité bien aux fraises (surtout sur les serveurs web ; sur le mail, ça va mieux), et d’ignorer qu’ajouter ses propres règles est laborieux. L’un ne ment pas, fait un peu peur mais finit par être un allié fidèle ; l’autre laisse facilement un faux sentiment de sécurité et devient un véritable enfoiré quand on essaie de l’adapter à nos besoins. Chaque fois que j’utilise l’un ou l’autre, je finis par conclure que je devrais rester avec Reaction seul, mais Fail2ban a un côté « rassurant » qui m’attrape à chaque fois.
Ceci dit, dans ce cas précis, les deux étaient aussi utiles que de danser emballée dans du jambon un soir de pleine lune.
Une fois ces actions inutiles accomplies (sans le jambon), et constatant que ma RAM et mon CPU étaient toujours à 100 % dès que je rallumais Apache, j’ai lu un peu mieux la doc de goaccess, constaté que ça ne m’aidait pas des masses, mais quand même, j’ai réussi à générer un rapport lisible, et j’ai commencé à comprendre le problème réel, LE scénario pénible.
Donc, le souci était, à première vue de goaccess, que des milliers d’IP se connectaient, chacune UNE fois (pas plus). Or, les filtres de Reaction ou Fail2ban sont plutôt du genre à agir après quelques essais. On peut effectivement faire bannir à la première connexion (ça aide parfois, comme dans le cas des 404 sur les liens contenant « admin » !), encore faut-il avoir un pattern exploitable, or là, je n’avais pas tellement de 404, mais plein de 200 : les bots visitaient des pages existantes. Je ne peux pas bannir tous les gens qui vont sur l’index ; autant laisser le serveur web éteint.
À noter que dans ce genre de cas, il est possible de filer un lien honeypot : le lien existe (code 200) mais on bannit quiconque va dessus. Cependant, dans le cas présent, ça n’aurait pas non plus suffi. Le serveur montait en charge à cause du nombre de connexion avant tout.
À noter que j’ai aussi installé libapache2-mod-evasive, qui est sans doute génial, mais qui ne m’a pas aidé des masses. Peut-être que j’ai loupé le bon détail dans la configuration.
Explorer les solutions
Vous avez noté le « à première vue » ? On va y revenir.
Ayant (imparfaitement) compris ce qui se passait, ayant testé des solutions inadaptées sans succès, j'ai continué à faire ce qu’on fait quand on craque : n’importe quoi.
J’ai commencé à explorer les mystères des adresses IP et de la notation CIDR il n’y a pas si longtemps. En fait, ça fait moins de 3 ans que je commence à vaguement comprendre quelque chose au réseau, et la notation CIDR est encore emplie de brumes dans ma tête. Heureusement pour moi, goaccess m’avait signalé que les adresses étaient en ipv4, je me suis donc concentrée sur ça. Dupliquer les logiques avec l’ipv6 (que je comprends encore moins qu’ipv4) aurait été en trop.
J’ai commencé par faire un script bash crasseux (non, je ne le partagerais pas) pour analyser une heure de log et voir d’où venaient les IPs.
Que fait une néophyte face à des adresses qui semblent venir de même plages d’IP ?
Elle bannit à grand coup de /8.
Alors, ouais : ça a calmé les attaques. Ça a aussi banni les utilisatrices légitimes. En fait, je me suis même banni moi-même ; heureusement, uniquement sur le container et non sur l’hyperviseur, donc via l’interface de proxmox, j’ai pu rectifier le tir.
Cela faisait deux jours que je me débattais à essayer de bloquer des fichus bots et là, soudain, le trafic repassait à un niveau plus ou moins acceptable. Même si j’avais banni la moitié du web, je suis allée me coucher avec l’esprit un peu apaisé. Tout en sachant que noooon, ce n’était pas une solution.
Le lendemain, je me suis rendu compte qu’en plus, ça ne marchait pas complètement ; j’ai passé une après-midi à tourner en rond pour comprendre pourquoi une ip dans la plage bannie pouvait quand même passer sur le serveur. La réponse était d’une simplicité totale pour quiconque comprend le réseau : le proxy file les ip en “forward”. Mais si je ne bannis pas le proxy (hem hem), ALORS il vaut mieux que j’applique les règles de bannissement sur le proxy. PAS sur le container avec le site web. En plus, c’est un peu à ça que sert un proxy : filtrer les enquiquineurs en amont.
À partir de là, c’est allé réellement mieux, mais malgré tout, je savais que j’avais banni trop largement. J’ai quand même continué à tourner en rond un moment sur le web, en cherchant quelle solution mettre en place.
- Cloudflare ? C’est probablement efficace, mais je refuse de mettre un Man-in-the-Middle des USA entre mes sites et mes visiteuses.
- Les solutions comme Anubis, Iocaine, les challenges à base de Javascript, les configurations d’Apache/Nginx, etc, n’étaient pas une solution puisque le souci venait juste du nombre de connexions ; chaque page, ensuite, ne consommait pas des masses. Il fallait éviter qu’Apache réponde à ces IPs.
- N’étant pas un service commercial, bannir AWS, Alphabet et Meta ne me gênait pas le moins du monde. Des fois que certaines grandes entreprises auraient été dans les plages d’où les bots venaient.
Accessoirement, je ne peux pas aller avec mon ordiphone sur les sites avec Anubis et Cloudflare : il chauffe, tourne dans le vide, et ne passe jamais les challenges. Donc ça ne me motive pas à y mettre sur mes propres services.
Pendant ce temps, sur le canal tech, des amis plus compétents que moi susurraient des mots comme ASN, mais je n’étais pas encore en état de donner du sens à ça.
J’ai donc découvert ce que voulait dire ASN le lendemain. J’en avais déjà vaguement entendu parler, mais jusque-là, ça restait un concept lointain et nébuleux, que je ne pensais pas devoir utiliser. Cette fois, j’ai lu la doc, comment ça marchait, et je me suis dit « bingo, je vais juste bannir les mauvais datacenters. »
Facile, hein ?
Faire vite et mal
J’ai pris des adresses ip un peu au pif, en me disant que ça suffirait à identifier les horribles datacenter chinois qui osaient flooder mon serveur pour entraîner leurs IA. Parce que là aussi, pourquoi se baser sur les faits quand on peut faire des suppositions ?
Mes diverses analyses de log pointent quand même que mes idées préconçues sont exactement ça : préconçues. Je n’ai pas refait de stats par pays, mais c’était assez réparti. Vite fait, il y avait le Paraguay, l’Éthiopie, la Malaisie, par exemple (et dans les exemples qui m’ont frappés).
Par ailleurs, bien que dans les logs, les bots se prétendent parfois être “ClaudeBot” dans l’user-agent (si si, il y en a), en réalité leur IP ne correspond pas du tout aux serveurs d’Anthropic. Idem sur les autres grosses entreprises d’IA. Je ne prétends pas qu’elles ne font pas de dégâts, mais elles ne sont pas forcément derrière ce genre d’attaque (pas directement).
Enfin, et c’est le point le plus important : l’analyse des ASN montrent que ce ne sont pas forcément les datacenters, le souci. Ho, ils en font partie. Mais… J’ai rapidement trouvé quelques gros acteurs des telecoms de divers pays. Pour le dire autrement : les bots étaient dans les ip résidentielles. Là, je commençais à voir pointer le fait que j’allais être obligée de bannir des gens qui n’avaient rien à voir avec le problème. La télé connectée, le smartphone avec cette appli trop bien, qui relayaient les appels des bots-criquets… Désolé, Mémé, mais ça va couper.
J’ai repris mon script bash, je l’ai torturé pour qu’il me donne de meilleures plages d’ip, et à la fin d’une autre journée de travail, j’en ai conclu que le mieux, c’était de bannir en /8 toute ip entre 1.* et 255.*. En plus, ça ne faisait que 255 lignes dans mon set nftables, trop la classe.
Les sysadmins compétents sont déjà en train de se marrer, mais je sais qu’il y a aussi des gens un peu moins techniciens dans l’assemblée, donc je me permets d’expliciter la blague : j’ai bien failli bannir tout internet. Tout. Enfin, en ipv4. Une solution qui, certes, avait le mérite d’arrêter les bots. Je me suis arrêtée avant de le faire réellement ; une petite étincelle de compréhension est passée dans mon esprit embrumé par le désespoir et le burn-out avant que j’applique la solution.
Je continue de penser que c’était une solution. Sans doute pas parfaite, mais ça réglait le souci.
Faire un peu moins vite et quand même mal
Une autre nuit de sommeil, à laisser les neurones faire des liens. Comment éviter de bannir le monde entier ?
Retour alors à l’aspect humain. Quel est l’impératif ? Que mes utilisatrices dans leurs associations aient accès à leurs sites, leurs clouds, leurs pads, etc.
Or, ces associations, je les connais. J’ai le numéro de téléphone de leurs dirigeantes, je sais à quoi ressemblent les membres. Quel est le dénominateur commun ? Leur lieu de résidence. À ma connaissance, il n’y a personne en Éthiopie ou au Paraguay. On a parfois des gens en Chine, mais pas ces temps-ci. En fait, on a surtout des gens en France, en Suisse, en Belgique et au Canada.
Et si on faisait l’inverse ? Non pas bannir tout le monde, mais autoriser uniquement certains pays ?
J’ai récupéré les listes des rang d’ip par pays puis j’ai utilisé iprange pour tenter de diminuer un peu le nombre de lignes. J’ai ensuite fait un set « allow_country » dans nftables, avec tous ces rangs d’ip, puis déclaré que seul les set « allow_sysadmin » (les ip personnelles de là où moi et mon co-sysadmin on se connecte) et « allow_country » étaient autorisées à se connecter. Ensuite, d’autres règles s’appliquent ; il y a aussi des bots dans ces 4 pays.
chain input_all {
type filter hook input priority 0; policy drop;
ip saddr @allowlistsys accept
ip saddr != @allowcountry drop
# [...]
ct state vmap { invalid : drop, established : accept, related : accept }
# [...]
}
Étonnamment, ça se charge vite, nftables ne bronche pas, la consommation mémoire est ridicule. Il y a pourtant 13 820 plages déclarées dans le set…
À la fin, les logs apaches montraient que j’étais de nouveau la seule à explorer les pages. Ouf !
Bon, pas complètement la seule : les autres membres des assos m’ont confirmé qu’elles accédaient bien aux sites (c'était l'objectif). Et puis j’ai encore quelques bots, qui ne font pas trop de bruit, et qui vont se prendre un coup de Reaction sur la tronche un de ces jours.
Est-ce que cette solution me satisfait ?
Franchement… non.
Mais ça marche. Ça répond au besoin de base actuel. Ça a viré les bots les plus gênants. Je déteste l’idée d’appliquer une sanction internationale à cause de quelques margoulins qui pourrissent internet, mais je n’ai pas non plus les moyens de faire mieux.
Et demain ?
Ah, pour demain, bien sûr, j’ai plein de projets. Je sais très très bien ce que je veux mettre en place. De quoi faire un set avec mes membres identifiés, qui sera en allow-list (qu’ils soient co ou non, comme ça), appliquer un rate-limit via nftables sur les autres (comme ça, le serveur restera confortable pour mes utilisatrices même en cas d’attaque mais en général accessible pour le reste du monde), mettre en place un serveur honeypot pour mieux analyser les plages qui génèrent du trafic de bot, reprendre mes configurations sur Reaction, paramétrer plus finement nginx (sur le proxy) et apache (sur les containers) pour que leurs propres mécanismes tamponnent, servir des « Too Many Requests » à ceux qui n’ont qu’une ip mais crawlent trop vite, améliorer les robots.txt (pour les bots honnêtes), autoriser peut-être certains indexeurs à venir avec des règles spéciales, partager les règles de ban entre mes serveurs, mettre plus de honeypot dans les coins, filtrer aussi par user-agent, comprendre un peu mieux comment les modifs du noyau à propos de synack pourraient aider, etc, etc.
Et évidement, appliquer tout ça à ipv6.
Demain.
Ou après-demain.
Dès que j’en ai l’énergie.
… Ouais, on peut parier que le monde entier ou presque va rester banni un moment.
Et mon code, il est où ?
Sans doute que je pourrais partager mes règles nftables. Elles sont loin d’être parfaites, cependant, et donc je doute que les offrir en exemple soit bon ; il y a encore des aspects que je n’ai pas compris (comme les rate limit ! ça ne marche jamais comme je l’espère). Idem sur le reste. Je sais que partager des solutions offre le risque que les gens derrière ces slop-bot trouvent des contournements, ceci dit je n’ai pas inventé la lune. Je veux leur interdire de me dire bonjour, point.
Mais… ça fait du job, de partager ça, que je préfère passer à peaufiner mes configurations. S’il y a vraiment une demande, je le ferais, mais comme je doute de la passion à lire des scripts bash mal conçus et des règles nftables un peu bancales, je m’économise cette partie pour le moment.
Ce que j’en retiens
- Je craignais le jour où les bots viendraient des ip résidentielles (ça nous pendait au nez depuis un bail) : c’est bon c’est fait.
- Pour le moment, tout ceci reste encore grandement basé sur ipv4 (pour ce que j’ai eu) mais la suite sera forcément en ipv6.
- Je crains la fin de l’internet ouvert. Bientôt on vérifiera la qualité de nos visiteuses suivant leur score de confiance dans une toile qui reste à inventer. On le voit déjà bien chez les GAFAMS, mais ceci est pour un autre roman : « comment Google m’aide à me désintoxiquer de sa came, et comment Meta évite que je tombe dedans » (oui, je pourrais l’écrire, si je m’ennuie).
- Combien de temps des bidouilleuses dans mon genre parviendront à maintenir des bouts d’internet ? Je ne sais pas. Ça finira peut-être en intranet, mes bidouilles… on en est déjà pas si loin.
- Les amis sont ce qui permet de faire face aux tempêtes. Ok, je ne me serais pas autant pris le chou si personne n’avait eu besoin de ces serveurs ; mais j’ai été amplement soutenue durant cette longue semaine, avec des voisins qui m’ont fait à manger, des gens qui m’ont envoyé des encouragements, qui m’ont dit que ce n’était pas grave que ce ne soit pas accessible, qui m’ont envoyé des liens vers de la doc, donné des pistes utiles. Autant les bots donnent envie de tout cramer, autant toute cette humanité fait chaud au cœur et aide à tenir le coup.
- Comme toujours quand je partage un retour d’expérience sur Linuxfr, je suis à la fois fière de partager mes déboires (parce que j’adore lire ce genre de chose et que je me dis que je participe à ma mesure ainsi), soulagée d’avoir lâché tout ça (c’était intense à écrire aussi), et inquiète des retours cruels qui vont me pointer à quel point je suis nulle en enrobant ça dans un pseudo-cynisme soi-disant bienveillant. Mais l’autre solution est de garder le silence, et j’ai bien assez de journaux, articles et écrits jamais publiés sur mon disque dur : P
J’espère que ça vous aura amusé un peu, à défaut d’offrir des pistes viables sur comment faire face à ces attaques !
# Whitelist
Posté par Valentin . Évalué à 10 (+14/-0).
Au cas où tu te sentirais seule : j'ai appliqué la même méthode pour HTTP, POP3 et IMAP il y a des mois.
Nos utilisateurs ne sont que dans quelques pays (francophones), et à moins de bannir tout Internet, je n'ai pas non plus trouvé d'autre solution.
Le problème des relais résidentiels (qui pour la plupart ne sont même pas au courant de ce qui se passe dans leur smartphone/tv/machine à café connectée) devrait être pris en charge au niveau judiciaire, si le monde fonctionnait correctement : pas de raison qu'on installe ce genre de cochonnerie dans le matériel des gens à leur insu.
Mais bon, si c'était le monde des bisounours, ça se saurait. Là, on part plutôt vers Mad Max…
# Intéressant !
Posté par Bernie . Évalué à 10 (+11/-1). Dernière modification le 31 août 2026 à 21:17.
Bon, tout d'abord, pour moi ça n'a pas été du tout du TL:DR, loin de là. Sans doute parce que c'est principalement du chinois antique en ce qui me concerne (aucune compétence en réseau), même si j'ai un peu pigé les divers pièges et impasses. En tout cas j'ai appris quelques trucs intéressants que je ne soupçonnais même pas (oui, le béotien débutant qui plus est !)
Ensuite,
ceux qui pourraient réagir ainsi, tu peux les bannir (je sais pas si la méthode que tu emploies sur ton serveur est efficace dans ce cas là). Parce que la seule réaction saine de "ceux qui savent", c'est d'essayer de donner quelques infos pour aiguiller. On n'est heureusement plus trop au temps (que j'ai connu) où la moindre question générait une rafale de RTFM et autres amabilités "pour aider le p'tit gars paumé".
Et pour finir, comme tu le dis très bien, tes errements serviront certainement un jour ou un autre à un pauvre sysadmin débordé par des attaques similaires, au moins pour ne pas faire les mêmes erreurs.
Allez, courage, ça va le faire ;-)
[^] # Re: Intéressant !
Posté par Zatalyz (site web personnel) . Évalué à 10 (+10/-1).
Je reconnais aussi que la communauté de linuxfr.org est quand même, dans l'ensemble, plutôt aimable (il y a des coins d'internet bien plus infréquentables). La preuve : jusque là, les retours sont vraiment très chouettes. Mais il y a quand même dans la communauté des personnes vraiment, vraiment désagréables, de façon quasi systématique, dont je n'ai aucune envie de lire l'avis, qui le donnent bien trop facilement en plus, et hélas je ne sais pas comment ne pas les voir.
Je gère ça en lisant les commentaires à un moment où, si jamais une de ces personnes est passée, je me pense capable de gérer sans en perdre le sommeil ! Et au final, ne voir que des commentaires pertinents, ça me rebooste…
Je suis contente que ça reste plus ou moins compréhensible même sans bien connaitre ! C'est toujours compliqué à écrire, ce genre de récit, car je sais qu'il y a ici des vrais cadors qui vont trouver que j'explique trop longuement des banalités, et des gens dont l'expertise n'est pas du tout là et pour qui j'aurais peut-être pu mettre un peu plus de liens vers des définitions… mais ça serait devenu très indigeste. Un public éclectique, ce qui est aussi intéressant ; j'ai personnellement énormément appris au fil des ans grâce aux divers contenus de ce site.
# Grand merci...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 10 (+17/-0).
Je viens de lire une bien belle histoire de la vraie vie dans le grand Ternet mondial, ça m'a fait vraiment plaisir de tomber sur de vrais détails technique : les deux étaient aussi utiles que de danser emballée dans du jambon un soir de pleine lune.
C'est très rafraichissant après le déluge de slop de ces dernières semaines :)
[^] # Re: Grand merci...
Posté par liberforce (site web personnel, Mastodon) . Évalué à 10 (+12/-0). Dernière modification le 01 septembre 2026 à 14:01.
Je pense qu'on est nombreux à s'être dit "Ouah, il y a encore d'irréductibles gaulois qui écrivent leur texte eux même sans IA !". On va la sentir passer l'invasion romaine…
# Pour LinuxFr.org
Posté par Benoit Sibaud (site web personnel) . Évalué à 10 (+23/-0).
Pour LinuxFr.org, la situation n'est guère différente :
Bref, ça nous fait plein de points communs… Et on est loin d'être les seuls c'est un sujet qui revient dans chaque conférence technique, chaque événement, dans les complaintes des adminsys unifiés de la Grande Internati… enfin bref partout. Dernier exemple :
https://bsky.app/profile/pierreb.bsky.social/post/3mu7yx7df4k2t (eu.org, et là il parle de OSM et Wikimedia)
[^] # Re: Pour LinuxFr.org
Posté par Misc (site web personnel) . Évalué à 6 (+3/-0).
Alors justement, j'étais à la conf mentionnée et une des questions que je n'ai pas pu posé à la fin (pour divers raisons), c'était "est ce que vous avez a pensé à une réponse juridique". Car bon, si c'est l'équivalent d'un DDoS, ç'est assez probablement illégal dans pas mal de pays.
Tout le monde ou presque semble souffrir de ça mais de ce que je vois, presque personne ne porte plainte et j'aimerais comprendre pourquoi. Je dis presque personne parce qu'il y a vaguement un cas aux USA (sur une liste de 6) qui s'appuie sur le CFAA (Computer Fraud and Abuse Act, l'équivalent du bon vieux 323 du code pénal de chez nous). Il y a peut être plus, mais j'ai pas entendu parler.
[^] # Re: Pour LinuxFr.org
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 01 septembre 2026 à 11:19.
En France, il y a LOPSI de 2002 et surtout la LCEN de 2004 qui transpose en droit français la directive européenne 2000/31/CE du 8 juin 2000 et étend la notion d'intrusion dans un SI initialement défini depuis la loi Godfrain de 1988 — le 323 dont parle Misc<). Eh ! Fallait suivre les mises à jour après la loi informatique et libertés de 1978 :D
Bon, je n'aime pas trop la LCEN (ni LOPSI), mais ce n'est pas l'objet de ce commentaire ;-) (son principal mérite étant pour moi l'extension du fax au mail comme preuve recevable, sans pour autant présager d'une quelconque garantie d'acheminement / intégrité / confidentialité o_O que n'a pas le mail :/). Bref, tout le reste n'est pas à jeter pour autant ('fin une bonne partie ayant donné DADVSI puis HADOPI, puis LOPPSI 2, puis TAFTA… bref j'avais dit : il est laissé à titre d'exercice de retrouver les articles de La Quadrature en parlant :p).
Donc je disais, intrusion dans un SI, — IANAL donc techniquement — ça peut vouloir dire quoi ?
Reste à voir le champ d'application effectif, caractériser les lois réellement applicables : là faudra un juriste…
Pour autant, tout sysadmin peut présenter factuellement — comme Zatalyz< l'a fait (même si ça manque d'images :p) — les conséquences de telles méthodes clairement abusives. Cela pourra ensuite être utilisé pour évaluer les dommages (et intérêts — aux deux sens du terme :p).
[^] # Re: Pour LinuxFr.org
Posté par Misc (site web personnel) . Évalué à 5 (+2/-0).
Sans sortir l'historique, c'est assez clair dans le code pénal (323-1):
On peut quand même noter que c'est une altération du fonctionnement du système si ce dernier ne fonctionne plus. La seule question est de savoir qui est responsable, et c'est le travail de la justice.
[^] # Re: Pour LinuxFr.org
Posté par Zatalyz (site web personnel) . Évalué à 10 (+8/-0).
Je dois dire que si j'avais de l'énergie à consacrer à ça, je ne saurais pas par où commencer. Attaquer (légalement !) les ASN qui ont relayé les attaques ? Chaque individu derrière les ips qui ont servi à ça ? Ça demanderait un gros boulot d'enquête pour définir qui est derrière, non ? On suppose que cela vient des malwares intégrés dans les app, mais si on en avait des preuves légalement recevables, ce genre de procès serait déjà fait ?
Je suspecte que les organismes capables de porter de tels procès aient aussi les moyens de juste gérer ces DDoS en payant une armée de tech compétents, et que ça revienne moins cher. D'autant que là, dans mon histoire, oui je peux tenter de dire que j'ai subi un préjudice mais… au final les bots n'ont rien fait de directement illégal (ils ont visités des liens publiques), et on pourrait facilement me retoquer en disant que je n'avais "qu'à" avoir une infra réseau plus solide.
Je reste une sysadmin du dimanche ; je ne sais pas du tout comment cela est perçu par les sysadmins dans les entreprises, si les décisionnaires dans les entreprises en question les écoutent, si le problème est vu comme un problème à ce niveau.
Le souci c'est que ce sont les petites structures qui morflent le plus dans cette bagarre, celles les moins à même de saisir l'institution judiciaire.
Voilà pour quelques théories…
[^] # Re: Pour LinuxFr.org
Posté par Misc (site web personnel) . Évalué à 6 (+3/-0).
Ou en passant sur cloudflare et co. Mais oui, je comprends que des gens qui font ça de façon bénévole veuille faire autre chose. mais Wikimedia a des admins à temps plein, OSM a un admin à temps plein, Gnome a un admin à temps plein, la fondation linux aussi. Certes, il n'y a pas forcément beaucoup d'argent pour ça, mais je pense que pousser la porte d'un poste de police ne devrait pas être si ruineux que ça.
Se rassembler pour mettre en commun les plaintes, ça me semble du domaine du possible.
Même les groupes organisés comme codeberg ou sourcehut font des posts de blog et des mitigations techniques. Le domaine du légal semble être impensable.
[^] # Re: Pour LinuxFr.org
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2 (+1/-0).
Et les utilisateurs légitimes qui, avec des ordinosaures(ou pas) via un FAI qui ne plaît pas aux Gafamycu, se retrouvent bloqués.
Et tout Internet qui se transforme de plus en plus en un mélange entre un minitel fasciste et un gros terrain de guerre de robots. En fait, ça ressemble beaucoup à la version virtuelle du monde décrit dans le rêve terrifiant que fait Ryse dans Terminator.
[^] # Re: Pour LinuxFr.org
Posté par Zatalyz (site web personnel) . Évalué à 8 (+6/-0).
Merci, ça me fait plaisir de voir que les choix ne sont pas si différents !
Et dans le cas de LinuxFr.org, bannir quasiment le monde entier est difficilement envisageable, il y a des gens d'un peu partout qui viennent mouler (pour de vrai)…
À part dire "bon courage", il n'y a pas grand chose à ajouter :D
# Comment ça touche les repos de kernel.org
Posté par Valentin . Évalué à 10 (+9/-0). Dernière modification le 31 août 2026 à 21:41.
Un article de Konstantin Ryabitsev (kernel.org) sur ce brûlant (pour les CPU) sujet :
https://people.kernel.org/monsieuricon/creepy-crawlies (merci Maclag<)
[^] # Re: Comment ça touche les repos de kernel.org
Posté par rewind (Mastodon) . Évalué à 9 (+6/-0).
C'est le premier lien du journal
# Pas de solution unique
Posté par passke (site web personnel) . Évalué à 6 (+5/-0).
D'abord merci pour cet excellent journal, franchement sympatique à lire, avec ce petit mélange de technique et d'autodérision.
Lutter contre les DDOS n'est jamais évident, ils prennent de nombreuses formes et au final une seule technique n'est souvent pas suffisante. Et je connais des sysadmin (moi en l'occurence) qui ont autant galéré sur leur premiers DDOS que toi.
Il y a cependant quelques pistes qui sont intéressantes à explorer. Je me suis beaucoup inspiré au départ d'un article de HAProxy. J'utilise aussi des liste noires issues de Crowdsec.
Quelque chose d'important également, mettre en place un cache qui décharge les serveurs applicatifs (si ce n'est déjà fait).
[^] # Re: Pas de solution unique
Posté par Valentin . Évalué à 9 (+8/-0).
Les listes noires et les fail2ban/crowdsec sont totalement inefficaces face aux proxies résidentiels qui n'effectuent le plus souvent qu'une requête par IP.
Et comme le décrit le journal, on en vient à bannir 0.0.0.0/0 ;-)
[^] # Re: Pas de solution unique
Posté par passke (site web personnel) . Évalué à 6 (+5/-0).
Tout à fait d'accord, c'est bien pour ça que la lutte contre les DDOS implique souvent de multiples techniques. En fait ce type d'outil te permet déjà d'éliminer le bruit de fond pour pouvoir te concentrer sur le DDOS.
Après tu peux faire du rate limiting par IP, par user-agent, par ASN, par pays (en combinant éventuellement avec des listes blanches). Et puis tu peux protéger tes serveurs applicatifs via le reverse proxy en limitant le nombre de connexions simultanées, tu peux prioriser certains pays ou ASN.
[^] # Re: Pas de solution unique
Posté par Voltairine . Évalué à 4 (+2/-0).
Oui mais cela ne résout pas le problème évoqué plus haut (proxies résidentiels ou botnets). Je peux te montrer des logs où des centaines d'IP différentes font des requêtes vers diverses pages web avec des agents utilisateurs variables semblant parfaitement légitimes.
Les règles de pare-feu sont vaines pour contrer ce type de robots. Surtout si tu dois absolument éviter de bloquer des utilisateurs légitimes, y compris certains moteurs de recherche.
Les seules solutions efficaces ont été évoquées dans ce fil : accès soumis au dépôt d'un cookie, artillerie lourde mais libre de type Anubis, solution privatrice de type Cloudflare,…
[^] # Re: Pas de solution unique
Posté par passke (site web personnel) . Évalué à 2 (+2/-1).
Oui les techniques que j'ai citées ne permettent effectivement pas de régler le problème de ddos utilisant des proxys résidentiels.
Ce qui serait intéressant de savoir, et malheureusement je n'ai que ma propre expérience sur le sujet, c'est de savoir combien d'IP uniques sont utilisées lors d'une telle attaque.
Les plus importantes que j'ai subi comprenaient quelques milliers d'IP uniques et variaient en durée de quelques minutes à quelques jours.
Dans le cas de quelques minutes, chaque IP ne fait effectivement que quelques rares requêtes. La solution que j'utilise est donc de prioritairement protéger les serveurs applicatifs (web et bdd) de la surcharge en limitant le nombre de connexions simultanées et en mettant le surplus en file d'attente. L'effet est généralement un ralentissement pour tout le monde, parfois quelques timeout, mais à la fin de l'attaque les services sont opérationnels.
Pour les attaques durant plusieurs heures ou plusieurs jours, chaque IP revient régulièrement et peut faire quelque chose comme une ou deux requêtes par minute. Ce que j'ai constaté c'est que les requêtes sont très très minoritairement sur des ressources statiques (js, css, png, …), ce qui est logique puisque le but est de faire tomber les services et que cibler du php est plus efficace qu'un css.
Je compte alors (en continu) le taux de requêtes statiques par IP. Lorsqu'il est inférieur à 5% par exemple, je bloque l'IP pour une heure. L'effet est que le ddos fonctionne à plein pendant quelques minutes, puis au fur et à mesure les IP se font bloquer. Ca n'arrête pas le DDOS, mais ça diminue fortement son impact.
Evidemment si je devais un jour subir une attaque avec un botnet de plusieurs millions d'IP, la technique ne fonctionnerai plus du tout.
[^] # Re: Pas de solution unique
Posté par Voltairine . Évalué à 5 (+3/-0).
Toutafé.
Mais les listes noires ont un autre intérêt. J'utilise celle de abuseipdb.com (~90 000 IP) que j'injecte à intervalles régulier dans mes règles nftables. Cela a pour effet de bloquer tous les bots qui cherchent de bêtes failles de configuration ou de sécurité sur les services habituels (SSH, couurier, web, etc.).
# Une autre solution assez simple
Posté par Faya . Évalué à 9 (+7/-0).
Si tu l'as ratée, il y a cette solution dont on avait parlé ici même. D'après SebSauvage c'est pas mal efficace mais ça impose de demander au visiteur d'avoir javascript activé… L'avantage c'est que c'est simple. Force et courage dans tes luttes.
[^] # Re: Une autre solution assez simple
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Je l'avais mis dans mes marques-pages… Et je m'étais dit que c'était un peu trop de boulot à adapter sur notre infra, mais quand même "à regarder" (sans doute demain !). je crois que Dokuwiki a un système similaire. Je ne suis pas certaine que ça aurait servi sur le DDoS, par contre : dans ce cas précis, il fallait vraiment qu'Apache arrête de répondre aux bots, tout court. En tout cas ce n'est pas trop pénible pour les utilisatrices, et ça filtre un peu tout de même en séparant les bots les plus basiques des humains qui le sont un peu moins.
# geoip = charlatanisme
Posté par Psychofox (Mastodon) . Évalué à 7 (+7/-3). Dernière modification le 01 septembre 2026 à 07:00.
Le problème de bannir ou authoriser des ranges d'IP par pays, c'est qu'en réalité ça n'existe pas la geolocalisation d'IP.
Mon ISP a son siège social et des datacenter dans deux pays différents que mon pays de résidence et du coup les adresses ip qu'il me fournit via DHCP est souvent reconnue par les services de geolocalisations d'IP et donc les serveurs comme venant d'un pays de l'est de l'europe qui n'a rien à voir avec mon lieu de résidence. Sans nulle doute qu'associée à mon adblocker ça participe au fait que je suis régulièrement soumis à des tonnes de captcha quand je ne suis pas tout simplement banni de certains sites à la première connection "parce que mon traffic est jugé comme suspect".
Pire les IP fournies par le même forunisseur internet à mon routeur et à mon smartphone sont généralement associées à des pays différents, pourtant quand j'active ou désactive le wifi sur mon smartphone je ne me téléporte pas.
Bref la geolocaliasation d'IP, ça n'existe pas. Une IP n'a pas d'adresse physique, ça n'indique pas où vont ces 0 et 1 transmis à toute allure dans des fibrea optiques dans le monde entier et toute tentative de leur donner une adresse ou même une région ou un nation n'est qu'une fumisterie qui ne marche pas et ça avant même de parler de VPN.
[^] # Re: geoip = charlatanisme
Posté par Valentin . Évalué à 2 (+3/-2).
Dans ce cas, c'est juste ton ISP qui ne fait pas son boulot.
Et si tu te fais ban parce qu'il y a du filtrage géographique, c'est de sa faute (l'ISP), pas celle du site qui te bloque.
[^] # Re: geoip = charlatanisme
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 02 septembre 2026 à 01:07.
Ben non, car les ASN sont lié aux groupes de routage, pas à ton adresse postale ou ta position GPS à un instant T.
Et les ISP qui opèrent dans plusieurs pays sont parfaitement en droit d'utiliser les IP qu'ils possèdent.
[^] # Re: geoip = charlatanisme
Posté par Zatalyz (site web personnel) . Évalué à 10 (+11/-0).
De ce que j'ai compris (qui peut être foireux), les listes ne sont pas "par pays", mais "par ASN", et on estime que tel ASN est en train de fournir tel pays. Par exemple Orange a plusieurs ASN (on voit ça ici par exemple), dont certaines sont explicitement déclarées comme étant dans un pays.
Ensuite, avec ces ASN, on a plein de panachage possible. Par exemple, j'aurais pu me dire : je prends les grands FAI des quelques pays que je suis, je ban le reste. Mais ce faisant je banissait forcément aussi les petits fournisseurs genre FDN (y'en a vraiment un paquet rien qu'en France).
À un moment il faut faire un choix dans les listes. Là, j'ai décidé de faire confiance aux listes de https://www.ipdeny.com/ (c'est pas geoip pour le coup) ; je ne sais pas ce qu'elles valent dans le détail, mais quand j'ai regardé ce qu'il y avait dans les ASN associés à la France, j'ai effectivement trouvé les ASN des divers gros FAI français, les plages où étaient les IP de certains membres (certains n'étant pas chez les gros), et autres.
Par contre je ne prétends pas que c'est idéal, bien loin de là. Déjà ces attributions changent à l'occasion et des plages attribués à une boite en France peuvent passer dans un autre pays (et j'imagine que c'est d'autant plus facile que la boite en question a une activité internationale). Ensuite il y a plein de moyens de contourner ça, par exemple utiliser des proxy en France qui relayent un flux qui vient d'ailleurs (c'est très certainement la façon dont les bots fonctionnent). Enfin : je déteste viscéralement bannir des gens sur un délit d'appartenance nationale, ça a des relents puants.
Mais vraiment, à ce stade, je n'ai pas trouvé plus efficace pour m'en sortir. Ça marche pour le moment, ça répond à l'objectif, et le taux de mécontents dans les gens qui me font des retours en allant sur les services que je gère est à 0% pour le moment. Je le répète : ce n'est pas une bonne solution. Par contre ce n'est pas du charlatanisme, vu que ça a l'effet escompté (avec sans aucun doute plein d'effets de bords que je n'ai pas encore listé/vu).
[^] # Re: geoip = charlatanisme
Posté par steph1978 . Évalué à 3 (+1/-0).
Dans la pratique, cela ne marche pas si mal.
MAIS, ce n'est pas la question. Entant qu'hébergeur, on ne cherche pas où est l'utilisateur (geo) mais qui est responsable de la connexion entrante, donc l'AS et de quelle juridiction il dépend (pays).
# Je recommande Anubis
Posté par rhodan . Évalué à 1 (+2/-1).
Comme expliqué dans le blog de kernel.org ci-dessus, ce n'est pas parfait et il faut le maintenir à jour pour s'ajuster aux nouvelles adaptations des bots, mais il nous a permis de retrouver un trafic normal. En plus des épreuves, Anubis comprend des listes d'IP à bannir et autoriser maintenues ainsi que la possibilité d'empoisonner les bots.
# Epuisement
Posté par Tarnyko (site web personnel) . Évalué à 6 (+4/-0).
Je réagis juste à ça ; ça m'est arrivé récemment aussi (la charge mentale, pas l'engueulage ; mais c'est plus facile en télétravail…) et c'est un peu inédit en ce qui me concerne.
Pour des personnalités analytiques comme les nôtres, gérer un tel flux de changements à volée avec des requêtes qui viennent de partout : c'est épuisant. Je donne souvent l'exemple de faire un "100 mètres sprint" : à la fin t'es fini et il faut laisser l'énergie revenir pour en faire un autre.
Ma réaction perso a été la transparence : "Je suis fatigué, alors j'ai ralenti pour me préserver. Il ne sert à rien de m'ajouter de la charge ou des réunions ; vous pouvez m'aider en mettant quelqu'un qui collecte les requêtes, me les présente, et organise la communication avec l'extérieur. Si vous voulez me rajouter une 'aide', gérez-le aussi pareil pour qu'il ne soit pas lui-même une charge au début."
Ça se passe bien du coup, mais parce les gens sont compréhensifs. Si ce n'est pas le cas, ah bah, y a rien d'autre à faire que de délester - en toute transparence également AMHA.
[^] # Re: Epuisement
Posté par Zatalyz (site web personnel) . Évalué à 10 (+9/-0).
Commencer à perdre les pédales sur des sujets anodins (comme lorsque j'ai vu rouge parce que je devais choisir un bon truc à manger…), quand ça devient régulier dans le temps, ça fait partie des innombrables signes d'un épuisement mental vraiment problématique. Au travail, on va parler de burn-out, et en principe le terme ne s'applique que dans le monde professionnel mais, dans la pratique, je constate des effets similaires chez des mères de familles ou des gens engagés dans les asso. Trop à faire, trop à gérer, non stop, on n'en voit pas le bout, il y a trop peu d'espace pour décompresser, se reposer, etc, et la cocotte-minute finit un jour par sauter.
Ce sont des signaux d'alertes à prendre sérieusement en compte. Et en fait, c'est plutôt bon signe d'être capable d'envoyer paître les gens (même s'ils n'y sont pour rien), ça veut dire qu'on est en état de ralentir l'arrivée dans le mur, de dire non à une partie des trucs à gérer. C'est pas très cool à vivre, cependant (pour soi comme pour les autres), mais bon…
Pour le coup, je trouve que la plupart des gens sont effectivement très compréhensifs quand on explique notre état mental (sans doute parce qu'il y en a pas mal qui vivent ça à des degrés divers…). Ça aide à faire face. Plus que les conseils à la noix des pseudo-coachs… j'ai un peu envie de bouffer ceux qui me conseillent de "prendre des vacances" : ouais, comme si je pouvais partir 3 mois à l'autre bout du monde avec juste ma liseuse, sans aucune conséquence pour ma vie ou les gens auprès de qui je me suis engagée…
Bref, ceci est donc aussi un appel général : envoyez paître les demandes avant de craquer :D
(Malheureusement, les badbots ne sont pas du tout compréhensifs, par contre…)
[^] # Re: Epuisement
Posté par Tarnyko (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 02 septembre 2026 à 13:18.
Exact ! Et aussi parce que si tu ne le fais pas, personne ne prendra ça sérieux… sauf trop tard : à ton "vrai" burnout et/ou quand les résultats ne seront pas là à temps. Avec le risque qu'on dise que c'est ta faute en plus 🫠.
Nan mais ouais, ça c'est classique : beaucoup qui conseillent, personne qui paie.
# l'humain toujours
Posté par orfenor . Évalué à 9 (+7/-0).
Aaaahhhh bravo ! merci de le rappeler.
# Je ne sais pas s'il y a de solution parfaite mais
Posté par Selenith (site web personnel) . Évalué à 10 (+12/-0).
Perso j'utilise plusieurs petits tricks qui marchent bien pour le moment.
Pour mon blog qui doit être accessible aux inconnus, j'ai banni les systèmes dynamiques. C'est un site statique en pur HTML/CSS généré avec Zola. Pas de langage interprété derrière. Ce n'est pas toujours possible pour tout le monde, mais en tout cas les serveurs web sont optimisés pour ça, c'est super robuste. Même la recherche est gérée coté client.
Pour les services qui craignent plus les requêtes car elles engendrent des traitement en PHP/base de donnée j'ai tout simplement forcé l'authentification par certificat P12 (comme ça et comme ça), vu que ce sont des services uniquement disponibles pour mes utilisateurs/utilisatrices et que je peux leur demander d'installer les certificat dans leur navigateur (en plus une fois que c'est fait, ils/elles gagnent en confort). Le serveur web n'accepte même pas la requête si aucun certificat n'est présenté, du coup tous les bots sont jetés avant même de pouvoir vraiment consommer des ressources.
Et pour tous les bots à la noix qui essayent de taper des pages au hasard sur l'IP du serveur sans même sélectionner un Vhost valide je clôture la connexion avec un bon gros erreur 444 via nginx.
C'est pas magique, mais ça permet à mon petit serveur ne ne jamais trop monter dans les tours. Après j'ai un petit service maison qui scanne mes logs en permanence et bloque les IPs les plus énervées au niveau du firewall de ma DMZ en amont. Mais c'est un système qui est proche de Reaction (qui est assez classique dans sont fonctionnement avec des regex) dont tu as parlé dans ton post, je ne détaillerais donc pas ce point.
En tout cas, force à toi et à celles et ceux qui s'auto-hébergent 😉.
[^] # Re: Je ne sais pas s'il y a de solution parfaite mais
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Ho, mais c'est très intéressant le coup du certificat ! Merci pour le partage, je n'avais pas encore ça dans mon horizon.
Après, oui, de toute façon faut cumuler plein de trucs par rapport aux diverses menaces et suivant ce qu'on a comme trucs sur le serveur.
# Reload
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Je viens de voir ce commentaire bsky (lié à une discussion dans un lien plus haut) :
Alors… ça parait effectivement un peu absurde vu comme ça, mais en fait, je me demande si ce ne serait pas une façon d'alimenter une liste d'ip "à voir". Quelqu'un qui recharge la page dans les 5 minutes est très probablement un humain qui s'est dit "heu, j'ai internet qui a bugué".
On a ça dans les tactiques de mail : un premier handshake, on demande de revenir plus tard, et on laisse passer la seconde fois. Ça filtre pas mal sur le mail sans tout régler (et ça crée des tas de soucis à côté, aussi, genre ces serveurs de GAFAM crétins qui retentent avec leur second serveur mail, et il faut attendre qu'ils aient passé les 10 en leur possession pour voir revenir le premier et son courrier…).
Appliquer ça sur le web ferait sans doute partie des solutions un peu boiteuses, mais qui pourraient peut-être permettre de gérer ce genre de DDoS sans trop bloquer les personnes légitimes. Parce que là, dans les logs, en une heure de temps, 99,9% des ip ne faisait qu'une seule et unique visite.
Techniquement, comment ? Je ne sais pas. Mais je serais curieuse d'explorer l'idée.
[^] # Re: Reload
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+8/-1).
Tu configures ton serveur web.
Si la requête arrive avec un cookie, tu la laisse passer normalement.
Si la requête arrive sans cookie, tu sers une page qui installe un cookie et contient le texte "protection anti robot. appuyez sur F5 ou control+R pour entrer."
Y'a sûrement moyen de rendre le truc plus compliqué, genre un cookie qui dépend (de façon non triviale, genre sel+hash) de l'IP qui fait la requête, pour empêcher qu'il soit réutilisé par quelqu'un d'autre. Mais là, tu risques de commencer à bloquer les gens qui utilisent Tor, par exemhle.
Ça va fonctionner avec les robots de scrapping: la page ne contenant aucun lien, ils ne vont pas se rendre compte qu'il y a tout un site à découvrir derrière. Ça ne marchera pas avec le pur DDoS dont le but est d'envoyer des requêtes en masse, peu importe le contenu, pour faire tomber le serveur.
Je commence à me demander si on est pas dans ce deuxième cas: le but serait oe rendre le web "normal" invivable, et oe pousser un maximum de choses à passer à travers cloudflare, permettant à ce dernier et au gouvernement américain d'espionner facilement tout le traffic comme ils le faisaient par d'autres moyens avant le déploiement généralisé de https. L'excuse des robots scrappers pour les LLM étant parfaite pour qu'on ne cherche pas d'où ça vient. Est-ce que je vire parano-complotiste?
[^] # Re: Reload
Posté par Zatalyz (site web personnel) . Évalué à 6 (+4/-0).
Disons que même si je pense que les scrappers-llm sont dans le problème… je doute que ce soit la seule chose derrière ces attaques. Il y a, je trouve, des choses bizarres. Typiquement là : il y avait plusieurs domaines sur le même serveur, certains très anciens, d'autres avec une très grosse visibilité, et l'attaque ne visait qu'un seul des domaines. Pourquoi celui-ci et non les autres ?
On nous a longtemps dit "indexer le web pour faire un nouveau moteur de recherche, oulah, ça coûte trop cher". Sauf que c'est bien ce que les LLM ont fait pour entrainer leurs modèles, non ? Et que ces bots semblent reproduire ? Soudain ça ne semble pas un coût si difficile pour des boites assez "neuves".
Je sais que dans les bots que je bannissais de mon serveur mail (à la recherche de failles), il y avait ceux d'une boite se prétendant être de "sécurité" (sur son site officiel). C'est vrai que tenter d'exploiter les failles pour venir dire ensuite "avec nous, vous serez protégé", c'est une tactique commerciale. Douteuse, illégale même sans aucun doute, mais si ça permet que les gens paient ? Peut-on envisager que des services de proxy genre Cloudflare jouent aussi à ça ? Après tout, en tant que MitM, ils ont déjà accès à des milliers d'ip pour faire ça…
Il y a aussi des intérêts gouvernementaux à fliquer sa population, à pousser à ce que la navigation ne soit pas privée mais identifié : le rêve de tout totalitarisme. Et le capitalisme aussi adore ce genre de totalitarisme : pouvoir pister chaque individu pour savoir exactement dans quel algorithme le guider et qu'il consomme au maximum avec les bonnes incitations au bon moment (les pubs ? c'est trop 2000 les pubs… y'a des tactiques plus efficaces), c'est déjà assez documenté sur d'autres pratiques.
Peut-être aussi qu'on sert de test pour des hackers qui prévoient des DDoS sur des cibles plus stratégiques. "Ce petit projet libre sans moyen nous a mis hors-ligne en une semaine, l'entreprise/l'état qu'on vise le fera en une journée ; on tente ou on attends d'avoir plus de bots ?"
Tout ceci est effectivement du niveau des théories parano-complotiste, mais comme dirait un cher ami paranoïaque : "parfois, une des théorie s'avère valide".
Je me méfie un peu des analyses trop rapides (j'ai fait assez d'erreur avec ça) : oui, ces DDoS peuvent être le fait d'agents IA, mais il y a des aspects qui ne collent pas du tout avec ce que j'ai compris de l'IA (un savoir assez léger, cependant, je l'admet). Qu'est-ce qu'on va trouver derrière ces DDoS à la fin ? Je trouve que ce n'est pas si clair que ça et je me méfie du "on-dit", largement utilisé en propagande.
En tout cas, à mes yeux, le web ouvert et anonyme est de plus en plus en danger (et le reste d'internet n'est pas loin derrière), non pas avec un seul complot, mais via un faisceau de divers acteurs immoraux, parce que oui, tout cela nous pousse à fermer, à contrôler, à briser les anonymats.
[^] # Re: Reload
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Les millions de dollars semblent pleuvoir sur ces entreprises en ce moment. Du point de vue des investissements, on se souvient peut-être de WeWork, l'entreprise qui investissait dans l'immobilier en faisant croire qu'elle était une entreprise de la tech.
Là, c'est l'inverse: des entreprises de la tech qui arrivent à convaincre les investisseurs que leurs dépense (en construcyion de datacenters, en matériel pour entraîner les modèles, en bots pour ingurgiter toujours plus de données), ce n'est pas de la tech, c'est de l'infrastructure. Et que l'investisseur qui a mis ses sous dans l'infrastructure, il aura une rente très intéressante pour les décennies à venir, à condition d'investir dès le début.
Bref, si un investisseurs est prêt à verser des centaines de millions ou des milliards de dollars, indexer le web, ça devient tout à fait envisageable.
Et il y a un autre aspect: les LLM sont très bon pour une chose, c'est stocker toutes ces informations, une fois digérées, de façon très compacte (c'est de la compression avec perte, comme on sait très bien le faire pour des flux vidéo par exemple). Ce qui explique pourquoi ils viennent re-demander les données sur les serveurs originaux, encore et encore: chez eux ils ne stockent que la version digérée, compressée par le LLM. Pas l'original. Ça coûte moins cher de venir le re-chercher à chaque fois.
Et en fait, tous les gens qui prennent un abonnement à Netflix, Spotify, Google Workspace… c'est le même principe. Internet est tellement efficace que aujourd'hui ce n'est plus rentable de stocker ses données chez soi. Et, du coup, peut-être le web victime de son succès?
Par ailleurs, j'ai toujours un gros problème avec "oulah, ça coûte trop cher". C'est souvent un moyen de dissuader les gens de se lancer et de protéger un monopole. En termes de moteur de recherche qui essaie d'indexer le web avec peu de moyens, https://about.marginalia-search.com parle de 200 dollars par mois, avec des résultats tout à fait honorables.
# Bravo!
Posté par DarkHack . Évalué à -3 (+0/-1). Dernière modification le 20 septembre 2026 à 20:47.
Zatalyz félicitation, j'applaudi l'approche, on se met pas a parler anglais
en apprenants par cœur les conversion des mots, mais en essayant de communiquer
avec le peu que l'on connais.
La sécurité réseau pour moi à commencer ainsi, comme toi, fermé la porte à moi même.
Terrible constat des besoin de déplacements sur place, après avoir perdu sa chaussette, on vas chercher la console.
J'ai appris depuis ses années d'expérience, en tant que propriétaire du domaine DarkWeb.fr depuis sa création en 2011, aujourd'hui j'essaie de le retransmettre au mieux,
J'ai nommé sa DarkWall : https://toqqee6cwewdumm4aubkcc02f5oou0tktial01i4wa3.darkweb.fr/DarkHack/posix/darkwall/form/
car oui, quand tu prend en main ton hebergement, bien d'etrange signaux navigue, déjà entendu parlé des icmp9? ou ra poisonning? ha!!!! beaucoups de copains son pas prêt.
https://toqqee6cwewdumm4aubkcc02f5oou0tktial01i4wa3.darkweb.fr/DarkHack/pkg/
Le monde des bots à changé, perso en 2025, c'etait surtout du hurrican, aujourd'hui on a du cyberconvoy, rootevidence.
pour les curieux à fail2ban :
<= Attention, ne faite pas cela chez vous, surtout, si vous utilisez un wordpress.
Beaucoup de site vitrine pourrais être converti en shtml en evitant le php complétement (ce qui allegerais deja bien correctement ton apache car il n'ouvrirais plus le php a chaque demande), un exemple de site en structure shtml :
https://toqqee6cwewdumm4aubkcc02f5oou0tktial01i4wa3.darkweb.fr/DarkHack/shtml/DarkHack/form/
c'est une solution sérieuse car pas de gros mod apache2, juste :
Ah oui j'oubliais les PCRE/regexp soit les modules de recriture d'url, si tu peu t'en passé tu reduite encore la surface d'attaque.
bon vue que le public aime les textes sans IA, bon celui ci sera ni corrigé, ni remodelé.
Brut tels le Franc-Comtois que je suis.
"Combien de temps des bidouilleuses dans mon genre parviendront à maintenir des bouts d’internet ? Je ne sais pas. Ça finira peut-être en intranet, mes bidouilles… on en est déjà pas si loin." <= peu être plus longtemps que certains Titans, eux on l'argent, nous la volonté.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.