博客上线5天，我搭了个安全运营中心

大家好，我是老张。

前天写了博客后台 Dashboard，昨天写了 WAF 自动封禁抓了 11 个恶意 IP。有读者留言问："拦是拦住了，但你怎么知道今天有多少攻击、都是什么类型、谁在打你？"

好问题。这就是今天要聊的------从单点 WAF 到安全运营中心。

昨天你看到的是盾拦了什么，今天你看到的是我搭了一个 4-Tab 安全监控大屏：总览 Dashboard、封禁 IP 库、实时攻击日志流、防护规则统计。指标监控 + 日志实时聚合，多种攻击类型自动分类，三级风险判定，IP 地理归属一条龙。

先看效果：

4-Tab 设计：每个 Tab 解决一个问题

Tab	解决的问题	数据来源
安全总览	一眼看清威胁全貌	时序指标 + 日志聚合
已封禁 IP	溯源取证、访问记录	黑名单 + 操作日志 + 离线归属地库
实时攻击日志	实时流式攻击监控	访问日志实时解析聚合
防护规则统计	每条规则的命中效果	时序指标计数器

下面逐个拆解。

1️⃣ 安全总览：一眼看清战场

四个核心指标卡片 + 两张趋势图表：(以下数据已图中数据为准，重新截了图，数据进行了对应的更新，就不在改了)

今日威胁总量：354 次

这个数字是后端实时扫描访问日志，按攻击特征聚合出来的。不是时序数据库的滞后数据------你打开页面的那一刻，它已经把今天的日志全扫了一遍。

今日拦截请求：52 次

WAF 规则命中后直接断开连接，这些请求根本没进后端。52/354 ≈ 14.7% 的拦截率，看着不高，但细看数据就明白了------265 次 PHP 后门探测，目标文件根本不存在，拦不拦都一样。真正需要拦截的是注入攻击和路径扫描。

风险告警：296 次

三级风险判定逻辑：根据攻击类型和潜在危害自动分级。时序指标的每日告警计数器驱动，即使监控系统临时不可用，也有降级兜底方案。

境外恶意 IP 占比：75.0%

16 个封禁 IP 里 12 个是境外。瑞士苏黎世、美国洛杉矶的扫描器比你想象的勤快。

近 24 小时攻击趋势图：时序数据库范围查询，多种攻击类型分色堆叠。今天早上 7:15 有一个橙色尖峰------PHP 后门探测突然飙到 120 次，9 点后又来了一波。这就是自动化扫描机器人的工作时间。

近 7 日封禁趋势 ：从操作日志 block_ip 事件按天聚合。8 月 1-5 日零封禁，6 日 5 个，7 日 4 个------说明攻击在加速。

2️⃣ 已封禁 IP：溯源 + 取证

这不是简单的 IP 列表。每个 IP 背后有完整的画像：

访问次数：从访问记录表 JOIN 出来的近 7 天真实访问量
属地：离线库解析（国家·省·市），本地缓存加速
首次出现 / 最近访问：精确到秒的时间线
User-Agent：设备指纹，三个绵阳 IP 全用同一个 macOS Chrome UA------很明显是同一台机器

你会发现攻击来源非常集中：绵阳承包了 TOP10 里的 7 席，最高 102 次。北京 2 席。这不是随机扫描，是有人在定点搞你。

3️⃣ 实时攻击日志：访问日志流式聚合

这是我个人最喜欢的一个 Tab。它不是时序指标（时序数据库不适合存高基数路径数据），而是后端直接读日志文件，按攻击特征匹配后实时输出。

三条典型记录------同一秒，同一个瑞士苏黎世 IP，连扫三个 Webshell 路径：

时间	路径	攻击类型	状态	拦截
07:34:11	`/i99z7zzbwtpte...`	PHP 后门探测	404	否
07:34:11	`/shiny.php`	PHP 后门探测	404	否
07:34:11	`/BDKR28WP.php`	PHP 后门探测	404	否

都是 404，因为文件根本不存在。但这不重要------重要的是你能实时看到谁在哪一秒用什么 payload 在扫你。这就是可观测性。

支持按 IP、路径关键词、攻击类型过滤，还有一个导出按钮。出安全报告的时候直接导出 CSV，不用手搓。

4️⃣ 防护规则统计：每道防线效果一目了然

多条规则，按命中数排序：

规则类型	等级	今日命中	最近触发
PHP 后门探测	高危	265	8/5 23:35
系统指纹探测	中危	38	8/5 22:59
后台路径扫描	高危	25	8/5 21:33
注入/XSS 攻击	高危	18	8/7 09:05
WAF 拦截	高危	6	8/5 23:21
管理工具探测	中危	2	8/5 08:54

数据源是时序指标计数器，由日志导出器从日志中提取。所有规则带最近触发时间------你可以一眼看出哪些攻击还在活跃。今天早上 9:05 还有人尝试 SQL 注入。

️ 架构设计：为什么不全部用时序监控？

这是我在设计时的一个关键决策。时序数据库擅长趋势图和计数器，但有两个问题：

高基数问题：攻击路径数以千计，放进时序 label 会爆内存
实时性问题：时序数据库默认有抓取间隔，跟不上"这一秒谁在扫我"

所以我把数据分了两层：

数据	存储方案	原因
趋势图表、规则命中计数	时序数据库	时序数据，低基数
TOP 攻击路径、实时日志、IP 详情	后端直读日志聚合	高基数 + 实时性要求

攻击分类引擎的核心思路就是特征匹配------按优先级命中第一个就分类。静态资源（js/css/图片）直接跳过，不参与分类。

老张的总结

这套安全监控体系的演进路径：

sh 复制代码

Day 1-3：博客上线，WAF + 自动封禁（被动防御）
Day 4：  后台 Dashboard 上线（管理能力）
Day 5：  安全监控 4-Tab 改版（可观测性）

三天时间，从"盾拦住了没"到"我能看清整个战场"。

有几个设计决策我觉得做得对：

时序指标 + 日志聚合双轨制------不强行把高基数数据塞进时序数据库，各司其职
降级设计------即使监控系统挂了，也有日志兜底方案
规则复用------分类引擎和日志导出器复用同一套特征库，规则只维护一处，改了之后面板自动同步
短周期内存缓存------避免每次请求都扫全量日志文件

当然也有没做的：目前告警和封禁还在持续优化中，下一步是把告警触发、自动封禁、自动解封做成完整闭环。

这篇文章和昨天那篇什么关系？

昨天那篇讲的是"盾"------WAF 自动封禁机制，2 个攻击案例。

今天这篇讲的是"指挥塔"------4-Tab 安全运营中心，攻击分类、指标监控、实时日志流、风险等级判定。

合在一起，就是一个运维人从零搭站到建成安全运营体系的完整叙事：先有盾（WAF），再有眼（Dashboard），最后有指挥塔（安全监控中心）。

互动话题

你的博客/个人项目有安全监控吗？还是全靠 CDN 扛？
攻击分类你是用现成 WAF 还是自己写规则？哪种更省心？
指标监控 + 日志聚合这套组合拳，你在生产环境用过吗？

⚠️ 声明：本文基于个人博客真实安全监控系统编写，截图数据均为真实攻击记录，已对 IP 归属地等敏感信息做模糊处理。攻击检测核心规则、封禁阈值等实现细节因安全原因未完全公开。