互联网企业安全高级指南读书笔记之入侵感知体系

主机入侵检测

开源 HIDS

OSSEC、Mozilla InvestiGator 和 OSquery

OSSEC 是典型的 B/S 架构，通常一个 Server 集群最多配置 2000 台 agent 接入。在此基础上，OSSEC 也支持在开发插件、采集数据、解析/检测规则三个方面的功能扩展

Mozilla InvestiGator 具备了现代 HIDS 架构的雏形，但是整体上 MIG 偏向事后的取证，而不是实时的入侵检测

OSquery 适合有一定 IDC 规模的企业，安全团队有一定的开发能力，并且对入侵检测有基于大数据理解的环境

自研 HIDS

agent 功能

基线安全

在 Linux 系统下以读取解析文本配置为主，辅以某些二进制文件的 ELF 格式解析；Windows 系统通过读取注册表和组策略信息完成采集

采集数据包括但不限于：

• 系统版本，Linux 发行版版本、Linux 内核版本、Linux 内核热补丁、Windows 补丁（微软官方补丁公告中注册表项）信息
• Linux 系统账户、Windows 账户权限、权限组、最后登录时间
• 系统关键文件 MD5
• 应用服务版本
• 第三方应用服务版本
• webapp 版本

日志采集

采集的日志内容如下：

• Linux 系统日志
  
  • syslog 默认日志
  • 系统服务登录记录
  • 系统账户登录记录
• Windows 系统
  
  • 应用服务日志
  • 安全日志
  • 系统日志
• Webserver
• 扩展插件日志

进程信息

• 周期性遍历/proc。这是风险最小的方案，部署适配性最强。但缺点明显，实时性无法得到保障，且性能差
• 用户态 Hook Libc 函数。相比前面一种方案，风险相对高一点，特别在多线程进程中要注意安全性。但其部署适配性也特别高，同时性能也是各种方案最好的，建议
  作为首要选择。虽然 libc hook 方式可能有被绕过的风险，但如果对抗主要集中在 Web 入侵场景，基本是无需担心的
• 利用 LSM 模块接口。如果对抗必须深入系统级攻防，那么通过内核态获取进程数据就非常必要了。但是为了安全性、适配性考虑，采用 LSM（Linux security module）开发接口就是较佳的选择。Fackbook 安全团队开发的 osquery 就是使用了 LibAudit 获取 execve 调用信息
• 内核态 syscall HOOK，安全类的开发最惯性的思维就是内核态 HOOK，反倒不是什么新鲜的招式。但是这样的方案未必都适合大范围使用，作为一个可能要大量部署的安全系统来说，不是一个最佳选择。在 Linux 环境里各种发行版和内核版本差异很大，以至于需要维护多个兼容性版本，同时稳定性也难以保证。这类方案通常是开发一个 LKM 模块实现

建议字段：

小技巧：

网络连接信息

• /proc/net/raw RAW 套接字信息
• /proc/net/tcp TCP 套接字信息
• /proc/net/udp UDP 套接字信息

Webshell

inotify 文件监控，Linux 系统中公认的技术就是 inotify，在 BSD 和 macOS 里类似的是 kqueue。Linux 内核从 2.6.13 开始引入 inotify，可以通过

 % grep INOTIFY_USER /boot/config-$(uname -r)
 CONFIG_INOTIFY_USER=y

来查看系统是否支持

DB 审计

DB 保护是重中之重

数据传输

• syslog 转发，默认使用 UDP 514 端口，数据量较大或者数据量波动可能会丢失数据，敏感信息也可能因明文传输而泄露
• 数据直传
• 数据接收 Server

值得注意的是：

• 避免数据传输波峰“雪崩效应”
• 敏感数据脱密与加密
• 做好数据传输环境的前后链对账，出现漏报时能够及时追查到可能导致数据丢失的环节

控制管理

健康度监控

自杀机制

安全在极端情况下，出现故障时必须为业务稳定牺牲，系统资源消耗超标功能模块要暂停甚至自杀

部署与更新

• 海量环境影响
  
  • 发布前必须通知业务方，有应急预案和回滚手段
  • 灰度发布，未经一个可靠的时间周期稳定运营验证，不得批量部署
  • 节假日前不部署
  • agent 更新由 Server 端推送任务完成
• 安全性
  
  • 控制（更新）指令仅允许选择固话的指令，严禁预留命令执行接口
  • 更新包必须经过第三方安全工程师审核之后上传至更新 Server 保存
  • 控制指令下发时必须由第三方审核批准才可执行

Webshell 检测

Webshell 通常是一个文件，静态文件的扫描检测是常见做法，但由于攻防技术的对抗发展，静态文件的变形越来越多

静态检测

可用维度

多维度检测

流量监控

入侵场景

https://github.com/xti9er/LogForensics/blob/master/LogForensics.pl 是一个 Webserver 日志分析脚本

RASP

运行时应用自身防护

PHP

PHP 代码解释为 opcode 之后再交由 Zend 引擎执行

检测模型

Java

技术架构

• 修改 rt.jar
• JVMTI

检测模型

• 基于高危行为组合的检测模型
• 基于调用栈的检测模型

数据库审计

旁路型

通过网络设备镜像流量，审计设备解码组包 DB 流量，并存储分析，通过模型检测和追溯可疑和高危事件

主机型

审计产品部署到 DB Server 主机上

代理型

攻击检测

主要针对两类问题：

• SQL 注入拖库
• 操作违规审计

对 SQL 攻击的检测面临各种变形 SQL 语句的绕过，但通过语法解析器的还原，任何伪装都必须褪去

将原始 SQL 请求使用语法解析器（Python 的 sqlpare 模块）格式化之后的语句，可以清晰地看到 SQL 语句被递归拆分成了 function+parameter 的展现形式

其实 SQL 注入就是本该只允许输入 parameter 的地方被恶意插入了 function 调用且被执行

入侵检测数据分析平台

功能模块

分析能力

现在的攻击往往不易触发单点的安全策略和检测，需要更多纬度和大视角的数据分析

• 单点事件描述数据的行为分析
• 上下文事件关联分析

实战示例

某个高权限进程的父进程为低权限，则告警。不过仍然有一些细节：

• 同样的情况在正常情景下有哪些，如何去除误报？
• 向前追溯还是向后追溯更容易实现？
• 提权除了上述场景，还有哪些？

入侵检测数据模型

战场纵深

高维防守

无论什么入侵行为，都对应着更高一纬度的系统功能和能力支持，尽量不要和攻击者在低纬度针尖对麦芒地对抗

策略实践

• 网络层：检测符合 RFC 1867 标准的上传 CGI 行为
• CGI 层：关注 fopen 等写 CGI 文件的 API 事件
• 系统用户态：检测系统层面的 API 调用行为
• 系统内核态：通过内核 inotify 事件来发现 CGI 创建行为

近身防守

要解决一个入侵场景，在指定策略之前做好足够的分析并提炼其最核心的技术点，贴近此特征指定策略效果就非常好