我最近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" <[email protected]>
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
):没什么异常 - 检查 postfix 是否进行中继:否(通过 telnet 检查)
- 通过 clamav 检查恶意软件:无结果
- 为 ssh、postfix 和 dovecot 安装并配置 fail2ban
- 安装了 Ubuntu 16.04 的最新补丁/更新(我每周都这样做)
- 检查我的 IP 地址是否在任何黑名单中:没有。
- 在我的托管服务提供商的管理控制台中验证了 rDNS 条目:它已正确设置为
mail.lotsearch.de
。 - 更改所有邮件账户的密码
- 更改了用于 shell 访问的公钥
更重要的是:日志中没有相关信息[email protected]
。因此,如果我的服务器被垃圾邮件发送者滥用(例如,由于某个邮件帐户的 smtp 凭据泄露),我会在日志文件中看到这一点。
我能想到的最后一种可能性是,入侵者在我的服务器上放置了恶意软件,但我还没有发现。
如何监控传出的邮件流量(每个进程和每个端口)?
仅监控传出端口 25 不会有帮助,因为这只会捕获通过 postfix 发送的不规则邮件,而不会捕获由潜在恶意软件感染引起的邮件流量(如果恶意软件使用 25 以外的其他端口直接发送邮件/与收件人邮件服务器通信)。如果我监控所有端口上的传出流量,我将得到一个巨大的日志文件,我无法有效地在其中搜索可疑活动。
编辑-添加开放中继测试:
$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied
编辑-运行 web 应用程序
- 基于 Zend Framework 3 的定制平台(https://framework.zend.com/)
- 维基百科 (https://www.mediawiki.org/)
- Mantis 漏洞追踪器 (https://www.mantisbt.org/)
答案1
在我提出建议之前,我想对您的提供商对您说的话发表一些评论:
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 REJECT
Web 应用程序不能再将邮件直接发送到远程 SMTP 服务器,而必须使用本地邮件池或经过身份验证的邮件服务。
答案2
在当今时代,尝试建立自己的邮件服务器在很大程度上是一场失败的战斗,您最好找到一个负担得起的服务。话虽如此……
查看发送到屏蔽您的提供商的日志,看看是否能发现任何可疑内容。有可能,而且经常发生,有人忘记他们订阅了您的新闻通讯并将您标记为垃圾邮件。然后根据提供商的不同,您可能会被列入提供商的黑名单,即使您没有做错任何事。
将所有其他电子邮件中的群发邮件分成两个服务器。
至少保存几周的日志,最好保存几个月。这样每当有事情发生时你都可以进行研究。
每天检查您的日志,查看任何提供商的类似情况,并每天或更快地进行调查。一旦您被阻止,如果您继续尝试发送,情况可能会变得更糟。您可能会从临时阻止变成永久阻止……甚至被报告到黑名单。
不确定他们是如何实现的,但我知道许多提供商为出站邮件服务做的一件事是,提供商/IP 阻止电子邮件后,就不会再尝试发送其他电子邮件。理想情况下,你想要这样的事情。因为第二封邮件被阻止了,发送更多邮件只会加剧问题。