在DMZ上打一个洞到一个Web服务器有多大的问题?

我们目前有我们的networking服务器在一个DMZ。 Web服务器在内部networking中看不到任何东西,但内部networking可以看到Web服务器。 在DMZ和内部networking之间的防火墙上打一个洞到内部网中的一个Web服务器有多安全? 我们正在研究一些将与我们的后台应用程序(都在一个服务器上)进行交互的东西,如果我们可以直接与持有这些数据的IBM i服务器进行通信,通过networking服务)。

从我的理解(我不知道品牌),我们有一个DMZ的防火墙,与另一个防火墙的主IP不同的外部IP。 另一个防火墙位于Web服务器和Intranet之间。

所以像这样:

Web Server <==== Firewall ===== Intranet | | | | Firewall Firewall | | | | Internet IP1 Internet IP2 

创buildDMZ中的主机的访问机制以访问受保护的networking中的主机没有任何问题,这是完成预期结果所必需的。 这样做也许不是可取的,但有时候这是完成工作的唯一方法。

关键的事情要考虑的是:

  • 限制您可以访问最特定的防火墙规则。 如果可能,请将规则中涉及的特定主机与将要使用的特定协议(TCP和/或UDP端口)一起命名。 基本上,只需要打开一个小孔就可以了。

  • 确保您正在从DMZ主机访问受保护networking上的主机,并且如果可能的话,以自动方式分析这些日志以查看exception情况。 你想知道什么时候会发生什么事情。

  • 认识到你正在将一个内部主机,即使是间接的,暴露给互联网。 留在您正在公开的软件和主机的操作系统软件本身的补丁和更新之上。

  • 考虑DMZ主机和内部主机之间的相互authentication,如果这对您的应用程序体系结构是可行的。 很高兴知道来自内部主机的请求实际上来自DMZ主机。 无论你是否可以做到这一点,都将高度依赖于你的应用程序架构。 另外,请记住,即使身份validation正在进行(因为他们实际上是DMZ主机),“拥有”DMZ主机的人也能够向内部主机发出请求。

  • 如果担心DoS攻击,请考虑使用速率限制来防止DMZ主机耗尽内部主机的资源。

  • 您可能需要考虑使用第7层“防火墙”方法,即将来自DMZ主机的请求首先传递给可以“清理”请求的特殊用途的内部主机,然后进行完整性检查,然后将其传递给“真正”的后端主机。 由于您正在讨论在IBM iSeries上与后台应用程序的接口,所以我猜测您对iSeries本身的传入请求执行完整性检查的能力有限。

如果你以一种有条不紊的方式来处理这个问题,并保持一些常识,那么在保持风险最小化的同时,你没有理由不能做你正在描述的内容。

坦率地说,你有一个不受限制地访问受保护networking的DMZ,可以让你跨越很多我见过的networking。 对于一些人来说,DMZ似乎只是意味着“防火墙上的另一个接口,可能带有一些不同的RFC 1918地址,基本上不受限制地访问Internet 受保护的networking”。 尝试并尽可能locking您的DMZ,同时仍然可以实现业务目标,而且您会做得很好。

显然有一些危险,但你可以做到。 基本上你打开了一个有人可以进入的针孔,所以把它做成很小。 将其限制在任一端的服务器上,并只允许所选端口上的数据。 使用端口地址转换来使用奇怪的端口是一个不错的主意。 但是,朦胧的安全性根本就不是安全的。 确保无论在另一端的服务器是否有某种方式来检查通过该连接的信息是真正的看起来是什么…或者至less有某种情境感知防火墙的地方。 此外,还有一些防火墙是为这种事情做的…我知道microsoft ISA为OWA和Exchange服务器做同样的事情。