HIDS系统存储方案探索与实践

lovedwy

0x01 HIDS的背景
+ v7 @+ b/ E5 R% B% n' ~' ?
) q& d0 m4 S% {8 P6 H& {企业有各种安全防护手段，HIDS与网络流量监听一样， 是一种威胁检测的手段。HIDS（Host-based Intrusion Detection System）基于主机型入侵检测系统。与网络监听这种形式的主要区别是， HIDS的主要数据源来至于主机本身产生的各种审计信息。
# d9 B. _9 P  |, T. ]/ N9 Y- Z$ ]各公司在构架这样的系统时， 多多少少都会面临时相同的问题，其中有一个共通地方就是审计数据的存储方案如何建设，我们回顾了一下，讨论一下HIDS的数据处理流程，与相应存储方案的优劣。
$ s9 X$ q" t1 H" \
$ g6 f: @8 x/ ?( k' q9 D0x02 HIDS与网络监听
# @5 v; ]) T# P5 Z/ n
& i% ~' Z6 A+ t1 K3 J通过在主机上安装一个审计数据收集的 agent代理程序，收集主机的相关信息。
/ m# H: I$ f$ e+ z; qHIDS系统和其他的系统都很多的相似之处，也有着明显的区别。Agent安装收集数据，与网络分光流量监听对比最大的区别，在于要在机器上装Agent，这本身是成本（部署覆盖率，监控覆盖率），而网络分光只要将数据集中，就可以分析流量中的网络相关数据。
实际上Agent上收集的数据总量，几乎占到一半存储比例的还是网络数据， 比如：网络连接数据（异常链接、网络等待等）。
, y. A  X# A4 x7 x2 h某种程度HIDS与网络流量监听， 即互补又殊途同归。
说到相同的地方， HIDS与其他的安全信息系统，有很多信息本身应该具备的组织部分，比如数据的存储，数据的分析，让安全运维人员与整个系统交互，进行安全策略的地方。
各大公司都有自己系统设计方案和建模方法， 他们用的审计数据源种类也许是相似的，大数据的存储方案也差不多， 建模的方法也是经典的建模方式，甚至有可能“攻击者”都是同一波人。
2 n) \' ^0 B- s# o2 }基于类似的背景，才可能将整个方案通用化， 产品化。没有形成产品，也可以制定一个通用的模型框架。
0x03 数据处理流程
9 u$ [, _8 o# i* }. t" ]7 ?& b/ C
: x7 h" X8 U4 W5 N我们将整个系统分成几个模块，来看整个系统：
. s# |5 t3 l3 f: A  x数据源：主机服务器上有各种审计数据，这些审计的数据是整个系统的数据分析素材。账号信息、网络链接、登录信息、服务信息、处理器信息等。无论什么平台， 这些基本的审计信息几乎都是共有的。
) E$ u8 o% S2 T我们用OSQuery举例，用开源方案说明问题， 可以脱敏。
: M" V" H7 H9 O) T( z7 D" J2 }比如，取得当前主机的端口监听：
3 e# f3 C( p0 t

& n- M+ V) U2 k, V$ C
• 
  ; x# u( n1 o8 ?1 c% V/ W; U

osquery>select * from listening_ports    pid | port| protocol|family | address    123| 808| 0 | 0 | 0.0.0.0市面上流通的入侵检测代理客户端（跨平台），很多是可以取得这些信息的。OSQuery是将主机各种类型的Audit信息，统一管理成了二维表（Virtual Table），提供了一个SQL查询引擎提供查询。
2 C* S; t. X4 I$ O+ T

OSQuery架构图

" l& p: ~8 L; X# ~数据收集：面对各种主机审计数据源，系统必须要有一个数据收集能力。
. N# ~- F" ?. M, c7 ZHIDS一个很重要的组成部分是Agent,  不只是安全系统才有Agent，像Zabbix这种监控服务也同样用Agent。数据收集Agent方法有几种方法选择：1.自行研发。2.开源方案。 
相同的目的：无论我们使用的开源方案，还是自研的Agent，目的都是一样的， 收集我们需要数据，服务器上的相关审计信息。只要能收集到我们想到的审计信息上这一点没有障碍，就达成目标。
  u8 i9 H, |) u( \9 w- l. R无论我们是采用开源，还是自研的方案，系统底层的很多都是相通的。以Linux的系统为例子看下图。
! y0 i+ M9 l8 Z  j( Y5 K
OSQuery或是自研的Agent相当于图中的go-audit， 都是系统审计日志Client客户端调用者。使用pythonaudit和caudit底层调用的API都是系统API，区别是对各种平台的支持（跨平台），Agent的性能和健壮性。

[color=#777575 !important]自研Agent优点：对于自研agent来说，我们可以控制整个软件的逻辑， 尽情的加入我们想扩展的功能。
9 Q7 Q$ h8 Z& @# w; L8 L: U[color=#777575 !important]自研Agent劣势：需要大量的平台适配，保证测试的覆盖率，不能轻易挂，没有社区的服务支持。
& J' E. C, h9 X+ [2 Z[color=#777575 !important]开源Agent优势：对于开源agent来说，开源Agent被行业充分的测试， 可以稳定的在企业各种已知的平台上，收集不同平台的数据，Linux、Windows、MAC。自研的方案各大厂都有自己的轮子。开源Agent方案：AuditBeat、OSQuery、NxLog等等，可以根据规模和平台的大小进行选择，各种入侵检测方案。
[color=#777575 !important]开源Agent劣势：需求的定制化和扩展性， 是否能适应企业审计需求，数据采集需求，后续是否会出现，软件停止维护等尴尬局面。
$ p7 H9 ~3 C9 p; ~7 S1 E

 HIDS的Agent收集的数据，之前说过，占比最大的一块数据是网络相关数据（几乎总量50%），随着时间的推移，工具的进来，“Netstat”相关信息取得也发生了变化。
4 Q8 o4 x% H2 o
1 h3 W2 K: i  e) _- q以上的图，可以看到工具是如何与操作系统交互取得底层数据，这种圆环套圆环，调用套调用的依赖关系， 如果都能简化成SQL这种DSL业务语言，简直就是太方便，把各种分类的审计信息全变成虚表，让安全人员专注于业务数据的审计和策略的构建迭代， 支持一下OSQuery这种SQL的设计方案。
还有一个Agent结点集中管理后台问题。
: D6 y0 J* ~& _5 t: J' X7 YOSQuery后台管理是有商业方案，但那不得花钱吗！所以有开源方案，如下：

[color=#777575 !important]https://github.com/shengnoah/osctrl

- L8 d0 H$ X3 E1 O! C2 Zosctrl是jmpsec推出的后台管理系统，Freebsd、Ubuntu、Debian等各种平台都支持。
如果您使用的本身是基于ELK的方案，没有Hive、Clickhouse、Spark这些什么事，还可以选择Auditbeat方案， 是Elastic同门产品，并且Elastic还直接支持了SIEM，至于适用不适用企业就具体分析。
这样像SOC/SIEM类的产品， Elastic、Graylog、Splunk都有解决方案。前两者都有开源和企业版，后者是一定数据量之内处理不要钱， 过量就要钱，
) [! t9 W* Z& F5 c  T6 H; t/ X# ?( e如果企业的数据是，几十T，几百T的数据量，不花钱是不可能的。排除软件和运维成本，数据本身的生产，消费，存储的硬件成本就很明显的硬件成本。
0x04 存储方案
2 [, V( p/ {% t
' {3 O5 e) i& ^2 J, f& v数据的存储：信息系统的一个核心是数据存储，数据库要保证基本的读写性能，扩展性，高可用性。
现在有成熟的大数据存储解决方案。

  f+ M* U* W% c; G3 o# y" X

ES集群核心存储方案（图2）

" N! _. {9 ?7 D! g* r% lES：ES集群存储，最常见大数据方案之一，在实时计算场景， ES可以满足我们实时处理数据的要求。但同时ES的成本并不低。
* l. ?% ]* b* B- n经过实践，ES集群为了稳定高可用，最少要用三台机器做结点，存两份数据的（1G的数据， 实际要用2G空间，有效使用空间低于2G），放到3台机器的不同分片， 这样才可能保证数据丢了可以找回来，要想达到数据访问的高性能，还需要配置高性的SSD磁盘。这都是钱。
只有ES不行，还需要配套的Buff队列Kafka前端机，前端消费机，只有带宽达到要求，缓存达到要求，才能保证存储服务的QPS。2万QPS至少12核左右的CPU，类推累计总消费量。
ES优点：实时计算快，生态工具多。ES缺点：成本相对贵，需要配套的运维和调优。
- M0 z+ R/ o, ^4 W3 z需要专家配合才能让整个系统表现良好，默认的设置和优化的设置区别很大。
: j% H  t3 W- t

ClickHouse集群核心存储方案（图3）

, E4 n" B% U6 W* V, ]6 AClickHouse:ClickHouse支持Mysql协议，存储空只需要原有数据的5分之1，1G的数据，200MB就可以保存(向高总致敬)。 并且检索的速度更快，相对使用机器更少。
OSQuery在收集取得审计数据时，使用的SQL结构化语言，ES也可以支持针对Index的Mysql查询，但从速度性能上看，ClickHouse最有优势（个人体验），并且ClickHouse本身就原生的支持SQL。
如果熟悉ClickHouse技术栈，Clickhouse也是一种主案，Clickhouse也同样需要前端机Kafka队列，也需要写Kafka数据，只是由原来的从Kafka写入ES，变成写入Clickhouse。

[color=#777575 !important]ClickHouse优点：存储空间小，速度性能快， 学习曲线不陡。ClickHouse缺点：生态没态ES多，需要自己实现一些服务工具链。
, ~- T3 L2 m3 Q/ u- W  P/ ~9 i

2 ~: h* v7 c% B' y  ^

Graylog集群核心存储方案（图4）

4 @: q& }: x- w! A; i! E6 AGraylog作为一个开源解决方案，本身就把自己定位成了SOC/SIM系统，新版的Graylog有审计Agent的对接，OSQuery方案，适应多种平台的审计数据采集，（Linux、Windwos、MAC），支持威胁情报管理。Graylog是基于Java技术栈的，整体打包了Kafka和消费程序，由Graylog组成的集群，整体解决了数据前端数据缓存到消费到ES上有服务流程， 还有Buff数据持久化等各种特性，这个之前糖果的实验室的公号和FB专栏发布的文章都有介绍，不太具体展开。Graylog在与ES配合的过程，需要优化配置才能有更好的性能表现， 默认的Graylog原生需要调配的，不然可能会达不到您的预期，在数据管理上造成困扰， 有时不是Graylog本身的问题，是配置方案选择的原因，需要专家积累和测试。
Hadopp集群核心存储方案
# S1 S  @: h7 v! \Hadoop：Hadoop要求存储空间是原文本的3倍， 对于中小规模的系统，几千台的服务器。如果用10T的数据存储，整个的实际的空间就要30T，而实际实时性上，不一定比ES和Clickhouse快。
数据存储的占比，HIDS几乎50%数据存储空间，都是在存储网络相关数据，其他类别数据5倍，甚至是50倍。HIDS系统的大头数据，是主机网络相关数据。

[color=#777575 !important]优点：功能强大，生态强大。缺点：基础设施构建成本高，需要专业团队运维，不是一天两天玩的转。

除了以上的方案还有Spark等其它的方案，成熟的技术在公司内部本身都有（ES、Clickhouse、Spark、Hadoop）， 最后我们根据过去的经验和当前形势综合考虑，最后选择ES方案。
 数据分析：随着积累沉淀的数据变多，存储多不意味着系统产出的收益多。基于规则模式的古典分析模式，在超大规模的数据存储过程中，存在视角上的盲点，和人力运维的巨大成本。威胁变化多样，我们需要的不只是指那打那规则策略系统，需要系统有举一反三的能力， 有联想威胁能力。基于AI、基于NLP、基于规则、基于语议分析都可以数据收集后，对原始审计数据中的威胁进行发掘。HIDS收集的数据有时可对应的算法，是否可能被有效的挖掘出数据， 不是一概而论，因为太多数据类型的审计日志， 需要挖掘建模方法，有时模型和威胁元数据是同样重要的。
  K+ T" k5 L4 {9 n5 S数据交互：整个HIDS最主要的操作者还是安全运维人员，让HIDS可以让安装运维人员配置策略，像无数安全分析系统一样，将威胁信息统计汇总。对于闭环的系统来说， 不需要过多的确认， 直接将威胁信息推给安全人员，直接响应是最理想的，这样运维人员，基本上不上后台系统，等着系统推送威胁给我们就好的理想状态。
0 M& c3 y! Y' D: f

[color=#777575 !important]“威胁告警是观点，不是结论。”一个百发百中的威胁发现系统，是需要完备的数据证据链路，提供支持，HIDS也只是数据链路上的一条。

因为证据链不全，才有了后期再分析判断的中间过程， 如果证据事实确凿，行动就行了，关键是证据链不全，最后还是需要先分析， 再决策，然后才能不瞎行动。
' F2 q  d" G( S0 p5 Z. Q( e0x05 总结

经过几种方案的对比， 最后我们在ES、Clickhouse、Hadoop之间选择了ES集群为中心的数据存储方案，只是在目前这个阶段，基于当前规模和成本的计算，综合数据威胁分析实时性考虑，我们选择了一个相对比较适合我们场景的方案，不同企业具体情况具体分析， 但是选案的原理和资源计算方法是可以参考的。
) @, @/ l# ^0 t! J" b对于那些，没有成本预算自研HIDS中小型公司，可以选择多种开源方案解决OSQuery、AuditBeat、OSSEC总有一款适合您。
9 H0 Y) G3 s1 \+ k. U* J2 r参考：
! O2 Q/ |2 p! ?8 U
5 [2 B! C0 R9 S  R, Z; j- lSyscall Auditing at Scale

[color=#777575 !important]https://slack.engineering/syscall-auditing-at-scale-e6a3ca8ac1b8
, i3 v. w$ X6 B3 m0 n

*本文原创作者：糖果L5Q，本文属于FreeBuf原创奖励计划，未经许可禁止转载

, f+ c$ X) b. y5 P$ b: G精彩推荐
6 L6 Y% T9 f. H, h
/ h" a8 t4 G  @- u, O( u: x

( e. a/ w/ \: k! W

来源：http://mp.weixin.qq.com/s?src=11&timestamp=1577106005&ver=2052&signature=TOp2rWi5tKlIEFwUHz3u7DT8-J9KpsMHyuuWNIrRy21lhopqTD0ukz7SndieKHTIernqgs3kZKI6rwJOD58oI59HVhFJ3n*jFdBv00VgP9CBeoI1-d9VRMCWrgAFjhsb&new=1
( a0 ?6 l/ ?. z- {. y) r7 k2 h免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！