我与入侵检测的二三事儿

总结毕业后的六年经历，从扫描器萌新，到入侵检测的“青年”油条，希望能对各位有一些参考价值。

一、扫描器

18年的夏天，我毕业刚满两年。每个工作日都沉浸在代码里，在扫描器的世界里挥斥方遒，poc数量和漏洞成果都越积越多，工作充实但内心的空洞却越来越大。

在机械化重复的工作间隙里，我一直在思考几个问题。

我是怎么走上这条路的？我没有主动选择过，但机缘巧合之下，全身都被贴满了扫描器的标签。实习的时候被安排的第一个任务是内网端口扫描，毕业后第一份工作是维护商业扫描器，后来变成自己来写扫描器。看似在不断进步——从一个模块，到整体维护，再到重构，实际上却被重复工作填满，个人成长非常有限。

我真的想做扫描器吗？最一开始的时候想做，刚毕业的萌新眼里，哪里都蒙着神秘的面纱，什么都想学。但真的花了两年摸了一遍之后，祛魅环节完成，扫描器就如同墙上被拍扁的蚊子血，失去了光彩。

这条路还有发展潜力吗？当然有，可以优化架构减少重复工作，也可以深入底层代码原理做性能优化。但我不想成为架构师，再继续下去，代码能力会成为束缚而非助力。

是时候换一个方向了。

寻觅良久，我盯上了HIDS——功能复杂繁多，历史积淀与未来发展并存，是一个绝佳的、值得深入研究的工作方向。

二、转职

“转职”的过程并不顺利，我原本想在Q公司内部转方向，但我所在的团队讲究“孤狼”文化：一两个人负责一个小项目，快速迭代出成果。HIDS实在不是一两个人短期内能完成的项目，数据采集和安全分析是两块儿巨大的蛋糕，很难一口吞下。

于是我离职换了工作，本以为到了K公司会柳暗花明又一村，结果变成了更孤的狼。总归还是做了一些努力：开发能力不过关，那就用开源系统OSQuery；没有数据分析能力，那就从头开始学。

结果还是不如人意，OSQuery虽然省去了很多工程化的工作，但各公司的基础环境不同，推动的时候遇到了非常多的阻碍，稳定性问题频发，覆盖率也一直上不去；数据分析学了一些，但巧妇难为无米之炊，没有数据谈何分析？

后来我离开K公司的时候，HIDS的部署量大约还剩百十来台机器，惨惨淡淡凄凄凉凉。再往后K公司也招了几位专业的研发同学，完全抛弃了OSQuery那一套东西，纯自研迭代了几轮之后也全部覆盖上了，不过这就已经是后话了。

在最迷茫的时候，我看到了一篇文章——《浅谈大型互联网的企业入侵检测及防护策略》，条理清晰、深入浅出的讲解了入侵检测中遇到的种种困境及解决思路。

所以，毕业第四年，第三份工作，我选择了M公司。

高中的时候有一位老师说过一段话，让我至今记忆犹新：“学习，是一个先把书读厚，再把书读薄的过程” 。读厚是指深入理解书里的原理，每页里都有厚重的故事；而读薄是指将技巧融汇贯通，摒弃招式，形成“方法论”，便能举一反三掌握各种变形。

这篇文章便是一本书，来到M公司后，我先将书读厚，书里每一句精炼概要的道理，我都在工作中不断经历、实践，所以知其然知其所以然；而后将书读薄，抽象方法论，万变不离其宗。

接下来便是我在M公司的“读书”小记。

三、基建

来M公司前，我以为HIDS的迭代路线是这样的：先把HIDS Agent该做的功能做的八九不离十，然后慢慢的灰度铺开，发几个版本修复bug，就可以开始写检测规则了。

而我入职的岗位职责之一就是“写规则”，推导一下，那Agent大概成熟度已经很高了，一定是在持续稳定的采集各类数据，就等我去分析建模了。

所以当我入职没几天，就发现HIDS Agent是全量挂掉的状态的时候，内心是有点儿噩梦重现的恐惧感的。尤其是挂掉的原因，又是稳定性问题——HIDS依赖的中间件故障。类似的问题，我在K公司定位了好几个月都没有解决…

但噩梦还没来及展开，就光速结束了。M公司内部建设HIDS实际有两个团队，将基建与数据分析拆分开，专业的人做专业的事情。全量停机的问题看起来严重，但在专业的研发同学眼里，并不是关键的技术瓶颈。大约两三周之后，问题修复，Agent重新灰度上线。

后来类似的事情又发生过几次，每次的原因都不尽相同，比如资源超限对业务产生影响、逻辑错误导致bug等等，在专业靠谱的研发团队支撑下，也都平稳度过，极少发生全量回滚/下线的情况。（研发团队指路->《保障IDC安全：分布式HIDS集群架构设计》）

当然除了稳定性问题，Agent的采集能力也与我想象中的“八九不离十”相差甚远。Agent早期存在非常多的数据质量问题，比如数据关联错误、短进程数据丢失、采集逻辑不全面等，每个问题都难以预知，也对后端的数据分析有非常大的影响。

数据源的问题很难一次性全部暴露出来，通常是在数据分析到一半的时候才发现问题，有时候还会影响很大。比如数据关联错误的问题，业务逻辑是A进程访问某敏感文件，但是错误关联成了B进程访问敏感文件，让行为模型的误报量飚高，只能等Agent修复后，模型的误报量才能到达上线标准。

当时定位问题的过程也非常坎坷，是否取错需要人工判断，而取错又是小概率事件无法稳定复现，代码层面上看不出问题，摸黑改了一次效果有限。而Agent变更可能会影响业务，所以灰度的周期很长，每次修改验证都动辄以月计，模型的进展也阻塞在这里，情况非常紧张。

无奈之下，我们用“大数据”找了一批复现概率比较高的机器和取错组合，提供给研发同学后，有了复现和验证的环境，再加上专业能力，问题很快就解决了。

类似的曲折故事，在推进数据源采集能力提升的过程中发生了很多次，但总归是在各自发挥专业优势、互相协作的的情况下，不断克服困难并持续进步。几年过去，目前Agent的稳定性和采集能力都有了明显的提升，关键数据源极少再出现取错或者漏取的问题，有效支撑了安全检出能力。

四、建模及告警

头三年的工作经历里，我做过一些安全规则的工作，以反弹shell、提权这一类比较简单的策略为主。但在我想象中，M公司这种成熟的公司肯定会更关注高级的攻击手法，为了避免“囊中羞涩”，我还专门花时间去研究了下Rootkit、后门、进程隐藏这些“高级”手法。

实际入职后，也是出乎意料的没有用武之地。因为第一件事情，还是反弹shell。

接到这个任务后，我第一反应就是回忆以前反弹shell的规则是怎么写的——在命令层面加一些关键字检测，然后撸袖子准备开始干活。

很快就被领导拦下来了，并且发出了一连串灵魂拷问：反弹shell一共有哪些手法？使用频次如何？哪些能在公司环境下使用？现在支持哪些手法的检测？本次要新增对哪些手法的支持？这些手法除了命令之外，有哪些维度特征？如何防止绕过？需要哪些数据源支撑？

方向比努力更重要，所以在开始动工之前，按照领导的指导，我花了几天去做大盘的梳理盘点和对标：

• 反弹shell的本质是什么？shell 通过特定的 连接方式 （与 通讯主体 进行通讯，然后由 通讯主体 ）与外部攻击者进行通讯。攻击者通过特定 监听手段 控制机器。

• 反弹shell有哪些手法？分别有哪些特征？如何防止绕过？静态命令特征、动态进程派生特征、网络连接特征、网络通讯特征。从命令、进程、网络、流量等多个维度纵深监测。

• ….

当大盘梳理完整后，就进入到了一个“下笔如有神”的阶段。因为反弹shell属于攻击特征非常明显的高危动作，整体建模逻辑比较简单直接，通过专家特征匹配即可。规则的编写、验证、验收工作，以非常快的速度完结了。

但新的问题又浮现出来，反弹shell只是攻击者的众多手法之一，还有非常多的手法没有覆盖，每种手法有可能依赖不同的数据源。这么多事情，应该先做啥？做我刚研究过的Rootkit和后门检测？

迷茫的时候，领导带着光出现，再次发出灵魂拷问：常规攻击者通常会使用哪些手法？历史攻击我司的攻击者又是用了哪些手法？目前对这些手法的覆盖率如何？未覆盖的手法做起来的难度和收益如何评估？

于是又花了一两周去做分析和复盘，当时或多或少会觉得有些浪费时间，但现在回想起来才觉得这个环节至关重要。这和反弹shell的大盘梳理是类似的逻辑，先明确全局视野、评估各个细分事项的投入，再结合内外部的攻击态势，判断某项工作最终能带来的收益，从而决定是否投入。

我们可以做容易的事情，不抬头望天只埋头苦干；也可以做所谓“困难”的事情，追求高级手法以提升个人知识技能。运气好的时候可能没什么太大的差异，但时间久了总会有失利的时候，花了许多时间去解决的问题不是主要矛盾，做出来的模型极少有检出，对整体的安全能力贡献极少，长期以往个人的提升也会受限。

M公司有句老话，讲得非常精准——“坚持做正确的事，而不是容易的事”。

仰望完星空，接下来就要脚踏实地。

经过一通分析和对标，得出来了结论：xx攻击手法是历史上出现频次最多的，也是检出效果比较差的，需要高优先级做行为模型的建设，对业务历史行为生成基线，对入侵行为做异常对比（非白即黑）。

虽然行为模型的逻辑相对清晰，也有比较成熟的业界实践。但真正要在数十万机器量级产生的大数据背景下，把所有的业务操作记录下来并进行实时匹配，并且还要控制误报的量级在人力可运营的范围内（当时的要求是<=10条误报/天），还是一件非常困难的事情。

我拿起hive和jupyter两把小工具，琢磨分析了几个星期的离线数据，怎么也找不到一个合适的方法控制告警量级，业务总有各种奇奇怪怪的使用方式。建模工作一度陷入瓶颈，好几个星期的周报都是“分析数据进行中，预计下周完成”。

下周复下周，下周何其多。

领导再再次出现，很快帮助我理清了思路，确定了迭代的方向——不要妄图一口吃成个胖子，直接做一个完美的通用模型出来，而是先圈定一个小范围，把这部分的问题迭代解决完之后，再逐步扩大范围，最终完成既定目标。

靠着持续迭代的思想，行为模型逐渐完善，在近几年的入侵检测中贡献了非常多的检出率，在内部的攻防对抗中，攻击者（更熟悉我们的能力）需要非常谨慎以及要采用更高级的手段来绕过感知，大幅提升了攻击门槛。保障关键项目持续有进展，也成为了领导对我后续工作的要求，对我助益良多。

五、总结展望

回顾在M公司这三年，值得一写的事情远不止这些。但真正能写出来、对外公开的内容非常有限。

我学会了如何在海量数据下建设纵深防御体系，视野上，在对标盘点的过程中了解了行业Top公司安全建设的迭代路径，知道如何往“业界最佳实践”靠拢；实操上，熟练使用实时、离线多种分析方式，做出来的模型也检出了无数次内外部入侵。

我学会了如何应急止损、快速定位并解决当前入侵风险，并利用各类数据完成溯源，确保历史上没有因同类问题导致的入侵行为。我学会了如何深入复盘并持续迭代能力，从事前建设、事中感知、事后溯源多个维度Review能力缺陷，并推动各方完成迭代更新。

我学会了如何推动合作团队共同完成目标，在遇到分歧时求同存异，在进展受阻时及时干预引导，在正确的时机上升对齐，推动流程完善以确保高质量交付。

我学会了…

目前取得的一些微小成果，有很多运气成分在里面，没有被顶尖的黑客团队盯上；也仰仗于专业的兄弟团队支持，在保障采集能力稳定运行的同时，没有因灰度对业务产生严重影响；同时也依赖于领导的“教练辅导”，在我方向不清晰、实施过程有阻塞点的时候，及时出现并引导我走向正确方向。

在这几年的工作中，有一些关键认知迭代，与诸位共勉：

• Agent基建与数据分析的能力，没有哪一部分是能一蹴而就的，也不存在先后关系，都在相互纠缠中慢慢成长完善。

• 专业的人做专业的事儿，而两个专业团队相互协作的力量，是1+1>2。研发同学擅长于解决稳定性、性能、采集方案等问题，安全同学对数据分析、攻击手法、建模思路更熟悉，协作一致才能形成更强大的力量。

• 方向比努力更重要，坚持做正确的事，而不是容易的事。如果摸不清楚方向，不如花一些时间抬头看路，在错误的方向上少走几步，也能算是阶段性的胜利。

• 个人能力的成长也需要“迭代”提升。《刻意练习》讲过：所谓“天真的练习”，基本上只是反复地做某件事情，并指望只靠那种反复，就能提高表现和水平，但这只会让你在现状中显得更深。而“正确的练习”，需要好导师、有目标、有反馈，才能不断走出舒适区，最终变成业内杰出人物。

总结完过去，接下来就是展望未来。

上图摘自今年Google云安全峰会的议题——《Taking an autonomic approach to security operations》，主要讲Google在做反入侵的时候，在数据采集、数据分析、响应处置、反馈提升四个大的阶段持续迭代，尤其是做了很多自动化处置的事情，以降低成本、更高效的运营闭环，最终提升安全能力。

Google是安全行业内的标杆，近几年发布的多篇安全白皮书也非常经典，一直在反复强调云原生安全的重要性。与上述议题结合起来看，随着外挂式安全建设的自动化、平台化能力越来越强，节省下来的人力投入到云原生安全方向，也是自然而然的事情。

以往我司大多数时间在做外挂式安全，已经有了一定的成熟度，也沉淀了很多平台化的能力（当然离Google还有一些距离）。依托这些能力，我们可以快速完成数据采集、分析建模、上线运营等流程，安全同学更专注于攻击手法和策略逻辑，效率也大大提升。

随着云原生的持续发展落地，我司也在逐渐往云原生安全的方向建设，把安全能力更早的内置到业务逻辑里。

这是一个关键的转折点，我非常期待在新篇章里去经历新的故事，与公司共同成长。

六、碎碎念

站在巨人肩膀上，看到更远更广阔的世界。文末来推荐几本经典书籍：

• 《金字塔原理》：写作基本功，如何更清晰、更有条理的表述

• 《非暴力沟通》：沟通基本功，在推动类的工作中非常重要的基本法则

• 《刻意练习》：如何成为大师，成长方法论

• 《领导梯队》：了解自己处于什么位置，以及可能的成长路线

• 《高效能人士的七个习惯》、《可复制的领导力》、《人性的弱点》、《你不可不知的人性》：一些优秀的职场素养，软素质、情商相关

也推荐几个优秀的公众号：

欢迎加我微信一起交流HIDS和反入侵建设的经验。

最后打个小广告，如果你想从事反入侵工作、希望能在此领域深耕，我们恰好在找一路同行的伙伴，欢迎来试试看。

原文始发于微信公众号（安全小黄鸭）：我与入侵检测的二三事儿