运维必看：日志标准化必须面对的4类问题和安全产品开发经验。简介关联分析涉及到很多安全分析产品的构建，比如日志分析、SOC、态势感知、风控等产品。最常见的五种关联分析模型在上一篇文章中已经介绍过了，在文章中也有介绍：要达到良好的关联分析效果，前提是要对采集到的日志进行标准化分析。分析的维度越多，内容越准确，对关联分析的支持就越强。下面介绍一些常见的日志解析内容。1.概述许多公司在产品介绍中描述了该产品有多少条日志解析规则。当然，这种内置的解析规则在这类产品中起着重要的作用。但是，这种方法也存在一些问题：首先，随着时间的推移，会发现市场上每年都会产生很多新的安全设备和模型，使得厂商很难实现所有预制的分析规则；第二，很多设备会频繁升级，这会导致日志类型的增加和调整。最后，很多设备的日志种类繁多，如果全部内置在系统中几乎不可能完成。因此，大多数产品只是内置了一些日志解析规则。比如CiscoASA防火墙日志，官网就有上百种日志格式。如果内置的要全部解析，工作量会很大，有时候还没有必要全部解析。根据以上分析可以得出结论，仅仅在产品中构建默认的解析规则是不够的，很多时候还需要根据客户的实际环境进行调整。在这种情况下，日志解析的灵活性、准确性和可扩展性非常重要。下面介绍日志分析中常用的内容：2.日志分析要点标准化分析，也叫范式分析，分析的目标是分析日志中的直接信息和间接信息，并将它们存储为单独的字段。对应数据库中“列”的概念。传统上，关系型数据库多用于存储，如oracle、mysql。随着大数据平台的发展，近几年存储都放在大数据平台上，比如hive，elasticsearch等。这里举一个Linux下常用的登录日志例子：May2217:13:0110-9-83-151sshd[17422]:Acceptedpasswordforsecislandfrom129.74.226.122port64485ssh2从这个日志中可以看到很多信息，比如直接信息包括：登录时间：5月22日17:13:01；主机名：10-9-83-151；进程名称：sshd；进程号：17422；事件类型：登录（这是根据内容分析的）；登录用户：seisland;来源ip：129.74.226.122；端口：64485；协议：ssh2。间接信息主要包括：直接信息无法体现，但可以通过客户环境的其他信息获取的信息，如：资产信息：通过设备的IP地址、设备的网域环境、业务所属系统、部署机房位置、设备管理人员等信息；账号信息：通过登录账号信息，可以获取账号授权给谁，账号是否有效，账号创建时间等信息。源IP相关信息：如果是公网，可以获取IP的地理信息，包括IP的国家、省份、城市、经纬度、IP是否为高危IP等。可以从情报中获得；如果IP是内网，则可以得到IP的部署位置，分配给谁，网域信息，业务信息等，经过上面的分析，每个字段都存入数据库，这样日志信息非常丰富，为后续的关联分析、统计报表等打下坚实的基础。解析的要点如上，但是在日志解析的实际运行阶段有几个无法回避的问题：解析前和解析后；自定义解析的灵活性；自定义解析支持的灵活性；自定义解析的效率。2.1预解析和后解析预解析的主要意义是在存储前对所有维度的信息进行预解析，然后存储；post-analysis的主要意思是反向的，即最开始只存储原始日志。后续需要进行搜索、告警、报表等操作时，会分析基本信息，并将需要的维度存入内存，供分析使用。预解析的好处是提前将维度存储在数据库中，方便后续操作。缺点是需要额外的存储空间，当预解析的内容不准确或发生变化时，无法进行下一步的分析（如账户信息发生变化）；后解析的优缺点与前解析正好相反。目前市面上大部分产品都是前分析，几乎没有纯后分析的产品。理想的解析方法是预解析和后解析相结合。目前市场上只有少数产品支持该功能。这个特点结合了两者的优点，缺点也相对可以接受，可以达到更好的平衡。但为什么市场上很少使用这种方法呢？据我分析，主要是这个模型太复杂了。首先，操作复杂，这种模式需要用户掌握一些相关的技能；其次，技术复杂，目前广泛使用的大数据平台技术对关系查询的支持不是很好。例如，Elasticsearch目前对于关系查询非常繁琐。但是，这种前解析和后解析的结合在应用上具有明显的优势，是日志解析未来的发展趋势。其他问题可以通过特殊手段解决，例如：繁琐的操作可以封装在产品中，隐藏在操作的后台；如果使用关系型数据库，很容易解决后处理的问题，但是大部分关系型数据库的处理能力不如现在的大数据平台，还有很大的差距，可以利用当日志数量不大时。2.2自定义解析的灵活性前面的分析可知，日志标准化解析在这类产品中扮演着重要的角色。如何提供日志解析能力尤为重要。目前，自定义解析有以下几种方式：通过编码实现。直接在代码中处理，编译发布，这种方式对厂商来说最灵活，但对用户来说最麻烦，因为几乎没有办法调整；它是通过配置文件实现的。比如input、filter、output等都是在logstash中配置的。这种方式解决了用户不能直接调整的问题，非常方便。但是这种情况下只能登录后台查看配置文件。如果安装较多，调整修改会有些麻烦；它是由工具生成的。比如之前版本的Symantec的SSIM平台就是通过他们提供的工具进行配置，然后导出他们产品可以识别的安装包，最后安装到平台上。这种方法本质上是前两种分析方法的结合，更加灵活。唯一的缺点是解析和查看需要工具。如果有修改或增加，需要重新部署；它是通过脚本实现的。脚本实现其实可以归结为编码实现的一种特例，但是大部分脚本不需要编译就可以直接运行。这种分析方式的优点是比较灵活，缺点是对用户要求较高，调整修改也比较麻烦；通过接口配置实现。就是直接在平台上配置，比如splunk，secilog等，这种方式的好处是比较灵活，从界面上配置也很方便。根据以上分析可知，通过接口配置的方式最好，配置文件次之，代码最差。2.3自定义解析支持的灵活性下面介绍自定义解析的具体要点，主要包括存储结构、语法支持、函数支持、多重支持、内置分析、字典支持、数据补全、上下文关联、外部知识库等。内容。存储结构：常用的解析语法主要包括XML、配置文件、数据库存储。这些存储结构可以满足大部分场景的需求。大多数XML存储结构是通过工具生成的。语法支持：目前多使用grok或者类似grok的结构来解析语法，而且大多支持正则表达式、函数等，从广义上支持。比较parsing的优劣主要还是看细节。功能支持：string：字符串提取，例如从字符串123-445-789-012中提取445-789是否方便；字符串拼接，比如将两个字段拼接成一个字段，add(sourceIp,eventId);字符串替换，如将字符串中的-替换为空格，replaceAll("-","");IF函数：比如很多日志中，0可能表示成功，if("0","success","fail”);多维支持：比如日志源IP信息，需要在target中加入解析时的IP和日志源IP；内置解析：比如http请求中的useragent，里面有很多信息，浏览器、操作系统、版本等都解析出来；字典支持：有很多有意义的数据日志中，尤其是业务日志，但是在保存日志的时候，很多日志都存储了代码。相应的名字加上；数据补全：日志中有直接和间接意义的数据，比如日志源IP，需要知道谁在使用这个IP，属于哪个部门；比如日志中有账号信息，需要了解账号的部门、姓名等信息；上下文关联：日志中有很多不一致的地方，例如，sftp登录日志中有账号信息，但是操作日志中没有帐户信息。补进去，方便进一步分析；外部知识库支持：很多公网IP可以通过IP知识库了解国家、省份、城市、地理信息，做分析时更有用；如果是内网，配置国家、省、市、地理信息也可以达到同样的效果；支持非工作时间处理等特殊逻辑处理：国内有法定节假日，法定节假日可能有交替休假等，每年法定节假日不一样，所以国内要等到年底公布下一年度法定休假计划；很多客户也会调班，这种情况下的工作日和非工作日比较特殊。在很多报警规则中，都有针对非工作时间的要求，比如在非工作时间登录服务器，在非工作时间进行敏感文件操作等。这个时候支持非工作时间就显得很重要了。2.4自定义解析效率不同的日志解析技术对效率的影响不同。目前主流的方法主要有模板法和正则表达式法。这些方法的效率是完全不同的。模板法的灵活性略低于正则表达式法，但在效率方面，模板法远高于正则表达式法。理想的方式是大部分的解析通过模板实现，少量复杂的解析通过正则表达式实现。这在灵活性和效率之间取得了平衡。上面列出了日志解析常用的关键内容，这些内容支持的灵活性越高越好。在实现SOC和态势感知等产品时，往往会花很多时间在分析上。如果能够灵活支撑，效率和效果可以大大提高。3.总结前面介绍的是目前日志标准分析的一些重点内容，可以作为安全分析产品中判断日志分析灵活性的参考。提高日志解析的准确性和灵活性也是一个非常复杂的过程，这部分处理在后续的关联分析中起着非常重要的作用。日志解析存储后，如何在海量数据中查找也是一个很重要的问题。存储只是解决了“存在”的问题，但是如何更加高效便捷的找到想要的数据，支持什么样的接口让客户快速准确的找到自己想要的内容也很重要。这方面我以后有时间内容再详细介绍。日志解析本身就是一个比较复杂的话题。我尽量保证内容和观点是正确的，但是我的才华和学问都很少。文中如有不足，欢迎大家批评指正。
