东西向加白名单！等保2.0挖了个“天坑” – 作者:蔷薇灵动dynarose-安全小百科

作为我国网络安全领域的基本国策、基本制度，关于等保2.0的重大意义，业界已经充分的讨论过，本文就不涉及了。而作为工作在网络安全第一线的队伍，我们更愿意就等保2.0的具体的技术要求做一些分析。

对于新的技术标准，业界普遍关注到，这个标准增加了对云计算等新业务场景的要求，但是事实上，等保2.0在基础技术要求部分也做了相当大的调整，可以说是在整个安全管理理念上做出了非常深刻的变革。本文只讲两个点，希望能够让大家有所感觉。

这个“天坑”是怎么挖的

1. 白名单

8.1.2.4 访问控制

a) 应在网络边界或区域之间根据访问控制策略设置访问控制规则，默认情况下除允许通信外受控接口拒绝所有通信；

在等保1.0中，关于网络安全访问控制部分，只是提出了要设置访问控制设备，并能提供状态检测能力，和部分应用检测能力。但是并没有明确提出是否应用白名单机制进行访问控制，而在等保2.0里面，则是非常明确的提出，访问控制应该使用白名单机制！

这里做个小科普，在访问控制策略的设计中，从大的机制上分成黑名单和白名单两种机制，所谓黑名单，就是默认放开全部通信，除非在策略中明确对该通信进行阻断。而所谓白名单，就是默认阻断全部通信，除非在策略中明确允许该通信。

一般来说，白名单当然是更安全的一种策略设计机制，但是白名单有一个很大的风险，那就是可能会阻断业务。因为你必须明确的指定你要允许哪些通信，而网络安全管理者往往不具备对业务的理解，因此无法有效设计出一个很完善的白名单来。相反，安全管理者所理解的是安全问题，或者说威胁挑战，关于该封堵什么他们往往有着丰富的知识，所以黑名单成为了网络安全实践中被普遍采用的一种机制。

当然，黑名单也有黑名单的风险，那就是攻击逃逸，或者说策略绕过。由于黑名单普遍依赖于签名信息，而攻击者通过一些技术手段比较容易将自己的特征进行变化进而躲开签名的匹配筛查，而一旦绕开这个签名，在黑名单机制下，攻击就可以畅通无阻了。所以，一直以来，攻击与防御始终在玩猫捉老鼠的游戏，恶意代码快速变种，而签名生产者就要尽快的捕捉到新的变种，然而，攻击的难度远远小于防御，黑名单机制越来越表现出力不从心的迹象。

在这种情况下，一方面业界发展出了一些基于行为的下一代分析方法，比如UEBA，EDR一类的技术，但是实话实话说，这些技术到今天为止从实战层面上看还很难被委以重任，相较而言，将黑名单机制切换回白名单机制，成为了更加有效和可执行的一种选择。我想，这也是为什么在等保2.0的技术要求里明确提出访问控制要用白名单机制了。

所以，第一个大坑，就是白名单机制，这要求广大安全管理者必须理解业务，并根据业务去设置白名单策略。作为安全老兵，我们深深知道这对于安全管理者的压力有多大，一个不慎就会阻断业务，然后就是铺天盖地的电话质询与事后问责。

2. 东西向

8.1.2.5 入侵防范

b) 应在关键网络节点处检测、防止或限制从内部发起的网络攻击行为；

在等保1.0的入侵防范部分，要求的是在边界处进行对指定类型的攻击进行防御，虽然并没有强调防内还是防外，但是从上下文的角度分析，当时的规范编写者考虑的是防范外来的攻击，这一点从其部署位置就能看得出来，边界上的防御，在传统的的理解上防的是边界以外的威胁。然而，在等保2.0中，则明确提出要进行对内部威胁的防御，也就是我们业界常说的东西向防御。

为什么说东西向防御也是个坑呢？

首先这是由网络结构决定的，一般来说南北向安全都能找到一个叫做网关的地方，我们只要将安全产品部署在网关的位置就能起到一夫当关的作用。然而东西向安全则不同，我们很难找到一个关键路径，让所有的内部流量都会经过这里。为了解决这个问题，业界有两个思路，一个思路叫做“引流”，就是把所有流量都牵引到一个固定的地方去处理，处理后再牵引回来。这个方法，业界笑称为“体外透析法”，是属于强行将南北向安全技术用于解决东西向问题的一种做法，其结果就是非常大的内网带宽占用，非常大的网络延迟，以及完全处理不过来的流量压力（东西向流量是南北向流量的20倍以上）。另一个思路，是将控制点下沉，比如在每一台接入交换机的位置都部署上安全设备，而这个方案的问题在于其高昂的采购，部署，和维护成本。

其次这也是由网络规模决定的，南北向安全不管内部有多大，网关就是一个，基本不受网络规模的影响，而东西向安全则和网络规模有很大关系，50台服务器的数据中心和500台服务器的数据中心将是完全不同的挑战。

而云计算，则更加让这个大坑显得深不见底。首先，当代数据中心规模都极其巨大，一些云数据中心，体量甚至数以10万计，再加上容器技术带来的节点数激增，使得云内的东西向安全已经成为了一个禁区。另一方面，由于云计算普遍采用了虚拟化技术，这意味着只有虚拟化安全产品才可能在云内得以部署，然而虚拟化的安全产品（主要是防火墙）普遍对云基础架构有着很强的依赖关系，比如国内发布的几款虚拟化东西向防火墙基本上都只支持少数几个指定的虚拟化架构，这使得云用户（尤其是自己开发云系统的私有云用户）很难找到能用的安全产品。而另一方面，虚拟化防火墙毕竟还是防火墙，并没有彻底解决我们前面提到的那个关于关键路径的问题，为了解决对东西向流量进行全覆盖，目前的东西向防火墙普遍要求很高的部署密度（每台宿主机一个），而与此同时，东西向墙的开销却并不低（2核2g是基础配置），这无疑使得在云内东西部署向安全产品变的难上加难。

3. 当东西向遇到白名单

白名单是个大坑，东西向也是个大坑，而当东西向遇到白名单，这个坑就是一个史诗级别的天坑了。

如果只在边界处做白名单，其实还好说，因为一个数据中心对外提供的服务一般来说都是属于已知的，比较规范的，和有限的服务，基本上还是比较容易摸清楚的。但是一旦把场景切换到了内部，你就会发现数不胜数的私有协议和应用，没有人了解他们的网络特性，也没有人准确的知道究竟有多少这样的私有化应用在内部。据说曾经有大型央企的安全部门尝试进行内部业务梳理，将近半年过去了，连冰山一角都还没摸清楚，不得不放弃了这个尝试。

同样的，如果说东西向安全只采用黑名单机制，也还好说，因为你不必要去理解内部的业务究竟是什么，你只需要将已知的威胁添加进黑名单就可以了，这样既做了内部防御，又不会破坏业务，但是如果做白名单，则场景就又回到了刚才我们描述的那个场景中。总之，还是那句话，当东西向遇到白名单，恭喜你喜提了一个天坑。