1、Telnet面臨的主要安全問題

1. 使用者認證
2. 數據傳送保密
3. 防范針對telnet的攻擊

Telnet本身沒有很好的保護機制，所以要借助其他外部的保護。

Telnet本身的缺陷是：

• 沒有口令保護，遠程用戶的登陸傳送的帳號和密碼都是明文，使用普通的sniffer都可以被截獲
• 沒有強力認證過程。只是驗證連接者的帳戶和密碼。
• 沒有完整性檢查。傳送的數據沒有辦法知道是否完整的，而不是被篡改過的數據。
• 傳送的數據都沒有加密。

SSH是一個很好的telnet安全保護系統，但是假如是要更嚴格的保護，你必須使用其他的telnet安全產品。SSH在前面的介紹中都已經具體地介紹過了，這里主要是介紹安全原理和安全產品。

1.1 使用者認證

對使用者的認證有以下幾種方式：

有關認證的相關的內容請參閱相關的RFC文檔。

相關的RFC文檔和連接是：

RFC1409 http://andrew2.andrew.cmu.edu/rfc/rfc1409.Html

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

Kerberos Version4認證的RFC文檔

RFC1416 http:// www.faqs.org/rfcs/rfc1416.html，這是一個關于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 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的有關站點發現。地址是http://srp.stanford.edu/srp，在這里你可以得到有關協議的在線說明http://srp.standford.edu/srp/design.html或者是一個出版的關于SRP的技術白皮書http://srp.standford.edu/srp/ftp。

Standford Telnet軟件套件是標準的Telnet協議的擴展的實施。標準的Telnet協議是在RFC845中定義的(http://srp.stanford.edu/srp/rfc845.txt)。假如你要更多的信息，請到http://www.ietf.org得到更多的RFC信息。

SRP的Telnet包Telnet認證過程是在RFC1416（http://srp.standford.edu/srp/rfc1416.text）的一個框架下實現的。但是SRP也有它自己的可選擇的號。假如你想知道具體的號的分配，你可以到http://srp.stanford.edu/srp/ftp 得到。當一個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（http://srp.stanford.edu/srp/rfc2144.txt）中有定義。標準的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

獲得軟件的地方是：http://srp.standford.edu/srp/class/download.html#srp 下載包括源代碼部分。

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產品后，他以前使用的軟件不至于不能在使用。完全透明而且又可以避免網絡上的一般攻擊是很困難的。

SRP是一個理想的安全Telnet協議。用戶可以基于本身的口令加密認證，而不必維護所謂的密鑰治理系統。用戶使用自己本身口令加密保護的機制，同樣可以取得和使用公鑰系統一樣安全的效果。這個軟件同樣沒有程序或者選項治理私鑰。

小結

本文主要是講述Telnet的基本安全。包括常見的Telnet安全系統工具。建議使用這些工具加強你的Telnet服務，至少可以使網絡監聽不是很輕易就辦到的。