觀點

SSHv2通用的加密通訊協定讓網路固若金湯

2005 / 11 / 03
文 / Eric Cole 翻譯 / 李慶發
SSHv2通用的加密通訊協定讓網路固若金湯

SSH是一套強大的程式組,它可以讓你在資料傳遞時發揮加密的強大力量。但部份安全管理人員一聽到加密就開始害怕了起來,原因無它,因為加密具有高難度、高成本等特質。但加強版的SSHv2,則是完全翻修後的版本,通常是免費附在Linux裡頭。對於技術高超的從業人員而言,這項工具可提供隱密性、完整性、可驗證性,以及不可否認性。
開發SSH的原因有二:一是作為Telnet的替代品,其二則是用做其他通訊協定的安全通道。這項基本功能可為你最脆弱的網路提供安全的保障。雖然SSHv1已被廣泛地使用了,但SSHv2還是較之前的通訊協定提供更多的安全與功能(請參照「SSHv1 vs. SSHv2」)。
像Telnet以及FTP這類的應用程式,曾經是完善的遠端存取與檔案傳輸工具,但卻是安全管理的惡夢。所有的驗證資訊,包括使用者ID與密碼,都是以純文字來傳送,而行動工作者若是在旅館、機場以及咖啡廳等公眾網路上連線的話,等於是邀請大家都來偷他的ID了。透過Telnet進行管理或是利用FTP傳輸檔案,都有可能惹禍上身。SSHv2工具組的主程式——ssh,可以將敏感性的資料加密,是Telnet的安全替代品。SSH通訊協定組還包括了像scp之類的工具,它可以進行遠端複製以及SFTP,同時也是FTP的安全替代品。
SSHv2相對上較易於學習,大多數具有網路基礎認識的人,都能夠快速地了解它的精神與潛力。我們將舉些例子讓你了解如何利用SSHv2來保護你的網路,你會對它強大的功能感到驚豔。

安全通道
SSHv2不但包含了一些工具來取代較不安全的Telnet或FTP,它還可以用來保全其他的應用程式與通訊協定,如POP3以及SMTP等。這些e-mail程式也是利用純文字來傳送敏感性的資訊,但它們卻沒有安全的替代品。雖然POP3有個較安全的版本可用,但大多數e-mail伺服器及用戶端都無法支援。
SSHv2的作法是:將POP3等不安全的通訊協定,導向到安全的SSH通道中。當然,若是能利用安全POP3或SMTP內建的功能來進行保全的話,效果會更好,因為它們可確實提供你所需的功能,但這種作法在每次使用時都需要高度的專業知識來設定。雖然SSHv2提供的方法較為一般化,但卻能對更多的服務提供更多樣的解決方案。
它的運作方式如下:將SSHv2伺服器設定為能夠接受SSH預設通訊埠22的連線;並關閉其他所有的通訊埠。然後,將伺服器設定成用戶端能透過通訊埠22來存取其他的網路服務。之後將用戶端設定成以通訊埠22連上網路,並將所有允許的服務全納入SSHv2的通道中。

SSH VPN
VPN在安全的遠端存取以及點對點的連線上極為常見。但它需要額外的設定以及特殊的用戶軟體。當你需要暫時、通用的VPN時,SSHv2不失為一個可行的方案。
例如,如果有人需要在他的筆記型電腦與公司伺服器之間,傳送幾個大型的機密文件的話,便可將所有離開電腦或網路的封包,全部送到SSH通道。將所有封包全部導向通道而非使用單一通訊協定,可以讓SSH做出與IPSec或SSL VPN相同的效果。由於這只是暫時的用法,因此也沒有傳統VPN煩瑣的管理問題。

減少漏洞
漏洞的存在是難以改變的現實。具有漏洞的應用程式(例如自行開發出具有安全缺陷的交易程式)有時會暴露好幾天,甚至好幾個星期,而不被發現。理論上,你可以將這些應用程式重導到SSHv2的通道中,但如果應用程式用到一般常用的通訊埠時則可能無法適用,例如使用通訊埠80的Web伺服器便是一例。
許多服務規模有限,且可以在任何通訊埠上執行,但這並不表示它們的漏洞較少。例如,有個組織在通訊埠21上執行FTP,且只讓少數使用者使用,這時駭客只要掃描系統,便可發現開啟的通訊埠並進行攻擊。像這種情況,你可以將應用程式放置在SSHv2的通道中,有了這層保護,你便不需擔心未知的缺陷,或是重新撰寫程式修正你發現的漏洞了。
真實世界的情境可能如下:有間公司設定了一個Web伺服器,以便讓業務人員可以存取所有客戶的資料庫。但是很快地便發現,伺服器本身存在許多外部的缺陷以及暫存器滿溢(buffer overflow)攻擊的漏洞。於是該公司便架設了SSHv2通道,以便保護應用程式並提供強力的驗證。這技巧很常見,因此許多商用軟體都會利用SSHv2的功能,尤其是系統管理者(sysadmins)所採用的遠端主控台。

強力驗證
對於許多Internet應用程式而言,驗證是第一道,也是唯一的一道防線,但是許多的服務與通訊協定仍採用脆弱的密碼驗證。若要再加上強力的驗證,不但煩瑣,而且還得對每一個應用程式或通訊協定個別處理。而過程也充滿了風險性。舉例來說,當初開發人員在常用的IMAP電子郵件通訊協定上加上強力驗證的功能時,就產生了幾個暫存器滿溢的新缺陷。
更可靠且更具彈性的作法,是將應用程式納入SSHv2通道中,並使用SSHv2的安全驗證,SSHv2提供了多種驗證方式,從密碼驗證到智慧卡都有。這種方式在同時執行多種Internet應用程式的環境中特別有用。智慧卡或許是個理想方案,但它需要大量的時間與精神來為每一個應用程式進行設定。而SSHv2就已支援了智慧卡,因此在上頭執行應用程式會更為簡便、快速,且更省成本。另外,雖然不是直接支援,但SSHv2還可以採用RADIUS、TACACS+等集中式的使用者憑證(credential)資料庫。

更為牢靠的防火牆
許多公司都運行了各式各樣的服務與應用程式,它們在防火牆上都需要開啟額外的通訊埠。最後,鋼筋水泥的防火牆就會像瑞士起司一樣,到處都是孔洞。比較好的作法是,將SSHv2『標示』為可信認的封包,將防火牆設為預設全部阻擋,只開放常用的通訊埠(如80與25)以及SSH的封包。這種方法可提供強力驗證,並確保規則簡單化。有採用IPSec的組織也可利用相同的方法,將AH標頭設為可信認的封包。SSHv2較適用於無需加密的內部網路中。
現在你已經有些概念了。這裡提到的解決方案,有些很不常見,但它們可展現出SSHv2的威力。只要有些基本的認識與創意的發揮,你也可以為你的企業找到獨特的保全方法。

ERIC COLE,CISSP,GIAC,是Sytex Group的首席科學家。他是Hackers Beware一書的作者,Network Security Bible的共同作者,同時也是SANS Institute的講師以及The Honeynet Project的成員之一。若你對於本文有任何想法,請寄到iseditor@asmag.com

Comparison SSHv1 vs. SSHv2
SSHv2將SSH通訊協定完全翻新;兩者並不相容。雖然SSHv1仍被廣泛地使用,但SSHv2提供了更多的優點。
通訊協定:SSHv1
缺陷:有一些缺陷能夠讓攻擊者取得完全的權限。
驗證方式:可以使用Kerberos、公開金鑰(RSA)RHosts、RHostsRSA密碼,或是TIS,但是缺乏多重驗證(multifactor authentication)的支援。
主機驗證:綁在主機名稱或IP位址上。
完整性:使用較弱的CRC-32。
加密支援:DES、TripleDE﹑IDEA、Blowfish。
取代程式:用來取代telnet、rlogin、rsh,以及rcp等。

通訊協定:SSHv2
缺陷:去除了已知的缺陷。需要完全權限才能執行的碼變得更少了。
驗證方式 :可以使用公開金鑰(RSA、DSA、Diffie-Hellman、OpenPGP)、RHostsRSA以及密碼;支援多重驗證。
主機驗證 :並無限制,支援常換位址或多重位址的行動用戶端。
完整性 :採用較嚴謹的SHA-1 MAC(Message Authentication Code)。
加密支援 :TripeDES、Blowfish、Twofish、Arcfour、AES。
取代程式:取代與SSHv1相同的通訊協定,以及FTP。