物聯網之MQTT3.1.1和MQTT5協議 (18) 安全

安全

概述

強烈推薦提供TLS的服務端實現應該使用TCP端口8883(IANA服務名:secure-mqtt)。

安全是一個快速變化的領域,所以在設計安全解決方案時總是使用最新的建議。

解決方案需要考慮的風險包括:

  • 設備可能會被盜用
  • 客戶端和服務端的靜態數據可能是可訪問的(可能會被修改)
  • 協議行爲可能有副作用(如計時器攻擊)
  • 拒絕服務(DoS)攻擊
  • 通信可能會被攔截、修改、重定向或者泄露
  • 虛假MQTT控制報文注入

MQTT方案通常部署在不安全的通信環境中。在這種情況下,協議實現通常需要提供這些機制:

  • 用戶和設備身份認證
  • 服務端資源訪問授權
  • MQTT控制報文和內嵌應用數據的完整性校驗
  • MQTT控制報文和內嵌應用數據的隱私控制

作爲傳輸層協議,MQTT僅關注消息傳輸,提供合適的安全功能是實現者的責任。使用TLS是比較普遍的選擇。

除了技術上的安全問題外,還有地理因素(例如美國歐盟安全港原則 [USEUSAFEHARB]),行業標準(例如第三方支付行業數據安全標準 [PCIDSS]),監管方面的考慮(例如薩班斯-奧克斯利法案 [SARBANES])等問題。

MQTT解決方案:安全和認證

協議實現可能想要符合特定的工業安全標準,如NIST網絡安全框架 [NISTCSF] ,第三方支付行業數據安全標準 [PCIDSS] ,美國聯邦信息處理標準 [FIPS1402] 和 NSA 加密組合B [NSAB] 。

在MQTT的補充出版物 (MQTT and the NIST Framework for Improving Critical Infrastructure Cybersecurity [MQTT NIST]) 中可以找到在NIST網絡安全框架 [NISTCSF] 中使用MQTT的指導。使用行業證明、獨立審計和認證技術有助於滿足合規要求。

輕量級的加密與受限設備

廣泛採用高級加密標準 [AES] 數據加密標準 [DES] 。

MQTT 5增加概述,對AES提供了硬件支持的處理器有很多,但通常不包含嵌入式處理器。加密算法ChaCha20 軟件加解密速度快很多,但不像AES那樣廣泛可用。

推薦使用爲受限的低端設備特別優化過的輕量級加密國際標準 ISO 29192

實現注意事項

實現和使用MQTT時需要考慮許多安全問題。下面的部分不應該被當作是一個 覈對清單 。
協議實現可以實現下面的一部分或全部:

客戶端身份認證

CONNECT報文包含用戶名和密碼字段。實現可以決定如何使用這些字段的內容。實現者可以提供自己的身份驗證機制,或者使用外部的認證系統如LDAP或OAuth,還可以利用操作系統的認證機制。

MQTT v5.0提供了一種增強認證機制。使用此機制需要客戶端和服務端雙方的支持。

實現可以明文傳遞認證數據,混淆那些數據,或者不要求任何認證數據,但應該意識到這會增加中間人攻擊和重放攻擊的風險。

在客戶端和服務端之間使用虛擬專用網(VPN)可以確保數據只被授權的客戶端收到。

使用TLS 時,服務端可以使用客戶端發送的SSL證書驗證客戶端的身份。

實現可以允許客戶端通過應用消息給服務端發送憑證用於身份驗證。

客戶端授權

【MQTT3.1.1】

基於客戶端提供的信息如用戶名、客戶端標識符(ClientId)、客戶端的主機名或IP地址,或者身份認證的結果,服務端可以限制對某些服務端資源的訪問。

【MQTT5】

如果客戶端已經成功通過身份認證,服務端實現需要在接受連接之前執行授權檢查。

授權可以基於客戶端提供的信息如用戶名,客戶端主機名/IP地址,或認證機制的結果。

具體來說,實現應該檢查客戶端是否被授權使用此客戶標識符,因爲客戶標識符提供了對MQTT會話狀態的訪問。此授權檢查是爲了防止某個客戶端偶然或惡意的使用了已被其他客戶端所使用的客戶標識符。

實現應該提供發生在CONNECT之後的訪問控制以限制客戶端發佈消息到特定主體或使用特定主體過濾器進行訂閱的能力。實現需要考慮對具有廣泛作用域的主題過濾器的訪問限制,如"#"主題過濾器。

服務端身份驗證

MQTT協議不是雙向信任的,基本認證沒有提供客戶端驗證服務端身份的機制。

【MQTT5】某些形式的擴展認證允許雙向認證。

但是使用TLS時,客戶端可以使用服務端發送的SSL證書驗證服務端的身份。

MQTT5說的證書是TLS證書

從單IP多域名提供MQTT服務的實現應該考慮RFC6066的TLS的SNI擴展。SNI允許客戶端告訴服務端它要連接的服務端主機名。

實現可以允許服務端通過應用消息給客戶端發送憑證用於身份驗證。

MQTT v5.0提供了一種增強的認證機制,它可以被客戶端用於驗證服務端。使用此機制需要客戶端和服務端雙方的支持。

在客戶端和服務端之間使用虛擬專用網(VPN)可以確保客戶端連接的是預期的服務器。

應用消息和MQTT控制報文的完整性

應用可以在應用消息中單獨包含哈希值。這樣做可以爲PUBLISH控制報文的網絡傳輸和靜態數據提供內容的完整性檢查。
TLS 提供了對網絡傳輸的數據做完整性校驗的哈希算法。
在客戶端和服務端之間使用虛擬專用網(VPN)連接可以在VPN覆蓋的網絡段提供數據完整性檢查。

應用消息和MQTT控制報文的保密性

TLS 可以對網絡傳輸的數據加密。如果有效的TLS密碼組合包含的加密算法爲NULL,那麼它不會加密數據。要確保客戶端和服務端的保密,應避免使用這些密碼組合。
應用可以單獨加密應用消息的內容。這可以提供應用消息傳輸途中和靜態數據的私密性。但不能給應用消息的其它屬性如主題名加密。
客戶端和服務端實現可以加密存儲靜態數據,例如可以將應用消息作爲會話的一部分存儲。
在客戶端和服務端之間使用虛擬專用網(VPN)連接可以在VPN覆蓋的網絡段保證數據的私密性。

消息傳輸的不可否認性

應用設計者可能需要考慮適當的策略,以實現端到端的不可否認性(non-repudiation)。

客戶端和服務端盜用檢測

使用TLS 的客戶端和服務端實現應該能夠確保,初始化TLS連接時提供的SSL證書是與主機名(客戶端要連接的或服務端將被連接的)關聯的。

使用TLS 的客戶端和服務端實現,可以選擇提供檢查證書吊銷列表 (CRLs [RFC5280]) 和在線證書狀態協議 (OSCP) [RFC6960] 的功能,拒絕使用被吊銷的證書。

物理部署可以將防篡改硬件與應用消息的特殊數據傳輸結合。例如,一個儀表可能會內置一個GPS以確保沒有在未授權的地區使用。IEEE安全設備認證就是用於實現這個機制的一個標準,它使用加密綁定標識符驗證設備身份。

異常行爲檢測

服務端實現可以監視客戶端的行爲,檢測潛在的安全風險。例如:

  • 重複的連接請求
  • 重複的身份驗證請求
  • 連接的異常終止
  • 主題掃描(請求發送或訂閱大量主題)
  • 發送無法送達的消息(沒有訂閱者的主題)
  • 客戶端連接但是不發送數據

發現違反安全規則的行爲,服務端實現可以斷開客戶端連接。
服務端實現檢測不受歡迎的行爲,可以基於IP地址或客戶端標識符實現一個動態黑名單列表。
服務部署可以使用網絡層次控制(如果可用)實現基於IP地址或其它信息的速率限制或黑名單。

其它安全注意事項

如果客戶端或服務端的SSL證書【MQTT5,是TSL證書】丟失,或者我們考慮證書被盜用或者被吊銷(利用 CRLs和 OSCP )的情況。
客戶端或服務端驗證憑證時,如果發現用戶名和密碼丟失或被盜用,應該吊銷或者重新發放。
在使用長連接時:

  • 客戶端和服務端使用TLS [RFC5246] 時應該允許重新協商會話以確認新的加密參數(替換會話密鑰,更換密碼組合,更換認證憑證)。

  • 服務端可以斷開客戶端連接,並要求他們使用新的憑證重新驗證身份。

  • 服務端可以要求客戶端使用機制週期性的進行重新認證。

    即MQTT5 的重新認證

受限網絡上的受限設備和客戶端可以使用TLS會話恢復降低TLS會話重連的成本。

連接到服務端的客戶端與其它連接到服務端的客戶端之間有一個信任傳遞關係,它們都有權在同一個主題上發佈消息。

使用SOCKS代理

客戶端實現應該意識到某些環境要求使用SOCKSv5 代理創建出站的網絡連接。某些MQTT實現可以利用安全隧道(如SSH)通過SOCKS代理。一個實現決定支持SOCKS時,它們應該同時支持匿名的和用戶名密碼驗證的SOCKS代理。對於後一種情況,實現應該意識到SOCKS可能使用明文認證,因此應該避免使用相同的憑證連接MQTT服務器。

安全配置文件

實現者和方案設計者可能希望將安全當作配置文件集合應用到MQTT協議中。下面描述的是一個分層的安全等級結構。

開放通信配置

使用開放通信配置時,MQTT協議運行在一個沒有內置額外安全通信機制的開放網絡上。

安全網絡通信配置

使用安全網絡通信配置時,MQTT協議運行在有安全控制的物理或虛擬網絡上,如VPN或物理安全網絡。

安全傳輸配置

使用安全傳輸配置時,MQTT協議運行在使用TLS 的物理或虛擬網絡上,它提供了身份認證,完整性和保密性。

使用內置的用戶名和密碼字段,TLS 客戶端身份認證可被用於(或者代替)MQTT客戶端認證。

工業標準的安全配置

可以預料的是,MQTT被設計爲支持很多工業標準的應用配置,每一種定義一個威脅模型和用於定位威脅的特殊安全機制。特殊的安全機制推薦從下面的方案中選擇:

使用 WebSocket作爲網絡層

如果MQTT在WebSocket 連接上傳輸,必須滿足下面的條件:

  • MQTT控制報文必須使用WebSocket二進制數據幀發送。如果收到任何其它類型的數據幀,接收者必須關閉網絡連接。
  • 單個WebSocket數據幀可以包含多個或者部分MQTT報文。接收者不能假設MQTT控制報文按WebSocket幀邊界對齊 。
  • 客戶端必須將字符串 mqtt 包含在它提供的WebSocket子協議列表裏 。
  • 服務端選擇和返回的WebSocket子協議名必須是 mqtt 。
  • 用於連接客戶端和服務器的WebSocket URI對MQTT協議沒有任何影響。

IANA注意事項

MQTT規範中請求IANA在WebSocket子協議名條目下注冊WebSocket MQTT子協議,使用下列數據:

IANA WebSocket標識符

子協議標識符 mqtt
子協議通用名 mqtt
子協議定義 http://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章