大型互联网公司如何防止黑客入侵？

[db:作者]

如何知道自己所在的企业是否被入侵了?是没人来“黑”，还是因自身感知能力不足，暂时还无法发现？其实，入侵检测是每一个大型互联网企业都要面对的严峻挑战。价值越高的公司，面临入侵的威胁也越大，即便是 Yahoo 这样的互联网鼻祖，在落幕(被收购)时仍遭遇全量数据失窃的事情。安全无小事，一旦互联网公司被成功“入侵”，其后果将不堪想象。
基于“攻防对抗”的考量，本文不会提及具体的入侵检测模型、算法和策略，那些希望直接照搬“入侵策略”的同学可能会感到失望。但是我们会将一部分运营思路分享出来，请各位同行指点，如能对后来者起到帮助的作用，那就更好了，也欢迎大家跟我们交流探讨。
入侵的定义
典型的入侵场景：黑客在很远的地方，通过网络远程控制目标的笔记本电脑/手机/服务器/网络设备，进而随意地读取目标的隐私数据，又或者使用目标系统上的功能，包括但不限于使用手机的麦克风监听目标，使用摄像头偷窥监控目标，使用目标设备的计算能力挖矿，使用目标设备的网络能力发动 ddos 攻击等等。亦或是破解了一个服务的密码，进去查看敏感资料、控制门禁/红绿灯。以上这些都属于经典的入侵场景。
我们可以给入侵下一个定义：就是黑客在未经授权的情况下，控制、使用我方资源(包括但不限于读写数据、执行命令、控制资源等)达到各种目的。从广义上讲，黑客利用 SQL 注入漏洞窃取数据，或者拿到了目标域名在 ISP 中的帐号密码，以篡改 DNS 指向一个黑页，又或者找到了目标的社交帐号，在微博/QQ/邮箱上，对虚拟资产进行非授权的控制，都属于入侵的范畴。
针对企业的入侵检测
企业入侵检测的范围，多数情况下比较狭义：一般特指黑客对 PC、系统、服务器、网络(包括办公网、生产网)控制的行为。黑客对 PC、服务器等主机资产的控制，最常见的方法是通过 Shell 去执行指令，获得 Shell 的这个动作叫做 GetShell。比如通过 Web 服务的上传漏洞，拿到 WebShell，或者利用 RCE 漏洞直接执行命令/代码(RCE 环境变相的提供了一个 Shell)。另外，通过某种方式先植入“木马后门”，后续直接利用木马集成的 Shell 功能对目标远程控制，这个也比较典型。
因此，入侵检测可以重点关注 GetShell 这个动作，以及 GetShell 成功之后的恶意行为(为了扩大战果，黑客多半会利用 Shell 进行探测、翻找窃取、横向移动攻击其他内部目标，这些区别于好人的特性也可以作为重要的特征)。有一些同行(包括商业产品)，喜欢报告 GetShell 之前的一些“外部扫描、攻击探测和尝试行为”，并美其名曰“态势感知”，告诉企业有人正在“试图攻击”。在笔者看来，实战价值并不大。包括美团在内的很多企业，基本上无时无刻都在遭受“不明身份”的攻击。知道了有人在“尝试”攻击，如果并不能有效地去行动，无法有效地对行动进行告警，除了耗费心力之外，并没有太大的实际价值。
当我们习惯“攻击”是常态之后，就会在这样的常态下去解决问题，可以使用什么加固策略，哪些可以实现常态化的运营，如果有什么策略无法常态化运营。比如需要很多人加班临时突击守着，那这个策略多半在不久之后就会逐渐消逝掉。跟我们做不做这个策略，并没有本质上的区别。类似于 SQL 注入、XSS 等一些不直接 GetShell 的 Web 攻击，暂时不在狭义的“入侵检测”考虑范围，建议可以划入“漏洞”、“威胁感知”等领域，另行再做探讨。当然，利用 SQL 注入、XSS 等入口，进行了 GetShell 操作的，我们仍抓 GetShell 这个关键点，不必在乎漏洞入口在何处。

“入侵”和“内鬼”

与入侵接近的一种场景是“内鬼”。入侵本身是手段，GetShell 只是起点，黑客 GetShell 的目标是为了之后对资源的控制和数据的窃取。而“内鬼”天然拥有合法的权限，可以合法接触敏感资产，但是基于工作以外的目的，他们对这些资源进行非法的处置，包括拷贝副本、转移外泄、篡改数据牟利等。



内鬼的行为不在“入侵检测”的范畴，一般从内部风险控制的视角进行管理和审计，比如职责分离、双人审计等。也有数据防泄密产品(DLP)对其进行辅助，这里不展开细说。
有时候，黑客知道员工 A 有权限接触目标资产，便定向攻击 A，再利用 A 的权限把数据窃取走，也定性为“入侵”。毕竟 A 不是主观恶意的“内鬼”。如果不能在黑客攻击 A 的那一刻捕获，或者无法区分黑客控制的 A 窃取数据和正常员工 A 的访问数据，那这个入侵检测也是失败的。
入侵检测的本质
前文已经讲过，入侵就是黑客可以不经过我们的同意，来操作我们的资产，在手段上并没有任何的限制。那么如何找出入侵行为和合法正常行为的区别，将其跟合法行为进行分开，就是“入侵发现”。在算法模型上，这算是一个标记问题(入侵、非入侵)。可惜的是，入侵这种动作的“黑”样本特别稀少，想通过大量的带标签的数据，有监督的训练入侵检测模型，找出入侵的规律比较难。因此，入侵检测策略开发人员，往往需要投入大量的时间，去提炼更精准的表达模型，或者花更多的精力去构造“类似入侵”的模拟数据。
一个经典的例子是，为了检测出 WebShell，安全从业人员可以去 GitHub 上搜索一些公开的 WebShell 样本，数量大约不到 1000 个。而对于机器学习动辄百万级的训练需求，这些数据远远不够。况且 GitHub 上的这些样本集，从技术手法上来看，有单一技术手法生成的大量类似样本，也有一些对抗的手法样本缺失。因此，这样的训练，试图让 AI 去通过“大量的样本”掌握 WebShell 的特征并区分出它们，原则上不太可能完美地去实现。此时，针对已知样本做技术分类，提炼更精准的表达模型，被称为传统的特征工程。而传统的特征工程往往被视为效率低下的重复劳动，但效果往往比较稳定，毕竟加一个技术特征就可以稳定发现一类 WebShell。而构造大量的恶意样本，虽然有机器学习、AI 等光环加持，但在实际环境中往往难以获得成功：自动生成的样本很难描述 WebShell 本来的含义，多半描述的是自动生成的算法特征。
另一个方面，入侵的区别是看行为本身是否“授权”，而授权与否本身是没有任何显著的区分特征的。因此，做入侵对抗的时候，如果能够通过某种加固，将合法的访问收敛到有限的通道，并且给该通道做出强有力的区分，也就能大大的降低入侵检测的成本。例如，对访问来源进行严格的认证，无论是自然人，还是程序 API，都要求持有合法票据。而派发票据时，针对不同情况做多纬度的认证和授权，再用 IAM 针对这些票据记录和监控它们可以访问的范围，还能产生更底层的 Log 做异常访问模型感知。这个全生命周期的风控模型，也是 Google 的 BeyondCorp 无边界网络得以实施的前提和基础。
因此，入侵检测的主要思路也就有两种：

根据黑特征进行模式匹配(例如 WebShell 关键字匹配)。

根据业务历史行为(生成基线模型)，对入侵行为做异常对比(非白即黑)，如果业务的历史行为不够收敛，就用加固的手段对其进行收敛，再挑出不合规的小众异常行为。

入侵检测与攻击向量
根据目标不同，可能暴露给黑客的攻击面会不同，黑客可能采用的入侵手法也就完全不同。比如，入侵我们的 PC/笔记本电脑，还有入侵部署在机房/云上的服务器，攻击和防御的方法都有挺大的区别。针对一个明确的“目标”，它被访问的渠道可能是有限集，被攻击的必经路径也有限。“攻击方法”+“目标的攻击面”的组合，被称为“攻击向量”。因此，谈入侵检测模型效果时，需要先明确攻击向量，针对不同的攻击路径，采集对应的日志(数据)，才可能做对应的检测模型。
比如，基于 SSH 登录后的 Shell 命令数据集，是不能用于检测 WebShell 的行为。而基于网络流量采集的数据，也不可能感知黑客是否在 SSH 后的 Shell 环境中执行了什么命令。基于此，如果有企业不提具体的场景，就说做好了 APT 感知模型，显然就是在“吹嘘”了。所以，入侵检测得先把各类攻击向量罗列出来，对每一个细分场景分别采集数据(HIDS+NIDS+WAF+RASP+应用层日志+系统日志+PC……)，再结合公司的实际数据特性，作出适应公司实际情况的对应检测模型。不同公司的技术栈、数据规模、暴露的攻击面，都会对模型产生重大的影响。比如很多安全工作者特别擅长 PHP 下的 WebShell 检测，但是到了一个 Java 系的公司……
常见的入侵手法与应对
如果对黑客的常见入侵手法理解不足，就很难有的放矢，有时候甚至会陷入“政治正确”的陷阱里。比如渗透测试团队说，我们做了 A 动作，你们竟然没有发现，所以你们不行。而实际情况是，该场景可能不是一个完备的入侵链条，就算不发现该动作，对入侵检测效果可能也没有什么影响。每一个攻击向量对公司造成的危害，发生的概率如何进行排序，解决它耗费的成本和带来的收益如何，都需要有专业经验来做支撑与决策。
现在简单介绍一下，黑客入侵教程里的经典流程(完整过程可以参考杀伤链模型)：入侵一个目标之前，黑客对该目标可能还不够了解，所以第一件事往往是“踩点”，也就是搜集信息，加深了解。比如，黑客需要知道，目标有哪些资产(域名、IP、服务)，它们各自的状态如何，是否存在已知的漏洞，管理它们的人有谁(以及如何合法的管理的)，存在哪些已知的泄漏信息(比如社工库里的密码等)……一旦踩点完成，熟练的黑客就会针对各种资产的特性，酝酿和逐个验证“攻击向量”的可行性，下文列举了常见的攻击方式和防御建议。
高危服务入侵
所有的公共服务都是“高危服务”，因为该协议或者实现该协议的开源组件，可能存在已知的攻击方法(高级的攻击者甚至拥有对应的 0day)。只要你的价值足够高，黑客有足够的动力和资源去挖掘，那么当你把高危服务开启到互联网，面向所有人都打开的那一刻，就相当于为黑客打开了“大门”。比如 SSH、RDP 这些运维管理相关的服务，是设计给管理员用的，只要知道密码/秘钥，任何人都能登录到服务器端，进而完成入侵。而黑客可能通过猜解密码(结合社工库的信息泄露、网盘检索或者暴力破解)，获得凭据。
事实上这类攻击由于过于常见，黑客早就做成了全自动化的全互联网扫描的蠕虫类工具，云上购买的一个主机如果设置了一个弱口令，往往在几分钟内就会感染蠕虫病毒，就是因为这类自动化的攻击者实在是太多了。或许，你的密码设置得非常强壮，但是这并不是你可以把该服务继续暴露在互联网的理由，我们应该把这些端口限制好，只允许自己的 IP(或者内部的堡垒主机)访问，彻底断掉黑客通过它入侵我们的可能。
与此类似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync 等等，凡是自己用来管理服务器或者数据库、文件的服务，都不应该针对互联网无限制的开放。否则，蠕虫化的攻击工具会在短短几分钟内攻破我们的服务，甚至直接加密我们的数据，甚至要求我们支付比特币，进行敲诈勒索。还有一些高危服务存在 RCE 漏洞(远程命令执行)，只要端口开放，黑客就能利用现成的 exp，直接 GetShell，完成入侵。
防御建议： 针对每一个高危服务做入侵检测的成本较高，因为高危服务的具体所指非常的多，不一定存在通用的特征。所以，通过加固方式，收敛攻击入口性价比更高。禁止所有高危端口对互联网开放可能，这样能够减少 90% 以上的入侵概率。
Web 入侵
随着高危端口的加固，黑客知识库里的攻击手法很多都会失效了。但是 Web 服务是现代互联网公司的主要服务形式，不可能都关掉。于是，基于 PHP、Java、ASP、ASP.NET、Node、C 写的 CGI 等等动态的 Web 服务漏洞，就变成了黑客入侵的最主要入口。比如，利用上传功能直接上传一个 WebShell，利用文件包含功能，直接引用执行一个远程的 WebShell(或者代码)，然后利用代码执行的功能，直接当作 Shell 的入口执行任意命令，解析一些图片、视频的服务，上传一个恶意的样本，触发解析库的漏洞……
Web 服务下的应用安全是一个专门的领域(道哥还专门写了本《白帽子讲 Web 安全》)，具体的攻防场景和对抗已经发展得非常成熟了。当然，由于它们都是由 Web 服务做为入口，所以入侵行为也会存在某种意义上的共性。相对而言，我们比较容易能够找到黑客 GetShell 和正常业务行为的一些区别。针对 Web 服务的入侵痕迹检测，可以考虑采集 WAF 日志、Access Log、Auditd 记录的系统调用，或者 Shell 指令，以及网络层面 Response 相关的数据，提炼出被攻击成功的特征，建议我们将主要的精力放在这些方面。
0day 入侵
通过泄漏的工具包来看，早些年 NSA 是拥有直接攻击 Apache、Nginx 这些服务的 0day 武器的。这意味着对手很可能完全不用在乎我们的代码和服务写成什么样，拿 0day 一打，神不知鬼不觉就 GetShell 了。但是对于入侵检测而言，这并不可怕：因为无论对手利用什么漏洞当入口，它所使用的 Shellcode 和之后的行为本身依然有共性。Apache 存在 0day 漏洞被攻击，还是一个 PHP 页面存在低级的代码漏洞被利用，从入侵的行为上来看，说不定是完全一样的，入侵检测模型还可以通用。所以，把精力聚焦在有黑客 GetShell 入口和之后的行为上，可能比关注漏洞入口更有价值。当然，具体的漏洞利用还是要实际跟进，然后验证其行为是否符合预期。
办公终端入侵
绝大多数 APT 报告里，黑客是先对人(办公终端)下手，比如发个邮件，哄骗我们打开后，控制我们的 PC，再进行长期的观察/翻阅，拿到我们的合法凭据后，再到内网漫游。所以这些报告，多数集中在描述黑客用的木马行为以及家族代码相似度上。而反 APT 的产品、解决方案，多数也是在办公终端的系统调用层面，用类似的方法，检验“免杀木马”的行为。
因此，EDR 类的产品+邮件安全网关+办公网出口的行为审计+APT 产品的沙箱等，联合起来，可以采集到对应的数据，并作出相似的入侵检测感知模型。而最重要的一点，是黑客喜欢关注内部的重要基础设施，包括但不限于 AD 域控、邮件服务器、密码管理系统、权限管理系统等，一旦拿下，就相当于成为了内网的“上帝”，可以为所欲为。所以对公司来说，重要基础设施要有针对性的攻防加固讨论，微软针对 AD 的攻防甚至还发过专门的加固白皮书。
入侵检测基本原则
不能把每一条告警都彻底跟进的模型，等同于无效模型。入侵发生后，再辩解之前其实有告警，只是太多了没跟过来/没查彻底，这是“马后炮”，等同于不具备发现能力。所以对于日均告警成千上万的产品，安全运营人员往往表示很无奈。我们必须屏蔽一些重复发生的相似告警，以集中精力把每一个告警都闭环掉。这会产生白名单，也就是漏报，因此模型的漏报是不可避免的。由于任何模型都会存在漏报，所以我们必须在多个纬度上做多个模型，形成关联和纵深。
假设 WebShell 静态文本分析被黑客变形绕过了，在 RASP(运行时环境)的恶意调用还可以进行监控，这样可以选择接受单个模型的漏报，但在整体上仍然具备发现能力。既然每一个单一场景的模型都有误报漏报，我们做什么场景，不做什么场景，就需要考虑“性价比”。比如某些变形的 WebShell 可以写成跟业务代码非常相似，人的肉眼几乎无法识别，再追求一定要在文本分析上进行对抗，就是性价比很差的决策。如果通过 RASP 的检测方案，其性价比更高一些，也更具可行性一些。
我们不太容易知道黑客所有的攻击手法，也不太可能针对每一种手法都建设策略(考虑到资源总是稀缺的)。所以针对重点业务，需要可以通过加固的方式(还需要常态化监控加固的有效性)，让黑客能攻击的路径极度收敛，仅在关键环节进行对抗。起码能针对核心业务具备兜底的保护能力。
基于上述几个原则，我们可以知道一个事实，或许我们永远不可能在单点上做到 100% 发现入侵，但是我们可以通过一些组合方式，让攻击者很难绕过所有的点。当老板或者蓝军挑战，某个单点的检测能力有缺失时，如果为了“政治正确”，在这个单点上进行无止境的投入，试图把单点做到 100% 能发现的能力，很多时候可能只是在试图制造一个“永动机”，纯粹浪费人力、资源，而不产生实际的收益。将节省下来的资源，高性价比的布置更多的纵深防御链条，效果显然会更好。
入侵检测产品的主流形态
入侵检测终究是要基于数据去建模，比如针对 WebShell 的检测，首先要识别 Web 目录，再对 Web 目录下的文件进行文本分析，这需要做一个采集器。基于 Shell 命令的入侵检测模型，需要获取所有 Shell 命令，这可能要 Hook 系统调用或者劫持 Shell。基于网络 IP 信誉、流量 payload 进行检测，或者基于邮件网关对内容的检查，可能要植入网络边界中，对流量进行旁路采集。也有一些集大成者，基于多个 Sensor，将各方日志进行采集后，汇总在一个 SOC 或者 SIEM，再交由大数据平台进行综合分析。
因此，业界的入侵检测相关的产品大致上就分成了以下的形态：
①主机 Agent 类：黑客攻击了主机后，在主机上进行的动作，可能会产生日志、进程、命令、网络等痕迹，那么在主机上部署一个采集器(也内含一部分检测规则)，就叫做基于主机的入侵检测系统，简称 HIDS。
典型的产品：OSSEC、青藤云、安骑士、安全狗，Google 最近也发布了一个 Alpha 版本的类似产品 Cloud Security Command Center。当然，一些 APT 厂商，往往也有在主机上的 Sensor/Agent，比如 FireEye 等。
②网络检测类：由于多数攻击向量是会通过网络对目标投放一些 payload，或者控制目标的协议本身具备强特征，因此在网络层面具备识别的优势。
典型的产品：Snort 到商业的各种 NIDS/NIPS，对应到 APT 级别，则还有类似于 FireEye 的 NX 之类的产品。
③日志集中存储分析类：这一类产品允许主机、网络设备、应用都输出各自的日志，集中到一个统一的后台。
在这个后台，对各类日志进行综合的分析，判断是否可以关联的把一个入侵行为的多个路径刻画出来。
例如 A 主机的 Web 访问日志里显示遭到了扫描和攻击尝试，继而主机层面多了一个陌生的进程和网络连接，最后 A 主机对内网其他主机进行了横向渗透尝试。
典型的产品：LogRhythm、Splunk 等 SIEM 类产品。
④APT 沙箱：沙箱类产品更接近于一个云端版的高级杀毒软件，通过模拟执行观测行为，以对抗未知样本弱特征的特点。
只不过它需要一个模拟运行的过程，性能开销较大，早期被认为是“性价比不高”的解决方案，但由于恶意文件在行为上的隐藏要难于特征上的对抗，因此现在也成为了 APT 产品的核心组件。
通过网络流量、终端采集、服务器可疑样本提取、邮件附件提炼等拿到的未知样本，都可以提交到沙箱里跑一下行为，判断是否恶意。
典型产品：FireEye、Palo Alto、Symantec、微步。
⑤终端入侵检测产品：移动端目前还没有实际的产品，也不太有必要。PC 端首先必备的是杀毒软件，如果能够检测到恶意程序，一定程度上能够避免入侵。
但是如果碰到免杀的高级 0day 和木马，杀毒软件可能会被绕过。借鉴服务器上 HIDS 的思路，也诞生了 EDR 的概念，主机除了有本地逻辑之外，更重要的是会采集更多的数据到后端，在后端进行综合分析和联动。
也有人说下一代杀毒软件里都会带上 EDR 的能力，只不过目前销售还是分开在卖。
典型产品：杀毒软件有 Bit9、SEP、赛门铁克、卡巴斯基、McAfee ;EDR产品不枚举了，腾讯的 iOA、阿里的阿里郎，一定程度上都是可以充当类似的角色。
入侵检测效果评价指标
首先，主动发现的入侵案例/所有入侵 = 主动发现率。这个指标一定是最直观的。比较麻烦的是分母，很多真实发生的入侵，如果外部不反馈，我们又没检测到，它就不会出现在分母里，所以有效发现率总是虚高的，谁能保证当前所有的入侵都发现了呢?但是实际上，只要入侵次数足够多，不管是 SRC 收到的情报，还是“暗网”上报出来的一个大新闻，把客观上已经知悉的入侵列入分母，总还是能计算出一个主动发现率的。
另外，真实的入侵其实是一个低频行为，大型的互联网企业如果一年到头成百上千的被入侵，肯定也不正常。因此，如果很久没出现真实入侵案例，这个指标长期不变化，也无法刻画入侵检测能力是否在提升。所以，我们一般还会引入两个指标来观测：

蓝军对抗主动发现率

已知场景覆盖率

蓝军主动高频对抗和演习，可以弥补真实入侵事件低频的不足，但是由于蓝军掌握的攻击手法往往也是有限的，他们多次演习后，手法和场景可能会被罗列完毕。
假设某一个场景建设方尚未补齐能力，蓝军同样的姿势演习 100 遍，增加 100 个未发现的演习案例，对建设方而言并没有更多的帮助。所以，把已知攻击手法的建成覆盖率拿出来，也是一个比较好的评价指标。
入侵检测团队把精力聚焦在已知攻击手法的优先级评估和快速覆盖上，对建设到什么程度是满足需要的，要有自己的专业判断(参考入侵检测原则里的“性价比”原则)。
而宣布建成了一个场景的入侵发现能力，是要有基本的验收原则的：

该场景日均工单

同一个事件只告警首次，多次出现自动聚合。

具备误报自学习能力。

告警具备可读性(有清晰的风险阐述、关键信息、处理指引、辅助信息或者索引，便于定性)，不鼓励 Key-Value 模式的告警，建议使用自然语言描述核心逻辑和响应流程。

有清晰的说明文档，自测报告(就像交付了一个研发产品，产品文档和自测过程是质量的保障)。

有蓝军针对该场景实战验收报告。

不建议调用微信、短信等接口发告警(告警和事件的区别是，事件可以闭环，告警只是提醒)，统一的告警事件框架可以有效的管理事件确保闭环，还能提供长期的基础运营数据，比如止损效率、误报量/率。

策略人员的文档应当说明当前模型对哪些情况具备感知能力，哪些前提下会无法告警(考验一个人对该场景和自己模型的理解能力)。通过前述判断，可以对策略的成熟度形成自评分，0-100 自由大致估算。单个场景往往很难达到 100 分，但那并没有关系，因为从 80 分提升到 100 分的边际成本可能变的很高。不建议追求极致，而是全盘审视，是否快速投入到下一个场景中去。
如果某个不到满分的场景经常出现真实对抗，又没有交叉的其他策略进行弥补，那自评结论可能需要重审并提高验收的标准。至少解决工作中实际遇到的 Case 要优先考虑。
影响入侵检测的关键要素
讨论影响入侵检测的要素时，我们可以简单看看，曾经发生过哪些错误导致防守方不能主动发现入侵：

依赖的数据丢失，比如 HIDS 在当事机器上，没部署安装/Agent 挂了/数据上报过程丢失了/Bug 了，或者后台传输链条中丢失数据。

策略脚本 Bug，没启动(事实上我们已经失去了这个策略感知能力了)。

还没建设对应的策略(很多时候入侵发生了才发现这个场景我们还没来得及建设对应的策略)。

策略的灵敏度/成熟度不够(比如扫描的阈值没达到，WebShell 用了变形的对抗手法)。

模型依赖的部分基础数据错误，做出了错误的判断。

成功告警了，但是负责应急同学错误的判断/没有跟进/辅助信息不足以定性，没有行动起来。

所以实际上，要让一个入侵事件被捕获，我们需要入侵检测系统长时间、高质量、高可用的运行。这是一件非常专业的工作，超出了绝大多数安全工程师能力和意愿的范畴。所以建议指派专门的运营人员对以下目标负责：

数据采集的完整性(全链路的对账)。

每一个策略时刻工作正常(自动化拨测监控)。

基础数据的准确性。

工单运营支撑平台及追溯辅助工具的便捷性。

可能有些同学会想，影响入侵检测的关键要素，难道不是模型的有效性么?怎么全是这些乱七八糟的东西?实际上，大型互联网企业的入侵检测系统日均数据量可能到达数百 T，甚至更多。涉及到数十个业务模块，成百上千台机器。从数字规模上来说，不亚于一些中小型企业的整个数据中心。这样复杂的一个系统，要长期维持在高可用标准，本身就需要有 SRE、QA 等辅助角色的专业化支持。如果仅依靠个别安全工程师，很难让其研究安全攻防的时候，又兼顾到基础数据质量、服务的可用性和稳定性、发布时候的变更规范性、各类运营指标和运维故障的及时响应。最终的结果就是能力范围内可以发现的入侵，总是有各种意外“恰好”发现不了。
所以，笔者认为，以多数安全团队运营质量之差，其实根本轮不到拼策略(技术)。当然，一旦有资源投入去跟进这些辅助工作之后，入侵检测就真的需要拼策略了。此时，攻击手法有那么多，凭什么先选择这个场景建设?凭什么认为建设到某程度就足够满足当下的需要了?凭什么选择发现某些样本，而放弃另一些样本的对抗?这些看似主观性的东西，非常考验专业判断力。而且在领导面前很容易背上“责任心不足”的帽子。比如为困难找借口而不是为目标找方法，这个手法黑客攻击了好多次，凭什么不解决，那个手法凭什么说在视野范围内，但是要明年再解决?
如何发现 APT?
所谓 APT，就是高级持续威胁。既然是高级的，就意味着木马很大可能是免杀的(不能靠杀毒软件或者普通的特征发现)，利用的漏洞也是高级的(加固到牙齿可能也挡不住敌人进来的步伐)，攻击手法同样很高级(攻击场景可能我们都没有见过)。所以，实际上 APT 的意思，就约等于不能被发现的入侵。然而，业界总还有 APT 检测产品，解决方案的厂商在混饭吃，他们是怎么做的呢?

木马免杀的，用沙箱+人工分析，哪怕效率低一些，还是试图做出定性，并快速的把 IOC(威胁情报)同步给其他客户，发现 1 例，全球客户都具备同样的感知能力。

流量加密变形对抗的，用异常检测的模型，把一些不认识的可疑的 IP 关系、payload 给识别出来。当然，识别出来之后，也要运营人员跟进得仔细，才能定性。

攻击手法高级的，还是会假定黑客就用鱼叉、水坑之类的已知手法去执行，然后在邮箱附件、PC 终端等环节采集日志，对用户行为进行分析，UEBA 试图寻找出用户异于平常的动作。

那么，我们呢?笔者也没有什么好的办法，可以发现传说中的“免杀”的木马，但是我们可以针对已知的黑客攻击框架(比如 Metasploit、Cobalt Strike)生成的样本、行为进行一些特征的提取。我们可以假设已经有黑客控制了某一台机器，但是它试图进行横向扩散的时候，我们有一些模型可以识别这个主机的横向移动行为。
笔者认为，世界上不存在 100% 能发现 APT 的方法。但是我们可以等待实施 APT 的团队犯错，只要我们的纵深足够的多，信息足够不对称，想要完全不触碰我们所有的铃铛，绝对存在一定的困难。甚至，攻击者如果需要小心翼翼的避开所有的检测逻辑，可能也会给对手一种心理上的震慑，这种震慑可能会延缓对手接近目标的速度，拉长时间。而在这个时间里，只要他犯错，就轮到我们出场了。
前面所有的高标准，包括高覆盖、低误报，强制每一个告警跟进到底，“掘地三尺”的态度，都是在等待这一刻。抓到一个值得敬佩的对手，那种成就感，还是很值得回味的。所以，希望所有从事入侵检测的安全同行们都能坚持住，即使听过无数次“狼来了”，下一次看到告警，依然可以用最高的敬畏心去迎接对手(告警虐我千百遍，我待告警如初恋)。
AI 在入侵检测领域的正确姿势
最近这两年，如果不谈 AI 的话，貌似故事就不会完整。只不过，随着 AI 概念的火爆，很多人已经把传统的数据挖掘、统计分析等思想，比如分类、预测、聚类、关联之类的算法，都一律套在 AI 的帽子里。



其实 AI 是一种现代的方法，在很多地方有非常实际的产出了。以 WebShell 的文本分析为例，我们可能需要花很长很长的时间，才能把上千个样本里隐含的几十种样本技术类型拆分开，又花更长的时间去一一建设模型(是的，在这样的场景下，特征工程真的是一个需要更长时间的工作)。而使用 AI，做好数据打标的工作，训练、调参，很快就能拿到一个实验室环境不那么过拟合的模型出来，迅速投产到生产环境上。熟练一点可能 1-2 个月就能做完了。
在这种场景下，AI 这种现代的方法，的确能极大的提高效率。但问题是，前文也提到过了，黑客的攻击黑样本、WebShell 的样本，往往极其稀缺，它不可能是完备的能够描述黑客入侵的完整特征的。因此，AI 产出的结果，无论是误报率还是漏报率，都会受训练方法和输入样本的影响较大，我们可以借助 AI，但绝对不能完全交给 AI。
安全领域一个比较常见的现象是，将场景转变成标记问题，要难于通过数学模型把标记的解给求出来。此时往往需要安全专家先行，算法专家再跟上，而不能直接让算法专家“孤军奋战”。针对一个具体的攻击场景，怎么样采集对应的入侵数据，思考这个入侵动作和正常行为的区别，这个特征的提取过程，往往决定了模型最终的效果。特征决定了效果的上限，而算法模型只能决定了有多接近这个上限。
此前，笔者曾见过一个案例，AI 团队产出了一个实验室环境效果极佳，误报率达到1/1000000 的 WebShell 模型，但是投放到生产环境里初期日均告警 6000 单，完全无法运营，同时还存在不少漏报的情况。这些情况随着安全团队和 AI 工程师共同的努力，后来逐渐地解决。但是并未能成功的取代原有的特征工程模型。目前业界有许多产品、文章在实践 AI，但遗憾的是，这些文章和产品大多“浅尝辄止”，没有在真实的环境中实践运营效果。一旦我们用前面的标准去要求它，就会发现，AI 虽然是个好东西，但是绝对只是个“半成品”。真正的运营，往往需要传统的特征工程和 AI 并行，也需要持续地进行迭代。
未来必然是 AI 的天下，但是有多少智能，前面可能就要铺垫多少人工。愿与同行们一起在这个路上继续探索下去，多多交流分享。（作者：弼政）