HIDS(Host-based Intrusion Detection System)作为网络安全的最后一条战线,我们现阶段是否处于攻防不对等的地位?现在主流的HIDS的建设思路和方式是否又存在各种不可忽视的缺陷?
1.为何是最后一条战线
我们面对各种不同的针对生产环境的威胁,攻击者最终诉求大多是维持一个可长期访问的/有一定权限的通道,便于从内部寻找弱点,得到想要的诸如核心系统,数据库,git/svn/邮件系统的权限,从而实现自己的目的.
那么在这么常规的攻击路径中,HIDS作为主机层的一双眼,往往是离真相最近的那一双,NIDS存在镜像流量可能不全/HTTPS/加密/规则绕过等问题,而据我的经验,稍微高级的入侵者往往并不会采用扫描/暴力破解等动作;WAF作为入口的看门大爷往往没有能力管理从内出去的安全问题;各种架构问题总会导致各处的日志收集不全/或者没有关键上下文难以甄别异常等等.
那么HIDS的作用就异常重要了,即:其他安全防线失效的情况下,HIDS是最后一道防线.如果这里也没有办法发现如:后门,webshell等行为,那么企业可能会长期处于被入侵但是自己丝毫不知情的糟糕地步.
2.现在部分的HIDS技术
我们来大概看看现在主流的HIDS部分关键技术.
Linux Auditd,作为一款以Hook框架发展起来的安全组件,可以Hook任意Syscall和一些关键操作.缺点是性能略差,不支持Namespace(即不支持容器技术,如Docker),还有比如Connect Hook位置靠前导致得不到源端口等小坑,使用Netlink传输性能略差,且难以二次开发等.
cn_proc,很多都采用cn_proc来获取进程创建信息,缺点也是很明显的,获取信息缺失严重,大多数场景需要自己去/proc取(瞬时进程还取不到),不支持Namespace,用户态的功能叠加同样可能会导致性能问题的出现.
用户态Hook,比如LD_PRELOAD,容易被绕过,且有时不是故意绕过...
clamAV/BusyBox/Rootkit Hunter等其他开源组件,使用规则的问题就是容易被绕过,开源组件拼凑往往难以实现威胁的全覆盖.
其他系统日志,比如bash_history等等,部分容易被绕过.
3.我们谈谈绕过的问题
为什么我总是说到被绕过?因为我们防御到不是普通的正常用户,面对已知的防御能力,入侵者会想出各种的绕过方法,逃避检测.笔者在之前处理了一起APT攻击事件,攻击组织使用了Kernel Rootkit来逃避检测,而发现时居然已距入侵估计时间节点长达数年之久.
HIDS上一起被绕过的入侵行为,很有可能就是企业安全最不想面对的梦魇,而梦魇来袭,防御者往往毫不知情.
我们随意例举几个笔者所知道的绕过姿势,如果有参与研发HIDS的甲方/乙方的同事不妨评估一下自己的HIDS是否可以精准捕获有效数据已足以支撑你们的决策部分作出判断:
1.更换默认Bash,如csh/zsh
2.巧用shell 命令:
或者:
3.反弹shell时不用bash,而是cp /usr/bin/bash test,然后使用test进行反弹shell
4.进程注入
5.pwnginx/mod_rootme/Knock-out等“复古后门”
6.各种隐秘通道技术(不仅仅有大家都熟知的DNS/ICMP)
7.Rootkit
7.自定义system_call,逃避Auditd等Hook技术
8.nc -e
9.利用memfd_create无文件渗透/利用ptrace模糊执行参数
仔细思考上面随便列举的几个方法,就会发现,攻防不对等技术一直存在.安全工程师过于理想的考虑攻击方手段,逐渐失去Hack的本质.大量使用开源检测组件而逐步失去思考能力,“无开源,不安全” 又导致检测规则和逻辑逐步被绕过而不知.
对于HIDS的检测能力,太多的依赖规则和”进程名“这种不可信的信息来源.而想要的到更精准/全面的信息,要么会出现短连接/短进程捕获不到,性能出现压力,没有成熟的开源组件而放弃想法,一直妥协最终出现目前的状态.
又有多少企业在虚假的安全中而忽视了这些风险呢?我们不得而知.当针对性的攻击出现时,很可能就是:防御终将失效.
4.我们谈谈内核态HIDS
笔者之前开源了Hook system_call的HIDS:AgentSmith-HIDS,反响寥寥.大多数的评价是:“内核态不稳定”,我相信大多数评价者应该都没有使用过/测试过这款开源的产品.习惯性的“Kernel态不稳定”总是政治正确的.当然笔者承认,稳定性和适配性的确是他的一大短板.我们暂且不讨论AgentSmith-HIDS,我们聊聊内核态的HIDS有哪些优势:
性能,内核态HIDS无需遍历/proc之类的,天然支持Namespace.传输方案也可以用共享内存代替Netlink
二次开发友好,想要stdin/out?简单,几行代码的事.想要tgid?简单.
天然支持微隔离,隔离到进程级别-syscall级别(大多数场景connect应该就够了)
难以绕过(但还是可能,相对困难些,比如“??/!!”这种还是是无法绕过的)
可以做到一定程度的实时行为检测Rootkit(之前说的APT的后门就是通过这种方式检测出的)
内核态HIDS并不全是内核态,通常是LKM+用户态Agent,所以,可以做到相互补充,用户态也可以做一些诸如:资产盘点,漏洞检测.webshell静态查杀等等行为
监控能力到达syscall级别,面对很多绕过的行为,可以支撑更多的行为监测逻辑.比如上文所述的一些绕过的反弹shell
可以借鉴LKRG(Linux Kernel Runtime Guard)这样优秀的产品,面对各种Linux Kernel的0day也可以做到一定程度的防御
良好可信的数据收集,带来的是后续优质的,可持续的,可以作为数据分析的数据源,可以建立不同维度的行为模型来发现更隐蔽的异常
Hook部分syscall甚至可以做到业务级的资产梳理,比如A发出了HTTP的Request,Host是XXX(理论可行)
诚然,依然会有很多缺点,但是内核态HIDS并非仅仅有一个LKM,肯定会伴随着用户态Agent的存在,可以发挥的地方比起传统的HIDS只多不少.整体信息收集能力更可信且难以被绕过,由于有进程的完整的syscall信息(hook的syscall)作为支撑,可以做更多的行为检测能力,后期也可以向进程级别微隔离/可信计算/Linux Kernel 0day漏洞检测方向发展,性能/容器化的支持也具有天然优势.
5.思考
作为防御方,我们应该有哪些盾来抵御潜在的“暗箭”呢?这是每一个防御方都要思考的问题,我们更要思考攻击者会有那些可能的方法,绕过我们的防御.想想马奇诺防线吧,臆想的防御方式很有可能不那么奏效.最后,笔者对HIDS的了解和研究也不是很深入,HIDS的学习/研发/测试也只有4-5个月的时间.后来一直在研究其他领域,也欢迎大家提出不同的观点和意见.
最后,这是笔者和老友Gaba还有另一位安全从业10年的老兵一起创建的公众号,偶尔发发技术干货和吐吐槽,欢迎大家关注
声明：本文来自灾难控制 局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
