tamakyi/tamabox
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
136 Commits 1 Branch 0 Tags
6fad0cbe509d4f1343a46735ffa69f588ba84988
Commit Graph
19 Commits
Author SHA1 Message Date
tamakyi 0318ba81b4 feat(autoban): 封禁响应体改成一张 403 图片 
被封禁来源访问任何路径时，原来只回 13 字节的 "403 Forbidden"：既没有信息量，
人肉访问（尤其是共享出口被连累的误封）时看着像站点挂了；扫描/爆破脚本也常靠
读这行明文确认「自己已被拦」。

改为返回一张 256×256 的 webp（约 8.6 KB，画面写着 403 Forbidden），状态码不变：
- 图片用 //go:embed 编进二进制，不依赖外部 URL、不占公开路径；
- 显式给 Content-Length（8 KB 超过 Go 的 2 KB 写缓冲，不设会退回 chunked）；
- Cache-Control: no-store —— 中间层缓存 403 没有意义，还会让解封后的响应继续命中；
- HEAD 只回头不写 body；
- 放在 internal/route/assets/ 而不是 static/：static 下的东西有可公开访问的 URL，
  等于多一个指纹入口。

注意链接：给的 R2 预签名地址 X-Amz-Expires=604800（7 天），热链到期就会挂，
所以是把字节取回来打包，而不是重定向或代理。

测试：
- TestWriteBanned：状态码 403、image/webp、Content-Length 与内嵌字节数一致、
  body 前 12 字节是 RIFF/WEBP（防止被换成 HTML 或明文这类回归）；
- TestWriteBannedHead：HEAD 无 body 但有 Content-Length；
- 原 TestHoneypotBansEvenWhenAutoBanDisabled 里断言 "403 Forbidden" 明文的用例
  改为断言 image/webp 与体积。
变异验证：把 writeBanned 改回写明文 + text/plain，两条用例均按预期变红。
 2026-10-23 15:04:13 +08:00
tamakyi 307bd94ed1 feat(honeypot): /xmlrpc.php 走真实 XML-RPC，动态 token 不再恒定 
线上验收发现两个「能被指纹识别」的破绽，都不影响原有功能但削弱伪装：

一、/xmlrpc.php 回的是 HTML 登录页（P1）
我们自己发的响应头里就有 X-Pingback: /xmlrpc.php —— 扫描器顺着跟过来，
一看是 HTML 就知道整站是假的（真实 WordPress 在这里回 text/xml）。
更可惜的是 system.multicall 这条通道被浪费：一次请求能带上千组用户名/密码、
且绕开登录页限速插件，是 WP 爆破里产出最高的入口。

新增 xmlrpc.go：
- 非 POST → 405 + fault「XML-RPC services are disabled on this site.」（与真实 WP 一致）
- POST methodCall → 200 + fault「Incorrect username or password.」（不区分用户是否存在）
- POST system.listMethods → 200 + 方法列表（枚举类工具靠它确认对面是真 WP）
- 凭据提取刻意不上 encoding/xml（蜜罐被高频命中）：抓所有 <string>、剔除
  methodName 与站点 URL 后两两配对。wp.getUsersBlogs 的 blog_id 若是短数字会让
  配对错位一位，故「奇数长度 + 首项短数字」时丢首项；另外原始串全量写进
  fields（xmlrpc.0/1/…），配对失败也不丢原文。
  multicall 的第一组进标准字段，其余进 cred2/cred3… —— 一个用户名配一长串
  密码是常见字典形态，只留第一组等于丢掉整份字典。
- 封禁与表单提交同规则：带凭据走 RecordHoneypot（立即封），否则走常规阈值。

二、进入页面的隐藏值每次请求都一样（P2）
两次请求拿到同一个 pma token / csrf_token / X-Jenkins-Session，任何脚本都能
判定对面是伪造的。改为按请求生成 32 位 hex（math/rand/v2 —— 这些是假 token，
不需要不可预测，只需要每次不同；crypto/rand 在 Windows 要走系统调用，贵一个量级），
页头、hidden 与 Set-Cookie 共用同一套。

顺带：
- X-Pingback 改绝对地址（$base/xmlrpc.php）。真实 WP 给绝对 URL，相对路径本身
  就是破绽；没配 external_url 时干脆不发这个头。
- Cache-Control 从 no-store 改 no-cache, must-revalidate, max-age=0
  （no-store 更像安全设备/代理加的，不像登录页）。
- Grafana / GitLab 补上真实产品会种的会话 cookie（grafana_sess、_gitlab_session）。
- Match 增加 .php 变体兜底：清单里是 /phpinfo，扫描器打 /phpinfo.php，
  原来漏掉 → 302 回首页，等于明确告诉对方「这个文件不存在」。

测试：xmlrpc_test（IsXMLRPCPath / getUsersBlogs / multicall / 数字 blog_id /
非 XML-RPC body / fault 与 listMethods 输出）、family_test（动态 token 两次不同且
是合法 hex、X-Jenkins-Session 与 correlation_id 动态、Pingback 绝对地址与缺省不发、
所有家族渲染后不残留 $ 占位符）、route 层（POST multicall 捕获凭据 + 立即封 +
回 text/xml；GET 回 405 fault 而非登录页）、honeypot（.php 变体命中且不牵连业务路径）。
四处变异验证均按预期变红：固定 token、xmlrpc 分支失效、Pingback 退化成相对路径、
.php 兜底失效。

性能：RenderFamily 3.7µs→4.18µs、2→3 allocs（多的一次是 hex 编码），
AssetFor 仍 0 分配。
 2026-10-23 12:58:48 +08:00
tamakyi 811578dcf1 feat(honeypot): 按扫描目标伪装成 9 类后台，静态资源不落库 
原来所有诱饵路径都回同一个 WordPress 登录页。爆破工具的标准流程是
「先按路径判断这是什么后台，再拿它认识的字段名填表」——在 /phpmyadmin/index.php
上回 WP 表单，等于告诉对方「这里没有 PMA」，对方直接换目标，既拿不到凭据
也没有取证价值。

新增 family.go（皮肤表）+ asset.go（静态资源占位），page.go 改为按家族渲染：

  wordpress   /wp-login.php /wp-admin /wp-json    log/pwd、wordpress_test_cookie
  phpmyadmin  /phpmyadmin /pma /adminer.php       pma_username/pma_password、hidden token
  tomcat      /manager/html /host-manager         401 + WWW-Authenticate: Basic（无表单）
  jenkins     /jenkins /jnlpJars                  j_username/j_password、X-Jenkins
  grafana     /grafana                            user/password、深色主题
  gitlab      /users/sign_in                      user[login]/user[password]
  luci        /cgi-bin/luci /luci                 luci_username/luci_password
  joomla      /administrator                      username/passwd、hidden option=com_login
  generic     /admin /console /zabbix /jira…      username/password

Tomcat 刻意不给 HTML 表单：真实 Manager 未认证就是 401 + Basic 弹框，给表单
反而更假；Authorization: Basic 本就在 ExtractCredentials 覆盖范围内，捕获能力不减。

凭据字段：
- credentialKeys 扩 pma_* / j_* / luci_* / user[login] / user[password]；
- token 只用于判 HadFields，**移出 isPasswordKey** —— PMA/GitLab 的登录表单带
  hidden CSRF token，而 Fields 是 map、遍历无序，原来的实现会让 token 随机
  顶掉真密码，记录下来的「密码」时对时错。

资源占用（这是本次主要约束）：
- 渲染一页 3.7µs / 2 次分配 / 5.2KB（改前 12µs / 22 次 / 19.5KB）：
  不用 html/template（每次 ParseFS 是毫秒级 IO+编译），改单次 strings.Builder
  并避免 "a"+b+"c" 反复分配，Replacer 提到包级；
- 静态资源请求 55ns / 0 分配：CSS/JS 回常量片段、图片回真 1×1 PNG，
  **不解析 IP、不判封禁、不写库**——真实后台页一次加载 5–10 个资源请求，
  否则等于把页面浏览放大成十几条 INSERT。插件目录下的 .php 回 404（webshell 探测）。

honeypot paths 增加家族汇总，便于确认实际生效的分布。
新增 dev/preview-honeypot：把 9 个家族渲染到 outputs/honeypot-preview/index.html
再配 headless 截图核对外观——本轮两个「源码看不出、截图一眼假」的问题
（Tomcat 忘配 css 导致按钮白字无底色、WP 登录页底部挂着 404 文案）都是它发现的。

测试：TestFamilyOf / TestEveryFamilyRendersItsOwnFields / TestTomcatUses401Basic /
TestAssetFor / TestRenderIsCheap（4KB 上限）/ BenchmarkRenderFamily /
BenchmarkAssetFor，route 层 TestHoneypotServesFamilySpecificPage /
TestHoneypotCapturesFamilyFields / TestHoneypotAssetRequestsAreNotRecorded。
变异验证：资源短路失效 → 3 个资源全变 text/html 且落库；FamilyOf 恒返回
Generic → 页面缺特征字段。两项均按预期变红。
 2026-10-23 12:38:35 +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 bd02eb7ed2 fix templates v1 2026-10-22 17:04:10 +08:00
tamakyi 74312fba58 fix(honeypot): cleanPath 处理零宽字符，并在清洗生效时打诊断日志 
上一版只用 strings.TrimSpace，实测漏掉「看不见但不算 White_Space」的字符：
  cleanPath("\u200b/wp-login.php") = "/\u200b/wp-login.php"
（零宽没被删，还因为首字符不是 '/' 多补了一个斜杠，拼出更怪的路径）

改为 TrimFunc 同时匹配 unicode.IsSpace 与 U+200B/200C/200D/FEFF，且只处理首尾
—— 中间的零宽字符可能是攻击 payload，取证要保留原样。

另加诊断日志：清洗前后不一致时 WARN，用 %q 打出原始值。
测试环境出现过「记录里 path 带前导空白、本地链路却复现不出来」的情况，
不可见字符必须转义输出才定位得到。

测试：TestCleanPath 补零宽空格 / BOM / 中间零宽字符保留三个用例。
 2026-10-21 16:18:25 +08:00
tamakyi 846bb8a3d9 fix(honeypot): 清洗反代链路的脏路径，回环来源 IP 打配置告警 
测试环境实测（Cloudflare → nginx → 源站）发现两处：
1. 凭据文件里记录的 path 是 " /wp-login.php"（前导空格）；
2. 来源 IP 记成 127.0.0.1。

path：Match 内部会 TrimSpace 所以仍能命中，但落库与假表单 action 用的是原始
req.URL.Path —— 取证数据带脏字符，爆破脚本还可能把表单提交到错误路径。
新增 cleanPath(trim + 补前导斜杠，不改大小写) 在 Serve 入口清洗一次。

IP：记录到回环地址说明站点在反代后面但 [security] trust_proxy 未开启。
此时所有访客在源站眼里是同一个 IP：取证数据失去意义，且一次蜜罐封禁会
连带封掉整站（含普通访客）。新增一次性 WARN（24h 冷却），只提示不改行为 ——
本地直连调试时回环 IP 属正常。sample.ini 的 trust_proxy 段补对应说明。

测试：TestCleanPath / TestIsLoopbackIP 覆盖前导空格、制表符、空串、
无前导斜杠、大小写保持，以及 shared.LimitKey 折叠后的 "::/64" 形式。
 2026-10-21 15:54:39 +08:00
tamakyi c29e1d071f fix(honeypot): 补齐封禁装配与诱捕语义，凭据外置为文件不再入库 
一、封禁链路整条没接上（P0，已实测复现）
route.New 的 autoban.New 漏传 HoneypotEnabled/Threshold/Duration，而
RecordHoneypot 首行就是 `if !b.honeypotEnabled { return false }`
→ 蜜罐命中从不封禁、落库 banned 恒 false、IsBanned 永不为真。
同一批改动又把中间件里蜜罐路径的常规计数也跳过了，净效果是蜜罐路径
从「10 次封禁」退化为零计数零封禁 —— 是 regression 不是修复。
处理：抽 newBanner() 作为唯一装配入口并补齐参数；新增 banner_config_test
四个用例（全部经由 newBanner，不再自建 Banner）。变异验证：分别把
HoneypotEnabled 置 false、HoneypotThreshold 置 0，对应用例按预期失败。

二、诱捕语义（审计时漏掉，比上面更影响功能价值）
原实现对**所有方法**计数且阈值 1 → 扫描器 GET 一次假登录页就吃 403，
永远走不到「POST 提交账号密码」那一步，蜜罐的核心价值（拿到字典）归零。
处理：提交凭据 → RecordHoneypot（不受 enable_auto_ban 约束，立即封）；
纯探测 → 常规 Record（阈值 10）。新增 TestHoneypotProbeDoesNotBanImmediately，
变异验证：把 GET 也塞进 RecordHoneypot，测试按预期失败。

三、落库边界（实测取证，非推断）
- Path 原样落库而列宽 512 → PG `SQLSTATE 22001 值太长了(512)`，整条证据丢失；
  实测 600 字符失败、500 字符成功；
- 三处按字节截断 → `SQLSTATE 22021 无效的 "UTF8" 编码字节顺序`（中文密码/URL
  可稳定触发）。统一改 rune 截断并按列宽逐项对齐。

四、资源与噪音
- alerted 无界 map → 带 TTL 的 deduper（上限 2 万，过期清理 + 超限硬裁），
  同时承担告警 24h 冷却与纯探测落库采样（每 IP 每分钟一条）——
  GET 洪泛不再变成等量 INSERT；
- credentialKeys 去掉 id/name，普通 JSON 探测不再被误判为凭据提交并触发假告警；
- canary 从 meta generator 移到 HTML 注释，generator 伪装成 WordPress，
  不再同时向扫描器自曝「这是蜜罐」和「这站是 TamaBox」；
- serveLoginFailure 复用 WriteLoginPage，不再手抄响应头（已开始漂移）；
- Describer 死代码 → Prefixes()，接到新命令 honeypot paths；
- honeypot_paths 解析挪到 honeypot.SplitPaths（CLI 与 route 共用），
  补前导斜杠、拒绝 "/"（会让所有 404 变假登录页）。

五、凭据外置：数据库不再存用户名/密码
明文账号密码一旦入库就会跟着进备份、主从复制与任何能连库的报表工具，
事后无法彻底清除。改为：
- 新增 honeypot.CredRecord/CredStore：按天文件 creds-YYYY-MM-DD.jsonl，
  目录 0700、文件 0600、坏行跳过、PurgeBefore 只删整天过期的文件；
- db.HoneypotHit 删掉 Username/Password/Fields/RawBody，只留 HadFields 元数据；
- HoneypotStore 删掉 TopCredentials/ListSinceByIP（CLI 改读文件后零调用）；
- 新增 LegacyCredentialColumns/PurgeLegacyCredentialColumns：AutoMigrate 不删
  既有列，老库升级后历史明文仍在 → 启动 WARN + `honeypot purge-creds` 显式 DROP；
- 清理器 HoneypotRetention 增加 CredPurgeable 参数，与 DB 记录共用保留期；
  honeypot prune 也一并删过期凭据文件；
- CLI：hits 不再连库（DB 挂了也能查），stats 的凭据排行读文件；
- 配置 honeypot_cred_dir（缺省 data/honeypot-creds），.gitignore 加 /data/。

验证：go build ./... / go vet ./internal/... / go test ./...（含 PostgreSQL）全绿；
新增 credstore_test（追加/倒序/IP 过滤/坏行/Top/Purge/权限）、
TestHoneypotLegacyCredentialColumns（ADD COLUMN 模拟老库 → 检测 → DROP）、
TestHoneypotWritesCredentialsToFile；CLI 端到端手动验证 hits/--ip/--show-password。
 2026-10-21 15:43:25 +08:00
tamakyi 7d52155411 fix(honeypot): 蜜罐封禁与 enable_auto_ban 解耦 + 泄露扫描后缀匹配 
- autoban: 新增 RecordHoneypot 独立通道（不受 enabled 约束）+ 独立阈值/时长；
  IsBanned 不再因 enable_auto_ban=false 而忽略已有封禁
- honeypot: 新增 honeypotSuffixes 后缀匹配，覆盖 /backup.zip、/db.sql、/id_rsa.pem
- 新增配置 honeypot_threshold / honeypot_ban_minutes
- 补测试：autoban/honeypot_test.go、route 侧禁用自动封禁仍封禁
 2026-10-21 12:36:33 +08:00
tamakyi 79051acae8 miguan v1 2026-10-21 12:09:28 +08:00
tamakyi e9fba8b9ed theme v1 2026-10-19 15:23:11 +08:00
tamakyi bd613a6f5a fix v12 2026-10-19 01:11:28 +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 6bd90779f8 restrict v1 2026-10-18 21:14:59 +08:00
tamakyi 0e0c16f786 fix deactivate 2026-09-15 12:10:42 +08:00
tamakyi adcc42cc8c fix anwser token and database issus 2026-09-15 11:06:09 +08:00
tamakyi 8e2325eda5 aliyun sensor server 2026-09-10 18:04:19 +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