telnet security

telnet security

Post by Tony Langd » Thu, 03 Dec 1998 04:00:00



It's 01 Dec 98  17:22:49,

discussion of telnet security

 rm> The connection between your system and machine X will be unencrypted,
 rm> and hence susceptible to snooping. The connection between X and Y will
 rm> however be encrypted.

 rm> Shortly put, this is not a secure connection, since it can be
 rm> intercepted in the clear at any point between your machine and machine
 rm> X, and hence the connection between X and Y can now be intercepted at
 rm> X.
 rm> Arindum

That depends.  Technically, you are correct, in that the section of the
link using telnet is in the clear and can be sniffed.  The question is
whether that clear link is over a private, trusted network, or an
untrusted (e.g. the Internet) network.  If it's the former, the overall
communication should be secure enough for most needs (unless the
"secure" network has been compromised), otherwise it's definitely
insecure.

So:

telnet from Windows to a UNIX box in the same office, then ssh to a
remote site is likely OK, but telnet across the Internet, then ssh to
the secure network is definitely a risk.

However, since TeraTerm and its ssh extensions are freeware
applications, even Windows users do not need to run their terminal
sessions in the clear, if a SSH server is available at the other end.

Final note:  Even while in ssh, beware of other services you open over
the Net.  It's all too easy to feel cosy in your SSH session and then
lapse and start an insecure FTP session between the same two hosts,
because you need to move some files. :-)

.. It's not what, but how.
--
|Fidonet:  Tony Langdon 3:635/728.18

|
| Standard disclaimer: The views of this user are strictly his own.

 
 
 

telnet security

Post by Arindum Muker » Thu, 03 Dec 1998 04:00:00



>It's 01 Dec 98  17:22:49,

>discussion of telnet security

> rm> The connection between your system and machine X will be unencrypted,
> rm> and hence susceptible to snooping. The connection between X and Y will
> rm> however be encrypted.

> rm> Shortly put, this is not a secure connection, since it can be
> rm> intercepted in the clear at any point between your machine and machine
> rm> X, and hence the connection between X and Y can now be intercepted at
> rm> X.
> rm> Arindum

>That depends.  Technically, you are correct, in that the section of the
>link using telnet is in the clear and can be sniffed.  The question is
>whether that clear link is over a private, trusted network, or an
>untrusted (e.g. the Internet) network.  If it's the former, the overall
>communication should be secure enough for most needs (unless the
>"secure" network has been compromised), otherwise it's definitely
>insecure.

In my experience, lax security in "private, trusted" networks is one of the
main reasons people get themselves into trouble with security. There's
no reason I can think of for exercising weak security practices in any
network. The former you mention leads to the latter.

Quote:

>Final note:  Even while in ssh, beware of other services you open over
>the Net.  It's all too easy to feel cosy in your SSH session and then
>lapse and start an insecure FTP session between the same two hosts,
>because you need to move some files. :-)

Amen to that. The number of times I have seen users insisting on SSH
connections, only to immediately FTP their files to the system
immediately afterwards...

Regards,

Arindum

 
 
 

telnet security

Post by Lachlan Cranswi » Fri, 04 Dec 1998 04:00:00



>>It's 01 Dec 98  17:22:49,

>>discussion of telnet security

>> rm> The connection between your system and machine X will be unencrypted,
>> rm> and hence susceptible to snooping. The connection between X and Y will
>> rm> however be encrypted.

>> rm> Shortly put, this is not a secure connection, since it can be
>> rm> intercepted in the clear at any point between your machine and machine
>> rm> X, and hence the connection between X and Y can now be intercepted at
>> rm> X.
>> rm> Arindum

>>That depends.  Technically, you are correct, in that the section of the
>>link using telnet is in the clear and can be sniffed.  The question is
>>whether that clear link is over a private, trusted network, or an
>>untrusted (e.g. the Internet) network.  If it's the former, the overall
>>communication should be secure enough for most needs (unless the
>>"secure" network has been compromised), otherwise it's definitely
>>insecure.
>In my experience, lax security in "private, trusted" networks is one of the
>main reasons people get themselves into trouble with security. There's
>no reason I can think of for exercising weak security practices in any
>network. The former you mention leads to the latter.

>>Final note:  Even while in ssh, beware of other services you open over
>>the Net.  It's all too easy to feel cosy in your SSH session and then
>>lapse and start an insecure FTP session between the same two hosts,
>>because you need to move some files. :-)
>Amen to that. The number of times I have seen users insisting on SSH
>connections, only to immediately FTP their files to the system
>immediately afterwards...
>Regards,
>Arindum

An almost instant repeat from me on a message posted to the SSH newsgroup.

What slick FTP (UNIX and Window) clients now support SSH?  Seems to
be a distinct lack of this that is visibly out there?  Not surprising users
might use "insecure" FTP if that is the only useable FTP client they have?

Lachlan.

Lachlan M. D. Cranswick
Collaborative Computational Project No 14 (CCP14)
    for Single Crystal and Powder Diffraction
Daresbury Laboratory, Warrington, WA4 4AD U.K
Tel: +44 (0)1925-603703  Fax: +44 (0)1925-603124  Room C14

CCP14 Webpage (Under heavy construction):
                                    http://www.ccp14.ac.uk

 
 
 

telnet security

Post by Tony Langd » Fri, 04 Dec 1998 04:00:00


It's 03 Dec 98  10:44:51,

discussion of telnet security

 rm> In my experience, lax security in "private, trusted" networks is one
 rm> of the  main reasons people get themselves into trouble with security.
 rm> There's no reason I can think of for exercising weak security practices
 rm> in any network. The former you mention leads to the latter.

You have a good point, and you rightly imply that a part of good
security is in developing secure habits (I know, I always reach for ssh
before telnet these days :) ).

 rm> Amen to that. The number of times I have seen users insisting on SSH
 rm> connections, only to immediately FTP their files to the system
 rm> immediately afterwards...

So easy to get caught off guard. :)

If no other alternatives exist, PGP encrypted email would be at least a
more secure, if somewhat clumsy alternative.

.. Don't blame me, it's San Andreas fault.
--
|Fidonet:  Tony Langdon 3:635/728.18

|
| Standard disclaimer: The views of this user are strictly his own.

 
 
 

telnet security

Post by vhal.. » Fri, 04 Dec 1998 04:00:00




>An almost instant repeat from me on a message posted to the SSH newsgroup.

>What slick FTP (UNIX and Window) clients now support SSH?  Seems to
>be a distinct lack of this that is visibly out there?  Not surprising users
>might use "insecure" FTP if that is the only useable FTP client they have?

The problem is not in the ftp clients, they can all tunnel the command
channel, and transfer the data unencrypted in PASV mode. Encrypted
random-port data channel does not fit to the port forwarding model very well.

The problem is in the SSH tunneling concept which applies only
to a short user definable list of ports in one hop. Tunnels and port
numbers are too difficult for normal users. There should be a
SSH wizard which would jump in when a user tries to use a nonforwarded
port. And it should be active in every box.

VesA

 
 
 

telnet security

Post by unsCAre » Sat, 05 Dec 1998 04:00:00



  []
  >Final note:  Even while in ssh, beware of other services you open over
  >the Net.  It's all too easy to feel cosy in your SSH session and then
  >lapse and start an insecure FTP session between the same two hosts,
  >because you need to move some files. :-)
        Ssh 2.X adds suport for _sftp_, a ssh ftp client using encription, and
you can also use _scp_ with 1.2.X versions of ssh. Ftp servers must run only
if you need an anonymous ftp server.
  >.. It's not what, but how.
  >--
  >|Fidonet:  Tony Langdon 3:635/728.18

  >|
  >| Standard disclaimer: The views of this user are strictly his own.

--
Un Saludo:
-------------------------------------------------------------------------------
E-mail: alvarovp!mad.servicom.es      + PGP id:7B87DC61 (at public servers)
        alvarovp!diskobolo.mat.ucm.es + unsCAred at #linux [irc-hispano]

 
 
 

1. Telnet Security

I want to disable certain users from telneting into a
RedHat Linux 5.1 machine altogether, is this possible?
Actually disabling certain users from using ftp, rsh,
rlogin, and anything else would be cool too.

--
Bryan Stevenson
BMH Associates, Inc.

2. KDE remote X connection problems.

3. telnet security

4. StarOffice 4.0 installation

5. Telnet security

6. bus error again ........

7. Telnet security...

8. One last Samba question (smb.conf also posted, so it's rather long)

9. Telnet security

10. telnet security

11. Telnet security

12. telnet security