核心要点（TL;DR）
- Osquery适合做资产与基线查询，不擅长实时告警，需自行搭建采集与告警链路。
- Wazuh是开箱即用的HIDS组合，规则丰富但资源占用与调优成本偏高。
- 小规模主机优先选轻量Agent型HIDS，中大型集群用Wazuh集中管理更省人力。
- 选型核心看三点：实时性要求、主机数量、团队是否有专职安全人力。
为什么你装了安全工具，还是被挖矿了
很多运维同学的现状是：主机上装了监控、开了防火墙，但真正的入侵信号——异常登录、计划任务被改写、Web 目录多出 webshell——全靠事后翻日志。开源主机安全工具能补上这块，但 Osquery、Wazuh 和各类 Agent 型 HIDS 定位完全不同，选错了要么白占资源，要么关键时刻没有告警。本文按实战视角做一次横评，给出可复制的命令和选型清单。
三类工具到底在解决什么问题
Osquery 把操作系统抽象成 SQL 表，用查询语言读取进程、端口、用户、计划任务等状态。它是采集与取证利器，但本身不产生告警。Wazuh 是完整的 HIDS 平台：Agent 采集 + 管理端规则引擎 + 告警与可视化，内置文件完整性监控（FIM）、日志分析、漏洞检测。Agent 型 HIDS 通常指一体化交付的轻量主机agent，强调开箱即用的入侵规则与低资源占用。
| 维度 | Osquery | Wazuh | 轻量Agent型HIDS |
|---|---|---|---|
| 实时告警 | 无，需自建 | 有，规则可调 | 有，默认规则偏实战 |
| 资源占用 | 低 | 中高（管理端） | 低 |
| 自定义能力 | 强（SQL） | 强（规则/解码器） | 弱到中 |
| 运维成本 | 高（要搭链路） | 中 | 低 |
动手：Osquery 快速做资产与基线核查
安装后先用交互模式验证数据源是否正常：
osqueryi
SELECT pid, name, path FROM processes WHERE on_disk = 0;
SELECT * FROM listening_ports WHERE address NOT IN ('127.0.0.1','::1');
SELECT username, shell FROM users WHERE uid >= 1000;把关键查询写成定时任务做基线比对，例如每天导出监听端口与计划任务快照，与前一天 diff：
osqueryi --json "SELECT * FROM crontab;" > /var/log/hids/cron_$(date +%F).json
diff <(jq -S . /var/log/hids/cron_$(date -d yesterday +%F).json) <(jq -S . /var/log/hids/cron_$(date +%F).json)注意：Osquery 默认不告警，必须自己把 diff 结果接入告警通道，否则只是「有数据」。
动手：Wazuh 最小可用部署与规则验证
用官方 compose 起管理端，再在业务机装 Agent：
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh && bash wazuh-install.sh -a
# 业务机
curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.7.0-1_amd64.deb
dpkg -i wazuh-agent_4.7.0-1_amd64.deb
sed -i 's/MANAGER_IP/10.0.0.10/' /var/ossec/etc/ossec.conf
systemctl enable --now wazuh-agent重点配置 FIM 监控 Web 目录与计划任务，并做一次规则有效性验证：
# 在 /var/www/html 写入测试文件
touch /var/www/html/.hids_test
# 观察管理端 alerts 是否出现 syscheck 事件
tail -f /var/ossec/logs/alerts/alerts.json | grep hids_test若没有告警，先查 Agent 连通性与 syscheck 配置是否包含该目录，再查规则是否被覆盖。
排查清单：主机是否已被入侵
- 登录审计：
last -a | head -20、grep 'Accepted' /var/log/auth.log，关注异常 IP 与非常用时段。 - 持久化：
crontab -l、ls -l /etc/cron.*、systemctl list-unit-files --state=enabled，找可疑新增项。 - 进程与外联：
ps aux --sort=-%cpu | head、ss -antp | grep ESTAB，看高占用与陌生外联。 - 文件变更：
find /var/www -mtime -1 -type f，重点看 webshell 常见后缀。
把以上检查项固化成脚本，交由 HIDS 定时执行并只推送差异，能大幅降低误报噪音。
怎么选：按场景给结论
主机少于 10 台、无专职安全人力，优先轻量 Agent 型 HIDS，半小时内能拿到可用告警；需要资产盘点、合规核查与应急取证，叠加 Osquery 做 SQL 查询；主机规模在 50 台以上、团队愿意投入调优，选 Wazuh 集中管理，规则与可视化收益最高。防护建议上，可在 Wazuh 规则之外补充主机层基线加固与异常行为拦截能力，例如 AegisX 提供的基线核查与入侵检测联动，减少自建规则链路的维护成本。
行动建议
本周先做三件事：一是在一台测试机跑通 Osquery 的端口与计划任务快照；二是用 Wazuh 单机版接入两台业务机并验证 FIM 告警；三是把上面的排查清单写成脚本纳入月度巡检。工具只是起点，规则验证和告警闭环才是主机安全真正生效的地方。
常见问题（FAQ）
Osquery能直接当HIDS用吗？
不能直接替代。Osquery本质是把操作系统状态暴露成SQL表的采集器，本身不含告警与响应能力。要当HIDS用，必须搭配调度器（如Fleet、Kolide）或自建采集管道，把差异查询结果推到告警系统。它更适合资产盘点、合规基线核查与应急取证，实时入侵检测需额外建设。
Wazuh单机部署需要多少资源？
官方建议管理端至少4核8GB内存、磁盘按每日日志量预留。实测50台以内主机、开启文件完整性监控与基础规则集时，4核8GB可稳定运行；若开启漏洞检测与大量自定义规则，建议8核16GB。日志留存周期越长磁盘压力越大，建议单独挂载数据盘并配置日志轮转。
Agent型HIDS和Wazuh有什么区别？
Wazuh本身就是Agent型HIDS的一种，区别在于商业或轻量Agent型HIDS通常把规则、告警、Web控制台做成一体化交付，部署快、默认规则贴近实战攻防，但扩展性与自定义能力弱于Wazuh。Wazuh开源免费、可深度定制，代价是需要自己维护管理端、调规则和做容量规划。
主机数量少，值得上HIDS吗？
值得，但要选轻量方案。3到10台主机建议用单二进制Agent型HIDS或Osquery加定时任务做基线核查，重点覆盖登录审计、关键文件变更、异常进程与外联。成本主要是学习时间，收益是入侵早发现，避免被挖矿或勒索后才发现。先做基线再谈实时告警。
如何验证HIDS规则是否真的生效？
用无害的模拟动作验证：创建测试用户、写入测试文件到监控目录、启动一个可疑命名的进程，观察是否在预期时间内产生告警。命令如 useradd testhids 后检查告警，再 userdel 清理。规则长期不验证会因系统升级静默失效，建议纳入月度巡检清单。