提示：正文共6400字，预计阅读需要17分钟

入侵检测

入侵检测是帮助系统对付网络攻击，扩展了系统管理员的安全管理能力(包括安全审计、监视、进攻识别和响应)，提高了信息安全基础结构的完整性。它从计算机网络系统中的若干关键点收集信息，并分析这些信息，看看网络中是否有违反安全策略的行为和遭到袭击的迹象。入侵检测是系统保护的最后一道安全闸门，在不影响网络和主机性能的情况下进行监测，从而提供对内部攻击、外部攻击和误操作的实时保护。

入侵行为的影响程度取决于对信息安全CIA三元组的破坏程度、商业压力及监管压力等多方面的影响。

黑客在未经授权的情况下，控制、使用我方资源（包括但不限于读写数据、执行命令、控制资源等）达到各种目的。从广义上讲，黑客利用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这个关键点，不必在乎漏洞入口在何处。

入侵检测技术

入侵检测技术：入侵检测是指“通过对行为、安全日志或审计数据或其它网络上可以获得的信息进行操作，检测到对系统的闯入或闯入的企图”。

入侵检测技术从结构上包含：入侵检测知识库、入侵检测主体、入侵检测体系等子结构。

1.     通过特征、模型、异常检测等手段进行入侵防御。

2.     部署于主机之上，实现无盲区覆盖。

3.     在高可用场景下依然可用，基于异常的启发式规则，将变种入侵手段通过行为特征捕获。

4.     可通过时间窗口关联多次行为特征，提高入侵检测的敏感和准确度。

5.     基于已知的行为判断发现发现未知的入侵行为。

入侵检测体系

入侵检测体系是根据入侵检测知识库建立的对抗入侵行为的制度和框架。入侵检测体系从粗糙臃肿、定位笼统不清晰的安全运营体系中抽离并对入侵检测体系再次抽象。

从而对企业内部入侵检测制度规范、检测策略、框架产生定义。入侵检测主体根据入侵检测知识库提供设计指导思想，建设和实施入侵检测体系。对检测到入侵行为后还原事件提供极大的帮助。

入侵检测框架

入侵检测框架是入侵检测实施主体结合入侵检测体系的制度规范、入侵检测框架的设计需求，对入侵检测系统的产生定义。为入侵检测系统实例提供设计标准，功能模块等方面的指导思想。是为了提高同步性、整合性、解耦方面的产物。

鲁棒性：比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。

入侵检测目标

1.      解决现有入侵检测商业化方案不能完美符合企业要求的问题：

• 性价比差：商业化解决方案对于技术成熟度高的企业收费和回报不成正比。

• 扩展性差：产品难以自主控制，扩展性小，无法随性更改功能模块，难以满足企业定制化要求。

• 定制性差：针对特殊场景的感知能力有限，不开放检测策略，难以满足安全工程师对于自身企业自定义策略。

• 关联性差，难以和其他入侵检测系统进行适配，无法完善的贴合已有入侵检测框架及入侵检测体系。

• 响应度差，需求得不到及时的回应，总是会被排期。

2.     解决入侵检测效率低下的问题

• 散乱无章的入侵检测实例各自为战、不能统一结合，既无法产生十分准确的感知，每个实例又单独生产出海量告警，使运营人员响应效率低下，长期以往意志消耗殆尽，从而丧失作战能力。

• 通过入侵检测框架中各个系统实例交叉验证、联动分析，降低误报率

3.     解决无完善标准化流程的问题

• 建立入侵检测体系中策略、制度、规范流程，整体从而在入侵检测体系上提升的预防、检测、缓解、事件响应、事件还原能力，而不是依赖单个入侵检测实例、入侵检测主体的技能经验，无规范、无序的解决以上问题。

4.     提升复杂入侵场景感知难的能力：

• 提升入侵检测技术之间的协同：近几年安全能力迅速发展，0day、Nday和APT泛滥，对抗利用各类Web应用、其他应用，操作系统的0day、Nday等等的漏洞入侵过程中，如果没有高效的情报协同，实施主体快速制定的制度、策略，准确无误的安全系统策略下发，无情报的协同的入侵检测，就无法使制度、策略、框架等多元因素高效协同；

• 提升体系中各个元素之间的协同能力：通过入侵检测体系中制度、策略、框架、主体之间有限融合、高效协同，通过解决复杂入侵场景中入侵行为感知困难的问题。

• 弥补静态的、未整合的资源下检测能力不足的缺陷：静态的，未整合的资源及环境在应对多方位、多变的入侵时，无论从预防过程、实践效率，还是结果上来看都很难满足对抗部分现有入侵的需求，企业面临的多变的入侵风险的现状从本质上决定了入侵监测体系是动态的，可扩展的；而静态则意味着包含缺陷、盲区、缺乏维护等因素。建立入侵检测体系恰恰就是以高效检测入侵行为为目标，最大程度上解决这些问题。

5.      解决经验无法赋能至体系中的问题

1)      事件响应后通过复盘优化入侵检测知识库，知识库再对系统赋能形成响应闭环。

6.     解决体系中因制度、策略、框架过度耦合带来的一些问题，将入侵检测体系中的制度、策略、框架在一定程度上解耦。

• 避免制度发生变更后同步至策略、框架困难；

• 避免一类入侵检测实例发生问题后，导致其他入侵检测实例功能失效；

• 避免主体与框架过度耦合，如发生人员离职后检测框架因入侵检测实例缺乏维护，影响整个入侵检测系统正常运行。

• 避免实例间过度耦合，实例发生故障而导致牵一发而动全身的情况。

• 除复杂的入侵场景以外，应依靠框架感知大部分入侵行为，避免更换主体后影响入侵检测框架的感知、事件还原等功能。在框架中实例开发时，应尽量使用易用、易维护、符合评估要求的公共组件。

入侵检测系统

入侵检测系统是根据入侵检测框架设计需求实现的结构化系统实例。含有对入侵行为进行自动化的监视、审计、缓解、阻断，事件还原等方面功能。每个入侵检测系统实例基本含有四个模块：事件产生、事件数据库、事件分析引擎、事件告警引擎触发。每一个入侵检测实例含有一个或多个模块。根据企业环境，各个实例的数据库、分析引擎、告警引擎可能有不同程度的统一。各个模块也可能多次、交叉、无固定顺序的进行关联形成一个联合整体。（大多数情况下，阻断功能可能会影响业务的正常进行，不建议轻易尝试）

入侵检测实例

1.      基线监控系统：基于安全策略基线的采集、审计、配置的近实时或定时基线监控系统。基线监控系统也可整合至HIDS，也可在依靠操作系统自带的高级审核功能作为引擎。

策略：

制度：包含在入侵检测体系内

框架：包含在入侵检测框架内

2.      网络入侵检测系统（NIDS）：基于网络流量特征、网络流量模型及启发式逻辑对监视、审计、控制的网络入侵检测系统（传统NIDS及基于模型的Web IDS/WAF）；

3.      终端入侵检测系统（HIDS）：基于终端行为对操作系统的程序，可执行代码，异常操作等可疑行为监视、审计的主机入侵检测系统；

4.      反病毒系统（AV）：基于终端的对恶意程序，恶意代码执行监视、控制的反恶意（反木马、病毒、蠕虫、勒索）行为的入侵防御系统；

5.      防泄漏系统：基于终端或网络，对机密信息非正常或过程的转移、窃取、复制等异常行为预防、检测、缓解的（针对企业机密的透明加解密（HDLP）、网络行为审计（NDLP、行为审计）、非信任设备监控）系统；

6.      公共流数据处理引擎：基于大数据产生的数据处理引擎，用于实时数据清洗和存储，决定了告警的准确性和实时性。

7.      公共安全信息事件管理系统：基于事件处理流程的事件告警、展示、管理的系统。

8.      威胁情报的系统：实施主体通过各种渠道积极获取威胁情报或者购买威胁情报厂商产品；

9.      恶意样本分析沙箱：基于动静态结合的手段，通过分析未知文件的特征、行为的恶意文件检测沙箱。

10.    蜜罐诱饵系统：基于伪/实状态结合的陷阱、诱饵式信息系统对入侵者进行情报收集的系统（蜜罐）；

11.    其他可扩展的对非正常手段或过程监视、审计、控制的入侵检测系统；

    1.   基于单实例单点感知的直接异常检测

    2.   基于单实例多点感知的时序异常检测

    3.   基于短时间内多个实例异常的组合事件检测

常见的入侵手法与应对

如果对黑客的常见入侵手法理解不足，就很难有的放矢，有时候甚至会陷入“政治正确”的陷阱里。比如渗透测试团队说，我们做了A动作，你们竟然没有发现，所以你们不行。而实际情况是，该场景可能不是一个完备的入侵链条，就算不发现该动作，对入侵检测效果可能也没有什么影响。每一个攻击向量对公司造成的危害，发生的概率如何进行排序，解决它耗费的成本和带来的收益如何，都需要有专业经验来做支撑与决策。

现在简单介绍一下，黑客入侵教程里的经典流程（完整过程可以参考杀伤链模型）：

入侵一个目标之前，黑客对该目标可能还不够了解，所以第一件事往往是“踩点”，也就是搜集信息，加深了解。比如，黑客需要知道，目标有哪些资产（域名、IP、服务），它们各自的状态如何，是否存在已知的漏洞，管理他们的人有谁（以及如何合法的管理的），存在哪些已知的泄漏信息（比如社工库里的密码等）......

一旦踩点完成，熟练的黑客就会针对各种资产的特性，酝酿和逐个验证“攻击向量”的可行性，下文列举了常见的攻击方式和防御建议。

高危服务入侵

所有的公共服务都是“高危服务”，因为该协议或者实现该协议的开源组件，可能存在已知的攻击方法（高级的攻击者甚至拥有对应的0day），只要你的价值足够高，黑客有足够的动力和资源去挖掘，那么当你把高危服务开启到互联网，面向所有人都打开的那一刻，就相当于为黑客打开了“大门”。

比如SSH、RDP这些运维管理相关的服务，是设计给管理员用的，只要知道密码/秘钥，任何人都能登录到服务器端，进而完成入侵。而黑客可能通过猜解密码（结合社工库的信息泄露、网盘检索或者暴力破解），获得凭据。事实上这类攻击由于过于常见，黑客早就做成了全自动化的全互联网扫描的蠕虫类工具，云上购买的一个主机如果设置了一个弱口令，往往在几分钟内就会感染蠕虫病毒，就是因为这类自动化的攻击者实在是太多了。

或许，你的密码设置得非常强壮，但是这并不是你可以把该服务继续暴露在互联网的理由，我们应该把这些端口限制好，只允许自己的IP（或者内部的堡垒主机）访问，彻底断掉黑客通过它入侵我们的可能。

与此类似的，MySQL、Redis、FTP、SMTP、MSSQL、Rsync等等，凡是自己用来管理服务器或者数据库、文件的服务，都不应该针对互联网无限制的开放。否则，蠕虫化的攻击工具会在短短几分钟内攻破我们的服务，甚至直接加密我们的数据，甚至要求我们支付比特币，进行敲诈勒索。

还有一些高危服务存在RCE漏洞（远程命令执行），只要端口开放，黑客就能利用现成的exploit，直接GetShell，完成入侵。

防御建议：针对每一个高危服务做入侵检测的成本较高，因为高危服务的具体所指非常的多，不一定存在通用的特征。所以，通过加固方式，收敛攻击入口性价比更高。禁止所有高危端口对互联网开放可能，这样能够减少90%以上的入侵概率。

Web入侵

随着高危端口的加固，黑客知识库里的攻击手法很多都会失效了。但是Web服务是现代互联网公司的主要服务形式，不可能都关掉。于是，基于PHP、Java、ASP、ASP.NET、Node、C写的CGI等等动态的Web服务漏洞，就变成了黑客入侵的最主要入口。

比如，利用上传功能直接上传一个WebShell，利用文件包含功能，直接引用执行一个远程的WebShell（或者代码），然后利用代码执行的功能，直接当作Shell的入口执行任意命令，解析一些图片、视频的服务，上传一个恶意的样本，触发解析库的漏洞......

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的攻防甚至还发过专门的加固白皮书。

写在结尾

本文大多数思路来自于公开资料，经过自己学习结合工作经验产出，如有错误可联系修改。

建了个群，有兴趣的师傅可以加一下。

点赞，转发，在看