我试图设置通常的事情，使用包含可以从互联网访问的服务器的DMZ和尽可能安全的局域网。
我碰巧在build筑上也有完全的自由。 鉴于我想让我的局域网尽可能地安全，我自己对自己说：“有什么能比从DMZ无法访问局域网更好”。 为此，我将configuration防火墙以阻止在DMZ-> LAN方向上的任何传入连接。
当然，我仍然需要我的前端应用程序在DMZ中联系受信任的局域网服务器。 为了使这成为可能，我想只允许在LAN-> DMZ方向build立连接。
这意味着，在通常情况下，我的信任LAN服务将连接到不受信任的DMZ前端服务器。 一旦build立了TCP连接，两个端点之间的所有请求和响应将在该连接上复用。
这在安全方面是一个好主意吗？ 还有什么我可以做我的局域网服务器更难达到？ 你有没有听说别人已经这样保护自己的局域网？ 难道让我觉得这是一个愚蠢的想法吗？
好的，尽量减lessDMZ和局域网之间的连接是一个很好的经验法则，尽pipe我不会成为这个想法的奴隶（如果你有现场的电子邮件服务器，那么你的电子邮件服务将是有趣的，如果你强迫它遵守你的想法）。
另外，不要认为这是一个神奇的黑客防御。 如果有人攻陷DMZ中的一台服务器，那么他们仍然有可能穿透你的networking，这取决于DMZ中的服务器是如何configuration的（例如，LAN侧的SQL数据库和DMZ-如果Web服务器已经被植入并且用于访问SQL服务器的证书被存储在DMZ服务器上，
此外，如果您使用/存储的信息本身是有价值的，而且仍然可能被在DMZ中再次植入服务器的人盗取，那么您提出的build议将毫无帮助。
与所有与安全有关的问题一样，答案是“取决于”。 这取决于您所在公司的types，运行的服务types，您的互联网所面临的服务的硬化程度，您所监pipe的数据，您必须遵守的法律等等。
简短的回答 – 通过限制DMZ和可信networking之间的地址/端口来最大限度地减less“攻击面”。 如果可能的话，部署使用反向代理types安排的技术，以便DMZ-> Trust的对话是不可能的。 当然，这并不总是可能的。 考虑设置一个包含“仅限Internet”数据库的中间防火墙区域。 最后，请确保您限制Trust-> DMZ的端口/地址。 许多恶意软件利用反向代理风格的连接（但方向相反），也就是说，它们依靠入站连接打开源networking。
这类问题的问题是，几乎每个人都会得到不同的答案，而select最适合自己的方式是您的工作。 额外的安全性不可避免地使日常操作变得更加尴尬，过于复杂的安全configuration常常会导致configuration错误，使得漏洞不被人注意。
安全全是关于防护的层面，无论人们告诉你什么都没有解决scheme，100％安全。 无论你决定要做什么，都要考虑在上线之前进行笔测，并确保你保持DMZ服务的打补丁。 最后，至less每年检查一次你的configuration。
那么你已经列出了这个设置的问题之一，它只是TCP。 不仅如此，在DMZ内部还可以相对容易地伪造一个会话。 对我来说，理想的理想解决scheme听起来像是像普通用户那样对待可信任的局域网，将它们从networking中发送出去，然后再返回。