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...
Les réponses au message de Mihamina Rakotomandimby (mihamina@rktmb.org)
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 ?
Mihamina Rakotomandimby wrote in message : > 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.
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...
Mihamina Rakotomandimby wrote in message : > 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.
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).
> 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, 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.
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 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.
> 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.
Eric Razny wrote, On 10/10/07 1:45: >> 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.
Il faut replacer dans le contexte de la phrase de Nicolas qui est en amont dans ce fil, mais que Mihamina a coupé au montage: "Il est bien plus rentable de renforcer les mots de passe."
> 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.
Non, pas dans ce contexte. J'espère que c'est plus clair maintenant.
Patpro ~ patrick proniewski wrote, On 10/10/07 7:29: >>> Mais dans la vraie vie, est-ce que ceux la se cassent-ils vraiment >>> séparément? >> [...] >> tu vas trouver au maximum en 26+26 questions >> [...] >> 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.
C'est sûr. J'expliquais juste pourquoi *théoriquement* le système "knocking+mdp fort" était plus faible que "mdp très fort".
Eric Razny wrote, On 10/10/07 1:45: >> 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.
Non, on parlait de renforcer le mot de passe vs. ajouter du port knocking. Contre une attaque ciblée, renforcer le mot de passe est plus sûr que d'ajouter du port knocking (à complexité totale égale des 2 côtés).
> 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.
Il faut replacer dans le contexte de la phrase de Nicolas qui est en amont dans ce fil, mais que Mihamina a coupé au montage: "Il est bien plus rentable de renforcer les mots de passe."
Le mer, 10 oct 2007 at 05:29 GMT, patpro ~ patrick proniewski a écrit : > 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 filtrer le "bruit", l'analyse "temps réel" des logs et le bloquage au niveau ip (firewall) des incoséquents est assez efficace aussi. ( éventuellement couplé à une liste blanche d'adresses correspondant aux usagers connus réguliers )
> Le mer, 10 oct 2007 at 05:29 GMT, patpro ~ patrick proniewski > a écrit : > > 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 filtrer le "bruit", l'analyse "temps réel" des logs et le bloquage > au niveau ip (firewall) des incoséquents est assez efficace aussi. > ( éventuellement couplé à une liste blanche d'adresses correspondant aux > usagers connus réguliers )
j'en connais un qui pas plus tard qu'hier s'est locké à l'extérieur de son serveur à cause d'un système comme ça :)
Le Wed, 10 Oct 2007 08:37:24 +0000, patpro ~ Patrick Proniewski a écrit :
>> Pour filtrer le "bruit", l'analyse "temps réel" des logs et le bloquage >> au niveau ip (firewall) des incoséquents est assez efficace aussi. >> ( éventuellement couplé à une liste blanche d'adresses correspondant aux >> usagers connus réguliers ) > j'en connais un qui pas plus tard qu'hier s'est locké à l'extérieur de > son serveur à cause d'un système comme ça :)
Le Wed, 10 Oct 2007 07:04:07 +0000, Olivier Croquette a écrit :
> Eric Razny wrote, On 10/10/07 1:45: >>> 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. > Non, on parlait de renforcer le mot de passe vs. ajouter du port knocking.
Oops. Mais bon, un mot de passe *doit* être fort (ou bloquer le système après 3 accès par exemple, dans le cas des CB où tapper un code de 12 caractère sur un ATM est un peu longuet :) ).
> Il faut replacer dans le contexte de la phrase de Nicolas qui est en > amont dans ce fil, mais que Mihamina a coupé au montage:
>Le monsieur a dit d'ajouter des listes blanche :)
Quand tu es amené à te connecter à partir de plein d'endroits divers variés et imprévisibles, ce qui est quand même le cas de pas mal de gens, les listes blanches... -- Nina
Le Wed, 10 Oct 2007 11:19:56 +0000, Nina Popravka a écrit :
>>Le monsieur a dit d'ajouter des listes blanche :) > Quand tu es amené à te connecter à partir de plein d'endroits divers > variés et imprévisibles, ce qui est quand même le cas de pas mal de > gens, les listes blanches...
Pour ce cas de figure je garde une machine accessible de partout ( tu peux mettre ssh sur un port non standard et/ou du port-knocking ) qui elle est white-listée sur les autres. Par contre elle est considérée comme potentiellement offensive (ie whitelist ne veux pas dire blanc-sein).
Même sans ça si tu te rate (erreur de frappe sur un clavier qwertz par exemple) et que tu es bloqué, tu te loggue en faisant gaffe sur une autre machine et là tu y va par rebond.
Le Wed, 10 Oct 2007 08:37:24 +0000, patpro ~ Patrick Proniewski a écrit :
>> Pour filtrer le "bruit", l'analyse "temps réel" des logs et le bloquage >> au niveau ip (firewall) des incoséquents est assez efficace aussi. >> ( éventuellement couplé à une liste blanche d'adresses correspondant aux >> usagers connus réguliers ) > j'en connais un qui pas plus tard qu'hier s'est locké à l'extérieur de > son serveur à cause d'un système comme ça :)
Le monsieur a dit d'ajouter des listes blanches :)
Le mer, 10 oct 2007 at 11:19 GMT, Nina Popravka a écrit : > On 10 Oct 2007 11:14:26 GMT, Eric Razny wrote: >>Le monsieur a dit d'ajouter des listes blanche :) > Quand tu es amené à te connecter à partir de plein d'endroits divers > variés et imprévisibles, ce qui est quand même le cas de pas mal de > gens, les listes blanches...
Bah faut ajuster la sensibilité du filtrage. Et si on finit par se verrouiller l'accès parcequ'on ne se souvient pas du mot de passe, ça ne change plus grand chose :o)
Vulnerabilite.com ne peut être tenu responsable des propos tenus dans le Newsgroup fr.comp.securite
Message de Fabien LE LEZ (gramster@gramster.com) (09 Octobre 2007)
