對於FreeSWITCH系統保護來說，VoIP安全是一個越來越重要的主題。保護策略包括主動防禦和被動防禦。FreeSWITCH中的主動防禦技術包括各種類型的加密技術，它們用於SIP和RTP通信，以防止篡改或竊聽電話。FreeSWITCH的被動防禦技術，與其它開源工具結合，可以阻止未知來源的可疑或惡意傳輸，並阻止濫用或欺詐。在生產環境中運行時，將FreeSwitch功能與通常可用的開源VoIP工具相結合的重要性益發突顯。
本章內容將分爲以下四個小節：
- 網絡級保護
- 信令保護
- 音頻保護
- 密碼保護
網絡級保護
大多數惡意用戶利用開放的網絡端口入侵VoIP系統。從弱密碼到已知軟件的BUG，他們尋找一切可利用的東西，並試圖利用這些來控制電話系統的配置和路由。他們一般的目的是進行盜打、竊聽電話或竊取信息（如語音郵件）。
由於網絡是系統的入口點，因此請務必密切關注網絡的設置方式，並利用FreeSwitch中的某些功能進一步保護你的系統。
分離接口與限制流量
在開放的互聯網上，SIP是一種經常被盜用的技術。在多數場景下，惡意黑客會嘗試掃描某個範圍的IP地址，向5060端口發送UDP數據包，嗅探服務端的反應。一旦他們找到有響應的服務器，他們就會嘗試強行使用普通密碼，或者乾脆嘗試撥號。在某些情況下，它們還會向服務器發送大量假註冊或其他數據包，破壞系統正常運行的能力。
平均來說，一臺SIP服務器接入互聯網30分鐘後，就會開始受到黑客和腳本的攻擊。如果你跟蹤SIP包，你將會看到很多REGISTER嘗試或INVITE嘗試，它們的user-agents是SIPvicious、friendly-scanner或SIPcli(還有那些更努力把自己僞裝成“普通”話機的人)。是的，他們都是有目的的。
保護FreeSWITCH系統最基本的方法之一是分離SIP接口，並在每個接口上強制執行不同的防火牆或IPTables規則。
正如你在前端章節所學的那樣，FreeSWITCH允許你設置不同的Sofia SIP接口，這樣，你就可以在同一系統的不同IP地址：端口上接收與發送SIP消息。可能不太明顯的是，這個設置對於提供額外的安全性和穩定性很有用。
就安全性而言，Sofia SIP profiles有默認的context用於控制來電路由。這些contex可以默認配置爲嚴格受限的撥號方案context。如果你把受限的撥號方案context與SIP profile相關的配置結合，就不太可能有人通過你的系統發送欺騙性的SIP請求，即使你不小心造成了一個小的錯誤配置。
此外，每個Sofia SIP profile都可以配置自己獨立的訪問控制列表(ACL)。通過這種方式，可以對面向外部的SIP profile (IP地址)施加更嚴格的限制，對私有IP地址施加更寬鬆的限制。
在穩定性和性能方面，關於FreeSWITCH的設計，一個鮮爲人知的事實是每個Sofia SIP接口都是一個單獨的線程。這意味着，通過爲每個端口和IP分配單獨的線程，可以在一定程度上把人可能對系統造成的任何干擾降低到最小程度。雖然這絕不是保護系統的萬無一失的方法，但是當受到惡意攻擊時，任何額外的解決方案都是有幫助的。
簡單配置示例
在最簡單的形式中，爲你的運營商或網絡電話提供商(ITSP)單獨配置一個SIP profile，把它與內部話機所使用的SIP profile隔離開來，本質上是非常有益的。大多數惡意攻擊始於5060端口的掃描，並發現其中的SIP交互。在這點之上，他們將嘗試各種組合來突破我們的鑑權防線，或以其它方式濫用該端口。如果你限制這個IP的訪問，並把端口改爲一個隨機的值 ，通過ACL控制你的運營商訪問權限，那麼即使你的用戶名和密碼泄漏了，你也能阻止他們訪問系統。
下圖展示了人們使用FreeSWITCH時常用的缺省組網設置：
另一種組網方式是：使用獨特的，不同尋常的端口，讓黑客難以找到它。進一步，你可以用防火牆限制運營商的訪問端口，同時，爲內部話機開放另一個端口。那麼，組網結構將變成下圖這樣：
爲了實現上圖的示例，即運營商通過5678端口通信，而內部話機通過23000端口通信，你可以這樣配置：
<profile name="incoming_from_pstn">
<settings>
<param name="auth-calls" value="true"/>
<param name="apply-inbound-acl" value="my_carriers"/>
<param name="context" value="inbound_call"/>
<param name="sip-port" value="5678"/>
... other settings here ...
</settings>
</profile>
上面這個是供運營商訪問的Sofia profile，運營商必須把呼叫發到5678端口。當呼叫抵達這個端口時，將適用my_carriers 這個ACL列表，它確保只有來自運營商的呼叫才能通過。如果你在my_carriers ACL中犯了什麼錯誤，這沒什麼大不了，它配置的context是inbound_call，這個context只允許入局呼叫，不允許出局。這是一套相當可靠的限制條件。
此外，由於你知道只有你的運營商會通過5678端口與你通信，那麼你可以修改你的防火牆或IPTable，讓這個端口只接受運營所屬IP的數據。對於入局訪問來說，這是一種簡單有效的控制方式。
接下來，你需要爲內部用戶建立一個profile：
<profile name="customer_access">
<settings>
<param name="auth-calls" value="true"/>
<param name="apply-inbound-acl" value="default_deny_list"/>
<param name="context" value="customer_call"/>
<param name="sip-port" value="23000"/>
... other settings here ...
</settings>
</profile>
這個Sofia SIP profile供內部用戶使用，你的客戶所發起的呼叫必鬚髮給23000這個SIP端口。這個端口的通信要求鑑權，並用有一個缺省的ACL列表叫default_deny_list，它缺省拒絕所有流量。這個機制要求強制鑑權，也就是說，必須提供合法的用戶名，並且校驗其密碼。如果用戶信息校驗通過，呼叫將被轉給customer_call context，在這裏進一步處理。
複雜配置示例
這個示例複雜一些，展現另一種網絡隔離的方式，假設你有網絡路由設備，那麼你可以對網絡進行物理分割(獨立網絡電纜和路由器)，或者建立子網或VLAN(參見下一章)。在更復雜的組網結構中，你還可以通過操作系統，爲不同的網卡綁定不同的IP地址。除了把SIP端口映射到不同的網絡接口之外，還可以把event socket和其它FreeSWITCH管理端口映射出來。
爲了實現這個方案，你需要設置兩個Sofia SIP profiles，就像這樣：
<profile name="incoming_from_pstn">
<settings>
<param name="auth-calls" value="true"/>
<param name="apply-inbound-acl" value="my_carriers"/>
<param name="context" value="inbound_call"/>
<param name="sip-port" value="5678"/>
<param name="sip-ip" value="2.3.4.5"/>
... other settings here ...
</settings>
</profile>
<profile name="customer_access">
<settings>
<param name="auth-calls" value="true"/>
<param name="apply-inbound-acl" value="default_deny_list"/>
<param name="context" value="customer_call"/>
<param name="sip-port" value="23000"/>
<param name="sip-ip" value="212.222.33.111"/>
... other settings here ...
</settings>
</profile>
請注意其中的SIP IP設置，不同的接口是不同的。一個是2.3.4.5，另一個是212.222.33.111。FreeSWITCH會根據Sofia SIP profile中配置的IP地址嘗試連接不同的物理網口。這樣，你可以爲FreeSWITCH系統中的不同網口，配置不同的防火牆規則和網絡連接。
在這個場景中，2.3.4.5中一個內部IP地址，它不能在公網中路由；而212.222.33.111則是一個公網IP地址，在公網中是可路由的。除非你有用戶在外部網絡中，否則212.222.33.111將只開放給對接的運營商。如果內部用戶需要通過公網訪問，可以通過VPN接入你的網絡。這將是最安全的策略。
前面描述的場景，可以通過下圖說明：
如上圖所示，內部話機與FreeSWITCH上綁定IP地址爲2.3.4.5的網卡通信，而運營商則與綁定爲212.222.33.111的網卡通信。
虛擬局域網(VLAN )
VLAN是一種將電話與本地網絡上的數據通信隔離開來的絕佳方法，如果操作正確，它們可以提高通話質量，同時防止惡意活動。
你不願意看到本地局域網的數據流量(有人在拷貝電影或備份大文件)影響到電話通信的共享帶寬，從而降低音/視頻通話的質量。
VLAN經常被忽略，但事實上，把電話網絡和計算機網絡混合在一起往往會造成巨大的傷害。在同一網絡中，識別一臺設備的地址並登錄是很簡單的。從中可以很輕鬆地提取很多話機的SIP用戶名和密碼。比如，你登錄一臺老式的Polycom話機後，就可以導出包含電話憑據的配置，並以純文本形式查看它們。如果話機位於網絡中的一個私有網段，那麼要達到相同目的就要面臨更大的挑戰。
除了直接操縱話機外，VLAN還阻止計算機上運行的工具向語音網絡發送虛假信息。這包括一些簡單的場景，如未經授權的軟電話，劫持一個分機併發送虛假的BYE消息，從而把本應該繼續通話的話務故意掛斷。
值得注意的是：VLAN對大多數網絡都是可用的，無論是基於端口標記的網絡(在交換機上指定物理口分配VLAN)，還是基於軟件標記的網絡都適用(通過網卡，或操作系統在IP報頭中用特定的VLAN號標記每個數據包)。
VLAN的設置方法超出本書的討論範圍。然而，應該注意的是，幾乎所有流行的臺式話機和最新的網絡設備都支持VLAN，包括基於軟件和基於端口的VLAN標記。
入侵檢測
檢測試圖訪問系統的入侵者，或故意創建拒絕服務或類似類型的干擾的入侵者是一種挑戰。雖然不尋常的流量有時候看起來很明顯，但是在設置自動檢測和阻止黑客嘗試的規則時，必須考慮一些邊緣情況。
註冊和呼叫嘗試監控
有些工具通過發送大量的假的授權嘗試消息，並忽略SIP中的授權質詢，以此衝擊VoIP系統。有一款很常見的攻擊工具叫friendly scanner或SIPvicious。這類工具使系統忙於處理僞造的請求，從而讓系統過載，處理真正的請求變得困難。另一種可疑行爲是短時間內頻繁撥打長途或國際長途電話。
在嘗試使用系統中的憑據（識別與否）時，FreeSWITCH提供了記錄告警信息的功能。然後可以用Fail2Ban之類的程序監視這一日誌行的輸出頻率。如果頻率達到我們設定的閾值，那麼對應的IP地址可能會被堵塞一段時間(或永久)。如果在相對較短的時間內從同一IP地址進行大量授權嘗試，通常認爲這是可疑的。
爲了確保FreeSWITCH收到無效身份驗證嘗試時生成警告，可以修改SIP profile並添加以下設置：
<param name="log-auth-failures" value="true"/>
收到授權嘗試時，會生成一條日誌信息，內容看起來是這樣的：
[WARNING] SIP auth challenge (REGISTER) on sofia profile 'customer_access' for [[email protected]] from ip 184.106.157.100
Fail2Ban 會自動統計這些日誌出現的頻率，如果達到設定的閾值，那麼系統將自動阻塞來自IP 184.106.157.100的通信數據。
Fail2Ban
Fail2Ban是一個第三方程序，它運行在後臺監視日誌。如果特定的日誌行(比如我們前面提到的授權嘗試)出現的頻率達到某個值(指定時間週期內超過指定的次數)，Fail2Ban會觸發一個響應動作。可以向你發封電子郵件進行告警，或自動添加一條IPTables規則，阻斷相應IP的通信。
本書不是Fail2Ban的完全指南。但是，在本章後續內容中，我們還是會給一些示例腳本。
配置Fail2Ban需要創建好幾個文件，它們指示Fail2Ban需要關注什麼樣的日誌，如果有匹配的日誌應該做些什麼。
Fail2Ban的默認配置中有一個用於存放filter的目錄。這些filter包含用於匹配日誌的字符串，相當於篩選器。如果你需要在日誌中查找不同類型的可疑輸出，可以設置任意多個filter。與FreeSWITCH非法登陸輸出的錯誤日誌相結合，立馬實現一套有效的過濾機制。
另一個文件叫jail配置文件，它將filter應用於一套規則之中，比如說錯誤允許出現的頻率，超過閾值時需要執行什麼響應動作之類的。Jail配置文件有效地定義了filter匹配時的應對措施。
- Filter配置文件
讓我們首先瀏覽一個filter配置文件。這類文件通常存放在/etc/Fail2Ban/filter.d/目錄下，並根據你的篩選內容命名。這個文件包含一個filter定義，用於查找授權嘗試失敗的日誌。它的格式是標準的正則表達式。在這個案例中，我們認爲FreeSwitch在有人試圖以無效憑據註冊或進行呼叫時都會失敗。
Fail2Ban社區的友好人士爲FreeSWITCH用戶維護了一個定製的配置。可以通過他們的git倉庫獲取最新的版本( https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/freeswitch.conf)，把它另存爲/etc/Fail2Ban/filter.d/freeswitch.conf。本文撰寫時，它的內容是：
# Enable "log-auth-failures" on each Sofia profile to monitor
# <param name="log-auth-failures" value="true"/>
# -- this requires a high enough loglevel on your logs to save these messages.
#
# In the fail2ban jail.local file for this filter set ignoreip to the internal
# IP addresses on your LAN.
#
[Definition]
failregex = ^\.\d+ \[WARNING\] sofia_reg\.c:\d+ SIP auth (failure|challenge) \((REGISTER|INVITE)\) on sofia profile \'[^']+\' for
\[.*\] from ip <HOST>$
^\.\d+ \[WARNING\] sofia_reg\.c:\d+ Can't find user
\[\d+@\d+\.\d+\.\d+\.\d+\] from <HOST>$ ignoreregex =
# Author: Rupa SChomaker, soapee01, Daniel Black
# https://freeswitch.org/confluence/display/FREESWITCH/Fail2Ban
# Thanks to Jim on mailing list of samples and guidance
它將關注FreeSWITCH 中註冊(REGISTER)和呼叫(INVITE)失敗的日誌信息。
- Jail 配置
現在，將這個filter與一個jail條目結合起來，如果在一段時間內收到太多失敗的邀請或註冊，那麼這個條目會阻止一個IP地址。
升級Fail2Ban時可能會覆蓋/etc/jail.conf文件。創建一個/etc/fail2ban/jail.local文件，並輸入以下內容，注意把FreeSWITCH日誌文件的路徑修改爲你環境中的路徑(你的日誌文件路徑可能是/usr/local/freeswitch/log/freeswitch.log)，並把sender字段中的Email地址修改爲你自己的：
[freeswitch] enabled = true
port = 5060,5061,5080,5081
filter = freeswitch
logpath = /var/log/freeswitch/freeswitch.log
action = iptables-allports[name=freeswitch, protocol=all]
sendmail-whois[name=FreeSwitch, dest=root, [email protected]] maxretry = 10
findtime = 60
bantime = 600
# "ignoreip" can be an IP address, a CIDR mask or a DNS host ignoreip = 127.0.0.1/8 192.168.2.0/24 192.168.1.0/24
上面設置中，使用名爲freeswitch的filter，如果在指定週期60秒內(findtime)，某個IP地址有10次(maxretry)的註冊或呼叫授權失敗，那麼阻止入侵者的IP併發送一封告警郵件。如果在60秒內滿足篩選器（意味着發生10次失敗的邀請或註冊授權嘗試），則會在600秒（bantime）內完全禁止有問題的IP地址，並向配置的管理員地址發送警報郵件。
- 不要製造冤假錯案
Fail2Ban的配置必須調優，這樣一個大型的站點纔不會在恢復上線時被踢除下線，因爲剛上線時，它所屬的所有話機都會在同一瞬間內重新註冊。舉例說明：如果你有一個Fail2Ban的速率限制條目(關於“良好”流量數量的規則，而不是關於“失敗嘗試”數量的規則)，如果該站點正好在5秒鐘內向你發送了50個身份驗證請求，你可能不希望Fail2Ban阻止它們。因爲這個站點有50部話機，假設站點停電了，在供電恢復的瞬間，所有話機都會同時嘗試重新註冊，如果我們只管數量，瞬間流量過大將導致它們被阻止。這顯然不是我們的意願。通過流量判斷“拒絕服務”(Denial of Service,DOS)攻擊時千萬要小心。
設置Fail2Ban時，要注意做好邊緣測試，比如我們剛討論過的停電的場景。
非WebRTC SIP中的加密：信令和媒體
已經特別針對“經典”或“普通”SIP開發出針對性的加密技術(和基於WebRTC的SIP不同，這點後面會有介紹)。
SIP加密基於兩個概念——加密信令和加密媒體（音頻/視頻）通信。與任何標準加密機制一樣，SIP加密利用標準加密庫，並涉及密鑰交換和密碼協商，保證安全地傳輸和接收信息。
SIP中使用的主要加密算法(稍後將詳細介紹)與這些場景非常相似：Web上的SSL或ssh連接遠程服務器時的密鑰交換。在任何一種交換中，主要目標都是在雙方之間建立一種算法和一個只有他們雙方知道的共同祕密，並把它們用於對實際內容(比如說電話)的加密和解密。
在任何一種交換中，主要目標都是在雙方之間建立一個加密算法和一個只有他們知道的共同加密祕密，這可以用來加密和解密實際內容——電話呼叫。
許多人大談術語TLS、SSL和SRTP，卻沒有完全理解它們。爲了充分保護通信，這裏建議同時對信令和音頻實施加密策略。
在接下來幾節中，我們將挨個介紹各種加密策略的細節。
在加密選項間進行選擇
FreeSWITCH有一些可用的加密選項。你可以加密信令(SIP消息)、媒體(RTP攜帶的音頻流)，或者對兩者都加密。
TLS (傳輸層安全)對基於TCP連接的所有內容加密，但它有個缺點，即TCP引入的抖動的時延。UDP通常是RTP的首選，使用TLSV1會帶來一點額外的流量開銷。
ZRTP的優點是它允許端到端(end-to-end)加密而不需要預先交換密鑰或證書，但配置起來有些複雜，特別是對於某些客戶端。ZRTP協議是由Phil Zimmermann參與共同設計的，他就是創建PGP加密的那個傢伙。更多信息請訪問http://zfone.com。
SSL (Secure Sockets Layer) v2/3; SSLv2已經被發現漏洞，自2011年以來已經被棄用，而SSLv3在2014年被破解，並在2015年被棄用(可以谷歌搜索POODLE攻擊)。我們沒有必要使用一種可破解的加密方式，因此，禁用SSL算法。
禁用SSLv3和SSLv2
我們的默認配置已經糾正這個問題很長時間了，但保險起見，你還是檢查一下自己的設置。希望你的tls-version參數配置中，不要出現sslv2或sslv3。
打開/usr/local/freeswitch/conf/vars.xml文件，(如果你是用安裝包安裝的，那麼可能是/etc/freeswitch/vars.xml)，找到這一行，確保它的內容是這樣的：
<X-PRE-PROCESS cmd="set" data="sip_tls_version=tlsv1,tlsv1.1,tlsv1.2"/>
然後檢查所有SIP profiles，看看它們是引用了這個變量還是有自定義的。一般都是繼承全局變量設置的：
<param name="tls-version" value="$${sip_tls_version}"/>
證書
對於任何類型的SIP加密，你都需要由認可的證書頒發機構頒發("簽名")的安全證書，該證書負責證明你的身份。
你可以使用模擬證書頒發機構的軟件(自己充當證書頒發機構)來製作“自籤”證書作弊。千萬不要這樣，請閱讀一下"WebRTC, SIP 和 Verto"那一章中的“證書”那一節。
證書與使用SSL作爲加密方法無關，“SSL證書”只不過是調用安全證書的舊方法(因爲當時使用的是SSL，但它也可以用於TLS，這完全沒有任何問題，始終是同一個證書)。此外，如果你禁用SSL，你依然需要證書，因爲TLS、DTLS和其它所有的加密算法都需要證書。
“真實”證書，來自“真實”CA
你需要使用真實的、實際的證書頒發機構頒發的證書(而不是“自籤”證書)。這些“真實”的證書，可以被SIP客戶端、WebRTC客戶 端、瀏覽器和物聯網自動接受。
從https://letsencrypt.org，你可以免費獲取合法證書，你也可以探尋最適合自己需要的付費解決方案(比如說通配證書)。
關於證書獲取安裝的細節，請參考第5章“WebRTC，SIP與Verto”的“證書”一節
保護信令
SIP信令中包含你的話機用於發起和接收呼叫的鑑權信息，還包含主叫與被叫電話號碼、身份信息，默認情況下，都是以純文本的形式描述的。這很容易嗅探和假造。加密可以增加它的難度。此外，如果你使用SRTP(安全RTP)，那麼SIP信令中還包含了保證音頻安全用的加密密鑰。如果有人以純文本的方式獲取這些密鑰內容，那麼他就很容易攻擊你的加密媒體。
通過TLS加密
當你拿到證書之後，你需要告訴FreeSWITCH使用這些證書。爲了達到這個目的，需要設置/usr/local/freeswitch/conf/vars.xml裏的幾個變量：
<X-PRE-PROCESS cmd="set" data="sip_tls_version=tlsv1,tlsv1.1,tlsv1.2"/>
<X-PRE-PROCESS cmd="set" data="internal_tls_port=3361"/>
<X-PRE-PROCESS cmd="set" data="internal_ssl_enable=true"/>
<X-PRE-PROCESS cmd="set" data="external_tls_port=3381"/>
<X-PRE-PROCESS cmd="set" data="external_ssl_enable=false"/>
<X-PRE-PROCESS cmd="set"
data="sip_tls_ciphers=ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH"/>
注意：在vars.xml中，TLS(由於歷史原因，以"ssl"命名)選項對內部和外部profile是分開設置的。
最後一行設置使用的密碼算法。如果你需要抓包分析自己的SIP TLS 包(使用私鑰)，那麼你只能使用非完全正向保密(PFS)算法。因此，使用AES256-SHA：
<X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=AES256-SHA"/>
在vars.xml中設置好默認值後，檢查你的SIP profile，確保其中的參數反映了你的意志(注意"<!--"與"-->"間的內容是被註釋掉的)：
<!-- TLS: disabled by default, set to "true" to enable -->
<param name="tls" value="$${internal_ssl_enable}"/>
<!-- Set to true to not bind on the normal sip-port but only on the TLS port -->
<param name="tls-only" value="false"/>
<!-- additional bind parameters for TLS -->
<param name="tls-bind-params" value="transport=tls"/>
<!-- Port to listen on for TLS requests. (5061 will be used if unspecified) -->
<param name="tls-sip-port" value="$${internal_tls_port}"/>
<!-- Location of the agent.pem and cafile.pem ssl certificates (needed for TLS server) -->
<!--<param name="tls-cert-dir" value=""/>-->
<!-- Optionally set the passphrase password used by openSSL to encrypt/decrypt TLS private key files -->
<param name="tls-passphrase" value=""/>
<!-- Verify the date on TLS certificates -->
<param name="tls-verify-date" value="true"/>
<!-- TLS verify policy, when registering/inviting gateways with other servers (outbound) or handling inbound registration/invite requests how should we verify their certificate -->
<!-- set to 'in' to only verify incoming connections, 'out' to only verify outgoing connections, 'all' to verify all connections, also 'subjects_in', 'subjects_out' and 'subjects_all' for subject validation. Multiple policies can be split with a '|' pipe -->
<param name="tls-verify-policy" value="none"/>
<!-- Certificate max verify depth to use for validating peer TLS certificates when the verify policy is not none -->
<param name="tls-verify-depth" value="2"/>
<!-- If the tls-verify-policy is set to subjects_all or subjects_in this sets which subjects are allowed, multiple subjects can be split with a '|' pipe -->
<param name="tls-verify-in-subjects" value=""/>
<!-- TLS version default: tlsv1,tlsv1.1,tlsv1.2 -->
<param name="tls-version" value="$${sip_tls_version}"/>
<!-- TLS ciphers default: ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH -->
<param name="tls-ciphers" value="$${sip_tls_ciphers}"/>
使用TLS可能會有一些陷阱和混亂。TLS是基於TCP的，而不是UDP。如果話機位於防火牆或NAT穿越機制之後，FreeSWITCH主動連接話機(比如向話機傳遞呼叫)可能會連接不上。你必須確保所有防火牆的配置支持TCP入局穿透。此外，還要保證你的話機上的時間配置正確，因爲如果時間相差太多，你可能會收到神祕的證書錯誤消息，導致不能正常建立握手。
保護媒體
對RTP流(音頻或視頻)進行加密，可以保證SIP通話的實際內容不會被竊聽、錄音非法截取。有多種方法可以達成這個目標。
實現加密的核心在於：發送與接收雙方就加密的方法和數據傳輸過程中加密與解密的算法達成一致。換句話說，如果不是兩邊都支持的加密方法，你就不能使用。此外，加密算法是基於密鑰交換完成的，這通常在呼叫開始時進行。密鑰交換有點類似於雙方交換密碼，但它是以電子方式進行的，而且通常是自動的。
加密音頻和視頻媒體流有兩種流行方式：SRTP和ZRTP。
SRTP由來自思科和愛立信的協議與加密專家組成的一個小組在2004年開發。SRTP定義了一種傳輸和接收RTP的方法，它在消息中攜帶身份驗證和完整性信息，還有RTP數據的回放保護信息。因爲它比較老，而且由關鍵的IP電話硬件供應商開發的，所以影響廣泛，大部分SIP設備都採用它。幾乎市場上可以見到的所有設備都支持SRTP。
ZRTP是由Phil Zimmermann (PGP的創建者)在2006年開發的。它是一個較新進入者，使密鑰協商自動化，大大簡化了設置和操作，以確保RTP通話的安全和加密。它還具有不依賴於服務器端加密的額外優勢。加密可以發生在不知道RTP流內容的服務器之間。然而，目前支持ZRTP的硬件數量有限，如果這個協議要完全成功，還需要多數硬件製造商實現。
FreeSWITCH既支持SRTP也支持ZRTP，不要着急，這一章會介紹怎麼使用它們。
通過SRTP加密
SRTP是一種加密機制，它在SIP呼叫建立過程中協商。SIP對方的雙方必須都同意支持RTP加密，並在SIP信令包中交換密鑰。SRTP所使用的密鑰是在SIP協商過程中交換的。然後用這些信息對媒體流加密。
SRTP支持對RTP數據進行加密，對RTP UDP數據包加密的開銷比較小。這樣做的好處是：呼叫數據加密了，但仍然通過UDP通信，使網絡時延最小化，而且可以和未加密流共享網絡遍歷機制。
一般來說，對於現有的安裝，SRTP是最適合防火牆的策略，因爲使用RTP時已經完成了網絡上的實質傳輸工作。在FreeSWITCH中配置SRTP相當容易。
因爲已經完成了使RTP在網絡上正確傳輸的實際工作。SRTP在FreeSwitch中配置相當容易。
注意：除非你同時啓用SIP的加密配置(前面討論過的)，否則SRTP的密鑰將在網絡中裸奔。爲了在你的話機與FreeSWITCH之間實現完全的安全連接，你應該把SIP加密和SRTP加密結合起來使用。這可以防止任何窺探的中間人攻擊。如果只啓用SRTP，那麼只有RTP包的有效載荷部分數據是受保護的。
啓用SRTP
你可以在撥號方案中爲每一路呼叫單獨啓用SRTP，需要時設置以下標記：
<action application="set" data="sip_secure_media=true"/>
這需要對出局和入局的兩條leg上都執行，才能完全有效。當然，向你提供PSTN落地網關的ITSP供應商可能不支持SRTP，因此，你可以只在FreeSWITCH與終端間啓用SRTP。
通過檢查變量${sip_secure_media_confirmed}來確定媒體安全的情況。我們給個示例，如果SIP媒體受保護，下面代碼塊將播放一個bong提示音：
<extension name="is_secure">
<condition field="${sip_secure_media_confirmed}" expression="^true$">
<action application="sleep" data="1000"/>
<action application="gentones" data="${bong-ring}"/>
</condition>
</extension>
- SRTP調試
在調試加密通話時，SIP數據包中有一個有用的提示，它說明電話是否正確地請求加密。如果你在SIP協商過程中提供RTP加密能力，你可以在SIP消息中看到一行a=crypto描述(你可以在FreeSWITCH 控制檯上看到TLS加密的SIP消息文本，方法是執行"sofia global siptrace on"命令)。
通過ZRTP加密
ZRTP是一種基於SRTP的加密算法，與SRTP不同的是，它在媒體流中交換加密密鑰，使加密過程更安全，而且對不支持協議的服務器是透明的。這使ZRTP比SRTP更靈活，併爲終端提供完全控制，以處理所有層面的加密需求，還沒有中間人攻擊的風險。ZRTP也不需要在媒體建立之前交換密鑰。密鑰交換髮生在RTP對話建立的初始期間。RTP協議在RFC6189中有充分的闡述。
ZRTP的一個主要優勢是它可以通過代理工作。通常使用SRTP，通信路徑中的每個點都需要知道加密協議，並且通過對媒體流加密和解密。這樣的話，如果你有權限訪問路徑中間的節點，那就意味着你可以在中間監聽。使用ZRTP時，正好相反，中間的服務器根本不瞭解其中的加密協議。它們只是認爲自己在透傳標準的RTP數據包。因爲服務器需要關心RTP流裏所包含的內容，所有隻需要兩邊的終端支持ZRTP，這樣對話的安全性保障才更徹底。代理不需要理解或傳遞加密信息。
ZRTP在FreeSWITCH中的另一個優勢是它是默認啓用的。ZRTP協議本身把協商包插入到RTP對話的初始包中，並等待應答。如果收到應答，那麼在其它終端請求時，就能自動啓用ZRTP加密。
因爲zrtp是一種不那麼流行的協議，所以除了支持ZRTP的電話和軟電話客戶端之外，還有ZRTP軟件代理可以工作。這個代理允 許你簡單地安裝一款叫Zfone的插件，就能把天生不支持ZRTP的軟件改造掉，讓它自動完成RTP流量的加密。Zfone在後臺默默地運行，發生密鑰交換時，會彈出通知消息告訴你。此外，還有一款SDP可以幫助你開發支持ZRTP的軟件和硬件。
- 啓用 ZRTP
首先，編輯/usr/local/freeswitch/conf/autoload_config/switch.conf.xml，把rtp-enable-zrtp屬性設置爲"true"：
<param name="rtp-enable-zrtp" value="true"/>
其次，你可以在撥號方案中啓用或禁用ZRTP支持，命令如下：
<action application="set" data="zrtp_secure_media=[true|false]"/>
ZRTP協商時，你將會在FreeSWITCH的控制檯上看到這樣的輸出說明正在提供ZRTP：
[DEBUG] switch_rtp.c:928 [ zrtp main]: START SESSION INITIALIZATION.
接下來，ZRTP協議將開始向RTP流中注入ZRTP協商包。如果ZRTP成功開啓會話，你將看到一條確認消息，後面跟着一系列ZRTP日誌消息，表明現在通道進入安全狀態，例如：
[zrtp protoco]: Enter state SECURE (DH).
您還將看到所選共享機密緩存已自動存儲，將在下次呼叫時用於比較：
[ zrtp cache] Storing ZRTP cache to </usr/local/freeswitch/db/zrtp.dat>...
測試媒體SIP加密
在演示配置中，當你呼叫9664(或呼叫5000接入IVR，然後按3)時，會同時嘗試SRTP和ZRTP。如果你從啓用SRTP或ZRTP的軟電話上呼叫(比如Linphone)，你將在聽到音樂之前聽到"This call is secure"的提示音。
保護WebRTC SIP、VERTO信令與媒體
WebRTC默認是加密的，使用TLS進行wss信令加密，使用DTLS(基於UDP的TLS)進行RTTP加密。請參閱WebRTC那一章的加密無處不在那一節。
對媒體和數據流的加密是強制的。不對媒體流加密，你根本無法建立WebRTC通信。媒體流包括音頻、視頻，還可能有數據流。媒體流通過DTLS交換密鑰，加密爲SRTP。
會話協議的信令(SIP或VERTO)也是加密的。承載這類信令的傳輸層通常是安全的WebSocket。在定義WebRTC信令服務器和終端時，URI前綴WSS:// (WebSocket Secure)無處不在。WSS信令交換由TLS加密。
保護密碼
在FreeSWITCH系統中，很多時候都用到密碼：話機註冊、發起呼叫、FreeSWITCH向外部網關/ITSP註冊、管理員通過Event Socket連接FreeSWITCH系統時的身份驗證(比如說fs_cli)。這些場景經常使用弱的明文密碼。
此外，許多用戶將密碼設置爲簡單、易於猜測的組合。更糟糕的是，有些人甚至從未更改或設置過語音信箱密碼，保留了默認設置。
這些密碼通常是有針對性的，一旦泄漏，就會被用於實施欺詐。
以下是一些可以緩解這些痛點的機制。
以散列值作爲註冊密碼
不要以明文形式在磁盤中保存註冊憑據。在你的用戶目錄中定義SIP憑據時，把這樣的格式：
<param name="password" value="samiam"/>
替換爲a1-hash 預計算的密碼，就如：
<param name="a1-hash" value="c6440e5de50b403206989679159de89a"/>
在linux平臺上生成a1-hash，可以獲取username:domain:password的值，並對它進行MD5運算，它用到你的用戶名、域名和密碼，通過冒號綁定在一起。例如：
echo -n "darren:2600hz.com:pass1234" | md5sum b62d1e3e27773ffd173c87e342a6aace
在用戶目錄條目中使用返回的散列值。這意味着您不必將實際的SIP註冊憑據存儲在磁盤上，這樣，入侵你文件系統的黑客也將無看到你的實際密碼。
下面是一個完整的示例：
<user id="darren">
<params>
<param name="a1-hash"
value="c6440e5de50b403206989679159de89a"/>
</params>
</user>
語音信箱密碼
語音信箱歷史上曾遭到各種原因的攻擊。除了簡單監聽別人的消息之外，語音信箱還經常被利用，因爲它具有遠程開啓回撥或前轉的功能。最常見的一種攻擊策略是入侵語音信箱系統，並把個人呼叫轉移到一個昂貴的國際長途目標上，適時間內盜用數千美金的話費。語音郵件密碼黑客行爲即使在今天也很流行。
防範弱的語音信箱密碼相當簡單。FreeSWITCH在數據庫中以純文本的形式存儲語音信箱密碼，允許你掃描弱諸如1111、1234之類的密碼。你還可以掃描出哪些賬號是直接把分機號設置爲密碼的，這是另一種常見的不安全策略。
要掃描弱密碼，你需要寫一個腳本來查找存儲語音信箱配置的數據庫。假設你使用的是FreeSWITCH的默認配置，那麼語音郵箱數據庫是一個SQLite文件，它位於你FreeSWITCH目錄下的DB文件夾中。根據你的FreeSWITCH安裝方式，這個目錄的具體位置會有些許不同，最有可能的地方是/opt/freeswitch/db、/usr/local/freeswitch/db或/var/lib/freeswitch/db。
檢查數據庫的一個示例方法是使用以下簡單的SQLite查詢
sqlite3 db/voicemail_default.db "select * from voicemail_prefs where password=1234 or password=1111"
這條命令調用SQLite3在的linux客戶端去查找voicemail_prefs這張表，檢查所有密碼設置爲1111或1234的記錄。它會在屏幕上打印出所有信箱相關的信息，包括用戶名、域名。然後，你可以採取糾正措施，要麼強制重置密碼，要麼與用戶聯繫，建議他們更改密碼。
總結
只是簡單介紹當今最常見的VoIP安全技術。此外還有很多資源，如www.hackingvoip.com網站、關於入侵VoIP和計算機安全的書籍。
採取本章中概述的基本步驟，將爲你提供足夠的安全防範當今最常見的黑客攻擊、DoS攻擊和盜用。這應該能夠讓大多數中小型PBX或承載VoIP的系統安全可靠地運行。
現在我們即將進入本書的最後一章。它告訴我們：當我們碰到出錯問題時；我們無法實現某些東西時；我們碰到一個 FreeSWITCH的BUG時，需要怎麼處理。我們將學習有關故障排除、尋求幫助和報告問題的基本知識。