进行日志标准化必须面对的 4 类问题

在很多安全分析类产品建设的过程中都会涉及到关联分析，比如日志分析、soc、态势感知、风控等产品。之前的文章中阐述过五种最常见的关联分析模型，在文中也介绍了：要想达到很好的关联分析效果，前提是对采集过来的日志进行标准化解析。解析的维度越多、内容越准确，对关联分析的支撑性就越强。下面就来介绍一下日志解析的一些常用内容。

很多公司在自己的产品介绍中描述产品有多少种日志解析规则等等，当然，这种内置的解析规则对这类产品发挥了很重要的作用。但这种方式也存在一些问题：

首先，经过时间的推移就会发现，每年市场上都会产生不少的新的安全设备和型号，导致厂家很难实现全部预制好的解析规则；

其次，很多设备会经常升级，升级后会导致日志种类的增加和调整；

最后，很多设备的日志种类非常之多，如果全部内置到系统中，几乎是不可能完成的任务。所以大多数的产品，只内置了部分的日志解析规则。比如思科ASA防火墙日志从官网看就有好几百种日志格式，如果内置都解析，是很大的工作量，何况有时候也没有必要全部解析。

根据以上分析可以得出，只在产品中内置默认的解析规则是不够的，在很多时候需要根据客户的实际环境进行调整。这种情况下，日志解析的灵活性、准确性、扩展性就显得非常重要了。下面介绍一下日志解析中常用的内容：

标准化解析，也叫范式化解析，解析的目标是把日志中的直接信息和间接信息解析出来，作为单独的字段进行存储。对应数据库中就是“列”的概念。传统上来说，存储大多用关系数据库，比如：oracle、mysql。随着大数据平台的发展，最近几年，存储都是放在大数据平台上的，比如：hive、，elasticsearch等。下面举个linux下一条常用的登录日志作为例子：

1. May 22 17:13:01 10–9–83–151 sshd[17422]: Accepted password for secisland from 129.74.226.122 port 64485 ssh2

从这个日志中就可以看到很多的信息，比如直接信息包括：

• 登录时间：May 22 17:13:01；
• 主机名：10-9-83-151；
• 进程名：sshd；
• 进程ID：17422；
• 事件类型：登录（这个是根据内容分析出来的）；
• 登录用户：secisland；
• 源ip：129.74.226.122；
• 端口：64485；
• 协议：ssh2。

间接信息主要包括：直接信息中体现不出来，但通过客户环境的其他信息可以得到的信息，比如：

资产信息：通过设备IP地址可以得到设备的网络域环境、所属业务系统、部署的机房位置、设备管理人员等信息；

账号信息：通过登录账号信息可以得到这个账号授权给哪个人、账号是否有效、账号创建时间等信息。源ip相关信息：如果是公网，可以得到IP的地理信息，包括国家省市、IP的经纬度、从情报中可以得到这个IP是否是高危IP等；如果这个IP是内网，可以得到这个IP的部署位置、分配给哪个人、网络域信息、业务信息等。

通过上面分析后，把每个字段存储到数据库中，这样日志的信息就很丰富了，为后面的关联分析、统计报表等打下了坚实的基础。

解析的关键点如上所述，但在日志解析的实际操作阶段有几个不可回避的问题：

• 预解析和后解析；
• 自定义解析的灵活性；
• 自定义解析支持的灵活性；
• 自定义解析的效率。

预解析的主要含义是，在入库之前把所有维度的信息预先解析出来，然后进行入库；后解析的主要含义是反过来的，就是刚开始只入库原始日志等基本信息，后面需要进行搜索、告警、报表等操作的时候再解析，把需要的维度放在内存中进行分析。

预解析的优势是预先把维度存储到数据库中，使后面的操作更加便捷，劣势是需要额外占用存储空间，并且当预先解析内容不准确或者内容有变化的时候，无法进行下一步的分析（比如账号信息发生了变化）；后解析的优缺点正好和预解析相反。目前市场上绝大多数的产品都是预解析，纯后解析的产品几乎没有。

比较理想的解析方式是预解析和后解析相结合，目前市场上只有少量产品支持这种特性。这种特性结合了两者的优点，缺点又相对能接受，可以达到一个比较好的平衡。但这种方式为什么市场上用的少呢？据我分析，主要的原因是这种模式过于复杂。

首先是操作复杂，这种模式要求使用者掌握一些相关技能；其次是技术复杂，目前应用较广的大数据平台技术，对关联查询的支持不是特别理想，比如Elasticsearch目前对关联查询就非常繁琐。但是这种预解析和后解析相结合的方式在应用上优势明显，是日志解析未来的发展趋势。

其他问题可以通过特殊手段来解决，比如：可以把繁琐的操作封装在产品中，隐藏在操作的后台；如果用关系数据库，倒是容易解决后处理的问题，但是多数关系数据库的处理能力和目前的大数据平台还是有较大差距，可以在日志数量不大的时候使用。

通过前面的分析得知，日志标准化解析在这类产品中的地位举足轻重。如何把日志解析的能力提供出来，就显得尤为重要，目前自定义解析的方式主要有几种方式：

• 通过编码实现。直接在代码中处理，编译发布，这种方式对厂家来说最灵活，但对使用者来说最麻烦，因为几乎没有办法进行调整；
• 通过配置文件实现。比如logstash中配置input，filter，output等，这种方式解决了用户不能直接调整的问题，非常方便。但这种情况只能登录后台查看配置文件，如果安装的比较多，调整修改起来会稍显繁琐；
• 通过工具生成。比如之前版本的symantec的ssim平台，通过他们提供的工具实现进行配置，继而导出他们产品能识别的安装包，最后安装到平台中。这种方式本质上是前面两种解析方式的结合，比较灵活。唯一的缺点，是解析查看的时候需要借助工具，如果有修改或者添加的操作，需要重新部署一遍；
• 通过脚本实现。脚本实现其实可以归于编码实现的一个特例，只是大多数脚本不用编译，可以直接运行。这种解析方式的优点是比较灵活，缺点是对使用者要求较高，同样调整修改起来较为麻烦；
• 通过界面配置的方式实现。就是在平台上直接进行配置，比如splunk、secilog等，这种方式的优点是比较灵活，从界面上配置非常方便。

根据上面的分析可以得知，通过界面配置的方式最优，其次是通过配置文件，最劣的是通过代码实现。

下面介绍自定义解析的具体关键点，主要包括存储结构、语法支持、函数支持、多为支持、内置分析、字典支持、数据补全、上下文关联、外接知识库等内容。

• 存储结构：

常用的解析语法主要包括XML、配置文件、数据库存储，这几种存储结构可以满足大多数的场景需求，提供XML的存储结构的大多是通过工具进行生成。

• 语法支持：

目前解析语法大多用的是grok或者类似grok语法的结构，大多都支持正则表达式、函数等方式，从大的方面都支持，要对比解析的优劣主要依靠细节。

• 函数支持：

字符串：

字符串提取，比如想在字符串123-445-789-012中提取445-789是否方便；

字符串拼接，比如两个字段拼接成一个字段，add(sourceIp,eventId)；

字符串替换，比如把字符串中的-替换成空格，replaceAll (“-”,””)；

IF函数：

比如很多日志中可能是0表示成功，if(“0”,”success”,”fail”)；

• 多维度支持：

比如日志源IP信息，在解析的时候需要添加到目标IP和日志源IP中；

• 内置分析：

比如http请求中的useragent，这里面含有大量的信息，是否能把里面的浏览器、操作系统、版本等分析出来；

• 字典支持：

在日志中有很多数据是有含义的，尤其是业务日志，但在日志保存的时候很多日志存储的是编码，这个时候需要通过字典把编码对应的名称添加进来；

• 数据补全：

在日志中有直接含义也有间接含义的数据，比如日志源IP，需要知道这个IP是哪个人在用，属于哪个部门的；比如日志中有账号信息，需要了解这个账号的部门，姓名等信息；

• 上下文关联：

有很多日志会存在不一致的地方，比如sftp登录日志中有账号信息，但操作日志中没有账号信息，这个时候需要在操作日志中把登录的账号补全进来，这样才有利于进一步的分析；

• 外接知识库库支持：

很多公网IP通过IP知识库是可以知道国家、省、市、地理信息的，这个在做分析的时候比较有用；如果是内网，可以通过配置国家、省、市、地理信息达到同样的效果；

• 特殊逻辑处理

比如非上班时间处理的支持：国内有法定假，法定假可能存在调休等，而且每年的法定假都不一样，所以还要等到年底国家才能颁布下一年的法定休假的方案；很多客户也有会调班的情况，这种情况的工作日和非工作日就比较特殊。在很多告警规则中都有非上班时间的诉求，比如非上班时间登录服务器，非上班时间进行了敏感文件操作等，这个时候对非上班能力的支持就很重要。

日志解析使用不同的技术对效率的影响是不一样的，目前主流的几种方式主要有模板方式、正则表达式方式等。这几种方式的效率有比较大的区别，模板方式的灵活性比正则表达式方式稍微低一些，但从效率上来看，模板方式比正则表达方式高很多。比较理想的方式是大部分解析用模板的方式去实现，少量复杂的解析用正则表达式的方式去实现。这样就达到了灵活性和效率之间的平衡。

上面列出了日志解析的常用关键内容，这些内容支持的灵活性越高越好。在实施SOC、态势感知等产品的时候，经常会花费大量的时间在解析上面，如果能灵活支持，可以大幅度提高效率和效果。

前面介绍的是目前日志标准化解析的一些关键内容，可以作为安全分析产品中日志解析灵活性评判的一个参考。提高日志解析的准确性、灵活性也是一个非常复杂的过程，这部分的处理对后续的关联分析等起到非常重要的作用。日志解析存储后，如何在海量数据中进行搜索，也是个非常重要的问题。

存储只是解决了“有”的问题，但如何更高效便捷地从中找到想要的数据，支持什么样的接口可以让客户快速准确地找到想要的内容也是非常重要的，后面有时间再详细介绍这方面的内容。日志解析本身是一个比较复杂的话题，我尽量保证内容观点正确，但本人才学疏浅，文中若有不足之处欢迎大家批评指正。