去年有个典型的复盘场景：一台跑着官网和几个内部系统的机器，运维某天偶然打开 /etc/sudoers，发现末尾多了一行不在变更记录里的授权。追查下去，最早的信号出现在两周前——/var/log/secure 里有一段来自陌生网段的失败登录，接着是一次成功登录，接着是几次 sudo 提权失败，再往后是一条奇怪的 cron 添加记录。日志一条不少地躺在那里，只是从来没人把它们串起来看。机器没蓝屏、业务没中断、监控图上 CPU 和内存都在正常区间，所以没人觉得有事。
这就是没有主机侧检测能力的典型状态：不是没有证据，是证据不会自己开口。本文聊的就是怎么让这些证据开口——以 OSSEC 为主线，顺带拿 Wazuh（OSSEC 的分支，后来独立发展）做横向参照，讲清楚日志关联、文件完整性监测、rootkit 检查这三类能力到底落地成什么样，以及为什么绝大多数团队装完之后的第一反应是「告警太多，先关掉一半」。
先把问题收窄。一台服务器被入侵（不管通过什么途径），在主机这一层几乎必然会留下痕迹，而这些痕迹只有四类载体：日志文件、文件内容与属性、进程与网络连接状态、账号与计划任务等持久化入口。任何一类主机入侵检测系统，本质上都是在对这四类载体做周期性或事件性的「取样—比对—判定」。
回到那个 sudoers 的例子。如果当时部署了 HIDS，理论上会出现这几条独立信号：第一条来自 SSH 认证的失败记录（authentication failure 或 Failed password），第二条是同来源 IP 在短时间内的成功登录，第三条是 sudo 会话开启或者提权失败，第四条是 /etc/sudoers 或 /etc/sudoers.d/ 下文件内容发生变化，第五条可能是 /var/spool/cron 下新增条目。这五条信号分属不同的检测模块，单独看每一条都平淡无奇——失败的 SSH 登录在任何一台公网机器上每天都有几十上百条，配置文件变更在发布窗口里也是家常便饭。
真正让事件浮出水面的，是把它们按时间窗和来源 IP 关联起来：同一源 IP 在 5 分钟内失败 10 次后紧跟一次成功登录。这一句话里包含了三个要素——重复次数、时间窗、顺序关系，缺一个都构不成「值得半夜爬起来看一眼」的信号。这也是本文最想讲清楚的心智模型：单条日志不值钱，日志之间的关系才值钱。
顺带说一句容易被忽略的事实：那台机器上的业务监控（CPU、内存、磁盘、HTTP 状态码）在这两周内一片绿色。挖矿类行为会让 CPU 曲线变化，但仅仅是留一个后门、加一行 sudo 授权、改一条 cron，资源消耗为零。指望资源监控发现入侵，本身就是错位的期待。
主机入侵检测（Host-based Intrusion Detection，HIDS）的取证范围被严格限制在「这一台机器内部」。它读本机的 /var/log，看本机的文件哈希，扫本机的进程表和隐藏模块，核对本机的账号清单和定时任务。它不抓包、不看流量、不关心交换机镜像口，也不知道隔壁机柜那台机器发生了什么。
这个边界必须讲清楚，因为它决定了能力的上限与下限。
网络侧检测（NIDS，典型如 Suricata、Zeek 这一类）站在流量视角，看的是数据包特征、协议异常、C2 通信模式、横向移动的扫描行为。它的优势是一次部署能覆盖一个网段，能发现主机还没被攻破之前的探测和尝试；劣势是对加密流量几乎无能为力，也看不到攻击者已经登录成功后在本机做了什么——比如那行 sudoers。反过来，HIDS 能看到「改了哪个文件」，但完全不知道攻击者的横向路径是从哪台机器跳过来的。
EDR（端点检测与响应）是另一个物种：它除了检测，还强调「响应」——隔离进程、阻断网络连接、回溯进程树、提供交互式调查。商业 EDR 通常带云端情报和托管分析能力，但代价是 agent 更重、需要内核模块或 eBPF 支持、按端点收费、而且数据往往要出网到厂商云端。OSSEC 这一类开源 HIDS 处在中间地带：比纯日志聚合强得多（有规则引擎和文件完整性），比商业 EDR 轻（用户态为主、可完全离线部署），但缺少自动响应能力和进程树级别的深度溯源。
所以「装了不等于安全」这句话不是套话，它有三层实际含义。第一层，HIDS 是检测手段不是防御手段，它不拦任何东西——OSSEC 的 active response 可以配置自动封禁，但那属于额外的动作组件，默认并不启用，而且误封的风险不小。第二层，检测依赖规则覆盖，规则库里没有的模式它一条都发现不了；一个从来没见过的手法，在特征库更新前就是隐形的。第三层，也是最现实的一层：告警产生后如果没人看、没人判、没人处置，那么这套系统的实际安全价值等于零，甚至因为「我们装了 HIDS」的心理安慰而变成负值。中小企业最该警惕的恰恰是第三层。
OSSEC 是典型的 C/S 架构，但对不同性质的被管机器提供了三种接入形态，选错了后期全是麻烦。
server 是唯一的分析中心。它保存所有 agent 的注册密钥、接收并解码日志、跑规则引擎、存文件完整性基线数据库、发告警。server 通常只有一台（规模大的可以分级），它需要稳定的磁盘和不错的单核性能——规则匹配是 CPU 密集型的串行工作，多核对它的帮助有限，这一点在规划配置时经常被误判。
agent 是装在受管机器上的小程序，用 C 写成，资源占用很低（常驻内存通常在几 MB 量级，具体随监控范围和日志量变化）。它负责采集本机日志、执行 syscheck 扫描、跑 rootcheck、把结果加密发回 server。绝大多数 Linux 和 Windows 服务器都应该装 agent——这是功能最完整的方式，文件完整性监测、rootkit 检查、主动执行命令（如定期取账号清单）都依赖它。
agentless 是给「装不了 agent」的设备准备的：交换机、路由器、防火墙、某些嵌入式设备或不允许安装第三方软件的受管机器。server 通过 SSH（网络设备场景）或 WMI（Windows 场景）定期登录过去，跑命令、取输出、把输出当日志来分析。代价很明显：它是轮询式的，有固定的间隔；它依赖凭据，凭据要存在 server 上；它做不了文件完整性监测（除非你自己写脚本对比哈希），也做不了 rootkit 检查。我的建议是——网络设备用 agentless 收 syslog 就够了，真正的服务器一律装 agent，不要因为「懒得一台台装」而用 agentless 糊弄过去，那样你买到的只是一个带规则引擎的日志收集器。
还有一种折中做法值得提：机器上不装 agent，而是让本机的 rsyslog/syslog-ng 把日志远程发到 server，server 用 syslog 接收。这对纯日志分析是有效的，但同样丢失了 FIM 和 rootcheck 能力，且 syslog 默认走 UDP 时可能丢日志。除非是严格禁止装 agent 的合规环境，否则不推荐作为主力方案。
agent 和 server 之间的通信是加密的（OSSEC 使用预共享密钥派生的会话密钥，基于 Blowfish 等对称加密；Wazuh 后续版本改为 AES 并改用 TCP 1515 做注册、1514 做数据传输，具体以对应版本官方文档为准）。加密本身不用操心，真正需要决策的是密钥怎么发到 agent 手上。
标准做法是三步：在 server 上用 manage_agents 为新 agent 添加条目、生成并导出密钥；把密钥通过带外方式（运维自己敲进去、配置管理工具下发、或手动复制）送到目标机器；在 agent 上导入密钥，重启 agent 完成注册。流程清晰但确实啰嗦，每加一台机器都要人工介入一次。
ossec-authd 就是来解决这个啰嗦的：server 上跑一个注册守护进程（默认监听 1515 端口），agent 启动时带着自己的 IP 和名字连过来，authd 自动分配密钥并完成注册。装一百台机器的工作量从一百次人工操作变成零。
但请注意它的安全取舍——这点是我在给客户做方案时一定会强调的：开放注册端口意味着任何能连到这个端口的人都可以注册成 agent。如果你的 1515 端口对公网开放且没有额外控制，攻击者可以注册一个恶意 agent 加入你的体系，往 server 灌伪造日志（干扰判断、淹没真实告警），或者从 server 侧拿到整个网络的 agent 清单与拓扑信息。这不是理论风险，是设计上就存在的。
怎么规避，有三条实用做法。其一，注册端口只对内网或运维管理网段开放，用防火墙或安全组严格限制来源，永远不要把它暴露在公网。其二，给 authd 加上密码或客户端证书校验（OSSEC 与 Wazuh 都提供了带密码/证书校验的注册模式，具体参数以官方文档为准），让「能连上」不等于「能注册」。其三，更彻底的方案是走配置管理：用 Ansible、SaltStack 之类工具在装机流程里自动完成密钥分发与导入，既自动化又不开放端口。规模化部署时我更推荐第三条，虽然前期要写点 playbook，但它同时解决了密钥分发和 agent 配置一致性两件事。
还有一个细节常被漏掉：agent 的 IP 在配置里可以是固定 IP，也可以设为 any。设为 any 时 agent 换 IP 不需要改配置，灵活但削弱了来源校验；设成固定 IP 时机器迁移网络就要改配置。公网机器上我倾向固定 IP 并配合严格的注册控制，内网弹性环境（比如 autoscaling 组）可以用 any。
这是评估 HIDS 可靠性时必须问的问题：agent 与 server 之间网络中断、server 重启、agent 所在机器负载飙高，这些情况下日志会不会丢？
OSSEC 的设计是本地队列 + 重发。agent 侧会把待发送的事件暂存在本地队列文件里（在 agent 安装目录下的 queue 相关路径），server 不可达时持续堆积，恢复后按顺序补发。这保证了短暂中断（几小时量级）不会丢数据。server 侧也有接收队列和归档机制，事件进来后先入队再由分析进程消费。
但队列不是无限的，它是磁盘上的文件，受两个约束：一是磁盘空间，二是队列长度上限（超过上限后最老的事件会被丢弃）。所以真正的风险场景是「长时间中断 + 高日志量」——比如一台日志量很大的机器断联三天，队列写满，最老的那部分事件就永久没了。规划时要想清楚：你的队列目录放在哪个分区、这个分区还剩多少空间、日志量最大的那台机器一天产生多少事件。这些数字不需要精确，但要有量级概念。
server 侧的磁盘规划更要提前算。三部分吃空间：原始日志归档（archives，通常按天切分目录）、告警日志（alerts，同样按天）、文件完整性基线数据库（syscheck 的哈希库，随监控文件数量线性增长）。一台监控 5000 个文件的机器，其 syscheck 数据库条目就是 5000 条量级，百台机器就是几十万条——这个量级本身不大，但加上每日告警日志和历史归档，一年下来是几十 GB 到几百 GB 的量级，取决于日志量和保留策略。建议的做法是：给 /var/ossec 单独挂一个分区，写清楚保留期（比如告警保留 12 个月、归档保留 3 个月），用 logrotate 或定时任务清理，并且务必监控分区使用率——磁盘写满会让整个 server 的分析停摆，这比丢几条日志严重得多。
顺带一个运维经验：agent 的存活状态本身应该被监控。OSSEC 有「agent 长时间无心跳」的告警规则，但前提是你要把它接到能触达人的通道上，而不是让它躺在 alerts.log 里。
这是全文最该讲清楚的一段，因为它决定了你能不能自己写规则、能不能判断某条告警为什么没触发。
OSSEC 的分析流水线是两段式：先 decode，后 match。解码器（decoder）负责把一行无结构的文本切成结构化的字段，规则（rule）负责在字段上做匹配并给出严重级别（level）。
以一条常见的 SSH 失败日志为例，原始文本大致是「Failed password for invalid user admin from 1.2.3.4 port 54321 ssh2」这一串。解码阶段发生的事：OSSEC 有一个预解码（predecoder）环节，先把 syslog 头部拆出来——主机名、程序名（sshd）、后面的消息体。然后进入 decoder 匹配，sshd 的解码器用正则从消息体里抽出 srcip（1.2.3.4）、srcport（54321）、user（admin）、以及动作类型（Failed password）。抽出来的字段会挂在这次事件的对象上，供后续所有规则使用。
规则匹配阶段：规则库里有一条针对 sshd 认证失败的规则（常见的规则 ID 在 5700 段附近，具体编号随版本和规则集版本变化，以你实际部署的规则文件为准），它的匹配条件是「解码器名等于 sshd 且 匹配 Failed password 这类模式」。命中后给出 level——SSH 认证失败一般是较低的 level（5 左右），并且会带上一个「攻击次数累积」的语义。
然后，这条 level 5 的事件会同时走两条路：一是按 level 阈值决定是否立即发到告警通道（OSSEC 默认对较高 level 的告警做实时通知，较低 level 的会进入后续的关联判断或者只写日志）；二是进入关联规则的统计池，等待被 frequency 类规则「捞」起来。
理解了这个流水线，几个长期困扰新手的问题就都通了：
为什么改了日志格式就检测不到了？因为解码器匹配不上，字段抽不出来，后面的规则自然全废。典型场景是应用自己打的日志格式变了、或者中间加了一层 rsyslog 模板改写导致头部结构变化。排查方法是用 ossec-logtest 这类工具把原始行喂进去，看它是否被正确解码、命中了哪条规则。
为什么加了自定义规则不生效？八成是规则里的解码器名（decoded_as）或字段名写错了，或者规则 ID 段被别的规则集占用。规则 ID 是有分段约定的（不同段留给不同用途，自定义规则通常用较大的 ID 段），乱写会和系统规则冲突。
level 到底意味着什么？OSSEC 的 level 是 0 到 15 的整数，大致语义是：0–3 几乎可以忽略（系统内部事件、成功登录这类），4–6 是低危但值得记录（认证失败、策略违规），7–9 是中危（多次失败、可疑命令、文件变更），10–12 是高危（明确的攻击特征、成功提权迹象），13–15 是极高危（多重关联命中、明确的入侵指标）。这个分级不是标准，只是 OSSEC 社区的约定，但它给了你一个统一的调参旋钮：把告警通道的阈值定在哪个 level，就决定了你每天收多少邮件。
现在讲关联。这是 OSSEC 最有价值、也最容易被低估的部分。
一条「failed password」是噪声，因为公网服务器上它每分钟都在发生——扫描器、撞库脚本、打错的同事，来源无穷无尽。真正有意义的是模式：同一源 IP、短时间、多次失败、然后一次成功。这个模式的价值在于，失败和成功之间建立了因果嫌疑——失败的积累不像是在猜密码，而像是猜对了。
OSSEC 用几条配置项表达这个逻辑，我按语义讲，不堆配置清单：
frequency 与 timeframe 是一对。timeframe 定义时间窗（单位秒），frequency 定义在这个窗内要累积多少次。比如「300 秒内出现 8 次」就是一个典型的暴力破解判定窗。这两个值怎么定，取决于你的真实流量——一台每天被扫几千次的公网跳板机，8 次/300 秒可能每小时响一次；一台只在内网开放的数据库服务器，2 次/300 秒就该响。没有通用值，必须看基线再调。
if_matched_sid 定义「累积什么」。它指的是：先命中某条规则（sid 指定其 ID）的事件，在窗内累积到 frequency 次后，我才触发。这就是两段式的精髓——被累积的是「已判定过的事件」而不是「原始日志行」，所以你可以在一条基础规则之上叠出多个不同阈值的关联规则，互不影响。比如对同一个 SSH 失败规则，你可以同时挂一条「5 次/60 秒报中危」和一条「50 次/3600 秒报高危」，分别对应暴力破解和慢速爆破两种节奏。
same_source_ip 定义「按什么维度累积」。不加这个选项时，统计是全仓的（所有来源加起来够 8 次就报），这在网络设备上偶尔有用，但在 SSH 场景下几乎没意义——几十个不同 IP 各试一次不构成事件。加了 same_source_ip 之后，统计按源 IP 分组，每组独立计数，这才是你要的语义。类似的还有 same_user、same_location、same_srcport、different_url 等选项，让你按用户、按来源地域、按不同 URL 等维度做分组统计。选对分组维度，是关联规则从「能响」到「响得准」的关键。
再往上一层是 if_sid / if_matched_sid 的串联：先失败 N 次，再成功一次。OSSEC 里可以用一条规则累积失败（if_matched_sid 指向失败规则），再用另一条规则表达「在刚才那个统计还存在的前提下，出现了 accepted password」——这就是复合事件规则（composite rule）。它表达的正是「先有因、后有果」的时序关系，是单条规则无论如何都表达不出来的。
Wazuh 在这块做了扩展，提供了更结构化的规则语法和更多的字段选项，也把规则集维护做得更频繁；但核心逻辑——时间窗、频次、分组维度、规则串联——是完全一致的。学会了 OSSEC 的关联心智模型，看 Wazuh 的规则文件不会有障碍。
最后一句实操建议：写关联规则前，先花一周只做统计不改阈值，把「我的机器上 SSH 失败的真实分布」摸出来。没有基线就拍脑袋定 frequency，结果只有两种——告警风暴，或者永远不响。
文件完整性监测（File Integrity Monitoring，OSSEC 里叫 syscheck）是主机侧最有说服力的一类证据：它不问日志有没有记，它直接看文件变没变。
该盯的目录，我一般分三档给客户建议：
第一档是必须盯的：/etc 下与权限、认证、服务启动相关的部分（passwd、shadow、sudoers 与 sudoers.d、ssh 配置、crontab 与 cron.d、systemd 的 unit 文件目录、pam.d）、/usr/bin 与 /usr/sbin 和 /bin、/sbin 这类可执行文件目录、以及动态链接器相关的配置（ld.so.preload 这种被篡改后能劫持进程的点）。这些目录的共同特征是：正常情况下变更极少，一旦变更几乎都值得问一句「谁改的、为什么」。
第二档是业务相关的：网页根目录、应用发布目录、脚本目录。这一档的意义在于发现「页面被挂马 / 被植入一句话 / 被替换下载链接」这类改动。难点是这些目录有正常的发布行为，所以必须和发布流程联动——否则每次上线都是一次告警风暴。可行的做法是把发布窗口设成 syscheck 的静默期，或者用配置管理工具在发布后自动更新基线。
第三档是选择性盯的：用户的家目录下的 shell 配置（.bashrc、.profile 被改是常见的持久化手法）、/root/.ssh/authorized_keys（这个我强烈建议单独盯，加一条未授权的 key 就等于留了后门）、以及应用配置目录。
必须放过的清单同样重要，而且更容易被忽略：
所有日志目录（/var/log 及其子目录）——日志每分每秒都在追加，监控它等于每秒产生告警，而且毫无价值。缓存与会话目录（各种 cache、session、tmp、/dev/shm）——内容频繁生灭。数据库数据文件（MySQL 的 ibdata、binlog，PostgreSQL 的 base 目录等）——这是最容易踩的坑，数据文件在正常服务期间被持续改写，把 /var/lib/mysql 加进 syscheck，你会收获一台永不停歇的告警机器。包管理器与系统临时目录（/var/cache、/var/tmp、/tmp）。proc、sys、dev 这类虚拟文件系统——它们本来就不是磁盘上的文件。还有邮箱与队列目录、容器运行时的数据目录（overlayfs 层变动极其频繁）。
为什么「全盘监控」必然崩？因为 syscheck 的成本是 O(文件数) 的：每轮扫描要遍历所有受监控文件、计算校验和、与基线比对。一个装了几百个包的 Linux 系统，文件数在十万量级，全盘扫一轮的 I/O 和 CPU 开销相当可观，而且其中 99% 的变更是日志、缓存、数据库这些无意义噪声。更糟的是，当告警量超过人的处理能力时，人们会开始忽略告警——这会连带让真正的告警也被忽略掉。宁可监控 2000 个高价值文件并保持每条都看，也不要监控 200000 个文件然后天天批量关闭告警。这是我在这个问题上最确定的一个结论。
syscheck 有两种工作模式，选择直接影响你「多久能知道文件被改了」。
定时轮询：按配置的间隔（OSSEC 默认是若干小时一次，可配置）把受监控目录扫一遍、算校验和、比对。优点是开销可控、对系统无侵入、跨平台一致（Windows 上也一样工作）。缺点是有时延——如果扫描间隔是 6 小时，那么最坏情况下你要 6 小时才知道文件变了。对多数场景这够用，但对 /etc/sudoers、authorized_keys 这类关键文件，6 小时足够攻击者做完所有事并清理痕迹。
实时监控：Linux 上基于 inotify 机制，内核在文件被修改时主动通知用户态程序，实现秒级感知。OSSEC 通过 realtime 配置项对指定目录启用，Wazuh 同样支持。开销比轮询低（不需要反复遍历），但有几个硬约束：inotify 的监控实例数和每个实例的 watch 数量受内核参数限制（fs.inotify.max_user_watches 等），监控文件数很大时需要调内核参数；inotify 不递归自动覆盖新建子目录（需要额外处理）；它告诉你「文件变了」，但不告诉你「谁改的」。
who-data 是补上「谁改的」这一环的机制，它依赖 Linux audit 子系统（auditd）：通过配置 audit 规则捕获对目标文件的写操作，并把 uid、进程名、父进程等信息一并带出来。价值非常大——告警里出现「文件 /etc/sudoers 被 uid=0 的进程 vi 修改」，和只出现「文件 /etc/sudoers 变更了」，是完全不同的可处置性。代价也不小：auditd 会产生海量事件（每个文件写操作一条），需要把 audit 的输出接进 HIDS 的分析链路；开启后对 I/O 有一定影响，在高写入负载的机器上需要实测；而且 audit 规则本身的配置与排错有门槛，规则写得不对会导致什么都没抓到或者抓到不该抓的。
我的取舍建议是分层：对少数十几个最关键的文件（认证、提权、启动项、SSH key）开 who-data 或至少开 realtime；对 /etc、/usr/bin 这类目录开定时轮询；对网页根目录按发布频率决定（发布频繁就用轮询配合发布窗口静默，发布很少就开实时）。这样既拿到了关键路径的秒级感知，又不会让 auditd 把机器拖垮。
还要提一句：syscheck 的校验和算法是可以配置的（MD5/SHA1/SHA256 等组合），更长的哈希安全性更好但计算更慢、数据库更大。对内部威胁模型而言 SHA1 级别通常够用，涉及合规要求时按合规要求选。另外，基线数据库本身要保护好——如果攻击者能改 syscheck 的基线库，那么 FIM 就形同虚设（这一点也是「主机被完全控制后检测结果不可信」这个根本局限的体现）。
rootkit 检测（OSSEC 的 rootcheck 模块，Wazuh 里对应位置有所调整，以各版本文档为准）做的事是：扫描已知 rootkit 的特征文件与默认路径、检查 /dev 下是否有异常条目、检查是否有隐藏端口和隐藏进程（通过对比不同接口拿到的结果来发现不一致）、检查是否有 promiscuous 模式的网卡（嗅探迹象）、以及检查一些已知后门程序的特征。
要说实话：这个模块的检测能力在整个体系里是最弱的一环。它的检测逻辑以特征为主，特征库更新并不频繁，面对一个稍微定制化的 rootkit 基本无能为力。它的真实价值在于「抓低级错误」——那些用了公开工具、没做免杀、留下默认路径和默认文件名的入侵。这类入侵在公网暴露的机器上并不少见（自动化脚本批量打上来的往往就是这类），所以它不是没用，只是要放对预期：rootcheck 报了，那基本有事；rootcheck 没报，什么都不能说明。
与它类似的还有 policy monitoring（策略监测）：它定期检查系统的一些安全相关状态——比如是否开启了一些不安全的配置、密码策略是否符合要求、是否存在空密码账号、sshd 配置里是否允许 root 直接登录等，把不符合项报出来。这块的规则多是基于 CIS 基准一类思路整理的，具体覆盖哪些检查项随版本变化。
另外一类值得了解的是 SCA（Security Configuration Assessment）/ cis-cat 这类基线扫描：思路是用一份结构化的基线清单（比如 CIS Benchmark）对机器做逐项核查，输出「哪些项通过、哪些项不通过、不通过的严重度」的评分式报告。它和 HIDS 的告警是两种东西——HIDS 是事件驱动的、告诉你「发生了什么」；基线扫描是状态驱动的、告诉你「配置偏离了标准多少」。两者互补：基线扫描发现「密码策略太松」，HIDS 发现「有人正在暴力猜密码」。需要提醒的是：不同版本、不同发行版对 SCA / cis-cat 类型的支持情况不一样，是否内置、支持哪些基线档位，请以你所用版本的官方文档为准，不要凭印象配置。
为什么这些结果必须人来读？因为它们天然高误报。rootcheck 对某些正常的容器运行时、特殊的网络配置会报可疑；策略检查对业务上有意为之的宽松配置会报违规；基线扫描不通过的项目里，往往有一批是业务上必须开的口子。这类东西如果直接接到告警通道并设成高优先级，几周之内所有人就会开始忽略它。合理的处理是：低频运行（比如每天或每周一次）、结果落到一个单独的视图或周报里、由人定期过一遍并决定哪些项纳入长期豁免。把它们当体检报告，不要当火警铃。
OSSEC 的告警输出有几种形态，实际部署时通常是组合使用。
第一种是本地文件：alerts.log（文本）和 alerts.json（结构化），这是所有告警的归处，也是后续被采集进日志系统的源头。无论用不用其他通道，这两个文件一定要保留并纳入备份/归档策略。
第二种是邮件：OSSEC 内置邮件通知，可以配置按 level 阈值发送、以及是否做聚合（把同一时间窗内的告警合并成一封）。我的经验是——务必开启聚合，否则一次批量扫描会产生几百封邮件，收件箱直接废掉。邮件通道适合中低危告警的「日报式」处理，不适合承载需要分钟级响应的告警。
第三种是即时通道：Slack、企业微信、钉钉、Telegram 之类，通常通过自定义脚本或 webhook 集成实现。做法一般是写一个脚本，读取 alerts.json 的新增行，按 level 过滤后推送到对应群或频道。这里的关键设计是分流：level 12 以上走「@值班人 + 手机推送」的高优通道，level 7–11 走工作群，level 7 以下只进日志不打扰人。分流的意义不在于减少告警总量，而在于保证「真正需要立刻看的」不会被淹没。
第四种是syslog 转发：把告警以 syslog 形式发到外部系统，便于统一采集。适合已经有集中日志平台的团队。
还有一类是 active response：告警触发后自动执行脚本（比如调 iptables 封禁来源 IP）。这个功能存在且可用，但我要给出一个偏保守的建议——中小团队慎开自动封禁。原因很实在：误封的代价可能比漏检更高（运维自己被锁在门外、业务方 IP 被误伤、NAT 出口下误封一大片用户），而且攻击者伪造源 IP 时，你的封禁动作可能被利用来制造拒绝服务。真要用，建议只针对极少数高置信度规则、设置较短的封禁时长、并且保留一键解封的能力。
降噪是 HIDS 落地过程中躲不开的一关，但降噪手法有对错之分。
相对正确的一类：按规则 ID 覆盖级别。OSSEC 支持在自定义规则里用 if_sid 引用已有规则并覆盖其 level（把它调低）或指定不发告警。这适合处理「某类事件在我的环境里确实没意义」的场景，比如某条针对特定软件的规则，而你根本没装那个软件。好处是粒度细、可追溯、可回滚——你改的是某一条规则，而不是一片。
需要谨慎的一类：ignore 与黑名单配置。可以配置忽略某些来源 IP、某些用户、某些文件/目录（syscheck 的 ignore 项）。这类配置的问题是它会形成「暗区」：被忽略的来源 IP 如果正是攻击者的，你什么都看不到。所以我的规矩是：忽略项必须写在配置里、必须带注释说明是谁在什么时间因为什么加的、必须定期（比如每季度）复审一次。放在配置文件里意味着它进版本管理、可被审计；随手在命令行改则迟早出事。
明确错误的一类：把所有高频低危规则全关掉。这是新手最常走的路——装上之后一天三千条告警，忍无可忍，把 level 7 以下的规则批量禁用，世界清静了。问题在于，很多高价值信号恰恰是从低危规则的累积里长出来的。前面讲过，关联规则是「if_matched_sid 指向某条基础规则」——你把基础规则关了，所有基于它统计的暴力破解、慢速爆破、横向尝试规则全部一起失效。你以为只是关掉了噪声，实际上拆掉了整条检测链的地基。
正确的降噪顺序应该是：第一步，确认噪声来源是不是配置问题（监控了不该监控的目录、日志源接错了、时间窗设得太宽）；第二步，针对具体的高频规则调阈值而不是关规则；第三步，对确实无意义的规则做 level 覆盖；第四步，才考虑 ignore。走完这四步再看告警量，绝大多数环境都能压到人能处理的规模。
把三类能力放在一张表里对照，方便按自己的环境决定投入重心。表格里的「资源开销」「及时性」给的是相对量级与机制差异，不是可引用的吞吐数字——具体数值取决于你的文件数、日志量和机器配置，必须自己实测。
| 能力 | 能发现什么类型的问题 | 典型误报来源 | 资源开销与及时性 | 维护成本 |
|---|---|---|---|---|
| 日志规则告警（含关联规则） | 认证失败与成功、暴力破解节奏、异常时间登录、sudo 提权、服务启停、计划任务变更、可疑命令执行。覆盖面最广，是唯一能表达「多次失败后成功」这类时序关系的模块 | 公网扫描器持续尝试、应用自身刷日志、时间窗阈值与环境不匹配、日志格式变更导致解码错乱后串到错误规则 | 开销集中在 server 侧规则匹配（CPU 串行），agent 侧很低；实时性最好，日志产生后秒级到分钟级可见 | 中等偏高。接新日志源要写解码器，环境变化要调阈值，需要持续投入；规则写对之后边际成本下降 |
| 文件完整性监测（syscheck） | 配置文件被改、二进制被替换、网页目录被植入或篡改、SSH authorized_keys 被追加、启动项与定时任务文件变化。证据最硬，不依赖对方有没有留下日志 | 包管理器批量更新、应用发布、证书自动续期改写文件、日志与缓存目录被误纳入监控、数据库文件被持续改写 | 开销与受监控文件数正相关。轮询模式有固定时延；实时（inotify）秒级但受内核 watch 限制；who-data（auditd）能给出操作者但事件量显著增大 | 前期高（要精确挑选目录、定忽略清单、联动发布流程），稳定后较低，但每次业务上线流程变更都要重新对齐 |
| rootkit 检查与策略/基线检查 | 已知 rootkit 特征文件与默认路径、隐藏端口与隐藏进程、网卡混杂模式、系统安全配置偏离（空密码账号、root 直登、密码策略过松等） | 容器运行时与虚拟化环境被误判、业务上有意为之的宽松配置、基线项与发行版或用途不匹配、特征库陈旧导致漏报（反向问题） | 定期扫描模式，实时性最弱（按小时或按天）；单次扫描开销较高但频率低，整体可控；who-data/audit 开启后另计 | 低到中。配置一次后基本不动，但结果需要人工定期判读，且要维护豁免项清单，否则逐渐变成无人看的死报告 |
| 主动执行类检查（命令输出采集） | 定期取账号清单、监听端口、已安装软件包、进程列表等快照，用于发现「不在预期内的新增账号/端口/软件」 | 应用动态创建账号、容器网络导致端口列表频繁变化、自动更新改变软件包清单 | 按配置周期执行，及时性取决于周期（通常分钟到小时级）；命令本身开销小 | 中等。需要维护预期基线（哪些账号/端口是正常的），业务变更时要同步更新，否则告警无意义 |
表格怎么读：如果你的机器全部暴露在公网、SSH 开着密码登录，那么日志关联规则是第一优先级，它挡住的是最大概率的入侵路径。如果你的机器是内网业务机、登录入口收敛得不错，那么 FIM 的性价比更高——因为这类机器上真正的高风险事件是「有人悄悄改了配置和程序」。rootkit 检查属于兜底，值得开但不值得为它单独投入人力。
容器化环境是 HIDS 最容易踩空的地方，原因不是工具不行，是观察对象变了。
第一个盲区是进程短命。容器里的进程生命周期以秒甚至更短计，一批 Pod 调度上来又销毁。主机侧 HIDS 即使扫到了进程，那个进程可能已经不存在了；以 PID 为线索的溯源在容器环境里几乎没有意义（PID 命名空间隔离，容器内的 PID 1 在宿主机上是另一个 PID）。
第二个盲区是日志走 stdout。容器化的最佳实践是应用把日志打到标准输出，由运行时收集到节点日志或集中日志系统。这意味着「本机 /var/log 下没有这个应用的日志」——主机侧 agent 按常规路径去读，什么都读不到。可行的补法是让 agent 也去读容器运行时的日志落盘路径（比如节点上由运行时汇总的日志文件），或者干脆在日志已进入的集中侧（ELK/OpenSearch）做规则分析，而不是指望主机侧。两种做法各有代价，前者对运行时版本有依赖，后者脱离了主机上下文。
第三个盲区是分层文件系统。容器镜像是只读层叠加可写层，进程写入的文件在可写层，容器销毁就没了。对宿主机上的 agent 来说，overlayfs 下的路径变动极其频繁且无意义，把容器数据目录纳入 FIM 只会得到噪声。
第四个是视角问题：agent 装在宿主机上，它看到的是宿主机的日志、宿主机的文件、宿主机的进程。容器内部发生了什么，它只能看到侧面投影。要在容器内做检测，就得把 agent 打进镜像或者以 sidecar 形式部署——但这又引入镜像体积、启动开销、每个容器一份常驻内存的问题，在容器数量大时代价不小。
云主机（虚拟机形态）本身没有这些麻烦，它就是一台普通 Linux，agent 照装。要注意的是另外两点：一是镜像模板化——如果你的云主机是用镜像批量开出来的，务必确保镜像里的 agent 配置里不含已固化的密钥和已固定的主机名，否则开出来的机器会带着相同身份去注册，互相顶掉。正确做法是在开机初始化脚本（cloud-init 之类）里完成密钥导入和主机名设置。二是弹性伸缩——autoscaling 组里机器随时生灭，agent 注册要用自动化流程（前面提到的 authd 加访问控制，或者配置管理下发），并且 server 侧要能自动清理已经销毁的 agent 条目，否则列表里会堆满僵尸条目。
OSSEC server 自己能存能查，但它的检索体验很原始（文本文件加命令行工具），规模一大就没法用。所以成熟的部署几乎都会把告警往专门的日志平台送。
常见链路是这样的：本机 agent 采集 → 加密送到 server → server 跑规则引擎产生告警 → 告警写入 alerts.json → 由 Filebeat / Logstash 之类采集器读取 → 送入 Elasticsearch 或 OpenSearch → 用 Kibana / OpenSearch Dashboards 或 Wazuh 自带的界面做检索、可视化和看板。
这条链路有几个设计点值得想清楚。其一，先分析后集中：在 server 侧完成规则匹配再送出去，送的是「已经判定过的告警」而不是原始日志，数据量大幅下降，而且带上了 level、rule id、来源等结构化字段，检索价值高得多。反过来，如果把全部原始日志都灌进 ELK 再在那里做规则，存储和计算成本都会上一个台阶。其二，原始日志要不要留：建议留，但要分层——高价值日志（认证、sudo、cron）长保留，低价值日志短保留。事后溯源时，告警只告诉你「发生了什么」，原始日志才能告诉你「完整的上下文」。其三，server 与集中平台之间要有缓冲：日志平台挂掉或做版本升级时，采集器要有本地队列，否则这段时间的历史就断档了。
还有一点容易被忽略：告警进入集中平台之后，仍然需要一个「谁来负责看」的机制。建一个每日告警摘要看板、定一个值班人每天花十分钟过一遍 level 阈值以上的条目、对反复出现的告警做归因并调规则或加白名单——这三件事比平台本身重要得多。我见过太多团队搭了漂亮的看板，然后三个月没人打开过。
把这几类单独拎出来，是因为它们几乎在所有环境里都会出现，而且有明确的处置思路。
cron 与计划任务执行。定时任务触发时会产生一批日志、可能读写一批文件，规则引擎会看到「计划任务变更」「异常命令」之类的告警。判断方法：看告警时间是否严格对应 crontab 里已知的周期（比如每天凌晨两点整），以及触发进程是否是已知的运维脚本。处置：把计划任务的执行窗口和用户加入白名单，或者调高相关规则的阈值。
包管理器批量更新。一次 yum/apt 批量升级会改写 /usr/bin 下大量文件、更新 /etc 下若干配置、产生大量 rpm/dpkg 日志。FIM 会在几分钟内报出几十上百个文件变更。判断方法：变更是否集中在 /usr/bin、/usr/lib、/etc 下的软件相关路径，时间是否与补丁窗口吻合。处置：把补丁窗口设为 syscheck 静默期，或者在打完补丁后主动重建基线（这一步必须做，否则基线长期与真实状态不一致，之后真正的篡改反而被当成正常）。这个「更新后必须重建基线」的动作，是很多团队漏掉的关键运维步骤。
证书自动续期。acme.sh、certbot 这类工具定期续期证书，会改写证书文件与私钥，通常落在 /etc/letsencrypt 或类似路径，并且 reload 服务。判断方法与上面类似。处置：把证书目录排除出 FIM（证书内容变化本身不是安全事件），或者放到单独的低优先级告警组里。注意：如果证书目录完全不监控，那么「证书被替换成攻击者签发的」这种事也发现不了——所以更稳妥的做法是监控证书文件的属性与权限变化，而不监控内容哈希。
运维自己改配置。这是最难处理的一类，因为它和真实入侵在信号层面完全一致——都是 /etc 下文件被改。区分的依据只能来自外部：变更是否对应工单、是否来自跳板机的已知会话、是否是配置管理工具推送的。处置思路是流程化：所有配置变更走配置管理或至少走变更记录，然后把「变更窗口」与告警做时间对齐。如果你们的配置变更完全没有记录，那么 FIM 告警的可判读性会大打折扣——这是一个组织问题，不是工具问题。
时钟漂移。这条最隐蔽。关联规则依赖时间窗，而时间窗依赖时间戳一致。如果 agent 所在机器的时钟与 server 相差较多，那么「5 分钟内 10 次失败」这个判断就会失真——事件到达 server 时的时间分布被打散或挤压，关联规则可能永远达不到 frequency。更麻烦的是多台机器之间时钟不一致时，跨机器关联基本失效。判断方法：定期检查各机器的 NTP 同步状态与时差。处置：所有受管机器强制 NTP 同步，把 NTP 服务状态纳入监控，并且在 HIDS 部署前先把全网的时钟对齐做完。这件事成本极低，收益极高，但经常被排到最后。
这一段只讲检测与处置原则，不涉及任何攻击手法。
告警出来之后，第一优先级不是「马上查攻击怎么进来的」，而是别把现场毁掉。具体包括：不要急着重启机器（内存里的进程、网络连接、未落盘的痕迹会全部消失）；不要急着删除可疑文件（文件本身是证据，删除后无法还原哈希与时间戳）；不要急着改密码或踢掉会话而不做记录（当前登录会话是重要线索，但也要评估继续在线的风险，两者需要权衡）。
第二步是固定证据：把相关日志段完整复制出来（认证日志、命令历史、sudo 日志、cron 变更、网络连接快照），记录关键文件的当前哈希与时间戳与权限，导出进程列表与监听端口。做这些动作时注意留存操作记录——你自己的排查动作也应该有痕迹，否则事后无法区分哪些变化是攻击者造成的、哪些是你造成的。
第三步是判断隔离的必要性。这不是一个纯技术问题，要在「继续被控制的损失」与「中断业务的损失」之间权衡。需要考虑的因素：这台机器承载的业务重要性、是否有可用的备用节点、数据是否还在被读取或外传、是否涉及其他机器的横向风险。如果判断需要隔离，优先选择网络层隔离（调整安全组/防火墙规则，切断除管理通道外的访问）而不是直接关机，这样保留了内存状态供后续取证。
第四步才是归因与恢复：在证据基础上重建时间线，确认受影响范围（哪些文件、哪些账号、哪些数据、是否涉及其他机器），然后按预案恢复——恢复应该是从可信的备份重建并修补入口，而不是在原机上「把那行删掉就算了」。原机上的任何残留都可能成为二次入口。
最后一句重要的原则：主机被完全控制之后，这台机器上产生的任何检测结果都不可信。攻击者可以改日志、改基线库、停 agent、伪造进程列表。所以高价值环境的做法是「带外记录」——日志实时外送到独立的、主机侧无法篡改的集中平台，这一条比任何本地加固都重要。
从合规角度看，等级保护相关标准对主机安全的要求大致集中在几个方向：身份鉴别（账号管理与口令策略）、访问控制（权限分配与最小权限）、安全审计（对重要用户行为和重要安全事件进行审计、审计记录的保护与留存）、入侵防范（对入侵行为进行检测与报警）、恶意代码防范、以及资源与剩余信息保护。这些是公开标准里的通用要求方向，具体条款、测评指标与判定细则以现行有效的标准和测评机构解释为准。
HIDS 能直接对应的是「安全审计」和「入侵防范」两块——日志集中留存与防篡改、入侵行为的检测与报警，正是 OSSEC/Wazuh 这类工具的主场。「恶意代码防范」通常还需要主机防病毒类能力配合，HIDS 的 rootkit 检查只能算部分覆盖。「身份鉴别」和「访问控制」则主要是配置层面的事，HIDS 的策略检查能起到核查作用但不能替代配置本身。
必须说清楚的是：装一套 HIDS 不等于满足任何级别的合规要求，也不等于能通过测评。合规是体系性工作，涉及制度、人员、流程、技术措施的完整闭环，工具只是其中一个环节。而且不同等级、不同系统类型的要求差异很大，不存在「装了 X 就过等保 X 级」这种对应关系。对于有合规需求的客户，我们这类服务商能做的是提供合规架构建议、协助对接有资质的测评与咨询服务，以及在基础设施层面提供便于合规落地的技术条件（比如日志集中存储、网络隔离能力、镜像与快照能力），而不承诺具体等级与结果。
坑一：监控范围一上来就设成全盘，然后告警风暴导致整套系统被弃用。为什么：文件变更告警量与文件数量和变更频率成正比，日志、缓存、数据库目录会把告警量推到人无法处理的量级。怎么判断：装好之后先看一天，如果 FIM 告警中有大量来自 /var/log、/tmp、数据库目录、容器数据目录的条目，就是配置错了。怎么避：从白名单目录开始——只放 /etc 关键项、/usr/bin、网页根目录，跑一周确认噪声可控，再逐步扩大；同时明确写出忽略清单并纳入版本管理。
坑二：把高频低危规则批量关掉，导致关联规则整链失效。为什么：关联规则依赖基础规则做累积统计，基础规则被禁用后上层规则永远触发不了。怎么判断：配置完降噪后，用已知的输入（比如自己连续输错几次密码）验证暴力破解类规则是否还会触发；不会触发就说明链条断了。怎么避：降噪只调阈值、只覆盖 level、只针对具体 rule id 做处理，禁用规则前先查有没有其他规则的 if_matched_sid 指向它。
坑三：打完系统补丁或做完应用发布后不更新 FIM 基线。为什么：基线停留在旧版本，后续所有比对都在和错误的参照物比，真正的篡改混在一堆「预期内变化」里。怎么判断：检查 syscheck 数据库的更新时间，如果远晚于最近一次补丁/发布时间，就是没做。怎么避：把「更新基线」固化进发布与补丁流程（配置管理工具里加一步），并定期核对基线时间与变更记录是否对齐。
坑四：agent 与 server 时间不同步，关联规则静默失效。为什么：frequency 与 timeframe 依赖时间戳分布，时钟偏移会让事件分布被打散，统计永远达不到阈值，而且这种失效是静默的——没有任何报错。怎么判断：定期比对各 agent 与 server 的时差；也可以观察同一来源的失败登录是否被正确聚合。怎么避：全网强制 NTP 同步并监控 NTP 状态，把时钟校验做成部署前的检查项之一。
坑五：告警只落在 server 本地，没有任何人负责看。为什么：HIDS 的价值闭环在人的判读上，告警无人处理等于零，还会制造虚假安全感。怎么判断：看告警通道（邮件/群）最近一次被打开、被回复是什么时候；如果答案是「没人记得」，那就是失效状态。怎么避：至少做两件事——把 level 阈值以上的告警推到有人值守的通道、定一个每天固定时间过一遍告警的轻量流程。不需要专职 SOC，一个人十分钟也够了，关键是持续。
OSSEC 和 Wazuh 应该选哪个？
Wazuh 是 OSSEC 的分支，核心的分析逻辑（解码器、规则、关联、level）一脉相承，学会了 OSSEC 看 Wazuh 规则没有障碍。差别在生态：Wazuh 有官方维护的 Web 界面、更活跃的规则更新、与 Elasticsearch 的现成集成、以及更结构化的配置方式；OSSEC 更轻、更贴近原始设计。如果你有精力自己搭看板和集成、追求最小依赖，OSSEC 够用；如果你希望开箱就有界面和持续的规则更新、团队人力有限，Wazuh 的落地成本更低。两者都能完全离线部署，数据不用出网。
装了 HIDS 之后，是不是就不需要防火墙和 Web 应用防护了？
完全不是一回事，两者处在防御链条的不同位置。防火墙和 WAF 是前置的访问控制与过滤，作用是减少暴露面、拦掉一部分已知攻击；HIDS 是后置的检测，假设前面的措施可能被绕过，负责在主机上发现异常。HIDS 不阻断任何东西——它发现问题时，事情已经发生了。反过来，只有前置防护没有 HIDS，那么一旦被绕过就完全失明。正确预期是分层：收敛暴露面在先，检测能力在后，两者不可互相替代。
一台 server 能带多少个 agent？
没有固定的数字，它取决于几个变量：总事件速率（每秒多少条日志进规则引擎）、告警产出量、syscheck 数据库大小、以及是否开启实时/who-data。经验上的规划方式是先估算总日志速率，再看 server 的单核 CPU 是否还有余量（规则匹配是串行为主），以及磁盘能否装下归档与告警。我的建议是先按几十台规模部署并观察 server 的资源曲线，再按实际增速推算扩容点；规模再大就考虑分级部署（多个 server 汇总到上层）或把分析负载转移到集中日志平台。不要按某个网传数字直接规划。
文件完整性监测会拖慢业务吗？
取决于监控范围和模式。定时轮询会在扫描时产生集中的 I/O 和 CPU 消耗，监控文件数越多、扫描越频繁，开销越大；实时模式（inotify）常态开销低，但需要内核 watch 配额，且高频写入目录会持续产生事件；who-data 依赖 auditd，事件量最大，在高 I/O 机器上需要实测。可控的做法是分层：关键文件实时、普通目录轮询并避开业务高峰、高频写入目录不纳入监控。绝大多数业务机器在合理配置下感知不到明显影响，但「不合理的配置」确实能把机器拖慢，所以上线前务必在业务低峰期先试跑一轮观察。
告警太多看不过来，第一刀应该砍在哪？
先别砍规则，先改配置。绝大多数告警风暴的根源是监控范围错了——把日志目录、缓存目录、数据库文件、容器数据目录纳入了 FIM，或者把日志源接错了导致同一条日志被多重计数。把这些排除掉，告警量通常会下降一个数量级。剩下的部分再按优先级处理：调高关联规则的 frequency、缩短 timeframe、对确实无意义的规则做 level 覆盖。直接禁用规则是最后手段，且操作前一定要确认没有其他关联规则依赖它。
容器环境还要不要装主机侧 HIDS？
要，但要清楚它的边界。宿主机上的 agent 能看到宿主机的日志、文件、账号、定时任务——这些恰恰是容器逃逸与宿主机被控场景下最关键的证据；而容器内部的短命进程、stdout 日志、分层文件系统，主机侧看不到或看到了也没意义。所以合理的分工是：宿主机装 agent 做主机层检测，容器内的应用日志走集中日志平台做规则分析，镜像层面做构建期扫描。指望一个主机侧 agent 解决容器内的可见性问题，是错位的期待。
机器被完全控制之后，HIDS 还有效吗？
这是 HIDS 的根本局限，必须诚实面对：拿到 root 权限的攻击者可以停掉 agent、修改或删除日志、篡改 syscheck 基线数据库、伪造进程列表，让主机侧的所有检测结果失去可信度。缓解办法不在本机，在带外——把日志与告警实时外送到主机无法访问的集中平台（独立网络路径、只追加的存储、独立的权限体系），这样即使单机失守，时间线依然保留在别处。这条原则对任何主机侧检测工具都成立，不是 OSSEC 独有的问题。
没有专职安全团队的小公司，这套东西值得做吗？
值得，但要控制投入。先把最有价值的部分做起来：SSH 认证相关的关联规则（挡住最大概率的入侵路径）、/etc 与网页根目录的文件完整性监测、告警推到一个有人看的群或邮箱、每天固定十分钟过一遍。这三件事加起来工作量不大，收益却覆盖了大部分常见场景。不要一开始就追求完整的规则集、漂亮的看板、全面的基线扫描——那些在没有人持续运营的情况下都会变成摆设。把闭环跑通比把功能铺全重要得多。
在一万网络的机器上铺 HIDS，流程上和其他 IDC 没有本质区别，但有几点结合交付环节说清楚会省很多事。
第一，把 HIDS 装进交付流程而不是事后补。机器交付时通常会有初始化环节（系统安装、基础安全加固、网络配置），把 agent 安装、密钥导入、NTP 配置、监控目录设定这几项写进初始化清单里，机器上线即具备基础检测能力。事后一台台补装，漏装率会很高——而且漏的往往是最容易被攻破的边缘机器。
第二，server 的位置要想清楚。它应该放在一个相对独立、只有运维能访问的位置，并且与受管机器之间的通信路径要稳定。如果机器分布在多个地区节点，server 的选址要考虑跨节点链路的稳定性——链路抖动会直接影响日志的实时性和队列堆积。同时，前面提到的注册端口（1515 一类）绝对不能对公网开放，用安全组或防火墙严格限制来源。
第三，规划好 server 的存储。日志归档、告警、syscheck 数据库三块要放在有冗余的分区上，并明确保留期与清理策略。磁盘写满会让分析停摆，这种故障往往在需要查日志的时候才被发现，代价很高。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。这类主机安全能力的搭建属于用户侧的软件与运维范畴，需要我们配合的主要是网络侧的条件——安全组规则、内网互通、独立管理网段、以及跨节点链路的稳定性。涉及合规场景，我们可以提供合规架构建议并协助对接有资质的测评与咨询服务，但不承诺具体等级与结果。
最后给一个落地顺序建议，按这个走不容易翻车：先做全网时钟对齐，再部署 server 与少量试点 agent，用一周摸基线（日志量、告警类型、误报来源），然后调规则阈值与监控范围，确认噪声可控后再批量铺开，最后接告警通道并定下每天过一遍的流程。跳过「摸基线」这一步直接铺全量，是绝大多数翻车案例的共同点。
OSSEC 官方文档（OSSEC Documentation，ossec.github.io）：架构说明（server / agent / agentless 三种接入方式）、解码器与规则语法、syscheck 文件完整性监测配置项、rootcheck 模块说明、agent 密钥管理与 ossec-authd 注册流程。
OSSEC 规则与解码器参考文档（ossec-rules / decoder reference）：sshd 相关解码器与认证失败规则的分段约定、level 级别的语义划分、关联规则配置项（frequency、timeframe、if_matched_sid、same_source_ip 等）的含义说明。
Wazuh 官方文档（documentation.wazuh.com）：Wazuh 与 OSSEC 的渊源说明、注册服务（authd）与端口使用（注册端口与数据传输端口）、FIM 的 realtime 与 who-data 模式、SCA 安全配置评估说明、与 Elasticsearch/OpenSearch 的集成方式。
Linux audit 官方文档与 man page：audit 子系统架构、auditctl 规则语法、who-data 依赖 audit 获取操作者信息的机制说明。
inotify 手册页（man 7 inotify）：inotify 机制说明、监控实例与 watch 数量的内核限制参数（fs.inotify.max_user_watches、max_user_instances 等）。
OpenSSH 官方文档与 sshd 日志行为说明：认证失败与成功登录在日志中的记录形式、登录事件与认证日志的字段构成。
CIS Benchmarks 公开资料：安全配置基线的基本思路与检查项组织方式；具体基线档位与工具支持情况以官方发布为准。
等级保护相关公开标准文件：主机安全要求中关于身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范的一般性要求方向；具体条款与判定以现行有效标准文本及测评机构解释为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
