纵深防御
互联网安全有几个比较核心的需求：快速检测、有限影响、快速溯源、快速恢复
攻击者视角
Plan-A：通常路径，从目标系统正面找漏洞，远程直接 rootshell 在现代基本没有了，大多数是以应用为入口，先获取上层应用的权限，然后通过上传 webshell 等方式间接获得系统 shell，最后提权获得 rootshell，后面继续扩大战果的事情就不提了，安全建设的思路自然是要反过来，阻止攻击者扩大战果
Plan-B：如果正面没有明显可利用的漏洞，就需要曲折迂回，从周围信任域开始下手，这个信任域是广义上的，包括可 arp 重定向的、可嗅探的、可会话中间人的、可链路劫持的、相同内网的、密码满足同一规律的、互联互通信任关系的，灾备或镜像站点等，获取一个点后再折返，之后的路径与A类似
Plan-C：如果直接针对生产网络不行，就需要考虑社会工程学了，针对管理员和办公网络的 APT、水坑攻击；针对应用后台管理员的社会工程学技巧，搞定 SA 自然也就搞定了所有服务器
防御者模型
第一层是安全域划分，这个安全域是对业务的抽象，并不是对物理服务器的划分，在大规模分布式架构中，同一个安全域的机器可能并不一定位于同一个物理机房，但是它们对应相同的安全等级，共享一组相同的访问控制策略，只对其他安全域或 Internet 暴露有限的协议和端口。即使攻击者渗透了其他相邻的服务器，也只能扫描和访问这个安全域内有限的几个端口，没办法自由渗透，这个方案主要解决Plan-B曲线救国时被入侵者“误伤”，即被无意识的扫描行为以很低的成本获取新的站点和权限，以及获得单点 root 后进一步渗透的扩散，希望能把安全事件爆发的最大范围抑制在一个安全域中，而不是直接扩散到全网
第二层是基于数据链路层的隔离，只有第二层隔离了才能算真正隔离，否则只在第三层以上做 ACL 效果会差一些，仍然会遭受 ARP 攻击，第二层使用 VPC、Vxlan、Vlan 等方法相当于在安全域的基础上对一组服务器以更细的粒度再画一道防线，进一步抑制单点沦陷后受害源扩大的问题。在不是特别大的网络中可以直接跳过安全域到这一步。当然安全域的概念在任何时候都是存在的，我们在这里仅仅是在做划分的事情
第二层之上就是端口状态协议过滤，这是绝大多数”防火墙”应用的场景。解决的还是对黑客暴露的攻击面的问题，即使我的加固做得不到位，不必要的服务没有清理干净，开放了有问题的端口，甚至有些端口上跑着的服务还有漏洞，但是因为被防火墙过滤了，路由不可达，所以攻击者利用不了，他只能在对外或对信任域暴露的端口上去想办法。本质上，就是给攻击者提供”窄带”，有限的访问通道。不过在有复杂嵌套引用关系的大规模生产网络中，出于运维成本的考虑，有时候访问控制策略不会做得很细粒度，因为那样的话，如果有台机器挂了，换个IP都麻烦，这也是安全向业务的妥协
再往上一层是现在讨论最多的App安全，其实从图中也可以看出你平日的工作都是聚焦于哪层。这一层单独拆开都可以再建一个纵深防御的子体系。应用层通常是暴露在 Internet 上的攻击面，这一层主要是解决认证鉴权、注入跨站上传之类的应用层漏洞，尽可能把人侵者堵在信息和资源的唯一人口。如果你在开发 WAF，那你对应的也是这一层的工作
应用层上方是容器、运行时环境。这里的目标是假设服务器上的应用程序有漏洞且攻击者找到了漏洞，我不希望这个漏洞能被成功利用，直接跳转到系统权限，而是希望能在这一步阻止攻击者，办法就是通过容器加固。比如阻止一些危险函数的运行，比如上传了 webshell 但是不被解析执行，比如你想执行 eval（) 并用种种方法变形编码字符串拼接逃过了应用层的检测，但是到了运行时其实是相同的底层指令，那么无论攻击者在上层多么努力地变形，我都有可能在更底层把攻击者揪出来，哪怕不直接阻断，我也至少报个警。在绝大多数人侵活动中，上传或生成 webshell 是从应用权限向系统权限转化的关键一步
如果不幸之前的步骤都没阻止攻击者，对方已经得到了普通用户的 shell”$”，那么我肯定不希望你继续得到 rootshell，对抗的办法就是大家常见的那些系统加固项。不过最主要的还是对抗本地提权以及内核提权，攻击免疫或称攻击缓解机制如 SMEP、SMAP、DEP、各种 ASLR、stack-canay、read-only、PLT、GOT 等都是在这里埋点，其他的诸如 umask=022 等也是在这里埋点。不过，当下各种基于Lxc的容器，越来越多的多租户的云环境，隔离的机制完全依赖于内核的健壮性，这些场景下对抗这一层的攻击都显得尤为重要
如果被拿走了 root 自然是很令人不爽的事，但还不是最令人不爽的。如果有一天当你
的1万台服务器中有500台被攻击了，而且还不能推断是不是装了 kernel rootkit 的情况下，这种感觉是最要命的。这时即便500台服务器备份数据、重装系统都不能彻底解决问题，而且近似于你某个子业务要处于离线状态，对于这种极其影响可用性的事情，业务部门会把你逼疯掉。所以不是特别需求要干掉 LKM、/dev/kmem 并限制 /dev/mem的全地址空间读写，另外 kernel MAC 内核强制访问控制也能限制 root 只能做有限的事情，尽管理论上内核提权还是能控制一切，不过要在没有开发环境的服务器上实现完整的 kernel rootkit 功能并保证不在用户态留下蛛丝马迹的概率还是比较低。这样做还有一个好处，把人侵检测聚焦于用户态，不要动不动就去装一堆内核级别的重量级玩意儿，大规模高并发的生产环境不适用
在云计算环境中，上面那步可能还不算是单点渗透的终结，更底层还有 hypervisor。如果攻击者逃逸出 VM 那就比较狼狈了，每个厂商都需要考虑一下 vMM 的保护方案，现在 hypervisor 这一层很薄，不会做得很重，似乎还没有特别成熟和通用的方案，不过肯定会发展起来，会有更多类似于XSM这样的方案
安全架构设计原则
- 纵深防御
- 多维防御：如对抗 SQL 注入，第一层 WAF、第二层 Web 日志分析、第三层 RASP、第四层 SQL 审计
- 降维防御：在更低层进行检测和拦截，如在内核态检测用户态攻击、使用 RASP 在运行时而不是在 CGI 层检测 Webshell、HIDS 的攻击检测不在本机判定而在云端计算
- 实时入侵检测
- 伸缩性、可水平扩展
- 支持分布式 IDC：对于海量 IDC 规模，需要支持去中心化，多级部署，解决一些列的失效、冗余和可用性问题
- 支持自动化运维
- 低性能损耗
- 能旁路不串联：对业务响应的延迟、对业务逻辑的影响、误杀阻断用户请求
- 业务无感知
- 去“信息孤岛”
- TCO 可控
