基于SSH的網絡安全解決方案
出處:mohanwei 發(fā)布于:2008-08-29 16:48:39
?。桑睿簦澹颍睿澹羰钱斀駨V泛使用的計算機網絡,TCP/IP協議則是Internet采用的網絡通信協議。由于TCP/IP協議本身缺乏可靠的安全機制以及Internet的開放性,其安全性就顯得更加脆弱。目前有多種網絡安全的解決方案,分別實現在TCP/IP協議棧的不同層次上:在物理層上使用機械或電器方法防止信息被非法竊取,如電磁泄漏保護;在數據鏈路層上使用硬件加密設備直接加/解密鏈路兩端的數據或采用用于組建遠程訪問VPN的安全協議PPTP和L2TP創(chuàng)建安全通道;在網絡層上通過基于IPSec規(guī)范的安全協議實現各種方式的VPN;在傳輸層使用SSL,TLS等安全協議提供端對端的安全通訊;在應用層則可以實現對某些特殊服務進行單獨保護,如S-HTTP等。在眾多的網絡安全解決方案中,當然可以采用VPN和防火墻來保護自己的信息安全。然而,除了這些措施以外,很多公司實際上遺漏了一種不起眼但卻很健壯有效的解決方案---(SSH(Secure?。樱瑁澹欤欤?。
1?。樱樱葏f議
?。保薄。樱樱葏f議介紹
?。樱樱龋矗樱澹悖酰颍濉。樱瑁澹欤欤且环N介于傳輸層和應用層之間的加密隧道協議,具有C/S的體系結構。SSH可以在本地主機和遠程服務器之間設置“加密隧道”,并且這樣設置的“加密隧道”可以跟常見的FTP,SMTP,POP應用程序,X應用程序相結和。目的是要在非安全的網絡上提供安全的遠程登陸和相應的網絡安全服務。既然SSH是以提供安全服務為目標的協議,其中必不可少的是一套完備的密匙機制。由于SSH協議是面向互聯網中主機之間的互訪 與信息交換,所以主機密匙成為基本的密匙機制。即SSH要求每一個使用本協議的主機都必須至少有一個自己的主機密匙對,服務器方通過對客戶方主機密匙的之后,才允許其連接請求。一個主機可以使用多個密匙,針對不同的密匙算法而擁有不同的密匙。
SSH在運行方式上,不像其他TCP/IP應用,被設計為工作于自己的基礎之上,而不是利用包裝(Wrappers)或通過Internet守護進程inetd運行。
?。保病。樱樱葏f議工作機制
根據IETF關于SSH草案的定義,SSH協議包含3個組成部分(層次)。
?。ǎ保﹤鬏攲訁f議(SSH-TRANS)
?。樱樱鹊膫鬏攲訁f議負責進行服務器,數據加密和完整性保護,并可以提供數據壓縮的功能。SSH傳輸層協議是建立在提供“底層”可靠的TCP連接之上的,當然,也可以用在其他可靠的數據流協議中。傳輸層的是基于主機的(并非面向用戶的),目的就在于為真正的上層應用提供安全保證。當SSH用在TCP/IP協議上時,SSH服務器一端一般會監(jiān)聽TCP22端口,一旦客戶端和服務器端的TCP連接建立起來,SSH傳輸層協議就開始發(fā)揮作用了。在這個階段,客戶端和服務器要約定使用的SSH協議版本,要協商選定雙方都支持的算法、加密算法、哈希算法和數據壓縮算法。協商好算法和密匙交換方法后,服務器端會向客戶端發(fā)送自己的主機密匙(HostKey),即服務器的公匙(PublicKey),以驗證服務器的身份。雙方還要依據協商好的加密算法生成性加密密匙,用于對整個商變更加密密匙。此外,傳輸層協議需要生成一個會話ID(Session Identifier),用于惟一標識本次會話連接。等所有這些過程結束后,客戶端就可以向服務器發(fā)送服務請求了,服務器接受2類請求:用戶服務(SSH-USERAUTH)和連接服務(SSH-COMMECTION)。
?。樱樱戎С值墓姿惴ㄓ校模樱梁停遥樱粒С值膶ΨQ密匙算法包括DES,3DES,Blowfish,Twofish,IDEA,ARCFOUR和CAST-128,支持的哈希算法有SHA-1,MD5等,支持Diffie-Hellman密匙交換方法。
(2)用戶協議(SSH-UXERAUTH)
用戶協議是建立在傳輸層協議之上的,當用戶進行時,假定底層(傳輸層)協議已經提供了數據完整性和機密性保護。用戶協議接受傳輸層協議確定的會話ID,作為本次會話過程的惟一標識。服務器首先會發(fā)起用戶,他他會告訴客戶端服務器所支持的方式,客戶端可以從中選擇。一旦用戶成功,根據客戶端的請求,服務器將會啟動相應的服務(在連接協議建立的邏輯通道中進行數據傳輸)。SSH支持的用戶方法包括:公匙方法、口令方法、基于主機的和PAM等。
?。ǎ常┻B接協議(SSH-CONNECT)
連接協議可以提供交互的Shell會話,支持遠程命令執(zhí)行,提供TCP端口以及X11連接轉發(fā)功能。通過將惟一一個加密隧道(tunnel)多路復用成若干個邏輯通道,提供給更高層的應用協議使用。邏輯通道是由兩端的通道號來惟一標識的。要啟動某個應用服務,首先要建立一個新的邏輯通道,這期間,先要分配兩端的通道號,協商緩存窗口的大小,然后是建立正式的會話,啟動應用程序。各種高層應用協議可以相對獨立于SSH基本體系之外,并依靠這個基本框架,通過連接協議使用SSH的安全機制。
1.3 算法
以SSH協議2.0為例,其常用公匙算法RSA或DSA進行身份,用對稱密匙算法3DES進行傳輸數據加密, 用Diffie-Hellman密匙協議算法交換密匙,用散列函數SHA-1或MD5進行完整性檢測,用zlib進行數據壓縮。
2 具體應用及安全模型
具體應用時,SSH可以提供3類服務:
?。玻薄“踩h程登錄和安全遠程命令執(zhí)行:替代傳統(tǒng)的telnet和rlogin,rsh命令
網絡遭受攻擊,很多情況是由于服務器提供了Telnet服務引起的。對于UNIX系統(tǒng),如果要遠程管理他,必定要使用遠程終端,而要使用遠程終端,自然要在服務器上啟動Telnet服務。但是Telnet服務有一個致命的弱點他以明文的方式傳輸用戶名及口令,所以,很容易被第三者竊取口令。一種有效代替Telnet服務的工具就是SSH。用戶要登錄到遠程計算機用戶賬號中,可以使用命令:
?。#螅螅琛。酰螅澹颍睿幔恚澹溃颍澹恚铮簦澹悖铮恚穑酰簦澹?/FONT>
整個登錄會話在客戶端和服務器之間傳輸時都是經過加密的,從而實現了安全遠程登錄。
對系統(tǒng)管理員來說,如果要查看局域網中4臺計算機(A,B,C,D)上的每個用戶啟動的進程,按傳統(tǒng)方法,可以使用rsh:
?。#。猓椋睿螅?/FONT>
?。妫铮颉。恚幔悖瑁椋睿濉。椋睢。痢。隆。茫模洌?/FONT>
?。颍螅瑁ぃ恚幔悖瑁椋睿澹酰螅颍酰悖猓?/FONT>
?。洌铮睿?/FONT>
雖然這種方法可以達到目的,卻不安全。/usr/ucb/w的結果在網絡上是明文傳輸的??梢岳茫樱樱却妫遥樱?,實現安全遠程命令執(zhí)行。
2.2 安全文件傳輸:替代傳統(tǒng)的rcp,ftp命令
傳統(tǒng)的文件傳輸程序(ftp.rcp或E-mail)都不能提供一種安全的解決方案。當文件在網絡上傳輸時,第三方總可以將其截獲并讀取其中的數據包。要防止這種問題,可以采取很多措施,例如,在源計算機上使用PGP(PrettyGood?。校颍椋觯幔悖┲惖某绦驅ξ募M行加密,然后使用傳統(tǒng)的方法把文件傳輸到目的計算機,并在此處解密文件。然而,這個過程比較復雜,而且對用戶不是透明的。利用?。樱樱?,用戶只需使用一個拷貝命令scp就可以在兩臺計算機之間安全的傳輸文件:#scp?。睿幔恚澹铮妫螅铮酰颍悖濉。睿幔恚澹铮妫洌澹螅簦椋睿幔簦椋铮?,文件在離開源計算機時 加密,到達目的計算機時自動解密。雖然scp命令十分有效,但用戶可能更熟悉ftp的命令。sftp是在SSH之上的一個基于SFTP協議的獨立的文件傳輸工具:
?。#螅妫簦稹。酰螅澹颍睿幔恚澹溃颍澹恚铮簦澹悖铮恚穑酰簦澹颍螅妫簦穑?/FONT>
sftp>
在一個sftp會話中可以調用多個命令進行文件拷貝和處理,而scp每次調用時都要打開一個新會話。
其實,SSH并不執(zhí)行文件傳輸。在SSH協議中沒有任何傳輸文件的內容,SSH通信者不能請求對方通過SSH協議來發(fā)送或接收文件。scp,sftp程序并沒有真正實現SSH協議,也根本沒有融合什么安全特性。實際上,他們只是在一個子進程中調用SSH進行遠程登錄,然后傳輸文件,調用SSH關閉本次連接而已。
?。玻场∞D發(fā):包括對各種TCP應用的端口轉發(fā)以及X11連接轉發(fā)
?。樱樱瓤梢栽黾踊冢裕茫校桑械膽贸绦虻陌踩浴_@是通過一種稱為轉發(fā)(forwarding)或隧道(tunneling)的技術來實現的。該技術通過對TCP/IP連接進行重新路由,使其通過SSH連接傳輸,并且透明地進行端到端的加密(實際上,這已經算是基本的VPN功能了)。
?。玻常薄《丝谵D發(fā)(port?。妫铮颍鳎幔颍洌椋睿纾?/FONT>
?。樱樱仁褂玫膫鬏敊C制是TCP/IP,通常使用的都是服務器的TCP端口22,并對經過連接傳輸的數據進行加解密操作。用SSH對其他應用程序在別的TCP端口上建立的TCP/IP傳輸進行加密和解密,這一過程稱為端口轉發(fā)。端口轉發(fā)可以使telnet,pop3,smtp,nntp和imap等基于TCP/IP的不安全協議變得安全。
假設用戶要在家里的主機H上運行一個Email閱讀程序,訪問位于企業(yè)局域網內部的一臺IMAP服務器S。要使IMAP連接通過SSH隧道,就得在主機H上選擇一個本地端口(1 024~65?。担常担?,將其發(fā)送至遠程套接字(S,143)。假設隨機選取本地端口2003,則創(chuàng)建隧道的命令為:#sshL2003:localhost:143?。樱渲?,-L表明是本地轉發(fā),此時TCP客戶端與SSH客戶端同在本地主機上?,F在,Email閱讀程序連接本地套接字(localhost,2003)即可安全的閱讀IMAP服務器上的郵件。
遠程轉發(fā)與本地轉發(fā)幾乎完全相同,只是方向相反,此時TCP客戶端在遠程,服務器在本地,轉發(fā)連接由遠程主機發(fā)起(其創(chuàng)建隧道的命令為#ssh-R2003:localhost:143 H)。
一般意義上講,SSH端口轉發(fā)是TCP使用的一種通用代理機制,而且只能用于TCP/IP協議,如果協議不是基于TCP的,比如基于UDP的DNS,DHCP,NFS和NetBIOS或者非IP類協議,如AppleTalk或Novell的SPX/IPX,就不能使用端口轉發(fā)機制。
?。玻常病。剞D發(fā)
?。兀祝椋睿洌铮魇牵眨睿椋ぷ髡旧虾芰餍械拇翱谙到y(tǒng),其中一項重要功能就是他的透明性。用戶可以運行遠程X應用程序,并將其顯示在本地機器上。但是機器間的通訊不安全,他完全暴露在窺探器之下。利用SSH,可以將X協議連接導入SSH連接,以保障其安全性,并提供更強的,此項功能稱為X轉發(fā)。X轉發(fā)是端口轉發(fā)的一個特例,SSH對此提供特別支持。
以SSH2.0協議的實現為例,在客戶端配置文件中將關鍵字ForwardX11設置成yes或no來啟用或禁用X轉發(fā)。服務器范圍配置關鍵字X11Forwarding及其同義詞ForwardX11和AllowX11Forwarding可以在服務器端啟用/禁用X轉發(fā)。
在以上SSH所提供的3種服務的基礎上,可以建構基于SSH的網絡安全模型,如圖1所示。

企業(yè)實際部署時可將防火墻與SSH服務器實現于同一臺計算機,即企業(yè)局域網的網關主機中。SSH可采用的OpenSSH或商業(yè)產品F-Secure SSH,而防火墻則采用普通的軟件防火墻產品,例如東大阿爾派NetEye?。玻啊?/FONT>
?。场“踩苑治?/FONT>
?。樱樱冉鉀Q了許多和網絡有關的安全漏洞,有效地防止了網絡竊聽(Sniffer)、IP欺騙、DNS欺騙、連接劫持(Connection Hijacking)、插入攻擊(Compensation?。粒簦簦幔悖耄┖椭虚g人攻擊(man-in-the-middle)等,但并沒有解決全部問題,尤其是他仍然容易受到針對底層TCP/IP缺陷而發(fā)起的服務器拒絕攻擊(DoS);他也不能解決一些考慮環(huán)境因素而產生的攻擊方法,例如流量分析和隱秘通道;也不能防止出現病毒,Trojin木馬和咖啡豆(coffee?。螅穑椋欤欤?。對于TCP/IP的缺陷引起的問題,只能通過更低級的網絡層技術才能很好的解決,例如硬件鏈路加密或IPSec;對于流量分析攻擊,SSH可以在空閑時發(fā)送一些隨機的,非操作性的信息來干擾活動狀態(tài)的分析(目前的SSH產品還沒有實現這種特性);對于病毒等則需要病毒防火墻來解決。
?。础〗Y語
?。樱樱葏f議既可以提供主機,又提供用戶,同時還提供數據壓縮,數據機密性和完整性保護。SSH的不足之處在于他使用的是手工分發(fā)并預配置的公匙而非基于證書的密匙管理。與SSL和TLS相比,這是SSH的主要缺陷。但從SSH2.0協議開始允許一同使用PKI證書和密匙,將來在SSH產品中把這種特性和通用的PKI一起實現,這樣可以降低密匙管理的負擔并提供更強大的安全保障。雖然SSH還有其不足之處,但相對于VPN和防火墻的復雜性和費用來說,也不失為一種可行的網絡安全解決方案,尤其適合中小企業(yè)部署應用。
歡迎轉載,信息來自維庫電子市場網(m.58mhw.cn)
上一篇:一種新型網絡處理器ip2022
下一篇:無線局域網的實際應用
版權與免責聲明
凡本網注明“出處:維庫電子市場網”的所有作品,版權均屬于維庫電子市場網,轉載請必須注明維庫電子市場網,http://m.58mhw.cn,違反者本網將追究相關法律責任。
本網轉載并注明自其它出處的作品,目的在于傳遞更多信息,并不代表本網贊同其觀點或證實其內容的真實性,不承擔此類作品侵權行為的直接責任及連帶責任。其他媒體、網站或個人從本網轉載時,必須保留本網注明的作品出處,并自負版權等法律責任。
如涉及作品內容、版權等問題,請在作品發(fā)表之日起一周內與本網聯系,否則視為放棄相關權利。
- 工業(yè)5G技術在智能制造中的應用與實踐解析2025/12/31 10:57:21
- 工業(yè)以太網交換機選型與現場應用技術指南2025/12/18 10:48:14
- 無線傳輸電路基礎,射頻前端設計、天線匹配與鏈路預算計算2025/10/27 13:55:50
- ASK 解調的核心要點與實現方式2025/9/5 16:46:17
- 雙偶極子天線:結構、特性與應用全解析2025/9/3 10:29:21









