此HIDS自研面对中小型企业,一般服务器百级。如果对集群部署,系统获取更加完善灵活,服务量级较高可以参考:

  1. 驭龙
  2. 美团
  3. 点融
  4. Wazuh

架构

架构采用,一般中小型企业安全人员较少,重视度远不如大型企业,多见“一个人的安全部”。架构不适宜过于复杂,后端开发可以根据实际采用python,go,Java等。web框架,有django,php都可以使用。消息的被动或者主动获取又涉及到是否需要使用ES或者ActiveMQ。这一点后面再讨论。此处使用平安集团分享的一个预警结构流程。

1578622803994.png

Agent

agent的建设是整个流程中最费劲的事情了。需要以下几种特点

  1. 可维护性高,获取信息稳定
  2. 对系统侵入小,适合多种系统的多版本内核
  3. 通道信息安全,进程可维护
  4. 支持灵活检测,负载小
  5. 便于一键化部署

对于互联网大厂采用的方案多是hook,audit等。hook的侵入性比较高,在没有专门的定制化开发下,中小型企业使用的成本比较高,之前在试图部署驭龙的时候就发现太容易对系统造成崩溃。这是生产系统不能接受的。

如何选择侵入小,兼容高,信息全,成本低就是主要考虑了。

对文件监控上比较好的开源监控也就是aide和inotify-tools。aide是对文件的hash比较来判断文件的改动,无实时性。inotify是实时监控,倾向于此。在实际系统测试上,对各个Linux的发行版兼容性也可以满足需求。

其他信息的获取上,倾向于python库psutil。这是Linux的运维的第三方模块。可以收集很多Linux系统的信息,进程,网络,用户,内存等。可以跟主机做实时的信息获取。而且实现简单,方便跟inotify做联动。

信息推送上,如果考虑实时性,可以使用agent主动推送的信息实现方案,但这样做会面临多服务的压力,延迟,丢失。所以需要对信息做消息处理,就需要消息队列。采用何种方式根据需求选择。

agent被动提供消息,只需要把获取的信息提交到某个特定的地址。比如,此处使用类似ES的信息提供方式,agent获取信息后交给flask以json来展示,server对agent来做守护任务来被动获取。这样,实时性较低,需要对获取的信息做过滤处理。但消息获取上比较稳定。

Server

server端主要做信息的展示和处理整合,此处直接使用python-django。如果使用被动获取信息,需要server做定时任务,采用任务框架APScheduler来管理定时任务。

简而言之,实现方便,操作简单。server端还真是没有多少值得谈论。

功能

虽然名为HIDS,但还是需要一些其他功能,只是agent传输的文件监控和主机的信息仿佛作用较低。而且在监控中可以看到,当服务文件改动较多的时候,提示的预警信息过于频繁。分析较为困难。所以为了便于发现其中存在的问题,使用文件扫描功能,比如Linux下的河马webshell扫描。调用扫描来对预警文件进行判断,但扫描识别率测试中,只有百分之六十到七十左右。识别率是否能接受就看个人情况拉。

同时,对于感染型后门,我增加了一个对威胁信息的检测。从以下地址获取感染IP:

http://osint.bambenekconsulting.com

https://feodotracker.abuse.ch

通过网络连接来判断是否有类似的感染发生,对于IP的获取同样使用定时任务。

web日志

目前想通过web日志的方式来做检测告警,比如,大量文件的变更时,跟web日志做查询,来判断是否是一个外部创建的文件。通过ES日志服务器来整合,但在实现中发现,不一定创建成功的文件就一定在日志中,就像文件重命名。所以此功能具体的实现还有待考究。

如果后期可以发现一种webshell识别较高的情况,可以使用扫描价web日志联合告警的方式来减少预警的情况下,提高准确度。

由于使用上没有采用agent主动推送,没用参考消息队列,后期准备改为推送和消息队列形式,同时增加对文件检测的识别和减少告警。同时希望agent的信息获取可以使用audit的方式。

以下是代码实现,简单到会django就可以做二次修改哦

zeru





# Open Source Security  

tocToc: