Discussion :

[biglittlekiss]

Bonjour,

J'aimerai plus d'éclaircissement sur un sujet.


Je me connecte sur mon serveur via SSH.

Cependant j'aimerai faire en sorte d'avoir un fonctionnement ainsi:

Mon client se connecte avec SSH sur le port 22 du serveur.
Une fois connecté, mon serveur indiquer au client de changer de port, toujours en SSH. Ce port est aléatoire pour plus de sécurité.

Une fois le changement de port effectué, la session SSH s'effectue.
Cependant, un changement de port toutes les 30s est nécessaire pour plus de sécurité lors de la session SSH en l'administrateur et le ser veur.

Ma question étant, comment puis-je faire en sorte de faire ça?
J'avoue ne pas comprendre comment je peux changer de port sans risque d'interrompre la transaction de donnée entre le client et le serveur.

De plus, comment avoir toujours uen connection SSH sans interruption, et surtout qui suive mon changement de port?

Enfin bref, plein de question auquel je ne trouve pas de réponse.

Merci pour toute aide

[gorgonite]

c'est une subtilité du protocole tcp/ip... demandes plutôt sur développements réseaux

[Juju_41]

Je ne pense pas que ceci soit réalisable facilement ...

Simple curiosité, pourquoi vouloir "sécuriser" la connection ssh alors que ssh repose sur des sessions sécurisées (authentification forte + sessions chiffrées) ?

[biglittlekiss]

Il faut que je sécurise la transaction admin ==> serveur au maximum.

Et ça fait partie d'une subtilité pour le reste du système

[Aramis]

Je ne pense pas que ceci soit réalisable facilement ...

Simple curiosité, pourquoi vouloir "sécuriser" la connection ssh alors que ssh repose sur des sessions sécurisées (authentification forte + sessions chiffrées) ?

Salut,

perso je ne crois pas au cryptage, surtout qu'il a ete demontre, par exemple, dans l'article de J. Viega "Security is harder than you think" (ACM-Queue) que les protocols tel que SSH sont vulnerable a l'attaque dite "man in the middle" . Cependant, je reconnais que malgre tout ce n'est pas donne a tout le monde de pouvoir casse un cryptage SSH.

Pour en revenir au sujet, il est tout a fait possible de faire tourner le service SSH sur un autre port que le numero 22. Maintenant, il faut aussi etre capable de garder une trace de ce genre de changement, car en meme temps il faudra adapte le par-feu et etc. Et puis ce genre de methode n'arrete pas les techniques tel que NMAP.

Il me semble qu'il est possible de rediriger la communication sur un autre socket une fois l'echange initial termine. Malheureusement, c est un peu comme le FTP passif/actif pour la configuration du par-feu ca va etre quelque chose. Il y a de long sujets sur ce probleme ici meme sur dev. reseaux.

Par contre, le changement de port toutes les X secondes c'est "no no". C'est contre les principes meme de la communication via TCP.

Il faut que je sécurise la transaction admin ==> serveur au maximum.

Et ça fait partie d'une subtilité pour le reste du système

Va falloir etre un peu plus precis car la securite c est une combinaison de theme suivants:
- confidentialite
- protection
- detection
- correction
- authorisation
- accountabilite
- transparence
et bien d'autres

Cordialement,

Ar@mi$ chercheur Informatique et securite des reseaux

[Juju_41]

perso je ne crois pas au cryptage, surtout qu'il a ete demontre, par exemple, dans l'article de J. Viega "Security is harder than you think" (ACM-Queue) que les protocols tel que SSH sont vulnerable a l'attaque dite "man in the middle" . Cependant, je reconnais que malgre tout ce n'est pas donne a tout le monde de pouvoir casse un cryptage SSH.

Merci pour le lien J'oublie parfois que "chiffré" et "sécurisé" ne sont pas des synonymes.

Par contre, le changement de port toutes les X secondes c'est "no no". C'est contre les principes meme de la communication via TCP.

+1

J'ajouterai même le changement de port ne sécurise en rien la connexion SSH (en cas d'attaque "man in the middle" par exemple).

[Aramis]

Merci pour le lien J'oublie parfois que "chiffré" et "sécurisé" ne sont pas des synonymes.

Je t'en pris . A ce sujet, j'ai plusieur fois eu ce probleme de language que ce soit avec des eleves ou bien des conferenciers - c'est fou le nombre de gens qui se melengent les pinceaux sur le theme de la securite informatique. Il y a encore des gens qui pensent que s'il y a un mot de passe alors c'est securise . Voici une etude par le FBI a ce sujet : lien ca fait peur.

J'ajouterai même le changement de port ne sécurise en rien la connexion SSH (en cas d'attaque "man in the middle" par exemple).

noui (oui et non ). Ca depend comment l'intrus s'y prends. S'ils capturent tout en effet cette methode n'empechera rien. Cependant, si l'intrus ecoute pour qqc en particulier, l'efficacite sera augmente. Maintenant, je viens de tester une communication SSH avec un server a moi et j'ai remarque que meme si je n'arrive pas a donner le bon login et mot de passe j'obtiens quand meme la clef du server. C'est plutot simple comme procedure et c'est tout de meme la moitie du boulot. Ensuite, j'ai deja vu des exemples ou les intrus se procure la deuxieme clef (et les details logins/password) en s'introduisant sur la machine cliente. C'est dingue mais pour logiciel tel que Cisco VPN Client (que j'utilise pour me connecter au VPN de mon etablissement par exemple) tous les details pour se connecter sont dans un dossier! Et pour les reutiliser par qqn d'autre il suffit de recopier les fichiers

Enfin, bref il y a un autre topic vachement interressant sur ce forum qui a ete initie par JackBeauRegard je recommende la lecture

Ar@mi$

[biglittlekiss]

En fait, peu importe que se soit contre le protocole TCP, ou pas.

Le truc c'est que je suis obligé de le faire mais je ne vois pas du tout comment.

Enfin je continuerai mes recherche via google.

Merci

[Aramis]

En fait, peu importe que se soit contre le protocole TCP, ou pas.

Eh bien c'est important puisque c'est INCOMPATIBLE avec les possibilites du protocol. Tout le monde peut marcher mais personne n'a reussi a marcher jusqu'a la lune que je sache!

Le truc c'est que je suis obligé de le faire mais je ne vois pas du tout comment.

[..]

Je commence a penser que la ou les personnes qui vous imposent cette specification, n'y connaissent absolument rien en securite et protocols reseaux. Je ne peux que vous recommander de leur faire comprendre car vous perdez votre temps.

A.