在“没有人的安全部”构筑护网防御工事（2）——日志监控
第二部分 日志监控
1 概述（what）
1.1 含义
日志监控是指以文本方式对系统的各类行为进行记录并发现其中异常的过程。而许多专业的安全能力的构建，也是以日志为基本输入，例如入侵检测系统。在这个系列的文档中，主动防御不是我们关注的重点，因此不去探讨日志可以有哪些妙用，只讨论日志能直接带来哪些价值。由于日志监控是在安全事件发生后才能产生价值，而它本身也不会接入防御过程中，但日志的重要性在我的认识中仅次于网络隔离，因为日志监控能让整个信息系统建立“看见”的能力，因此它相当于给系统创造了一双眼睛。
日志监控分为日志记录和使用两个部分，日志记录关注日志的类型、格式、读写方式等内容，日志使用关注如何发现攻击、如何还原入侵过程、如何锁定攻击源甚至反制等。
1.2 原理
日志是由一条一条描述行为事件的文本的集合。一条日志应该清晰完整的描述事件的主体、客体、事件发生的时间、内容以及结果，在此基础上，为了能够更便捷的分析日志，还可以人为添加事件分类、等级等标签。简言之，一条日志应该明确描述一个事件，即什么时候，谁对谁做了什么事情，以及结果是什么。
日志是信息系统的运维和安全管理不可确实的一环，中小组织往往会忽略日志系统（包括存储、分析）的能力建设。日志监控其实是一项ROI非常理想的工作，而这可能不被很多攻防经验较少的读者所理解。一定要充分理解日志能力的重要性，并投入足够的资源建设日志管理系统。
1.3 原则
- 覆盖范围足够大
日志记录必须覆盖整个系统的各个入口、平台、子系统、主机等等，否则效果将大打折扣。很多组织在部署安全防守的时候，做了很多事情，一种虚假的充实感会让工程师疏忽掉后方的兜底防线，这是非常可怕的现象。以笔者无数次护网的经历总结的经验教训，日志数据往往在最需要的时候是缺失的，而事先往往“以为”这些数据是充分且详实的。
请谨记：“种下一棵树最好的时间是十年前，其次是现在”。
- 记录时间足够长
同上一条一样，日志记录除了在空间上要足够，在时间上也要足够，原因同上。但相比而言，满足时间上的要求更加容易，但缺点是带来的成本开销是线性增加的。就护网而言，一般演练的时间是一个月左右，算上攻击队踩点的时间，保留三个月足够。但是如果要把功夫做在平时，同时要把价值用在平时，那么按照等保的要求，半年是最少的。而如果有条件做离线存储的话，笔者推荐承载重要数据和重要功能的，保存两年以上，如果能存够5年是最好的。通常离线存储的成本相对比较低（可以将存储介质封存，不需要满足在线读取的需要，只保证使用时能找到数据即可），而五年一次的事故的调查成本，往往高过数据存储的成本。
- 独立存储
日志应当在独立的日志服务或服务器上存储，这样一是为了便于日志的管理，二是防止攻击者在获得系统权限后对日志进行篡改删除。
- 尽可能工具化
最后是尽可能工具化，工具化是指专业的处理日志的工具平台。完成了日志的记录存储只是解决了第一步，但真实运营起来还需要有专业的工具来支持才能达到更好的效果，例如在进行一些关联分析的时候，使用日志分析平台可以支持SQL语句对数据进行处理，这样会大大提升分析日志的效率和精度。
常见的日志分析工具有著名的开源工具ELK组合，商业化产品有Splunk。
2 目的（why）
日志审计是一种消极防御策略，而笔者把它提升到第二的重要性，意图是希望读者能够充分重视日志的作用。系统的防御设施受到设计者经验能力、资源预算、运营者的运营力度等因素的影响，难免会出现疏漏。日志监控可以在安全事件发生后还原事件发生的场景和过程，帮助防守方发现和解决问题。尽管发生在事后，但在大多数情况下一次事件并不能造成无限损失。进一步而言，攻击者对系统的入侵也是由外及里，如果能在外层发现并修复系统防御的缺陷，就可以阻止攻击者进一步深入到系统内部。
3 方案（how）
3.1 日志的结构
一般情况下日志具有标准格式。根据前述的日志的定义，通常会将日志设置成key-value的格式，key也就是字段名，value是相应的内容。一条日志的最简格式应该包含以下几项内容：
- 时间： 即事件产生的时间，一般用标准时间格式或时间戳表示。有时需要注意时区转换。
- 发起者： 即造成事件发生的主体，可以是代表人的实体（例如账号），也可以是代表设备的实体（例如IP地址）。这个字段的内容应该具有唯一性和不可冒用性。
- 目标： 即事件作用的对象，也称客体。
- 事件描述： 即发生了什么事情，这个字段的定义是开放的，不同的系统可能差别极大。
- 结果： 即事件作用的结果，大多数情况下用成功或失败来描述。
- 类型：日志的分类，往往根据系统的类型和系统开发者的偏好所定义的。
日志分类是否得当影响着日志分析的效率，工程师可以根据匹配类型字段的关键字筛选出特定的日志，缩小检索的范围。由于初始的日志分析离不开人工对日志的内容进行初步的学习和查阅（毕竟没有人可以记住所有日志的内容），因此此举可以帮助工程师减少体力劳动。
日志分类没有统一的规则，对于自研系统可以通过总结归纳功能的内容将日志进行分类。例如，对于一个内部管控系统的事件可以分为以下积累：
- 账号活动： 账号及子账号的创建、注销、冻结，不同账号的关联关系建立、解除、修改，账号的相关信息、配置信息以及与其他身份信息的编辑、绑定、关联、解除、修改等事件，用户或账号组的创建、解除、增加或删除成员等，以及进行这些操作时产生的错误事件或告警。
- 权限变更： 对一个权限主体（账号、用户组等）的权限的编辑、申请、授予、变更、回收（清除），以及进行这些操作时产生的错误事件或告警。
- 对象管理： 产品实例的创建、释放、参数更改、查询，系统性能的参数更改、查询，使用周期变更、续费，以及在进行这些操作时产生的错误事件或告警。
- 资源访问：（除了所有人都有权限访问的公开数据）对敏感数据的访问（敏感数据包括但不限于身份证、手机号、邮箱、身份认证凭据、地址等），以及进行这些操作时产生的错误事件或告警。
- 一般变更： 包括但不限于一般的更改、组件更改、更新以及受到变更管理过程控制的任何其他信息，过程可以是增删改等，以及进行这些操作时产生的错误事件或告警。
- 错误事件： 一般的错误提示或告警。
3.2 日志分析
日志监控分为以下几个步骤。
- 原始日志采集
由被审计（或被监控）的软件本身来完成，它会根据自身的运行情况记录每个事件的内容。通常，日志从产生源头会先把日志记录到本地文件中，然后通过某种方式传输到日志的采集器。日志的类型一般有web日志、操作系统日志、数据库日志、业务日志等。
- 日志存储
为了适应日志数据的高速读写的要求，日志往往使用消息队列进行高速缓存，而大量日志又需要持久被存储，消息队列不适合这样的场景，因此还需要将日志在磁盘中持久化存储。
- 格式化
由于日志源类型多样，格式并不统一，必须要对数据进行格式的调整，形成统一的格式才能进一步处理。前文所述的时间、发起者、目标、事件描述、结果、类型等几个要素是基本的，其中前五个是必选字段，类型是可选字段。此外，可以根据自身需要扩展日志的字段。
- 日志分析
日志分析及有自动化分析和人工分析。自动化分析是指借助日志分析平台，根据一定规则，对日志进行匹配的过程。日志的自动分析可以进一步发展成为安全检测能力，例如主机入侵检测系统（HIDS)和网络入侵检测系统（NIDS）。而人工分析更多用在更高自由度威胁识别过程中，这个过程依赖分析人员对攻击过程的理解程度————当然这不代表日志分析需要有很多攻防对抗的经验，其实只要足够细致，没有攻防方面的背景同样可以做好日志分析。
此处发表一点个人见解：通过日志对攻击事件或疑似攻击事件（有时候不确定是否存在攻击事件，但需要排查）进行分析还原的时候，对攻击手法的理解是一方面，但更多的是需要开阔的思路、对系统运行机制和原理的理解，有时候还需要一些想象力。因为日志本身只会告诉你发生了什么，而不会告诉你对方做了什么。例如当你看到一条条登录失败的日志，只是说明有多次登录失败的情况，但是进一步观察IP、账号和时间的分布特征，才能够断定对方可能是在暴力破解登录口令。一条日志的信息是有限的，其背后可能有无数个可能性，分析人员需要多观察多收集，才能将一条一条简单的日志串联成一个行为链路，最终破解攻击者的意图。
4 需要注意的一些问题
日志监控有以下一些常规的注意事项。
- 日志的主体要唯一。
日志的主体即发起者，要固定在一个个体，或者一个实体，这样对追溯过程才有实际意义，否则一个日志后面有多个可能的行为人，那么日志也就无法最终定位。对于实体，最常见的是IP，有时候由于攻击者使用代理或网络公共出口造成访问来源不唯一的情况，对于这种情况要使用其他方法标记访问的发起者，例如使用X-Forwards-For请求头来记录IP地址。
- 时区转换。
日志记录的时间有可能是格林威治时间，使用者需要根据情况进行转换。