Quand il y en a qui ne veulent pas lâcher l'affaire.

Bambusa29

Chevalier Jedi
10 Avril 2022
411
172
88
Quand il y en a qui ne veulent pas lâcher l'affaire.
🤨


La même adresse IP : 154.213.192.53 (provenant d'un cloud européen) qui essaye de venir chez moi sur le port 443 plus de 2500 fois pendant la journée du 03 octobre et qui se fait jeter en amont par mon pare-feu.
😆


Apparemment, je ne suis pas le seul dans ce cas-là ; ce cloud semble être utilisé depuis la fin aout pour effectuer des scans de port, du Brut Force et du DDOS un peu partout dans le monde...

drop.png
 
Oh mais c'est de gentils pirate qui veulent du bien à notre ami @Bambusa29 :sick:
Plus sérieusement j'ai regarder dans mes logs mais apparemment aucune trace de cette gentille IP
Mais ce qui m'étonne c'est le nb d'alertes détectées par jour avec des répétitions comme ici
Capture.PNG
Je regarde pas trop ces log , pour l'instant les pirates me chérisses .
 
Pour le moment , je n'ai aucune IP qui tente quoique ce soit.
Bon après, mon nginx n'autorise que les IP FR. Ça doit aider ^^
 
  • J'aime
Réactions: Bambusa29
Il s'est arrêté ce matin vers 5h00 :D
Je n'ai pas refait le total, mais il a dû m'envoyer plus de 3000/4000 requêtes au total. Je ne peux pas voir les requêtes qu'il a envoyées au Proxy, car c'est le firewall qui a bloqué en amont, parce que c'est une IP qui est considéré comme 'Hostile' (Spamhaus DROP List : https://www.spamhaus.org/) par le pare-feu.

Il y a plus de 2000 recensements sur abuseIP provenant de 16 adresse IP de ce cloud depuis fin aout :

https://www.abuseipdb.com/check-block/154.213.192.0/24
 
Salut,
Je subis aussi quelques approches de la part d'adresses en 154.213, mais elles viennent plutôt des sous-réseaux 154.213.184.0/24 et 154.213.187.0/24. Elles se noient dans le flot habituel des tentatives d'attaques et ne poussent jamais le bouchon assez loin pour se faire exclure.
Code:
# cscli alerts list | grep 154.213
| 835 | Ip:154.213.187.244 | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-03 23:33:49.008505763 +0000 UTC |
| 823 | Ip:154.213.187.244 | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-03 16:17:01.621675508 +0000 UTC |
| 787 | Ip:154.213.184.14  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 20:28:47.149379565 +0000 UTC |
| 776 | Ip:154.213.184.14  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 17:40:51.156137 +0000 UTC    |
| 775 | Ip:154.213.184.15  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 17:07:11.23907176 +0000 UTC  |
| 771 | Ip:154.213.184.15  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 15:38:11.245060999 +0000 UTC |
| 769 | Ip:154.213.184.14  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 15:00:23.867197666 +0000 UTC |
| 761 | Ip:154.213.184.15  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 13:52:18.73421414 +0000 UTC  |
| 759 | Ip:154.213.184.15  | crowdsecurity/suricata-high-medium-severity | SC      | 51396 Pfcloud UG                                        |           | 2024-10-02 12:25:27.210867174 +0000 UTC |
 
Salut,
Je subis aussi quelques approches de la part d'adresses en 154.213, mais elles viennent plutôt des sous-réseaux 154.213.184.0/24 et 154.213.187.0/24. Elles se noient dans le flot habituel des tentatives d'attaques et ne poussent jamais le bouchon assez loin pour se faire exclure.

Salut @Eirikr70, ce sont les traces au niveau de ton proxy avec Crowdsec/Sucricata ?
As-tu moyen de voir le contenu des requêtes ?
 
Il s'est arrêté ce matin vers 5h00 :D
Je n'ai pas refait le total, mais il a dû m'envoyer plus de 3000/4000 requêtes au total. Je ne peux pas voir les requêtes qu'il a envoyées au Proxy, car c'est le firewall qui a bloqué en amont, parce que c'est une IP qui est considéré comme 'Hostile' (Spamhaus DROP List : https://www.spamhaus.org/) par le pare-feu.

Il y a plus de 2000 recensements sur abuseIP provenant de 16 adresse IP de ce cloud depuis fin aout :

https://www.abuseipdb.com/check-block/154.213.192.0/24
Comment ton pare-feu s'appuie-t-il sur les listes de Spamhaus ? Tu utilises un service de Spamhaus ? Tu copies leurs listes ?...
 
Comment ton pare-feu s'appuie-t-il sur les listes de Spamhaus ? Tu utilises un service de Spamhaus ? Tu copies leurs listes ?...

Ce sont des listes intégrées dans le pare-feu qu'il met à jour régulièrement.
J'en ai rajouté une perso 'nginx_perso' qui vient de mes blocages faits par 'Reaction' (fail2ban fork en Go) sur le serveur Nginx en aval.


parefeu.png
 
Le fichier de destination des ip à bloquer , il est intégré comment dans tes .conf ?
Est-il lu automatiquement par nginx ?
J'ai intégré la "commande" include /config/nginx/blockips.conf; dans la configuration Nginx et j'ai positionné la liste à cet endroit-là, ce qui fait qu'elle est lue automatiquement. Il y a eu une époque où j'alimentais cette liste à la main. Mais c'est plus simple avec une alimentation automatique de 198 903 adresses ou sous-réseaux IP.
EDIT : J'aimerais inclure un décompte du nombre d'adresses ou sous-réseaux transmis par chaque liste (pour pouvoir éliminer les listes qui ne sont plus actives). Mais ça dépasse mes compétences en shell.
 
Dernière édition:
  • J'aime
Réactions: MilesTEG
Je me suis construit un petit script d'agrégation des blocklists publiques, pour les injecter dans mon proxy inversé : https://github.com/Eirikr70/swag-blocklists, en complément de Crowdsec et Suricata.

Avant, j'utilisais aussi une mega liste de blocage avec Swag provenant de GitHub, mais maintenant que j'ai le pare-feu en amont ; c'est lui qui gère les blocages IP ; c'est plus efficace et surtout pas de retour 403 venant du proxy qui renseigne la techno utilisée.
Je ne sais pas si cela a aussi un impact sur les performances de Nginx quand tu gères une mega liste de 200K 'deny'.

Petite précision : si tu utilises Swag, tu ne peux pas cacher ou changer le nom du serveur retourné (il faut activer un module spécifique dans Nginx pour modifier les 'Headers' du serveur), sinon tu pourrais retourner autre chose que 'nginx' comme serveur.

Par exemple, chez moi, tout est redirigé vers un 404 si tu n'es pas bloqué en amont par le pare-feu, et la techno du serveur retourné est alors customisé :D :

serveur.jpg
 
Par exemple, chez moi, tout est redirigé vers un 404 si tu n'es pas bloqué en amont par le pare-feu, et la techno du serveur retourné est alors customisé :D :
Intéressant 🧐
Je veux bien ta méthode 😊

Je pensais avoir mis des pages 404 403 etc custom…
Mais il semblerait que ça ne fonctionne plus sur mon instance …
Si je tape une adresse bidon sur mon domaine j’ai ça :
1728457438943.png
 
@MilesTEG
Pour avoir un custom 404/403... sur un 'subdomain' qui n'existe pas, il te faut un fichier '/cheminconfig/swag/nginx/proxy-confs/default.conf' :

Code:
server {
   listen      80 default_server;
   server_name everythingelse;

   include /etc/nginx/snippets/404.conf;
}

server {
  listen 443 ssl http2 default_server;
  server_name everythingelse;

  include /etc/nginx/snippets/404.conf;

  include /etc/nginx/ssl/ciphers-subdomain.domain.tld;    # pour nginx seulement
}

Par exemple, chez moi :D

custom.png

EDIT : Pour Swag il faudra changer cette ligne 'include /etc/nginx/ssl/ciphers-subdomain.domain.tld;' par 'include /config/nginx/ssl.conf;'
 
Dernière édition:
  • J'aime
Réactions: Eirikr70 et MilesTEG
Après vérification sur l'image de 'Swag', le module 'header' est présent dans le répertoire '/etc/nginx/modules', donc il devrait aussi être possible avec Swag de manipuler les headers de réponse du serveur...

À tester en rajoutant ces deux lignes dans votre fichier 'nginx.conf' :

Code:
include /etc/nginx/modules/10_http_headers_more.conf;

puis dans la section 'http' :

Code:
more_set_headers 'Server: ce que vous voulez';
 
Avant, j'utilisais aussi une mega liste de blocage avec Swag provenant de GitHub, mais maintenant que j'ai le pare-feu en amont ; c'est lui qui gère les blocages IP ; c'est plus efficace et surtout pas de retour 403 venant du proxy qui renseigne la techno utilisée.
Je ne sais pas si cela a aussi un impact sur les performances de Nginx quand tu gères une mega liste de 200K 'deny'.

Petite précision : si tu utilises Swag, tu ne peux pas cacher ou changer le nom du serveur retourné (il faut activer un module spécifique dans Nginx pour modifier les 'Headers' du serveur), sinon tu pourrais retourner autre chose que 'nginx' comme serveur.

Par exemple, chez moi, tout est redirigé vers un 404 si tu n'es pas bloqué en amont par le pare-feu, et la techno du serveur retourné est alors customisé :D :

Voir la pièce jointe 13451
Merci pour cette réponse. J'ai essayé d'injecter les 200 000 adresses et sous-réseaux dans Iptables, mais ça a mouliné un paquet de temps sans résultat visible, donc j'ai pris peur et je suis revenu en arrière. Du coup je me suis limité à celle de Spamhaus. Comme je suis un novice en firewall, je m'y prends avec une certaine prudence. Mais j'ai bien conscience qu'il serait préférable d'avoir un blocage firewall (tous ports) plutôt que proxy inversé (port 443).
 
Question complémentaire : vous gérez une liste blanche sur votre pare-feu ? Si oui, elle est composée de quelles adresses ? Toutes les adresses privées potentielles ?...

Non pas de liste blanche sur mon pare-feu ; je n'ai que des listes de blocages. J'héberge mon blog chez moi, donc je ne peux pas être restrictif, tout doit pouvoir rentrer.