Provya

@nico :

ou pas.

Prétendre qu'il y a une seule solution absolue en matière de sécurité est la marque d'une grande méconnaissance pour ne pas dire incompétence, et est dommageable aussi bien pour la réputation de l'auteur que pour le domaine de la sécurité en général.

Une utilisation par clé uniquement complexifie sensiblement les choses, il faut maintenant avoir une politique de gestion des clés correspondant au modèle de menace, et ça impose un peu de gymnastique pour traverser la machine qui sert de rebond pour accéder au réseau interne. voir https://blog.octo.com/le-bastion-ssh/ pour plus de détails.

Au delà de cette complexification, elle introduit des incompatibilités avec certains usages et introduit des failles et des problèmes de sécurité avancées qui n'existent pas forcément avec un mot de passe.

L'usage de clé est souvent un bon choix mais ce n'est pas toujours le cas. Par rapport à mon modèle de menace personnel l'usage d'un bastion ssh dont le service est masqué derrière du port knocking apporte le niveau de sécurité suffisant sans avoir besoin de recourir à l'usage de clés.

Fail2ban ce n'est pas que du ssh. C'est aussi du contrôle pour le smtp, le pop, l'imap, le http, le ftp et de manière générale tout ce qui peut générer des logs utilisables, donc oui c'est très intéressant.

De plus même si vous avez des briques d'authentifications solides comme du roc, fail2ban permet de réduire le nombre de tentatives de connexion et d'éviter des dénis de service sur l'auth.

SSH c'est keypair auth only. Du coup fail2ban ne sert absolument à rien dans ce cas.

Par contre certain logiciel qui repose sur du mot de passe n'ont pas de sécurité de ce type par défaut et la oui un Fail2ban peut être intéressant.

@Guillaume :

Bah non justement , au titre de ton article je suis moi aussi déçu.Tu enfonces des portes ouvertes et c'est dommage !
Au final pour des services de base comme ssh , un simple durcissement de la conf suffirait sans parler du hardenning sytemd .
Ca te permet de ne pas rajouter un programme tiers comme Fail2ban à ton système et qui plus est tourne sur ta machine avec les privilèges root
Et attention , je ne dis pas que fail2ban ne sert à rien . Dans certains cas il est très complémentaire. Mais un peu de nuance aurait été de bon aloi et t'aurais différencié des centaines d'autres articles qui traitent du sujet sans vraiement connaitre les possibilités natives  :P
.

@Bruno :
Bonjour,

Ne vous trompez pas de lecture.
Cet article présente l'intérêt évident de fail2ban dans une stratégie de sécurisation d'un serveur ; il n'a pas vocation à discuter sur comment configurer et/ou sécuriser un serveur SSH.

Il est écrit nul part que fail2ban protège d'une attaque par déni de service distribué. Ce n'est d'ailleurs pas la fonction première de fail2ban.

Enfin, si on veut creuser le sujet, on pourrait s'interroger sur la pertinence même d'avoir un service SSH en écoute sur un serveur accessible par Internet sans aucun filtrage. Mais ce n'est pas le sujet de l'article. ;-)

Cordialement,

Guillaume
--
Provya

Ah ben zut alors…
J'attendais avec interêt les arguments sur l'inutilité de fail2ban. Mais non un seul point de vue, sans aucune nuance…
fail2ban est inutile pour un service SSH correctement configuré avec identification uniquement par clés.
fail2ban ne protège pas des faiblesses de configuration de services en amont.
fail2ban ne protège pas d'une vraie attaque DDOS.

Excellent article.
Perso j'utilise SShGuard sur un serveur dont seul le port SSH est ouvert sur internet. Efficace également.

--
cmic