Security

評估執行自己的電子郵件伺服器的安全問題

  • December 15, 2016

我在一個小型研究中心工作,該中心必須在預算緊張的情況下獨立管理很多事情。其中之一是所有 IT 基礎設施,包括 Web 和電子郵件託管。雖然我還沒有成為系統管理員,但到目前為止,我已經成功地在一家託管公司找到了負擔得起的根伺服器,設置了我們的網站和 Web 應用程序,並讓它們執行了幾年。

到目前為止,我們的電子郵件是在外部託管的,這意味著我們付出很少的代價:最大 875Mb 的電子郵件儲存空間。35 個 POP 郵箱。由於電子郵件客戶端中的本地收件箱損壞導致幾次數據失去後,我決定至少調查使用我們正在僱用的根伺服器上存在的 postfix / qmail 郵件伺服器的選項。乍一看,有很多優點:我們可以切換到幾乎無限的 IMAP 帳戶,將電子郵件包含在伺服器備份中的電子郵件帳戶中,每個郵箱使用更多儲存空間等等。最重要的是,郵件伺服器已經包含在我們為網路伺服器支付的費用中,因此我們可以降低外部電子郵件託管成本,甚至可以以更少的成本獲得更多。

技術部分已經足夠有趣了:我已經能夠進行所有設置(發現 Plesk 面板的優點)並且原則上我們可以立即切換到新的電子郵件伺服器。然而,我不確定我能否正確估計管理電子郵件伺服器所涉及的風險,安全方面。當然,我在所有電子郵件帳戶上啟用了 SpamAssassin 和防病毒(Plesk Premium 防病毒),設置了 SSH 證書並將 SPF、DMARC 和 DKIM 記錄添加到我們的 DNS。我主要擔心的是:這是否足夠,受到攻擊並使整個伺服器受損的可能性有多大?

例如,我注意到即使在這個過早的測試階段,QMail 日誌中也充滿瞭如下消息:

Dec 15 17:07:00 server4545 postfix/smtpd[23838]: connect from unknown[91.200.13.5]
Dec 15 17:07:00 server4545 plesk_saslauthd[24512]: Invalid mail address 'albert@'
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: warning: unknown[91.200.13.5]: SASL LOGIN authentication failed: authentication failure
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: lost connection after AUTH from unknown[91.200.13.5]
Dec 15 17:07:00 server4545 postfix/smtpd[23838]: disconnect from unknown[91.200.13.5]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: connect from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: lost connection after CONNECT from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:04 server4545 postfix/smtpd[23838]: disconnect from 24-35-233-74.fidnet.com[24.35.233.74]
Dec 15 17:07:20 server4545 postfix/smtpd[23838]: warning: hostname ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.172.216: Name or service not known
Dec 15 17:07:20 server4545 postfix/smtpd[23838]: connect from unknown[118.71.172.216]
Dec 15 17:07:22 server4545 postfix/smtpd[23838]: NOQUEUE: reject: RCPT from unknown[118.71.172.216]: 554 5.7.1 <name@ourdomain.com>: Relay access denied; from=<voicemailandfax@jgnluxwatch.com> to=<name@ourdomain.com> proto=ESMTP helo=<[100.74.205.159]>
Dec 15 17:07:22 server4545 postfix/smtpd[23838]: disconnect from unknown[118.71.172.216]
Dec 15 17:07:22 server4545 /usr/lib/plesk-9.0/psa-pc-remote[8577]: Message aborted.
Dec 15 17:07:22 server4545 /usr/lib/plesk-9.0/psa-pc-remote[8577]: Message aborted.

這似乎表明完全不相關的 IP 地址引起了人們的極大興趣,即使我目前甚至沒有使用該東西進行測試。好的部分似乎是這些嘗試被認可和拒絕,但我仍然想知道它們來自哪里以及我應該擔心多少。即使他們是無辜的,我可以想像處理所有這些請求可能會給伺服器帶來嚴重的成本。出於測試目的,我在我們的 DNS 中添加了一個低優先級的 MX 記錄;我想知道這是否已經向我們的郵件伺服器“邀請”了這麼多請求?

換句話說:我正在尋找關於執行自己的郵件伺服器所涉及的安全風險的合理建議。畢竟,如果事情破裂,他們可能會破壞一切,我將不得不自己處理。

任何建議將不勝感激!

羅恩

作為一名後來成為滲透測試員的前管理員,我感受到了你的痛苦。然而事實證明,就像你看起來的那樣,我非常關心我的系統的安全性,以找出 DKIM 和 SPF 之類的東西,並實施它們,並使用 SSH 密鑰等。事實證明,我做的最多事情對了。聽起來你是;-)

從您的日誌來看,您看起來不像,但最重要的事情之一是確保您沒有執行開放中繼。以下連結應允許您測試:http: //mxtoolbox.com/diagnostic.aspx

您還需要防止使用者列舉。您不希望攻擊者能夠登錄到您的 SMTP 伺服器並執行以下操作:“VRFY bob”或“EXPN joe”並讓郵件伺服器回復告訴您系統上是否存在 joe。可以將郵件伺服器配置為不支持這些功能。您也不希望郵件伺服器響應“MAIL TO: tom”來立即告訴您 tom 存在。你明白了。查看 smtp/pop3/imap 使用者列舉並緩解它。

另一件事 - 不要使用沒有加密的 pop3 或 imap。密碼將以明文形式在網際網路上傳輸 - Wifi 通常也很容易被黑客入侵,這將立即將憑據洩露給未加密的郵件服務。您需要傳輸層安全性 (TLS)。

與 SMTP 類似,您希望對發送郵件的遠端使用者進行身份驗證,但這也必須通過 TLS 連接發送。另外,不要忘記要求本地使用者發送郵件的身份驗證,並防止內部開放中繼。我最近在一家律師事務所進行了一項滲透測試,我可以通過 25 埠遠端登錄到他們的郵件伺服器,並從公司負責人向員工發送郵件,告訴他他加薪或被解僱。顯然我也沒有這樣做,但你不想允許這種可能性。如果可能,最好有不可否認性。

很明顯,您很擅長為自己尋找東西,我不會詳細介紹,但我只想說 - 您需要了解 POP3S 和 POP3 與 STARTTLS 之類的相對優點,埠 25 之間的區別, 465, 587 等 IMAP 和 IMAPS 等。要求客戶端 TLS 證書進行身份驗證可能是最重要的,但不要使用自簽名的伺服器 TLS 證書,你應該得到真正的證書。你可以從 go-daddy 或類似的地方買到便宜的。不要使用 SSL2、SSL3 或 TLSv1.0。如果可能,應該啟用 TLSv1.2。

此外,將您的郵件伺服器配置為在您連接到埠時不要公佈其軟體版本(或任何產品詳細資訊,如果可能)。一個簡單的通用橫幅就足夠了。

要求您的使用者和管理員提供強密碼!

還有一件事,為了避免垃圾郵件,如果配置正確,灰名單可以很好地工作。我用了很長時間,從來沒有遇到過郵件未送達的問題。

網際網路上的機器總是被掃描和戳。如果您已經安全地配置了它,那麼我不會太擔心(儘管如果您擔心 DoS,您可以使用 iptables 速率限制 - 或與您的 ISP 交談),但在 PLESK 等控制面板方面和SSH,使用 iptables 將需要訪問這些埠的 IP 列入白名單,這樣攻擊者甚至看不到它們的存在。在您的伺服器上使用 nmap 來查看攻擊者會看到什麼。如果除您的郵件埠之外的所有埠都向公眾過濾,那麼很好。只使用 HTTPS,而不是 HTTP 來連接到 Web 管理的東西,同樣,只使用 TLSv1.2。或者更好的是,讓它只在 localhost 上監聽,這樣它就無法從外部訪問,然後使用 SSH 埠轉發來連接它!

Google為您正在使用的每個軟體項目“伺服器強化 PRODUCTNAME”,“滲透測試 PRODUCTNAME”,“PRODUCTNAME 漏洞利用”可能會有所幫助。

非常重要 - 盡可能保持所有軟體和 linux 作業系統的更新檔和最新。

一個經常被忽視的風險是您自己的工作站受到損害的風險。作為管理員,您是主要目標。如果發生這種情況,那麼攻擊者可能會竊取您的密碼或 SSH 密鑰並找到您的文件,這些文件將告訴他們他們需要了解的有關您的配置的所有資訊。一旦他們擁有了它,那麼無論您如何保護它,他們都可以進入您的郵件系統,即使它是一個託管的 Office 365 解決方案。事實上,在某些方面,如果它託管在其他地方並且配置更熟悉,對他們來說會更容易。

除非需要,否則不要以 root 或管理員身份登錄您的電腦。不要向您的同事提供超出他們需要的訪問權限。等等。打開電子郵件附件等時要非常小心——通常的東西。

引用自:https://serverfault.com/questions/820981