郵件系統基本上是所有企業對外或者對內的工作溝通平臺，而隨着電子郵件的廣泛使用，那些漫天的廣告郵件和包含釣魚鏈接的垃圾郵件成了一個日益嚴重的問題，所以我們的企業安全人員以往更多關注反垃圾郵件，對數據保密有要求的企業還會對郵件外發做數據防泄露方面的管控。
這些年，SMTP協議沒有變，對***者而言，郵件仍然是一個非常好的入口，只是隨着技術水平的提升和利益的趨動，APT***、勒索軟件開始流行起來，並不時被媒體報道。美國大選，希拉里郵箱被***攻破，大量競選相關的黑幕被世人知曉；全球四大會計公司之一的Deloitte（德勤）表示其郵件系統被***，大量客戶郵件被泄露；Locky 勒索軟件通過釣魚郵件方式大量傳播，很多企業用戶中招導致文檔被加密，還有很多的案例，就不一一列舉了。
你的企業郵件系統安全嗎？你的企業有用戶文檔被加密嗎？我們又該做些什麼工作呢？2017年11月10日，黨政機關事業單位和國有企業互聯網電子郵件系統安全專項整治工作電視電話會議召開。
根據網上的相關解讀，電子郵件安全專項整治行動，分爲幾個工作措施：梳理排查郵件系統基本情況、開展郵件系統集中建設工作、加強郵件系統網絡安全等級保護、加強郵件系統建設安全管理、加強郵件系統的應急處置工作，其中關於安全管理中提及了防釣魚、防竊密、防病毒、反垃圾、內容過濾、安全審計這幾個關鍵安全保護措施，我們可以做一些方向上的參考。
小編所在單位很早就部署了專門的郵件網關，產品屬於Gartner領導者象限（爲避免廣告嫌疑就不提具體產品了），入站啓用反垃圾、防釣魚、防病毒功能，出站啓用內容過濾功能，但在實際的運營過程中，還是遇到了不少問題，在解決這些問題的過程中，安全能力不斷提升，這裏抽象出來分爲幾個階段，希望對大家有幫助。
第一個階段：滿足業務需要
郵件網關從上線的第一天開始就是貼合業務需求，比如反垃圾功能。某天，業務人員向我們反饋，大量發給QQ郵箱的通知郵件失敗，希望我們能聯繫QQ郵箱解決。跟騰訊相關同學進行聯繫後，對方反饋由於前一天收到大量來自我們通知郵箱的垃圾郵件，所以將我們對應的郵箱加入了黑名單。臨時處理後，我們開始研究相應的解決方案，SPF、DKIM、DMARC、RDNS等等。
SPF(Sender Policy Framework)是一種以IP地址認證電子郵件發件人身份的技術。當你定義了你域名的SPF記錄之後，接收郵件方會首先檢查域名的SPF記錄，來確定連接過來的IP地址是否被包含在SPF記錄裏面，如果在，就認爲是一封正確的郵件，否則會認爲是一封僞造的郵件進行退回或丟棄處理。SPF可以防止別人僞造你來發郵件，是一個反僞造性郵件的解決方案。設置正確的 SPF 記錄可以提高郵件系統發送外域郵件的成功率，也可以一定程度上防止別人假冒你的域名發郵件。
DKIM（DomainKeysIdentified Mail）是一種防範電子郵件欺詐的驗證技術，通過消息加密認證的方式對郵件發送域名進行驗證。在發送郵件時，發送方會利用本域私鑰加密生成DKIM簽名並將DKIM簽名及其相關信息插入郵件頭，而郵件接收方接收郵件時，通過 DNS 查詢獲得公鑰並驗證郵件DKIM簽名的有效性，從而確認在郵件發送的過程中，防止郵件被惡意篡改，保證郵件內容的完整性。其工作原理圖如下：
DMARC（Domain-basedMessage Authentication, Reporting & Conformance）是一種基於現有的SPF和DKIM協議的可擴展電子郵件認證協議，在郵件收發雙方建立了郵件反饋機制，便於郵件發送方和郵件接收方共同對域名的管理進行完善和監督。DMARC要求域名所有者在DNS記錄中設置SPF記錄和DKIM記錄，並明確聲明對驗證失敗郵件的處理策略。郵件接收方接收郵件時，首先通過DNS獲取DMARC記錄，再對郵件來源進行SPF驗證和DKIM驗證，對驗證失敗的郵件根據DMARC記錄進行處理，並將處理結果反饋給發送方。DMARC能夠有效識別並攔截欺詐郵件和釣魚郵件，保障用戶個人信息安全。
RDNS就是反向解析，即把IP解析爲域名，有時候郵件發出去被退信，做RDNS會好很多，但這個需要找運營商去做。
對比以上技術方案，SPF只需做DNS記錄上的調整，DKIM除了DNS設置外還涉及到郵件網關上的密鑰生成及配置，DMARC則在SPF和DKIM基礎上多了一個反饋共享機制，需要配套的郵箱來接收這些信息。建議從易到難的方式來實施，實際過程中還需多驗證、從子域名着手開始部署，最後逐步。
我們看看qq.com的配置：
qq.com text = "v=spf1 include:spf.mail.qq.com-all”
再看spf.mail.qq.com是一長串的內容：
spf.mail.qq.comtext ="v=spf1 include:spf-a.mail.qq.com include:spf-b.mail.qq.cominclude:spf-c.mail.qq.com include:spf-d.mail.qq.com include:spf-e.mail.qq.com"
一直到spf-a.mail.qq.com才能看到真實的IP地址，其主要原因是騰訊郵箱的服務器太多了，IP地址段非常多而include語法有長度的限制，所以這個需要關注。
這裏面有個細節需要在運營的時候關注，IP地址過多尤其是寫網段的，隨着IP地址的分配變化，有些IP已經不屬於該業務或者該企業了，但SPF記錄如果未更新的話，可能會被有心人利用。
配置好之後，有個在線網站可以幫你評估：www.mail-tester.com，它會出現一個隨機的郵箱，你從你的郵箱發一個郵件過去，它就會自動評分，打對勾的表示測試通過，有扣分的會詳細告訴你情況，如下圖用QQ郵箱測試效果，9分（只扣了1分，很不錯了）：
在郵件網關處對來源IP做SPF做檢查，可以有效阻斷一些僞造的電子郵件，但在我們實際運營過程中，發現有利用知名公司域名的子域來進行投遞惡意郵件的，這個需要關注，比如有一天你收到來自[email protected]的郵件，標題是跟hotfix update相關的內容，你會點開嗎？
第二階段：統計分析優化與應急處置階段
某日，我們對入站郵件的附件進行分析，得到一個很嚇人的數據，直接投遞可執行文件的郵件佔到了惡意郵件的90%，太簡單粗暴了！於是我們開始針對exe、dll等可執行文件直接在郵件網關上進行過濾，凡是附件是可執行文件的直接隔離，以暴制暴！貓和老鼠的遊戲從這裏開始，exe不行了就開始有壓縮包，壓縮包郵件網關也還是能識別的，exe、dll沒了，但還有好多可執行文件格式可以利用，以下是我們遇到的一起案例樣本：
郵件附件名是putty.zip，搞運維的同學都不陌生，點進去就是一個src屏保文件，雙擊就執行了。於是遊戲繼續，某日我們又發現一個附件是加密壓縮包而且將密碼寫在郵件中的樣本：
將這個壓縮包下回來，我們輸入郵件正文中的密碼進去發現是個cpl的文件，如下圖：
這個cpl雙擊也是可以執行的，執行之後會啓動Word打開一個doc文檔，大約過4分鐘後會跟外部通訊，關於這個cpl樣本，又是另外一個很長的故事了，有機會我們再單獨介紹。帶密碼的網關默認是沒法解密了，不過也還是有辦法，如果發現附件是加密了但同時又在郵件正文中出現密碼、password等關鍵字，則可以在郵件網關上做進一步的處理。現在市面上有一些網關號稱可以提取郵件中的密碼對壓縮包進行解密，還沒有實際測試過效果和性能，有測試過的同學可以交流。
第三階段：查漏補缺階段
郵件網關包含了反垃圾、防病毒、防釣魚功能，但實際工作中還是會有放進來的情況，我們建議有條件的企業，將郵件網關投遞到企業郵件服務器的流量丟到沙箱進行分析，如果前面網關沒攔截而沙箱有發現問題，可以針對性的在郵件網關進行加強，如此查漏補缺不斷改進，安全能力肯定會越來越強。
在接入沙箱後，我們看到，除了可執行文件外，還有各種各樣的腳本文件，比如我們抓到不少的js、jse、vbs、vbe文件。我們以jse爲例說明。Jse，全稱JScript EncodedScript，爲什麼jse能雙擊就可以運行，其實跟操作系統的環境變量設置有關：
從上面可以看出，vbs,vbe,js,jse等文件可以直接被執行。題外話：如果終端機器不需要執行各種腳本，可以直接在這裏修改屏蔽。下面是我們從真實環境中抓到的一些樣本截圖，比如下面這個是jse的勒索病毒樣本：
這個jse並非真正被微軟加密過的jse文件，而是病毒作者自己用了各種技術寫成的一個腳本，仔細分析，可以得知腳本經過混淆和加密，一個是變量加長混淆，一個是關鍵函數加密。變量加長的前綴爲：wololosampsonFROG2或者Wololosampson，針對此類的變種，基本的思路是替換，將wololosampsonFROG2替換爲空，然後將Wololosampson替換爲空，得到如下：
這個時候餘下的就是作者自定義的加密函數了，考驗人耐心的時候到了，下面是真正解密後的內容，爲了方便看懂加入了註釋：
整個腳本的流程就是訪問特定URL下載病毒文件並執行，這裏下載後的文件是加密的文件，需要解密後再執行，最後的效果是在感染機器上啓動瀏覽器打開如下的頁面：
隨着powershell的流行，我們也抓到下面這樣一個js樣本，原始郵件內容如下：
這個附件打開裏面是個js，700多行的代碼，各種內部加密組合就不說了，丟到虛擬環境直接看效果：
這個js最後的目標是調用powershell去下載後門並執行，不再過多分析。郵件網關上對策依然是過濾，各種可能有危害的可執行文件、腳本基本在這裏被收拾的差不多了。
某日又發現漏放進來了幾封郵件，居然還是.7z的壓縮包，裏面赤祼祼的還是個可執行文件。經過不斷測試發現，7zip有四種壓縮方式，而現版本的郵件網關居然只支持其中一種壓縮方式，其它3種都無法正常檢測。
這算是一個坑，經過驗證，大版本升級後能解決，但這個細節還需要引起大家的關注，針對壓縮包進行檢測的場景，郵箱入站檢測裏、後端沙箱裏、出站檢測裏都會涉及到，不支持就意味着有被突破的風險。還有一些產品，默認有一些參數，比如針對大的office、pdf可能不會進行檢查，也需要引起關注，在產品測試選型階段就要搞清楚，以便採取針對性的措施或方案進行彌補。