我们每个人在职业生涯中都犯过错误。这里所说的错误，是那种会使你马上丢掉工作的错误。举例来说，曾经有过一个学校的网络管理员犯过这样的错误，直接导致了校园里的所有路由器同时重启，而不是一个接一个。这个管理员本来是写了个脚本，对路由器进行安全升级，计划中是打算一个一个的升级并重启的，但是结果却是同时重启了。他经过重新检查脚本，才发现错误出在没有等待路由器重启，就直接命令下一个路由器进行升级。

　　像出现这种情况几乎肯定要被学校开除了，但很幸运，学校并没有这样做。不过，对于任何涉及到一场大灾难的人来说，都应该从灾难中学到些什么。我们都学过一些危机管理的知识，在网络重新恢复后，我们有必要花上几个小时来学习该如何检查网络是否工作正常。

　　所幸是大多数时候，大家所面对的错误并不是那么严峻。而不幸的是我们犯的错误不见得马上会被发现，这意味着这个错误可能潜伏数周，数月，甚至数年时间，直到有一天造成严重的后果，或者监管部门发现问题后把我们叫去盘问。在网络安全阵地的前沿，防火墙管理是一个很重要的区域，任何简单的错误规则或配置，都可能给我们带来无尽的后患。下面就让我们大家一起来了解一些最常见的错误：

　　建立毫无意义的防火墙组

　　一个防火墙管理员可能在超过半数的规则中都包含有一个特定的网络对象。我们假定这个对象名字叫“Joe_Montana”。每次当这个对象需要访问网络时，管理员就为这个对象添加一个IP地址，而这个地址是很多许可规则里列出的被许可的地址。这看上去没什么问题，因为没有任何一个规则里包含了ANY范围，但实际上这是个大漏洞。它使得防火墙规则变得毫无意义，而彻底梳理防火墙规则库来解决这个问题，可能需要耗时几个月。

　　从不升级防火墙软件

　　很多公司的防火墙设备所采用的软件都是过时的。在问到为什么会出现这种情况时，大部分企业的防火墙管理员都会说是为了保证防火墙的稳定，或者不允许防火墙因为升级而出现暂时关闭现象。而实际上，防火墙产品厂商决定升级防火墙软件都是有一定原因的。即使企业不一定必须更新到最新版的软件，但如果还是运行着五六年前的旧版软件，或者是距离最新版本老15-20个版本旧软件，那么就应该考虑立刻开始升级了。

　　使用错误的技术

　　之前，有个网络安全管理员与监管人员发生了争执，因为该管理员在公司的安全web服务器前端放置了一个防火墙，作为第二层防护屏障。按照他的想法，这就构成了一个双重验证机制：一个用户密码加一个防火墙。可以说这个管理员在创新性上可以得满分，但是防火墙本身并不算是一个双重验证的解决方案。双重验证需要你的用户拥有两件可验证对象，即所知的和所拥有的两个对象。比如知道密码，并拥有令牌。

　　偶然停电

　　曾经发生过这样一件事，有个防火墙管理员为某个项目而在防火墙服务器上进行数据收集。这个管理员在调整网线的时候不小心碰了几下鼠标，这时候鼠标指针正好在“开始”的位置，然后，鬼使神差的鼠标指针又指到了屏幕中央弹出来的关机确认窗口，并且点到了中间的关机按钮。于是这个财务公司的防火墙就在这种情况下突然关闭了。

　　不良的文档

　　大家肯定经常听说防火墙管理员抱怨无法理解全部的防火墙规则。如果管理员在建立防火墙规则时图省事，没有进行详细的文档说明，看似节省下来的时间和精力，以后必然会花费到去理解这些规则上。因此肯定有人听过这样的话“恐怕我们要重新修改防火墙设置了，以前的管理员设置的那些防火墙规则没有注释，所以我们很难搞清楚它们的作用。”

　　过度使用丢弃Drop规则

　　一般来说，如果时间比较紧迫，我们都会建立一些属于过度访问的规则，然后再在这些规则的基础上，建立丢弃规则，将不允许的数据连接丢弃。之所以这样，是因为我们很多管理员都不愿意去设置一个精确的防火墙规则。比如：“allow All DMZ devices to All Internal devices ACCEPT”，然后在这个规则之上再建立一个“All DMZ devices to Secure Network device DROP”。这两个规则看上去没什么问题，但是实际上却包含了很多的后患，原因是我们没有在第一条规则中表现出建立该规则的目的。如果长此以往的话，我们的防火墙规则库就会出现很多“成对儿”的规则，而在记录规则日志或修改规则时，也很容易出现更多的风险，或者会导致必要的数据被拦截。最终，我们就不得不重新改写整个防火墙规则库中的全部规则。

　　使用路由作为安全策略

　　大家平时会遇到过很多类似的情况，当防火墙规则库需要修改时，路由规则也要跟着修改。当然，如果涉及到新的网络，那么这种现象是可以理解的。一般导致这种情况的错误有两种。首先，防火墙没有默认路由。所有路由都是手工输入防火墙的，同时如果防火墙没有策略，会使用最小子网掩码，防止数据流向无关设备。这听起来很不错，但却是完全没必要的，因为如果从现代的防火墙上删除策略，防火墙会恢复为DENY ANY。这个设计会因此变得难以管理，最终使整个IT团队都不敢去修改防火墙设置了。如果每个改变都需要工程师检查路由设置，那么会导致耗费过多的时间，影响企业正常业务的运转，这对企业来说很不值得。

　　第二种情况最常出现在Cisco设备中，管理员通过访问控制列表管理两个源或目标均为ANY的接口。实际上这个规则里的ANY并不是所有地址，而是指端口后的所有地址。只有在知道路由表与防火墙关联的前提下，管理员才可能理解防火墙规则库中的规则，这对于管理员来说太复杂了。

　　在规则中使用DNS对象

　　作为一个选项，很多防火墙都会嵌入一个源地址或目的地址作为DNS对象，如google.com。这么做看似错，因为google.com 使用了相当多的IP地址，就算google.com 改变了IP地址，防火墙也会放行google.com的数据流。但是这种做法会导致相当严重的安全隐患，相信任何企业都无法接受。首先，这么做会使你的防火墙更容易遭受DoS攻击。如果连google.com都无法解析会怎么样呢?其次，你的防火墙会浪费CPU，内存以及网络IO来判断每一个数据包是否属于google.com这个域名。第三，如果你设置的DNS被黑客攻击，包含有恶意地址的命令和控制数据中带有google.com的地址，会怎么样呢?在这种情况下，你的防火墙会允许僵尸网络发送的命令和控制数据，并作为google.com记录在防火墙日志中。

　　危急时刻所作的改动

　　可以想象一下，如果服务器上的RAID阵列坏了，一块硬盘报废。你换了一块硬盘，在重建RAID的过程中，服务器无法提供正常的服务，但是你没有意识到这个问题。此时，你的客户已经被拒绝服务长达40小时了，每一分钟你都在遭受损失。而且不断有客户放弃你的服务，却选择了竞争对手。

　　当情况陷入危急时，我们往往会开始改变各种设备的配置：交换机，路由器，负载平衡服务器和防火墙，任何你怀疑导致服务不正常的环节都被调整了一翻。可能又过了很长一段时间后，团队中终于有人发现了问题所在。因此你又需要把所有一改过的配置从新恢复回来，但问题是没有人会记得之前的配置，原因是之前的情况太过紧张，导致没人去做修改配置的文档。最终的结果是，你不得不再花上三天时间将各个设备的配置调试到以前的状态。

　　相信所有的企业都不希望以上这种情况发生。但是事实证明这种情况却时有发生。即使那些运转最好的企业也会出现类似问题，尤其是在防火墙配置上。不过通过自动化恢复机制，这些依靠经验很难实现的工作变得越来越容易实现了。而要想知道你的企业是否具有这种针对网络安全设置或其它安全设置的自动恢复功能，就要看企业是否对投资回报率进行过明确且详细的量化设计。毕竟，如果对于安全投入没有明确的投资回报量化统计，谁能相信这个企业在安全性上是值得信赖的呢?