日志解析新思考

    最近蒙朋友关照，一起合作了一个日志审计的项目，让我有机会重新思考与审视日志解析相关的技术问题，重新系统的梳理了下近二十年从业中经历中积累的经验与教训。

• 日志解析在日志审计中是否重要？

    这是一个很见仁见智的问题。主要取决于日志审计希望达到的效果。如果日志审计的主要目标在日志留存和检索溯源上。那么日志解析没有那么高的重要性。但如果希望能够对日志进行更深入的分析与统计，那么日志解析就变的必不可少。众所周知，不同应用产生的日志，其书写格式、表述习惯存在很大差异。另外，日志通常是非结构化或半结构化描述的，也不利于进行分析处理，故需要使用日志解析技术将各类日志进行归一化处理，实现日志结构化形式的统一表述。经过归一化处理的日志，可以实现跨应用系统的综合分析，深入分析，发现隐藏在日志信息中的行为特征、事件线索等。

    日志解析现阶段看，仍是高度依赖人工处理，这无疑会带来巨大的人力成本。这些成本很多时候决定了审计产品侧重的功能特性，弱化分析能力的产品，强调在日志采集的性能及检索性能上会有很大的优势；而强化分析能力的产品，则更注重审计的应用效果与效率。能否鱼与熊掌兼得？--很难！开发者总要不断的在二者间权衡。对客户而言，其实适用最好，毕竟每个客户的情况也不太一样。在这里要提一下Splunk，它的产品给了业界很大的启发，首先，它提供了日志留存及高效检索的基本能力，并采用了自然语言处理的相关技术，方便用户回溯查找。同时，它也保留了可以进一步进行日志扩展解析的能力，方便在此基础上构建更深入的分析应用。当然，用好它不容易，它对使用者有一定的要求。

    另外，抛开日志解析在日志审计中是否重要不谈，日志解析对于SIEM(Security Information & Event Management)、安全管理平台、态势感知等产品绝对是不可或缺的基础工作，这几类产品都是高度强调分析效果的产品。

• 日志解析的目的是什么？

    日志解析的目的对于从业者来说都不陌生，在上文咱们也提到了些。但这里我还是想深入讨论下。在讨论日志解析之前，我们先讨论下什么是日志吧。我们这里所讨论的日志是计算机领域中的概念，因为用词差异，我这里援引一条百度百科关于系统日志的定义：

    系统日志是记录系统中硬件、软件和系统问题的信息，同时还可以监视系统中发生的事件。用户可以通过它来检查错误发生的原因，或者寻找受到攻击时攻击者留下的痕迹。系统日志包括系统日志、应用程序日志和安全日志。

    这个定义也许不够准确，但它基本反映了我们通常情况下对于日志的认知。日志是一种记录软、硬件行为及状态的信息形式，可以辅助我们完成故障定位、行为审计等工作。它因为记录的内容差异，可以分为系统日志、审计日志、安全日志等。

    日志在内容上虽然有差异，但是所有日志都至少含有两个最主要的信息，一是时间，二是级别；时间在这里不做赘述了，而日志级别更多是用来告知日志响应者，日志需要被处理的紧迫程度。因此，日志的级别是一个很重要的信息，日志产生者对此信息如果定义的不合理，就可能造成很大的隐患或资源浪费。除去以上两个共有信息外，还有部分日志会包含有日志类型的信息，该信息也是一个重要信息，它能直观的告诉使用者，哪些人需要关注及处理这个日志。

    日志在书写方式上没有也无法做到有统一细致的标准，因为没有任何一个日志标准能够细致的适应不同应用系统产生日志的要求。但即便如此，行业内还是出现了几款日志标准，一定程度的统一了日志的书写方式。其中最具代表性的就是Syslog标准。Syslog的相关标准包括有2001年的RFC3164以及2009年RFC5424。RFC3164的日志格式如下：

日志格式	PRI HEADER MSG
日志样例	<30>Oct 9 22:33:20 hlfedora auditd[1787]: The audit daemon is exiting. PRI -- 30 HEADER - TIME -- Oct 9 22:33:20 - HOSTNAME -- hlfedora MSG - TAG -- auditd[1787] - Content --The audit daemon is exiting.

       由上表可以看到，Syslog标准主要由PRI、HEADER以及MSG三部分组成，其中每一部分在实际应用过程中又做了进一步拆解。但日志中传递的核心信息内容是由Content部分描述的，这里采用的是自然语言描述方式，没有对内容进行再进一步的拆解定义。

       在Syslog标准之后，安全行业内又出现了WELF(WebTrends Enhanced Log file Format)日志标准，该标准采用了键值对描述方式，同时定义了常用的信息字段，将日志以拥有结构信息的文本化方式进行了表达。如下例：

日志样例	id=firewall time="2000-2-4 12:01:01" fw=192.168.0.238 pri=6 rule=3 proto=http src=192.168.0.23 dst=6.1.0.36 rg=www.webtrends.com/index.html op=GET result=0 rcvd=1426

不少安全厂商就采用了格式来描述安全设备的日志，我的老东家天融信就是其中之一。

    除去以上两种标准外，还有厂商采用CSV、Json、W3C等各种不同格式与标准书写日志的，但也有很多厂商拥有一套自己独特的书写格式，如下：

日志样例1	<11>Jul 16 18:43:17 localhost waf: tag:waf_log_websec site_id:1526350602  protect_id:2526350633  dst_ip:10.16.0.14  dst_port:80  src_ip:10.16.5.251  src_port:53614  method:GET  domain:218.65.204.251  uri:/favicon.ico  alertlevel:HIGH  event_type:Info_Leak  stat_time:2018-07-16 18:43:16  policy_id:3407879  rule_id:0  action:Block  block:No  block_info:None
日志样例2	<142> 1 10.199.199.22 2017 Dec 28 16:16:00 FW 350560409 NAT444:SessionW 1514448960|1514448961|118.184.178.162|118.184.178.162|42895|221.207.254.61|1433|6
日志样例3	##TIME=2020-07-14 10:22:31##PROCESS=IncidentSvr-Per[19467]##BLOCKED=DISABLE##BLOCKEDSTATUS=UNSUCCESS## INCIDENT_ID=37636##INCIDENT_TIME=1594693341000## PROTOCOL=HTTP##method=resquest## RECIPIENTSADDR=172.168.81.43##RECIPIENTSPORT=80##RECIPIENTSDOMAIN=http://172.168.81.43/lib/testcases/tcEdit.php## SENDERIP=172.168.80.2##SENDERPORT=62917##Serverty=high##SUBJECT=##TARGET=
日志样例4	<12>Jun 22 12:42:16 (none) : {"dt":"VENUS_IDS_0700R0200B20140925112801","level":10,"id":"152325963","type":"Alert Log","time":1529642536707,"source":{"ip":"1.1.1.99","port":0,"mac":"14-14-4b-82-72-b6"},"destination":{"ip":"192.168.7.2","port":0,"mac":"00-10-f3-36-c1-c8"},"count":51,"protocol":"TCP","subject":"TCP_SSH尝试登录","message":"nic=1;数据长度=16;TCP数据内容=00 00 00 0c 0a 15 74 61 db 09 62 80 6a 61 5f 7f;"}

    日志的书写格式千变万化，而将这些千变万化的日志书写格式统一为同一个书写格式，是做日志审计或日志分析从业者一直面临并去实际解决的问题，这也是日志解析工作承载的主要工作内容。但日志解析不应该只是简单的统一日志的书写格式。在过去的实践中，经常会发现很多系统的日志字段无法被映射填充的情况，为了能够尽可能的留存信息，类似宽表结构的全日志书写格式诞生了。这些宽表结构可达2～300个字段之多，存储时会构成一个典型的稀疏矩阵，存储效率、应用支撑都无法做到最优。究其原因，是因为在日志解析时，仅做了简单的信息映射，形式上统一了日志的书写格式而已。

    现在我们回顾一下日志的定义，可以理解到它是一种承载了特定内容的信息。其内在传递的信息才是其最核心的部分，而不是日志的书写格式。我们可以用各种方式传递信息，如图画、音乐、中文、英文…，这些只是传递信息的方式，而对于我们而言，信息本身才是最核心的，也就是日志所传递的信息对我们才是最重要的。这也是日志解析真正的目的，即将日志中所蕴含的信息，从一种书写格式转换为另一种便于进行日志分析的格式，从一种信息编码格式转为另一种编码格式。

    早期采用的字段全映射的日志解析方式是一种被动的等同语义转换方式，形式上它保留了被转换日志中全量的语义，但实际上由于宽表结构本身很多字段含义模糊，这种映射其实是丢失了部分相关语义信息的。简单的通过字段名相同进行解析映射的方式是一种常见的可能造成语义丢失的行为。另外，这种解析转换，即使语义被无损的保留下来，但由于是被动完成，缺乏主动理解，在构建上层应用时，也无法充分的应用和展示出蕴含在日志中的真实意义。

    日志解析应该采用更为主动的方式，在保持语义不变的基础上，完成书写格式的转换。当然，这也将耗费更多的解析成本，但从未来可能对应用产生的支撑效果看，这应该是值得的。因为只有这样，才能真正将日志蕴含的价值发挥出来，为用户带去价值。

• 归一化日志结构如何定义？

    日志解析的主要工作是在保持日志语义的基础上，将日志从各种书写格式转换为统一的书写格式，即解析为归一化日志。纵观从业这些年，日志解析主要由两大类工作组成，一是如何提取不同书写格式日志中的有效信息；二是如何填充这些信息进入统一的书写格式。要开展这两项工作，首先要解决的是归一化日志的结构定义问题，即日志的统一书写格式。这个结构的定义将指导解析人员了解需要提取日志中的哪些信息，并如何将这些信息填充入归一化日志结构。同时，这个结构也决定了上层应用系统可以实现的功能的边界。

    归一化日志结构的定义应该兼顾从上而下及从下而上两个方向上的需求。从上而下需要考虑到应用系统分析及管理的目标是谁，是人、物、事件还是其他对象；自下而上需要考虑到日志中实际蕴含的信息有哪些？这些信息有哪些可以为应用分析所使用。自下而上的结构定义方式将是一个长期有效的方式，因为技术在不断更迭，日志信息中也会不断承载更多新的内容，这些新内容将驱动归一化日志结构的变化，从而进一步影响业务层的分析管理能力。而自上而下的定义方式围绕产品提供的功能边界来定义，它可以进一步明确归一化日志结构中的有效部分，精简归一化日志结构，使得更容易进行日志解析相关工作。

    业内翘楚Arcsight利用其对安全日志(事件)的深度理解，定义了其独树一帜的归一化日志结构。这个结构为其构建上层强大的数据分析与管理能力提供了有力的保障。早期我们曾借鉴其强大的归一化日志结构的表达能力做为我们的结构基础，但由于无法窥探其构建此日志信息模型的全部逻辑，在实际应用中碰到了很多麻烦。日志解析时，时常会碰到填充时有歧义的问题，此时缺少冲突解决的原则；还会碰到信息的取舍问题，因没有合理的取舍原则，因此在既有的日志结构上做了很多无效的扩展。

    因此归一化日志结构的定义不只是一个信息模型的定义，它还包括围绕该模型的一系列数据处理原则。只有在这些原则的指导下，才能有效的开展日志解析的工作，保证归一化日志结构的解析质量。

• 一种基于主客体的日志结构化信息模型

    随着技术的发展和解析工作经验的积累，发现早期基于Arcsight的日志信息模型已不能很好的解决后续出现的UEBA、APM以及数据安全类业务的分析工作了。它不能很好的描述基于用户的行为，状态信息、数据实体信息等信息了。其信息模型早期包含有近200个字段，为解决类似问题需要不断的扩充信息模型的字段，后来有了近300个字段。致使字段间很多时候会出现歧义现象；应用开发时也无法知道哪个字段的数据是被有效填充的；数据出现了明显的稀疏矩阵问题，这对数据的存储及处理效率都有了很大的影响。

    如何能够定义一种信息模型可以在保持语义且信息字段基本收敛的状况下，完成对日志的结构化统一描述，那么这将是一种比较理想的信息模型。由于我们已知，日志是用来传递系统中特定内容的信息。而我们日常最熟悉的传递信息的手段是语言，语言学也已经为我们高度抽象了一套语言的结构化表述方式—“语法结构”。在语法结构的基础上构建日志信息模型一定可以做到信息无损的转换。因为，我们在日志中所传递的任何信息都一定是可以通过自然语言进行描述的。

    由此，借用语法结构中最常见的“主谓宾”、“主系表”（注：借用英语语法，对于中文”这朵花很漂亮!”，我们不容易找到它的谓语，而英文表达下”The flower is very beautiful!”，我们能清楚看到”is”这个系动词，这将更有利于我们去解析日志中类似结构的信息。比如常见的状态类信息，都可理解为这类结构。）结构，构建一种基于主客体的日志结构化信息模型。该模型包含四个核心要素：主体、行为、客体、状态。主体表示语法结构中的主语；行为表示语法结构中的谓语或系动词；客体表示语法结构中的宾语；状态表示语法中的表语。在此信息模型的基础上，需要依据系统的分析需要，定义出主体、客体的类别。比如：需要包含对数据实体的分析，那么主客体定义就需要包括类似文件、表格等数据对象；如果仅需要对网络行为进行分析，那么主客体定义只要包括：设备、IP、域名等网络资源对象即可。

    日志中主客体的定义与抽象完全与分析系统要分析、管理的目标对象相关。同样一条日志，在不同条件下其主客体的识别会有不同。如一条主机访问日志记录了：“机器A访问了机器B上的B1数据表”。主体我们可以很快识别到是“机器A”，行为是“访问”，但客体是“机器B”还是“数据表B1”呢？这取决于分析系统是否会关注“数据表B1”，若系统并不关注“数据表B1”，即系统不将数据表B1作为其分析管理的对象，那么客体就是“机器B”反之就是“数据表B1”。那么客体填充了二者任何一个之后，另外一个信息应该如何保留？其实，主客体信息模型的核心要素是这四个，围绕这四个要素还应有其它的信息字段，如何设计这些字段就需要跟分析系统需求紧密相关了。

    篇幅有限，有机会再深入探讨如何定义出一套基于主客体信息模型的，适用于日志审计或分析的通用日志归一化结构及相关的日志解析原则吧。