kali-linux

Kali Linux：Kali 管理、工具和实验室工作流

Kali 基于 Debian，但常见问题通常都与 Kali 特有的方面有关：分支混用、元软件包泛滥、镜像过时、持久化配置错误、硬件边缘情况，或是用错工具系列。

管理 Kali Linux 时，不要把它简化成普通 Debian，也不要把它当成一堆攻击工具。首先确认你实际使用的是哪种 Kali 环境——滚动安装、最新快照、Live USB、VM 镜像、Purple 镜像、NetHunter，还是临时实验室主机——然后分别处理基础操作系统健康状况、工具选择、分支规范、硬件支持和测试范围。

目标版本（已于 2026 年 10 月验证）：

仅当版本号或日期锚点会实质影响兼容性或故障排查方式时，才在此处固定记录。对于常规软件包操作，应优先参考当前分支和仓库状态，而不是过时的软件包表格。

组件	版本或日期	重要性
当前有日期标记的 Kali 镜像版本	2026.3	当前镜像基准和发行说明
分支文档	2026 年 10 月重新检查／实时验证	分支行为和安全的环境选择比单个软件包版本更重要
元软件包文档	2025-07／实时验证	工具系列分组和安装范围比记住某个软件包列表更重要
Kali 2026.3 内核系列	7.1.5	镜像发行版的硬件和驱动预期基准

适用场景

• 在 Kali 上使用 apt、dpkg、apt-cache 进行软件包管理、仓库健全性检查、密钥环管理或分支验证
• Kali 镜像和安装相关问题：Live ISO、netinst、ARM 和 SBC 镜像、VM 镜像、持久化和恢复
• Kali 分支和软件源列表相关问题：kali-rolling、kali-last-snapshot、选择性使用分支以及镜像源规范
• 元软件包规划：kali-linux-default、kali-linux-everything、专用的 kali-tools-* 套件、桌面元软件包和 kali-tweaks
• 在误装半个仓库的软件包之前，为任务选择合适的 Kali 工具系列
• Kali 桌面和笔记本电脑相关工作：Xfce、GNOME、KDE、i3、PipeWire、GPU 驱动、抓包工具和 VM 客户机行为
• 无线、SDR、Bluetooth、RFID、HID、USB 以及攻击硬件支持问题，实际根源在于 Kali 主机或软件包
• NetHunter 和移动设备相关的 Kali 问题，其根源在于镜像、软件包、内核或主机工具配置，而非利用技术
• 安全的实验室搭建、故意存在漏洞的练习目标、快照工作流，以及实验室系统与生产系统的隔离
• 在 Kali 特有的仓库、分支、镜像或工具背景比通用 Debian 建议更重要时，处理 Kali 上的基础 Linux 运维

不适用场景

• 没有 Kali 特定背景的通用 Debian、Ubuntu、Mint 或 Pop!_OS 管理——使用 debian-ubuntu
• Arch、CachyOS 或 EndeavourOS 管理——使用 arch-linux
• Fedora、RHEL、Rocky 或 AlmaLinux 管理——使用 rhel-fedora
• NixOS 或声明式 Nix 配置——使用 nixos
• Shell 语法、引号处理或脚本可移植性——使用 shell-scripting
• 网络架构、DNS、VPN、反向代理或防火墙设计——使用 networking
• Docker、Podman、镜像构建或容器运行时问题——使用 docker
• 故障明显发生在 Kali 客户机之外的虚拟机监控程序配置、直通连接或 VM 平台问题——使用 virtualization
• Kubernetes 集群或清单相关工作——使用 kubernetes
• 通过 playbook 进行全机群 Linux 配置——使用 ansible
• 针对真实目标的漏洞利用、权限提升、横向移动或利用后活动——使用 privilege-escalation
• 新型漏洞挖掘、深度逆向工程、模糊测试或概念验证研究——使用 vulnerability-research
• 防御性加固、漏洞分级处理或全面安全审查——使用 security-audit
• OPNsense 或 pfSense 设备相关工作——使用 opnsense-pfsense

---

AI 自检

在返回 Kali 命令或工具建议之前，请确认：

• 已识别 Kali 类型：滚动版安装、last-snapshot、Live USB、VM 镜像、Purple 镜像、NetHunter 或自定义实验室设备。不同类型的建议很快就会出现差异。
• 没有将其简化为纯 Debian：未经检查 Kali 分支、元软件包和软件包来源之前，不要给出通用 Debian 建议。
• 已了解分支模型：kali-rolling、kali-last-snapshot，以及 kali-experimental、kali-bleeding-edge 和 kali-dev 等部分或开发分支。不要随意混用。分支、快照、元软件包和 NetHunter 相关建议应符合官方文档。
• 软件源状态正常：没有盲目添加 Debian 软件源、沿用过时的镜像假设、损坏的 kali-archive-keyring，也没有互相矛盾的软件源列表。
• 升级路径合理：在 Kali 上，如果软件包转换很重要，优先使用 apt update 和 apt full-upgrade。不要照搬 apt upgrade 后就认为大功告成。
• 已识别镜像模式：已安装系统、Live 媒体、带持久化存储的 Live 媒体、VM 镜像或移动设备镜像。恢复步骤各不相同。
• 有意选择元软件包范围：如果合适的答案是精简的 kali-tools-* 工具包，就不要建议安装 kali-linux-everything。
• 工具系列与任务相符：信息收集、漏洞评估、Web、密码、无线、逆向工程、漏洞利用、后渗透、取证、报告或实验室。
• 遵守授权边界：Kali 工具建议仍须限定在授权范围内。工具索引不代表获得许可；攻击性工具只能用于授权实验室、CTF 或自有系统。
• 将实验室软件包视为有意设置的易受攻击软件：kali-linux-labs 用于受控练习，不适合日常工作站安装。
• 无线和硬件方案切实可行：芯片组、固件、监听模式、注入支持、SDR 软件栈、USB 直通和内核模块均应与实际硬件相符。
• GPU 和采集软件栈配置合理：在归咎于工具之前，先确认 VM 直通、主机加速、PipeWire、浏览器采集和桌面会话彼此兼容。
• 没有将 NetHunter 当作普通桌面版 Kali：移动设备内核、Android 主机限制、无 root 与完整 chroot 的形态，以及缺少 systemd 风格的工具，都可能影响哪些检查适用。
• 选择了正确的交接目标：将立足点后的权限提升或相关授权路径交由 privilege-escalation。将原始漏洞发现工作交由 vulnerability-research。
• 没有屏蔽诊断错误：对于错误原因很重要的命令，不要用 2>/dev/null 隐藏有用的失败输出。收集信息时使用 2>&1 || true。
• 已应用跨领域 Agent 卫生规范——参见 references/agent-hygiene.md

---

工作流

以下步骤按顺序排列。复制此清单并跟踪进度：

• 步骤 1：识别 Kali 类型
• 步骤 2：收集当前状态
• 步骤 3：加载匹配的参考资料
• 步骤 4：一次更改一层；先确认影响重大的更改
• 步骤 5：验证（失败时，修复并返回步骤 4）

步骤 1：先确定 Kali 使用场景

使用场景	默认建议	需要注意的变化
已安装的 Kali rolling	大多数用户的默认选择	持续更新，软件包漂移很重要，仓库管理是重中之重
Kali last-snapshot	更安全、更固定的使用场景	不同版本快照之间的行为类似正式发行版
Live ISO / live USB	首先将其视为临时环境	持久化、覆盖层状态和存储布局会影响恢复方式
VM 镜像	检查客户机工具和虚拟机监控程序相关假设	共享剪贴板、显示、USB 直通和虚拟网卡的特殊问题都很重要
ARM / SBC 镜像	首先检查特定开发板的镜像相关假设	启动固件、存储介质、外设和软件包预期与 amd64 安装有所不同
Kali Purple 镜像	带有蓝队风格的安全发行版	软件包组合和镜像选择与标准红队工作站有所不同
NetHunter	对移动设备和内核较为敏感	Android 主机、自定义内核、HID 和无线支持都会影响解决方案
部分更新或使用开发分支的用户	立即放慢操作	kali-experimental、kali-bleeding-edge 和 kali-dev 并非适合随意使用的默认选项

步骤 2：收集当前系统状态

从最小范围开始，只有在故障所在层仍不明确时才扩大检查范围。

所有 Kali 情况的基线检查：

cat /etc/os-release
uname -r
find /etc/apt -maxdepth 2 -type f \( -path /etc/apt/sources.list -o -path '/etc/apt/sources.list.d/*.list' -o -path '/etc/apt/sources.list.d/*.sources' \) \
  -exec grep -HnEv '^[[:space:]]*(#|$)' {} +
apt-cache policy 2>&1 || true
apt-cache policy kali-archive-keyring kali-defaults kali-linux-core kali-linux-default 2>&1 || true
apt list --upgradable 2>&1 | tail -n +2
findmnt /
lsblk -f
dpkg -l | grep '^ii  kali-' | head -40

仅在任务需要时添加子系统探测。在 NetHunter 或其他与移动设备相关的环境中，跳过不存在的桌面环境或特定于 systemd 的探测。

# services and logs
ps -p 1 -o comm=
command -v systemctl >/dev/null 2>&1 && systemctl --failed 2>&1 || true
command -v journalctl >/dev/null 2>&1 && journalctl -b -p warning..alert 2>&1 || true

# boot and storage
findmnt /boot 2>&1 || true
findmnt /boot/efi 2>&1 || true

# desktop and capture path
echo "Session=$XDG_SESSION_TYPE Desktop=$XDG_CURRENT_DESKTOP"
loginctl list-sessions 2>&1 || true
systemctl status display-manager 2>&1 || true
systemctl --user --failed 2>&1 || true
systemctl --user status pipewire pipewire-pulse wireplumber xdg-desktop-portal 2>&1 || true
command -v wpctl >/dev/null 2>&1 && wpctl status

# hardware, wireless, GPU, and NetHunter
lspci -k | grep -Ei 'vga|3d|display|network|wireless'
lsusb
rfkill list 2>&1 || true
iw dev 2>&1 || true
journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true
command -v dkms >/dev/null 2>&1 && dkms status 2>&1 || true
command -v airmon-ng >/dev/null 2>&1 && airmon-ng 2>&1 || true
command -v nethunter >/dev/null 2>&1 && nethunter -h 2>&1 | head -20

步骤 3：仅加载相关参考资料

任务类型	参考资料
apt、软件源、密钥环、rolling 与 snapshot、镜像站	references/packages-branches-and-repos.md
选择元软件包并了解 Kali 工具系列	references/metapackages-and-tool-families.md
Live USB、持久化、安装程序、VM 镜像、恢复	references/images-live-persistence-and-recovery.md
无线、GPU、SDR、USB、Bluetooth、NetHunter、硬件支持	references/wireless-gpu-hardware-and-nethunter.md
范围纪律、易受攻击的实验室、快照、安全实践	references/lab-safety-and-scope.md
反复出现的 Kali 故障模式和边缘情况	references/gotchas-and-special-situations.md

默认情况下不要加载所有参考资料。选择与故障模式相匹配的资料，只有在第一层检查无误时才扩大范围。

步骤 3.5：留在此处还是转交

请求类型	路由
在 Kali 上安装、软件包、镜像、持久化、硬件或工具系列选择	留在 kali-linux
虚拟机监控程序配置、USB 直通、客户机显示加速或 VM 平台连接配置	使用 virtualization
在已获授权的目标上利用漏洞、横向移动、提升权限或运行后渗透工作流	使用 privilege-escalation
模糊测试、深入逆向工程、寻找新漏洞或构建 PoC	使用 vulnerability-research
审查目标代码或服务，查找防御方面的问题	使用 security-audit
没有 Kali 特定背景的通用 Debian 系主机管理	使用 debian-ubuntu

第 4 步：一次只更改一个层

• 在调试可能只是缺失或不匹配的工具前，先修复软件源列表和软件包状态。
• 在断定 Live USB 已损坏前，先修复镜像或持久化布局。
• 在归咎于 Burp、Wireshark 或浏览器工具前，先修复桌面会话和捕获相关配置。
• 在归咎于监控模式、注入、SDR 或 Bluetooth 工具前，先修复硬件支持和固件。
• 选择与工作流匹配的最小元软件包，而不是全部安装。
• 将实验环境与生产环境分开。优先使用快照、一次性 VM 和隔离的 USB 媒体。
• 在进行重大升级、GPU／无线驱动操作或 Live 持久化更改前创建快照。

有重大影响的更改（会移除软件包的 full-upgrade、分支或软件源列表更改、大型元软件包安装或移除、写入或重新分区 USB 媒体、内核和 DKMS 驱动操作）：展示确切命令及其操作内容（模拟事务、软件源列表差异或目标设备），获得明确确认后再执行，然后进入第 5 步。在无人值守运行中，停在计划阶段。确切命令见 references/packages-branches-and-repos.md（升级、分支恢复）和 references/images-live-persistence-and-recovery.md（Live USB 和持久化）。

第 5 步：结束前进行验证

apt-cache policy package_name
command -v systemctl >/dev/null 2>&1 && systemctl status unit_name 2>&1 || true
journalctl -u unit_name -b 2>&1 || true
dpkg -l | grep '^ii  kali-' | head -20
command -v msfconsole 2>/dev/null || true
command -v nmap 2>/dev/null || true
command -v aircrack-ng 2>/dev/null || true

如果检查失败，修复它所指向的层，然后返回第 4 步。只有在弄清启动路径、持久化情况或内核更改，并且至少有一种已知可用的恢复方式后，才重新启动。

---

故障排查模式

保持跨层排查，按部就班：

1. 确认 Kali 所属版本线、分支、镜像类型和软件源状态。
2. 找出故障所在层：软件包、镜像或持久化、桌面会话、硬件或工具选择。
3. 更改配置前，先收集合适的日志。
4. 一次只更改一个层，然后重新测试。
5. 将范围和安全性与工具安装分开处理。

核心日志检查：

journalctl -b -p warning..alert
journalctl --user -b
dmesg --level=err,warn
journalctl -u unit_name -b 2>&1 || true

需要关联分析而非初步精准定位时，可进行广泛的模式扫描：

journalctl -b | grep -Ei 'nvrm|nvidia|amdgpu|i915|xe|ath|iwlwifi|brcm|rtl|mt76|drm' 2>&1 || true
journalctl --user -b | grep -Ei 'portal|pipewire|webrtc|burp|wireshark' 2>&1 || true

如果问题看起来像是“Kali 坏了”，先检查这些常见原因：

• 软件源列表漂移或密钥环过时
• 混用不同分支
• 在性能较弱的硬件上安装大型元软件包
• USB 直通或监控模式预期超出芯片组能力
• Live USB 持久化损坏
• VM 来宾附加组件与显示栈不匹配

---

默认决策

• Kali 首先要保持分支整洁。 仓库状态比稀奇古怪的软件包传闻更能解释问题。
• 除非有明确理由，否则优先使用 kali-rolling。 这是大多数用户应使用的主分支。
• 如果用户希望获得更平稳、类似正式版本的体验，请使用 kali-last-snapshot。 不要只因为选项越多越好，就在启用 kali-rolling 的同时启用它。
• 优先选择专用元软件包。 除非设备确实是为了打造一个大型工具箱，否则 kali-tools-* 套件比 kali-linux-everything 更合适。
• 将 Kali 视为工作流发行版，而不只是软件包仓库。 镜像选择、持久化、硬件和使用范围都与软件包名称同样重要。
• 问题聚焦于软件包时，就专注于软件包。 安装 nuclei、burpsuite、hashcat 或逆向工具时，仍属于此范畴，除非问题转向防御性审查、攻击工作流或新型漏洞研究。
• 实验环境应可随时丢弃。 相比永远手动维护一台珍贵的渗透测试笔记本，快照、一次性 VM 和隔离介质更好。为可重复的实验使用快照或固定镜像，不要在练习过程中排查滚动更新造成的偏差。
• Kali 默认并不是一款经过加固的日常服务器。 将字典、抓包文件和 VM 磁盘放在较小的根分区之外。
• 先选工具类别，再纠结具体工具。 先选类别，再选工具，最后选软件包。
• 无线和 SDR 工作首先取决于硬件。 芯片组支持、固件、直通、电源和实际的监控模式支持情况，比菜单项更重要。
• 正确处理攻击相关的深入工作。 Kali 可以安装这些工具，但权限提升归属 exploitation workflow，漏洞研究负责发现新型漏洞。

---

快速排查清单

症状	首要检查项
安装后 apt 异常	源列表、apt-cache policy、密钥环软件包、分支混用、待执行的 apt full-upgrade
已安装元软件包，但找不到工具	dpkg -l、apt-cache depends、命令路径、软件包拆分、过渡软件包
Live USB 未保留更改	持久化分区、挂载状态、覆盖层损坏、镜像模式错误
VM 运行异常或无法识别 USB 设备	虚拟机监控程序的客户机工具、USB 直通、网络模式、显示加速
无线工具无法使用监控模式或注入	芯片组支持、固件、rfkill、USB 供电、直通、内核模块
SDR 或硬件工具运行异常	软件包状态、udev 访问权限、内核模块、USB 权限、设备固件
Burp 或浏览器抓包异常	桌面会话、CA 导入、代理绑定、GUI 辅助工具的 PipeWire 或 portal 路径
NetHunter 问题	Android 版本、内核支持、镜像类型、HID 和无线支持、移动软件包渠道
系统体积庞大且运行缓慢	元软件包泛滥、桌面选择、后台服务、安装 kali-linux-everything 带来的后悔
一切都毫无头绪	查看常见问题参考——分支混用、密钥环过时、持久化状态漂移、VM 直通错误和不受支持的 Wi-Fi 芯片组，往往能解释很多问题

---

参考文件

• references/packages-branches-and-repos.md - Kali 分支模型、源列表、密钥环、更新和软件包状态恢复
• references/metapackages-and-tool-families.md - Kali 主要元软件包会安装哪些内容、工具系列如何对应实际工作流、kali-tweaks 配置菜单，以及何时应转交给 privilege-escalation 或 vulnerability-research
• references/images-live-persistence-and-recovery.md - 安装器 ISO、netinst、Live 镜像、Purple 镜像、虚拟机镜像、持久化和恢复流程
• references/wireless-gpu-hardware-and-nethunter.md - Wi-Fi、Bluetooth、RFID、SDR、GPU、USB 直通，以及 NetHunter 特有的硬件情况
• references/lab-safety-and-scope.md - 一次性实验室设置、故意存在漏洞的目标、快照和授权边界
• references/gotchas-and-special-situations.md - Kali 中反复出现的故障模式和边缘情况

---

输出约定

完整约定见 references/output-contract.md。

• 技能名称： KALI-LINUX
• 交付类别： audits
• 模式： 有条件。当请求执行现有仓库内容的分析、审查、审计或改进时，请遵循 references/output-contract.md 中的报告长度和证据规则，并将交付文件写入 docs/local/audits/kali-linux/<YYYY-MM-DD>-<slug>.md。当请求回答问题、讲解概念、构建新产物或生成内容时，可自由作答，不受该约定约束。
• 严重级别： P0 | P1 | P2 | P3 | info（参见共享约定；仅在审计／审查模式下使用）。

相关技能

• debian-ubuntu - Debian 系发行版的基础管理。通用 apt 系主机请使用此技能；涉及 Kali 特有的分支、镜像、元软件包或工具背景时，请使用本技能。
• privilege-escalation - 在获授权的目标上进行利用、利用后操作和权限提升。本技能用于选择和维护 Kali 工具；privilege-escalation 负责实际的攻击工作流。
• vulnerability-research - 漏洞发现、深入逆向工程、模糊测试和概念验证工作。本技能涵盖支持这些工作的 Kali 环境和工具系列。
• security-audit - 用于防御性加固和漏洞审查，而非攻击性发行版工作流。
• virtualization - 当问题明确出在 Kali 客户机之外时，用于设置虚拟机监控程序、配置客户机、设备直通和处理虚拟机平台问题。
• shell-scripting - 当实际问题在于 Shell 而非 Kali 时，用于处理 Shell 语法、包装器、别名和脚本可移植性。
• networking - 用于处理超出主机级 Kali 软件包问题范围的网络服务、VPN、DNS、代理和防火墙设计。

---

规则

1. 运行影响重大的变更前，先确认。 展示准确的命令及其执行计划，等待明确同意后再执行，然后进行验证。无人值守运行必须停在计划阶段。
2. 遵守授权范围。 推荐 Kali 工具不代表获准在授权环境之外使用这些工具。
3. 区分实验室与生产环境。 实践目标、易受攻击的应用和攻击工具应放在一次性系统或隔离设备中。通过明确的存储边界，分开存放客户数据、实验室产物和漏洞利用工具。
4. 正确转交。 工作涉及利用方法时，使用 privilege-escalation。涉及原创漏洞研究时，使用 vulnerability-research。