Je persiste et signe qu'un DROP est je ne sais combien de fois mieux qu'un REJECT sur du traffic non legit. Il le bénéfice de masquer ton service. Le botnets peuvent avoir le timeout qu'ils veulent même de 1s c'est pas un problème. Justement à chaque DROP tu économise un ICMP destination-unreachable par rapport au REJECT...
après niveau lectures tu trouveras toujours de tout du style: les reptiliens existent et voici un peu de lecture : https://8e-etage.fr/2014/11/07/les-reptiliens-la-plus-grande-conspiration-politique-jamais-inventee/ Le ven. 7 juin 2019 à 19:37, daniel huhardeaux <[email protected]> a écrit : > Le 07/06/2019 à 18:40, Florian Blanc a écrit : > > le client va timeout > > Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des > outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur > timeout sera très court > > Une lecture par ex. > > http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject > > > > > Le ven. 7 juin 2019 à 18:39, Florian Blanc <[email protected] > > <mailto:[email protected]>> a écrit : > > > > > 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] > > <mailto:[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] > > <mailto:[email protected]>> a écrit : > > > > Le 07/06/19 à 16:39, Florian Blanc > > <[email protected] > > <mailto:[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 > > > >
