|
????????任何技术其实酷不酷不是最重要的，最重要的是实用。早在几年前，笔者实现了兼容Lucene语法的实时匹配引擎Tripod后，就曾考虑过是否会有这样一种场景，同时需要使用SQL+Lucene两种语法的能力来描述匹配条件，对数据进行实时匹配？因为事情较多，一时没有想到，就此搁下。
????????一晃差不多三年过去了，最近在一个项目中碰到了我的老本行--“安全日志分析”的需求。如今的日志分析已经有了专门的检测规则共享格式— sigma, 与我们早期无法打破安全知识与工程实现间的鸿沟相比，已经截然不同。工程实现者不用再更多的去关注日志的安全规则该如何编写了。在Sigma项目中，全世界安全从业者已经总结了相当数量的检测规则，可供学习使用。有感兴趣的朋友可以参见 (https://github.com/SigmaHQ/sigma)。
????????在对sigma语法及规则进行了大致分析后，笔者发现其规则主要有两大类，一类是面向单条日志匹配的规则; 一类是带有时间窗的多事件匹配规则，如： rules/network/firewall/net_firewall_high_dns_requests_rate.yml。但绝大多数规则属于第一类规则，是面向单条日志匹配的。另外，这些日志规则会更多的面向日志中的文本类型字段，分析字段中的文本内容，与我们早期主要关注日志中五元组等协议相关字段的思路有了很大的不同，这也使得日志检测可以更为准确有效。从Sigma项目中的sigmac命令可以将规则转换为ElasticSearch Query Strings(即Lucene)、Splunk等拥有较强文本检索能力的工具规则可见一斑。但经过分析我们也能发现，传统的五元组等信息，这些非文本类的字段在分析中依然有效。安全日志分析人员在过去，通常采用SQL技术对这些字段进行分析处理，并积累了大量的经验。
????????Sigmac能够将sigma规则转换为十几种不同工具的检索规则，从而可以使客户摆脱对具体工具的依赖，并且能完成相应的日志安全分析。从工程实现的角度看，这样的分析时效性较低，且会带来巨大的磁盘IO消耗。对于带有时间窗的多事件分析规则来说，这算是一个好的选择。而对于单日志的匹配规则来说，更好的选则是进行实时计算，保证能更快的发现问题，解决问题。通过对Sigma规则的分析和认识，笔者觉得SQL+Lucene的联合语法应该能够等效的表达Sigma的规则，而一款支持这种联合语法能力的实时匹配引擎能够提供更有效率的日志分析能力。这就将笔者当年一闪而过的想法重新带到了面前。
????????说起笔者做不同语法规则实时引擎的习惯，要回到近二十年前的一段愉快记忆中。当时笔者刚转Java开发，与目前IT业大牛老蔡是半徒半友关系。当时正值Arcsight在全球SIM类安全市场如日中天，其产品中折射的技术令我等神往。当时国内的安全日志及事件分析主要使用关系型数据库，对数据的分析如今日sigmac转换为各工具检索规则一样。那时所有安全厂商也皆是在数据入库后再将数据使用SQL规则分析检索出。而那时的Arcsight已经可以使用SQL语法的等同能力对安全日志及数据进行实时分析，规则可随时变更。今天这种能力看起来已平平无奇，但倒退近二十年，那可是不得了的技术。当时老蔡初为公司SIM产品架构，一心各方面追平Arcsight。他忙不过来，于笔者一个刚转Java开发的人一通忽悠，让笔者去解决这个兼容SQL语法的实时计算问题。后来按着他给的技术路线，硬着头皮一通搞竟然搞成了，也算是当年该类产品国内最早搞成该技术的团队了。
????????从此，一发不可收拾，让笔者养成了能实时计算绝不依赖底层存储计算的习惯。数年后，做了一个能够兼容更完整的SQL语法的实时计算开源项目MOQL(https://github.com/colorknight/moql)。 再后来笔者做舆情产品，需要对舆情信息进行实时匹配，看到网上的所有方案都是将匹配规则作为检索条件去ElasticSearch中查。该方案会遇到索引刷新、磁盘IO等一系列问题。于是笔者又秉承惯性思维，实现了兼容lucene语法，可实时匹配计算的Tripod项目(GitHub - colorknight/tripod: Real-time text matching compatible with lucene‘s query syntax)。现在碰到了sigma的规则场景，似乎将两种语法能力融合在一起，实现一个可实时匹配的引擎是一个不错的选择。
????????目前，笔者已经升级了Tripod项目，为其加入了一个缺省的Ansj分词器，以方便不熟悉NLP的使用者使用，但建议大家在使用该类技术时，还是要对分词有一个大致了解，否则无法更好的使用该引擎。另外，网上各种分词工具很多，使用者可自行扩展自己喜欢的分词器。笔者同时也升级了MOQL项目，并以此项目作为两种语言能力整合的主体框架。笔者在MOQL中增加了一个lu函数，该函数可以传入一个lucene表达式完成SQL+Lucene的语法联合。需要注意的是，其字段名的访问规范遵循MOQL。如下代码示例中可以看到，字段名a.content是以表别名a作为根对象访问的。
public void testLuSelector() {
? List<BeanA> beanAList = BeanFactory.createBeanAList(0, 100);
? List<Map<String, Object>> mapList = BeanFactory.toMap(beanAList);
? DataSetMap dataSetMap = new DataSetMapImpl();
? dataSetMap.putDataSet("dbba", mapList);
? String sql = "select a.id, a.name, a.num%50 from dbba a where lu('a.content:\"第5代 领导\" a.content:任命')";
? try {
? ? Selector selector = MoqlEngine.createSelector(sql);
? ? selector.select(dataSetMap);
? ? RecordSet recordSet = selector.getRecordSet();
? ? outputRecordSet(recordSet);
? } catch (MoqlException e) {
? ? // TODO Auto-generated catch block
? ? e.printStackTrace();
? }
}
????????项目新鲜出炉，可能还会有些问题，可以在项目的问题列表中给我反馈，我看到后会及时处理与回复。在使用该类功能时，最好对日志进行提前分词，这样可对日志进行多个规则的同时匹配，效率更佳。
????????希望这样的方案能够给从事日志安全分析的同行带来些许帮助，能让安全问题发现的再快一点，再早一点，能更好的为客户提供安全保障，能更好的面对国际间的安全对抗。
????????另外，直接将sigma语法作为原生语法，写一个实时匹配引擎也是一个不错的技术路线，有兴趣的朋友可以尝试一下。
|