58天象反入侵体系建设实践

随着互联网行业的高速发展，暴露在网络上的网站几乎每时每刻都在遭受非法的攻击和入侵，反入侵系统就成为一个能及时发现攻击或入侵行为、并能够向安全管理者提供有价值的安全警报的系统。由于入侵事件的实际危害越来越大，人们对入侵检测系统的关注也越来越多。入侵检测系统便成为网络安全体系结构中的一个重要环节。
58同城作为全球最大的一个分类信息服务平台，每天可能面临高达数百万起的网络探测或者攻击事件。那么我们是如何建立了一套完整反入侵体系呢，请让我为大家介绍一下。

总体结构

下图是天象反入侵体系的整体架构图

图：天象反入侵架构体系
1.最上面是外网环境，每条访问到58平台的流量通过核心交换机转发到集团内网的Nginx集群上。
2.下面是内网环境，流量通过Nginx网关会均衡转发到各个业务服务器的集群上，业务处理完成之后再把响应通过ngixn返回给用户。
3.内网环境的右面就是整个天象反入侵体系，从组成结构上分为三部分，黄色主题是数据采集部分，通过自研的数据传感器采集58机房内的各种网络设备或终端的日志数据；蓝色主题是数据检测部分，负责对收集的数据进行规则检测；红色主题是事件响应部分，负责对检测结果中有攻击行为的事件进行处置。

数据采集：

对于入侵检测系统，一般流量数据的收集会从网络、主机、应用系统三个层面进行采集。天象也在不同的网络设备和环境下部署了多种数据传感器进行流量数据的采集。
网络层，我们主要从集团入口交换机上的网卡镜像流量、nginx转发流量进行数据采集。主机层面，我们通过自研的HIDS主机入侵检测系统从公司各种主机资产（包括物理机、宿主机、虚拟机及容器、办公网服务器等）上进行日志采集。而应用层面，我们目前已经收集了集团一些主要业务数据库的binlog、慢日志等，并结合白盒IAST能力，对集团各业务线上流量日志进行数据采集。

网络层

交换机流量镜像

我们在内网机房部署了一组分光服务器，用来转发从公网访问的入口流量镜像，在分光服务器上面我们通过dpdk的数据包传输能力将交换机上每秒数十G的网络流量转发到一组kafka集群上面。

WAF流量收集

基于交换机流量镜像的日志采集虽然可以收集到整个集团的入口流量（包括4层和7层），但是它有一个非常大的缺陷，就是因为它处于4层交换机上，所以无法解析通过SSL加密的7层https流量，通过我们自研的天网应用防火墙（WAF），可以将经过集团LB层的实时流量进行收集。
如下图所示：

图：天网应用防火墙（WAF）
天网应用防火墙是一个可以提供实时规则检测、实时封禁能力的服务网关。我们通过嵌入式部署方式，将系统集成到集团负载均衡集群上面：首先在集团nginx集群上面部署了一组lua脚本，作为流量转发的数据传感器，流量通过http协议转发到后端的一组服务器上面，这组服务器集群主要为公司整个安全平台提供了三种能力：
1.收集流量：通过收集http和https的请求和响应流量，为入侵检测系统和其他安全能力提供数据服务。
2.WAF检测能力：可以对web流量数据进行实时检测和拦截。由于篇幅所限，这里不做过多介绍。如果各位有兴趣，请关注我后面的文章，会详细的介绍天网防火墙及WAF引擎的整体设计架构和落地实践。
3.反爬检测能力，反爬系统作为信息类网站的核心安全系统，对企业数据安全有着无法替代的作用，但是之前安全平台的反爬系统接入成本非常高，需要业务线通过接口对接的方式才能为其提供反爬服务。而天网应用网关可以直接将网络流量转发到反爬系统，正在逐步取代现有的接口调用的接入方式。

主机层

HIDS流量收集

主机流量收集，我们是通过自研的天穹HIDS系统，对主机层的流量日志进行收集。
如下图所示

图：天穹HIDS整体结构

我们在集团所有的业务服务器上部署了一个agent，用于执行主机上各种日志采集的任务，并上报给一组agent服务器集群。
agent服务器用于管理所有agent节点，监听agent节点进程的存活状态，对agent需要执行的插件和任务配置进行下发，接收并采集agent上报上来的进程日志，文件监听等日志数据，最后将日志数据推送给反入侵检测引擎进行攻击行为的检测。
目前我们的agent已经覆盖了58集团99%以上的服务器资产，每天可以在主机上面收集百亿级别的日志数据。
同时我们正在逐步覆盖办公网环境下的主机，通过流量日志，可以有效监听到攻击者通过钓鱼、木马植入等途径对员工电脑的入侵行为，拦截外部入侵者对内网环境的安全威胁。
天穹HIDS的架构设计和落地实践我们也会在后面的文章中详细阐述，欢迎各位读者关注和交流。

应用层

IAST流量收集

在应用层流量方面，除了采集了部分数据库日志等，我们还通过自主研发的基于IAST（交互式应用安全测试技术：可以通过字节码增强的方式，将运行代码中的关键函数或方法中插入探针，通过监控变量污点传播的方式，跟踪整个程序的调用过程）能力开始将应用程序中函数调用的执行日志收集上来，通过这些日志数据可以打通内部主机行为和外部网络请求的关系，有效解决了我们无法闭环入侵事件从公网数据请求到内网主机攻击的问题。

流量检测

目前业界对流量检测的方式主要分为两种：基于数据特征的检测和基于异常行为的分析。其中数据特征类主要是对认定为攻击行为的特征进行规则匹配，把命中规则的流量转化为攻击事件，以进行下一步的事件处理。而另一种方式主要是通过识别攻击者在主机或者网络上的异常事件或者行为进行分析，我们假设攻击的行为总是与正常的用户行为不同，可以通过这些不同点去检测攻击和入侵行为。
下图为入侵检测引擎的架构设计：

图：天象入侵检测引擎
入侵检测系统实现了一个可持续化运营的服务体系，并为安全运营人员提供了一个体验非常友好运营后台，用户通过数据源和元数据配置既可以将需要检测的流量数据同步接入，并且可以定义和规范所有可以过滤和检测的数据字段，为下游的检测工作提供了一个标准化的配置入口。用户可以根据这些流量日志的元数据信息进行特征和规则的配置，随着安全对抗的升级，在配置域不断创建的安全策略会在不重启服务的情况下被动态的加载到运行域。
安全运营人员需要对每一种被规则命中的事件进行处置配置，使系统可以自动根据事件进行拦截或者告警。按照洛克希德.马丁提出的网络杀伤链（Cyber Kill Chain）模型，我们把入侵事件进行了攻击阶段、攻击类型等方面相应的分类，对应各种类型的攻击场景，都会对应不同的事件级别。

预计算

检测流量在进入入侵检测系统时首先需要经过flink计算引擎进行预处理，这个预计算引擎主要有三个作用：
1.数据过滤：我们每日的检测数据量非常大（目前每日需要处理100T左右的流量，峰值QPS100W左右），这就需要利用flink强大的数据处理能力过滤大量的静态url、白名单等数据，还可以对海量的主机日志数据进行去重，以减少下游检测引擎的处理量。
2.数据标准化：flink计算模型需要把接入的原始流量进行数据转换，按照在配置域中定义的格式对数据标准化，使进入规则计算引擎的数据必须是格式化后的数据，同时需要将标准化后的数据同步到离线数据表，给离线检测模型和算法模型提供日志数据。
3.特征预计算，虽然经过过滤已经拦截掉了大量的检测数据源，但进入到规则检测引擎的流量数据还需要进行非常多的特征计算。尤其是累计类特征，是一种非常消耗性能的特征计算，除了特征匹配本身的计算消耗外，还需要借助一些分布式缓存对累计值的中间状态进行存储，当累计的结果达到某个阈值时则认为特征被命中。随着对抗场景的不断增加，累积类特征会不断增加，这必然会大大提高分布式缓存产品的存储成本。除了存储成本，计算模型在计算特征时要非常高频率的访问缓存，会导致计算引擎系统对缓存系统进行非常多的IO请求，最终会使整个系统的计算延时大幅增长，还会给cpu带来大量上下文切换的性能消耗。所以，我们希望可以有一种不需要网络请求就能够对过去一段时间的行为特征进行累计的方法。通过flink窗口集合的特性，以纯内存的方式（也可以通过高性能的RocksDB本地数据存储）来存储和计算累计特征。
如下图，以10秒内某特征出现次数为列：

图：累计特征计算模型
蓝色方框代表某一秒内特征出现的次数，时间窗口每一秒滑动一次，flink会每一秒种对过去10秒钟内的所有命中特征的次数进行累加。实时产生新的特征累计值。最终我们在把这个累计特征的计算结果和标准化后的流量一同转发到规则引擎进行规则计算，计算过程如下图所示：

图：特征预计算

规则计算引擎

规则引擎模块是执行检测规则计算逻辑的子系统，它可以对多个特征的计算结果进行逻辑运算，我们会对每种数据源配置多个特征，对攻击行为进行检测，每条流量在进入引擎后，要先进行规则解析，将每条规则涉及的特征加载到内存中。我们对计算模型进行了优化，会将正则匹配类特征和非正则类特征的进行拆分，正则类特征可以通过hyperscan进行一次性匹配，hyperscan独特的内存和性能优化机制可以大大降低我们对正则匹配类特征的计算资源的成本消耗，匹配完成的特征如果需要和其他数据源进行关联计算，还需要将匹配结果写入特征库，而累计类特征的中间结果也同样要存入特征库（时间窗口小的累计特征会在flink的预计算引擎中计算完成），最终我们将所有匹配成功的特征代人规则表达式，进行规则计算。
以往的规则计算一般都是在相同数据源下进行的，这样会很大程度上失去多个攻击场景之间的关联性，所以我们提供了跨场景关联的检测能力，来提高事件命中的准确率。单个数据源的某个特征在被命中后，会被临时存储到某个缓存中一段时间，当其他关联数据源的流量到达之后先匹配其本数据源下的行为特征，当特征命中后再和关联特征联合计算，以确定是否命中了一个入侵事件。我们以某个场景为例：当从外网访问的某条web请求的body中，带有一段可能会利用fastjson漏洞的字符串，业务系统在响应这个请求后反序列化，可能会通过一个RMI地址，加载到远程的有恶意攻击的代码，以致使系统在内网的主机上触发了一个可以反弹shell的命令。针对类似的事件单从外网的请求日志不能准确的判断攻击者是在进行web攻击。而只从内网的主机层面的日志也无法完全确定这个命令执行的代码是从外网的攻击请求导致触发的，即便确认为一个入侵事件，也无法对攻击者进行有效拦截，因为不知道是从哪个集群或者域名访问的，甚至连攻击者的IP都获取不了。这时，可以通过IAST Agent收集上来的在应用内部的函数调用日志，将通过外网请求的URL流量日志和基于主机层上的行为日志关联起来。最终确定为一个利用系统fastjson漏洞在内网主机的一次命令执行攻击。有了这个完整的攻击连，我们便可以第一时间对这些攻击行为进行处理。这个就是数据关联特征检测的作用。
整个规则引擎每天要承受上千亿次的流量检测任务，即便是在上游的flink中将相当大的一部分流量进行了过滤，但还是会有每秒数十万次的检测需求，而通过hyperscan等特征匹配逻辑是一些cpu密集型的计算单元。所以系统在设计的时候，就要将特征匹配、规则计算这些cpu密集型的子进程和流量接收、事件推送等这些io密集型的子进程进行分离。这样可以保证系统在进行规则计算时，其运行的子进程可以最大程度的减少上下文切换所带来的CPU消耗，从而充分获取了CPU的利用率。

离线检测模型

实时计算引擎具有很高的检测攻击事件实效性，但是其要求安全运营能够准确并且全面的定义出攻击者的行为特征，只有命中这些特征的流量才能被检测出来。但在实际的安全对抗过程中，攻击者往往会想尽办法绕过这些特征，演化出很多隐蔽性很强的攻击方式，从而绕过我们的检测规则。
所以我们需要从大量的历史数据中，分析出不同于一般正常用户的行为数据，通过多种数据关联或者统计的方法，挖掘出有效的基于异常行为的检测模型。
我们建立了一个涉及多个维度的数据仓库，把每天的流量或日志数据收集到离线数据存储里，并提供可视化的大数据分析工具为安全运营的小伙伴提供操作性友好的数据分析平台。在这里我分享两种常见的检测模型
1.基于URL的出入度异常检测
一些攻击者可以通过系统漏洞先把webshell文件上传到系统服务器上，以为其后面的攻击提供一个可以利用的后门。为了检测这种类型的攻击行为，我们可以对系统内所有URL出入度进行统计，所谓出入度是指，当用户从一个页面调转到另一个页面时，出度+1，被跳转到的页面入度+1，以此类推，这样就可以统计出所有URL的出入度之和。正常的用户访问，页面间跳转都是比较频繁并且多元的，而这些含有webshell的页面，因为访问者知道其具体位置，所以其出度和入度相对都很少，并且访问来源非常单一。这时我们可以在一定时间内（比如：一天）对所有的URL都计算一次出入度之和，然后根据结果对排在最前面的几个URL进行进一步分析，把访问较少并且来源IP相对固定的URL进行打标。或者直接转给安全运营的同学进行线下确认。（注意：这种计算模型需要排除那些服务接口类型的URL，一般可以通过服务域名区分。）
2.基于威胁情报的反连检测
我们可以从集团交换机上收集全部的从内网出口访问外网的流量，然后将其访问的域名或IP地址等资产和合作方或其他安全部门的威胁情报数据进行关联，被威胁情报数据关联到的资产（比如：远控、僵尸网络、劫持等）可以初步被识别为攻击源。但单纯从出口流量日志一个维度关联会有一定误报，这时可以结合HIDS收集上来的bash日志，对发出类似反弹命令的行为进行关联，准确率会更高。

事件响应

一般的安全体系建设在面对入侵事件时会通过下面几种方式进行响应。
1.告警，这个是最基础的处理流程，我们要在第一时间感知到系统被攻击的事件。
2.收集日志、取证，为以后的事件溯源留下充足的数据。
3.直接阻断或者对攻击源发起挑战，如果是合法的用户访问会通过挑战流程
4.直接攻击入侵者，这种方式的风险性非常高，误伤甚至触动到法律红线都有可能，所以一般会先线下收集攻击着的身份信息，再考虑是否攻击。
我们的天象反入侵体系在事件响应机制上基本涵盖了以上几种方式：

告警

整个反入侵体系会通过MTTR（事件的平均修复时间）指标，来衡量每个事件从行为发生到完成响应的及时性，所以需要系统在第一时间将事件通知到运营。尤其是相对严重的攻击事件，我们会绑定一个默认的通知告警，但告警级别相对较低，只会发送邮件，主要是避免运营的同学在短时间内可能接收到大量的短信或电话通知。但如果事件没有在第一时间得到处理，就可能会在后面的一段时间内反复出现，系统就会升级告警级别，来提醒运营人员尽快处理。下图是我们正在使用的一个告警升级模型。

如图，最下面的白色箭头代表入侵事件，从下往上以此表示告警级别的升级，红色方格代表有告警发生。
最下面一层为低级别的告警一般是邮件告警，只要有事件发生，就会触发告警，中间一层为中级别告警，在一个滚动窗口内，发生一定次数的告警就会升级为短信告警。最上面一层为高级别告警，在过去连续的三个时间窗口内累计出现三次中级别的告警就会升级为电话告警。
同时为了当事件产生时不会有大量重复的告警通知，系统会对同一类事件进行聚合，以减少告警数量，让运营人员避免花费大量的时间来分类这些事件，提高运营效率。

取证

当事件发生时，系统会自动记录所有入侵过程的完整信息，并将所有的事件源通过事件指纹串联起来，形成一个完整的证据链。为以后的事件源追踪或者报案留下充足的数据。

阻断

很多明显的入侵行为是不需要事后的人工分析就可以被确定的，比如有明显特征的sql注入语句。对于这些事件，系统要有能够作出实时阻断请求或者发起验证码等挑战的能力。一般的安全系统只会通过特征维度来对攻击事件进行事后响应，比如某个用户通过一个IP或者UA发起攻击，反入侵系统就会将该IP和UA加入黑名单，等下次入侵者进入时才能对其进行拦截。如果入侵者用低廉的成本更换掉资产特征，就会轻易的绕过这些名单。而我们可以通过WAF安全防火墙的实时检测和拦截能力对每一条攻击流量进行阻断，做到了事中响应。

追杀

除了事中的实时拦截能力，我们还实现了一套完整体系的策略追杀机制，做事后处置。首先筛选出那些由于规则准确率不高，没能在第一时间告警或处置的入侵事件，然后对历史数据中相关流量再进行一次规则匹配，把符合该规则的数据资产拉入黑名单。亡羊补牢，尚不算晚吧。

自天象反入侵体系建立以来，我们已经接入了同城、安居客、人人车、巧房等多个平台及业务线的数量流量。每天检测出的入侵行为高达数万起，聚合之后的中高级安全事件也有数十起，整个防御体系为集团的安全运营发挥着重大作用。我们还将持续更新迭代或集成业内最前沿的反入侵检测能力。欢迎各位安全大佬一起交流学习。