Le 25/04/2024 à 17:29, Sebastien Guilbaud a écrit :
> c'est de la sécurité par l'obscurité,
C'est la mesure la plus efficace (sauf si c'est la seule).
bof, se dire que les vilains ne trouveront pas le service ssh vu que tu l'as mis sur un autre port, ca peut donner une fausse sensation de sécurité, c'est ce que j'appelle la sécurité par l'obscurité. C'est dommage de tomber sur cette technique en première étape de tutos à neuneus qui ne prennent même pas la peine de bloquer l'authentification par mot de passe ou jouer un peu avec MaxStartups pour réduire le débit des bruteforce.
La mesure réellement la plus efficace, c'est que le service ne soit pas ouvert à tous vents. (filtrage sur IP source, VPN ou port knocking comme dit plus haut)
Changer le port ssh a l'inconvénient de sortir du standard ; si l'administration
devait être reprise par quelqu'un d'autre, ce serait une source de galère
supplémentaire.
Argument recevable mais alambiqué. Si tu refiles l'admin à quelqu'un d'autre, tu remets tous les sshd exposés sur le port 22 et basta
et quand tu distribues la conf ssh versionnée à tous les collègues pour accéder à toutes les machines derrière le rebond, c'est un non-problème.
(Merci openssh 7.3p1+ et ~/.ssh/config.d/)
De plus, les tentatives de connexions ssh permettent de faire une moisson
d'adresse IP à bloquer. Sans être un expert en attaque, je me dis que même les
pirates pro (pas les kiddies donc) ne doivent pas se priver de commencer à
tester le port 22 et là, paf, il sont bloqués avant de mettre en œuvre des
techniques d'attaques plus avancées ou plus larges que celles des kiddies.
toi, t'as pas regardé ce que fait endlessh :) ça ne bloque rien, tu collectes aussi les adresses des attaquants si ça t'intéresse, mais tu leur fais surtout perdre du temps avec une réponse protocolairement correcte, juste très lente. (en consommant très peu de ta bande passante, même avec un grand nombre d'attaquants simultanés)