owlshells/tooling-deployment-scripts

# 工具部署脚本 [](https://github.com/owlshells/tooling-deployment-scripts/actions/workflows/ci.yml) [](https://github.com/owlshells/tooling-deployment-scripts/actions/workflows/container.yml) [](LICENSE) 用于 Kali 安全工作站的自动化部署脚本——一个适用于你本地操作的物理机，另一个适用于你远程访问的无头设备（headless box）。两者在接触真实机器之前，都会在真实的 Kali container 中进行验证。 ## 选择哪个脚本 | 脚本 | 目标 | 桌面环境 | 访问方式 | |---|---|---|---| | **`kali-deploy-physical`** | 你本地操作的物理笔记本电脑 | i3 + polybar + kitty | 仅限本地；针对不安全的局域网进行了加固 | | **`kali-deploy-remote`** | 无头设备 / 云端 teamserver | 无 | Tailscale SSH + 加固的 OpenSSH + ufw | 被取代的 Ubuntu 脚本位于 [`archive/`](archive/) 中。`SPEC.md` 包含了当前这对脚本的设计理由。 ## kali-deploy-physical 针对你携带的笔记本电脑优先采用 Kali 的部署方案：完整的工具集、i3 桌面环境，以及针对会议网络的加固。 ``` sudo ./kali-deploy-physical ``` 选项： ``` --dry-run show what would happen; change nothing --skip skip a phase (repeatable) --only run only these phases (repeatable) --list-phases print phase names --print-packages print every package the script can install --print-checked-binaries print every binary the verification pass ticks -h, --help ``` 阶段：`base tools desktop harden i3 polybar kitty shell wordlists` 重复运行始终是安全的——每个阶段都是幂等的，因此中途失败的运行可以通过再次执行来恢复（或使用 `--only` 缩小范围）。完整的运行记录会输出到 `/var/log/kali-deploy-physical-.log`。 ### 它会安装什么 工具来自 Kali 自有的 `kali-tools-*` metapackages，而不是手动列出的软件包名称列表——它们是经过精心挑选、解决了依赖关系并且在滚动更新中保持稳定的。编辑脚本顶部的 `TOOL_METAS` 即可更改范围。 包含：信息收集、漏洞、Web、数据库、密码、漏洞利用、后渗透、嗅探与欺骗、Windows 资源、逆向工程、802-11、无线、蓝牙、RFID。 不包含：`kali-tools-sdr`（gnuradio 是一个非常庞大的依赖树）。如果你需要，请将其添加到 `TOOL_METAS` 中。 `EXTRA_PKGS` 指定了 metapackages 未涵盖的内容——包括 AD 和 Web 工具（`netexec`、`mitm6`、`certipy-ad`、`enum4linux-ng`、`bloodhound.py`、`ffuf`、`gobuster`），它们*不*在 `kali-tools-*` 的闭包内。不要假设 ISO 镜像会提供它们；请参阅“测试”部分。 桌面环境是 `kali-desktop-i3`，这是一个完整的桌面环境——i3、lightdm、polybar、kitty、picom、feh、network-manager、betterlockscreen——并且 i3 session 已注册到 display manager 中。在此之上，脚本写入了从 `archive/ubuntu-autodeploy-v5` 沿用过来的 i3、polybar 和 kitty 配置。 Kali 将其*自有*的 i3/polybar/kitty 配置暂存在 `/usr/share/i3-dotfiles/` 下，并且从不将它们复制到 `$HOME` 中，因此它们不会与这些配置发生冲突。如果你想借鉴它们，值得一看。 ### 加固 针对处于不受信任局域网中且随身携带的笔记本电脑，而不是远程主机： - `ufw` 默认拒绝入站流量，已启用 - 无 SSH server（如果存在则禁用并屏蔽） - `avahi-daemon` 和 `cups`/`cups-browsed` 关闭——无 mDNS 或打印机广播 - `bluetooth.service` 关闭（蓝牙*工具*仍然安装） - NetworkManager MAC 随机化，包括扫描时和每次连接时 - 通过 `xss-lock` 在闲置 5 分钟后自动锁屏 验证阶段最后会输出一个 `ss -tulpn` 列表，列出所有实际处于监听状态的内容。请阅读该列表，而不是盲目信任那些开关状态。 **入站默认被拒绝**，因此在打开端口之前，Responder、mitm6 或 `python3 -m http.server` 将无法从局域网访问： ``` sudo ufw allow 8000/tcp # or the fw-open alias ``` ### 完成后 有些东西只能在硬件上进行检查，脚本会在最后将它们打印出来，而不是声称它们已经通过： 1. **在 LightDM 登录界面选择 i3 session。** Kali 默认是 Xfce；i3 不会自动选择。 2. 确认 polybar 正常渲染并且电池模块找到了 `BAT0`。 3. Mod 键是 **Alt**。`Mod+Return` 打开 kitty，`Mod+d` 打开 dmenu，`Mod+Escape` 锁屏。 4. 如果强制门户或 MAC 白名单网络拒绝了你的连接，那是因为 MAC 随机化——执行 `sudo rm /etc/NetworkManager/conf.d/00-macrandomize.conf`。 5. 在依赖监听模式之前先进行验证：`sudo airmon-ng start wlan0`。 ### Shell Kali 自有的 zsh 配置保持不变；脚本追加了一个由标记保护的块，其中包含 PATH、字典表变量和别名。故意*没有*安装 Oh My Zsh——Kali 已经自带了语法高亮和自动补全建议，而 OMZ 只会增加启动开销。要移除它，请删除 `~/.zshrc` 中位于 `kali-deploy-physical` 标记之间的代码块。 ## kali-deploy-remote（无头环境） 适用于你通过 Tailscale 远程访问而不是坐在前面的设备。安装没有 GUI 的 Kali 工具集，通过 Tailscale SSH 加入 tailnet 作为主要身份验证途径，将 OpenSSH 加固作为备选方案，并将入站流量限制在 `tailscale0` 接口上。 ``` sudo ./kali-deploy-remote ``` 它采用与物理机脚本相同的标志——`--dry-run`、`--skip`、`--only`、`--list-phases`、`--print-packages`、`--help`。 阶段：`base tools tailscale ssh firewall tmux shell wordlists` 环境变量选项：`TS_AUTHKEY`、`TS_ADVERTISE_TAGS`、`SSH_PUBKEY`、`SKIP_TAILSCALE=1`、`SKIP_UFW=1`。最后两个等同于 `--skip tailscale` / `--skip firewall`，保留它们是为了不破坏旧的调用方式。 除非它能证明你有其他方式登录（已安装的密钥，或 Tailscale 已经启用），否则它不会禁用密码身份验证或启用防火墙——一台自己无法登录的设备比一台开着密码身份验证的设备更糟糕。 与物理机脚本一样，它保留了 Kali 自有的 zsh 并追加了一个由标记保护的块；故意*没有*安装 Oh My Zsh 和 `agnoster` 主题。Agnoster 需要你连接*来源*的终端支持 powerline 字形，因此在未配置的环境下通过 SSH 连接时，它会显示为方块。 在交互式 SSH 登录时，你的 shell 会自动附加到 `main` tmux session 中，因此断开连接永远不会导致你的工作中断。如果你只需要一个普通的 shell——万一某天 tmux 本身出问题了——请使用 `NO_AUTO_TMUX=1` 进行连接。 完整的运行记录会输出到 `/var/log/kali-deploy-remote-.log`。 请参阅 `TMUX-TAILSCALE-CHEATSHEET.md`。 ## 测试 部署脚本很难测试，因为失败的模式是一台配置了一半的机器。`tests/` 目录会在任何脚本接触硬件之前，针对真实的 Kali container 验证**这两个**脚本： ``` tests/run-tests.sh # static analysis + container suite tests/run-tests.sh --static-only # bash -n + shellcheck only ``` 针对每个脚本涵盖以下内容：每个软件包名称都能解析到一个安装候选者，通过 `apt --simulate` 进行完整的依赖关系解析，验证阶段打勾的每个二进制文件实际上都由该软件包集提供，`--dry-run` 不会修改任何内容，配置阶段能够真实运行且具有正确的所有权，`i3 -C` / `tmux` 验证生成的配置，重复运行的幂等性，备份在重新运行后依然存在，在没有 systemd 的情况下优雅降级，SSH 和防火墙锁定防护，注入错误软件包的处理，以及参数验证。 该测试套件从 `--print-packages` 读取其软件包列表，并从 `--print-checked-binaries` 读取其预期的二进制文件列表，因此两者都不会与脚本产生不同步。 这第二个标志存在的原因是由于一个真实的 bug：物理机脚本为七个它从未安装过的工具打上了绿色的勾。其中四个（`netexec`、`bloodhound.py`、`ffuf`、`gobuster`）碰巧存在于 ISO 的 `kali-linux-default` 中，因此在标准安装上它们看起来没问题——这是运气，而不是有意为之，在进行 netinst 时就不复存在了。另外三个（`mitm6`、`certipy-ad`、`enum4linux-ng`）在任何途径下都是缺失的。在你急需使用该设备的当天，在长达 40 分钟的部署后看到一个红色的 X，这就是你原本会发现问题的方式。 需要 docker。它会拉取 `kalilinux/kali-rolling` 和 `koalaman/shellcheck`，并且不会对主机进行任何修改。 CI 会在每次 push 时运行静态检查。完整的 container 测试套件会按计划每周运行一次，并在 pull request 和手动触发时运行——Kali 是滚动发行版，因此即使这个 repo 没有任何更改，metapackage 也可能被重命名或引入新的依赖冲突，而计划任务运行能在部署之前发现这些问题。 ## 归档 `archive/ubuntu-autodeploy-v5` 是最后一个 Ubuntu 版本，也是 Kali 脚本继承的 i3 桌面和 apt 弹性助手的来源。它修复了一系列真实的 v4 部署失败问题——在 `set -e` 下，没有安装候选者的软件包导致整个 apt 批处理中止，对 venv 符号链接执行 `setcap`，对非 gzip 文件执行 `gunzip`——这就是为什么这些脚本都不使用 `set -e` 的原因。请参阅 [`archive/`](archive/) 了解完整情况。 ## 许可证 MIT — 请参阅 [LICENSE](LICENSE)。

标签：应用安全, 环境配置, 系统加固, 系统部署, 请求拦截, 运维自动化