bonjour, si on peut lister les URL légitimes, un silent DROP systématique permet de ne pas confirmer la présence d'une cible potentielle, non ? À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les tentatives de brute force qui atteignent le service protégé, a besoin d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence et la nature de la cible (sshd) sont confirmées à l'attaquant.
Éric Dégenètais Le ven. 7 juin 2019 17:48, Daniel Caillibaud <[email protected]> a écrit : > Le 07/06/19 à 16:39, Florian Blanc <[email protected]> a écrit : > > > Et ça change vraiment grand chose ? > > > cf. modele OSI ton firewall refusera les connexions layer 3/4. > > Merci ;-) > > Ce que je voulais dire, c'est que le gain de perfs[1] est tellement > négligeable que je pense qu'on arrive même pas à le mesurer sur une machine > en prod (qui bosse). > > Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions > ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas > envisageable dans mon contexte (mes ssh publics doivent rester accessibles > par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas > d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé. > > [1] si y'en a un, faudrait comparer ce que coûte une règle iptable > supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions > ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper). > > -- > Daniel > > La médecine est un métier dangereux : > les clients qui ne meurent pas peuvent porter plainte. > Coluche > >
