黃曉巧 汪凱

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

0 前言

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

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

1 建立SSHTM模型的目的

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

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

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

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

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

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

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

圖1 擴展的SNMP實體

在圖 1中，在原有的 SNMP實體的基礎(chǔ)上，在 SNMP引擎部分新增加了傳輸子系統(tǒng)，在安全子系統(tǒng)中新增加了TMSM安全傳輸模型。RFC3417中定義的傳輸映射不提供低層的安全功能，也不提供特定的傳輸安全參數(shù)，本文通過定義擴展的SNMP實體框架修改了RFC3411和RFC3417，傳輸映射使用抽象服務(wù)接口(Abstract Service Interface, ASI)把特定傳輸安全參數(shù)傳遞給其它的子系統(tǒng)，包括特定的傳輸安全參數(shù)轉(zhuǎn)換成獨立于傳輸?shù)陌踩桶踩墑e。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)度器的一部分，它負責執(zhí)行實際的安全處理。

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

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

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

3 SSHTM模型安全功能

3.1 SSHTM模型提供的安全保護

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

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

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

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

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

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

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

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

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

3.2 消息認證安全

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

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

3.3 認證協(xié)議安全

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

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

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

4 SSHTM模型的性能

4.1 會話建立

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

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

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

4.2 SSHTM安全模型的安全性能

SSHTM模型的安全性是通過與SNMPv3/USM安全性進行比較得到的。

（1）短操作安全性

短操作主要是通過 snmpget操作進行的。snmpget操作在不同安全級別下時間表如2所示，單位：ms。

表2 snmpget操作時間表

（2）長操作安全性

長操作安全性是通過snmpwalk操作進行的。snmpwalk操作在不同安全級別下時間對比如表3所示，單位：ms。

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

5 總結(jié)

通過構(gòu)造安全外殼傳輸模型 SSHTM，增強了網(wǎng)絡(luò)管理安全性，對安全模型SSHTM的性能分析得知，SSHTM模型在會話建立階段因為要進行密鑰交換用時相對來說要長一些，但隨著時間的推移這種時間上的多余可以由后面的操作來彌補。SSHTM模型比SNMPv3/USM的安全性能要好一些，對于目前安全性要求較高的網(wǎng)絡(luò)管理來說無疑是一種好的解決辦法。

[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]馮登國,裴定一.密碼學(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.