企业网络安全之主机入侵检测
一次性付费进群，长期免费索取教程，没有付费教程。
教程列表见微信公众号底部菜单
进微信群回复公众号：微信群；QQ群：460500587
微信公众号：计算机与网络安全
ID：Computer-network
主机入侵检测系统（Host-based Intrusion Detection System，HIDS）顾名思义是基于主机的入侵检测系统，是部署在需要防护的主机服务器上的一种软件。由于其开发部署需要考虑业务环境，其架构对业务系统侵入性的部署也带来了版本适配等开发难题，同时部署过程也需要耗费大量运维成本。商用产品较少，以至于现在市面上知名的商用HIDS几乎没有。在开源产品方面有著名的OSSEC，被各中小型互联网公司选用。各大互联网公司则因为生产网络的海量IDC环境不得不自研HIDS产品，这些自研的HIDS在入侵对抗的一线不断的迭代更新，其能力和效果甚至会比商业产品更好，至少非常适合自身的生产网环境，同时根据自身安全需求它们往往已经不再是传统的标准HIDS架构。
一、开源产品OSSEC
OSSEC是著名的开源HIDS产品，且长期维护更新。它的版本覆盖了主流操作系统，支持Linux\BSD\Windows，以及Linux的多个发行版的不同版本，并提供源码安装，RPM和DEB安装方式。非常适合中小型网络，服务器规模小于10000台的生产网环境。同时还出现了Virtual Appliance版，那些使用云服务的小企业也可以选择此类部署方式。
OSSEC是典型的BS架构，Agent端会通过各种模块，分析并采集数据上报到Server，如图1所示。在Server端接受数据，并分析数据存储到DB或通过WUI展现。其Agent和Server端都可以通过二次开发，规则变更等方式，增强其检测能力，所以也可以把OSSEC当成一个数据采集处理框架。
图1 OSSEC典型架构
根据处理数据量和机房布置的需求，整个大的公司生产网可以划分成多个处理集群。Server端可以有不同的配置方式。通常一个Server集群（数据收集&分析&存储）最多配置2000台agent接入。
OSSEC的管理运营如下：
Agent部署——OSSEC的入侵检测能力基于各Agent从主机上采集到的数据的分析，在整套入侵检测系统建设第一步就是部署Agent，同一套入侵检测系统中可以有众多不同版本的Agent存在，包括Windows、Linux。OSSEC Agent在部署的时候会生成一个keys，用于与服务器的通信协议认证。所有操作系统的OSSEC Agent均以后台服务模式被安装。Agent端默认会采集某些系统数据，比如Linux系统的/var/log/message、/var/log/authlog、/var/www/logs/access_log等常见的入侵过程可能遗留下痕迹的地方。在Windows上则会采集系统上默认会存在的application、security、system三类日志。在木马检测方面，OSSEC AGENTS会根据配置项检测一些常见木马和文件异常行为。
配置管理——OSSEC的检测能力均来自数据采集与分析，而具体有什么能力则是通过配置来实现。分为：前端数据采集配置ossec-agent.conf；后端数据解析配置decoder.xml；数据分析规则配置rule/apache_rules.xml、rule/syslog_rules.xml等。自身系统的管理也是可配置的ossec.conf、ossec-server.conf，规则集管理和告警邮箱、扫描频率、木马特征库配置等。OSSEC配置管理如图2所示。
图2 OSSEC配置管理
OSSEC主要是通过配置文件来决定收集哪些信息，主要分为三类：系统自身产生的日志、任何用户配置的文本日志、通过OSSEC自带功能生成的数据日志。其检测能力如下：
（1）规则配置——配置文件以XML格式书写，一个典型的配置如下所示，这表示可采集本地的message和secure日志文件内容：
<localfile>
<log_format>syslog</log_format>
<location>/var/log/messages</location>
</localfile>
<localfile>
<log_format>syslog</log_format>
<location>/var/log/secure</location>
</localfile>
任何数据被收集到服务端之后，还需要通过decoder解码格式化为服务端分析所需格式，由配置文件decoder.xml定义解码规则。一个典型的解码规则如下所示：
<decoder name="sshd-success">
<parent>sshd</parent>
<prematch>^Accepted</prematch>
<regex offset="after_prematch">^ \S+ for (\S+) from (\S+) port </regex>
<order>user, srcip</order>
<fts>name, user, location</fts>
</decoder>
以上规则可以理解为“一个SSH登录成功记录”，并且会输出几个关键字段：用户、来源IP。
为了其数据分析的效率考虑，它做了很多优化的细节：
● 事件集归类，如上述示例会将匹配到的事件归类到SSHD事件集，方便后端的事件分析。
● 分级匹配，prematch预匹配一个粗粒度的正则表达式，避免不必要的全量原始数据直接进入复杂正则表达式，减轻数据格式化引擎负担。
● 众所周知，PCRE几乎是最强大的正则引擎，但因为它的强大也拖累了使用效率。OSSEC的正则表达式解析不使用PCRE正则引擎，而是自己实现了一个简化版的正则引擎称之为“os_regex Library”。
（2）默认能力\规则——当部署完毕OSSEC启动之后，安装包中自带的规则集就让您具备了初步的安全事件检测能力，包括但不限于以下内容：
● SSH破解相关规则。
● webserver（Apache\Nginx）日志检测规则。
● 杀毒软件（Symantec\calm）事件告警规则。
● 安全设备（IDS\FIREWALL\SonicWall）事件告警规则。
● DB（MySQL\postgresql）事件告警规则。
● Ftpserver（proftpd\pure-ftpd\ms-ftpd）事件告警规则。
● 其他常见应用服务事件告警规则。
（3）误报——作为一个开源软件，能够做到对一个中型生产网络的常见入侵事件的检测能力，确实难能可贵。但因其开源软件的属性，其功能基本上是满足基准需求，可用够用就好，在实际运营中会有很多的误报出现。为了对其误报场景有足够的理解，不会被其干扰，甚至可以按需调优。以下举例说明一些误报场景。
Rootkit检测误报——OSSEC的rootkit检测方式非常‘土’，但有效。其中“隐藏端口”检测逻辑是主动尝试去连接本地的1-65535端口，然后与netstat命令结果对比。整个逻辑清晰，代码也简洁，作为一个普通主机的安全检测是完全有效的。可是在一个负载很高业务进程繁忙的Server上很可能产生误报，因为每次的1-65535循环过程中，每个端口的检测逻辑按OSSEC代码来看就需要花4秒，加之netstat命令在高负载机器上也执行非常慢，在netstat还未执行完毕的时候，原先能connect的端口早已关闭，会导致误报“Kernel-level rootkit or trojaned”rootkit隐藏端口。
文件篡改检测误报——安全系统对于系统关键文件必须是要有监控的，常见的做法就是做MD5对比，OSSEC也有相应功能。有一种场景可能导致误报，当磁盘故障时，每次对同一个文件的MD5计算都不一样，OSSEC检测到这类事件会告警。所以碰到此类告警可能先要排除是系统故障的可能。
历史上各时期总会有不同的安全事件热点，远程缓冲层溢出攻击、弱口令破解、Web漏洞攻击等等，所以一成不变的规则是不能满足所有阶段以及所有企业的生产网风险场景的。需要不断迭代完善检测能力。
OSSEC拥有基础的入侵检测能力，同时也可以看做是一个基础数据采集和分析框架引擎，如果需要新增检测能力，通过增加数据和分析规则是可以实现的。OSSEC的功能扩展如图3所示。
图3 OSSEC功能扩展
扩展功能介绍如下：
（1）开发插件，生产数据——为了对某类事件有感知能力，首先开发扫描插件，譬如说木马检测场景中，需要关注服务器上新增了哪些可执行文件，以及这些文件的基础检测数据：ELF\PE文件信息；inode信息；编译时间；owner_uid；owner_name；符号表有哪些高危或敏感函数。重点关注的信息：
● 是否设置S位权限（每次启动可以拿到root权限）。
● 是否静态编译（黑客为了避免环境依赖等问题通常静态编译）。
● 是否非工作时间（黑客通常不在工作时间入侵）编译。
● 是否继承了某些攻击面服务进程属主账户（比如Apache\MySQL）。
● 是否有木马常用的函数（执行命令system，重定向输出dup，DDoS中多线程pthread_creat，Linux环境常见网络服务多线程模型用得较少）。
新增的扫描工具添加到crontab周期性运行，并将结果写入日志/va/log/Sensitive_elf，设定的日志格式在OSSEC Server端规则中需要解析。譬如一条新增elf文件的扫描信息上报如下：
Permission:S_ISUID|linked:static|inode:606356|ctime:22|owner_uid:501|owner_name:no
body|function:system,dup2,pthread_creat
（2）添加新的数据采集——新增工具部署完毕之后，需要修改ossec-agent.conf文件，新增日志采集配置：
<localfile>
<log_format> Sensitive_elf </log_format>
<location>/va/log/Sensitive_elf </location>
</localfile>
（3）开发解析\检测规则——当数据从agent端采集到Server端之后，第一步是需要解析格式化，这时需要修改的就是decoder.xml，通过对它的配置，可以让OSSEC能提取日志里的关键信息。
接下来到告警规则，在OSSEC安装目录的etc/rule/目录下新增一个xml配置文件，比如Sensitive_elf.xml。
继续按“新增可疑ELF文件”场景举例，新增一个检测规则描述“当新增的ELF文件包含任意3个危险特征判断为高危文件”，那么规则如下：
<rule id="54321" level="3">
<match>SUID|static|nobody||system|dup2|pthread_creat</match>
<description>dangerous execute binary file.</description>
</rule>
<rule id="543210" level="10" frequency="3">
<if_matched_sid>54321</if_matched_sid>
<same_source_ip />
<description>dangerous execute binary file.</description>
</rule>
二、MIG
Mozilla InvestiGator是一个开源的分布式取证框架，不能算是严格意义上的HIDS，但功能与HIDS类似，它主要作用是通过消息队列Active MQ在分布式的agent上执行系统检查命令然后返回结果，目前包含4个模块，分别是：文件（file）、网络（network）、内存（memory）、漏洞（vuln），如表1所示。
表1 MIG对各平台支持的功能
MIG系统架构如图4所示。
图4 MIG系统架构图
从这张图可以看出MIG具备了现代HIDS架构的雏形，但是整体上MIG偏向于事后的取证，而不是实时的入侵检测，所以只部署MIG还不能实现主机侧的入侵检测，必须辅之以其他的Agent，如OSSEC或Osquery等。
下面是一些比较直观的MIG适合干什么的列子：
如果您知道一个攻击特征，MIG能够迅速帮您查找哪些服务器上拥有这些特征：
同样，如果得知discuz某个版本的程序有漏洞，可以通过文件指纹（SHA256哈希值或其他）迅速查找匹配的机器，用以调查哪些地方需要修补。
总体上对于救火而言MIG是利器。
三、OSquery
Facebook的开源项目OSquery这个东西在国内比较冷门，它不能算是完全的HIDS，也不能说是完全为了安全而设计的，有一部分应该是出于运维的需求。它的实现是把操作系统当做一个数据库，各种系统信息可以用SQL语句的方式来查询，如下所示：
一般人可能不会把它联想到是一个安全强相关的系统，但是我们摘取一些它支持的查询项来看：
跟安全相关的项目不止这些，因篇幅关系不过多列举，这些查询项乍一看都很不起眼，不是直接可以检测安全的选项，大多数都不足以判断有无攻击或者是否被装了rootkit，但是如果周期性地轮询这些信息，通过消息队列将关键信息发送到云端进行如文件的完整性对比、进程树模型对比，就能检测是否正在遭受入侵、被提权、被攻击者创建新的进程等。能否实现实时入侵检测的关键在于采集数据的维度和云端的检测方法。大多数人的思路可能还停留在Agent直接告警的年代，这可能也是导致OSquery冷门的一个原因。
如果要正式在服务器上使用OSquery，它还不是一个成品，因为本身只是一个Agent程序，不是一个完整的HIDS，从日志聚合开始到云端分析的大数据平台以及管理端都需要自己去实现，只有实现了这些才算是一整套的平台，光有平台也还不行，还要定义BI的那些事情，采集哪些，分析什么，对于不够的数据采集点可以自行开发插件。总之，OSquery适合于有一定IDC规模的企业，安全团队有一定的开发能力，并且对入侵检测有基于大数据理解的环境。
四、自研Linux HIDS系统
互联网公司业务的急速扩张，也让各大公司的生产网环境急速膨胀，以至于他们的生产网安全对抗也变得更加复杂，使得几乎很难有一个可直接照搬或者购买部署的HIDS产品能满足需求，主要原因如下：
综上原因，往往各大互联网公司都会考虑自研HIDS类系统，并且这类HIDS也未必是市面上的通用HIDS模式，会根据企业自身的安全风险以及生产网架构适当调整风格，架构也有各自的独到之处。
1、架构设计
虽然HIDS在一个企业的安全体系中几乎成了一个基础设施般的存在，但在架构设计之初，第一步还是需要梳理清楚自己的安全需求，以及怎样适合企业自身运维体系，才能有更适合自身的架构。
行业法规需求——行业法规这里指上市公司审计要求，等级保护等。通常要求对系统账户登录有记录，有追溯审计能力。
基础安全需求——基础安全需求来自于常见入侵场景检测能力要求，一般逐一对应渗透入侵的各个环节的检测能力。如：端口扫描、SQL注入、命令注入、webshell、反连木马、嗅探、提权、文件篡改等。
企业自身的特殊安全风险需求——根据分析历史安全事件复盘和基线安全数据，推导出企业自身存在的特定安全特点和场景，为解决此类场景专设的能力。
运维体系\网络环境适应——根据风险需求分析选择更适合自身的架构，比如风险主要来自Web攻击，那么HIDS未必需要做内核模块功能；但如果是云租户环境则不同，因为云租户受到的攻击各种各样，往往很容易就被攻击拿到root权限，甚至会有更多的横向渗透过程，那么在内核态是有必要有安全措施的。
HIDS基本是CS架构，与传统安全软件不同的是，现在互联网公司的生产网环境对系统性能极为敏感，通常对安全系统提出较为苛刻的系统资源消耗指标要求，加之为快速应对新型风险的检测能力，使得主要的计算分析基本迁移到后端进行，前端仅仅以数据采集为主。HIDS系统架构如图5所示。
图5 HIDS系统架构
在超大型网络里，为考虑容灾，以及海量服务器和海量数据的性能压力，整套HIDS系统还会拆分成多个层级。第一级可按机房或某地区数据中心划分，每个部署单元设立两个以上接入Server作为容灾备份。在运营过程中，我们会发现大量垃圾数据、脏数据，考虑到跨区域传输对带宽的影响以及减少后端无意义计算，可以将第一级数据分析&格式化中心就近部署，仅将过滤之后的高价值数据向后面数据计算存储集群传输。
2、Agent功能模块
Agent分三个部分，安全功能模块、数据传输、管理模块。HIDS Agent架构如图6所示。
图6 HIDS Agent架构
安全功能模块是整个Agent的核心部分。各个功能模块既可以以单独进程也可以以线程模式存在，建议用独立进程模型，因为避免因单个BUG影响整个Agent系统的稳定性。这里的各个子模块的功能是对应于不同安全需求的，每个公司根据自身风险推导出的需求不一定相同，这里列举常见模块。
（1）基线安全
基线数据可以说是一个古老但不能舍弃的标配，采集主机上配置版本信息。主要针对两类需求：安全视角的软资产管理；0day应急。当新出现一个0day，需要通过基线数据及时知晓企业自身网络环境里受影响的范围有多大，并能直接导出iplist等信息，并指导应急响应下一步行动。此模块的采集方式，在Linux系统下以读取解析文本配置为主，辅以某些二进制文件的ELF格式解析；Windows系统通过读取注册表和组策略信息可完成采集。
可采集的数据包括但不限于以下信息：
● 系统版本，Linux发行版版本和内核版本包括内核热补丁等；Windows则包含补丁（微软官方补丁公告中注册表项）信息；
● 系统账户，Linux可直接取passwd文件或仅解析提取其中部分信息，如账户名、权限、以及shadow里的密码最后一次修改时间；Windows取账户权限、权限组、最后登录时间；
● 系统关键文件MD5；
● 应用服务版本，诸如sshd\ftp\telnetd\RDP版本信息
● 第三方应用服务版本，apache\nginx\tomcat\IIS\mysql\sqlserver\oracle版本信息；
● 第三方服务配置文件，webserver配置文件，web根目录路径，启动账户权限，支持的method\CGI\第三方模块信息；php配置，版本信息，安全配置项开关情况如safe_mode\disable_function\magic_quotes_gpc\safe_mode_exec_dir\safe_mode_include_dir\allow_url_include等；
●webapp版本，discuz\phpwind\phpbb\wordpress\thinkphp\phpcms\dedecms\struts\xwork等。
（2）日志采集
在较早的HIDS设计里日志采集也是标配，甚至是最核心功能。但事实上日志里的信息量较为有限，大量新的攻击手段，常规日志已不能覆盖其攻击面和攻击向量。采集的日志内容如下：
● Linux系统日志
● Syslog默认日志：/var/log/message
● 系统服务登录记录：/var/log/secure
● 系统账户登录记录：/var/log/secure
● Windows系统
● 应用服务日志：application（不少第三方服务日志也会写入这里，如sqlserver\Symantec\serv-U等）
● 安全日志：security
● 系统日志：system
● Webserver
● 所有的webserver日志，包括apache\nginx\tomcat\IIS等
● 扩展插件日志
● 这里指在AGENT发布时没有的功能，暂时用小程序或脚本应急产生的日志，可通过修改HIDS配置采集解析上报。另一种技巧就是可将临时小程序的日志输出到系统日志，Linux的syslog或Windows的application日志中。
（3）进程信息
相比前面几个，这是几乎所有HIDS都有的标配模块，进程信息数据在入侵检测方面贡献的价值更大。在Linux系统中，几乎所有的运维操作以及入侵行为都会体现到执行的命令中。所以进程命令信息无论是作为运维操作审计，还是入侵行为分析都有极大帮助。
进程信息获取技术方案选择如下：
周期性遍历/proc。这是风险最小的方案，部署适配性最强。但缺点明显，实时性无法得到保障，且性能差；
用户态Hook Libc函数。相比前面一种方案，风险相对高一点，特别在多线程进程中要注意安全性。但其部署适配性也特别高，同时性能也是各种方案最好的，建议作为首要选择。虽然libc hook方式可能有被绕过的风险，但如果对抗主要集中在Web入侵场景，基本是无需担心的。
利用LSM模块接口。如果对抗必须深入系统级攻防，那么通过内核态获取进程数据就非常必要了。但是为了安全性、适配性考虑，采用LSM（Linux securitymodule）开发接口就是较佳的选择。Fackbook安全团队开发的OSquery就是使用了LibAudit获取execve调用信息。
内核态syscall HOOK。安全类的开发最惯性的思维就是内核态HOOK，反倒不是什么新鲜的招式。但是这样的方案未必都适合大范围使用，作为一个可能要大量部署的安全系统来说，不是一个最佳选择。在Linux环境里各种发行版和内核版本差异很大，以至于需要维护多个兼容性版本，同时稳定性也难以保证。这类方案通常是开发一个LKM模块实现。
如果仅仅是记录进程派生事件，通常仅需要少数几个字段即可。但是建议在设计数据结构（字段）的时候，先将数据的使用场景想清楚，这样或许需要的字段信息将会更多，同时输出的字段既不浪费传输带宽和存储空间，还能最大化的服务于使用场景。表2是建议使用的字段。
表2 建议使用字段
数据使用中有几个技巧如下：
● mode字段，在规则检测（数据分析）过程，会发现一个无法解释的情况，某些root权限执行的进程的父进程是低权限，不符合系统进程派生原则。那么这里可能有几种情况：
a）有人利用系统漏洞提升了进程权限，可直接告警。
b）sudo执行，可通过父进程pcmdline\ppath辨别。
c）设置了S位的可执行文件，mode字段的意义就在于可将S位可执行文件运行事件与漏洞提权行为区别开。
● ENV字段，接上条“sudo提权行为可通过父进程为sudo来辨别”，可是在很多发行版里sudo运行可执行文件，在进程记录里父进程不是sudo，而是父进程的父进程，原因在于execve调用的进程派生方式，它是将子进程的ELF文件映像加载到内存里并执行，也就是sudo和被执行的进程‘共用一个进程空间’，但在我们记录的进程信息这个时间切片这里已经是新进程了。那么难道没有办法了吗？这里就用得到环境变量里的信息了，sudo执行的进程，进程的环境变量信息会新增3个环境变量信息SUDO_COMMAND\SUDO_USER\SUDO_UID，通过这三个变量就能判断当前进程是否是被sudo启动的。
（4）网络连接信息
网络连接信息分三类需求：连通性数据采集，用于分析违规ACL和可疑网络连接；用于恶意行为检测的数据需求，用于检测木马等场景；监控探测扫描行为。
获取网络连接信息，是一个较为消耗性能的工作，无漏是通过解析/proc中网络连接信息，还是内核消息。毕竟在一个业务繁忙的系统里，网络连接事件相对超出进程信息事件多个数量级，设计和使用时必须谨慎。一般通过周期性解析以下三个文件信息获取：
● /proc/net/raw——RAW套接字信息。
● /proc/net/tcp——TCP套接字信息。
● /proc/net/udp——UDP套接字信息。
如果仅为获取网络连接信息，那么五元组就能满足需求，但为了安全场景检测的数据分析需要可能还需关联进程信息，相当于一个定制版netstat。建议字段如表3所示。
表3 建议字段
关于字段的几个提示：
● ip字段，这里数据类型是Int，相比text来说int存储空间节省很多，且方便计算。
● 为减少“无意义数据”的产生，周期性的数据提取但仅上报增量数据。
● 很多业务繁忙的系统里，业务进程的网络连接请求非常多，所以监听端口的被动连接信息可考虑裁剪。
（5）webshell
在常规的互联网攻防里Web攻防基本是一个最常见的场景，而Web攻击的整个流程里最常见的是GET SHELL，也就是生成一个webshell。当然在入侵检测里webshell检测也成了一个很重要的环节。技术方案选择如下：
● inotify文件监控，Linux系统里的webshell检测，最重要也是几乎公认的技术就是inotify，在BSD和macOS里类似的是kqueue。从Linux内核从2.6.13开始引入inotify，inotify是一种文件变化通知机制，几乎所有Linux发行版都支持，可以通过以下命令看您的系统是否支持：
% grep INOTIFY_USER /boot/config-$(uname -r)
CONFIG_INOTIFY_USER=y
● 如果显示CONFIG_INOTIFY_USER=y则说明支持。
● 如果不支持inotify，那么很遗憾，不得不周期性遍历Web目录来做检测。
（6）DB审计
企业的核心资产通常是数据，用户数据、销售数据、产品数据、财务数据等等，那么DB的安全保护就成为了重中之重。安全厂商不乏大量的DB安全产品，根据产品的不同形态，DB安全（审计）产品可以是一个独立的系统，也可以作为HIDS的一个模块存在。
当作为HIDS的一个模块存在的时候，产品方案必定是部署于主机的，这样带来的好处是复用了HIDS系统的控制管理指令通道以及数据传输通道，同时更贴近DB服务端避免了攻击流旁路绕过的可能。但是缺点也较为明显，会消耗掉服务器自身部分系统资源。
3、数据传输
与传统HIDS以及PC版HIDS不同的是，企业版HIDS通常需要通过后端数据分析来实现安全能力，特别是互联网企业中，为了降低前端计算带来的系统资源消耗基本以后端数据分析为主。那么数据传输就是必要且重要的功能模块。同时在“大数据时代”，数据质量、数据运营可靠性成了支撑安全能力指标的关键性要素，必须认真对待。技术方案如下。
● syslog转发——当数据分析架构在初级阶段，借用Linux系统自带的syslog转发基本能满足数据传输统一管理的需求。只需修改syslog服务的配置文件即可实现转发，不需要额外开发数据接收Server。
● 此轻量解决方案易于实现，但缺点也很明显，syslog数据传输默认采用UDP 514端口，假如数据量较大或者数据量波动可能会丢数据。另外敏感数据也可能因明文传输而泄露。
● 数据直传——在数据量较少的阶段，譬如agent部署量在几千台服务器的阶段，前端agent采集的数据可以直接发送到HIDS后端Server，典型的如OSSEC。
● 数据接收Server——当HIDS系统部署运营到BAT这类公司的量级，数据通道的建设就必须更为谨慎。
在BAT这类公司，通常运营（包括安全）监控都有成熟的数据通道，那么在安全系统建设过程中，也可以复用它，既避免重复造轮子带来的开发资源浪费，也能快速的获得数据质量和可靠性的保障，从公司运营体系角度来看也是有益的。
那么如果没有合适的可用的现成系统的时候，新建这类数据通道需要注意什么呢？如下所示：
（1）避免数据传输波峰“雪崩效应”，例如当某个机房网络不通时，数据可能挤压在缓存里，在网络通畅之后集中传输占用网络通道以及对接受Server带来类似DDoS的效果。可对数据传输队列做随机性的主动延迟，避免拥塞；另外可使用Server端下发“数据上报”任务的方式来触发上传，而非agent主动无序上报。
（2）敏感数据脱敏及加密，很多数据中包含敏感信息，如http请求里的cookie、命令行里的密码。配合业务部门或数据安全部门制定数据采集规范，在agent端隐去敏感信息，传输环节做好加密，存储系统做好权限控制。
（3）做好每个数据传输环节的前后链对账，当出现安全事件漏报时能及时追查到可能导致数据丢失的环节，便于后续的优化与debug。
4、控制管理
企业级HIDS系统部署量非常大，且安全防守体系任何一点的故障都可能导致整体防守的失效。合理的管理手段，能让整套系统更为健壮，确保可用性。
● 健康度监控——与传统安全系统基于端的检测方式不同，新型的企业级HIDS系统往往采用后端数据分析的方式实现入侵场景检测，从行为数据采集到数据传输存储、分析，是一个较长链条的流程，必须逐一对每个环节做好数据对账、异常监控。常见的检测点如表4所示。
表4 常见的检测点
●“自杀”机制——互联网企业里，业务会极度榨取系统性能，那么安全系统的部署也同样会受到严格挑战。毕竟业务系统的稳定运行才是第一目标，安全在极端情况，以及出现故障的时候必须为业务稳定牺牲。在产品设计中会设定一些系统资源耗用指标，超出指标则暂停功能模块甚至会“自杀”。常见指标如下：
CPU占用<10%~20%
内存占用<100M
数据上传<200/s（根据环境可配）
● 部署与更新——日常运营中必然会碰到部署和更新的需求，在HIDS架构里必须有推送更新的功能。单从功能和技术角度来说“更新”功能与大多数软件系统一样没有什么特别需要讲的，在大型互联网企业中重点关注两个方面：
（1）海量环境影响
大型网络中，动辄上万甚至几十万的部署量，对于每次的更新必须谨慎。这里需要设定以下原则：
● 发布前必须通知业务方，必须有应急预案和回滚手段。
● 遵循灰度发布原则，未经一个可靠的时间周期（通常一个月）稳定运营验证，不得批量部署。不同业务环境分别灰度。
● 节假日前不部署。
● agent更新行为由Server端推送任务完成。
（2）安全性
曾经有人开玩笑说，部署的这么多Agent就相当于一个大型的分布式僵尸网络。确实，假设恶意攻击者能操纵任何的HIDS集群系统的控制指令和平台，那么真的是“一损俱损”。为确保管理控制系统的安全性，必须设定几个安全原则：
● 控制（更新）指令仅允许选择固化的指令，严禁在Agent端预留执行系统命令的接口；
● 更新包必须经过第三方安全工程师审核之后上传至更新Server保存，更新仅允许选择更新Server上已有的安装包；
● 控制指令下发时必须由第三方审核批准才可执行。
微信公众号：计算机与网络安全
ID：Computer-network