• <strike id="fdgpu"><input id="fdgpu"></input></strike>
    <label id="fdgpu"></label>
    <s id="fdgpu"><code id="fdgpu"></code></s>

  • <label id="fdgpu"></label>
  • <span id="fdgpu"><u id="fdgpu"></u></span>

    <s id="fdgpu"><sub id="fdgpu"></sub></s>
    您當前的位置是:  首頁 > 新聞 > 國內(nèi) >
     首頁 > 新聞 > 國內(nèi) >

    SIP系列講座-SIP安全-3-RTP加密-攻擊類型-防范方法-攻擊工具

    2017-11-09 13:55:10   作者:james.zhu   來源:CTI論壇   評論:0  點擊:


      前面的講座中,他們介紹了SIP安全的幾個核心概念,包括,認證,簽權,SIP加密,TLS等。現(xiàn)在我們繼續(xù)討論關于對語音的加密,DTLS,目前出現(xiàn)的幾個安全問題,如何防范這些安全問題和如何使用工具來檢測這些問題。
    1
      在我們的講座中,我們前面討論了對SIP信令的加密,但是僅對SIP加密仍然不會實現(xiàn)真正的加密,系統(tǒng)必須對語音也進行加密。對語音加密的則稱之為SRTP。
      SRTP的主要作用當然是確保語音流和RTP Payload的加密安全,同時防范第三方軟件對語音的注入,確保本身語音的完整性。SRTP不使用PKI的方式來交換密鑰,它使用的是Master key的方式。如果直接通過明文的SDP發(fā)送key是不安全的,所以必須使用加密的方式來傳輸。如果發(fā)起INVITE之前沒有開啟TLS的話,SDP消息中的k就會被暴露出來,這也是非常不安全的。
      如何傳輸以安全的方式傳輸SDP中的k是一個非常復雜的流程。以下是一個傳輸SDP k的流程圖。這里需要注意到是,在傳輸過程中,用戶需要設置SRTCP來保證第三方侵入,防止對呼叫方強制發(fā)送BYE消息,掛斷呼叫。
      cipher 加密默認使用的是AES,它是一種高級的加密方式。RFC3711 標準對此加密方式的類型和算法有非常詳細地說明,AES本身就非常復雜,筆者對此不是太了解,如果讀者希望獲得更多算法的話,筆者建議讀者查閱RFC 3711。我們現(xiàn)在介紹的SDP中的k屬性,它相對比較簡單,所有的k的消息都在交互中進行。另外一種方式就是使用SDP中的Crypto,它也是一種交互機制,但是支持了很多參數(shù),而且比較靈活。它主要描述了前一個單播媒體中的cryptographic suite,key 參數(shù)和會話參數(shù)。注意,Crypto必須出現(xiàn)在SDP的媒體中,不會出現(xiàn)在信令中。基本的語法格式為:
      a=crypto: []
      在以上的舉例中,SDP包含了3個m 媒體流,但是其中的兩個媒體流則使用了RTP/SAVP傳輸,每個媒體流都有自己的crypto。
      關于crypto具體的解釋如下:
      tag 1 定義crypto的suite。一般默認是1。
      AES_CM_128_HMAC_SHA1_80 則表示是SRTP使用的cipher。
      HMAC_SHA1_80是一個80bit的認證tag消息。
      Master key的長度是128 bit(前面已經(jīng)定義為AES_CM_128),默認的最大生命周期是2^20。
      inLine 是一種Key的方式。這里已經(jīng)明確,inLine 后面的一串字符(PSXXXVBR)。注意,這里也可能是一個URL。
      1:32這里不是1 是Master Key ID,32 Bytes長。也可以支持更多更多的Master key,這些key未來可能會更新。
      我們的示例中使用的是默認的設置。關于crypto suite在RFC4586中有非常詳細地定義,我們這里不再更多討論。
      以下是一個終端設置的舉例,用戶必須啟動相應的安全設置和參數(shù)。注意,不同的終端可能支持的參數(shù)有所不同,用戶要注意檢查。
      在SDP中的消息舉例,這里通常出現(xiàn)的兩個crpto中,用戶會首先選擇第一個crpto。另外,一定要注意,因為加密是雙方的安全機制,需要雙方檢查,同時需要IPPBX本身要配置相應的設置,否則可能導致呼叫失敗。
    2
      盡管SIP加密方式已經(jīng)對SIP信令點安全設置了很多復雜的算法,但是仍然缺乏對呼叫方的身份(Caller Identity)認證經(jīng)過多次轉發(fā)到身份保護機制。如果初始的SIP請求發(fā)起方經(jīng)過多個路徑,當初SIP消息的發(fā)起者的身份在到達最終目的地之前可能因為安全的問題發(fā)生修改。RFC4474 對類似呼叫方身份做了安全的保護。RFC 4474 在頭域中定義了兩個參數(shù)值:Identity和Identity-Info來確保發(fā)起請求者的安全。Identity負責傳輸用戶有效性的簽名消息,Identity-Info負責對證書簽名者傳輸一個證明信息。
      以下圖例解釋了如何通過SIP頭域中的Indentity和Indentify-Info 發(fā)送到呼叫請求中的身份消息。
      整個身份驗證的流程經(jīng)過以下幾個步驟:
      終端發(fā)起INVITE消息,Proxy收到消息以后和自簽的證書服務器進行交互。
      本地Proxy通過證書服務器,使用hash和from header生成本用戶的Indentity。
      簽名服務器返回證書消息,Proxy在SIP消息中添加證書的Indentity和Indentity-Info(證書發(fā)放簽名)。然后對對端Proxy發(fā)起一個INVITE消息。
      對端Proxy收到INVITE消息以后,通過web server 獲取證書信息,然后提取SIP消息中的Indentity和Indentity-Info,結合hash來計算用戶安全身份。
      如果驗證成功,則對另外一個終端發(fā)起INVITE消息。整個驗證過程結束。
      注意,RFC 4474 僅發(fā)布了SIP請求中的安全機制,并沒有規(guī)定如果發(fā)生錯誤時的響應處理機制。響應處理是一個更加復雜的處理流程,希望未來有更多RFC規(guī)定來進一步的優(yōu)化。
      通過以上身份的驗證,整個INVITE信息的安全處理結束,接下來啟動語音的安全認證流程。這里使用了DTLS(Datagram Transport Layer Security)來驗證Indentity和語音的加密處理。以前我們介紹過,TLS不能支持UDP的傳輸,但是實際工作場景中,仍然有很多應用使用UDP。所以,為了滿足UDP的安全處理機制,通過對TLS拓展實現(xiàn)DTLS的安全機制。DTLS可以適用于時延比較敏感的應用場景和VPN(隧道)等場景。在以下場景中,INVITE完成以后,用戶通過DTLS實現(xiàn)對雙方Indentity加密認證,也包括來對語音進行加密。
      當然,以上場景僅是一個非常簡單的雙方呼叫的場景,事實上,在DTLS加密的環(huán)境中,很多應用層面的功能需要考慮,例如,匿名呼叫的防范,早期媒體流的處理,分拆SIP請求,多個媒體處理的握手認證流程。如果Proxy在處理這些功能處理時不能正確處理DTLS握手的流程,也同樣會導致很多呼叫問題。關于DTLS的規(guī)定,用戶可以參考RFC5763進行進一步的研究,我們這里比做更多討論。
    3
      上面我們提到了關于對發(fā)起呼叫方的安全控制機制,但是,目前仍然沒有看到非常完整的關于呼叫方安全保障的完整的解決方案,除了RFC 4474以外,以下規(guī)定也對caller的身份做了相關的規(guī)定:
    • RFC 4474bis-00是RFC 4474的升級,除了header中的identiy以外使用,不僅僅在from header中使用SIP URL,在from header中還增加了Tel的號碼支持。
    • STIR(Secure Telephone Identity)是目前專門針對VoIP-to-PSTN規(guī)定的標準,主要目的對發(fā)起呼叫者的號碼進行保護和確認。因為,在實際電話應用的場景中,大部分的用戶仍然相信普通電話號碼的呼叫,但是因為網(wǎng)絡的介入,PSTN號碼可能最終被其他非法業(yè)務利用來進行非法呼叫。此標準專門針對非法呼叫,語音語音郵箱攻擊等業(yè)務設計了不同的機制。具體規(guī)定請讀者查閱STIR證書草案。
    • P-Asserted-Identity:服務提供商對號碼服務提供的認證用戶保護。其中,在SIP INVITE的呼叫中包括了caller id消息,Proxy 通過在SIP頭中添加P-Asserted-Identity對呼出的網(wǎng)絡聲明其真實性。
    • PSTN網(wǎng)絡中的ISUP通過S/MIME 支持了SIP的SDP加密,需要說明的是,SIP header 不會被加密,仍然需要通過TLS處理。此圖例中,SIP經(jīng)過兩個Gateway 傳輸,最后到達另外一邊的終端。通過MIME來傳輸ISUP消息。
    • IPPBX SIP trunk 和服務提供商之間的安全策略限制或防范設備。在上面的安全策略中,我們所探討的都是基于本地認證機制來實現(xiàn)的。這些解決方案相對比較復雜。如果用戶部署了企業(yè)IPPBX的話,企業(yè)IPPBX通過SIP 中繼實現(xiàn)外部呼叫連接的話,可以通過以下方式實現(xiàn):
      通過SIP中級加密的方式的話,企業(yè)用戶的SIP中繼必須需要安全處理,例如,使用MD5或者TLS加密的方式。如果按照這樣的方式來對接運營商trunk,本地PBX需要支持支持運營商提供的認證方式,運營商也可以調(diào)整認證方式接受本地PBX生成的證書,本地IPPBX必須有有效的證書。
      使用對SIP支持比較好的防火墻來對SIP進行安全處理。事實上,類似的方法也可能遇到很多問題。
      使用IP-Sec 設備或者SBC來連接,通過IP-Sec設備來對所有語音設備進行加密處理。這里要注意,因為IP-Sec設備會處理全部的信令和媒體,增加了很多網(wǎng)絡開銷,帶寬要求也會隨之增加。從目前市場情況來看,如果針對VOIP 語音應用來說,可能SBC是最佳的解決方案。在后期的討論中,我們會重點介紹SBC的作用,讀者可以了解更多比較全面的關于SBC的解決方案。
    4
      在前面的章節(jié)和本章節(jié)的前幾個部分我們重點從技術的角度討論了關于SIP中安全機制的設置和一些技術概念。在以下的圖例中,VOIP用戶仍然面對很多的安全問題,包括上面提到的那些問題,這些安全問題涉及了整個網(wǎng)絡的方方面面,同時也涉及了公司安全策略和各種規(guī)章制度。
      研究人員Dimitris Geneiatakis發(fā)表的關于幾種SIP安全的匯總:
      如果我們回到具體到現(xiàn)實環(huán)境中,SIP安全的問題主要包括以下幾個方面:
      通常情況下,VOIP電話系統(tǒng)都會受到至少五種以上的攻擊或侵入。因為篇幅的關系,我們這里不展開討論所有的攻擊方式和細節(jié)。關于以上攻擊方式的介紹,請讀者查閱SANS Institute Reading Room 發(fā)表的文章,作者重點介紹了各種攻擊方式的概念和基本原理。哥倫比亞大學的SIP研究機構也發(fā)布過關于SIP安全的介紹,用戶可以查閱。如果讀者對安全方面的加密算法有非常濃厚的興趣,可以查閱Amruta Ambre發(fā)表的關于算法加密討論的文章。
      以下是一個示例通過修改SIP信息,把真正的呼叫轉入到侵入者自己的終端,用戶必須使用TLS/PKI/SRTP對信令和語音加密。
      更多關于使用工具侵入或偽裝的操作方式,請參閱筆者提供的參考資料。
      另外一個案例是一個所謂通過釣魚的方式獲取用戶信息。很多時候,釣魚者會給用戶發(fā)送郵件或者短信通知用戶呼叫一個電話號碼(例如:07558101000),說銀行有什么業(yè)務需要客戶馬上聯(lián)系銀行。如果用戶呼叫上面的號碼的話,這時這個號碼會呼叫網(wǎng)關的號碼,然后通過VOIP網(wǎng)關修改路由,最后轉呼到銀行的電話號碼上(真正的銀行號碼:07558100000)。如果用戶不小心的話,可能聽到銀行的呼叫就會按照銀行系統(tǒng)的要求輸入用戶密碼信息(323345),這時,釣魚者可以通過SIP線路上的DTMF按鍵音獲取到用戶的真正的密碼消息。當然,這樣的后果用戶是知道的。
      另外,非法的盜打情況也可能經(jīng)常發(fā)生,因為很多國際長途的花費是非常高昂的,犯罪分子利用國際話費結算的差價獲利。中國國內(nèi)經(jīng)常會看到電話騷擾,電話盜打,電話欺騙的新聞。國外也有類似的問題發(fā)生。根據(jù)FBI的官方報道,2001 年第一個被逮捕的犯罪分子,通過攻擊VOIP電話系統(tǒng),轉售獲得利潤的個人。
      FBI抓捕捕到盜打電話的罪犯。
    5
      國家安全監(jiān)管機構,VOIP行業(yè),廠家,用戶等都有非常明確的安全機制來防范安全問題,但是可能仍然會出現(xiàn)安全問題。我們今天介紹幾個防范措施來最大限度保證用戶的VOIP網(wǎng)絡安全。目前,有效地防范VOIP網(wǎng)絡攻擊的手段很多需要公司系統(tǒng)管理員處不同角度來進行排查,其中也包括了對公司員工的安全教育,公司規(guī)定的安全規(guī)則,技術手段,安全設備部署等。
      關于技術方面的討論我們前面的章節(jié)部分和以前的講座中已經(jīng)做了很多分享,現(xiàn)在,我們再補充一點來自于政府權威機構和研究機構的一些安全建議。
      美國國家安全監(jiān)管機構FBI 建議,F(xiàn)BI的建議中,包括了從地理位置的安全處理,設備的安全處理,人員安全培訓,管理員的安全培訓,采購商的安全處理等方面的內(nèi)容。以下圖例解釋了多種網(wǎng)絡設備在安全方面的設置和相關的公司規(guī)章制度的設立,值得讀者去參考。
      美國負責計算機安全的機構NIST也給出了幾個方面的建議:
    • 網(wǎng)絡數(shù)據(jù)和語音分離,私有網(wǎng)絡和公網(wǎng)的分離。
    • 使用支持ALG的防火墻或者SBC來提升安全性能。
    • 使用比較嚴格的安全認證機制來防范被破解。
    • 使用TLS加密方式。
    • 進來少用個人電腦軟電話或者來自未經(jīng)授權的第三方基于SIP的軟電話。
    6
      因為VOIP網(wǎng)絡中很可能出現(xiàn)很多網(wǎng)絡安全的問題,公司層面雖然制定了很多安全策略,管理人員也部署了針對安全機制的設備,但是仍然需要一些非常有經(jīng)驗的系統(tǒng)管理員來進行維護檢測。技術人員必須了解一些安全工具,以免讓攻擊者侵入。俗話說,知己知彼才能百戰(zhàn)百勝。現(xiàn)在,我們羅列幾個已經(jīng)在VOIP方面使用多年的工具,以便幫助管理員進一步防范攻擊者的攻擊。
      以下列表列出了VOIP工程師可能經(jīng)常使用的排查根據(jù)和平臺,大家可以學習:
      1、使用Wireshark 工具抓包解析數(shù)據(jù):
      2、Nmap 掃描網(wǎng)絡
      3、SIPScan: 掃描端口,IP地址。
      4、Authtool 獲取認證的工具,密碼破解。
      5、進行洪水工具的工具:
      6、Linux 工具: inviteflood,registerflood
      7、SIP 信令篡改工具:erase_registrations(刪除注冊),add_registrations(添加注冊流程)
      8、Linux 系統(tǒng)缺陷檢測工具:protos SIP test suite
      9、Linux 工具:reghijacker(攻擊注冊流程),authtool(竊取認證消息)
      10、Linux 工具:sip_rogue(偽裝B2BUA,或者SIP Proxy)
      11、Linux 工具:teardown 對已創(chuàng)建的SIP 會話拆線工具,自動結束終端通話。
      12、Linux 工具:check_sync 創(chuàng)建一個SIP 終端重啟命令。
      13、Linux 工具:redirector 對SIP呼叫執(zhí)行重定向,可能轉接到非法服務器。
      14、Linux RTP 語音注入工具:rtpinjector 對RTP語音進行注入。
      15、“正式的”Linux平臺工具:Asterisk,F(xiàn)reeSWITCH, SIPp以上這些工具或平臺是正規(guī)的開源語音平臺,用戶可以通過這些平臺開發(fā)呼叫中心,IPPBX,壓力測試等相關業(yè)務。
      到現(xiàn)在為止,我們已經(jīng)把SIP的整個安全措施,流程,機制和相關架構,安全工具等等問題后做了一個比較全面的介紹,希望,讀者通過這個系列的講座充分了解SIP安全的重要性,同時,也必須注意,因為網(wǎng)絡環(huán)境不斷變化,安全防范措施和攻擊工具也同時進行升級,所以用戶需要關注更多這個方面的研究報告,以便保證用戶系統(tǒng)的安全。以下鏈接是關于SIP安全的相關技術資料說明,筆者再次提醒,可能有的工具已經(jīng)不再工作,可能SIP安全能力得到了推廣,所以,攻擊工具可能不能完全正常工作。讀者需要不斷練習,實戰(zhàn)是解決問題的唯一手段。
      參考資料:
      關于STIR:https://datatracker.ietf.org/doc/draft-ietf-stir-certificates/
      關于 Secure Telephone Identity Threat Model:
      https://datatracker.ietf.org/doc/rfc7375/?include_text=1
      關于P-Asserted-Identity:https://www.ietf.org/rfc/rfc3325.txt
      關于SRTP標準:https://www.rfc-editor.org/info/rfc3711
      關于RFC3261認證的升級:https://datatracker.ietf.org/doc/rfc4474/
      關于RFC 4474:https://www.rfc-editor.org/rfc/rfc4474.txt
      https://tools.ietf.org/html/draft-jennings-dispatch-rfc4474bis-00
      關于 DTLS:http://www.rfc-base.org/txt/rfc-5763.txt
      https://www.rfc-editor.org/rfc/rfc4568.txt
      關于DTLS和SIP 身份討論:
      https://www.rfc-editor.org/rfc/rfc6347.txt
      https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/telepresence.html#wp42084
      https://www.cisco.com/c/en/us/about/security-center/securing-voip.html
      SIP加密算法研究:
      Detection and Prevention Mechanism on Call Hijacking in VoIP System。
      SANS Institute Reading Room 關于安全的討論:https://www.sans.org/reading-room/whitepapers/voip/security-issues-countermeasure-voip-1701
      SIP安全討論:http://cdn.ttgtmedia.com/searchUnifiedCommunications/downloads/SIP1Controlling_Convergent_Networks_CH7.pdf
      關于SIP安全的討論:
      https://www.cs.columbia.edu/~smb/classes/f06/l13.pdf
      http://download.securelogix.com/library/SIP_Security030105.pdf
      關于SIP安全討論:http://startrinity.com/VoIP/Resources/sip-security-mechanisms-a-state-of-the-art-review.pdf
      關于SIP安全和攻擊工具介紹:
      http://www.hackingvoip.com/presentations/IPCOMM_SIP.pdf
      https://link.springer.com/chapter/10.1007/978-3-642-11530-1_10
      https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Endler.pdf
      安全測試標準:https://www.rfc-editor.org/rfc/rfc4475.txt
      FBI 關于電話盜打報告和安全機制建議:https://www.fbi.gov/
      攻擊工具列表:http://www.voipsa.org/Resources/tools.php
      關注我們的微信號:asterisk-cn 獲得更多有價值的技術分享,訪問技術論壇下載開源免費IPPBX:www.issabel.cn/forum.
    【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

    專題

    亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩 包头市| 深州市| 大悟县| 庆安县| 新丰县| 林口县| 贡觉县| 梁平县| 桂东县| 墨竹工卡县| 上蔡县| 白城市| 肥西县| 常熟市| 彰化县| 泽库县| 吉水县| 藁城市| 北辰区| 百色市| 寿宁县| 吴堡县| 来安县| 横山县| 周宁县| 新丰县| 都匀市| 繁峙县| 平阴县| 永嘉县| 绥芬河市| 东乡县| 宜兴市| 额尔古纳市| 北海市| 巴中市| 敦煌市| 和硕县| 云安县| 固镇县| 丰宁| http://444 http://444 http://444 http://444 http://444 http://444