J’ai de plus en plus (chez moi ou chez des clients) d’aspiration de contenu et/ou /d’attaque DDoS un peu pauvre (difficile à dire) et c’est difficile à contrer parce que ça vient de pool d’IP qui change quasi à chaque requête
X.Y.202.142
X.Y.65.224
X.Y.96.202
Z.A.202.138
Z.A.65.196
Z.A.96.206
Bien sûr ce sont des IP qui provient de Singapour, de Russie… du trafic illégitime au vu des requêtes / du nombres…
Et ça génère de gros ralentissements/fait monter le load bien fort et les requêtes légitimes n’ont plus de place…
Pour l’instant je monitore et je bloque des subnet entier (exemple X.Y.0.0/24)
Vous vous doutez bien que j’ai pas vraiment envie d’aller vers des trucs à la cloudflare… mais existe-t-il un équivalent « self hosted » et libre ?
L’idée de bloquer le trafic par pays ici n’est pas envisageable en plus d’être extrêmement peu fiable… Une idée serait de faire un programme qui fait ce que je fais. À savoir consulter le server-status et émettre des hypothèses de trafic illégitime + bloquer celui-ci. Mais ça existe peut-être déjà ?
Note : j’ai pas la main sur les connexions réseaux…ce sont des VPS et/ou des Proxmox avec des LXC qui ce fond attaquer…
David
Note: fail2ban ne semble pas être aussi intelligent que ça… a moins que vous ayez un bout de conf / doc pour m’aiguiller…
Fail2ban permet de bloquer des pays, par localisation.
Je n’ai pas la config sous la main.
Par contre, je bloque beaucoup de ranges des clouds : AWS, Google Cloud, Azure.
je le fais de temps en temps, et je n’ai rien automatisé, parce que ça ne pose pas de soucis à mes services, ça bouffe juste des logs.
j’ai aussi des regexps pour bloquer sur les trucs les plus courants : Wordpress (je refuse d’héberger cette merde), MySQLadmin etc.
Aussi certain client refuse de bloquer des pays entier (a juste titre) de peur de se privé de trafic… Aussi ça me chatouille niveau éthique de bloquer des pays entier… ça serait encore internet ? Du coup il y aurait une liste de pays ?
Tu penses à leur offre de blocklists ou à l’usage de crowdsec en lieu et place de fail2ban qui serait plus intelligent et pourrait bloquer ces attaques à IP multiple en provenance du même subnet ?
Sachant que pour faire ça bien, il faudrait se baser sur la base whois des allocations des RIR pour ne jamais aggréger des blocs alloués à des LIR différents.
J’ai prévu d’ajouter la fonctionnalité de détection de réseaux /xx dans reaction. Mais le risque reste présent de bloquer des blocs non concernés, comme dit @sekil. C’est tellement cas par cas comme situation que je vois pas trop quels thresholds il faudrait mettre en place…
Si tu ne vérifies pas les bases whois des RIR, il ne faut pas remonter au delà de /24, parce que les RIR n’allouent pas des préfixes plus spécifiques que /24.
Crowdsec est très efficace et détecte des scénarios que fail2ban est incapable de bloquer mais tout dépend de l’attaque. Pour des requêtes qui paraissent légitimes et dont les adresse IP sont très nombreuses il sera pas efficace.
Sinon plutôt de bloquer des pays entiers tu pourrais songer à drop les ASN Complet, 99% du temps les attaques proviennent de data center, il faudra ensuite gérer les rares cas de faux positif en mettant certaines IP en liste blanche.
Merci pour vos retours, J’ai commencé à déployer Crowdsec en test, c’est vrai que ça semble plus « intelligent » que fail2ban pour contrer les attaques. Ceci dit je sais pas dans quelle mesure c’est charte-CHATONS-freindly parce que ça cause « mutualisation » (= remonté de data chez un tiers) bon même si la société est Française le site est hébergé à San Francisco (mention légal) Typiquement j’ai peur (attention spéculation) que le modèle économique soit de récupérer de la data (les IP malveillantes) sur les crowdsec community pour détecter des intrusions et vendre des bases d’IP à bloquer aux autres… Oui parce que maintenant les bases sont payantes ce qui n’était pas le cas auparavant j’ai l’impression. (note : ce partage vers l’API centrale est désactivable : FAQ / Troubleshooting | CrowdSec)
Le dashboard local est déprécié Cscli dashboard deprecation | CrowdSec au profil de l’APP en ligne crowdsec non open source pour le coup… (pour le coup c’est pas indispensable à l’usage de Crowdsec)
Bref j’ai l’impression que le modèle économique se dessine et que ça se ferme un peu…
Toute proportion gardé bien sûr, on parle d’IP malveillante et non de data utilisateur… Je voudrais pas faire mon « libo-terroriste » hein
Non du tout.
Ce que tu vois dans les 2 set (v4 et v6) sont les IP collectées par tous les Crowdsec.
Les IP que tu vois via cscli sont celles qui sont ban spécifiquement sur ta machine.
J’ai proddé Crowsec y-a environs 1 an et franchement c’est un produit sans soucis (faux positifs assez rare).
Je garde fail2ban pour les filtres que j’ai mis en place fil des années car la création de « scénarios » Crowdsec est assez différente de simple regex (pas vraiement pris le temps non plus).
Après Crowdsec pour contrer une DDOS ça le fera pas. Je reste sur ma position de ban les AS de data center trop douteux
J’en ai une petite centaine de bannis et mes week-end sont bien plus tranquilles + économie de ressources conséquent.
Il existe JA3/S, et le plus récent JA4+, un algorithme d’empreinte pour identifier un client TLS (navigateur ou bot), et qui peut être utile dans le lutte contre les DDOS.
Quelqu’un a de l’expérience avec ceci ?
L’avantage en théorie est que ça permet de bloquer un bot peu importe l’IP source. L’inconvénient est le risque de faux positif, donc il faut probablement bannir avec une approche hybride (AS + emprunte).
Ça nécessite probablement une mention dans la politique vie privée, vu que ça implique calcule d’un emprunte navigateur, et traitement de celle ci. Ca me semble raisonnable dans la mesure ou l’emprunte identifie un navigateur (eg Firefox 123 à 130), pas un utilisateur, et qu’il n’y a pas d’association faite avec des données personnelles.
L’empreinte d’un navigateur est une donnée potentiellement personnelle, au même titre qu’une IP est une donnée potentiellement personnelle.
Donc ça semble bien raisonnable de le mentionner dans la politique vie privée.
