在我的伺服器上檢測垃圾郵件發送者
我最近
Undelivered Mail Returned to Sender在向我的 1500 名客戶中的一位發送時事通訊時收到了一份。我的網站使用雙重選擇程序來確保使用者明確希望接收我的時事通訊。錯誤資訊：
smtp; 554 ... Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please refer to xyz.com if you feel this is in error.我收到了一個範例垃圾郵件（來自接收郵件伺服器的郵件提供商）：
Received: from mail.com ([94.130.34.42]) by smtp-27.iol.local with SMTP id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100 From: "Servizi online - Poste Italiane" <posteitaliane@test123.it> Subject: Abbiamo ricevuto una segnalazione di accredito Date: Mon, 12 Feb 2018 11:32:03 -0500提供商還表示，我的伺服器似乎被黑了。他進一步表示，“在這種情況下，收件人郵件伺服器只是記錄了連接 IP 提供給它的 rDNS
mail.com ([94.130.34.42])”——這絕對不是因為我為我的 IP 地址配置了我的 rDNS 條目 (mail.lotsearch.de)。因此，如果我正確理解 rDNS，接收郵件伺服器會查詢發件人 IP 以獲取 rDNS 條目（94.130.34.42 => 應該解析為 => mail.lotsearch.de，當我通過本地機器測試它時，它肯定會這樣做$ host 94.130.34.42）。怎麼可能欺騙 rDNS？我無法想像這在技術上是如何工作的（只有在接收郵件伺服器和我的伺服器之間的基礎設施中某處發生中間人攻擊）。
提供商還提到，“從我的 IP 連接的機器很可能已被入侵，並通過直接連接到收件人郵件伺服器（也稱為直接 MX）發送這些消息”。是什麼
direct MX意思？有人竊取或發現了我其中一個郵件帳戶的洩露郵件憑據並將其用於發送郵件？到目前為止我所做的以確保我的伺服器不是/不會被黑客入侵：
- 搜尋郵件日誌 (
var/log/mail*): 沒有什麼特別的- 檢查 ssh 登錄日誌 (
last,lastb): 沒有異常- 檢查後綴是否正在中繼：不，它沒有（通過 telnet 檢查）
- 通過 clamav 檢查惡意軟體：沒有結果
- 為 ssh、postfix 和 dovecot 安裝和配置了 fail2ban
- 為 Ubuntu 16.04 安裝了最新的更新檔/更新（我每週都這樣做）
- 檢查我的 IP 地址是否在任何黑名單上：不是
- 在我的託管服務提供商的管理控制台中驗證了 rDNS 條目：它已正確設置為
mail.lotsearch.de.- 更改所有郵件帳戶的密碼
- 更改了用於 shell 訪問的公鑰
posteitaliane@test123.it更重要的是：日誌中沒有關於的資訊。因此，如果我的伺服器被垃圾郵件發送者濫用（因為其中一個郵件帳戶的 smtp 憑據洩露），我會在日誌文件中看到這一點。我能想到的最後一種可能性是入侵者在我的伺服器上放置了我還沒有找到的惡意軟體。
如何監控外發郵件流量（每個程序和每個埠）？
僅監視傳出埠 25 將無濟於事，因為這只會擷取通過 postfix 發送的不規則郵件，而不會擷取由潛在惡意軟體感染引起的郵件流量（如果惡意軟體使用 25 以外的其他埠直接發送郵件/與收件人郵件伺服器通信） . 如果我監視所有埠上的傳出流量，我將獲得一種方法來獲取巨大的日誌文件，我無法有效地搜尋可疑活動。
編輯 - 添加了開放繼電器測試：
$ telnet mail.lotsearch.de 25 $ HELO test@test.de 250 mail.lotsearch.de $ MAIL FROM: test@test.com 250 2.1.0 Ok $ RCPT TO:<realEmail@gmail.com> 454 4.7.1 <realEmail@gmail.com>: Relay access denied編輯 - 執行 webapps
- 基於 Zend Framework 3 ( https://framework.zend.com/ )的自定義平台
- 媒體維基 ( https://www.mediawiki.org/ )
- 螳螂蟲追踪器 ( https://www.mantisbt.org/ )
在我提出我的建議之前，我想評論一下您的提供商對您說的話：
Received: from mail.com ([94.130.34.42])by smtp-27.iol.local with SMTP id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100這並不表示 94.130.34.42 的反向 DNS 是（或曾經是）mail.com。相反，它表明 SMTP 客戶端
mail.com在其HELO（或EHLO）行中發送。（配置良好的郵件伺服器會完全拒絕此連接，但那是在 Swisscom 上，而不是您…） 此行不表示任何反向 DNS 條目。如果是這樣，它就會出現在括號內。例如：Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])在這種情況下，第一個主機名是郵件伺服器在其
EHLO. 第二個主機名是建立連接時記錄的反向 DNS。RFC 5321 第 4.4 節用正式語法解釋了 Received: 行的格式。
在您的情況下，沒有記錄反向 DNS。由於您的 IP 地址有 PTR 記錄，這可能是因為他們沒有查找它，或者 DNS 臨時故障。
現在，您似乎執行了一個網路託管服務並擁有許多網路應用程序。如果其中之一遭到破壞，它可能會開始發送垃圾郵件。這些通常通過查找其 MX 記錄並連接到埠 25 來直接連接到遠端郵件伺服器，就好像它們實際上是郵件伺服器本身一樣，而不是將郵件傳遞到本地郵件假離線或埠 587 或 465 上的經過身份驗證的郵件服務就像合法的網路應用一樣。
我阻止這種情況的一種方法是實施防火牆規則，該規則阻止埠 25 上的傳出連接，除非使用者是郵件伺服器使用者。例如：
iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECTWeb 應用程序不能再將郵件直接發送到遠端 SMTP 伺服器，而必須使用本地郵件假離線或經過身份驗證的郵件服務。