tamakyi
d690355cdc
feat(honeypot): 蜜罐安全状况周期汇总（周报/月报 + 地图 + 邮件）
...
以周/月为单位汇总蜜罐命中，把来源 IP 通过公共服务查地理位置，画到地图上，
生成 HTML 报告并发邮件。同时补齐 ipinfo 无法回答「这个 IP 在哪儿」的问题。
新增 IP 地理定位层 internal/security/geoip：
- 与 internal/security/ipinfo 正交。ipinfo 走 cdncheck 离线指纹，只认云厂商/CDN/WAF，
答的是「是不是代理」；肉鸡（家宽、企业宽带、移动网络）必然被判为
「未识别（普通网络）」，所以「在哪儿」必须另建一套。
- ip-api.com 批量打底（100 个/请求、1.4s 节流）+ 腾讯位置服务精修国内
（一 IP 一请求，只精修命中数最高的前 N 个，受 ip_geo_tencent_key 控制）。
- Result{Geo, Unresolved, Requests, Failures} 三态。服务明确回答「没有这个地址」
才允许写失败缓存；请求超时/限流/5xx 一律不写 —— 否则一次抖动会把整批 IP
钉成「查不到」三天，此后每份报告的定位覆盖率都莫名变成 0。
- addrs 按调用方给的顺序构建（不是 map 遍历）：腾讯精修只取前 N 个，乱序会让
每次运行精修到不同 IP，配额花在长尾上。
报告生成 internal/security/report：
- period：PreviousWeek / PreviousMonth，窗口一律 [start, end) 左闭右开，
相邻两期不重叠也不漏边界整点；period_key（week:2026-W44）做幂等。
- aggregate：按 shared.LimitKey 合并（IPv4 精确 / IPv6 折 /64）；国家、城市、
路径、每日趋势；显式统计未定位命中数（覆盖率 60% 的图看起来和 100% 一样）。
- mapdraw：自绘等距圆柱投影气泡图。零海岸线零国界 —— 国界/台湾/南海诸岛绘制
必须符合国家标准，自绘极易画错，真实底图交给腾讯。经纬网 + 度数刻度 +
标签防重叠（同一都市圈两城市坐标差 0.01°，曾把「AU 55」和「AU 30」叠成
看起来像 AU 305 的假数字）。
- html：自包含报告页，内嵌 SVG + 腾讯交互地图（无 key 时给申请指引，
代码里不预置任何 key）。
- countryname：港澳台统一显示「中国香港/中国澳门/中国台湾」，常见国家用中文名。
存储与调度：
- ip_geo_cache（主键 = LimitKey，成功 TTL 90 天 / 明确无数据 TTL 3 天）
- security_report_logs（period_key 唯一索引 → 重启、错过时间窗都能正确补发，
失败重试上限 5 次后停止）
- honeypot report --period week|month [--to] [--dir] [--no-email]
- web 启动时按配置挂 30 分钟一轮的调度器（与保留期清理共用停止信号，
defer 移出 if 外，避免「清理关掉、报告开着」时 goroutine 泄漏）
配置（[security]）：ip_geo_provider=auto|ipapi|tencent|none、ip_geo_tencent_key、
honeypot_report_enabled / _weekly / _monthly / _email / _dir。
顺带修复：
- route/honeypot_test.go 的 captureStore 缺 AggregateSources/AggregatePaths/
TimestampsBetween，整个 route 包编译不过。
- templates/render_test.go 的 mockLoggedUser 缺 TelegramChatID，3 个渲染测试失败。
2026-10-30 16:40:44 +08:00
tamakyi
818fa74160
fix(honeypot): 取证记精确地址、封禁用 /64 键，并补建封与拦截日志
...
线上实测：IPv6 访问蜜罐后收到「你的 IP 已被封禁」，邮件里却是
`2408:…::/64` —— 既不像自己的地址，也说不清封了多大范围；同时用户自己
仍能正常访问，看日志也无从判断到底有没有封。
根因是「取证地址」与「封禁键」混用同一个变量（都取 LimitKey 的折叠值）：
- 取证丢掉精确 IPv6 后 64 位，事后无法定位到具体主机、没法和其他日志对账；
- 邮件只给聚合键，运维第一反应是「不是我」，排查方向直接被带偏。
改动：
- Serve 拆 clientIP（ResolveClientIP，精确）与 banKey（LimitKey，/64）：
DB / 凭据文件 / 告警邮件用前者，封禁 / 探测采样 / 告警去重用后者；
- autoban.Options 新增 OnBan 回调（保持纯标准库、不引入 logrus），
route.newBanner 注入后每次建封打 WARN：ban_key / reason / duration / expires_at；
中间件 403 分支加 Debug 日志（被封者会持续请求，Info 会被刷屏）；
- 告警邮件新增「封禁范围」行，仅 ip != ban_key 时渲染（IPv4 不重复显示），
顺带把过时的「已入库」改为「写入取证文件」——凭据早就外置了；
- honeypot stats 的来源排行改按 LimitKey 合并，否则 IPv6 轮换地址会把
排行碎成几十条各 1 次的记录；合并口径与封禁完全一致。
测试（每项都做了变异验证：改坏→确认变红→恢复）：
- TestHoneypotRecordsExactIPv6ButBansByPrefix：精确地址进 DB 与凭据文件、
/64 才是封禁键、同 /64 换地址仍 403；
- TestOnBanCallback：建封回调带键/时长/原因，封禁期内重复命中不重复回调；
- TestHoneypotAlertTemplateRenders：IPv6 渲染封禁范围、IPv4 不重复；
- TestMergeSourcesByKey：同 /64 合并、IPv4 原样、limit 与空输入。
2026-10-23 10:53:03 +08:00
tamakyi
79051acae8
miguan v1
2026-10-21 12:09:28 +08:00
tamakyi
899b6d7f32
fix v16
2026-10-19 03:01:17 +08:00
tamakyi
dba991aa9d
fix v15
2026-10-19 02:37:59 +08:00
tamakyi
12a37e726f
fix v14
2026-10-19 02:25:19 +08:00
tamakyi
7a6417c33d
restrict v8
2026-10-18 23:32:38 +08:00
tamakyi
bd81398a06
restrict v6
2026-10-18 22:18:21 +08:00
tamakyi
e3e59e7c69
chore: baseline snapshot before moderation-strictness feature
...
Repo .git was damaged (refs/ missing, index truncated, object store near-empty).
Repaired via git init (rebuilt refs), stale index preserved as .git/index.corrupt-20260910.bak,
then full worktree committed as a rollback baseline.
2026-09-10 10:56:27 +08:00
tamakyi