将 IMAP 服务器暴露给 Internet:DMZ 还是端口转发?

Fix*_*ker 6 dmz reverse-proxy port-forwarding imap

我们目前将所有电子邮件存储在我们内部网络的 Dovecot IMAP 服务器上。网络上的客户端机器能够连接和访问他们的电子邮件。

现在我们希望允许某些用户能够使用 IMAP 从外部连接并查看他们的电子邮件。我们目前有一个带有专用(未使用)DMZ 端口的防火墙/路由器。在我看来,我们有两种选择:

  1. 在路由器上设置端口转发,将端口 585 或 993 上的任何 IMAP 请求转发到服务器;然后服务器可以验证用户。
  2. 将反向代理 IMAP 服务器附加到路由器的 DMZ;这反过来可以将 IMAP 请求转发到内部网络上的服务器(在这样做之前可以选择验证用户名)。

有没有人对这两种方法的优点有任何建议/意见?

我发现很难想到在三足防火墙的 DMZ 中拥有额外的反向代理有什么读取优势,因为无论如何它几乎只是有效地进行端口转发。......或者我错过了什么?

Eva*_*son 4

将 IMAP 从 Internet 端口转发到 LAN 意味着添加相当有选择性的转发规则。您不会在服务器端发生诸如动态端口分配之类的丑陋事情(就像使用 FTP 或 MSRPC 等协议那样)。在我看来,与 LAN 的接触是最小的。您依靠 IMAP 服务器上的 IP 堆栈不做任何愚蠢的事情(因为您向服务器提供未经请求的入站 IP 访问),并且您依靠 IMAP 服务器软件本身不做任何愚蠢的事情。

在您描述的 DMZ 场景中,您限制了 IMAP 服务器与 Internet 的直接 IP 连接,并且限制了 IMAP 服务器执行愚蠢操作可能使您面临风险的程度。您用直接 IP 连接到 IMAP 服务器的风险来换取直接 IP 连接到 IMAP 代理服务器的风险,并且您依赖 IMAP 代理服务器软件不会做任何愚蠢的事情。在这种情况下,IMAP 服务器中的漏洞仍然有可能通过 IMAP 代理被利用,具体取决于 IMAP 代理的“状态”程度以及它执行的“健全性检查”程度。

在我看来,DMZ 方法增加了移动部件和复杂性,但没有增加太多真正的安全性。我认为您最好将端口转发到 LAN,并使用您在 DMZ/IMAP 代理方法上花费的精力,确保您有良好的 IMAP 服务器日志记录、密码/锁定策略抵御强力密码破解,以及警报机制,让您知道是否看到 IMAP 服务器的意外流量(“从未见过”分析)。