Discussion :

[soumou]

salut,
ethereal est sniffer qui peut sniffer desmots de passe sur des protocoles comme ftp (c'est le seul que je connais).
est ce qu'il y a d'autre type de mots de passe qui sont captés (en clair) par ethereal ?
Merci d'avance

[Eusebius]

Bah tous les mots de passe qui sont passés en clair !
mdp e-mail non chiffrés,
mdp web non chiffrés,
mdp telnet (il me semble),
mdp applicatifs non chiffrés...

[Katyucha]

mdp telnet (il me semble),

[HNT]

En fait n'importe quel protocle qui ne crypte pas donc par exemple
ftp
http
pop3
smtp
telnet
Les plus courant

C'est pour ça qu'on conseil de les remplacés par :

sftp (ex de serveur vsftp)
https (pour les webmin, phpmyadmin ou site ou tu introduit ton numéro de carte de crédit)
pop3s
ssh
smtp avec ssl

Bref on les remplace par un équivalent qui utilise ssl donc qui crypte la communication.

[maestro1303]

Bonjour à tous,

Est-il possible de remplacer aisément telnet par ssh? Je m'explique:
Je travaille dans une entreprise où le SI consiste pour l'essentiel en un seul produit CCBS sous cobol qui permet de facturer, de dégrever, d'encaisser, de créer des clients d'en supprimer, d'ouvrir des caisses d'en fermer etc... Or pour chaque connexion on utilse Telnet (port 23) et moyennant un sniffer on peut voir circuler un tas d'infos sur ce système notamment : login et mdp. Comment à votre avis pourrait on remplacer ce proto de connexion par ssh et est ce que ceci est coûteux?

Merci

[Katyucha]

Bien sur.
Il suffit d'installer un serveur SSH.

Quel type d'OS avez vous? Quelle version?


Le cout: ca se compte en 1 ou 2 hommes/jour pour l'installation et l'information (enfin, si vous avez un seul serveur).
Le plus long, ca sera de demander aux utilisateurs de passer par ssh (qu'est ce qu'ils utilisent actuellement pour se connecté en telnet ? putty? reflexion? )

Ensuite, je pense qu'un mois d'adaptation suffit. Tu récoltes chaque semaine les gens qui se connectent encore en telnet. Piqure de rappel gentille. Au bout d'un mois, tu coupes le service telnet (sauf si tu as des applications qui utilisent ce service)

Je m'y prendrais ainsi (avec l'aval de mon responsable)

Telnet, c'est mal

[toto019]

D'autant plus qu'avec SSH on peut faire exactement la même chose qu'avec Telnet, mais de manière complétement sécurisée, et bien plus encore (par ex VPN ssh).

Je ne connais pas Reflexion, mais si c'est Putty le client actuel, et bien c'est une case à cocher en plus ^^ (c'pas sorcier).

[David.Schris]

Il suffit d'installer un serveur SSH.

Quel type d'OS avez vous? Quelle version?

Et si jamais l'installation d'un serveur SSH n'est pas possible (ex. : pas de version existante ou compilation problématique pour le système utilisé), on peut toujours mettre en place un tunnel (SSL ou autre).

[maestro1303]

Bonjour à tous,

C'est vraiment très gentil à vous.

J'utilise une application en cobol sous unix sco développée par une société SI en France et qui nous offre un support complet: seulement tout fonctione avec Telnet et PUTTY.
nous avons un seul serveur et moins d'une centaine de clients à travers tout le pays. je voudrais vraiment en finir avec telnet!
Excusez moi car la réponse que je vous ai faites ici, n'est pas attentive et complète à mon goût car quelqu'un vient de m'appeler pour une chose urgente.

Mille mercis.

[David.Schris]

J'utilise une application en cobol sous unix sco développée par une société SI en France et qui nous offre un support complet: seulement tout fonctione avec Telnet et PUTTY.
nous avons un seul serveur et moins d'une centaine de clients à travers tout le pays. je voudrais vraiment en finir avec telnet!

Bonsoir,

Cela fait plus de dix ans que tout le monde devrait en avoir fini avec telnet...

Solutions possibles à votre problème (liste non exhaustive) :

1) Installer un serveur SSH sur votre serveur unix SCO [1] ==> OpenSSH fonctionne sous SCO (mais peut-être pas sur toutes les versions, à vous de vérifier).
Problèmes éventuels : vous ne savez pas installer OpenSSH, vous ne pouvez pas instaler OpenSSH sur le serveur (ex. : problème de version), vous avez peur de toucher à votre serveur (ex. : vieux et très "sensible" aux modifications), l'administrateur ne veut pas que qui que ce soit touche au serveur, etc.

2) Sans toucher au serveur et avec un coût (en logiciels/matériels, peut-être pas en temps/formation...cela dépend de vous et des compétences dans votre entreprise) faible, il est possible de chiffrer les échanges entre les clients et le (site du) serveur.
Pour cela, vous aurez besoin d'une machine supplémentaire (ou deux si vous voulez faire du "load-balancing", prévenir les risques de pannes, etc) qui sera placée entre les clients et votre serveur actuel sur le site du serveur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
client1/site1 ------------|         site serveur
                          |    +---------+    +-------------+
                          |    | serveur |----| serveur SCO |
client2/site2 ------------|----| tunnel  | ^  |             |
                          |    +---------+ |  +-------------+
client3/site2 ------------|                |
                          |                +---- (telnet)
                          |
       ...etc...
 
              <================>
                    ^
                    |
                    +----- (chiffré : SSL ou autre)

Les communications entre les clients et le site du serveur SCO seront chiffrées, les communications entre le serveur servant à créer le tunnel (une sorte de proxy, pour simplifier) et le serveur SCO resteront en telnet.
Avantage : pas besoin de toucher à votre serveur actuel.
Problèmes possibles : il vous faut au moins une machine de plus, du temps pour l'installer, la configurer et faire des tests.

Pour mettre en place ce type de tunnel, vous pourriez par exemple (au choix) :

• utiliser SSH pour créer un tunnel (cf. "SSH tunneling explained") ;
• utiliser une solution du type SSLTunnel ;
• créer un VPN SSL (ex. : avec OpenVPN).

Maintenant, documentez-vous sur les différentes solutions et discutez-en avec vos responsables/administrateurs.
Coût des logiciels = 0.
Coût du matériel : dépend de vos besoins (redondance ? fonctionnement 24/24 7/7 ? durée maximale d'indisponibilité ? type de (contrat de) garantie ? etc).
Coût humain : dépend des compétences dans votre entreprise (et de la volonté des personnels impliqués).
Coût de la formation : cf. ci-dessus.
Coût du déploiement : dépend de la solution choisie et de la façon dont les postes clients sont gérés (administrables à distance ? correctement maintenus ? etc).
Enfin, pour que cela fonctionne, il faudra probablement que la direction s'implique dans le projet.

A vous de jouer.

Cordialement,
DS.

[maestro1303]

David.Schris, qu'est ce que je peux dire après tous ces détails dont j'avais réellement besoin.
Je vais bien me documenter afin de choisir l'une ou l'autre des solution et je vous tiendrai aucourant de l'évolution des choses.

Et si je rencontre un problème en cours de route je vous tiendrai au courant également.

Merci Infiniment de votre aide

A bientôt!

[SnakemaN]

Ahhh un bon topic qui fini bien, un nouveau membre tres poli qui remercie gentiment et un bon conseiller !



C'est pas du trollisme mais ca me gonfle des gens qui posent des questions puis qui se barre apres...