tamabox

183 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
tamakyi	036156b6fb	蜜罐告警: 修复去重口径与空收件人短路审阅蜜罐邮件提醒功能发现的问题，三项一并修： 1. autoban.alerted 从 map[string]bool（永不过期）改为带时间戳的 map[string]time.Time，冷却期 24h 与蜜罐侧对齐。cleanup 里清理过期项，长期盯防同一来源不再漏掉后续攻击活动（此前一生只报一次）。 2. 蜜罐告警在 security_alert_email 为空时短路：route.go 注入 sendAlert 前判空，收件人缺失置 nil，避免每次凭据提交白做 SMTP 拨号 + 刷 Warn。 3. 强化 security_alert_email 的配置警示（蜜罐邮件含明文密码，必须是个人邮箱、禁群组/分发列表）。	2026-10-30 17:17:25 +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	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

Author

SHA1

Message

Date

tamakyi

036156b6fb

蜜罐告警: 修复去重口径与空收件人短路

审阅蜜罐邮件提醒功能发现的问题，三项一并修：

1. autoban.alerted 从 map[string]bool（永不过期）改为带时间戳的
   map[string]time.Time，冷却期 24h 与蜜罐侧对齐。cleanup 里清理过期项，
   长期盯防同一来源不再漏掉后续攻击活动（此前一生只报一次）。
2. 蜜罐告警在 security_alert_email 为空时短路：route.go 注入 sendAlert
   前判空，收件人缺失置 nil，避免每次凭据提交白做 SMTP 拨号 + 刷 Warn。
3. 强化 security_alert_email 的配置警示（蜜罐邮件含明文密码，
   必须是个人邮箱、禁群组/分发列表）。

2026-10-30 17:17:25 +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

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