Bloquer attaque http, ip multiple

Bonjour à tous,

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 :confused:

  • 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.

Effectivement c’est possible de bloquer des Pays avec fail2ban : https://www.webfoobar.com/node/54 (en quoi c’est pas plus simple d’ajouter des listes directement dans le firewall ? : Bloquer des adresses IP par pays | Guides Sécurité Linux
Mais tout ça utilise la lib geoip qui n’est pas / plus très fiable de ce que j’ai lu/constaté.

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 ?

C’est plutôt : X.Y.Z.0/24 ou X.Y.0.0/16

As tu essayé crowdsec (je connais juste de nom)?

Oui…

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…

C’est sûr c’est pas simple à déterminer et puis après à tester c’est encore une autre paire…

1 Like

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.

1 Like

Tu peux également envisager crowdsec qui permet de faire un bon ménage. Depuis son déploiement chez moi, j’ai radicalement réduis les attaqués.

Bonjour,

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.

Bonjour à tous,

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 :slight_smile:

David

Effectivement il y a un modèle économique derrière Crowdsec.
Cependant je crois que tout ce qui est en local est open source (libre je sais pas).

La collecte de data sert à peupler la base des abuses IP avec une durée de 4h.
Tu peux les voir dans les set Ipset qu’il a créé :

ipset -L -n crowdsec-blacklists

Name: crowdsec-blacklists
Type: hash:net
Revision: 6
Header: family inet hashsize 16384 maxelem 131072 timeout 300
Size in memory: 1843528
References: 1
Number of entries: 34745

Ok, cette base d’abuses est uniquement re-distribuer si on a l’offre payante !?

Par ce que dans mon ipset j’ai aussi beaucoup (plus) d’entrée que ce que je n’ai dans mes alertes/décisions

Name: crowdsec-blacklists
Type: hash:net
Revision: 6
Header: family inet hashsize 8192 maxelem 131072 timeout 300
Size in memory: 994312
References: 1
Number of entries: 28834
# cscli alert list  |grep "Ip" | wc -l
50

Du coup ça me met le doute… :upside_down_face:

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).

1 Like

Merci pour ces précisions @greg

En tout cas sur l’économie de ressources entre fail2ban et crowdsec y’a pas photo :

1 Like

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 :slight_smile:
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.

1 Like

Une autre approche qui peut être combinée avec fail2ban ou crowdsec pour identifier les bots : Creating a Robots.txt Honeypot

2 Likes

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. :+1: