docs: README v0.2.4 四轮误报标定记录 + YARA 范围文档移入 docs/
第四轮记录：逐规则独立贡献重放（60 条命中/25 条有独立贡献/前 10 条占 92.6%）、 批量按族退役零 verdict 变化、复核地板重构与复测表；另记 meshsafe-cron 自查结论与 ClamAV 签名库新鲜度机制（库龄不影响处置结果是剩余缺口）。遗留项明确 35 条零贡献规则 暂不退役的原因。YARA 检测范围文档从仓库根目录挪进 docs/。
This commit is contained in:
111
README.md
111
README.md
@@ -1,6 +1,6 @@
|
||||
# MeshSafe · 文件安全检测服务
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -171,7 +171,7 @@ MeshSafe 会**分析宏的实际行为**：
|
||||
| 可执行程序结构分析 | 异常特征、签名目录、导入表 |
|
||||
| 外部链接与二维码提取 | 文档和图片 |
|
||||
| 恶意链接库查询 | 分级处置 |
|
||||
| 零容忍规则集（15 条） | 打开即执行载体全覆盖 |
|
||||
| 零容忍规则集（25 条） | 打开即执行载体全覆盖 + 高危行为词表 |
|
||||
| 宏行为例外机制 | 合法公文模板受控放行 |
|
||||
| 引擎故障安全降级 | 任何检测引擎不可用时整体拒绝（安全优先） |
|
||||
| 同步 + 异步双模式 | 小文件同步返回，大文件异步轮询 |
|
||||
@@ -200,6 +200,113 @@ MeshSafe 会**分析宏的实际行为**：
|
||||
|
||||
## 版本历史
|
||||
|
||||
### v0.2.4 (2026-11-02)
|
||||
|
||||
**误报清零专项（现场反馈的三类误判）：**
|
||||
|
||||
真实 PPT（内嵌图表对象）、电脑上正常无病毒的 EXE/DLL、写有安装命令的 skill.md 文档，在旧策略下分别被判「中危可疑」「严重拒绝」「零容忍拒绝」。根因不是某一个规则，而是**弱信号可以靠权重堆叠越过 block_score=70**，以及**关键词/YARA 用裸子串匹配**。本轮把"载体信号"和"行为信号"彻底分档，行为如下：
|
||||
|
||||
- **文档内嵌对象分级** — `documents.py _scan_ooxml()` 不再把 zip 目录条目当成内嵌对象；对 `ppt/embeddings/*` 逐条做**魔数嗅探**：MZ/ELF/Mach-O 或 `.exe/.dll/.js/...` → `EmbeddedExecutable`（严重 75，零容忍）；Office 部件（`.bin` 里装的是 OLE/子文档）→ `EmbeddedObject`（低危 5）；其余 → 中危 20。正常 PPT 的图表/嵌入对象不再产生 20 分可疑
|
||||
- **YARA 判定改用导入表邻接窗口** — `pe.yar` 全面重写：API 名必须在**同一张导入名表内相邻 512B**才算命中（`$b in (@a[i]-512..@a[i]+512)`），导出表、i18n 资源、语言包里的字符串堆不再触发；RAT 规则要求真实 C2 痕迹（IP:端口 / .exe URL / 网关面板 php），打包器 UPX 降为 low
|
||||
- **Linux/脚本规则去恒真** — `linux.yar` 修掉 `$a and $b` 这类"两个独立字符串同时存在即命中"的恒真写法；`ettercap/responder/nmap` 加词边界并需与攻击参数成组；`LD_PRELOAD` 只在指向可写临时目录或出现 `ld.so.preload` 时命中；`C7_Misc_Ruby_Lua_ReverseShell` 需要 `exec` 与 `TCPSocket/loadstring` 同窗口
|
||||
- **PE 信号分档（不再单独定罪）** — `binary.py`：导入 API 分三档，单个注入级 API 只记 5 分（低危），≥2 个才记 20 分；`WinExec/ShellExecuteEx/CreateService/InternetOpenUrl` 从"高危"降到能力档；`IsDebuggerPresent/GetTickCount/FindWindow` 等反调试探测记 0 分；调试信息、异常时间戳 10 → 0；未签名 20 → 10
|
||||
- **YARA 严重度取 `meta.risk_level`** — 旧版只读 tag 和规则名，规则文件里的 `risk_level` 被完全忽略；现在 severity/weight 一律先取 meta，再按 `policy.yaml yara_rule_weights` 覆盖，档位统一为 **critical=85 / high=60 / medium=30 / low=10**，44 条规则全部按 meta 重新归位
|
||||
- **可执行扩展名降为"载体分"** — `DangerousExecutableExtension` 45 → 35：单独命中仍进人工复核（≥30），但不再充当把后续中低置信度信号顶过 70 分的底座
|
||||
- **关键词引擎不再无条件删换行** — v0.2.2 的"整篇文本去换行"是 `skill.md` 误报的直接原因（上一行行尾和下一行行首黏成一句话）。改为默认按行匹配，仅显式 `cross_line: true` 的规则额外跑一遍**换行压成空格**的文本（保留分隔符，兼容续行绕过，不再产生黏连）
|
||||
- **下载类词表重写 + 移出零容忍** — 新增 `RemoteDownloadExec`（下载**即执行**：`curl|sh`、`wget -O … && chmod`、`iwr|iex`、`certutil -urlcache … .exe`、`mkfifo+nc`，40 分）与 `PayloadDropToDisk`（下载落地成 `.exe/.ps1/.so/…`，45 分）；`RemoteDownloadUnix` / `RemoteDownloadPowerShell` 从"零容忍直接拒"降为 12 分信息项。裸 `curl https://…` 出现在 README/运维文档里不再拦截，内网源站另有白名单放行
|
||||
- **反弹 Shell 词表只认执行原语** — `ReverseShellNetcat` 要求 `nc|ncat|netcat` 带 `-e/-c` **且跟 shell 路径**（`/bin/`、`*sh`、`cmd.exe`），或 `/dev/tcp/`、`bash -i >&`；裸 `nc`、`nc -l`、`nc -z`（速查文档、二进制字符串表里必然出现）不再命中；英文公文里的 "NC -E" 之类缩写组合也不再误触
|
||||
- **`rules/ransom.yar` / `webshell.yar` 收尾** — 卷影删除不再接受裸 `vss` / `ShadowCopy` 子串与加密 API 同框（正常备份组件的必然组合），要求 `vssadmin … delete … shadows`；混淆 PHP 马要求存在 `<?php` 或超全局变量上下文
|
||||
|
||||
**验证结果（离线，ClamAV/DB 不在本机）：**
|
||||
|
||||
| 指标 | 修复前 | 修复后 |
|
||||
|---|---|---|
|
||||
| 32 个干净样本（系统 DLL/EXE + Git/node 工具 + 真实 PPTX）裁决 | 18 malicious/reject、14 suspicious、0 pass | **0 reject**、31 manual_review（仅因"是可执行文件"）、1 pass（PPTX 全程 0 命中） |
|
||||
| 2162 个真实 Windows 二进制 YARA 误报 | **407 条命中 / 14 条规则**（`C1_PE_Downloader_Loader` 单独 290 条，ActionCenter.dll 一类正常组件全中） | **4 条**，全部为 `C1_PE_ProcessInjection` 命中调试/注入基础设施组件（dbgeng.dll、ttdinject.exe、PayloadRestrictions.dll、VsGraphics*），属真实能力特征 |
|
||||
| 靶场 91 个恶意样本 YARA 覆盖 | 全部命中 | **全部命中，无一条漏检** |
|
||||
| 168 条样本逐条对账（同一离线管线，HEAD vs 本轮） | 124 Fail | 124 Fail，其中 2 条由 Fail 转 Pass，仅 `L5-005_injection_imports.exe` 从 reject 变为 manual_review（928B 占位假 PE，无导入表，旧结论完全靠权重堆叠），expected_verdict 已同步为 review |
|
||||
|
||||
**处置口径（本轮已确认，不再作为开放项）：**
|
||||
|
||||
- **干净 EXE/DLL 落人工复核。** 可执行文件本身是载体，单独命中 `DangerousExecutableExtension`（35 分）落在 `review_score` 区间是设计目标，不改自动放行；"严重/拒绝"只留给真实恶意特征。
|
||||
- **调试/注入基础设施组件的命中保留，不做白名单。** dbgeng.dll、ttdinject.exe、PayloadRestrictions.dll、VsGraphics* 这 4 个 Windows 组件确实具备进程注入能力，`C1_PE_ProcessInjection` 命中它们属真阳性，**维持现状**（critical=85，单条即判恶意拒绝）。**不使用 `yara_hash_whitelist` 豁免，也不在规则里判断 Microsoft 版本信息**——版本信息可伪造，任何基于它的放行都会开出一条绕过路径；这类文件本就不该走通用摆渡通道传输，如业务确有需要，由管理员单独确认后处置。
|
||||
|
||||
**容器内实测（v0.2.4 部署后，ClamAV + PostgreSQL 全部可达）：**
|
||||
|
||||
| 指标 | 结果 |
|
||||
|---|---|
|
||||
| 6 个引擎可用性 | `engine_errors` **0 条**（168 个样本全程无引擎降级） |
|
||||
| 三个原始误报复测 | `北京简介 (1).pptx` → clean/pass、0 命中（现已真正展开 61 个 OOXML 部件仍 0 命中）；`SKILL.md` → clean/pass、0 命中；干净 PE（dxdiag.exe 50 分、shell32.dll 65 分、cmd.exe 45 分）→ manual_review，均低于 `block_score=70` |
|
||||
| 靶场 168 条（控制台对账口径） | **168/168 通过**（初测 4 条未过，见下） |
|
||||
|
||||
**第二轮修补的 4 条检出缺口（容器内才暴露）：**
|
||||
|
||||
- **zip/OOXML 成员从未参与扫描（HEAD 既有缺陷）** — `extractor.py` 的成员写盘循环用 `while True: … if not chunk: break` 正常结束，`else:` 分支因此永不执行，解出来的成员一个都没进扫描队列：压缩包和 docx/xlsx/pptx 正文里的高危串全部放行。改为显式 `overflow` 标志后 `scanned_objects` 才真正大于 1；tar 分支同修（原先超限成员既不丢弃也不报，还把截断文件塞进队列）。这条修复让 `L3-015`（docx 正文的 `Invoke-WebRequest`）、`L3-023`（zip 内的 `mimikatz`）从 0 命中变检出。
|
||||
- **不可解析即放行** — 畸形 OLE 触发 olefile 内部异常后被 `documents.py` 的宽 `except` 兜成 `OleToolsUnavailable`，权重 0 → clean/pass。改为 medium/30，宏解析不了的文档一律进人工复核。
|
||||
- **换行拆分绕过** — `L3-009` 把 `Invoke-WebRequest` 拆成两行，`-OutFile evil.exe` 因跨行漏检。`RemoteDownloadExec`/`PayloadDropToDisk` 恢复 `cross_line`，并让 cmdlet 词容忍 `invoke-web_request`/换行拆分形态；仍要求"下载工具 + 执行或落地动作"同框，因此 `SKILL.md`、README 类文档保持 0 命中。
|
||||
- **裸下载命令权重回正** — 为压误报把 `RemoteDownloadPowerShell`/`RemoteDownloadUnix` 降到 12 分是矫枉过正：靶场里没有任何"期望放行"的样本含下载命令，误报源头是 `curl|wget -o 任意值` 这种松散写法而非权重。现改回 30/medium 并删掉裸 `-o` 分支，`L3-018`/`L3-024`/`L3-025` 随之回到 review。
|
||||
|
||||
**第三轮：生产日志暴露的 4 个问题（现场上传 `go1.25.0.windows-amd64.msi` / `nvidiaInspector.exe`）：**
|
||||
|
||||
- **被拒绝的文件在库里查不到记录（留痕丢失）** — `scan_tasks.real_type` 是 `VARCHAR(256)`，而这个 MSI 的 libmagic 描述串有 **632 字符**（CFB 会把 Title/Subject/Creating Application/Number of Pages 全部拼进描述）。Postgres 对超长值不是截断存储而是**整条 INSERT 报错回滚**，因此这次扫描的记录连同 3 条 `scan_findings` 一起丢失——一个 `malicious/reject` 的文件没有任何痕迹。修复三处：模型列宽 256 → 512（`app/models.py`）、线上 `ALTER TABLE scan_tasks ALTER COLUMN real_type TYPE VARCHAR(512)`（已入 `scripts/migrate.sql` 并在 meshsafe-postgres 执行）、落库前按列宽截断 `filename/declared_ext/real_type/extracted_path`（`scanner.py` 新增 `_clip()`）。外部可控长度（libmagic 串、归档成员路径、用户文件名）从此不可能再撑爆 INSERT：实测 600 字符文件名 + 900 字符 reason + 1600 字符成员路径 → 记录与 findings 全部入库（512/512/1024）。
|
||||
- **`verdict=malicious` 却给出 `open_risk.level=low`** — 同一条日志里的自相矛盾。`compute_open_risk()` 只看命中因子，不看裁决。补上裁决下限：`malicious/error/reject` 一律至少 critical，并把 `.msi/.jar/.ps1/.lnk/.hta/…` 这类真实载体扩展名纳入 `contains_executable`。
|
||||
- **`C8_Ransomware_Note_Filename` 把 Go 官方安装包判成勒索** — 单文件实测命中量：`$wallet` **76,526 次**（`1[A-Za-z0-9]{25,34}` 无边界，任何 GUID/哈希子串都算比特币地址）、`$bitcoin` **44 次**（压缩流里的 `BTC`/`Xmr` 随机字节）、`$n4` 命中安装包内字面量 `README.txt`。三者拼出 70 分 → 官方 MSI 被拒。仓库自己的 `tests/samples/index.json` 同样中招（`ransom` 是 `Ransomware` 的子串）。重写为：文件名只保留家族专有名 + 扩展名（去掉裸 `README.txt`/`_readme.txt`，`\b_readme` 不再命中 `normal_readme.txt`）；赎金语言必须是完整词组（`bitcoin address`、`send the money`、`\bransom\b note`）；地址按 base58/bech32/ Monero 真实字符集与长度并用 `\b` 锚定整个 token；条件要求**文件名 + （加密 API + 赎金语言）或（赎金语言 + 钱包地址）**。修复后 MSI 该规则 0 命中，`index.json`/`_scan_results.json` 0 命中，真勒索样本 `ransom_dropper.exe.txt` 仍命中（100 分拒绝）。
|
||||
- **`PeParseFailed` 打在非 PE 容器上** — `BINARY_EXTS` 里的 `.msi/.msp/.jar/.apk/.war/.so/.elf` 本来就不是 PE，`pefile` 解析必然抛错，于是每个合法安装包/共享库白送 10 分。新增 `_is_native_container()`：内容魔数与声明格式一致（MSI=CFB、JAR/APK=ZIP、SO/ELF=ELF）→ 不做 PE 分析。真正结构损坏的 PE（`L5-010_bad_mz.exe`、0 字节 exe、截断 exe）仍照常命中。
|
||||
- **`RemoteDownloadPowerShell` 把 .NET 标识符当下载动作** — 该词表原本是裸子串 `DownloadString|DownloadFile`，`nvidiaInspector.exe` 命中 `add_DownloadFileCompleted`、`DownloadFileAsync` 两处（任何托管程序的标识符表都有），白得 30 分，把 45 分的人工复核顶成 **75 分拒绝**。现改为：cmdlet 名（`Invoke-WebRequest`/`Invoke-RestMethod`/`Start-BitsTransfer`/`BitsAdmin`）带词边界单独命中；.NET/Win32 方法名必须与 URL/IP 同框（±40 字符）才算下载。攻击链没有削弱——`macro_alert.docm` 的 `DownloadString(http://evil.com/ps1)`、`IEX (New-Object Net.WebClient)…` 仍分别命中本规则与 `RemoteDownloadExec`。
|
||||
|
||||
**第三轮复测（容器内，策略版本 `2026.10.2-9affe243`）：**
|
||||
|
||||
| 指标 | 结果 |
|
||||
|---|---|
|
||||
| 靶场 168 条（控制台 tier 口径） | **168 Pass / 0 Fail**，`engine_errors` 0 条，总耗时 34.5s（最慢 `L0-020_zip_bomb.zip` 13.4s） |
|
||||
| `go1.25.0.windows-amd64.msi` | `malicious/reject 70` → **`suspicious/manual_review 30`**，仅剩 `DangerousExecutableExtension`；`real_type` 632 字符被截断到 512，记录 + findings 正常入库 |
|
||||
| .NET 标识符噪声（`add_DownloadFileCompleted`/`DownloadFileAsync`/`URLDownloadToFileA`） | **clean/pass，0 命中**（对应 `nvidiaInspector.exe` 由 75 拒绝回到 45 人工复核） |
|
||||
| 干净 PE 基线 | cmd.exe 45 / dxdiag.exe 50 / shell32.dll 65 → 全部 manual_review，均低于 `block_score=70` |
|
||||
| 勒索真样本 `ransom_dropper.exe.txt` | 仍 `malicious/reject 100`（`C8_Ransomware_Encryption` 85 + `VolumeShadow` 60 + `Note_Filename` 30） |
|
||||
|
||||
**ClamAV（L1）命中的处置链路与本轮两处修复：**
|
||||
|
||||
- **机制** — ClamAV 签名名是动态的（`Win.Trojan.Agent-1`、`Txt.Malware.Sustes-6779550-1`…），进不了 25 条静态零容忍名单，所以走**权重分档 + 阈值**：`critical=95 / EICAR=90 / 默认 malware=85 / heuristic·packed=70 / PUA=25`。`block_score=70` 意味着除 PUA 外**单条 ClamAV 命中即 `malicious/reject`**；PUA 档 25 分落 `pass_with_flag`，与其他信号叠加后进人工复核。零容忍名单里只显式登记了 `Eicar-Test-Signature`（等保"检测到即阻断"，`config/policy.yaml:63`），命中直接 100 分。
|
||||
- **没有绕过口子** — 步骤 -1 的两类白名单只作用于 `keywords`（关键词白名单）和 `yara`（哈希白名单）引擎，`clamav` 的 finding 不会被过滤；宏行为例外表只覆盖 VBA 零容忍规则。`engine_failure_mode: fail_closed` 下 clamd 连不上/超时会判 `error/reject`。
|
||||
- **修复一：分档实际是死代码** — `_judge_signature()` 用小写关键字去比对 `signature.upper()`，因此 95 与 70 两档永不命中，除 EICAR/PUA 外所有签名一律落默认 85（注释里的档位与真实行为不符）。关键字改为大写后实测：`Win.Ransomware/Win.Trojan/Win.Dropper`（含 `Win.Trojan.GenericKD`）→ 95 critical，`Win.Heur.Gen`/`Win.Packed.Upx`/`Win.Riskware.Tool` → 70 high，`Unix.Coinminer`（无家族关键字）→ 85 默认，`PUA-OSX.iAdWare` → 25 medium。
|
||||
- **修复二：1G~1.5G 的文件在 L1 完全裸奔** — clamd 默认 `MaxFileSize=1G`，超限拒扫时引擎返回 `ok=True + meta.skipped` 且 **0 条 finding**，而策略 `max_file_size` 是 1.5GB → 这段区间的文件其他 5 个引擎照跑，结论可以是 `clean/pass`，即"AV 没查过"被当成"AV 没查出"。现补 `ClamAVSkippedSizeLimit`（medium/30）：实测仅此一条 → `suspicious/manual_review 30`（修复前同一场景 `clean/pass 0`），与"不可扫描不放行"口径一致。
|
||||
|
||||
**第四轮：规则独立贡献数对账 + 复核地板解耦（策略版本 `2026.10.2-d3b747a4`）：**
|
||||
|
||||
- **口径** — 从 `scan_findings` 重建 findings，用 `PolicyEngine.decide()` 对近 14 天 **3,661 条真实扫描**（排除 `test`/`test_center`，其中 `console_upload` 3,586 条、真实摆渡通道 75 条）做反事实重放：逐条规则剔除其全部命中后重判，处置档位变化即该规则的独立贡献。先验证重放器可信度：改造前 **3,660/3,661 = 99.97%** 与历史入库 action 一致（唯一差异是本轮之前收紧的 `RemoteDownloadUnix`）。
|
||||
- **裁决高度集中** — 60 条有命中的规则里只有 **25 条有独立贡献**，前 10 条承担 **92.6%**（1,700/1,836 次跨档）。`DangerousExecutableExtension` 一条就贡献 1,074 次（其中 1,070 次是"把可执行文件送进人工复核"这条口径本身）；`OfficeEncrypted` 103 次走的是策略步骤 4 的加密分支而不是它的 25 分权重。35 条规则**独立贡献为 0**，分三类：同族冗余（`C8_*`/`Email*`/`Pdf*`/`PathTraversalBlocked`/`C7_..._NC` 总与另一条同批命中）、分数被挡（其余信号已 ≥70）、纯留痕（`PeParseFailed` 806 次命中、610 次连自己的档位都没到；`OoxmlParseFailed`/`OleToolsUnavailable`/`PEArchInfo` 权重 0）。
|
||||
- **退役必须按族，不能按条** — 按族只保留权重最高代表（C8 族留 `C8_Ransomware_Encryption`、Email 族留 `EmailAttachmentWebshell`、`PathTraversalBlocked`、`PdfOpenAction`、`Sustes`）在 3,661 条上重放：**90+90+92+76+76 条扫描裁决全部不变，零影响**；但把 35 条零贡献规则**同时**退役会让 258 条 reject 降级（255 条直接变 pass，全是 `.eml`/`.txt`/`.pdf`）——它们互为备份，批量删等于整族失明。`Txt.Malware.Sustes-*` 这类是 ClamAV 签名名，属于外部信号映射，不在可退役范围。
|
||||
- **结构风险修复：`manual_review` 覆盖从"注 65 分"改成"处置地板"** — 旧实现（`app/services/policy.py` 步骤 5）把评分强推到 65 再累加其余权重，同时跳过该规则自身权重：注进去的 65 分不是证据，任何 ≥5 分噪声叠加就翻成 reject，且显示分数与真实证据脱钩。现在步骤 5 只登记地板标志，步骤 6 全量累加权重，步骤 9（新增）在阈值裁决后把低于复核的处置抬到 `manual_review`（已是 reject 的不回退）。同时把 `DangerousExecutableExtension` 登记为 `manual_review` 覆盖——光闸"EXE/DLL/脚本不自动放行"从此由显式地板保证，不再依赖 `weight=30/35` 恰好等于 `review_score` 下界 30 这个数值巧合。
|
||||
- **第四轮复测：**
|
||||
|
||||
| 指标 | 结果 |
|
||||
|---|---|
|
||||
| 靶场 168 条（控制台 tier 口径） | **168 Pass / 0 Fail**，`engine_errors` 0 条，总耗时 34.6s（最慢 `L0-020_zip_bomb.zip` 12.3s） |
|
||||
| 3,661 条真实扫描重放 diff | 只有 **1 条**变化，且是本轮之前那处 `RemoteDownloadUnix` 收紧的预期结果；处置分布与改造前完全一致：reject 2,005 / manual_review 1,091 / pass 561 / pass_with_flag 4（放松 0 条降到 pass，收紧 0 条） |
|
||||
| 分数纠偏 | 14 条 `ArchiveContainsExecutable` 扫描 action 不变、分数由人为的 65 回落为真实的 30 |
|
||||
| 干净 PE 基线（实扫） | cmd.exe 45 / dxdiag.exe 50 / shell32.dll 65 → 全部 manual_review，与第三轮逐项一致 |
|
||||
| 解耦反证 | 把 `review_score` 下界抬到 36/40/50，或把 DEE 权重降到 10：无地板时干净可执行文件静默变 `pass_with_flag`（10~30 分放行），有地板时恒为 `manual_review` |
|
||||
|
||||
**meshsafe-cron 自查：定时任务自引入以来一次都没成功执行过。**
|
||||
|
||||
- **根因** — `Settings.admin_password` 是必填字段（`app/config.py:51`），但 cron 容器的 environment 里没有 `MESHSAFE_ADMIN_PASSWORD`。于是任何走 `app.db` → `get_settings()` 的路径在 import 阶段就抛 `ValidationError`，`archive_old_tasks.py --apply` 与 `VACUUM ANALYZE` 双双崩溃，`run()` 只往 docker 日志写一行 `❌ 返回码 1`，容器状态照常 `Up`——**任务挂了但没有任何存活信号**。时间线：必填字段来自初始提交 `16f134e`(10-28)，cron 来自 `da8496a`(10-29)，即从上线第一天起就没跑过。旁证：`policy_versions` 现存 10 行而归档策略是"留 5 删 5"，`scan_tasks_archive` 空表。
|
||||
- **修复一（env）** — `docker-compose.yml` cron 补 `MESHSAFE_ADMIN_PASSWORD=cron-unused-placeholder`。cron 不做控制台认证，用占位值而不是复制真实口令（容器 env 会出现在 `docker inspect` 里）。实测归档 dry-run 在 cron 容器内跑通。
|
||||
- **修复二（VACUUM 事务块）** — `run_vacuum()` 原来用 `engine.begin()` 包住 `VACUUM ANALYZE`，Postgres 直接 `ActiveSqlTransaction: VACUUM cannot run inside a transaction block`，即使 env 修好，VACUUM 仍会整批失败。改为 `engine.connect().execution_options(isolation_level="AUTOCOMMIT")`；实测 6 张表 VACUUM ANALYZE 共 0.25s 全部完成。
|
||||
- **修复三（日志泄密）** — pydantic 的 `ValidationError` 会把整个 settings dict 打进 stderr，而 `run()` 原样逐行 `log.warning`，等于把 **DB 连接串（含口令）与 `MESHSAFE_MASTER_KEY` 尾部**明文写进 cron 日志。新增 `_redact()` 按 env 值替换为 `***`（覆盖 `MESHSAFE_DB_URL/MASTER_KEY/ADMIN_PASSWORD/API_KEY/API_CLIENTS`），实测两类密钥串都不再出现在输出里。
|
||||
|
||||
**ClamAV 签名库"过期"：机制、阈值与一个真实缺口。**
|
||||
|
||||
- **"过期"不是失效** — .cvd 库不会到期停用，clamd 照样拿它扫描，结论照常产出。所谓过期只是**新鲜度告警**，两处阈值：引擎 `health()` 里 `signature_days_old > 7` → `status=degraded`（`app/engines/clamav.py:111`，硬编码），诊断规则 R002 用 `config/diagnostics.yaml:47` 的 `clamav_db_stale_days: 7` 出 WARN；控制台签名库面板显示"已 N 天"（`dashboard.html:408`）。当前库 `ClamAV 1.5.4/28166/Tue Oct 27 14:24:12 2026`，今天 6 天，**11-04 起变 8 天开始告警**。
|
||||
- **内网的更新方式只有离线导入** — `scripts/init_clamav.sh` 仅在库为空时试一次 `freshclam`，失败即静默降级；光闸环境里它注定失败。可用路径：外网下载 `main.cvd`/`daily.cvd`/`bytecode.cvd` → 摆渡进内网 → 控制台「📤 上传签名库」（`app/console.py:1487`，落 `/var/lib/clamav` 后给 clamd 发 SIGHUP 立即热加载，无需重启容器）。官方 daily 库每天发布，按周导入即可把库龄压在 7 天内。
|
||||
- **缺口（未修，需先定运维周期）** — 库龄只影响展示与诊断告警，`decide()` 完全不看 `signature_days_old`：签名库 30 天没更新时 L1 事实上认不出新病毒，文件照样可能是 `clean/pass`。这与"不可扫描内容不得放行"的口径不一致，同类先例是 `ClamAVSkippedSizeLimit`（clamd 超大小限制没查过 → 补 medium/30 进复核）。建议补 `ClamAVSignatureStale`（medium/30），阈值取**真实摆渡周期 + 缓冲**（按周导入填 10~14 天），不要直接填 7——那会让每次告警窗口把全量文件推进人工复核。
|
||||
|
||||
**遗留项（已确认，未在本轮处理）：**- `scripts/init_db.py:71` 用 `scalar_one_or_none()` 取最新策略版本，表内多于 1 行即抛 `MultipleResultsFound` → compose 注释里的"YAML 灌库"步骤在已有环境上跑不通；本轮改用 `PolicyStore.save_from_dict()` 灌库（注意 `/api/v1/policies/reload` 只刷新收到请求的那一个 worker，`UVICORN_WORKERS=8` 下仍需重启才全量生效；另外 `docker compose restart api` **不会**换用刚构建的新镜像，改了 `app/` 必须 `docker compose up -d api` 重建容器）。
|
||||
- **`allow_encrypted_archive: false` 实际未生效** — `scanner.py:391` 只在 document 引擎报 `PdfEncrypted`/`OfficeEncrypted` 时置 `encrypted=True`，压缩包侧的 `EncryptedArchive` 不触发这条策略，于是策略明令禁止的加密压缩包仍以 20 分放行（`L0-024_encrypted.zip` → pass_with_flag）。补一行即可生效，但会把所有加密包从"复核"改成"拒绝"，涉及真实业务流量，需先定口径。
|
||||
- **`ExtractMemberFailed` 权重 0** — 成员解压失败零成本，与上面同一类 fail-open。
|
||||
- **纯启发式签名单条即拒** — `Win.Heur.*`、`Win.Packed.*`、`Win.Trojan.GenericKD-*` 这类 ClamAV 启发式命中现在分别是 70/95 分，等于"AV 一家之言直接拦截"，与"干净可执行文件只进人工复核"的口径不完全一致（启发式是 AV 误报集中区）。降档需要先有内网真实误报样本做标定，否则会把真木马放到复核队列里；本轮保持拒绝。
|
||||
- **深扫成员后的耗时** — 解包递归真正生效后：PPTX（61 个对象）5.3s、8MB DLL 2.3s、zip 炸弹样本 10.7s；扫描循环上限 2000 个对象，理论上大压缩包可在同步请求里跑到分钟级，而 `sync_max_size` 现值 512MB 基本等于全部走同步。建议按实测流量把同步阈值下调（例如 20MB）或给对象数配一个更低的上限。
|
||||
- **35 条零独立贡献规则暂不退役** — 单条退役在这 3,661 条上零影响，但它们是同族互为备份（整族一起退役会让 258 条 reject 降级），退役单位是"族"不是"条"；而且本语料 97.9% 是控制台上传样本、真实摆渡通道只有 75 条、ClamAV 只在 81 条上命中，样本偏斜不足以证明这些规则在真实恶意样本上也没用。等内网积累到足量真实流量再按簇退役。
|
||||
|
||||
### v0.2.3 (2026-10-29)
|
||||
|
||||
**Bug 修复：**
|
||||
|
||||
Reference in New Issue
Block a user