高质量解读《互联网企业安全高级指南》三部曲（技术篇）——入侵感知体系
前言：
高效读书，一张逻辑图读懂、读薄书中重点。
注：下面文字只是对逻辑思维图的”翻译“，节省时间，只看图即可。
入侵感知体系逻辑思维图
1. 说明
1.1. 入侵感知是目前安全防御体系建设中最重要的一环，是大型互联网生产网络的核心需求
1.2. 本章从系统、应用、后端架构等维度讲述入侵感知体系的实现方法
2. 主机入侵检测
2.1. 主机入侵检测系统(Host-based Intrusion Detection System, HIDS)顾名思义是基于主机的入侵检测系统，是部署在需要防护的主机服务器上的一种软件
2.1.1. 存在问题
开发部署需要考虑业务环境，其架构对业务系统侵入性的部署也带来了版本适配等开发难题
部署过程需要耗费大量运维成本
商用产品较少，以至于现在市面上知名的商用HIDS几乎没有
2.1.2. 市场上存在2类产品
在开源产品方面有著名的0SSEC，被各中小型互联网公司选用
各大互联网公司则因为生产网络的海量IDC环境不得不自研HIDS产品
2.2. 开源产品OSSEC
2.2.1. OSSEC是典型的BS架构，Agent端会通过各种模块，分析并采集数据上报到Server, 如图8-2所示
2.2.2. OSSEC拥有基础的入侵检测能力，同时也可以看做是个基础数据采集和分析框架引 擎，如果需要新增检测能力，通过增加数据和分析规则是可以实现的OSSEC的功能扩展，如图8-4所示
2.3. MIG
2.3.1. Mozilla InvestiGator是一个开源的分布式取证框架，不能算是严格意义上的HIDS，但功能与HIDS类似。它主要作用是通过消息队列Active MQ在分布式的agent上执行系统 检查命令然后返回结果，目前包含4个模块，分别是：文件（file）、网络（network）、内存 （memory）、漏洞（vuln）、如表 8-1 所示
2.3.2. MIG系统架构如图8-5所示
2.3.3. MIG具备了现代HIDS架构的維形，但是整体上MIG偏向于事后的取证，而不是实时的入侵检测，所以只部署MIG还不能实现主机侧的入侵检测，必须辅之以其他的Agent,如OSSEC或Osquery等
2.4. OSquery
2.4.1. Facebook的开源项目OSquery这个东西在国内比较冷门，它不能算是完全的HIDS，也不能说是完全为了安全而设计的，有一部分应该是出于运维的需求
2.4.2. OSqucry适合于有一定IDC规模的企业，安全团队有一定的开发能力，并且对入侵检测有基于大数据理解的环境
2.5. 自研Linux HIDS系统
2.5.1. 自研原因
互联网公司业务的急速扩张，也让各大公司的生产网环境急速膨胀，以至于他们的生产网安全对抗也变得更加复杂
几乎很难有一个可直接照搬或者购买部署的HIDS产品能满足需求
海量环境、需求迭代快
2.5.2. 自研设计
架构设计
安全需求
行业法规需求——行业法规这里指上市公司审计要求，等级保护等
基础安全需求——基础安全需求来自于常见入侵场景检测能力要求，一般逐一对应渗透入侵的各个环节的检测能力:如：端口扫描、SQL注入、命令注入、webshell，反连木马、嗅探、提权、文件篡改等
企业自身的特殊安全风险需求——根据分析历史安全事件复盘和基线安全数据，推导出的企业自身存在的特定安全特点和场景，为解决此类场景专设的能力
运维体系\网络环境适应——根据前述的风险需求分析选择更适合自身的架构
HIDS基本是CS架构，与传统安全软件不同的是，现在互联网公司的生产网环境对系统性能极为敏感，通常对安全系统提出较为苛刻的系统资源消耗指标要求，加之为快速应 对新型风险的检测能力，使得主要的计算分析基本迁移到后端进行，前端仅仅以数据釆集 为主。HIDS系统架构如图8-6所示
Agent功能模块
Agent分三个部分，安全功能模块、数据传输、管理模块HIDS Agent架构如图8-7所示
安全功能模块是整个Agent的核心部分各个功能模块既可以以单独进程也可以以线程模式存在，建议用独立进程模型，因为避免因单个BUG影响整个Agent系统的稳定性
数据传输
数据传输是必要且重要的功能模块
与传统HIDS以及PC版HIDS不同的是，企业版HIDS通常需要通过后端数据分析来实现安全能力，特别是互联网企业中，为了降低前端计算带来的系统资源消耗基本以后端数据分析为主
控制管理
企业级HIDS系统部署量非常大，且安全防守体系任何一点的故障都可能导致整体防守的失效合理的管理手段，能让整套系统更为健壮，确保可用性
3. 检测webshell
3.1. 介绍
3.1.1. 互联网公司Web类的应用服务占较大比例，那么在此攻击面上的攻防入侵场景中占比非常高，几乎Web安全成了攻防对抗的代名词
3.1.2. 在Web入侵中最重要的一个环节就是 getshell，也就是放置Web后门webshell，那么Web安全能力中一个最重要的指标就是webshell检测能力
3.1.3. webshell通常是一个文件，那么静态文件的扫描检测是常见做法，但由于攻防技术的对抗发展，静态文件的变形越来越多，已不足以满足检出率要求，于是出现了流量检测、运行时检测等方案
3.2. 检测方法
3.2.1. 静态检测
静态文件检测是常规做法，在Linux系统里，一个webshell检测模块运作流程如图8-8所示
文件静态扫描基于黑名单特征字符串，以及几个“高危函数”出现概率的组合，通常一个业务CGI文件，几乎不可能存在文件读写、命令执行、代码执行、DB操作文件上传几 类函数同时出现的情况
3.2.2. 流量监测
对于一些常见的webshell来说，对于webshell的http请求应该是固定的，包括 "cookie”, post data,功能函数参数等等
4. RASP
4.1. 描述
4.1.1. 出现原因
随着攻防对抗的升级，防守方发现在已有的日志和数据中，已很难提升分析检测能力，误报越来越多，事件追溯无足够的细节可用
4.1.2. 我们需要一种数据和能力实时刻画攻击事件现场，甚至于依据模型直接阻断恶意行为, 于是 RASP (Runtime Application Self Protect)系统应运而生
4.1.3. 目前主流web开发语言是Java和PHP
4.2. PHP RASP
4.3. Java RASP
5. 数据库审计
5.1. 一个企业的最核心资产莫过于数据，在互联网企业则是更甚
5.2. 常见MySQL相关的审计产品
5.2.1. 旁路型
旁路审计几乎是传统乙方安全厂商最常见的模式，通过网络设备镜像流量，审计设备解码组包DB流量，并存储分析，通过模型检测和追溯可疑和高危事件
5.2.2. 主机型
5.2.3. 代理型
5.2.4. 攻击检测
6. 入侵检测数据分析平台
6.1. 架构选择
6.1.1. 常规的安全产品可能是一个杀毒软件、一个IDS、一个WAF，这能解决一个单点安全问题，但如果没有全局的信息汇聚与分析，很难实现对全局态势的感知
6.1.2. 分析与计算在后端，也就是所谓的云端来实现
6.2. 功能模块
6.2.1. 大型网络的安全监测产品通常有各类SOC系统、分布式安全产品，以及云安全产品。 产品形式千变万化，但功能模块可以简化如图8-20所示
6.2.2. 主要模块
感知能力
通常SOC系统会收集各种日志，各种NIDS∖HIDS都有数据采集功能。尽可能多的釆集数据对于入侵分析是很有帮助的
数据分析
定义格式化数据需做以下工作：分析规则决定数据纬度；关联逻辑定义字段扩展
6.3. 分析能力
6.3.1. 单点事件描述数据的行为分析
6.3.2. 上下文事件关联分析
6.3.3. 规则描述
6.3.4. 多数据纬度关联分析
6.3.5. 结上诉架构与分析逻辑，我们得出整体架构图见图8-26
6.4. 实战演示
7. 入侵检测数据模型
8. 数据链生态—僵尸网络
8.1. 僵尸网络传播
8.1.1. 漏洞传播
为快速获取大量被控僵尸肉鸡，攻击者会及时更新攻击模块
8.1.2. 自动化攻击工具
漏洞常有，而装有存在漏洞的软件的服务器不常有
8.2. 僵尸网络架构
8.2.1. 示例：僵尸网络利用CVE-2012-1823漏洞大肆传播，并且利用充分榨取肉鸡系统资源Botnet架构如图8-33所示
8.3. 应对僵尸网络威胁
8.3.1. 及时发现，及时修补漏洞，建立阻断策略，避免其危害扩散
9. 安全运营
9.1. 安全方案选型
9.2. 安全事件的闭环运营
9.3. 可量化的安全能力量