電子郵件之安全

電子郵件說簡單可以非常簡單,因為當時電子郵件剛發明時的時空背景沒有考慮到安全性的問題,要收發電子郵件的門檻非常的低;但是為了反制垃圾信件或是偽造信件等問題,基於SMTP之上的附加防護陸續被開發出來,本文會簡單帶過電子郵件的安全問題,至於如何設定還請各位自行精進了。

電子郵件怎麼運作?

對於這個問題,可以先到鳥哥的私房菜補充一下關於電子郵件的基本知識;這篇文章是建立於讀者已經就以下內容有初步的理解了。

看完上面那個章節之後,我已經預設你知道SMTP與DNS的關係了;接下來我會補充一些更進步的安全性設定簡介。

傳輸方面:

灰名單:

灰名單是一種策略,透過丟棄第一次送來的訊息並且記錄下來,在第二次收到時再收下。這是利用了一般垃圾郵件寄件者在第一次失敗後就不會再次嘗試的特性,而普通主機在失敗後會排入佇列稍後重新發送,缺點是要等待對方重寄,所以在收件方面會有所延遲。

TLS/SSL/STARTTLS:

對於IMAP4、SMTP、POP3的傳輸來說,預設的Port是143、25、110,都是沒有加密的傳輸協定;顯然在今日的網路環境已經非常危險了,所以在這些協定上面加上了TLS作為保護。如果你要加上TLS,你需要一張有效的憑證,之後就可以在這些協定上面加上TLS/SSL安全傳輸了。

而STARTTLS則是在更後面被提出來的協定,SSL、TLS、STARTTLS在某些場合有可能通用而導致了一些語意不清的情況發生。

TLS/SSL

TLS/SSL是提供兩台機器在網路上面通信的具體地協定。TLS是SSL的後繼者,一般情況下TLS、SSL是同義詞,除非是特指某一種版本。

STARTTLS

STARTTLS是直接將非安全連線的IMAP4、SMTP、POP3升級至安全連線的一種手段,這意味著你不必更改使用的Port,可以保持原樣;需要注意的是使用STARTTLS不意味著你必使用TLS,SSL也是選項之一。

我們造一個句子:我的電子郵件伺服器使用STARTTLS技術在25 Port提供SMTP安全連線。重點是技術這個詞,我並非使用協定來描述它。

SSL與TLS的版本

自SSL發展至TLS時,版本編號並非是連續的。自從TLS取代SSL時選用了新的本版編排方式,新增了子版本的編號(亦即會有小數點)。歷史是這樣的:SSL v2、SSL v3、TLS v1.0、TLS v1.1、TLS v1.2、TLS v1.3(最新)。

雖然現在SSL與TLS都是廣泛使用的,但是SSLv2、SSLv3已經被發現有安全性問題而逐漸淘汰,幾乎所有的軟體都支援TLS1.0;TLS1.1與TLS1.2的相容性問題主要發生在IE瀏覽器上面。

SSL/TLS與STARTTLS/未加密所用的Port:

原本每一個協定都要用一個獨立的Port,為了區分連線使用TLS/SSL加密連線,所以特別獨立選定了一些Port:

  • IMAP使用143,SSL/TLS IAMP使用993
  • POP3使用110,SSL/TLS POP3使用995
  • SMTP使用25,SSL/TLS SMTP使用465

雖然大部分使用者使用加密Port,但是為了確保相容性要多開一個Port有點浪費,這正是STARTTLS要解決的問題。

然而在用戶還沒全面升級到支援STARTTLS時就造成了問題,軟體使用未加密端口時會嘗試以未加密的方式登入,即使伺服器拒絕了要求,但是使用者未加密的帳號和密碼已經送出了。

SMTP STARTTLS並非如此順遂:

當初(SMTP發明時)SMTP被設計成傳輸郵件而非提交郵件(以前電子郵件是直接送出的,不用經過第三方伺服器),所以又額外定義了一個Port 587作為SMTP STARTTLS使用;Port 465在不久後被建議放棄使用,以促使使用者使用587進行郵件的提交。

在大部分的時候這項政策運作良好,使用587需要經由STARTLS來連線,而且一定要進行身分驗證;這讓網路管理員或是IPS可以直接封鎖25 Port來防堵垃圾郵件的氾濫。

然而結果造成了一些較舊的電子郵件客戶端仍在在使用465,而且通常這些用戶很少升級客戶端,導致無法及時淘汰465,因此它被公布成一個可選的備用端口。

驗證方面:

為了因應垃圾郵件的氾濫,網路社會制定了基於DNS的認證方式來確認這封電子郵件確實是該網域授權某台伺服器寄出的信件;而伺服器本身也有一些方式來證明這封信件確實是經過網域授權寄出的。

IP反解(PTR):

設定反解的意義在於收件者可以透過反查IP來得知網域,但是這只要有IP的控制權就可以設定了,所以除了對付因為中毒而亂寄信的電腦外,對於有計畫的垃圾郵件寄件者是沒有意義的。

而在IPv6環境,已知Google對此有額外的限制:傳送 IP 必需擁有 PTR 紀錄 (例如傳送 IP 的反向 DNS),且與透過 PTR 紀錄中指定主機名稱的轉寄 DNS 解析所接收的 IP 相符。否則,系統可能會將郵件標示為垃圾郵件或拒絕接收。

SPF:

SPF是由收件者主動進行驗證的認證,它被寫在寄件者的網域DNS上面,以前有個類型是SPF紀錄,但是最近已經被TXT紀錄取代了。

SPF可以做到的功能是告訴收件主機我允許那些”伺服器(可能是網域,也可以是IP)”寄出信件,以及若是你收到的信件沒有我的允許,我希望你如何處理,可以丟棄、退信、或特別標註該封郵件。

雖然SPF不能完全保證別人無法盜用你的寄件者身份,因為主要還是依賴收件端郵件主機的設定,但有此設定,可減低郵件伺服器寄出的郵件被誤判為垃圾信件的機會。

每個域名可以擁有一筆SPF紀錄,但是單筆SPF紀錄可以寫入很多規則。

DKIM:

DKIM是計件伺服器主動在信件標頭加入數位簽章來確認該封信件確實是由某台伺服器所寄出;DKIM是基於數位簽章的認證方式,依舊是依賴DNS,因為公鑰是經由DNS公布的。

DKIM紀錄包含一個選擇器與公鑰,選擇器的意義在於說一個網域可以有多筆紀錄,亦即多台寄件伺服器,每個簽章經由選擇器就可以驗證是否合法了。

DMARC:

無法通過SPF與DKIM的郵件會觸發DMARC政策,該政策是被用來定義回報與驗證的,一樣是寫在DNS紀錄裡面,類型是TXT紀錄。

當你的電子郵件無法通過SPF與DKIM時,伺服器會去查詢寫在DMARC裡面的聯絡手段來發送錯誤報告,讓你了解是否有人偽造你的電子郵件以及設定是否正確。

同時你也可以設定篩選的嚴格度,自監控到隔離甚至直接封鎖;此紀錄必須要先有SPF或DKIM紀錄才能工作。

DNSBL:

垃圾郵件黑名單是由一些組織所維護的一個清單,內容是垃圾郵件寄件者IP地址;收信時主機可以查詢寄件主機是否在上面來決定後續的動作。所以若是要租用SMTP服務的話可以看一下供應商提供給你的IP位置是否位於其中。

此外,所謂的IP信譽就是依靠這個來評定的,所以確保你的IP位置的純潔是非常重要的;做為網管你可以直接封鎖Port 25,同時限制只能連線到你們的郵件伺服器來避免自己的IP被玷汙。

 

內容方面:

內容防護:

主要是針對信件內容盡興安全防護之類的部分。

程式碼無效化:

有時候信件內容會含危險程式碼,此時可以透過將HTML標籤無效化的方式來避免使用者一開信件就直接被零時差漏洞攻擊。

防毒:

可以搭配clamav將收到的附件進行掃描,無論收發都要掃描,前者可以防止自己中毒,後者可以防止收件者中毒;甚者可以購買其他廠商(例如卡巴之類的)的掃描服務。

危險內容掃描:

目前有觀察到群暉科技的郵件伺服器有這項功能,會將信件內的連結pass給Google進行掃描。

寄件者認證:

本章主要的範疇在於說內容的安全性,以及認證的方面。

S/IMEI

S/IMEI與SSL/TLS相同,都是經由PKI體系來做驗證。目前Outlook與雷鳥都支援這部分的驗證,如果你收到經由S/IMEI驗證的信件的話,就可以看到封蠟的圖案,若是不支援的話就會看到內容+附件(僅簽署,未加密的狀況)。

除了驗證外,他還支援加密,若是你簽署了一封信件給對方,他就可以用你的公鑰進行加密回覆。

GPG

不同於S/IMEI的集中認證體系,GPG是另一中去中心化的加密方式,它是依靠其他人幫你的身分進行背書來增加你的身份的真實性。其加密強度非常之高,足以用來傳遞會危害你人身安全的極機密訊息,然而因為種種原因導致說入手門檻有點高,雖然有介面但是仍然沒有中文。

它可以用來加密內容與附件,但是沒辦法加密標題;此外也可以用於一般檔案的簽署與加密,很多軟體都會藉由GPG來驗證發行版本的完整性與真實性。

One Trackback

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

*
*