核心要点（TL;DR）
- HIDS管“正在发生什么”，基线检查管“配置是否合规”，两者互补不可替代。
- 预算有限优先部署Wazuh或OSSEC做文件与登录监控，再用Lynis做周期性基线体检。
- 免费工具的最大成本是调优与告警治理，不调优的HIDS等于噪声发生器。
- 基线检查必须落到修复闭环，只出报告不改配置等于没做。
很多站长和运维的云主机安全现状是：安全组开了、密码改复杂了，就以为万事大吉。直到某天发现CPU跑满、/tmp里多了个陌生二进制、authorized_keys被追加了一把公钥，才意识到主机层根本没有可见性。主机入侵检测（HIDS）解决的是“正在发生什么”，基线检查解决的是“配置是否合规”，两者一个管动态、一个管静态，缺一不可。本文按实战视角盘点免费方案，给出可直接执行的命令与清单。
一、先分清：HIDS与基线检查各自解决什么问题
HIDS通过Agent或轻量采集器监控文件变更、登录事件、进程与网络连接，核心价值是发现异常并留痕；基线检查则是按CIS等标准逐项核对系统配置，输出合规得分与整改项。前者是摄像头，后者是体检报告。
| 维度 | 主机入侵检测（HIDS） | 基线检查 |
|---|---|---|
| 运行方式 | 常驻Agent，实时/准实时 | 周期性扫描，按需执行 |
| 典型工具 | Wazuh、OSSEC、Auditd | Lynis、OpenSCAP、自写Shell脚本 |
| 输出 | 告警事件流 | 评分与整改清单 |
| 主要成本 | 规则调优、告警治理 | 修复闭环、变更后复查 |
二、免费HIDS怎么选：Wazuh、OSSEC与Auditd
三者并非完全替代关系。Auditd是内核审计子系统，适合做底层系统调用与关键文件监控；OSSEC轻量、规则成熟，适合单机或小规模；Wazuh基于OSSEC演进，自带Elasticsearch可视化与合规模块，适合想要开箱即用面板的团队。
方案A：Wazuh单机快速验证
# 官方一键安装（仅建议在测试机先跑）
curl -sO https://packages.wazuh.com/4.x/wazuh-install.sh
sudo bash ./wazuh-install.sh -a
# 安装完成后访问 https://<IP>，默认账号 admin
# Agent端安装并注册
sudo WAZUH_MANAGER='管理端IP' yum install wazuh-agent -y
sudo systemctl enable --now wazuh-agent方案B：OSSEC最小化部署
# 编译安装（以3.x为例，路径按实际调整）
wget https://github.com/ossec/ossec-hids/archive/refs/tags/3.7.0.tar.gz
tar xzf 3.7.0.tar.gz && cd ossec-hids-3.7.0
./install.sh # 选择local或server模式
/var/ossec/bin/ossec-control start方案C：Auditd精准盯关键路径
# 监控SSH配置、计划任务、Web目录的可疑写入
echo '-w /etc/ssh/sshd_config -p wa -k sshcfg' >> /etc/audit/rules.d/host.rules
echo '-w /etc/cron.d/ -p wa -k cron' >> /etc/audit/rules.d/host.rules
echo '-w /var/www/html/ -p wa -k webroot' >> /etc/audit/rules.d/host.rules
augustctl -R /etc/audit/rules.d/host.rules && systemctl restart auditd
aureport -k sshcfg -ts today选择建议：单机小站优先Auditd+OSSEC组合，成本最低；有可视化与多机管理需求选Wazuh；已有ELK栈的团队可直接接Wazuh的日志输出。
三、免费基线检查工具：Lynis与OpenSCAP
Lynis上手最快，一条命令出报告；OpenSCAP更贴近等保与CIS标准，适合需要合规证据的场景。
# Lynis安装与执行
apt install lynis -y # 或 yum install lynis
lynis audit system --quick
# 报告位置
/var/log/lynis.log
/var/log/lynis-report.dat
# 只看建议项
grep -i suggestion /var/log/lynis.log | head -30Lynis输出中的Hardening index只是参考值，真正要看的是Warning与Suggestion条目。建议把每次报告存档，用diff对比变更前后的差异，比单次得分更能说明问题。
四、实战排查：主机疑似被入侵时的五步动作
- 看登录痕迹：
last -a | head -20、lastb | head -20，重点看陌生IP与异常时段。 - 查账号与密钥：
grep -v '^#' /etc/passwd | awk -F: '==0'找UID为0的账号；检查~/.ssh/authorized_keys是否被追加。 - 看进程与网络：
ps aux --sort=-%cpu | head、ss -antp，关注无文件路径、伪装成系统名的进程。 - 查持久化：
crontab -l、ls -la /etc/cron.d/、systemctl list-unit-files | grep enabled、cat /etc/rc.local。 - 看文件变更：用HIDS的变更记录或
find /var/www -mtime -2 -type f定位近期被写入的Webshell。
排查顺序建议先取证后处置：先导出进程列表、网络连接、登录日志，再考虑隔离与清理，避免证据被覆盖。
五、基线检查清单：十项高频整改项
- SSH禁止root直登，改用普通账号+sudo：
PermitRootLogin no - 关闭密码登录，强制密钥：
PasswordAuthentication no - 修改默认端口并限制来源IP（安全组+sshd双层）
- 开启登录失败锁定：
pam_tally2或faillock - 关闭不必要的服务与端口，
ss -antlp逐项确认 - 内核参数加固：关闭IP转发、开启SYN Cookie、限制ICMP
- 日志集中留存，rsyslog转发到独立日志机
- 关键目录权限收敛：
/etc/shadow为600，Web目录禁止777 - 定期补丁：
yum update --security或apt upgrade - 为关键文件建立哈希基线，定期比对
六、防护建议：把工具接成闭环
免费工具真正的门槛不是安装，而是告警治理与修复闭环。建议按“基线先行、HIDS跟进”的顺序落地：先用Lynis完成一轮加固，再用Wazuh或Auditd盯住关键路径变更，最后把告警接入值班渠道。若团队缺少人力做规则调优，可考虑在关键节点叠加具备主机入侵检测与基线核查能力的托管方案，例如AegisX提供的实时文件监控与配置基线核查，能减少自建规则的维护负担，与开源工具形成分层防护。
行动建议：今天就选一台非核心节点，执行lynis audit system --quick拿到首份基线报告，同时用Auditd监控/etc/ssh与Web根目录，跑满一周后再决定是否引入Wazuh做集中管理。
常见问题（FAQ）
免费的主机入侵检测工具能用在生产环境吗？
可以，但要区分场景。OSSEC、Wazuh这类开源HIDS在生产环境已有大量实践，核心风险不在软件本身，而在规则调优与告警治理。建议先在非核心节点灰度部署，收敛误报后再推广，并为Agent预留CPU与磁盘IO余量，避免影响业务。
基线检查工具和漏洞扫描有什么区别？
基线检查看的是“配置是否符合安全规范”，比如SSH是否禁止root登录、密码策略是否达标；漏洞扫描看的是“软件是否存在已知缺陷”。两者维度不同，基线不合格会放大漏洞危害，通常先做基线加固，再叠加漏洞扫描与补丁管理。
云厂商自带的主机安全能力还需要自建HIDS吗？
建议组合使用。云厂商Agent通常覆盖暴力破解、异常登录等通用场景，但对自定义业务目录、特定配置文件缺少细粒度监控。自建HIDS可按业务定制监控路径与规则，形成互补，同时保留数据自主权。
Lynis多久跑一次比较合适？
建议变更后必跑、常规环境每月一次。系统升级、中间件调整、开放新端口后立即执行一次基线复查，能及时发现配置回退。将Lynis输出存档并做版本对比，比单次得分更有价值。
HIDS告警太多怎么办？
先做白名单收敛，再做分级。把已知的定时任务、发布目录、日志轮转路径加入例外规则，将告警分为“立即处置”和“日报汇总”两级，只对高危事件实时推送。每周复盘一次误报，持续迭代规则，通常两周内噪声可下降一个量级。