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 <mailto: 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 <mailto: 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 <mailto: a écrit : Le 07/06/19 à 16:39, Florian Blanc <mailto: 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
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
Le ven. 7 juin 2019 à 18:39, Florian Blanc <florian.blanc.adm@gmail.com
<mailto:florian.blanc.adm@gmail.com>> 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 <edegenetais@henix.fr
<mailto:edegenetais@henix.fr>> 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 <ml@lairdutemps.org
<mailto:ml@lairdutemps.org>> a écrit :
Le 07/06/19 à 16:39, Florian Blanc
<florian.blanc.adm@gmail.com
<mailto:florian.blanc.adm@gmail.com>> 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
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 <mailto: 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 <mailto: 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 <mailto: a écrit : Le 07/06/19 à 16:39, Florian Blanc <mailto: 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
steve
Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :
Il est donc possible que 2222 soit trop simple
C'est ce qui semble en effet. J'ai choisi un port différent (guess what) et depuis 4 jours, pas une seule tentative !
Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :
Il est donc possible que 2222 soit trop simple
C'est ce qui semble en effet. J'ai choisi un port différent (guess what)
et depuis 4 jours, pas une seule tentative !
