日志分析系列(一):介绍篇
本系列故事纯属虚构，如有雷同实属巧合
小B是Q公司的安全攻城狮，最近Q公司不太平，出现了好几次的安全攻击事件。可在事后小B却找不到被攻击的真正原因，于是领导下命令给小B，必须做到对攻击事件的检测与溯源，不然就可以卷铺盖回家了。
听到此话的小B冷汗连连，找到最近几次攻击的记录文档，认真剖析未发现真相的原因，总结如下：
-
系统未记录日志：部分系统无日志信息可用。
-
日志信息无备份：日志被攻击者删除，或因存储空间不够被删除，无备份日志可用。
-
采集维度不详细：日志格式为默认配置，不够详细，不能从中提取太多有效价值信息。
-
采集信息不准确：类似IP等用户识别维度信息不准确，不能定位到攻击者。
-
记录结果不统一：相同字段在不同的日志中类型不统一，无法进行日志关联。
找到了原因，小B就知晓了要想解决这些问题，就必须实现统一日志分析平台。拥有了这个平台，那么在下一次面对攻击时就不会那么两眼一抹黑了。
小B说目的
建设统一日志分析平台，小B需要先向领导汇报得到领导的支持。首要就是向领导说明搭建统一日志分析平台的目的。
日志分析在企业内部是一项很基础的核心技术，不光运用在安全团队中，还运用在IT研发团队、业务团队中。不同的是目的：
-
从安全来看：安全团队提取日志分析主要是为了发现未知安全事件、对已知的安全事件进行溯源分析。还有另外一个很重要的目的是国家层面的监管合规要求。
-
从IT研发来看：企业内部的非安全技术团队做日志分析主要也是为了发现位置问题、分析已知问题，主要集中在：系统监控、APM(APM包含了研发团队关注的所有监控项)。
-
从业务来看：业务团队对于日志分析的需求，更多集中在风险控制、运营推广、用户画像、网站画像等方面。
日志躺在硬盘中毫无价值，通过日志分析技术能实现日志信息的价值化。日志价值体现程度越高，也能变相反映公司的技术实力。
日志分析的更新换代
日志分析并不是一项新颖的技术了，虽然现在有人给它换了很多新衣。但是对于只有较小安全团队的公司来说，不要追求高大上的地图炮，需要的是实际解决问题的思路或工具，哪怕是一段只有20行的命令脚本都可以。从古至今，小B将日志分析经历划分成了4个时代：
石器时代： 这个时代大家在做日志分析的时候更多依靠的是Excel、终端命令(awk、grep、sort、uniq、wc等)。在这里推荐大家阅读 Web日志安全分析技巧 与 Web日志安全分析浅谈(https://xz.aliyun.com/t/1121)，其中提到了关于使用命令来进行安全分析的案例。
铁器时代： 这个时代大家在做日志分析的时候更多依靠的是脚本工具(自写工具)、简易交互式工具(logwatch、logparser)等。
工业时代： 这个时代大家在做日志分析的时候相比前两个时代已经有了太多的进步了，各种开源、免费、付费的软件可供选择，比如：Elastic系列、Splunk、ArcSight等等。
未来时代： 这个时代大家在做日志分析的时候我不知道会用到什么，但是从目前来看，机器学习、人工智能应该是核心之一。
小B是这么认为的：不论我们处在哪个时代，过去的思路与工具都有着不可替代之处。因为那是一个时代经历了优胜劣汰之后留下的优秀产物，本质上新时代的产品也是经历史长河演变而来。(内心OS：有小部分的工具或系统是辣鸡的，大家慎用！)
如何实现统一日志分析平台
>>>>
统一日志分析架构
实现统一日志分析平台在不同企业中各不相同。主要表现在：平台对企业的适用性、企业自身的技术能力、技术团队对产品的优劣选择不同等。但是核心的架构基本还是如下图所示：
>>>>
实现统一日志分析难点
-
难度1：技术难点
-
复杂的网络环境如何来采集信息？
-
繁杂的日志类型如何定义统一解析规则？
-
TB甚至PB级别的日志如何快速查询？
-
地图炮无用什么才是最好的展示方式？
-
每天被报警打晕，如何自救？
-
难度2：人，主要体现在没有良好的沟通撕逼撕不过。
-
推动力度不够：老板不重视或伪重视；
-
推动阻力太大：别人是老板，你是工程师
小B作为一个安全工程师，理所当然的认为安全是最重要的(其实这是错误的)，但是小B也会灵活变通勾兑IT研发团队、业务团队一起推动，人多力量大。虽然大家的分析目的不一致，但是统一日志分析平台架构是大家都需要的。
>>>>
安全场景下的分析思路
如果硬要给安全场景分类的话，小B会分为：已知场景和未知场景。在已知场景中，我们常用的分析手法包括：基于正则表达式分析、基于统计聚合分析、基于关联分析；在未知场景中，我们使用的分析方法主要是数据挖掘，从数据中挖掘未知的东西。
基于正则表达式分析
此类的分析方法主要适用于常见带有特征的攻击场景，比如：
-
特定Payload场景：SQL注入、XSS、Bypass WAF等，可以总结为基于规则库进行分析；
-
特定关键字场景：爬虫(特定UA、Cookie等)；
基于统计与聚合分析
此类的分析方法是：尽可能在不同维度下进行统计与聚合，根据统计聚合结果挖掘有价值的信息。最常见的就是分析场景就是：单位时间内的某个客户端对某个服务端的操作信息。
基于关联分析
此类的分析方法，需要有一定的基础数据，通过关联分析来举一反三，比如
-
与外部情报关联分析：企业可以购买威胁情报(微步、威胁猎人)来关联内部的日志数据从而发现风险，比如：通过购买恶意域名情报，然后通过办公网出口流量与日志分析看是否有访问记录，如果有就可能代表内部有人中了木马或病毒。
-
与内部情报关联分析：以前面分析技术得到的结果作为依据标准来进行关联分析发现其他风险，比如：找到了一个恶意的用户IP，然后在日志分析系统中查找该IP的其它行为，说不定有意外收获，在IP这个维度要注意IP自身的属性信息。
数据挖掘分析
-
异常场景分析：通过聚类、分类等数据挖掘方法分析单点异常、上下文异常、集体异常等。
-
未知场景分析：通过机器学习算法识别0Day、Bypass技巧等。
日志分析的思路：思考各种场景，合理利用已有信息与可获取信息从而让信息产生价值。
>>>>
优化日志平台
统一日志分析平台不是简单的有一套系统，做个大屏biubiubiu就完事了的。搭建日志分析平台是一项集技术、沟通撕逼、运营的老大难项目，50%的人死在了起点、30%的人死在了中途、15%的人死在了成功的前一步，只有5%的人做好了这个平台。
日志分析坑太多，如果领导支持人力与财力，就可以考虑买一套产品再有人来维护是最好的状态！如果领导不支持人力与财力，算了吧！利用运维的东西做一做也挺好。
统一日志分析平台的工作在小B看来可以简单分为2个阶段：
-
平台实现：
日志规范化 --> 日志采集 --> 日志存储 --> 日志分析 --> 日志展示 --> 告警实现，在这些部分中，小B认为日志规范化是很重要的一步，因为这个步骤是牵扯到与其他团队的配合最多的一步，尽可能的把要做的工作集中一次性完成(虽然这是不可能的)。 -
平台优化：这个阶段是对平台实现中的每一个步骤进行优化。
对于平台优化又可以简单细分为(小B能想到的就这么多)：
-
规范优化
-
日志种类优化：系统、服务、应用、业务等日志都需要采集；
-
日志字段优化：采集尽可能多且有用的信息；
-
日志格式优化：从TXT到JSON(从JSON到Protocol Buffer)；
-
采集优化：从Rsyslog到Logstash、从Logstash到Flume、Filebeat(主要是对客户端系统性能影响优化)；
-
传输优化：从无到有的消息队列、从不可靠传输(UDP)到可靠传输(TCP)、从无加密到加密(SSL)；
-
存储优化：从文本存储到数据库存储、从数据库存储到分布式文件系统；
-
分析优化：从单一场景到多场景、从经验之谈到数据分析技巧；
-
展示优化：从地图炮到直观安全风险展示、从单一到丰富；
-
告警优化：从每天报警不断到分级别告警、从单一告警方式到多层次告警；
-
架构优化：从单机到集群、从单集群到分布式集群；
**关键是：**持续运营，能力沉淀、数据沉淀
以上就是小B给领导汇报关于统一日志分析平台立项报告中的一些关键点了。
也许是因为开篇吧，十分不好写！日志分析这个话题以小B目前的水平也很难写的深入，大家将就看一下。
☞ 下一篇：小B就要开始实现统一日志分析平台了！
-HISTORY-
