Bonjour,
Soit ce type de "protection" (sur un serveur dédié):
http://www.debian-administration.org/articles/268
En gros:
- je fais une requete sur le port 100, puis 200, puis 300 puis 400, dans
cet ordre
- c'est ensuite que je peux avoir acces au port 22, seulement de l'IP
qui a fait la combinaison.
On peut changer la combinaison comme on veut, quand on veut...
L'interet c'est de pouvoir REJECTer les attaques par force brute sur le
22, entre autres.mais ça peut etre aussi sur les autres ports.
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur
soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres
serveurs). Alors si ça peut m'aider...
On 09 Oct 2007 12:30:58 GMT, Mihamina Rakotomandimby :
- je fais une requete sur le port 100, puis 200, puis 300 puis 400, dans cet ordre - c'est ensuite que je peux avoir acces au port 22, seulement de l'IP qui a fait la combinaison.
Si tu peux demander au client de faire tout ça, est-ce que ça ne serait pas plus simple de changer carrément le port SSH ?
On 09 Oct 2007 12:30:58 GMT, Mihamina Rakotomandimby
<mihamina@rktmb.org>:
- je fais une requete sur le port 100, puis 200, puis 300 puis 400, dans
cet ordre
- c'est ensuite que je peux avoir acces au port 22, seulement de l'IP
qui a fait la combinaison.
Si tu peux demander au client de faire tout ça, est-ce que ça ne
serait pas plus simple de changer carrément le port SSH ?
On 09 Oct 2007 12:30:58 GMT, Mihamina Rakotomandimby :
- je fais une requete sur le port 100, puis 200, puis 300 puis 400, dans cet ordre - c'est ensuite que je peux avoir acces au port 22, seulement de l'IP qui a fait la combinaison.
Si tu peux demander au client de faire tout ça, est-ce que ça ne serait pas plus simple de changer carrément le port SSH ?
Nicolas George
Mihamina Rakotomandimby wrote in message <fefs9n$rho$:
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Mihamina Rakotomandimby wrote in message
<fefs9n$rho$1@cabale.usenet-fr.net>:
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur
soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres
serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine
par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Mihamina Rakotomandimby wrote in message <fefs9n$rho$:
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Mihamina Rakotomandimby
Nicolas George wrote:
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Nicolas George wrote:
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur
soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres
serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine
par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber
aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre
chose à deviner...
Je lorgne de ce coté parceque j'ai cette fois-ci hérité d'un serveur soumis à beaucoup de ce type d'attaque (beaucoup plus que mes autres serveurs). Alors si ça peut m'aider...
Est-ce que ces attaques ont un impact sensible, sur la charge de la machine par exemple ? Sinon, je ne vois pas vraiment l'intérêt.
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Nicolas George
Mihamina Rakotomandimby wrote in message <fegtac$bp1$:
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe. D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile d'ajouter une couche de gadget par dessus.
Mihamina Rakotomandimby wrote in message
<fegtac$bp1$1@cabale.usenet-fr.net>:
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber
aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre
chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent
séparément. Il est bien plus rentable de renforcer les mots de passe.
D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de
sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile
d'ajouter une couche de gadget par dessus.
Mihamina Rakotomandimby wrote in message <fegtac$bp1$:
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe. D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile d'ajouter une couche de gadget par dessus.
Eric Razny
Le Tue, 09 Oct 2007 22:20:05 +0000, Nicolas George a écrit :
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe. D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile d'ajouter une couche de gadget par dessus.
Bonjour. Sur ce point je ne suis pas entièrement d'accord. Si un service doit être disponible pour tous (typiquement http) ou un nombre conséquent d'utilisateur (pop ou imap, ssh) alors on a pas trop le choix.
Par contre s'il y a une poignée d'utilisateur ssh qui ont un minimum de comptétance le port-knocking peut être interressant. Je ne parle pas de la faille openssl qui est passée il y a peu (elle touche par mal de services de facto) mais le port-knocking peut protéger des risques d'un 0-day sur ssh (dans cet exemple). Sans compter que dans le port-knocking rien n'oblige à envoyer un "simple" SYN, ce qui, avec le nombre de port, rend plus qu'improbable une attaque "au pif" réussie
Attention, je ne parle pas de securité par l'obscurité, ça n'empêche pas les mises à jour de sécu sur la machine, le banissement des passwords faibles etc (et si on parle d'unix-like les droits sur les répertoires et autres suid root laissent parfois rêveur).
Le Tue, 09 Oct 2007 22:20:05 +0000, Nicolas George a écrit :
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent
séparément. Il est bien plus rentable de renforcer les mots de passe.
D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de
sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile
d'ajouter une couche de gadget par dessus.
Bonjour.
Sur ce point je ne suis pas entièrement d'accord.
Si un service doit être disponible pour tous (typiquement http) ou un
nombre conséquent d'utilisateur (pop ou imap, ssh) alors on a pas trop le
choix.
Par contre s'il y a une poignée d'utilisateur ssh qui ont un minimum de
comptétance le port-knocking peut être interressant. Je ne parle pas de
la faille openssl qui est passée il y a peu (elle touche par mal de
services de facto) mais le port-knocking peut protéger des risques d'un
0-day sur ssh (dans cet exemple). Sans compter que dans le port-knocking
rien n'oblige à envoyer un "simple" SYN, ce qui, avec le nombre de port,
rend plus qu'improbable une attaque "au pif" réussie
Attention, je ne parle pas de securité par l'obscurité, ça n'empêche
pas les mises à jour de sécu sur la machine, le banissement des
passwords faibles etc (et si on parle d'unix-like les droits sur les
répertoires et autres suid root laissent parfois rêveur).
Le Tue, 09 Oct 2007 22:20:05 +0000, Nicolas George a écrit :
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe. D'ailleurs, des mots de passe faibles sont en eux-mêmes des problèmes de sécurité ; et à l'inverse, si les mots de passe sont forts, il est inutile d'ajouter une couche de gadget par dessus.
Bonjour. Sur ce point je ne suis pas entièrement d'accord. Si un service doit être disponible pour tous (typiquement http) ou un nombre conséquent d'utilisateur (pop ou imap, ssh) alors on a pas trop le choix.
Par contre s'il y a une poignée d'utilisateur ssh qui ont un minimum de comptétance le port-knocking peut être interressant. Je ne parle pas de la faille openssl qui est passée il y a peu (elle touche par mal de services de facto) mais le port-knocking peut protéger des risques d'un 0-day sur ssh (dans cet exemple). Sans compter que dans le port-knocking rien n'oblige à envoyer un "simple" SYN, ce qui, avec le nombre de port, rend plus qu'improbable une attaque "au pif" réussie
Attention, je ne parle pas de securité par l'obscurité, ça n'empêche pas les mises à jour de sécu sur la machine, le banissement des passwords faibles etc (et si on parle d'unix-like les droits sur les répertoires et autres suid root laissent parfois rêveur).
Mihamina Rakotomandimby
Nicolas George wrote:
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément.
Effectivement, le fait que les deux se cassent séparément fait qu'en probabilité ça revient au même. Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
Nicolas George wrote:
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent
séparément.
Effectivement, le fait que les deux se cassent séparément fait qu'en
probabilité ça revient au même.
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment
séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec
succès) l'un empeche l'autre (la connexion au demon SSH et la tentative
de login).
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément.
Effectivement, le fait que les deux se cassent séparément fait qu'en probabilité ça revient au même. Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
Olivier Croquette
Nicolas George wrote, On 10/10/07 0:20:
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe.
C'est peut-être vrai pour les attaques ciblées, mais par contre toutes les attaques automatiques vont être écartées.
Les avantages que je vois sont: 1. une protection efficace en cas de recherche *automatique* d'exploitation à une faille de SSH 2. une augmentation immédiate de la lisibilité logs sur le serveur, ce qui facilite la surveillance et donc indirectement la sécurité
En fait, le port knocking est comme un mot de passe préalable pour accéder au service. Port 22 ~= pas de mot de passe Changer d'écoute le port de SSH ~= mot de passe de 2 caractères (64k valeurs) Port knocking de 3 ports ~= mot de passe de 6 caractères
Juste changer le port est peut-être le bon compromis, car il faut aussi considérer la compatibilité au niveau des clients et la facilité d'utilisation.
Nicolas George wrote, On 10/10/07 0:20:
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber
aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre
chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent
séparément. Il est bien plus rentable de renforcer les mots de passe.
C'est peut-être vrai pour les attaques ciblées, mais par contre toutes
les attaques automatiques vont être écartées.
Les avantages que je vois sont:
1. une protection efficace en cas de recherche *automatique*
d'exploitation à une faille de SSH
2. une augmentation immédiate de la lisibilité logs sur le serveur, ce
qui facilite la surveillance et donc indirectement la sécurité
En fait, le port knocking est comme un mot de passe préalable pour
accéder au service.
Port 22 ~= pas de mot de passe
Changer d'écoute le port de SSH ~= mot de passe de 2 caractères (64k
valeurs)
Port knocking de 3 ports ~= mot de passe de 6 caractères
Juste changer le port est peut-être le bon compromis, car il faut aussi
considérer la compatibilité au niveau des clients et la facilité
d'utilisation.
Je me dis qu'en plus du mot de passe d'un compte systeme, il doit tomber aussi sur la bonne séquence de toc-toc. J'aurais introduit une autre chose à deviner...
Ce n'est pas un bon modèle de sécurité, parce que les deux se cassent séparément. Il est bien plus rentable de renforcer les mots de passe.
C'est peut-être vrai pour les attaques ciblées, mais par contre toutes les attaques automatiques vont être écartées.
Les avantages que je vois sont: 1. une protection efficace en cas de recherche *automatique* d'exploitation à une faille de SSH 2. une augmentation immédiate de la lisibilité logs sur le serveur, ce qui facilite la surveillance et donc indirectement la sécurité
En fait, le port knocking est comme un mot de passe préalable pour accéder au service. Port 22 ~= pas de mot de passe Changer d'écoute le port de SSH ~= mot de passe de 2 caractères (64k valeurs) Port knocking de 3 ports ~= mot de passe de 6 caractères
Juste changer le port est peut-être le bon compromis, car il faut aussi considérer la compatibilité au niveau des clients et la facilité d'utilisation.
Olivier Croquette
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment
séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec
succès) l'un empeche l'autre (la connexion au demon SSH et la tentative
de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me
demander séparement:
- est-ce que le 1er est "x"?
- est-ce que le 2ème est "y"?
tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander:
- est-ce que les 2 sont "xy"?
tu vas trouver au maximum en 26*26 questions
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
Eric Razny
Le Tue, 09 Oct 2007 22:50:44 +0000, Olivier Croquette a écrit :
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Je vois mal comment, s'il ne diminue pas la sécu de son ssh (et sous réserve que le gestionnaire du port-knocking soit bien écrit bien sur) il a au minimum la sécu d'origine. On a pas un chaine qui a la solidité du maillon le plus faible mais plutôt une porte de plus a passer.
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
Oui mais ça c'est plutôt qui est x1y1 suivit, en cas de succès de qui est x2y2... Ce n'est pas pareil.
Le Tue, 09 Oct 2007 22:50:44 +0000, Olivier Croquette a écrit :
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment
séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec
succès) l'un empeche l'autre (la connexion au demon SSH et la tentative
de login).
C'est justement la raison pour laquelle le système est plus faible!
Je vois mal comment, s'il ne diminue pas la sécu de son ssh (et sous
réserve que le gestionnaire du port-knocking soit bien écrit bien sur)
il a au minimum la sécu d'origine. On a pas un chaine qui a la solidité
du maillon le plus faible mais plutôt une porte de plus a passer.
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de
me demander séparement:
- est-ce que le 1er est "x"?
- est-ce que le 2ème est "y"?
tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander:
- est-ce que les 2 sont "xy"?
tu vas trouver au maximum en 26*26 questions
Oui mais ça c'est plutôt qui est x1y1 suivit, en cas de succès de qui
est x2y2... Ce n'est pas pareil.
Le Tue, 09 Oct 2007 22:50:44 +0000, Olivier Croquette a écrit :
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Je vois mal comment, s'il ne diminue pas la sécu de son ssh (et sous réserve que le gestionnaire du port-knocking soit bien écrit bien sur) il a au minimum la sécu d'origine. On a pas un chaine qui a la solidité du maillon le plus faible mais plutôt une porte de plus a passer.
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
Oui mais ça c'est plutôt qui est x1y1 suivit, en cas de succès de qui est x2y2... Ce n'est pas pareil.
patpro ~ patrick proniewski
In article <feh0ip$e83$03$, Olivier Croquette wrote:
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
le fait est que les outils d'attaque ssh en force brute ne font pas de port-knocking. Donc du point de vue du "filtrage du bruit de fond", changer de port le serveur ssh ou mettre un port knocking revient strictement au même. Et le problème initial c'est bien de filtrer le bruit de fond, pas tellement d'augmenter la sécurité. Pour la sécurité on peut utiliser un firewall, la config sshd, ... pour limiter l'accès à certaines IP, certains login, et même carrément interdir l'usage de mot de passe.
patpro
-- http://www.patpro.net/
In article <feh0ip$e83$03$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> wrote:
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment
séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec
succès) l'un empeche l'autre (la connexion au demon SSH et la tentative
de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me
demander séparement:
- est-ce que le 1er est "x"?
- est-ce que le 2ème est "y"?
tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander:
- est-ce que les 2 sont "xy"?
tu vas trouver au maximum en 26*26 questions
le fait est que les outils d'attaque ssh en force brute ne font pas de
port-knocking. Donc du point de vue du "filtrage du bruit de fond",
changer de port le serveur ssh ou mettre un port knocking revient
strictement au même.
Et le problème initial c'est bien de filtrer le bruit de fond, pas
tellement d'augmenter la sécurité.
Pour la sécurité on peut utiliser un firewall, la config sshd, ... pour
limiter l'accès à certaines IP, certains login, et même carrément
interdir l'usage de mot de passe.
In article <feh0ip$e83$03$, Olivier Croquette wrote:
Mihamina Rakotomandimby wrote, On 10/10/07 0:41:
Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment séparément? Je pense que non, parceque (le rejet si n'a pas knocké avec succès) l'un empeche l'autre (la connexion au demon SSH et la tentative de login).
C'est justement la raison pour laquelle le système est plus faible!
Si je choisis 2 caractères entre "a" et "z", et que tu as le droit de me demander séparement: - est-ce que le 1er est "x"? - est-ce que le 2ème est "y"? tu vas trouver au maximum en 26+26 questions
Si tu ne peux que demander: - est-ce que les 2 sont "xy"? tu vas trouver au maximum en 26*26 questions
le fait est que les outils d'attaque ssh en force brute ne font pas de port-knocking. Donc du point de vue du "filtrage du bruit de fond", changer de port le serveur ssh ou mettre un port knocking revient strictement au même. Et le problème initial c'est bien de filtrer le bruit de fond, pas tellement d'augmenter la sécurité. Pour la sécurité on peut utiliser un firewall, la config sshd, ... pour limiter l'accès à certaines IP, certains login, et même carrément interdir l'usage de mot de passe.
