重要更新
在处理此事时，一天多来都没有转发过垃圾邮件，所以我把它留在那里，一夜之间，两封电子邮件就转发了！确认！
以下是我的 tail / grep 命令的结果（具体内容如下）：
Feb 13 02:30:01 fs1 postfix/smtp[749779]: 1442CBE4C12: to=<[email protected]>, relay=mail.s1.alexdf.ru[82.202.199.173]:25, delay=3.4, delays=0.03/0.06/2.4/0.84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A8D104D1D)
Feb 13 06:22:24 fs1 postfix/smtp[793411]: 8702BBE4C12: to=<[email protected]>, relay=mail.s2.alexdf.ru[188.68.206.204]:25, delay=3, delays=0.03/0.06/2.2/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAD424D20)
所以我又把它关掉了。下面是进一步的更新。
背景
这个问题的背景比较长，因为有问题的服务器已经存在了很长时间，我不会在这个问题上深入讨论，但我要讨论一个正常工作的系统是如何被搞砸的，以及到目前为止已经做了哪些工作可以在这里找到。
值得注意的是当垃圾邮件破解者说服系统中继邮件时，我们认为它的配置与以前大致相同，并nmap报告它不是开放中继！然而，正如另一个页面上所记录的那样，几天后，系统发送了数十万封中继垃圾邮件！
关于已经提出的其他问题，
第一个问题是询问如何阻止它成为一个开放中继，简而言之，只需Postfix这样配置：
default_transport = error: This server is presently not sending email
（当然，选择您自己的信息 - 这实际上不是我们的，但在这里，我很有礼貌。）
第二个问题我如何确定它是否已修复？如果没有，如何快速修复它？，并且它有一个可能是正确的答案，但我觉得我不能相信。这里不是测试网站；问题在于这两个包之间的交互，因为它涉及到用作开放中继、关闭它以及将服务返回给有效用户，即使标准（尽管简单/过于简单）测试（例如来自nmap）表明它不是一个开放中继 - 而且我们从未见过这种情况。
当然，postfix 和 dovecot 安全相关设置都是相互关联的，但是，我们从 20 世纪 90 年代末开始在这个系统上使用这两个软件包（当然会根据需要进行更新），这些年来，我亲自设置并维护了它们，更新、调整等。但这并不意味着我一直全部随着时间的推移，了解变化并了解所有漏洞是什么，等等。例如，直到最近我才知道 v 2.1 中的分叉，其中将smtpd_recipient_restrictions中继问题拆分为smtpd_relay_restrictions。但是，我确实已经阅读了目前的绝大多数官方材料。（我发现其中一些内容似乎相互矛盾和/或不清楚，但这是理所当然的。）
了解一下这些信息可能会有所帮助，原始安装必须在 1 月底（不到一个月前）从头开始重建到相同的操作系统版本，并且在此之前不久，它已经获得更新但尚未重新启动。因此，在 2023 年 1 月 19 日开始发生这种情况时，我们正在使用旧设置，在恢复后，我们意外地获得了默认的 Dovecot 配置，并且很困惑为什么我们必须对其进行大量破解才能让使用 Dovecot 的用户（主要是外部用户）连接（尽管在垃圾邮件发送者找到我们之前，我甚至不确定这是否完全有效）。
值得指出的是，垃圾邮件发送者似乎在我们入侵 Dovecot 的 Auth 部分以使我们的远程用户连接大约一天后就破解了我们，这也是在系统恢复接收电子邮件大约两天后。为了阻止垃圾邮件，我们尽快删除了远程用户，但此后有效的远程连接从未起作用。尽管我们认为后来配置得更好。现在的一个关键目标是让我们的远程用户连接再次正常工作，而无需再次使其成为开放中继！（当然，这是假设它目前实际上不是一个开放的中继，但我们认为我们已经修复了这个问题几次，但他们又回来了！）
当前版本为：
- Fedora Server v 37 更新于 2023 年 1 月 20 日左右
- 内核 6.0.7-301.fc37.x86_64
- postfix-3.7.3-1.fc37.x86_64
- dovecot-2.3.20-1.fc37.x86_64
相关但辅助的问题
虽然这严格来说不属于既定目标的一部分，但我有点太分心了，除了考虑这些之外什么都做不了：我当然想知道如何限制出站错误消息以免发送任何断开连接的原因 - 本地日志就足够了，谢谢！他们不需要知道有“没有这样的用户”等等，但邮箱满了也没关系。我还想知道如何永久禁止某些 IP 地址，仅基于我自己对试图破解我/我们的系统的 IP 地址的观察。例如，任何来自美国以外的 IP 地址都不能作为用户有效连接，事实上，有效用户列表很短（尽管我不知道确切的数字，而且由于大多数 ISP 会更改 IP 地址，因此IPs我实际上无法知道有效用户的确切数量）。IPs
当前配置
在已经引用的问题页面中，有人说他们认为这是“被盗凭证”，因此ALL the credentials were replaced由于我们错误地没有记录身份验证（现在我们记录了所有内容！），并且不知道可能使用了什么凭证。所以，实施了强力、不信任的政策。所述授权材料的内容显然超出了这里应该分享的范围。
在谈论所有这些价值观之前，值得一提的是，在撰写本文时，所有imap/ imaps/ pop3/pop3s连接均不起作用。它们已启动并接受连接，但有效用户无法通过，因此必须尽快修复。
关于这两个包现在对配置的看法，我使用了：postconf -f > file postconf -Ff > file和doveconf -n > file
总内容大约有 1404 行！当然，太多了，无法在这里发布。仅 的postfix“主要”条目就包含 1043 行，但是我发现了迄今为止我未知的命令LANG=C comm -23 <(postconf -n) <(postconf -d) > file，它做得非常出色，只返回了postconf不在“默认编译”中的主条目，只有 42 行！所以...
我仔细检查了所有内容，并选出了这里看起来合适的内容 - 如果需要更多内容，请告诉我。首先按顺序介绍 Postfix 的主要配置：
milter_default_action = accept
mydestination = $myhostname,
localhost.$mydomain,
localhost,
...60 more...
mynetworks = explicit list of IPs, no ranges
relay_domains = $mydestination,
...and most of the internal box IPs...
smtp_tls_security_level = may
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
check_helo_access hash:/etc/postfix/helo_access,
reject_invalid_helo_hostname,
reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unauth_destination,
check_sender_access hash:/etc/postfix/sender_access,
check_client_access hash:/etc/postfix/pop-before-smtp,
permit_mynetworks
smtpd_relay_restrictions = permit_mynetworks,
reject_unauth_pipelining,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_sender_access hash:/etc/postfix/sender_access,
check_client_access hash:/etc/postfix/pop-before-smtp,
permit_sasl_authenticated,
defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
permit_sasl_authenticated,
reject_unlisted_sender,
check_client_access hash:/etc/postfix/pop-before-smtp
smtpd_tls_security_level = may
接下来是Postfix的主配置。在仔细检查后，我发现可人工编辑的配置更容易理解！此外，几乎所有配置都是默认的，我删除了除 之外的所有内容smtp，以设置一个熟悉的模式，因此：
smtp inet n - n - - smtpd
submission inet n - n - - smtpd -o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes
policyd-spf unix - n n - 0 spawn user=policyd-spf
argv=/usr/libexec/postfix/policyd-spf
然后，Dovecot。我的感觉是，这就是“所有问题所在”，但除非上面的命令没有输出关键内容，否则它看起来很干净？！... 与 一样Postfix，我剔除了看似不相关的部分，使这个问题更容易处理。它在这里：
passdb {
args = scheme=cram-md5 /somefile
driver = passwd-file
}
passdb {
args = /anEMPTYfile (not using it yet)
driver = passwd-file
master = yes
pass = yes
}
service auth - matches postfix
service imap-login {
inet_listener imaps {
port = 993
ssl = yes
}
}
service pop3-login {
inet_listener pop3s {
port = 995
ssl = yes
}
}
service submission-login {
inet_listener submission {
port = 587
}
}
ssl = required
certs, including our virtual domains, omitted
我现在的看法是，最可能的问题是 Postfix 中的许可和拒绝的顺序。我很快会（再）更仔细地检查一遍。
正在进行的测试和结果
当然，下一步是让用户在监控的同时进行连接，看看是否还有垃圾邮件通过。关于垃圾邮件发送者监控，我使用的是：
watch -n 1 -p -b qshape
和：
tail -f /var/log/maillog | grep 'status=sent' | grep 'relay=' | grep -v 'relay=local'
如果有更好的方法，欢迎分享！同时：
测试结果：
结果 1
我们用新的“全部跟踪”配置测试了内部和外部的有效用户尝试，结果产生了“堆积如山”的材料。但是，当使用已知的错误密码时，我们会收到一条明确的消息，而当使用正确的密码时，我们不会收到任何确认，并且 Dovecotimap-login: Login: user=每次连接尝试都会重复几次，没有任何解释为什么我发现了这一点？！很奇怪！
这似乎是从所述imap-login消息开始的，其中包括正确的用户、方法，rip并且提供了lip我认为的会话 ID。TLS
下一条相关消息说，Added userdb setting: plugin/=yes嗯......我不知道这是否意味着我应该包含一些配置细节，但它知道要添加或什么。
连接不成功。继续...
结果 2
我注意到没有声明 userdb，此时，我已经尝试返回到整个较旧的配置树，我认为它（暂时）不需要（因为我们还没有使用虚拟用户，但希望今年能实现），但是，Dovecot 并没有明显拒绝使用有效密码的连接（就像它对已知错误密码所做的那样），所以我想知道他们是否确实通过了，然后没有用户目录或类似的东西。所以，我尝试使用示例语法。
Dovecot 拒绝重新启动，因此我将其删除，但是你可以在这里找到我改编的模板。
结果 3
正如目前在最顶部强调的那样，为了强调：由于服务器运行了一天多，相对没有变化，并且没有看到转发，我决定在一夜之间信任它，回到电脑前，我发现有两个已经通过了。...这些条目由我上面提到的日志跟踪 tail / grep 命令突出显示：
Feb 13 02:30:01 fs1 postfix/smtp[749779]: 1442CBE4C12: to=<[email protected]>, relay=mail.s1.alexdf.ru[82.202.199.173]:25, delay=3.4, delays=0.03/0.06/2.4/0.84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A8D104D1D)
Feb 13 06:22:24 fs1 postfix/smtp[793411]: 8702BBE4C12: to=<[email protected]>, relay=mail.s2.alexdf.ru[188.68.206.204]:25, delay=3, delays=0.03/0.06/2.2/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAD424D20)
我立即停止了 Postfix 和 Dovecot。我远不是这种分析的专家，但我知道如何运行 grep！我推测对于第一个，我想关注 1442CBE4C12 和/或 A8D104D1D，对于第二个，我想关注 8702BBE4C12 和/或 DAD424D20。分析开始...
我只从日志中得到了输出，而队列中什么也没有——它们显然是空的。（我不得不重新打开邮件来检查队列，这让我很惊讶，所以我先关闭了发送功能！
首先：
Feb 13 02:29:58 fs1 postfix/cleanup[749650]: 1442CBE4C12: message-id=<[email protected]>
Feb 13 02:29:58 fs1 postfix/bounce[749778]: 6248FBE48BE: sender non-delivery notification: 1442CBE4C12
Feb 13 02:29:58 fs1 postfix/qmgr[644284]: 1442CBE4C12: from=<>, size=49321, nrcpt=1 (queue active)
Feb 13 02:30:01 fs1 postfix/smtp[749779]: 1442CBE4C12: to=<[email protected]>, relay=mail.s1.alexdf.ru[82.202.199.173]:25, delay=3.4, delays=0.03/0.06/2.4/0.84, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as A8D104D1D)
Feb 13 02:30:01 fs1 postfix/qmgr[644284]: 1442CBE4C12: removed
第二：
Feb 13 06:22:21 fs1 postfix/cleanup[793292]: 8702BBE4C12: message-id=<[email protected]>
Feb 13 06:22:21 fs1 postfix/bounce[793410]: CFFC7BE41DA: sender non-delivery notification: 8702BBE4C12
Feb 13 06:22:21 fs1 postfix/qmgr[644284]: 8702BBE4C12: from=<>, size=49321, nrcpt=1 (queue active)
Feb 13 06:22:24 fs1 postfix/smtp[793411]: 8702BBE4C12: to=<[email protected]>, relay=mail.s2.alexdf.ru[188.68.206.204]:25, delay=3, delays=0.03/0.06/2.2/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAD424D20)
Feb 13 06:22:24 fs1 postfix/qmgr[644284]: 8702BBE4C12: removed
这对于查明垃圾邮件发送者是如何做到这一点毫无用处！
答案1
天啊，这太痛苦了！然而我发现：
一些重要细节
这些并不容易实现……
第一的
我确信这个系统不是官方的公开邮件中继系统，尽管确实有中继，但我会尝试确认这一点。（更多内容见下文。）
第二
关于参数，我错了，没有人纠正我default_transport Postfix；设置后，它会阻止除正在运行的系统之外的所有入站和出站on（“ localhost”）。（这仅适用于 from 和 to on localhost。）
此外，default_transport设置后，也会切换到硬拒绝代码550，因此不应再尝试。因此，像我之前建议的那样使用它有点危险。（我没有尝试用来缓解它soft_bounce，但那可能会起作用，但是，它覆盖了我的其他错误代码设置，unknown_local_recipient_reject_code = 450所以请进行测试以确保万无一失。）
第三
阻止所有发送但允许接收的“方法”是使用两个都自 Postfix v 2.1 以来，和分为了两对smtpd_relay_restrictions，smtpd_recipient_restrictions同时还要注意，关于“向后兼容性”的文档相当令人困惑——我并不是唯一一个在这个领域工作了几十年的人，我暂停了这项工作，并决定唯一的方法不仅是理解文档，而且理解这两个参数的唯一方法是探究实际行为。……对于那些以任何专业形式从事此类工作的人来说，这是一个重要的教训：文档经常是错误或令人困惑的，人们对事实并非如此的事情过于确定，而这种真理的唯一真正仲裁者是软件的实际行为。
第四
我被大量收到的垃圾邮件所欺骗，因此错误地认为电子邮件接收仍然正常，而Postfix事实上我拒绝了所有遵循通常规则的收到的邮件。
我仍然不确定它是如何在普通电子邮件无法进入的情况下进入的，但它不是普通的垃圾邮件，例如，没有from 或return-path地址，我们只是在日志中得到了没有内容的打开和关闭尖括号。
我也不清楚如何防止接收，但可靠的SpamAssassin安装应该可以解决问题。
第五
我们时不时会收到以下信息：
Feb 18 01:42:58 <our_server> postfix/smtp[2188531]: 2B647BE41F6: to=<[email protected]>, relay=mail.s1.alexdf.ru[5.53.127.107]:25, delay=4.2, delays=0.06/0.06/2.1/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 806D64DA7)
Feb 18 08:57:36 <our_server> postfix/smtp[2270044]: 4E1F2BE41F7: to=<[email protected]>, relay=mail.s1.alexdf.ru[188.68.219.83]:25, delay=3.4, delays=0.03/0.06/2.5/0.8, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as F01A54DDC)
每次的模式都差不多，只是有一些细微的变化，所以我认为这些是在试探他们是否可以再次利用系统。当default_transport设置为非空值时，这些是永远不会出现的，所以它们应该能够以某种方式被阻止，如上所述。我试图明确拒绝这些，但这是一个即时解决方案！
结论
虽然我从未找到真正的原因或解决方案，但我仍在寻找它，如果我找到一个，我一定会更新这个答案。但是，我认为这里有足够的信息对其他人有用，例如知道你可以关闭它，但default_transport仍然会收到垃圾邮件。这确实是一件奇怪的事情！