核心要点（TL;DR）
- 主机安全防护服务器内部，WAF防护Web应用层，堡垒机管控运维访问。
- 三者互补而非替代，需协同部署形成纵深防御。
- 主机安全侧重入侵检测与漏洞修复，WAF侧重拦截应用层攻击，堡垒机侧重审计与访问控制。
- 明确职责边界可避免安全建设重复或遗漏。
痛点引入：安全设备买了一大堆，为什么还是被入侵？
很多运维团队在安全建设上投入不少，WAF、堡垒机、主机安全Agent都上了，但依然出现服务器被挖矿、数据被拖库的惨剧。根本原因往往不是设备不行，而是职责边界不清——该WAF拦的请求漏给了主机，该堡垒机管的运维操作绕过了审计，该主机安全发现的异常进程没人处理。结果就是安全设备各自为战，形成防护盲区。
本文从实战角度拆解主机安全、WAF、堡垒机三者的核心区别与职责边界，并给出可落地的配置步骤和检查清单，帮你把安全体系从“堆产品”变成“建能力”。
一、三者的核心定位与职责边界
简单来说，主机安全守护服务器内部（系统层），WAF守护Web应用层，堡垒机守护运维访问通道。它们分别对应不同的攻击面和防护目标。
| 维度 | 主机安全 | WAF | 堡垒机 |
|---|---|---|---|
| 防护对象 | 服务器操作系统、进程、文件、账户 | Web应用流量（HTTP/HTTPS） | 运维人员访问服务器的操作 |
| 核心功能 | 入侵检测、漏洞修复、基线核查、文件完整性监控 | 拦截SQL注入、XSS、CC攻击等应用层攻击 | 身份认证、权限控制、操作审计、会话阻断 |
| 部署位置 | 服务器内部（Agent或Agentless） | Web服务器前端（反向代理或透明桥） | 运维终端与服务器之间（网关模式） |
| 典型产品 | HIDS、EDR、漏洞扫描器 | 云WAF、硬件WAF、软件WAF（ModSecurity） | 堡垒机（如JumpServer）、特权访问管理（PAM） |
三者互补而非替代。WAF无法发现服务器内部的提权行为，堡垒机无法检测Webshell，主机安全无法拦截外部的SQL注入。只有明确边界，才能协同作战。
二、主机安全：服务器内部的“监控摄像头”
主机安全的核心是持续监控服务器内部状态，发现异常行为并告警。常见能力包括：文件完整性监控（FIM）、进程行为分析、账户变更检测、暴力破解防护、漏洞和基线管理。
实战配置：以开源HIDS（如Wazuh）为例
1. 安装Agent：在服务器上执行curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -，然后添加源并安装wazuh-agent。
2. 配置监控目录：编辑/var/ossec/etc/ossec.conf，在<syscheck>中添加关键目录（如/etc、/var/www/html），设置实时监控realtime="yes"。
3. 启用入侵检测规则：确保<rootcheck>和<localfile>中的日志监控开启，例如监控/var/log/auth.log。
4. 启动服务：systemctl start wazuh-agent，并检查日志tail -f /var/ossec/logs/ossec.log确认无报错。
检查清单
- Agent进程是否运行：
ps aux | grep wazuh - 关键文件变更是否告警：手动修改
/etc/passwd测试 - 基线核查是否通过：运行
/var/ossec/bin/agent_control -l查看状态 - 漏洞扫描是否定期执行：检查扫描任务计划
三、WAF：Web应用的“门卫”
WAF部署在Web服务器前端，对HTTP/HTTPS流量进行清洗，拦截恶意请求。它不关心服务器内部状态，只关注请求是否合法。
实战配置：以ModSecurity+OWASP CRS为例
1. 安装ModSecurity：apt install libapache2-mod-security2（Apache）或编译Nginx模块。
2. 启用核心规则集：下载OWASP CRS，放置于/etc/modsecurity/crs/，在配置中引入Include /etc/modsecurity/crs/crs-setup.conf和Include /etc/modsecurity/crs/rules/*.conf。
3. 设置拦截模式：在modsecurity.conf中设置SecRuleEngine On，并配置SecDefaultAction "phase:1,deny,log"。
4. 测试规则：使用curl发送包含?id=1' OR '1'='1的请求，观察是否返回403。
检查清单
- WAF是否处于拦截模式（非仅检测）
- 规则集是否定期更新（CRS版本）
- 误报率是否可接受：检查日志
/var/log/modsec_audit.log - 是否覆盖所有Web入口（包括API网关）
四、堡垒机：运维操作的“审计通道”
堡垒机用于集中管控运维人员对服务器的访问，实现身份认证、权限最小化和操作审计。所有运维操作必须经过堡垒机，避免直接登录服务器。
实战配置：以JumpServer为例
1. 部署JumpServer：使用Docker快速启动docker run -d -p 80:80 -p 2222:2222 --name jumpserver ...（参考官方文档）。
2. 配置资产：在Web界面添加服务器资产，设置协议（SSH/RDP）。
3. 创建用户并授权：添加运维用户，绑定资产权限，设置命令过滤规则（如禁止rm -rf）。
4. 启用会话审计：确保会话记录开启，可回放操作过程。
检查清单
- 所有运维人员是否只能通过堡垒机访问服务器
- 是否启用多因子认证（MFA）
- 高危命令是否被拦截或二次审批
- 会话日志是否保留至少6个月（等保要求）
五、协同作战：构建纵深防御体系
明确边界后，三者应联动形成闭环。例如：WAF拦截攻击并告警，主机安全检测到Webshell落地，堡垒机审计到异常登录。建议建立统一的安全运营中心（SOC）或SIEM，汇聚日志进行关联分析。
在防护建议方面，可以考虑使用AegisX的主机安全能力，其轻量级Agent能实时监控文件变更和异常进程，并与WAF日志联动，快速定位攻击链。同时，AegisX提供可视化 dashboard，帮助运维人员直观掌握安全态势。
行动建议
- 立即梳理现有安全设备，对照本文表格明确各自职责，找出防护盲区。
- 为每类设备制定检查清单，每周执行一次巡检。
- 至少每季度进行一次模拟攻击测试，验证设备协同效果。
- 推动安全左移，在开发阶段引入WAF规则测试和主机基线检查。
安全建设不是堆砌产品，而是让每个组件在正确的位置发挥正确的作用。理清主机安全、WAF、堡垒机的边界，你的防御体系才能真正生效。
常见问题（FAQ）
我们公司已经用了WAF，还需要主机安全吗？
需要。WAF主要防护Web应用层攻击（如SQL注入、XSS），但无法检测服务器内部的恶意进程、文件篡改或提权行为。主机安全能监控系统调用、文件完整性和账户异常，弥补WAF的盲区。两者互补，共同构建纵深防御。
堡垒机可以替代主机安全吗？
不能。堡垒机核心是运维访问的管控与审计，记录谁在什么时间做了什么操作，但缺乏对主机内部威胁的实时检测和响应能力。主机安全则持续监控主机行为，发现入侵迹象。两者职责不同，需配合使用。
小企业资源有限，应该优先部署哪个？
建议优先部署主机安全（如HIDS）和基础WAF。主机安全能防护核心数据，WAF可阻挡常见Web攻击。堡垒机可在运维流程复杂后引入。根据业务暴露面选择，但主机安全是底线。
如何验证主机安全agent是否正常工作？
可通过命令检查进程和日志：ps aux | grep agent 查看进程，tail -f /var/log/agent.log 查看日志。还可模拟入侵行为（如创建恶意文件）测试告警。定期检查agent与管控端的心跳状态。
WAF和堡垒机在等保合规中分别对应哪些要求？
WAF对应等保中Web应用防火墙要求（如入侵防范、恶意代码防范），堡垒机对应访问控制、安全审计要求（如身份鉴别、操作审计）。主机安全对应入侵防范、恶意代码防范和资源控制。三者共同满足等保多个控制点。