三层防护日志统一看，核心不是再买一套大屏，而是把网络边界、主机运行、应用访问三路日志按统一字段格式接入集中平台，用关联规则把同一攻击事件拼成一条完整链路。 下面从采集、工具、合规和运维四个维度拆开说。
三层防护日志统一查看的难点与单层日志有什么区别
三层防护通常指网络边界防护、计算环境防护、应用数据防护，每一层产生的日志格式差异很大，比如防火墙日志里源地址字段可能叫src_ip，WAF日志里可能叫source，主机审计日志里又可能叫SourceIP，时间戳格式、事件等级、动作字段也各自为政。
单层日志只能反映局部事实，防火墙看到端口扫描，主机层看到暴力破解，WAF看到SQL注入，如果不统一看，安全人员会收到三条孤立告警，甚至误判为三起低风险事件，攻击者横向移动时，跨层证据链被切碎,定位问题自然变慢。
企业三层防护日志怎么集中管理，先要承认一个现实：靠人工登录三套设备翻日志，基本等于盲人摸象，统一查看的价值就在于把“盲人”变成“站在高处看全图的人”。
日志集中管理的第一步：把三路日志“请”进一个平台
统一查看的前提是采集，采集方式不能一刀切,不同层有不同脾气。
网络层用Syslog统一推流
边界防火墙、IDS、IPS基本都支持Syslog，配置路径通常在设备的“日志设置”或“Syslog服务器”菜单。
- 登录防火墙管理界面，找到Syslog配置项，填入集中日志服务器IP,端口默认514。
- Linux侧用rsyslog接收，编辑
/etc/rsyslog.conf，开启UDP监听：module(load="imudp") input(type="imudp" port="514") - 重启服务：
service rsyslog restart - 验证是否收到：
tail -f /var/log/syslog | grep 防火墙IP
主机层走Agent采集
Windows和Linux主机不能只靠系统自带日志文件，业内专家指出，主机层日志实时性要求高,Agent方式比定时拉取更可靠。
- Windows用Winlogbeat或商业EDR，配置
winlogbeat.yml
- Linux用Auditbeat或Osquery，采集
/var/log/auth.log、/var/log/secure以及auditd审计记录。 - Agent统一由管理端下发策略,避免每台机器单独配置。
应用层不能只靠文件
WAF、数据库审计、Nginx访问日志常落在本地文件里,用Filebeat做轻量级采集最合适。
filebeat.inputs:
- type: filestream
paths:
- /var/log/nginx/access.log
output.logstash.hosts: ["192.168.1.100:5044"]
启动命令：sudo systemctl enable filebeat
采集完成后，需要做字段标准化，比如把不同来源的源IP统一映射为src_ip，事件类型统一映射为event_type，这一步不完成,后面关联分析会非常吃力。
三层防护日志分析工具多少钱才合理
价格是很多人关心的现实问题，工具选型不能只看软件报价,要算总账。
开源方案里，ELK组合、Graylog、Wazuh软件费用为零，但人力投入高，从部署、调优、规则编写到故障排查,至少需要一个熟悉Linux和正则的人长期维护。
商业SIEM或日志审计平台，比如Splunk、QRadar、国内主流日志审计系统，多数按EPS或日志源节点数授权，价格区间跨度大，几万到几十万都有,主要看日志量和功能模块。
多少钱算合理，可以先看日均日志量：
- 日均日志量在10GB以下，开源ELK加Wazuh基本够用,主要成本是服务器硬盘和运维人力。
- 日均日志量超过30GB，商业SIEM的索引性能和内置告警规则优势明显,但授权费会随数据量上涨。
- 等保合规场景下，日志留存至少6个月，存储成本是容易被忽视的隐性开销，一盘8TB企业级硬盘也存不下太久的全量日志,需要做冷热分层。
| 方案 | 软件费用 | 人力投入 | 适合场景 |
|---|---|---|---|
| 开源ELK+Wazuh | 免费 | 高 | 日志量小，团队有Linux能力 |
| Graylog | 免费 | 中 | 中小企业，需要快速检索 |
| 商业日志审计/SIEM | 按EPS/节点 | 低 | 合规严格，安全人力有限 |
选择思路很简单：先算日均日志量，再评估团队有没有能力维护开源方案，没有能力，就老老实实上商业平台,别让工具变成负担。
北京地区等保合规场景下的三层防护日志集中管理方案
北京地区等保测评对日志留存和审计有明确要求：日志必须保存至少6个月，这个留存期是底线,不是可选项。
具体落地方案可以这样设计：
- 部署位置：集中日志服务器放在内网安全管理区,不直接暴露互联网。
- 高可用：用rsync或数据库主从同步做双机热备,防止单点故障后日志丢失。
- 日志源覆盖：至少包括防火墙、WAF、服务器操作系统、数据库、堡垒机,缺一类在测评时都可能被扣分。
- 报表导出：测评时能按资产、时间范围、事件类型快速导出审计报表,格式通常要求CSV或PDF。
- 北京机房网络质量较好，可以在同城双机房做日志异地备份,但不一定要跨省。
等保场景下，统一查看不只是日常运维需求，更是合规刚需，如果日志分散在设备本地,测评时很难证明审计完整性。
用关联规则让三层日志“对话”
日志进了平台，还只是第一步，真正让统一查看产生价值的,是关联规则。
比如同一IP在边界防火墙出现端口扫描，在主机层出现大量登录失败，在WAF出现SQL注入尝试，单条看都不严重，但三个条件同时满足,大概率是自动化攻击工具在跑。
在Splunk类查询语言里可以这样写：
index=security sourcetype IN (firewall, wineventlog, waf) | transaction src_ip maxspan=10m | table src_ip, sourcetype, signature
在ELK里可以用Kibana的KQL先查单层,再用Painless或Watcher做联合告警。
典型攻击链路中,三层日志对应关系如下：
| 攻击阶段 | 边界层日志 | 主机层日志 | 应用层日志 |
|---|---|---|---|
| 扫描探测 | firewall deny TCP 22 | 无明显条目 | WAF返回403 |
| 暴力破解 | firewall allow TCP 22 | sshd Failed password | 无 |
| 漏洞利用 | firewall allow TCP 80 | HIDS告警可疑进程 | WAF SQL注入特征 |
| 数据外传 | firewall outbound大流量 | EDR告警外联 | 数据库审计select大量数据 |
行业共识认为，三层日志若不关联，只能看到孤立告警；一旦关联上，从扫描到爆破到利用到外传的完整攻击链会自然浮现，安全分析从“猜”变成“看证据”。
统一查看后的日常运维习惯
工具上线不是结束,日常习惯才决定能不能持续看到效果。
- 保存高频查询视图：今日登录失败Top10”“防火墙拦截Top10”“非工作时间数据库导出操作”。
- 设置基线告警：非工作时间出现批量数据导出，或者单IP短时间跨层触发多条告警,直接推送通知。
- 定期回顾留存策略：索引不能一味膨胀，但也不能为了省磁盘提前删，留存期要满足合规底线,同时用冷热分层降低存储成本。
三层防护日志统一查看用什么开源工具？
Wazuh负责主机层入侵检测，ELK负责日志检索与可视化，Filebeat负责文件类日志采集，三者组合能满足多数中小企业需求，网络层如果以Syslog为主，再加一个Logstash做解析,基本可以跑通全链路。
三层防护日志和单层日志有什么区别？
单层日志只能说明单一防护点发生了什么，比如防火墙看到扫描，但无法判断扫描是否进入主机，三层日志统一后，能看到扫描、爆破、漏洞利用、数据外传的完整因果链，分析效率明显不同，区别不在数据量,而在能否还原攻击全貌。
三层防护日志统一查看需要留存多久？
根据等保2.0要求，日志留存至少6个月，部分行业如金融可能要求更长，具体以监管侧当期要求为准，留存时长直接决定存储容量规划,也影响索引策略和冷热分层设计。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/655199.html
