thelovedevil/gentoo-automation-lab

# gentoo-automation-lab **基于 Ansible 驱动的流水线，在本地 QEMU/KVM 构建炉中烘焙出一个可移植、经过安全加固的 Gentoo Linux 镜像 —— 开箱即可用于全盘加密的裸机部署。** ## 架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ BUILD HOST (WSL2/Linux) │ │ │ │ ansible-playbook ──SSH:2222──► QEMU/KVM Guest (4GB / 4 vCPU) │ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Stage A (ISO-driven) Stage B (installed OS) │ │ │ │ ┌──────────────────┐ ┌─────────────────────┐ │ │ │ │ │ 1. GPT + UEFI │ │ 6. CLI utilities │ │ │ │ │ │ 2. stage3 fetch │ reboot │ 7. Networking/VPN │ │ │ │ │ │ 3. Portage sync │ ────────► │ 8. Desktop (bspwm) │ │ │ │ │ │ 4. Kernel build │ │ 9. Emacs + LSP │ │ │ │ │ │ 5. GRUB UEFI │ │10. LLM runtime │ │ │ │ │ └──────────────────┘ │11. Offensive tools │ │ │ │ │ │12. Dotfiles │ │ │ │ │ │13. TOMOYO hardening │ │ │ │ │ └─────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ Phase 2 (metal): flash to SSD ──► LUKS encrypt ──► tune │ └─────────────────────────────────────────────────────────────────┘ ``` ## 为什么会有这个项目 标准的 Gentoo 安装是一个手动、易错且耗时的过程。本项目用一个**确定性的双阶段 Ansible 流水线**取代了它，该流水线能够： - 在 QEMU/KVM 构建炉中构建一个可以在*任何*现代 x86-64 硬件上启动的**可移植镜像**（`-march=x86-64-v3`） - 提供一个**完整的攻击性安全工作站**，包含跨越四个安装层级（portage、Go、Rust、pip）的 30 多种工具 - 部署一个 **LLM 编排运行时**（LangChain/LangGraph + 通过 llama.cpp 进行本地推理） - 从首次启动起即应用**强制访问控制**（TOMOYO）并进行 SSH 加固 - 支持在 Phase 2 通过就地 LUKS2 加密**迁移**至裸机 ## 核心硬性约束 这些约束确保了同一个镜像既能同时在 QEMU 构建炉中启动，也能在任何目标硬件上启动： | 约束条件 | 原因 | |---|---| | 仅限 `-march=x86-64-v3`，绝不使用 `-march=native` | 确保二进制文件可移植；原生特性调优是 Phase 2 的附加步骤 | | GPT + UEFI + 真实的 ESP | ESP 可以原样迁移至物理机；GRUB `--removable` 能够引导任意的固件 | | fstab/bootloader 基于 `PARTUUID`/`UUID` 挂载 | 设备名在不同硬件上会发生变化（`vda` → `nvme0n1` → `sda`）；Phase 2 会对 LVM 卷使用 UUID | | 内核 + initramfs 同时包含 virtio 和物理机驱动 | `dracut --no-hostonly` 构建包含 NVMe、AHCI 和常见网卡的通用 initramfs | | OpenRC + 最小化的 USE flags | 保持干净的初始状态；极小的攻击面 | ## Roles ### Stage A — 烘焙（由 ISO 驱动，chroot 进入空磁盘） | Role | 功能说明 | |---|---| | `partition` | 通过 sgdisk 进行 GPT 分区：512M ESP (vfat) + root (ext4)，捕获 PARTUUID | | `stage3` | 获取最新的 stage3 tarball，进行 GPG 签名验证，并解压 | | `portage` | 配置 make.conf、repos.conf，bind-mount 伪文件系统，执行 `emerge-webrsync` | | `kernel` | 发行版内核（`gentoo-kernel`）+ 配置片段（TOMOYO、网络调整参数、双驱动内置），dracut 通用 initramfs | | `bootloader` | GRUB UEFI `--removable`，基于 PARTUUID 的 fstab，启用 dhcpcd+sshd，设置 root 凭证 | ### Stage B — 环境配置（启动已安装的 OS，通过常规 SSH） | Role | 功能说明 | |---|---| | `cli` | tmux, ripgrep, fd, jq, htop, bash-completion | | `networking` | WireGuard, Tor, proxychains, OpenVPN, socat, tcpdump, Wireshark (CLI), curl | | `desktop` | Xorg (modesetting), bspwm, sxhkd, sakura, picom, polybar, dmenu, fonts | | `editor` | Emacs (X11 GUI) + clangd (C/C++ LSP) + pylsp (Python LSP) + libvterm | | `runtime` | 包含 LangChain, LangGraph, Anthropic SDK, Ollama, llama-cpp-python (CPU) 的 Python 3.13 venv | | `offensive` | **Portage:** nmap, masscan, nikto, hydra, hashcat, sqlmap · **Go:** nuclei, httpx, subfinder, katana, ffuf, gobuster, dalfox, puredns, dnsx · **Rust:** feroxbuster, rustscan · **Pip:** arjun · **Git:** SecLists | | `dotfiles` | Emacs 文学编程配置 (Org-mode)，自定义主题，工具配置（侦察扫描器配置） | | `hardening` | TOMOYO MAC（首次启动为学习模式），sshd 锁定（提供公钥时强制仅使用密钥） | ### Phase 1.5 — 刷写前加固 (`phase1_5_harden.yml`) 在刷写到物理机之前应用 —— 最大化可移植的部分： | 领域 | 内容 | |---|---| | Browser | LibreWolf（通过 overlay 获取的注重隐私的 Firefox 分支） | | Desktop | bspwm 主题（自定义调色板，picom 85-92% 半透明，kawase 模糊，polybar），sxhkd 快捷键，Xresources 终端颜色，GTK 深色主题 | | Firewall | nftables 基线配置（默认拒绝 input，限制 SSH/ICMP 速率，记录丢弃的包） | | Kernel hardening | 保留 s ask on interview 以保护隐私 vsyscall=none) | | DNS privacy | DNS-over-TLS 解析器 (stubby) | | Security tools | lynis（审计），firejail（沙盒），doas（极简 sudo），gnupg | | Shell | 自定义 .bashrc，包含工具别名、历史记录加固、PATH 配置 | | Network prep | Ansible 控制节点，针对 FreeBSD/pfSense 目标的 SSH 配置 | | LLM prep | Ollama OpenRC init 脚本，环境变量 | ### Phase 2 — 物理机部署 | Role | 功能说明 | |---|---| | `luks` | 就地 LUKS2 + LVM 加密：备份 rootfs → `cryptsetup luksFormat` (AES-XTS-512, argon2id) → LVM (root + swap + home) → 恢复 → dracut crypt+lvm 模块 → 带有 LVM 支持的 GRUB `cryptodisk` | ## 项目结构 ``` ├── ansible.cfg ├── inventory.ini # QEMU guest (localhost:2222) ├── inventory_metal.ini # Phase 2 metal target ├── group_vars/ │ └── all.yml # Single source of truth (all tunables) ├── stage_a_bake.yml # Stage A playbook (ISO → installed OS) ├── base_provision.yml # Stage B playbook (provision the OS) ├── phase1_5_harden.yml # Pre-flash hardening (desktop, firewall, etc.) ├── phase2_luks.yml # Phase 2 LUKS + LVM encryption ├── stage_a_resume.yml # Resume Stage A (skip partition/stage3) ├── stage_a_bootloader.yml # Re-run bootloader only ├── roles/ │ ├── partition/ # GPT + format + PARTUUID │ ├── stage3/ # Fetch + GPG-verify + unpack │ ├── portage/ # make.conf + chroot + webrsync │ ├── kernel/ # Distribution kernel + dracut │ ├── bootloader/ # GRUB UEFI + fstab │ ├── cli/ # Shell utilities │ ├── networking/ # VPN + anonymity + packet tools │ ├── desktop/ # bspwm + Xorg + compositor │ ├── editor/ # Emacs + LSP │ ├── runtime/ # Python + LLM stack │ ├── offensive/ # 4-tier offensive toolchain │ ├── dotfiles/ # Editor + tool config deployment │ ├── hardening/ # TOMOYO + sshd │ └── luks/ # Phase 2 LUKS encryption ├── templates/ │ ├── make.conf.j2 │ ├── fstab.j2 │ └── dracut.conf.j2 └── scripts/ ├── create-disk.sh # qemu-img create ├── boot-installer.sh # Boot ISO (Stage A) └── boot-installed.sh # Boot installed OS (Stage B / testing) ``` ## 核心设计决策 ### 双阶段拆分 Ansible 需要 SSH 访问权限，但全新的空磁盘没有操作系统。Stage A 在 QEMU 中启动 Gentoo 最小化 ISO（该镜像自带 sshd），然后 Ansible 通过 chroot 驱动整个安装过程。Stage B 重启进入已安装的系统并正常进行环境配置。 ### 四层攻击性工具链 并非所有的安全工具都在 Gentoo 的 portage 树中。`offensive` role 按顺序从四个来源进行安装： 1. **Portage** — nmap, hydra, hashcat, sqlmap, masscan, nikto（稳定且受维护） 2. **Go** — ProjectDiscovery 套件 (nuclei, httpx, katana, subfinder), ffuf, gobuster（从源码获取最新版） 3. **Rust** — feroxbuster, rustscan（通过 `cargo install`） 4. **Pip** — arjun，专用的 Python 工具（在隔离的 venv 中） ### LLM 运行时 该镜像自带一个包含了完整 LangChain/LangGraph 技术栈以及用于本地推理的 llama-cpp-python 的 Python venv。GPU 加速（CUDA）被推迟到 Phase 2，即在带有专用 GPU 的物理机上运行时进行。该架构将编排层（可移植）与计算后端（特定于硬件）分离开来。 ### LUKS Phase 2 加密是一个部署时关注的问题，而不是构建时的。Phase 2 LUKS playbook 在目标磁盘上执行就地加密：备份 → 加密 → 恢复 → 使用 `crypt` 模块重建 initramfs → 配置 GRUB `cryptodisk`。这避免了在虚拟机构建周期中出现密码提示，同时确保了生产环境的部署是完全加密的。 ### 内核配置 为了可移植性，使用了发行版内核（`gentoo-kernel`）。一个配置片段合并了 TOMOYO LSM、高级网络参数（策略路由、conntrack、qdiscs、netns），并将 virtio 和物理机存储/NIC 驱动程序作为内置模块。Phase 2 会切换到 `gentoo-sources` 以进行手动定制的内核调优。 ## 经验总结 - **内核编译期间的 OOM**：在配置了 `-j5` 的 4GB 内存虚拟机中，Intel ICE 驱动会导致 `cc1` 被 OOM-killer 杀死。修复：添加 2GB swap + 修改为 `-j3` - **LLVM/Clang 编译时间**：在具有 4 个 vCPU 的嵌套 KVM 中大约需要 5 小时。Ansible 的异步超时（即使在 4 小时时）也是不够的 —— 重型的 emerge 任务直接在客户机内部运行 - **Gentoo 软件包命名**：Kali/Debian 的软件包名称无法与 portage atom 实现 1:1 映射（例如，`john` → `app-crypt/johntheripper-jumbo`，`proxychains` → `net-misc/proxychains`） - **~amd64 masking**：大多数攻击性安全工具在 Gentoo 稳定版分支中需要设置 `ACCEPT_KEYWORDS="~amd64"` - **USE flag 级联**：启用 `X` 会触发传递依赖（freetype 需要 harfbuzz，zlib 需要 minizip，xmlto 需要 text） —— 请在执行大型 emerge 运行之前预先配置 `package.use` ## 前置条件 ``` # QEMU/KVM + OVMF UEFI firmware sudo apt install -y qemu-system-x86 qemu-utils ovmf sudo usermod -aG kvm "$USER" # re-login required # Ansible pip install ansible # 验证 [ -r /dev/kvm ] && echo "KVM ready" ``` ## 使用方法 ``` # 1. 创建磁盘镜像 scripts/create-disk.sh # 2. 下载 Gentoo minimal ISO # （来自 https://www.gentoo.org/downloads/） # 3. Stage A — 烘焙基础镜像 scripts/boot-installer.sh install-amd64-minimal-*.iso # 在串口控制台中：设置 root 密码，启动 sshd ansible-playbook -i inventory.ini stage_a_bake.yml -e ansible_ssh_pass= # 4. 重启进入已安装的 OS scripts/boot-installed.sh # 5. Stage B — 完整配置 ansible-playbook -i inventory.ini base_provision.yml -e ansible_ssh_pass= # 6. Phase 2 — 刷入 SSD 并加密（在 metal 上，从 live USB） qemu-img convert -O raw gentoo_staging.qcow2 /dev/sdX ansible-playbook -i inventory_metal.ini phase2_luks.yml \ -e luks_target_disk=/dev/sdX \ -e luks_passphrase= ``` ## 技术栈 Ansible · QEMU/KVM · OVMF (UEFI) · Gentoo Linux · OpenRC · GRUB2 · dracut · TOMOYO · LUKS2/cryptsetup · bspwm · Emacs · LangChain · LangGraph · Python · Go · Rust · Portage ## License MIT

标签：Ansible, DLL 劫持, Gentoo Linux, LUKS加密, QEMU/KVM, 大语言模型, 渗透测试系统, 系统加固, 系统提示词, 自动化运维, 逆向工具