B0bTheSkull/container-watch

# ContainerWatch    ## 功能简介 两种模式： - **`audit`** — 对每个正在运行的容器进行一次性扫描。可将其用作日常 cron 任务、部署前检查或基线评估。 - **`monitor`** — 实时流式监听 Docker 事件 socket，并在每个新容器启动时进行审计。可作为在工作站或构建服务器上长期运行的监控程序。 无论哪种模式，都会生成带有严重性标签的检查结果 —— 可输出供 SIEM 采集的 JSON 格式，或供人工阅读的彩色文本。 ## 检测内容 | 检查项 | 严重性 | 为什么重要 | |---|---|---| | `--privileged` 容器 | critical | 相当于拥有主机上的 root 权限 | | 挂载了 Docker socket (`/var/run/docker.sock`) | critical | 容器可以控制 Docker 守护进程 —— 可通过 `docker run` 逃逸 | | 绑定挂载了 `/`、`/etc`、`/proc`、`/sys`、`/root`、`/var/lib/docker` (rw) | high | 可以读取或修改主机状态 | | 相同挂载 (ro) | medium | 虽为只读，但仍会泄露敏感信息 | | `--pid=host` | high | 可以查看并向主机上的每一个进程发送信号 | | `--network=host` | high | 绕过容器网络隔离 | | `--cap-add SYS_ADMIN`、`NET_ADMIN`、`DAC_*`、`SYS_PTRACE` 等 | high | 除非有充分理由，否则绝不应添加这些 Capabilities | | `--security-opt seccomp=unconfined` | high | 禁用了 syscall 过滤 | | `--security-opt apparmor=unconfined` | high | 禁用了 AppArmor MAC | | 暴露了 `2375/tcp` 端口 | critical | 未启用 TLS 的 Docker API —— 通常属于意外暴露 | | 容器进程以 root 身份运行 | medium | 除非确有必要，否则应使用 `--user` 降低权限 | 检查结果会按严重程度从 critical 到 low 排序，并标记容器名称。 ## 安装说明 ``` git clone https://github.com/B0bTheSkull/container-watch.git cd container-watch pip install -e . ``` 你需要具有访问 Docker 守护进程 socket 的权限 —— 请以属于 `docker` 用户组的用户身份运行，或使用 `sudo`。 ## 用法 ### 审计正在运行的容器 ``` container-watch audit ``` ### 审计已保存的 inspect 文件（离线模式 —— 适用于 CI / 排查分析） ``` docker inspect $(docker ps -q) > snapshot.json container-watch audit --offline --inspect-file snapshot.json ``` ### JSON 输出 ``` container-watch audit --json > findings.json ``` ### 实时监控 ``` container-watch monitor ``` 持续追踪 Docker 事件流，并在每个新容器启动时进行审计。可以将其配置为 `systemd` 服务，部署在构建服务器或经常运行容器的工作站上。 ### 退出码 | 代码 | 含义 | |---|---| | `0` | 没有 critical 或 high 级别的检查结果 | | `1` | 至少发现一个 critical 或 high 级别的问题 | | `2` | 配置 / 连接错误 | ## 示例输出 ``` ContainerWatch Containers inspected: 6 | Findings: 11 ──────────────────────────────────────────────────────────────────────── [CRITICAL] privileged_container (privileged-tool) container started with --privileged — equivalent to root on the host ──────────────────────────────────────────────────────────────────────── [CRITICAL] sensitive_mount (dind-runner) bind-mount of /var/run/docker.sock (rw) — container can drive the Docker daemon ──────────────────────────────────────────────────────────────────────── [CRITICAL] docker_api_exposed (exposed-docker-api) port 2375/tcp mapped — looks like Docker API exposed without TLS ──────────────────────────────────────────────────────────────────────── [ HIGH] dangerous_capability (host-net-tool) --cap-add NET_ADMIN — can manipulate host networking from inside the container ──────────────────────────────────────────────────────────────────────── [ HIGH] net_host (host-net-tool) --network=host — container shares the host network stack ──────────────────────────────────────────────────────────────────────── ... Summary: [CRITICAL] 3 [ HIGH] 5 [ MEDIUM] 3 ``` ## 开发动机 容器安全在很大程度上就是*配置*安全。真正有影响的攻击通常不是针对运行时的 CVE，而是配置失误，比如遗忘了 `--privileged`、将 `docker.sock` 挂载到了 CI 运行器中，或者为了图方便在 homelab 的 compose 文件里使用了 `network: host`。虽然 Falco、Trivy 和 Docker Bench 等工具能捕获大多数此类问题，但它们相对笨重。 ContainerWatch 体积小巧，足以让人在闲坐时快速读完，可以在任何可达的 Docker 守护进程上运行，并且能与我的其他检测工具组合完美配合。检查结果会直接输出为 JSON 格式，随时准备转发给 [LogHound](https://github.com/B0bTheSkull/loghound) 或任何 SIEM。 ## 路线图 - [ ] 镜像层扫描（识别使用了已知漏洞基础镜像的 FROM 指令） - [ ] Docker Compose 文件静态扫描（在运行前捕获错误配置） - [ ] Kubernetes 模式（基于 Docker 处理 Pod / DaemonSet / StatefulSet 规范） - [ ] 用于 Slack / Discord 告警的 Webhook 输出 - [ ] `--baseline` 模式 —— 与已保存的正常状态进行对比，仅对差异发出告警 - [ ] Sigma 格式的检测规则包（以便 [SigmaForge](https://github.com/B0bTheSkull/sigmaforge) 可以进行转换） ## 许可证 MIT — 查看 [LICENSE](LICENSE)

标签：CISA项目, Cloudflare, DevOps安全, DevSecOps, Docker API暴露, Docker安全, MITRE ATT&CK, Python, SIEM集成, Web截图, Web报告查看器, 上游代理, 事件监控, 安全告警, 安全基线检查, 容器安全, 容器逃逸检测, 容器配置核查, 无后门, 特权容器检测, 系统防护, 网络安全, 运行时安全监控, 逆向工具, 隐私保护