开源SOC安全运营中心的设计与实践

开源日志系统分析很常见， 现在基于开源中间件可以很有效的搭建日志中心，处理各种数据的收集与分析。 日志系统也是信息系统，从软件工程的角度来看和一般的信息系统有很多类似的地方，我们可以从服务器物理部署的角度来解释这种系统，这种更多的是从运维角度来看，我们也可以从软件系统构成的角度来分析，也可以从数据流向看系统。我们这次把物理部署和软件逻辑系统放到一起，展示出整个系统的数据流向，数据存储和处理逻辑，也展示了从系统设计到插件工厂的实现逻辑。

一、需求

现实的需求很简单，就是从我们要从收集到日志数据中，分析各种可能存在威胁，按照高中低危进行报警，并统计威胁数据，进行报警与后续动作。

简化威胁定义表同，如下：

SRC_IP,DST_IP,LEVEL,TYPE

192.168.1,192.168.6,high,php_injection

192.168.1,192.168.6,middle,xss_injection

192.168.1,192.168.6,low,sql_injection

整个系统要做的就是：

1.数据收集：生产中很多服务器的日志和状态数据，我们都可以拿来分析。如果是nginx服务器，我们可以通过访问日志发现访问中的威胁，如果部署有HIDS，我们可以分析单机服务器的状态，并与长期聚合的白名单进行比对，发现威胁。

2.数据清洗：实际我们收集了大量的各种日志数据，这些数据，我们不能直接拿来用，初级阶段的日志分析和简单查找可以做到，之后，我们需要对数据的格式进行整形，如果进行威胁分析，就要把大量不关键的信息清洗掉。

3.威胁分析：我们的数据在先期经过了整型和规范化后，可以把数据与我们的威胁特征库进行比较分析，用我们积累的威胁特征库来威胁判断，发现数据中是否存在异常的威胁行为存在。

4.威胁展示：经过数据的清洗与威胁初步判断，我们找出了，存在于日常中日志中的威胁行为，我们需要对这些数据，按优先级，威胁高低程度显现，给安装安全运维人员使用。

5.威胁报警：在实际的工作中，会有各种威胁报警产生，但是真正危害到系统的关键性威胁，是有一个优先层级的，我们往往把优先级高，危害大的威胁行为，第一时间通知管理人员，比如：生产服务器发生与危险主机的外连通信，服务器产生了，根本不该产生的SQL注入行为。

二、数据收集与存储

我们尽量从现有的生产环境中，取得对我们来说有用的数据源信息，前期开源工具起动很大的作用，比如，我们用nxlog、filebeat之类的工具在服务上架设数据agent，架设syslog server服务器，使用共享ES数据集群， 在这个阶段我们关注数据源来源，数据内容，接受的方式，部署数据agent的平台环境，这是构建数据日志信息系统必经的一条路。

数据存储：

1.Syslog服务器： Syslog是基于UDP协议的，很多设备都支持syslog日志传送，生产中有很多nginx为基础的web应用，nginx也可以发送syslog格式的日志。

2.ES数据库服务器集群：ES对于存JSON形式的数据非常友好，我们可以把syslog数据进行数据整形存到ES中。

3.Kafka队列：有时数据IO特别大时，需要一个缓存来存数据，然后再消费到ES或是ClickHouse中。

4.ClickHouse：ClickHouse支持大数据存储，可以支持SQL查询。

5.MongoDB：这种KV数据库几乎也是要用的，用于存放共享配置信息。

6.Graylog数据网关：如果我们支持通过HTTP接口去ES中取数据，要处理跨index的查询，而实际当中，如果可以把ES的操作按业务单元再抽象出一层，把对业务数据的操作，归并成大类的REST API操作，会让处理逻辑更清晰，更好维护，这种情况下，Graylog提供的REST服务就为我们解决了这个问题，Graylog提供了原始数据“流”数据组织的跨越，具体的此处不细说。

数据收集：

1.NxLog：Nxlog是支持跨平台的系统级日志收集，我们可以在Windows好部署Nxlog解决特定日志的收集问题。

2.CatKafka：catkafka可以把本地落地的日起文本推送到kafka队列中，然后从队列中消费到ES或是ClickHouse中。

3.Logger：这个就是把文本放到syslog服务器接受端口。

4.Filebeat：把文本内容发到ES中。

三、威胁分析处理

既然威胁分析系统也是信息系统的一种，我们把重点放在，如果对系统划分，如果对接，如果组织和设计程序单体这些点上。如果，我们系统是基于ES为数据库为基础核心，或是Graylog这种提供了REST API的数据查询接口服务的系统，我们可以很简单的划分组织数据，通过一套REST API就可以取得我们想要的日志数据。日志数据有了，如何识别日志中是否有威胁行为，就是要针对不同的数据源做分析工作，就是构建整威胁分析系统的大脑灵魂部分，我们要有根有据的识别出那些数据是有问题的， 威胁分析过程如下：

1.取特定业务数据源的数据。->2.与威胁规则库进行比较。->3.判断结果根据黑白名单。->4.进行威胁定级。->5.生成威胁报告。

完成这些事，关键的3个点：

1.数据源：没有数据源无从进行分析。

2.判断策略：对威胁和异常的定义，是我们判断的主要依据，实际生产中，有各种威胁，这种威胁的定义都是不一样，我们只有有这种对异常的判断依据，才能分析出什么是问题行为。

3.黑白名单：威胁报警噪音，各种系统和设备的误报其实是一直存在，我们实际事况也很复杂，应对误报比较有效的一种方式，就是构建黑白名单机制，把明显的误报都放到白名单里，把特别需要注意的，出现过问题的服务列表放到黑名单里。

数据分析：从软件系统设计的角度来看，3个角度来分析信息系统：

1.架构设计：整体的架构设计很明了，基于ES和ClickHouse为数据存储核心，围绕核心写子系统。

2.概要设计： 如果非系统的概要级描述， 从技术角度来看，我们采用插件方式组织模块，从业务上来讲，SQL注入和PHP注入的关联性是不大的，我们采用插件的方式也是为了解开模块间的耦合关系。

3.单元插件设计： 体现出单体设计大不同，可以从单体类的接口设计和目录构成来区分。

四、模块单体设计

1.单体设计：

模块对象接口设计：为了使用类工厂集中调度模块，我们预定了插件模块必须要有接口函数。

/*定义单体可处理的输入数据*/
class input_data {
string src_ip,
string dst_ip,
string payload
};
/*定义单体输出的数据型态*/
class output_data {
string src_ip,
string dst_ip,
string payload,
int level
};
class xxx_Injection {
vritual int Init(void); // 负责所有相关外部数据资源的获取和黑白名单的设置。
virtual output_data* main(input_data *message); // 主要的威胁判断和特征判断。
virtual int fin(void); // 释放相关资源
};

2.目录构成设计

我们除去预定的接口，同时约定了插件目录结构构成。

lib、src、data、config文件夹，Makefile、run.sh、logs三个文件。

lib文件夹：所有的特征库都在这里，比如libInjection这个库。

src文件夹：插件的源代码。

data文件夹：单体测试用的CSV文件。

config文件夹：黑白名单配置文件。

Makefile文件：单体配置文件。

run.sh文件：运行脚本。

logs文件：调试日志。

3.代码实现

有了特征库，预定了接口，剩下就是具体的编码，这个因项目和数据业务而不同，占不展示。

五、威胁报表与报警

整个系统起到点睛作用的部分就是威胁报告输出，最开始我们简单的约定了威胁输出了的格式：

1.威胁输出格式。

SRC_IP,DST_IP,LEVEL,TYPE

192.168.1,192.168.6,high,php_injection

192.168.1,192.168.6,middle,xss_injection

192.168.1,192.168.6,low,sql_injection

如果是在ClickHouse生产系统中创建威胁表格要比这个多，字段和展现的数据聚合是有关系的，我们简单的举例一下：

SRC_IP：攻击IP，是谁发起的IP，我们可以对应IP在表中产生地理位置信息，典型的报表形式就是用于地图跑。攻击IP是可以威胁情报进行比对的。

DST_IP：被攻击IP，具体那个服务器被攻击，一般的公司都有服务器管理的CMDB数据库，可以在生成报告时，直接找到对应的IDC、机房、管理员。

LEVEL：威胁级别，高中代危，看黑白名单和特征库的定级。

TYPE：具体是什么威胁，比如：SQL注入、XSS注入、PHP注入。

2.威胁报告的形式。

邮件： 每天早上发送昨天的攻击总结日报告、周报告、月报告等。被威胁IP的top10、被攻击总数top10、威胁聚合分布。

实时报告：提供实时查询接口，直接给出ClickHouse威胁情报的聚合信息，实时查询挂在墙上。

六、总结

目前我们把一个基于开源技术的微型日志威胁分析系统介绍完了，并没给出更具体的实现代码，更多的为基础部署架构和设计方式提代了一个思路，具体到包括单体接口实现的约定，理想状态下，按照这种模式写出的模块的大同小异，我们这么预定也是为了后续系统扩展和调试更方便。如果有人不太喜欢这种方式，其实也是没有问题，一定会有更好更高效的方式处理系统的设计和实现，然后呢？然后我们后续会更具体针对某一些特定业务，给出对应业务插件的实现。