telnet的应用

最新推荐文章于 2025-05-09 16:27:01 发布

George_Fal

最新推荐文章于 2025-05-09 16:27:01 发布

阅读量464

点赞数

CC 4.0 BY-SA版权

文章标签：运维网络操作系统

原文链接：http://blog.51cto.com/295520/54159

1 、 Telnet 面临的主要 安全问题 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

1. 使用者认证

2. 数据传送保密

3. 防范针对 telnet 的***

Telnet 本身没有很好的保护机制，所以要借助其他外部的保护。

Telnet 本身的缺陷是：

没有口令保护，远程用户的登陆传送的帐号和密码都是明文，使用普通的sniffer都可以被截获
没有强力认证过程。只是验证连接者的帐户和密码。
没有完整性检查。传送的数据没有办法知道是否完整的，而不是被篡改过的数据。
传送的数据都没有加密。

SSH 是一个很好的 telnet安全保护系统，但是如果是要更严格的保护，你必须使用其他的 telnet安全产品。 SSH 在前面的介绍中都已经详细地介绍过了，这里主要是介绍安全原理和安全产品。

1.1 使用者认证

对使用者的认证有以下几种方式：

NULL	不使用认证
KERBEROS_V4	使用 Kerberos_v4
KERBEROS_V5	使用 Kerberos_v5
SPX	使用 SPX
RSA	使用 RSA 公钥私钥认证
LOKI	使用 LOKl

有关认证的相关的内容请参阅相关的 RFC 文档。

RFC1411 [url]http://andrew2.andrew.cmu.edu/rfc/rfc1411.html[/url]

Kerberos Version4 认证的 RFC 文档

RFC1416 http:// [url]www.faqs.org/rfcs/rfc1416.html[/url] ，这是一个关于 telnet 认证选项的 RFC 文档。

对使用者的认证，和本身网络的安全级别有关系。不同的安全级别使用不同的认证方法。具体使用的认证协议不是本书讨论的范围。

1.2 数据传送保密

使数据在 Telnet 会话中安全传送的方法有：

· 使用 DES 、 TripleDES 、 IDEA 的随机密钥加密会话

· 使用 Diffie-Hellman 进行密钥交换。

· 使用公钥私钥加密签名。

1.3 防范针对 telnet 的***

与其说对 Telnet 的***，不如说是利用 Telnet ***。 Telnet 是一个很好的工具。早期的***主要是针对环境变量的使用***。例如在支持 RFC1048 或者是 RFC1572 的系统中，如果用户登陆的服务器的 Telnetd 支持共享对象库的话，就可以传递环境变量，这个环境变量是影响 telnet 守护进程的调用和登陆。使用环境变量的初衷是测试使用的二进制库的，例如你可以改变路径，而不必改变原来的库的位置。但是如果是***者把自己定义的库加入其中，然后改变环境变量，根据自己的库的位置设置环境变量中有关路径的参数，可以取得 root 的权限。幸运的是，现在的安全专家已经意识到了这个问题，例如使用忽略环境变量的 setuid 等程序。

用户可以利用 Telnet 获得很多的关于服务主机的情况。例如服务器的操作系统的种类等。而且， Telnet 不仅仅可以使用端寇 23 ，而且也可以连接到其他服务的端口。例如端口 21 是 FTP ，端口 25 是 SMTP ，端口 80 是 HTTP 等。

例如一个登陆到自己的端口 25 的例子：

$telnet localhost 25
Tring 127.0.0.1 …
Connected to localhost,localdomain.
Escape character is ‘^]’
220 localhost.localdomain ESMTP Sendmail <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />8.9.3/8.9.3;Tue 19 oct 1999 10:31:540
EHLO localhost
250-localhost.localdomain Hello
IDENT:host@localhost.localdomain[127.0.0.1]u
250-EXPN
250-VERB
250-8BITNIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
MAIL FROM:host@localhost
250 host@localhost…send ok
RCPT TO:root@localhost
250 root@localhost… recipient ok
DATA
354 Enter mail,end with “.” On a line by itself
the content of the mail…..
250 KAA00615 Message accepted for delivery
QUIT
221 localhost.localdomian closing connection
Connection closed by foreing host.

我们可以看到，只要是端口是开放的，就可能发生使用 Telnet 获取信息的情况。甚至你可以利用 Telnet 向端口 80 发送请求，只要请求是正确的，端口 80 就可以得到回应，甚至是一条错误的 GET 指令都可以得到回应。

早期的对 Telnet 的***还有内核转储法。这个方法会显示已经屏蔽的口令。应该注意的是，在服务器端应该设置登陆次数和登陆延时限制，防止用户企图使用强力***破译口令。

2 、常用的 安全Telnet 软件

2.1 Stanford University 的 SRP

SRP 软件包是用在 FTP/Telnet 的安全软件。保证口令可以安全地在网络上面传送。基本的思想是，防止有被动或主动网络***者使用字典***。对口令数据采取加密保护，即使***者得到了口令数据库，也不能直接使用。

现在的 Sweet Hall clusrter ，使用 Kerberos 认证协议，可以被 “Macleland” 和 “PCLeland” 两个软件包访问，也可以建立起加密的登陆会话。 Standford 大学计算机系开发了 SRP 软件包，提供基于口令认证和会话加密的安全机制，而不需要用户或者是网管参与密钥的管理或分发。 SRP 为每一个人提供透明的密码安全，而没有其他昂贵的起始开销，比如阻止其他安全套件软件的使用等。不像其他的安全软件， SRP 套件是一个完全的实现密码认证的软件包，不是临时的解决方案。和标准的 /etc/shadow-style 安全比较， SRP 在每一个方面都是比较好的。

使用 SRP 对用户和管理者都有以下的好处：

SRP抵制“password sniffing”（口令监听）***。在一个使用SRP认证的会话中，监听者不会监视到任何在网络中传送的口令。在远程登陆软件中，明文的密码传送是最大的安全漏洞。任何人可以用一个简单的sniffer工具得到你登陆到远程系统的密钥。
SRP抵制字典***。一个系统保护简单的密码监听是不够的。如果***者使用强力***，例如字典***等，他们不是简单的直接监听密码，而是跟踪整个的会话过程，然后把整个的信息和字典中的普通密码对照。甚至有的Kerberos系统对这样的***也是脆弱的。SRP在抵制字典***的前，就进行口令的安全处理了。使用的算法就是在***者进行强力***前就要求***者必须执行一次不可能的的大的计算。SRP甚至保护针对口令的“active”***。因此，即使***者有能力和网络接触，也不能攻破SRP。所以即使是用户使用的是很脆弱的口令，也不会让***者很容易地破解的。
SRP对于终端用户是完全透明的。因为没有所谓的“密钥链”(keyrings)以及“证书”(certificates)，或者“票据”（ticket）。你的口令就是密钥。SRP简单地保护这个密钥，但要比老的、弱的密钥保护机制要好。
SRP从管理者的角度来说也是容易实施的。没有所谓的“密钥服务器”、“证书认证”，以及“认证服务器”等这样的概念。SRP口令文件在标准的Unix口令文件的旁边，软件本身协同这两个系统口令和SRP口令文件的一致性，没有多余的维护系统的机制。
SRP在认证一个用户的时候交换一个加密的密钥。这就意味着一个登陆会话是可以被加密，而抵制所谓的网络监听和恶意地篡改。用户在远程阅读他们的信笺，是使用128-bit加密后的信息，这是当用户登陆后自动处理的，而用户本身不必关心到底需要不需要加密。系统完成加密，然后送到用户的这里。

2.1.1 SRP 是如何工作的呢？

详细的 SRP 工作原理可以在 SRP 的有关站点发现。地址是 [url]http://srp.stanford.edu/srp[/url] ，在这里你可以得到有关协议的在线说明 [url]http://srp.standford.edu/srp/design.html[/url] 或者是一个出版的关于 SRP 的技术白皮书 [url]http://srp.standford.edu/srp/ftp[/url] 。

Standford Telnet 软件套件是标准的 Telnet协议的扩展的实施。标准的 Telnet协议是在 RFC845 中定义的 ([url]http://srp.stanford.edu/srp/rfc845.txt[/url]) 。如果你要更多的信息，请到 [url]http://www.ietf.org[/url] 得到更多的 RFC 信息。

SRP 的 Telnet 包 Telnet 认证过程是在 RFC1416 （ [url]http://srp.standford.edu/srp/rfc1416.text[/url] ）的一个框架下实现的。但是 SRP 也有它自己的可选择的号。如果你想知道具体的号的分配，你可以到 [url]http://srp.stanford.edu/srp/ftp[/url] 得到。当一个 Telnet 会话开始的时候，这个认证的框架自动执行包括 SRP 的一个认证机制协商。如果会话两边都发现他们支持 SRP ，例如，如果有一方不支持 SRP ，那么，认证将使用比较弱的那一方使用认证方法。或者如果根本就没有认证协议使用，就使用标准的明文认证。

和一般的安全Telnet 软件不同的是， SRP 不需要用户记忆更多的在线命令，例如在 SSH 中使用的各种复杂命令，而是完全和标准的 Telnet 兼容，用户只是简单地一样输入他的命令和密码就可以了。因为 SRP 和标准的 Telnet 的完全兼容性，所以它可以取代已经存在的系统二进制文件。

一个安全的 Telnet 会话可以像下面所描述的一样：

$ telnet xenon.stanford.edu
Trying 171.64.64.24...
Connected to xenon.stanford.edu.
Escape character is '^]'.

[ Trying SRP ... ]
* Unauthorized access to this computer system is prohibited. *
*Violators are subject to criminal and civil penalties. *

[ Using 1024-bit modulus for 'tjw' ]
SRP Password: (Password is typed locally)
[ SRP authentication successful ]
[ Output is now encrypted with type CAST128_CFB64 ](Encryption enabled)
[ Input is now decrypted with type CAST128_CFB64 ]
Sun Microsystems Inc.SunOS 5.5.1 Generic May 1996
xenon$ (User now has a secure session)

SRP 缺省使用的 128-bit 的 CAST 加密算法。 CAST-128 在 RFC2144 （ [url]http://srp.stanford.edu/srp/rfc2144.txt[/url] ）中有定义。标准的 SRP 也支持 56-bit 的 DES 以及 48 位的 DES 。高级的支持 Triple-DES 加密手段。

SRP 支持的平台有：

Solaris 2.x/SPARC
Solaris 2.x/i386
SunOS 4.x/SPARC
SGI IRIX 5.2, 5.3, 6.x/MIPS
DEC OSF/1 2.x, 3.x/Alpha
DEC Ultrix 4.x
HP-UX 9.x, 10.x
Linux 1.x, 2.x/i386

获得软件的地方是： [url]http://srp.standford.edu/srp/class/download.html#srp[/url] 下载包括源代码部分。

2.2 SRA Telnet

这是一个 Texas A&M University 开发的软件。使用的认证标准也是 RFC1416 。尽管它可以像 SRP 那样透明的实现功能，但是它仍然有很多的缺点。

SRA 的安全是在没有认证的使用一个固定的、短小的模块（ 192 比特）的 Diffie-Hellman 密钥交换算法。这就意味着认证会被使用 man-in-the-middle ***方法攻破，或者是使用计算离散的 computing discrete logs against the 192-bit modulus, 而这在个人计算机上面只是需要几个小时就可以破解的。它本身也没有加密会话，所以它仍然是 TCP 会话***是有缺陷的。实际上 RSA 只是一个临时的解决 Telnet安全的软件。

但是在所有的提供的 Telnet安全软件中， SRA 是最容易实现的。它需要用户的行为和系统改变最小。不幸的是，这种透明性也减少了系统本身的安全程度。

2.3 Stel

这个软件是意大利的 Milan 大学开发的。 Stel 是一个完全的为远程登陆提供的协议。它提供安全的认证和会话加密机制。像 SRA Telnet 一样， Stel 可以对付来自网络的密码监听。

不幸的是 Stel 仍旧是有很大的安全弱点。 Stel 也是使用 Diffie-Hellman 密钥交换方式建立一个安全会话。尽管 Stel 允许一个比 RSA 长的模块 modulus ，但是，它依旧受限于本身协议。例如，它依旧是对 man-ih-the-middle ***表现得束手无策。 Stel 试图使用一个提前分发的秘密文件来减缓这个问题，但是这只是把问题改变成了一个 deployment issue.

Stel协议完全和标准的 Telnet协议不兼容，要求用户要记忆新的命令和新的命令行选项。为了抵抗 man-in-the-middle ***， Stel 是使用了一个内琐协议(interlock) ，就是要求用户在他自己的主目录下面有一个秘密文件那个秘密文件在开始在连接的主机间是共享的。当然 Stel 根本就不为用户提供任何分发这个文件的安全途径。既然没有安全的保护机制，就需要一个安全的通道实现文件的传送。有的人使用 Catch-22 作为文件传送的安全通道（？？？？）

但是也有人使用软盘直接拷贝文件，但是这就是说物理上的安全问题又成为了令一个要考虑的问题了。

另一个重要的问题是 Stel 自己本身并不认证。实际上它只是在一个假定的安全连接上传送密码和数据块。当使用一个标准的 Unix 认证，也许最常用的是 scenario ，会有被使用服务器端口令捕获***（ server-side password capturing attacks ）。那么， Stel 的 Telnet安全解决方案只是一个临时的方案，不是长久使用的。

2.4 SSH

SSH 是一个提供安全登陆和远程命令执行的软件包。是为替代 rlogin/rsh 而设计的。 SSH 和 RSA 一样是基于本身主机密码加密的一个安全连接。 SSH 被认为是比较安全的，但是其安装和使用的问题，限制了它的广泛使用。真正 SSH 面临的安去问题是它还是直接把口令在一个安全连接中传送。因为人们喜欢在主机之间共享密钥，如果一个***攻破了一台主机，然后在这台主机上面安装 Trojan ***，那么他可以很容易捕获从其他主机传送过来的密码，然后试着破解其他主机的密码了。

SSH 是被认为是比较安全的系统。但是也存在一个安装和使用的问题，导致它不能被广泛地使用。真正的 SSH 的要面临的问题是，它仍旧是把密码从一个安全的连接直接传递到另一台主机上。因为有很多的人喜欢共享密码，也就是很多的地方使用同一个密码，如果有一台 SSH 服务器被攻破了，***者可以在服务器上面安装特洛伊***程序，然后跟踪所有的连接，得到所有用户的密码，就可以试着破解另其他的连接到 SSH 服务器上的主机了。 SSH 为了缓解这个问题，使用公钥密钥对，但是又有另一个问题产生，就是用户使用不方便。密钥必须从一个地方挪到另一个地方，而且密钥的管理也成为一个问题。

为了避免所谓的公钥监听，要求每一个用户在自己的主目录下面都有所有要连接的主机的公钥的拷贝。但是每一个公钥都要占用大约 1k 的空间。如果用户企图连接很多的主机，那么所有的这些主机的公钥也要占用一部分空间，同时给管理带来不便。

尽管 SSH 通过在美国外面开发避免出口限制，但是它使用的是 RSA 技术， RSA 技术的使用是受到美国政府的限制的。一个美国的公司想要开发基于 SSH 的产品，必须面对两个问题：一个是出口限制阻止它发布 SSH 相关的代码； RSA 需要一个 BSAFE 许可证。因此，出口的限制将主要是在 SSH 中使用的加密的密钥的长度上面的限制。 SSH 是依靠加密手段来保护明文的，对于 SRP 就可以进行安全的认证，而不必使用特殊的加密机制。

2.5 SPX,SSLtelnet,Kerberos

SPX 、 SSLtelnet 、 Kerberos 等产品提供了不同级别的安全保护，但是有一个共同的地方就是需要外部的证书或者是某种密钥分发设施。这就使得它们的应用范围受到了很大的限制。

2.6 S/key,IOIE 一次性口令系统

一次性口令系统（ OPT ）。一次性口令系统可以使用很方便，原因是客户端不需要被修改。然而，它固有的安全缺陷却掩盖了它的优点。

OPT 系统不使用任何形式的会话加密，因此是没有保密性的。所以这会在第一次会话中成为一个问题，如果他想要阅读他的在远程系统的邮件或者日志。而且，有感 TCP 会话的***，对这样的会话也构成威胁。所有的一次性口令系统都面临一个问题，就是密钥的复用。有时候，使用密钥的用户会重复使用以前使用的密钥。同样会给***者提供***的机会。

还有，去维护一个很大的一次性密钥列表也很麻烦，有的系统甚至让用户把所有使用的一次性密钥列在纸上。这样很明显是让人很讨厌的事情。有的是提供硬件支持，就是使用产生密钥的硬件，提供一次性密钥。但是这样所有的用户都必须安装这样的硬件。

最后，用户必须维护一个口令列表。这个列表是当前的 OPTs 选择的口令用完的时候使用。当系统是自动认证的时候，这个问题尤为严重。即使是一个长的 OPTs ，有的时候也会很快就耗尽。所以 OPTs 在一个有很多用户的大型的系统中是不适用用的，有的时候会导致一次性密钥管理混乱，尤其是对于管理者，要维护每一个用户的一次性密钥列表，势必提高系统的维护费用。

2.7 Deslogin

Deslogin 是一个使用 DES 加密算法实现密钥认证和会话加密的远程登陆系统。它尽管比使用明文密码认证要安全的多，但是仍然存在两个主要的缺点。因为口令文件不像 /etc/passwd 和 /etc/shadow ，包括用户的明文口令。因此这个口令文件必须被小心保护，避免整个系统被攻破。而且， Deslogin 对强力字典***也暴露出了缺陷。 Delogin 的会话加密，阻止了电子窃听。尽管 Deslogin 和标准的 Telnet 是完全兼容的，但是，用户必须记住各种命，令访问被 Deslogin 保护的系统，这个命令和其他主机使用的口令都是不同的。

虽然，所有的早期试图创造一个安全远程登陆系统比起明文口令认证安全度提高很多，但是它们中很多引入了其他的安全缺陷。例如和以前的标准的 Telnet 不兼容或者明文口令短缺等问题，有的给用户带来了很多的不便，增加了系统维护费用，例如使用证书系统等。最困难的是，用户使用了安全Telnet 产品后，他以前使用的软件不至于不能在使用。完全透明而且又可以避免网络上的一般***是很困难的。