在很多安全分析类产品建设的过程中都会涉及到关联分析，⽐如⽇志分析、soc、态势感知、风控等产品。之前的⽂章中阐述过五种最常见的关联分析模型，在⽂中也介绍了：要想达到很好的关联分析效果，前提是对采集过来的⽇志进⾏标准化解析。解析的维度越多、内容越准确，对关联分析的⽀撑性就越强。下⾯就来介绍⼀下⽇志解析的⼀些常⽤内容。 概述
很多公司在⾃⼰的产品介绍中描述产品有多少种⽇志解析规则等等，当然，这种内置的解析规则对这类产品发挥了很重要的作⽤。但这种⽅式也存在⼀些问题：
⾸先，经过时间的推移就会发现，每年市场上都会产⽣不少的新的安全设备和型号，导致⼚家很难实现全部预制好的解析规则；
其次，很多设备会经常升级，升级后会导致⽇志种类的增加和调整；
最后，很多设备的⽇志种类⾮常之多，如果全部内置到系统中,⼏乎是不可能完成的任务。所以⼤多数的产品，只内置了部分的⽇志解析规则。⽐如思科ASA防⽕墙，从官⽹看就有好⼏百种⽇志格式，如果全都内置解，是很⼤的⼯作量，何况有时候也没有必要全部解析。
根据以上分析可以得出，只在产品中内置默认的解析规则是不够的，在很多时候需要根据客户的实际环境进⾏调整。这种情况下，⽇志解析的灵活性、准确性、扩展性就显得⾮常重要了。下⾯介绍⼀下⽇志解析中常⽤的内容： ⽇志解析关键点
标准化解析，也叫范式化解析，解析的⽬标是把⽇志中的直接信息和间接信息解析出来，作为单独的字段进⾏存储。对应数据库中就是“列”的概念。传统上来说，存储⼤多⽤关系数据库，⽐如：oracle、mysql。随着⼤数据平台的发展，最近⼏年，存储都是放在⼤数据平台上的，⽐如：hive、，elasticsearch等。下⾯举个linux下⼀条常⽤的登录⽇志作为例⼦： 从这个⽇志中就可以看到很多的信息，⽐如直接信息包括：热解焚烧炉
登录时间：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是内⽹，可以得到这个IP的部署位置、分配给哪个⼈、⽹络域信息、业务信息等。
通过上⾯的分析后，把每个字段存储到数据库中，这样⽇志的信息就很丰富了，为后⾯的关联分析、统计报表等打下了坚实的基础。
解析的关键点如上所述，但在⽇志解析的实际操作阶段有⼏个不可回避的问题：
1、预解析和后解析；
2、⾃定义解析的灵活性；
3、⾃定义解析⽀持的灵活性；
4、⾃定义解析的效率。
预解析和后解析
预解析的主要含义是，在⼊库之前把所有维度的信息预先解析出来，然后进⾏⼊库；后解析的主要含义是反过来的，就是刚开始只⼊库原始⽇志等基本信息，后⾯需要进⾏搜索、告警、报表等操作的时候，再把需要的维度放在内存中进⾏解析。预解析的优势是预先把维度存储到数据库中，使后⾯的操
作更加便捷，劣势是需要额外占⽤存储空间，并且当预先解析内容不准确或者内容有变化的时候，⽆法进⾏下⼀步的分析（⽐如账号信息发⽣了变化）；后解析的优缺点正好和预解析相反。⽬前市场上绝⼤多数的产品都是预解析，纯后解析的产品⼏乎没有。
⽐较理想的解析⽅式是预解析和后解析相结合，⽬前市场上只有少量产品⽀持这种特性。这种特性结合了两者的优点，缺点⼜相对能接受，可以达到⼀个⽐较好的平衡。但这种⽅式为什么市场上⽤的少呢？据我分析，主要的原因是这种模式过于复杂。⾸先是操作复杂，这种模式要求使⽤者掌握⼀些相关技能；其次是技术复杂，⽬前应⽤较⼴的⼤数据平台技术，对关联查询的⽀持不是特别理想，⽐如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通过IP知识库是可以知道国家、省、市、地理信息的，这个在做分析的时候⽐较有⽤；如果是内⽹，可以通过配置国家、省、市、地理信息达到同样的效果；
⾮上班时间的⽀持：国内有法定假，法定假可能存在调休等，⽽且每年的法定假都不⼀样，所以还要等到年底国家才能颁布下⼀年的法定休假的⽅案；很多客户也有会调班的情况，这种情况的⼯作⽇和⾮⼯作⽇就⽐较特殊。在很多告警规则中都有⾮上班时间的诉求，⽐如⾮上班时间登录服务器，⾮上班时间进⾏了敏感⽂件操作等，这个时候对⾮上班能⼒的⽀持就很重要。
天线制作⾃定义解析的效率
⽇志解析使⽤不同的技术对效率的影响是不⼀样的，⽬前主流的⼏种⽅式主要有模板⽅式、正则表达式⽅式等。这⼏种⽅式的效率有⽐较⼤的区别，模板⽅式的灵活性⽐正则表达式⽅式稍微低⼀些，但从效率上来看，模板⽅式⽐正则表达⽅式⾼很多。⽐较理想的⽅式是⼤部分解析⽤模板的⽅式去实现，少量复杂的解析⽤正则表达式的⽅式去实现。这样就达到了灵活性和效率之间的平衡。
上⾯列出了⽇志解析的常⽤关键内容，这些内容⽀持的灵活性越⾼越好。在实施SOC、态势感知等产品的时候，经常会花费⼤量的时间在解析上⾯，如果能灵活⽀持，可以⼤幅度提⾼效率和效果。
⼩结
前⾯介绍的是⽬前⽇志标准化解析的⼀些关键内容，可以作为安全分析产品中⽇志解析灵活性评判的⼀个参考。提⾼⽇志解析的准确性、灵活性也是⼀个⾮常复杂的过程，这部分的处理对后续的关联分析等起到⾮常重要的作⽤。⽇志解析存储后，如何在海量数据中进⾏搜索，也是个⾮常重要的问题。存储只是解决了 “有”的问题，但如何更⾼效便捷地从中到想要的数据，⽀持什么样的接⼝可以让客户快速准确地到想要的内容也是⾮常重要的，后⾯有时间再详细介绍这⽅⾯的内容。⽇志解析本⾝是⼀个⽐较复杂的话题，我尽量保证内容观点正确，但本⼈才学疏浅，⽂中若有不⾜之处欢迎⼤家批评指正。
*本⽂作者：secisland，转载请注明来⾃FreeBuf.COM
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议