> 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 ? exactement
Le ven. 7 juin 2019 à 18:34, Eric Degenetais <[email protected]> a écrit : > 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 >> >>
