安全防护与大数据日志分析系统设计与实践

0x01 概要

本篇是关于构建安全防护与大数据日志分析系统的一篇实践文章，我们想发现系统中的威胁和异常行为，就要构建安全系统，来定义和分析什么是业务的异常，安全算法和策略是思想，而思想需要载体来落地实现，让威胁行为可以浮出水面。为此目地，我们创建各种安全系统，并在系统间建立联系。在业务系统的外围，加上围墙、加上护城河、加上哨卡，风险来时，起烽烟，点战火。系统也如人一样，用眼去看，耳去听，大脑去思考。

防护系统和业务系统之间的交互关系，我们分为下图几种。

第一种方式：拿到业务系统相同的流量，威胁蕴藏在正常流量中，给业务系统同时，防护系统也复制到一份，比如，核心路由分光，WAF等系统。

第二种方式：拿到业务相关有价值的日志，日志标记了业务关键的数据，日志中标记了正常的数据，也记载了威胁行为的存在。比如，日志收集系统，大数据智能分析系统。

第三种方式：系统嵌入到被保护业务的相同平台上，监控所在平台的状态。比如：各种系统Agent和数据代理Agent。

第四种方式：通过主动发起应答交互，来判断业务系统特定输入的输出是否正常。比如：Zabbix WEB监控，主动扫描，端口扫描。

下面介绍的各种系统，覆盖了大多数的交互方式，我们就是通过构建不同的安全系统，并建立其联系，进行安全防护的，分为以下几个具体的流程例子：

云WAF威胁防护：流量串并连接同时存在。
云WAF系统构成解析：一种系统的多种形态。
安全网关案例实践：数据聚合系统的门户。
负载均衡与自动运维：服务质量和安全同样重要。
端口扫描与日志分析汇聚：主动发起探测交互感官触角。
Agent与大数据聚合：面对异构系统日志的复杂性。
日志系统数据迁移：让数据流动的更顺畅。
日志监听与威胁分析：威胁就隐藏在数据中。
CH大数据系统日志接入：举个栗子。

0x02 云WAF威胁防护：流量串并连接同时存在

WEB系统最常用的防护方式就是使用WAF，WAF有多种形态，有基于流量和规则定义的软WAF，也有基本流量分光日志落地，基于大数据分析的防护系统。下图我们初期构建的WAF形态，云WAF。关于云WAF有一个常见的议题是，基于集中日志分析的WAF方案好，还是基于实时流量规则拦截的云WAF比较好? 两种WAF各有所长，排除性能的差异，基于流量分析的WAF可以实施更具体的拦截措施，如，针对POST请求的过滤，针对cookie注入的拦截等，实时拦截有其好处，基于大数据算法统计分析系统的方案，可以更好的溯源和发现群体性攻击。

随着技术的演进，突破了常见串行或是并接的连接方式，可以直接串接流量的现时，并接流量实时分析。为了可以加长威胁判断的生命周期，一般同时采用基于流量分析和日志分析的两种结合方式的WAF防护。因为采用了，基于流量镜像WAF同时将WAF和蜜罐关联协同，更好的收集威胁情报，具体的实施策略可能每家公司的方案都不太一样。

对WAF系统来说，WEB日志同质化，而对于内网环境来说，日志的形态各种和样，采用一种好的日志收集组织形式，更能有效组织起数据，上面的图，真正的把日志收集逻辑化，概念化，就有了Stream和Input这种高抽象的定义。落实到实际上，logstash、filebeat、nxlog、syslog、flume各种形式的收集都可以存在。

0x03 云WAF系统构成解析：一种系统的多种形态

有了WAF系统和日志分析系统，我们自然的就会想到如何将这两种系统协同工作，既复制了实时流量进行检测，又将日志落进行日志分析。

对于基于流量规则的WAF系统，白名单和黑名单的建立是一个比较常用的场景，最常见的黑白名单就是IP地址的黑白名单。对于WAF的规则系统来说，是否可以有效的拦截，取决于规则的条目，但任何系统都是有特定的服务内容，对于人制定的规则都不一定会覆盖所有的异常情况，对于通用威胁的WAF规则可以通用，XSS注放，SQL注入。但是针对PHP系统来说，有些Python的系统问题，对PHP来说并不一定存在。如何弥补人为规则覆盖不完的问题，打开了黑白名单的另一个思路。

因此，我们可以根据特定的业务，经过一定时间的数据沉淀，来聚类出系统的白名单正常行为，这样可以都明显属于白名单的请求不进行规则判断，或是修改拦截流程。这种自动化的白名单汇聚是有前提的，白名单是针对特定业务的，业务越复杂汇聚的周期越长，准确性也是和时间成本成正比，并且用人为辅助确认的方式，再确认自动生成的白名单是否不会误伤请求。这种白名单可以提供异常检查的效率，对于真正正常的请求给予放行，不再耗时进行异常检查。

我们现在可以很方便的基于Openresty这种开源项目，创建WAF项目，可以是用Lua写的，也可以是用C的，采用多种语言可更好灵活性的实现复杂的特性。

对于WAF的使用者来说，几乎请求中的HTTP数据都是可见的，只是在传递到真正的业务系统前，对业务系统将要处理的数据进行初期检查。异常威胁定义是用DSL或是JSON规则定义，发现请求中的问题。同时，也可以用Lua动态的实现安全策略，比如业务上游切换，同样用C和Lua都能实现。

对于WAF来说，拦截异常请求是本职工作。但如果很明显的让人看出来是一个WAF系统，就很容易的被集中试探绕过。

怎么办，所以基于串并同联的部署方案，我们除了将流量型WAF日志接入日志分析系统外，将蜜罐也引入系统联合使用，收集威胁情报，变成了安全系统与安全系统之间发生协作关联。当我们明确的识别了请求是客户的攻击探测，我们可以将请求引入一个蜜罐系统，并将黑客的攻击手法记录下来，集少成多，形成自己的威胁情报库。

0x04 安全网关案例实践：数据聚合系统的门户

基于Openresty+Nginx基础的软件，提供了多种可能拦截设置，在日常应用了，即使不用其开发一个完整WAF的功能，也可以用其代理的功能，作为一个安全防护网关使用，也可以作为一个数据查询代理人的功能。将日志收集到日志容器存储中，只是作为起始的第一步。为了数据可以被方便的检索，实现策略代码的高生产性，我们在基础ES的API上，加入高一层的抽象，在对外提供数据查询接口时，隐藏原始的索引等裸开源元素的一些概念。

通过提供这么一套，高度贴合业务的数据网关，提供便利的查询接口，让程序驱动数据更方便，让策略落体更容易，这样我们可尽量的减少冗余的代码量，集中经历实现我们策略直接相关的内容。

Syslog可以基于UDP协议快速的将业务系统的日志，集中心发送给日志收集中心，syslog在落地本地文本同时，在ES复制一份日志数据。Splunk、Graylog、ELK这些工具，可快速的查询原本散落在各个独立服务应用上的日志，集中到ES后，集中查询，这也构成了日志系统的基础工作模式。有了syslog和ES的日志数据中心，才有了数据中心提供API查询，才演化出了分析模块，大屏幕可视系统，预警系统，则不只是各种纯文本日志的简单集合。

0x05 负载均衡与自动运维：服务质量和安全同样重要

我们在构建安全防护系统时，要考虑被防护系统基本的系统结构，如果我们的系统不能与被防护系统很好的融合，是无法落体实施的。

LVS是分担了原本发一台机器的流量，分散给多台机器同时处理，是提高系统响应时间的最常用的系统结构。通过智能域名线路选择解析，NAT、DR等负载均衡方式，不同的模式，会影响日志收集中的具体关联字段。同一种系统结构，会有不同的防护系统部署方案，区别体现在部署成本的不同。正因为有这种因果联系，我们为了日志分析，在选择负载均衡方式时，也是要考量的。

明确了系统结构，找到影响业务正常运转的关键点，在关键点部署监控。

系统安全同时，也要保证系统服务的正常，所我们不仅仅要关注安全问题，同样不能抛开业务质量，基于负载均衡的系统，我们不仅仅要探活主要服务本身，还要监控服务所依赖的上下连服务。这就是我们所面临的，将服务质量和安全结合在一起考虑。

监控只是自动化运维的触角，我们通过监控业务服务的本身状态，和相关服务态，来自动变更业务配置，通过改变服务的状态，切换安全等级，当外部发生异常时，做降级，当外部服务恢复时，做自动升级，不需要人参与切换。

0x06 端口扫描与日志分析汇聚：主动发起探测交互感官触角

日志系统通过阅读业务系统的日志发现问题，是一种被动接受数据推送的过程。针对某些场景，我们尝试主动与系统交互，收集相关数据，端口扫描适用这种场景。我们通过扫描程序，收集内网服务器端口数据，形成指纹，然后通过对这些数据进行聚合，发现数据的变化和异常，构建数据结构和异常鉴别模型直接影响探测效果。

关于指纹采集存储与指纹存储，我们开始时采用了ES的存储方案，有版本控制，之后采用了Clickhouse存储方案，使用SQL做后期数据聚合发现异常量的突变。

在实际的存储过程中，数据的逻辑关系不变，IP和PORT作为基础属性，关联附加机房信息，业务信息，服务类型，负责人等信息，更准确的定位，异常发生的具体位置。

图只是简单的示意，最具体的逻辑展现，是通过SQL或抽象化的代码逻辑流程。关于聚合具体算法，完全可以另开一文介绍。这里只是展现了一个基本的处理思路。

可视化是威胁现展现的一种手段，现在很流行，但有时，某些图的装饰意义可能会大于实际使用的意义，但是，我们还是可以通过桑吉图或是端口IP关联图，展示端口的变化异常趋势。让可视化图表真正的起到有价值的作用。

0x07 Agent与大数据聚合：面对异构系统日志的复杂性

对网站型业务来说，日志形式相对单一，而实际的过程中，我们不可能只是单纯收集nginx服务日志。我们需要一种更高级的日志模式，可以把零散的工作，概念化，把数据的汇聚模式化。

ES存储模式是现在普遍被认可的方案：为了更集中业务数据处理，使用Graylog这种开源的软件，用更高级抽象出Stream的方案，把index管理等底层工作交给Graylog，把时间和索引，封装到Stream里。基于Stream，Graylog提供了数据API暴露方案。

当Graylog和ES为容器的方案，不能满足我们某些场景的需求时，我们把数据引入到Clickhouse，在这个过程中,Kafka起到了一般队列服务应该起动的典型作用。在数据存储和实时分析方面，才用什么样的方案才能达到理想的效果，要根据具体的业务量和系统规模而定，ClickHouse是独立于Hadoop这种生态的大数据解决方案，我们基于Clichouse模式的实践也是一个渐进发展的过程。

基于ClickHouse我们针对不同的数据源，进行各种可视化数据汇聚。从这个阶段开始，我们将数据，每日的变化以威胁日报的形式，邮件发送出来，我们相关于每天都可以可视化的看到内网的威胁充数化趋势。面对每天的海量威胁日志，汇聚只是工作的开始，自动化安全的运维的关键是，我们利用这些软件系统，自动自发的发现威胁，才是我们构建自动化安全系统初衷。

0x08 日志系统数据迁移：让数据流动的更顺畅

Clickhouse是一个高性能的数据，我们的系统中，可能会存在多种的数据聚合方案，我们需要逐步的将各种数据源数据，迁入到Clickhouse中，对于要放ES中的数据，我们在syslog接收时，就将数据直接转放到kafka中，这样实现一个同数据源，同时存到ES和Clickhouse中。基于开源软件的另一个好处时，社区提供了大量的现成插件，让同样场景的问题，直接用前人的工作成果，就可以轻松完成。

0x09 日志监听与威胁分析：威胁就隐藏在数据中

我们汇聚了日志、构建数据API，可视化展现、整个安全信息系统的实现，只要通过自动化的技术手段，寻找在日常流量和日志中，隐藏异常攻击。我们如何收集、如何发现、如何展现威胁的方式，决定了是否可以有效的发现威胁。

对于复杂的运营环境来说，数据源是多样性的，数据可以来之针对流量的协议解析数据，可以来至设备的日志数据，可以来至WEB服务的日志数据，各式各样。对于存储我们可以放到ES、mysql、Graylo、Clickhouse中。

数据集中后，我们就可以过滤清洗数据，打标记，单纯收集数据，只是将数据方便的集中到了一起，迁移数据简单，可以让我们有更多的选择各种数据库的汇聚生态，归到本质，无论是WAF系统还是日志系统，对威胁的定义都是由安全运维人员来制定的，我们发拟定多层次的异常判断手段。

我们引入了SQL Injection，引入各种语言，语义语法的检查，实时的发现PHP注入挂马问题，同时联动代码审计系统，发现类似的问题。一个库的背后凝聚了一种判断威胁思想，而面对海量的威胁数据，如论是基于规则，还是基于大数据，还是基于第三方库，都很难有一劳永逸的方案，可以解决掉所有威胁的发现。业务软件会随着需求更新代码，就有衍生出新的漏洞或是攻击手段，威胁也是在动态变化中，于对数据聚合系统数据流流向，系统构成的抽象层面，越抽象越类似，但具体的落地方案实施每一家都是不一样的，设计不一样，实施不一样，效果各有异同。