我运行一个通过 smtp.mailgun.org 发送电子邮件的服务器。我锁定了该服务器,只允许通过端口 587 向 smtp.mailgun.org 发送 SMTP 邮件。
此域的 IP 地址最近发生了更改,因此我的系统停止发送电子邮件。在尝试找出停止工作的原因时,我意识到在 iptables 规则中使用域名的缺点,以及 iptables 在运行规则时进行查找并在创建规则时保存 IP 地址的事实,因此域中的 IP 地址更改不会反映在 iptables 中。
从 mailgun 的状态页面来看,他们说
我们的基础设施升级将导致这些 IP 地址在未来发生更频繁的变化,客户应确保在连接到 Mailgun 服务时仅使用我们支持的主机名。
我没有收到 IP 地址变更的通知,而且我不知道将来是否会收到有关 IP 地址变更的通知。
处理这种情况的最佳方法是什么?我是否应该编写一个脚本,定期检查 smtp.mailgun.org 的 IP 地址并在其更改时更新 iptables?(我知道这样做存在安全风险,但也许值得冒这个险)。
答案1
快速查看 smtp.mailgun.org 的当前 IP 地址,可以发现它们都在 Amazon AWS 上。您应该预料到这些地址会经常更改,因此在防火墙中对它们进行硬编码充其量也是一件棘手的事情。即使使用动态脚本,您也可能会丢失外发邮件,因为 IP 地址可能会更改,并且您会尝试在下次运行脚本之前发送邮件。这称为竞争条件。除了重新设计之外,您无能为力,这就是我建议的……
至于出口防火墙,我真的不太担心到端口 587 的传出流量。所有此类流量无论如何都必须向远程邮件服务器进行身份验证,因此这对我来说不是一个大问题。对于邮件,我担心到端口 25 的传出流量;如果您使用的是 mailgun 之类的服务,则不应该有此类流量,如果有,几乎肯定是因为您受到了攻击。
您可以考虑以下一些事项:
允许任何传出的 TCP 流量到目标端口 587。如上所述,这种风险相当低,但您可以通过以下方式进一步降低风险...
使用唯一的用户 ID 运行您的 Web 应用,然后仅允许该用户 ID 向目标端口 587 发送任何传出 TCP 流量。(使用匹配
-m owner
。)这进一步降低了风险,因为规定只有 Web 应用的用户才能发起此类流量。请注意,如果您这样做,其他用户将无法建立此传出连接,甚至 root 用户也无法建立(但 root 可以更改防火墙规则以使其成为可能)。您可以使您的设置更加强壮的通过运行配置为使用 mailgun 作为智能主机的本地邮件服务器,中继它收到的所有邮件(因为它只在本地监听,所以这应该只来自你的 web 应用程序)。然后你只允许邮件服务器的用户 ID 向端口 587 进行传出连接,如上所述。这为你提供了额外的不会因为您的 Web 应用尝试发送邮件时无法访问 mailgun 而丢失邮件。如果由于网络问题、防火墙配置错误或任何其他原因导致 mailgun 无法访问,您的 Web 应用将记录错误并丢失邮件,但本地邮件服务器将对邮件进行排队并在服务恢复时发送邮件。然后,您可以将 Web 应用配置为本地发送。