网络安全纵深防御体系

第一层是安全域划分，这个安全域是对业务的抽象，并不是对物理服务器的划分，在大规模分布式架构中，同一个安全域的机器可能并不一定位于同一个物理机房，但是它们对应相同的安全等级，共享一组相同的访问控制策略，只对其他安全域或 Iinternet 暴露有限的协议和接口。即使攻击者渗透了其他相邻的服务器，也只能扫描和访问这个安全域内有限的几个端口，没办法自由渗透，这个方案主要解决Plan-B曲线救国时被人侵者“误伤”，即被无意识的扫描行为以很低的成本获取新的站点和权限，以及获得单点root后进步渗透的扩散，希望能把安全事件爆发的最大范围抑制在一个安全域中，而不是直接扩散到全网。

第二层是基于数据链路层的隔离，只有第二层隔离了才能算真正隔离，否则只在第3层以上做ACL效果会差一些，仍然会遭受ARP攻击。第二层使用VPC、 Vxlan、VLan等方法相当于在安全域的基础上对一组服务器以更细的粒度再画一道防线，进一步抑制单点沦陷后受害源扩大的问题。在不是特别大的网络中可以直接跳过安全域到这一步。当然安全域的概念在任何时候都是存在的，我们在这里仅仅是在做划分的事情。

第二层之上就是端口状态协议过滤，这是绝大多数“防火墙”应用的场景。解决的还是对黑客暴露的攻击面的问题，即使我的加固做得不到位，不必要的服务没有清理干净，开放了有问题的端口，甚至有些端口上跑着的服务还有漏洞，但是因为被防火墙过滤了，路由不可达，所以攻击者利用不了，他只能在对外或对信任域暴露的端口上去想办法。本质上，就是给攻击者提供“窄带”，有限的访问通道。不过在有复杂嵌套引用关系的大规模生产网络中，出于运维成本的考虑，有时候访问控制策略不会做得很细粒度，因为那样的话，如果有台机器挂了，换个P都麻烦，这也是安全向业务的妥协。

再往上一层是现在讨论最多的APP安全，其实从图中也可以看出你平日的工作都是聚焦于哪层。这一层单独拆开都可以再建一个纵深防御的子体系。应用层通常是暴露在Internet上的攻击面，这一层主要是解决认证鉴权、注入跨站上传之类的应用层漏洞，尽可能把入侵者堵在信息和资源的唯一入口。如果你在开发WAF，那你对应的也是这一层的工作。

应用层上方是容器、运行时环境。这里的目标是假设服务器上的应用程序有漏洞，且攻击者找到了漏洞，我不希望这个漏洞能被成功利用，直接跳转到系统权限，而是希望能在这一步阻止攻击者，办法就是通过容器加固。比如阻止一些危险函数的运行，比如上传了 webshell 但是不被解析执行，比如你想执行eval()并用种种方法变形编码字符串拼接逃过了应用层的检测，但是到了运行时其实是相同的底层指令，那么无论攻击者在上层多么努力地变形，我都有可能在更底层把攻击者揪出来，哪怕不直接阻断，我也至少报个警。在绝大多数入侵活动中，上传或生成 webshell 是从应用权限向系统权限转化的关键一步，所以这一层的防御也是比较重要的。后面会有单独篇幅讲如何对抗webshell。

如果不幸之前的步骤都没阻止攻击者，对方已经得到了普通用户的shel＂$＂，那么我肯定不希望你继续得到 rootshell，对抗的办法就是大家常见的那些系统加固项。有很多文章洋洋酒洒写了一大堆主要就是用在这个场景的，不过最主要的还是对抗本地提权以及内核提权，攻击免疫或称攻击缓解机制如SMEP、SMAP、DEP、各种ASLR、 stack- canay、read-only、PLT、GOT等都是在这里“埋点”，其他的诸如 umask=022等也是在这里埋点。似乎看上去这些不太需要安全团队的介入，好像都是OS默认的机制?其实不然，安全做到偏执的程度后还是有自己出手的地方， Android出手比标准的 Linux更快一点，也许以后就真的没太多需要自己出手的地方了。不过，当下各种基于LXC的容器，越来越多的多租户的云环境，隔离的机制完全依赖于内核的健壮性，这些场景下对抗这一层的攻击都显得尤为重要。

如果被拿走了root自然是很令人不爽的事，但还不是最令人不爽的。如果有一天当你的1万台服务器中有500台被攻击了，而且还不能推断是不是装了 kernel rootkit I的情况下，这种感觉是最要命的。就如同你生了个肿瘤手术摘掉也就算了，如果手术完都不确定摘了没有，可就麻烦了，这时即便500台服务器备份数据、重装系统都不能彻底解决问题，而且近似于你某个子业务要处于离线状态，对于这种极其影响可用性的事情，业务部门会把你通疯掉。所以不是特别需求要干掉LKM、/dev/kmem并限制/dev/mem的全地址空间读写，另外 kernel MAC内核强制访问控制也能限制rot只能做有限的事情，尽管理论上内核提权还是能控制一切，不过要在没有开发环境的服务器上实现完整的 kernel rootkit功能并保证不在用户态留下蛛丝马迹的概率还是比较低。这样做还有一个好处，把入侵检测聚焦于用户态，不要动不动就去装一堆内核级别的重量级玩意儿，大规模高并发的生产环境伤不起。

在云计算环境中，上面那步可能还不算是单点渗透的终结，更底层还有 hypervisor。如果攻击者逃逸出VM那就比较狼狈了，每个厂商都需要考虑一下VMM的保护方案，现在hypervisor这一层很薄，不会做得很重，似乎还没有特别成熟和通用的方案，不过肯定会发展起来，会有更多类似于XSM这样的方案。

在一个真正建立纵深防御的系统中，人侵者一般到不了root这一步就会被揪出来，只不过完整的纵深防御分散在全书后续的篇幅里，这里只是选取了其中一个维度来试图解读这个概念。另一方面，完整的纵深防御体系只有大型互联网公司才可能全覆盖，因为跟安全建设成本有关，这个问题之前提到过:不同规模企业的安全需求和同一公司在不同安全建设阶段的需求是不一样的。

网络安全纵深防御体系

第一层是安全域划分，这个安全域是对业务的抽象，并不是对物理服务器的划分，在大规模分布式架构中，同一个安全域的机器可能并不一定位于同一个物理机房，但是它们对应相同的安全等级，共享一组相同的访问控制策略，只对其他安全域或 Iinternet 暴露有限的协议和接口。即使攻击者渗透了其他相邻的服务器，也只能扫描和访问这个安全域内有限的几个端口，没办法自由渗透，这个方案主要解决Plan-B曲线救国时被人侵者“误伤”，即被无意识的扫描行为以很低的成本获取新的站点和权限，以及获得单点root后进步渗透的扩散，希望能把安全事件爆发的最大范围抑制在一个安全域中，而不是直接扩散到全网。

第二层是基于数据链路层的隔离，只有第二层隔离了才能算真正隔离，否则只在第3层以上做ACL效果会差一些，仍然会遭受ARP攻击。第二层使用VPC、 Vxlan、VLan等方法相当于在安全域的基础上对一组服务器以更细的粒度再画一道防线，进一步抑制单点沦陷后受害源扩大的问题。在不是特别大的网络中可以直接跳过安全域到这一步。当然安全域的概念在任何时候都是存在的，我们在这里仅仅是在做划分的事情。

第二层之上就是端口状态协议过滤，这是绝大多数“防火墙”应用的场景。解决的还是对黑客暴露的攻击面的问题，即使我的加固做得不到位，不必要的服务没有清理干净，开放了有问题的端口，甚至有些端口上跑着的服务还有漏洞，但是因为被防火墙过滤了，路由不可达，所以攻击者利用不了，他只能在对外或对信任域暴露的端口上去想办法。本质上，就是给攻击者提供“窄带”，有限的访问通道。不过在有复杂嵌套引用关系的大规模生产网络中，出于运维成本的考虑，有时候访问控制策略不会做得很细粒度，因为那样的话，如果有台机器挂了，换个P都麻烦，这也是安全向业务的妥协。

再往上一层是现在讨论最多的APP安全，其实从图中也可以看出你平日的工作都是聚焦于哪层。这一层单独拆开都可以再建一个纵深防御的子体系。应用层通常是暴露在Internet上的攻击面，这一层主要是解决认证鉴权、注入跨站上传之类的应用层漏洞，尽可能把入侵者堵在信息和资源的唯一入口。如果你在开发WAF，那你对应的也是这一层的工作。

应用层上方是容器、运行时环境。这里的目标是假设服务器上的应用程序有漏洞，且攻击者找到了漏洞，我不希望这个漏洞能被成功利用，直接跳转到系统权限，而是希望能在这一步阻止攻击者，办法就是通过容器加固。比如阻止一些危险函数的运行，比如上传了 webshell 但是不被解析执行，比如你想执行eval()并用种种方法变形编码字符串拼接逃过了应用层的检测，但是到了运行时其实是相同的底层指令，那么无论攻击者在上层多么努力地变形，我都有可能在更底层把攻击者揪出来，哪怕不直接阻断，我也至少报个警。在绝大多数入侵活动中，上传或生成 webshell 是从应用权限向系统权限转化的关键一步，所以这一层的防御也是比较重要的。后面会有单独篇幅讲如何对抗webshell。

如果不幸之前的步骤都没阻止攻击者，对方已经得到了普通用户的shel＂$＂，那么我肯定不希望你继续得到 rootshell，对抗的办法就是大家常见的那些系统加固项。有很多文章洋洋酒洒写了一大堆主要就是用在这个场景的，不过最主要的还是对抗本地提权以及内核提权，攻击免疫或称攻击缓解机制如SMEP、SMAP、DEP、各种ASLR、 stack- canay、read-only、PLT、GOT等都是在这里“埋点”，其他的诸如 umask=022等也是在这里埋点。似乎看上去这些不太需要安全团队的介入，好像都是OS默认的机制?其实不然，安全做到偏执的程度后还是有自己出手的地方， Android出手比标准的 Linux更快一点，也许以后就真的没太多需要自己出手的地方了。不过，当下各种基于LXC的容器，越来越多的多租户的云环境，隔离的机制完全依赖于内核的健壮性，这些场景下对抗这一层的攻击都显得尤为重要。

如果被拿走了root自然是很令人不爽的事，但还不是最令人不爽的。如果有一天当你的1万台服务器中有500台被攻击了，而且还不能推断是不是装了 kernel rootkit I的情况下，这种感觉是最要命的。就如同你生了个肿瘤手术摘掉也就算了，如果手术完都不确定摘了没有，可就麻烦了，这时即便500台服务器备份数据、重装系统都不能彻底解决问题，而且近似于你某个子业务要处于离线状态，对于这种极其影响可用性的事情，业务部门会把你通疯掉。所以不是特别需求要干掉LKM、/dev/kmem并限制/dev/mem的全地址空间读写，另外kernel MAC内核强制访问控制也能限制rot只能做有限的事情，尽管理论上内核提权还是能控制一切，不过要在没有开发环境的服务器上实现完整的 kernel rootkit功能并保证不在用户态留下蛛丝马迹的概率还是比较低。这样做还有一个好处，把入侵检测聚焦于用户态，不要动不动就去装一堆内核级别的重量级玩意儿，大规模高并发的生产环境伤不起。

在云计算环境中，上面那步可能还不算是单点渗透的终结，更底层还有 hypervisor。如果攻击者逃逸出VM那就比较狼狈了，每个厂商都需要考虑一下VMM的保护方案，现在hypervisor这一层很薄，不会做得很重，似乎还没有特别成熟和通用的方案，不过肯定会发展起来，会有更多类似于XSM这样的方案。

在一个真正建立纵深防御的系统中，人侵者一般到不了root这一步就会被揪出来，只不过完整的纵深防御分散在全书后续的篇幅里，这里只是选取了其中一个维度来试图解读这个概念。另一方面，完整的纵深防御体系只有大型互联网公司才可能全覆盖，因为跟安全建设成本有关，这个问题之前提到过:不同规模企业的安全需求和同一公司在不同安全建设阶段的需求是不一样的。