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...
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.
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.
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.
Olivier Croquette
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".
Dans la pratique, je suis d'accord avec toi, cf <feh0c5$r2r$01$
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".
Dans la pratique, je suis d'accord avec toi, cf
<feh0c5$r2r$01$1@news.t-online.com>
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".
Dans la pratique, je suis d'accord avec toi, cf <feh0c5$r2r$01$
Olivier Croquette
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."
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."
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."
Dominique ROUSSEAU
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 <patpro@boleskine.patpro.net> 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 )
patpro ~ Patrick Proniewski
In article , Dominique ROUSSEAU wrote:
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 :)
patpro
-- http://www.patpro.net/
In article <slrnfgp1bq.dti.usenet@pacoli.in.lee-loo.net>,
Dominique ROUSSEAU <usenet@leeloo.fdn.fr> wrote:
Le mer, 10 oct 2007 at 05:29 GMT, patpro ~ patrick proniewski
<patpro@boleskine.patpro.net> 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 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 :)
patpro
-- http://www.patpro.net/
Eric Razny
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 blanche :)
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 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 blanche :)
Eric Razny
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:
A bas les ciseaux
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 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:
A bas les ciseaux
Nina Popravka
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... -- Nina
On 10 Oct 2007 11:14:26 GMT, Eric Razny <news_01@razny.net> 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...
--
Nina
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
Eric Razny
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 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 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.
Eric Razny
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 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 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 :)
