postfix 可以在 permit_sasl_authenticated 之前强制执行 rejection_unknown_helo_hostname 吗?

postfix 可以在 permit_sasl_authenticated 之前强制执行 rejection_unknown_helo_hostname 吗?

我有一个正常工作的 postfix 3.5 中继,其配置包括:

smtpd_client_restrictions = permit_mynetworks,
    reject_unknown_client_hostname,
    permit
smtpd_helo_required=yes
smtpd_helo_restrictions = reject_unknown_helo_hostname
    reject_invalid_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks, 
    permit_sasl_authenticated
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
    reject_unauth_destination

我在日志中看到频繁的身份验证尝试:

2 月 23 日 16:53:02 m.example.com postfix/smtpd[30155]: 从未知 [196.190.41.137] 连接
2 月 23 日 16:53:17 m.example.com postfix/smtpd[30155]: 警告:未知 [196.190.41.137]:SASL LOGIN 认证失败:认证失败
2 月 23 日 16:53:19 m.example.com postfix/smtpd[30155]: 经过来自未知 [196.190.41.137] 的 AUTH 后失去连接
2 月 23 日 16:53:19 m.example.com postfix/smtpd[30155]: 断开与未知 [196.190.41.137] 的连接 ehlo=2 starttls=1 auth=0/1 command=3/4

我原本希望它能reject_unknown_helo_hostname立即拒绝,但它似乎允许他们尝试 SASL 登录。虽然我认为我的 saslauth 相当安全,但我更希望他们甚至不能尝试。

有没有办法让“未知”主机名更早被拒绝?这样可以阻止 90% 的登录尝试,因为这个不断尝试相同登录的僵尸网络中的大多数主机名都是未知的。

我的配置中是否存在太过宽松的东西,以至于他们总是可以进入 saslauth 步骤?

各种 SMTP 访问限制按照什么顺序应用?

编辑:Wireshark 显示最近一次 SASL 登录验证失败导致此消息启动会话:

EHLO [182.150.23.17]

那么为什么在发生这种情况之前没有被拒绝:

2 月 23 日 23:49:42 m.example.com postfix/smtpd[42557]: 警告:未知[182.150.23.17]: SASL LOGIN 身份验证失败:身份验证失败

答案1

根据我自己的观察和测试,以及类似的观察https://mailing.postfix.users.narkive.com/AheRlxjc/blocking-access-before-sasl似乎在服务器应用各种smtpd_xxx_restrictions规则之前,SMTP 客户端被允许尝试 SASL 身份验证。

来自上面的链接:

似乎“smtpd_client_restrictions”是在 SASL 完成后运行的。它按预期工作并禁止用户发送消息(甚至返回我自定义的 REJECT 原因),但告诉机器人 AUTH 已成功,因此他们可以从另一个 IP 再次尝试。

因此,连接的客户端可以启动 AUTH 步骤,并得到一个响应,告诉他们它是否有效(这意味着攻击者将知道他们是否成功猜出了密码!)服务器决定是否应出于任何原因拒绝该连接。拒绝原因可能是客户端未发送有效主机名,或位于阻止的地址范围内,或因为他们未通过 SASL 身份验证。但这些情况和拒绝发生在尝试进行身份验证之后。

这种行为可能是故意的SMTP 访问限制列表的评估延迟。我会试验使用 是否smtpd_delay_reject=no会改变行为,尽管有记录显示这会给某些客户端带来问题。可能是我不关心这些客户端,因为有缺陷的 smtp 客户端可能就是垃圾邮件机器人。

上面链接的建议是使用后筛选过滤掉垃圾邮件发送者。我想我也会研究一下。

编辑:使用smtpd_delay_reject=no似乎确实能得到预期的结果。具有无效主机名的客户端现在会立即被拒绝,甚至在它们能够协商 TLS 会话或尝试进行身份验证之前。我的日志现在显示:

postfix/smtpd[64594]: NOQUEUE: 拒绝: 来自未知的连接[45.88.90.174]: 450 4.7.25 客户端主机被拒绝:找不到您的主机名,[45.88.90.174]; proto=SMTP

我怀疑过去没有看到此类错误的原因是,试图强行破解我的 SASL 身份验证的垃圾邮件机器人在登录失败后立即断开连接,因此它们没有停留足够长的时间来被拒绝。这似乎与上面问题中显示的日志一致,在登录失败后连接断开:

2 月 23 日 16:53:19 m.example.com postfix/smtpd[30155]: 来自未知 [196.190.41.137] 的 AUTH 后失去连接

因此,我没有看到reject基于无效/未知客户端主机名的预期日志的原因是因为客户端是坏人,甚至没有等待足够长的时间就被拒绝。

相关内容