Salut,
Je m'occupe d'un serveur (qui est dans les locaux de l'association qui l'utilise car la connexion est assez aléatoire dans leur pampa). Il est derrière une box orange.
Je recois des messages de connexions du type
[Fail2Ban] sshd: banned 101.132.188.120 from Polo
Parfois plus d'une cinquantaine par heure.
A priori, l'accès ssh se fait par clef privée/publique seulement (il faut que je vérifie, ça fait longtemps que j'ai configuré ce serveur … mais je n'y ai pas accès pour le moment).
Donc, l'accès ssh par mot de passe ne fonctionnera jamais. Ceci étant, faudrait-il faire quelque chose ?
Je n'ai jamais eu autant de tentatives de connexion (ça dure depuis 2 semaines).
Merci d'avance pour vos conseils.
# à voir
Posté par NeoX . Évalué à 6.
je dirai que si ton acces se faire par clef
et que fail2ban te dis qu'il a bannit
ben c'est qu'il fait bien son boulot ;)
apres si c'est souvent la meme ip qui revient (trop) souvent
tu peux peut-etre augmenter la durée du bannissement par exemple.
utiliser whois pour savoir à qui appartient cette IP
ici
c'est donc une adresse chinoise, dans un cloud chinois (Alibaba)
si tes utilisateurs ne vont jamais en chine, tu peux utiliser des filtres GeoIP pour ne laisser rentrer que certains pays sur ton site/serveur.
[^] # Re: à voir
Posté par ComputingFroggy (site web personnel) . Évalué à 2.
Oui, il y a des adresses IP de la Chine … mais pas que ! Et beaucoup d'adresses différentes, jamais la même.
Cependant, je retiens le filtre GeoIP que j'avais oublié (merci pour le rappel) et que je n'avais manifestement activé.
Je vais vérifié mais je crois bien que toutes les connexions sont depuis la France voire même le même département ! ;)
# Autre port ?
Posté par AncalagonTotof . Évalué à 1.
J'ai pris l'habitude de ne jamais laisser un sshd publique sur le port par défaut.
Ça les attire en essaims !
Mais il faut que ce soit possible de changer le 22 par autre chose.
# Récidive
Posté par xandercagexxx . Évalué à 8.
Je te conseil d'activer "recidive" dans fail2ban. Tu peux même en ajouter plusieurs pour augmenter la durer du ban pour les ip qui reviendrait trop souvent.
L'avantage cest que tu ne banni sur une longue période que les ip qui sont vraiment insistante.
Recidive utilise le fichier fail2ban.log là où les jail de départ utile le auth.log (on ne banni donc sur le long terme que les ip qui ont déjà été ban. Ça évite les erreurs).
Après, le changement du port par défaut pour le ssh est aussi un bon moyen de limiter les tentatives d'intrusion, dans le sens où beaucoup de bot ne font que scanner le port standard ssh.
[^] # Re: Récidive
Posté par AlexTérieur . Évalué à 2.
+1 j'allais le dire.
J'avais régulièrement des problèmes de ralentissement de mon serveur à cause des attaques type "brute force". Tout le monde me disait que c'était normal jusqu'à ce que je tombe un article qui expliquait d'activer le filtre "recidive" et maintenant j'ai beaucoup plus la paix.
[^] # Re: Récidive
Posté par Graveen . Évalué à 2.
Merci pour l'info :)
[^] # Re: Récidive
Posté par AlexTérieur . Évalué à 0.
Autre paramètre à tenir en compte, désactiver l'authentification root pour ssh. 90% des attaques se font par des tentatives de connexion au compte root. On peut ensuite activer un filtre qui va surveiller l'IP et la bannir dès la seconde tentative.
Aussi ce que j'ai remarqué, ce sont des tentatives avec un nom de user aléatoire. Il y a sans doute un moyen de détecter ça et d'appliquer un filtre.
# Auth par mot de passe activée ?
Posté par lagou . Évalué à 4.
Les tentatives d'authentification par mot de passe sur un serveur ssh n'autorisant que l'authentification par clés n'apparaissent pas dans auth.log. SSH coupe la connexion avant que la phase d'authentification n'entre en jeu, à la phase du choix de la méthode d'authentification. Failtoban n'est donc pas sollicité. L'authentification par mot de passe est sûrement active sur ton serveur.
Le changement de port n'est pas une mesure de sécurité : ce n'est d'ailleurs pas préconisé par l'anssi dans son guide de sécurisation de ssh. Cela donne à mon sens un faux sentiment de sécurité qui est préjudiciable. Éventuellement, c'est une mesure de confort en évitant des logs dans auth.log si l'authentification par mot de passe est activée, ce qui ne devrait pas être le cas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.