本文作者:Pamela@涂鸦智能安全实验室
前言
先挖个坑,这段时间一直在学习主机入侵检测的相关方法,本篇文章为最近学习的一个记录总结,文章以开源项目为背景,因内容较多,出于篇幅考虑,将其收入一个系列。期望对后期在HIDS能力的增强方面有所帮助。
HIDS
基本概念
主机入侵检测, 通常分为agent和server两个部分,其中agent负责收集信息, 并将相关信息整理后发送给server。server通常作为信息中心, 部署由安全人员编写的规则(目前HIDS的规则还没有一个编写的规范),收集从各种安全组件获取的数据(这些数据也可能来自waf, NIDS等), 进行分析, 根据规则判断主机行为是否异常, 并对主机的异常行为进行告警和提示。HIDS存在的目的在于在管理员管理海量IDC时不会被安全事件弄的手忙脚乱, 可以通过信息中心对每一台主机的健康状态进行监视。
HIDS的基本功能
- 基础信息收集:系统版本号、系统用户、web组件、数据库、三方组件包等信息,主要用于CVE漏洞检测以及应急响应。
- 日志监控:主要是登录相关的日志、bash日志以及webserver产生的日志,主用用做异常登录监控、危险命令监控以及基础DOS检测。
- 文件监控:新增文件、敏感权限文件、核心文件变动监控、crontab文件监控,主要用于rookit检测、webshell监控等。
- 进程监控:主要用于木马、反弹shell、rookit等检测。
- 流量监控:主要用于木马,反弹shell等发生网络行为的一些异常监控。
- 系统命令监控:主要用于入侵后命令执行的检测。
HIDS数据处理流程
此处以ossec的架构为原型进行分析
终端Agent组件:用于收集服务器信息、计划任务、监听端口、服务、系统日志、用户列表,实时监控文件操作行为、网络连接,系统安全配置核查(基线扫描)、webshell扫描、反弹shell监控等,初步筛选整理后传输到Server节点。
管理端Server:集群化部署,用于解析用户定义的规则,对从各Agent接收到的信息和行为进行分析检测和保存,对文件变化、异常登录、异常网络连接行为等进行分析并告警,从而实现对入侵行为实时预警。
Elasticsearch:日至存储、聚合、分析
Mysql:存储配置信息、cmdb资产信息、告警信息、监控组信息
Redis:任务队列、告警队列、消息推送队列
Web后台,搜集展示来至es的日志,提供给安全人员或运维人员;包括监控日志、告警消息查询,数据统计、监控组管理、主机管理、告警过滤、规则查看、配置下发等功能。
开源HIDS分类
开源HIDS主要有ossec、Wazuh、Osquery、yulong-hids以及AgentSmith HIDS。
开源产品 | 简介 | 项目地址 |
ossec | 在众多互联网企业中广泛运用 | |
wazuh | 基于ossec扩展出来的,结合了Elastic Stack | |
osquery | facebook开源的osquery,通过集成osquery来实现快速监控系统安全 | |
yulong-hids | 同程安全团队开源的HIDS | |
AgentSmith HIDS | 点融安全团队开源的HIDS |
此处以Wazuh、Osquery和AgentSmith为例。Wazuh是一个已经构建完善的HIDS, 应用范围较广,有agent端和server端, 有自带的规则, 基础的rootkit检测, 敏感文件修改提醒等功能, Osquery是一个facebook研发的开源项目, 可以作为一个agent端对主机相关数据进行收集, 但是server和规则需要自己实现。而如今针对Osquery的server端已经有开源的解决方案了https://github.com/shengnoah/osctrl,osctrl是jmpsec推出的后台管理系统,Freebsd、Ubuntu、Debian等各种平台都支持。AgentSmith是字节团队开源的一个主机入侵检测项目,适用于企业大规模服务器的场景,检测结果较为精确,但是管理端为开源。
以下是三个开源项目的详细评估对比:
评估角度\HIDS名称 | 评估标准 | Wazuh | Osquery | AgentSmith |
架构组成 | HIDS的架构组成一般是这样: agent:安装在企业内每台主机,进行基线采集,事件监控 管理端:管理每台agent的配置下发,状态检测,版本管理 规则分析中心:接收各种agent上传的数据,进行分类重整化,关联分析 报表平台:展示规则分析的结果 | 1. 有agent 2. 有管理端 3. 有规则分析中心,也有分析规则 4. 集成ELK里展示报表 | 有agent | 1.有agent 2. 使用kafka来接收数据 |
架构组成对比结论 | 对于管理运维来说,Wazuh更有优势 | |||
基线检测(包括系统基线,设备基线,软件基线,配置基线等) | 设备基线:系统的硬件设备(CPU型号,内存设备型号,存储设备,各种外设) | 仅支持CPU使用率监测 | 支持常用的设备基线 | 无 |
系统基线:cpu个数,内存使用,磁盘使用,分区加载,系统版本,发行版,启动时长,系统限制 | 系统基线基本上满足,但不支持磁盘加载、系统限制、系统负载监测 | 支持常用的系统基线 | 支持内存、内核、发行版本和系统信息 | |
供应链基线:软件管理的仓库 | 无 | 支持APT和YUM | 无 | |
软件基线:软件列表,软件详细信息 | 支持deb包和rpm包 | 支持除npm包以外的包 | 无 | |
配置基线:shell配置,启动配置,加载配置,分区配置 | 无 | 支持主机、协议、服务端口 | 无 | |
用户基线:用户列表,组列表,权限列表 | 可以监测用户信息 | 支持常用的用户基线 | 仅支持命令历史,但是这块比Osquery更精确 | |
网络基线:网卡个数,地址信息,ARP信息,路由信息,DNS信息,防火墙信息 | 支持网卡、地址、路由信息检测 | 支持常用的网络基线 | 无 | |
服务基线:服务列表,已启动的服务,服务所管理的进程,定时任务 | 无 | 支持crontab | 无 | |
安全基线:apparmor配置和运行状态,selinux配置和运行状态,yara配置,suid程序 | 无 | 支持常用的安全基线 | 无 | |
容器基线:docker版本,镜像,网络,容器 | 无 | 支持常用的容器基线 | 支持docker进程和docker文件变动 | |
基线检测对比结论 | Osquery基本上满足目前常见的基线检测,AgentSmith可以通过execve钩子的日志来重组命令历史,这块检测会比Osquery更精确,AgentSmith的事件内置了命名空间字段,可以检测容器里的进程变动和文件变动。 | |||
事件监控 | 提权行为、监控进程启动 | 没有进程树,有检测进程隐藏,没有检测so注入,没有检测提权,可以通过Audit来监控进程启动 | 通过Audit监控进程启动 | 除了没有检测进程隐藏,都有 |
监控进程异常退出 | 通过Audit监控进程异常退出 | 通过Audit监控进程异常退出 | 有 | |
检测rootkit/bootkit | 通过Audit的SYSCALL类型来过滤 | 通过Audit的SYSCALL类型来过滤 | 有 | |
检测恶意篡改,痕迹隐藏,恶意授权 | 通过AuditAudit的SYSCALL类型来过滤,但无法检测隐藏文件 | 通过AuditAudit的SYSCALL类型来过滤,但无法检测隐藏文件 | 有,无法检测隐藏文件 | |
检测高危端口和外连行为 | 通过Audit的SYSCALL类型来过滤 | 通过Audit的SYSCALL类型来过滤 | 有 | |
检测动态注入和DOS行为 | 通过Audit的SYSCALL类型来过滤 | 通过Audit的SYSCALL类型来过滤 | 有 | |
事件监控对比结论 | 这三款HIDS都没有检测隐藏文件和隐藏进程的能力(Wazuh有检测隐藏进程能力),它们都可以获取全量进程创建和退出信息,也可以获取所有文件和目录访问信息。 | |||
运维角度 | HIDS应该具有这些运维能力: agent: 支持从管理端远程下载和执行脚本,获取最新配置,版本更新,重启,向管理端发送指定文件,发送心跳和状态上报; 管理端:支持批量下发配置,远程推送版本,远程重启agent,向某agent指定获取某文件。 | 1.支持批量版本更新 2.支持批量配置更新 3. 支持批量重启 4. 支持执行本地命令,不支持远程下载脚本执行 5. 支持远程获取指定文件 6. 有心跳和状态上报。 7. 分布式:文档用nginx支持LB,实际不可行,配置倒是支持多管理端,单个管理端支持600-1000个Agent。 | 1.有心跳和状态 2.支持命令执行 | 1.agent具备版本更新 2.agent有支持远程配置更新 3.agent有支持重启的能力 4.agent也有心跳和状态上报 5.分布式:因为管理端没开源,不清楚,但字节跳动已经用它管理了几十万台,分布式不成问题。 |
运维角度对比结论 | 从运维角度来说Wazuh更优(因为AgentSmith的管理端没开源) | |||
开发角度 | 这里开发角度是基于对现有产品不做任何功能重构,只是使用角度扩充的基础上 | 1.增删或修改分析规则,基本不需要开发人员 2.新增关联分析需要写脚本 3.对Kibana没有的报表,需要nodejs开发 | 1.agent需要开发,来支持批量运维能力 2.需要开发管理端,来支持批量运维能力 3.需要开发规则分析平台,增加各种规则 4.需要开发报表平台 | 1.需要开发管理端,开源解决方案:https://github.com/shengnoah/osctrl 2.需要开发规则分析平台,增加各种规则 3. 需要开发报表平台 |
开发角度对比结论 | 从开发角度来说Wazuh最优,但是Osquery有开源解决方案之后,也很香 | |||
操作平台角度 | HIDS支持的操作系统平台 | 支持AIX, HP-UX, Linux, MacOS, Solaris, Windows | 支持MacOS, Linux, FreeBSD, Windows | 支持Linux |
操作平台角度对比结论 | 从操作平台角度对比情况来说,Wazuh兼容性更优 |
信息搜集
系统基本信息
- 系统版本:根据操作系统解析相应
/etc/readhat-release
、/etc/redhat-release
、/etc/gentoo-release
文件系统版本信息搜集。 - keneral信息:解析
/proc/cmdline
和/proc/version
- 用户信息:通过
/etc/passwd
文件搜集用户信息,剔除nologin的用户 - 进程信息:通过遍历/proc目录下获取所有的进程信息,取信息参考[/proc目录结构](http://man7.org/linux/man-pages/man5/proc.5.html)
- 环境变量信息:切换到各个用户,运行以下命令:
- set命令显示当前shell的变量,包括当前用户的变量;
- env命令显示当前用户的变量;
- export命令显示当前导出成用户变量的shell变量。
- 已登录用户信息:已登录用户保存在
/var/run/utmp
(对应linuxwho
命令),c函数getutxent
可直接解析此文件获取信息。 - 历史登录用户信息:已登录用户保存在
/var/run/utmp
/(对用linuxlast
命令),c函数getutxent
可直接解析此文件获取信息。 - WEB Server进程信息:通过监控到的所有的进程信息,筛选出命令行运行了
nginx|httpd|apache|tomcat|weblogic|jboss|jetty
等webserver的信息。通过/proc/[pid]/cmdline
获取到服务运行的命令行,一般是用于搜集webserver的版本号以及webserver的web代码路径。不同的webserver要通过不同的方法的命令和方法获得,例如nginx可以通过找到nginx的路径运行nginx –v
获得版本信息,通过读取/proc/[pid]/cmdline
命令行信息匹配-c的内容或者/proc/[pid]/cwd
运行目录获取到web文件的路径。 - 数据库信息进程信息:数据库配置路径和版本的获取方法和web路径获取方法类似。
- 三方组件信息:三方组件包最常见的就是java的三方组件,获取方法是遍历webservers三方路径下的jar文件。如果是war文件部署,还需要把war包解压,然后再重复上述步骤遍历.jar文件获取到三方组件的名字和版本号。另一种更优雅获取组件的方式可能是解析web应用的pom.xml文件(并非所有java web应用程序都有),文件里的标签 ``管理着三方组件的信息。
- 其他组件的搜集(例如ThinkPHP等框架),主要也就是匹配框架指纹(可能根据robots.txt文件,可能根据一个文件里的特定内容等)这个就需要大家去网上或者自己搭建搜集指纹,可以优先常用cms的识别方法,后期可慢慢优化添加其他框架。
crontab信息:/etc/crontab
文件保存系统计划任务,/var/spool/cron/
文件夹保存用户计划任务
1 | "/etc/cron.d/", // system all |
2 | "/var/at/tabs/", // user mac:lion |
3 | "/var/spool/cron/", // user linux:centos |
4 | "/var/spool/cron/crontabs/", // user linux:debian |
上面的路径是开源HIDS里定义的:
authorized信息:遍历所有加目录下的".ssh/authorized_keys",".ssh/authorized_keys2"
文件
konw_host文件:遍历所有用户家目录下的.ssh/known_hosts
文件
sudoers信息:解析/etc/sudoers
和/etc/sudoers.d/
目录下的文件
iptables信息:解析/proc/net/ip_tables_names
文件
系统控制文件:解析系统控制配置文件
系统文件路径:/etc/sysct.conf
系统控制文件可能存在路径
1 | "/run/sysctl.d/%.conf", |
2 | "/etc/sysctl.d/%.conf", |
3 | "/usr/local/lib/sysctl.d/%.conf", |
4 | "/usr/lib/sysctl.d/%.conf", |
5 | "/lib/sysctl.d/%.conf", |
其他信息(非完整):
memory_map:解析
/proc/iomem
mounts:解析
/proc/mounts
modules:解析
/proc/modules
memory_info:解析
/proc/meminfo
shared_memory:通过
shmctl
函数遍历merory id从1遍历到最大uptime:通过
sysctl
函数获取boottime
重要文件监控
这项功能实现很简单,就是定时计算整个目录下文件或者单个的Hash值并存储起来。但是哪些文件属于重要文件就需要安全人员去研究定义,这个过程可能不是一蹴而就,一方面可能新的漏洞层出不穷,一方面是受限于个人的知识点有限,无法梳理出所有通用的漏洞策略。以下是一些我的不完全整理:
/bin/ps
、/bin/netstat
、/usr/sbin/lsof
、/usr/bin/top
等命令:rookit时候hacker可能会替换这些系统命令- libc.so文件:ubuntu平台
/usr/lib/x86_64-linux-gnu/libc.so
,centos平台/lib64/libc.so.6
。查看某个平台具体的libc.so文件路径,可以运行ldd ls | grep libc.so
。 - 开机启动文件:/etc/init.d是 /etc/rc.d/init.d 的软链接,测试新装的linux系统必须开启的服务
ssd、rsyslog、network、crond
- [/etc/rc.local](https://common.cnblogs.com/editor/tiny_mce/plugins/preview/https://www.landui.com/help/nshow-8196.html)
- 基于白名单过滤,查找异常的执行命令
- 基于已知的特征做数量统计或异常行为分析。
- /etc/profile文件:本文件可设置全局的系统变量。
- 内核模块:
ls -alt /sys/module
- 预加载文件:
/etc/ld.so.preload
- suid文件监控:全局搜索是不太现实,一般服务器负载都比较高,全局搜索耗时和对系统负担大。
1 | "/bin", |
2 | "/sbin", |
3 | "/usr/bin", |
4 | "/usr/sbin", |
5 | "/usr/local/bin", |
6 | "/usr/local/sbin", |
7 | "/tmp", |
搜索上述几个路径的文件,判断权限是suid和guid
日志搜集
- /var/log/secure:Linux系统的安全日志,记录用户和工作组变化情况、用户登陆认证情况。一般入侵告警ssh被尝试爆破就是通过这个文件来进行规则制定的。
- /var/log/wtmp:该日志文件永久记录每个用户登录、注销及系统的启动、停机的事件,这个文件是二进制文件,cat查看不了,可以使用last命令查看。此文件可用于异常用户登录检测,通过检测异常的IP和登录地进行告警。
- history日志:监控用户输入的历史命令,后续会讲到具体做法。
- webserver日志:主要用于应急响应或者做些cc攻击的防御,是否集成到HIDS里有待商榷。定位到日志的具体路径是难点,做简单的cc攻击防御的话,最简单可以通过ip时间段内访问频率来设置防御策略。
参考:
https://www.freebuf.com/articles/es/197337.html
https://www.freebuf.com/articles/es/194510.html
漏洞悬赏计划:涂鸦智能安全响应中心(https://src.tuya.com)欢迎白帽子来探索。
招聘内推计划:涵盖安全开发、安全测试、代码审计、安全合规等所有方面的岗位,简历投递sec@tuya.com,请注明来源。