le client va timeout

Le ven. 7 juin 2019 à 18:39, Florian Blanc <[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]> 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
>>>
>>>

Répondre à