networking（防火墙）架构为大型企业

你在找什么，重新：三层防火墙体系结构的理由，听起来像是一个幻想的世界，不能很好地映射到现实。 除非您控制所有应用程序，否则严酷的现实是，大多数应用程序供应商都假定从每个层到相邻层（也可能是非相邻层）的软件组件之间不受过滤和不受限制的访问。

我曾经在一些环境中做了一些工作，在这些环境中pipe理层通过防火墙将服务器计算机远离局域网，并尽量减less暴露服务的数量。 每当有新的软件，硬件或供应商参与进来时，这都是一个挑战，因为局域网内所有“传统”的无拘无束的端到端连接的假设已经开始了。 实施任何事情都会在这样的环境下花费更多。

我在局域网内限制通信和暴露的策略和build议如下：

• 在内部路由器/防火墙上使用访问控制列表/防火墙规则来“用粗糙的笔刷绘制”，并排除非常不理想的stream量types（访问IP安全摄像机从任何地方连接到的子网/ VLAN安装video聚合服务器的VLAN，从只安装内部服务器计算机的子网访问Internet等）。

• 从运行在各种服务器计算机上的防火墙软件（Windows防火墙，iptables）实施更具体的访问控制规则。 确保服务器只安装并运行所需的软件，并且只有所需的服务/守护程序才在所需的接口上侦听networking通信。 在这一天，更改控制，密码/ SSO安全以及保持操作系统和应用程序更新的常识性方法。

防火墙允许您量化和仲裁stream量。 所谓的“第7层”防火墙将自己的注意力集中在应用层stream量上（即使在这种stream量的任意深度上），也可以执行比“传统”防火墙更为专业化的仲裁规则。 然而，防火墙并不“提供安全性”，而只是与devise规则集或监视日志的人类一样有效。 总之，规则最初受到的约束越严格，结果就越是让应用程序工作。

我个人会怀疑是否要增加防火墙来“增加安全性”。 我发现networking上所有应用的维护成本都有所增加，但没有保证环境抵抗攻击或降低风险状况的可量化的改进。

这是关于限制事情可以做的损害。 你的防火墙规则很less能够完全防止攻击，但是如果有什么东西被攻破，就应该防止它受到太多的破坏（因为任何给定的方块都应该只能访问你已经validation过的服务列表，它需要访问）。 除此之外，他们还能让您随时了解networking上的stream量。

标准化您的防火墙设置，但是，可能是愚蠢的。 在所有站点都不需要相同数量的防火墙，每个站点的防火墙体系结构应该在易于部署新服务和安全性之间进行权衡。 如果你的环境不断变化，或者放松员工的工作，那么大量的防火墙将会带来太多的麻烦，而且收益甚微。 如果你愿意限制你的员工的自由，那么在互联网，互联网可访问的服务和你的LAN之间设置防火墙是非常值得的（如果一个LAN处理敏感数据，你可能需要在单独的防火墙上子网，如果可能的话）。

从本质上讲，防火墙的重点应该是只允许你知道你需要的服务器之间的stream量，你知道需要相互交谈。 这并不意味着你应该拥有多个防火墙，尽pipe这些防火墙可能是有用的（如果没有其他的话，最终你会在单个防火墙上用尽端口）。 这确实意味着你应该有需要获得类似信任水平的东西，以及类似的系统。 如果您要使用多级防火墙，那么使用异构系统（即Checkpoint到您的Web服务器，在Web服务器和数据库服务器之间使用ASA）是值得的。

我们甚至在非军事区之外跑1，只是因为，到底是什么，为什么不呢？ 非军事区意味着要被暴露，但是允许无限暴露是愚蠢的。

然后我们在DMZ和我们允许联系DMZ的服务器之间运行一个。 我们允许连接到互联网的所有东西都通过DMZ中的代理连接; 这是发生攻击事件时的快速切入点，以及可以在不影响服务器本身的情况下妥协的机器。

最后，我们在连接的所有东西和内部networking之间运行防火墙，所以如果在DMZ中有什么东西被攻破，它不能在内部传播。

有一个例外：企业广域网与内部服务器在同一层，所以在广域网中的一个漏洞只有一个防火墙远离内部系统，尽pipe它们和我们的防火墙布局相同，所以仍然有2个在这个向量之间的外部世界之间的防火墙。

从某种意义上来说，我们可以使用外部防火墙，代理，防火墙，应用程序服务器，然后是同一级别的数据库服务器。 数据库服务器和应用程序服务器之间的防火墙（除了通常的内部防火墙之外）是难以理解的：两者之间的访问是必需的，无论防火墙如何，都有足够的访问权限来违反。

我认为SITES之间的标准化是愚蠢的，但是就暴露的应用程序/服务器而言，你应该是标准化的。 你不想把这个问题留给地方自由裁量权：有人会做出一个错误的决定。 例如，我们的卫星办公室只有一个防火墙，然后是一个到普通networking的VPN，但是他们没有任何保护，而我们的金融系统除了本地以外不可访问。