安全外殼傳輸模型SSHTM構(gòu)造及性能分析

黃曉巧 汪凱

許昌學(xué)院教育技術(shù)與信息部 河南 461000

0 前言

SNMP協(xié)議三個(gè)版本的安全特性：SNMPv1和SNMPv2都是基于團(tuán)體名的安全檢查措施，而團(tuán)體名在網(wǎng)絡(luò)中的傳輸是以明文形式出現(xiàn)的，其安全性根本無(wú)法保證；在SNMPv3中加入了基于用戶的安全措施USM模型，但因?yàn)镾NMPv3中的消息摘要算法HMAC-MD5原理已泄露，而且認(rèn)證是單向的，加密算法DES的密鑰長(zhǎng)度太短，僅有56位，對(duì)于目前的攻擊手段來(lái)說(shuō)，完全可以破解，因此其安全性也受到威脅。而網(wǎng)絡(luò)系統(tǒng)的安全管理又不能小視，所以有必要借助其他的安全協(xié)議來(lái)加強(qiáng)基于 SNMP網(wǎng)絡(luò)安全管理。利用 SSH協(xié)議安全性加強(qiáng)基于SNMP網(wǎng)絡(luò)安全管理就不失為一種好的解決辦法。

利用SSH協(xié)議的安全特性，即它的三個(gè)協(xié)議：傳輸層協(xié)議、認(rèn)證協(xié)議和連接層協(xié)議。傳輸層協(xié)議提供數(shù)據(jù)機(jī)密性、信息完整性等方面的保護(hù)；認(rèn)證協(xié)議提供基于公鑰的認(rèn)證；連接協(xié)議建立隧道，使信息在隧道內(nèi)進(jìn)行安全傳輸。在SSH的基礎(chǔ)上，構(gòu)造安全外殼傳輸模型(the Secure Shell Security Model, SSHTM)。

1 建立SSHTM模型的目的

SSHTM利用SSH的安全基礎(chǔ)設(shè)施，滿足網(wǎng)絡(luò)管理人員對(duì)網(wǎng)絡(luò)安全管理和操作需要，在可操作的環(huán)境中最大化其可用性來(lái)獲取高的成功配置，同時(shí)使執(zhí)行和配置的費(fèi)用最低，并且使配置的時(shí)間最少，保證網(wǎng)絡(luò)系統(tǒng)正常高效運(yùn)行。

SSH協(xié)議允許服務(wù)器與客戶端進(jìn)行雙向認(rèn)證，SNMP就可以利用已認(rèn)證的標(biāo)識(shí)符在授權(quán)策略范圍內(nèi)對(duì)數(shù)據(jù)進(jìn)行訪問(wèn)。SSHTM利用SSH協(xié)議的客戶端認(rèn)證和密鑰交換方法來(lái)支持不同的安全基礎(chǔ)設(shè)施，并提供不同的安全屬性。SSHTM使用的SSH用戶認(rèn)證方法包括：公鑰、口令、基于主機(jī)、鍵盤交互、使用MIC的GSSAPI、密鑰交換GSSAPI、GSSAPI、擴(kuò)展密鑰交換和不認(rèn)證等等方法，其中不認(rèn)證方法是不推薦使用的。通過(guò)使用公鑰，或者基于主機(jī)認(rèn)證，或者使用口令認(rèn)證方法來(lái)支持本地賬戶，口令方式允許綜合配置口令基礎(chǔ)設(shè)施，例如作為AAA服務(wù)器使用RADIUS協(xié)議。SSHTM還為將來(lái)用戶認(rèn)證方法留有余地，這也是充分發(fā)揮SSH協(xié)議的安全特性。

現(xiàn)在有許多 Internet安全協(xié)議和機(jī)制在廣泛地使用，它們中的大多數(shù)都試圖為不同的應(yīng)用層協(xié)議提供通用的基礎(chǔ)設(shè)施，而SSHTM建立就是起一個(gè)杠桿的作用。SSHTM是對(duì)SNMPv3安全管理、命令行接口(Command Line Interface，CLI)和其它管理接口的統(tǒng)一。

2 SSHTM模型的構(gòu)造

2.1 SNMP實(shí)體結(jié)構(gòu)擴(kuò)展

建立SSHTM模型不會(huì)對(duì)SSH和低層的協(xié)議有影響，它只是對(duì) RFC3411框架的一個(gè)擴(kuò)展，如圖 1所示，對(duì)現(xiàn)有的SNMP協(xié)議也無(wú)影響。這種擴(kuò)展允許通過(guò)SSHTM由擴(kuò)展協(xié)議SSH連接到SNMP引擎提供安全服務(wù)。

本文由河南省教育廳自然科學(xué)基金(2010B520027)項(xiàng)目資助。

圖1 擴(kuò)展的SNMP實(shí)體

在圖 1中，在原有的 SNMP實(shí)體的基礎(chǔ)上，在 SNMP引擎部分新增加了傳輸子系統(tǒng)，在安全子系統(tǒng)中新增加了TMSM安全傳輸模型。RFC3417中定義的傳輸映射不提供低層的安全功能，也不提供特定的傳輸安全參數(shù)，本文通過(guò)定義擴(kuò)展的SNMP實(shí)體框架修改了RFC3411和RFC3417，傳輸映射使用抽象服務(wù)接口(Abstract Service Interface, ASI)把特定傳輸安全參數(shù)傳遞給其它的子系統(tǒng)，包括特定的傳輸安全參數(shù)轉(zhuǎn)換成獨(dú)立于傳輸?shù)陌踩桶踩?jí)別。SSHTM 利用傳輸子系統(tǒng)。

2.2 SSHTM模型的構(gòu)造

安全外殼安全傳輸模型SSHTM由兩部分構(gòu)造而成：傳輸映射安全處理器(the Transport Mapping Security Processor，TMSP)和安全模型安全處理器(the Security Model Security Processor, SMSP)構(gòu)成(如圖 2 所示)。

圖2 SSHTM構(gòu)成

TMSP是傳輸調(diào)度器的一部分，它負(fù)責(zé)執(zhí)行實(shí)際的安全處理。

SMSP在安全處理子系統(tǒng)內(nèi)，它負(fù)責(zé)識(shí)別需要的合適的安全模型。它還必須與TMSP交互合作，才能提供需要的安全服務(wù)。

傳輸映射安全處理器TMSP是從一個(gè)SNMP引擎調(diào)度器的傳輸映射起作用的過(guò)程到執(zhí)行傳輸安全參數(shù)到/從獨(dú)立安全模型參數(shù)轉(zhuǎn)換的過(guò)程中被調(diào)用的。TMSP附加的安全功能執(zhí)行是由安全模型安全處理器SMSP來(lái)完成。

TMSP與SMSP之間必須進(jìn)行信息的交換，在TMSP和SMSP之間使用緩存，在緩存中傳遞信息，修改MIB模塊。這種方式是處理速度快，簡(jiǎn)單，也是最有效的方式。TMSP與 SMSP之間進(jìn)行信息傳遞的主要部分是傳輸映射狀態(tài)參考tmStateReference，與RFC3412中定義的securityStateReference相似。TMSP為SSHTM模型提供部分安全功能，而另一部安全功能由SMSP來(lái)完成，TMSP與SMSP之間要進(jìn)行協(xié)調(diào)。例如，TMSP提供加密、數(shù)據(jù)完整性、認(rèn)證以及授權(quán)策略的找回，或者是這些屬性的子集，這些都依賴于傳輸機(jī)制中可用的屬性。

3 SSHTM模型安全功能

3.1 SSHTM模型提供的安全保護(hù)

SSHTM針對(duì)RFC3411中定義的主要威脅和次要威脅，提供如下的安全保護(hù)：

（1）消息流修改：SSH確保每個(gè)接收到的消息在網(wǎng)絡(luò)中傳輸未被修改，由SSH加密隧道完成。

（2）信息修改：SSH確保每個(gè)接收到消息的內(nèi)容在網(wǎng)絡(luò)傳輸過(guò)程中未被修改，數(shù)據(jù)在沒(méi)有被授權(quán)的情況下遭到篡改或破壞，與不是故意修改的情況相比，數(shù)據(jù)序列號(hào)在很大程度上不會(huì)被改變。由SSH加密隧道完成。

（3）假冒：SSH提供SSH服務(wù)器身份的確認(rèn)以及SSH客戶端身份的確認(rèn)，確?？蛻舳税l(fā)出的信息是由自己產(chǎn)生的，而不會(huì)抵賴。SSH服務(wù)器身份確認(rèn)是通過(guò)SSH傳輸層協(xié)議服務(wù)器認(rèn)證來(lái)完成的。

（4）用戶身份的確認(rèn)對(duì)使用SNMP訪問(wèn)控制子系統(tǒng)來(lái)說(shuō)是很重要的，以確保只有授權(quán)的用戶才能訪問(wèn)敏感數(shù)據(jù)。SSH用戶身份被映射到一個(gè)SNMP模型獨(dú)立的安全名上。

（5）SSH服務(wù)器與客戶端相互認(rèn)證確保真實(shí)的SNMP引擎提供MIB數(shù)據(jù)，無(wú)論這個(gè)SNMP引擎是駐留在服務(wù)器端或是客戶端。操作者或管理應(yīng)用程序要對(duì)接收到的數(shù)據(jù)進(jìn)行處理(例如，對(duì)一個(gè)操作者升起一個(gè)警告，對(duì)發(fā)送Trap操作的設(shè)備進(jìn)行配置修改，修改網(wǎng)絡(luò)中其它設(shè)備的配置等等)，對(duì)MIB數(shù)據(jù)的提供者是經(jīng)過(guò)認(rèn)證的，這一點(diǎn)很重要。

（6）泄露：SSHTM模型提供對(duì)接收到SNMP消息的內(nèi)容不被泄露給未授權(quán)用戶的保護(hù)。

（7）重放：SSH確保SSH會(huì)話開(kāi)始創(chuàng)建的與SSH會(huì)話狀態(tài)中存儲(chǔ)的加密密鑰對(duì)于每一個(gè)會(huì)話都產(chǎn)生新的會(huì)話密鑰，密鑰不會(huì)重復(fù)，這是由SSH中Diffie-Hellman密鑰算法來(lái)實(shí)現(xiàn)的。這些密鑰是用來(lái)認(rèn)證和加密數(shù)據(jù)用的，以防止會(huì)話中遭遇重放攻擊。另外，在一次會(huì)話中，SSH使用序列號(hào)信息來(lái)阻止重放和消息重組攻擊。

除了以上的保護(hù)外，SSHTM 還提供數(shù)據(jù)完整性檢查，防止SNMP消息延遲和重定向。另外，SSH本身還能堤防中間人攻擊、IP連接劫持等，SSHTM模型同樣具有這樣的防范能力。

3.2 消息認(rèn)證安全

RFC3411體系結(jié)構(gòu)定義了SNMP可以識(shí)別的三種安全級(jí)別：不認(rèn)證不加密(noAuthNoPriv)、認(rèn)證但不加密(authNoPriv)和認(rèn)證且加密(authPriv)。SSH協(xié)議提供對(duì)加密和數(shù)據(jù)完整性的支持，而技術(shù)上可能支持不認(rèn)證不加密，但在SSHTM模型中不推薦使用。

SSHTM模型從SSH_MSG_USERAUTH_SUCCESS數(shù)據(jù)包中獲得已認(rèn)證的用戶身份，以及與SNMP引擎接收到消息相關(guān)聯(lián)的消息類型和傳輸?shù)刂?，它還將這些信息提供給SNMP引擎請(qǐng)求的消息。SSHTM模型充分信任低層的SSH連接已經(jīng)正確配置以支持authPriv特性。SSHTM傳輸模型對(duì)算法或者打開(kāi)SSH會(huì)話匹配不同安全級(jí)別選項(xiàng)不了解，為了信任間相互可操作，就假定在 SNMP引擎之間，一個(gè) SSH傳輸模型兼容執(zhí)行必須使用SSH連接提供認(rèn)證、數(shù)據(jù)完整性和加密服務(wù)，以此達(dá)到SNMP安全的最高級(jí)別authPriv。對(duì)于由SNMP應(yīng)用程序請(qǐng)求發(fā)送出去的消息，如果指定的安全級(jí)別是noAuthNoPriv或者是authNoPriv，則SSHTM傳輸模型就會(huì)以SNMP最高級(jí)別authPriv對(duì)待。

3.3 認(rèn)證協(xié)議安全

SSHTM傳輸模型支持任何的服務(wù)器或客戶端認(rèn)證機(jī)制，這種機(jī)制是由SSH支持提供的，包括認(rèn)證方法有：公鑰、口令、基于主機(jī)和鍵盤交互。

基于口令認(rèn)證機(jī)制為了完整性允許使用配置口令基礎(chǔ)設(shè)施，可以把一個(gè)口令交給一個(gè)提供認(rèn)證服務(wù)的服務(wù)器，如RADIUS，Diameter，以得到認(rèn)證，這種認(rèn)證也是使用用戶名和用戶口令屬性得到的。也可以使用不同的口令確認(rèn)協(xié)議，如CHAP或者消息摘要認(rèn)證，與RADIUS或Diameter結(jié)合提供身份認(rèn)證。不過(guò)，這些機(jī)制要求的口令都是明文進(jìn)行傳輸?shù)模浒踩缘貌坏奖ＷC。

通用安全服務(wù)(Generic Security Service, GSS)密鑰交換為附加客戶端認(rèn)證機(jī)制提供了一種框架，以支持不同的安全基礎(chǔ)設(shè)施，并提供不同的安全屬性，附加的認(rèn)證機(jī)制如支持X.509認(rèn)證證書(shū)，此項(xiàng)已添加到SSH2中。

4 SSHTM模型的性能

4.1 會(huì)話建立

表1給出了在不同的傳輸層協(xié)議 TCP和 UDP上執(zhí)行snmpget請(qǐng)求操作的結(jié)果。從該表中可以看出SSH會(huì)話的建立需要的花費(fèi)(時(shí)間、數(shù)據(jù)大小和數(shù)據(jù)包數(shù)量)是很大的，這是因?yàn)镾SH協(xié)議在進(jìn)行認(rèn)證和SSH連接建立之前建立會(huì)話密鑰要用到 Diffie-Hellman算法進(jìn)行密鑰交換。因?yàn)榧用懿僮魇荂PU綁定的，因此會(huì)話建立所花費(fèi)的時(shí)間在CPU速度比較慢的機(jī)器上增長(zhǎng)更快。

表1 snmpget操作數(shù)據(jù)表

表1同樣也反映出在不同的傳輸層，數(shù)據(jù)大小和數(shù)據(jù)包數(shù)量有明顯的不同：在TCP上使用的數(shù)據(jù)量普遍比UDP高很多。這是因?yàn)門CP連接的使用需要花銷，連接建立和拆卸都需要額外的網(wǎng)絡(luò)流量，而且，在下面的操作系統(tǒng)網(wǎng)絡(luò)層還要保持開(kāi)放的連接綁定資源。不過(guò)，對(duì)于網(wǎng)絡(luò)帶寬日益增加的前提下，這樣的花銷也就算不了什么，而且這種開(kāi)始建立會(huì)話的花銷還可以由后繼的SNMP安全操作來(lái)抵消。

4.2 SSHTM安全模型的安全性能

SSHTM模型的安全性是通過(guò)與SNMPv3/USM安全性進(jìn)行比較得到的。

（1）短操作安全性

短操作主要是通過(guò) snmpget操作進(jìn)行的。snmpget操作在不同安全級(jí)別下時(shí)間表如2所示，單位：ms。

表2 snmpget操作時(shí)間表

（2）長(zhǎng)操作安全性

長(zhǎng)操作安全性是通過(guò)snmpwalk操作進(jìn)行的。snmpwalk操作在不同安全級(jí)別下時(shí)間對(duì)比如表3所示，單位：ms。

從表2的snmpget操作時(shí)間與表3 snmpwalk操作時(shí)間來(lái)看，無(wú)論安全級(jí)別是noAhthnoPriv，或是AuthNoPriv，或還是AuthPriv，TCP協(xié)議下的操作時(shí)間都要大于UDP，這是因?yàn)門CP數(shù)據(jù)包的包頭比UDP數(shù)據(jù)報(bào)的包頭要大，這就造成了 SNMP實(shí)體在處理 SNMP消息時(shí)花費(fèi)的時(shí)間就長(zhǎng)。而SSHTM模型下的SNMP操作，即snmpv2c/SSH，snmpv3/SSH操作在沒(méi)有安全級(jí)別時(shí)(noAuthnoPriv)，所要用到的時(shí)間比snmpv3/UDP/USM snmpv3/TCP/USM都大，這是因?yàn)镾SH會(huì)話建立要進(jìn)行密鑰交換造成的，但隨著安全級(jí)別的增強(qiáng)，SSHTM模型下的SNMP消息所需要的操作時(shí)間明顯降低了，其優(yōu)點(diǎn)顯現(xiàn)出來(lái)了。這是因?yàn)镾SH協(xié)議數(shù)據(jù)包頭增加了一個(gè)很小的頭部，這個(gè)很小的頭部相對(duì)SNMPv3/USM的頭部所占用的空間要小得多。因此可以說(shuō)，在相同的安全級(jí)別下，SSHTM模型比SNMPv3/USM的安全性能要好一些。

5 總結(jié)

通過(guò)構(gòu)造安全外殼傳輸模型 SSHTM，增強(qiáng)了網(wǎng)絡(luò)管理安全性，對(duì)安全模型SSHTM的性能分析得知，SSHTM模型在會(huì)話建立階段因?yàn)橐M(jìn)行密鑰交換用時(shí)相對(duì)來(lái)說(shuō)要長(zhǎng)一些，但隨著時(shí)間的推移這種時(shí)間上的多余可以由后面的操作來(lái)彌補(bǔ)。SSHTM模型比SNMPv3/USM的安全性能要好一些，對(duì)于目前安全性要求較高的網(wǎng)絡(luò)管理來(lái)說(shuō)無(wú)疑是一種好的解決辦法。

[1]M. Schoffstall, J. Davin Simple Network Management Protocol(SNMP)[S].RFC1157.1990.

[2]M. Rose, S. Waldbusser Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)[S].RFC1905.1996.

[3]Presuhn.R McCloghrie.K User-based Security Model (USM)for version 3 of the Simple Network Management Protocol(SNMPv3) [S].RFC3414.2002.

[4]Krawczyk,H.,Bellare,M.,and R.Canetti,HMAC:Keyed-Hashing for Message Authentication[S].RFC2104.1997.

[5]馮登國(guó),裴定一.密碼學(xué)導(dǎo)引[M].北京:科學(xué)出版社.1999.

[6]Ylonen, T. and C. Lonvick, Ed. The Secure Shell (SSH) Protocol Architecture[S].RFC4251.2006.

[7]C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol[S],RFC4253.2006.

[8]C. Lonvick,The Secure Shell (SSH) Authentication Protocol[S].RFC4252.2006.

[9]C. Lonvick, The Secure Shell (SSH) Connection Protocol[S].RFC4254.2006.

[10]http://www.ietf.org/ietf/1id-abstracts.txt.

[11]J. Salowey, J. Galbraith, V. Welch Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol[S].RFC4462.2006.

[12]W.Simpson,S.Willens,Remote Authentication Dial In User Service(RADIUS) [S].RFC2138.1997.

[13]Pat R.Calhoun,John Loughney,Jari Arkko,Erik Guttman,Glen Zorn Diameter Base Protocol[S].RFC3588.2003.

[14]J. Hutzelman, Generic Security Service Application[S].RFC4462.2006.