0xCyberBerserker/aur-incident-defense-kit
GitHub: 0xCyberBerserker/aur-incident-defense-kit
面向 Arch Linux/AUR 用户的防御性事件审计工具包,用于供应链安全事件后在不破坏证据的前提下完成软件包关联分析、IOC 搜索和风险评估。
Stars: 0 | Forks: 0
# AUR 事件防御工具包
专为 Arch Linux、CachyOS 和 AUR 用户设计的防御性、非破坏性事件审计工具。
在巴塞罗那满怀热爱地为 Arch/AUR 社区打造。
## 为什么会有这个项目 AUR 供应链安全事件提醒我们,社区构建脚本本质上就是代码。`PKGBUILD` 是代码。`.install` 脚本也是代码。如果我们不加审查就直接执行它们,就等于将信任完全托付给了上游的更改。 该工具包旨在帮助用户和响应人员在确保证据不被破坏的前提下,解答首要的运维问题: - 当前安装了哪些外来/AUR 软件包? - 已安装的软件包名称是否出现在已知的受影响列表中? - 这些软件包是否在事件发生时间窗口内进行了安装、升级或重新安装? - 在 pacman 日志、安装脚本、AUR 助手缓存、npm/bun 缓存、systemd 或 eBPF 中是否存在本地 IOC? - 在采取破坏性操作之前,下一步应该审查什么? ## 快速开始 ``` git clone https://github.com/0xCyberBerserker/aur-incident-defense-kit.git cd aur-incident-defense-kit chmod +x scripts/diagnose-aur-incident.sh scripts/remediate-aur-incident.sh scripts/diagnose-aur-incident.sh --output reports/local-audit scripts/remediate-aur-incident.sh --report-dir reports/local-audit ``` 快速执行首轮排查: ``` scripts/diagnose-aur-incident.sh --output reports/fast --skip-cache-scan ``` ## 功能说明 - 使用 `pacman -Qqm` 列出已安装的外来软件包。 - 下载并标准化社区提供的受影响软件包列表。 - 将已安装的软件包名称与该列表进行交叉比对。 - 审查 `pacman.log` 中在设定时间窗口内的安装/升级/重新安装事件。 - 在 pacman 日志和软件包的 `.install` 脚本中搜索直接的 IOC。 - 搜索 AUR 助手和用户缓存,包括 yay、paru、pikaur、makepkg、npm 和 bun。 - 检查 systemd 系统/用户单元,查找可疑的持久化模式。 - 检查 `/sys/fs/bpf` 中是否存在可疑的映射(例如 `hidden_pids`、`hidden_names` 和 `hidden_inodes`)。 - 生成 `report.md`、`foreign-package-matrix.tsv` 以及证据哈希值。 - 生成一份非破坏性的修复计划。 ## 不会执行的操作 - 不执行远程脚本。 - 不使用 `curl | bash`。 - 不移除软件包。 - 不删除缓存。 - 不停止或禁用服务。 - 不轮换凭证。 ## 风险模型 - `LOW`:没有匹配受影响列表的软件包,也没有发现直接的 IOC。 - `MEDIUM`:仅有软件包名称匹配,但在事件时间窗口内没有相关事件,也没有直接的 IOC。 - `HIGH`:软件包名称匹配,且在事件时间窗口内有安装/升级/重新安装事件,但没有直接的 IOC。 - `CRITICAL`:在日志、安装脚本、严格缓存扫描、systemd 或 eBPF 中发现了直接的 IOC。 仅仅软件包名称重合并不能证明已被入侵。请综合关联软件包名称、事件时间、直接 IOC、来源、签名以及本地文件完整性进行判断。 ## 博客 / 反思 - [ES: AUR, supply chain y la confianza que no revisamos](docs/blog/2026-06-aur-supply-chain-reflection.es.md) - [EN: AUR, supply chain, and the trust we forget to review](docs/blog/2026-06-aur-supply-chain-reflection.en.md) ## npm、pnpm 与供应链规范 本项目建议在可行的情况下,为新的基于 Node 的项目考虑使用 `pnpm`。这并不是在断言 `npm` 是恶意软件。而是为了改善依赖规范:实现可重现的安装、显式的 lockfile、减少重复,并在依赖状态发生变化时提供更好的可见性。 无论使用哪种包管理器,在系统软件包安装期间引入的依赖项都属于您的安全边界范围。 ## 西班牙语文档 西班牙语 README:[README.es.md](README.es.md)标签:Arch Linux, Docker镜像, PB级数据处理, SQL, 安全运维, 库, 应急响应, 文档安全, 系统审计