6.2 Kali自身加固：加密与防火墙

6.2 Kali自身加固：加密与防火墙

本节摘要：Kali 默认为攻击便利优化，用作防守侧工作台前要先加固自己。本节讲两层：全盘加密应对"设备物理失控"场景，防火墙与服务收敛应对网络暴露面。这节的深层价值是示范——把自己当被测对象，用第 4 章的眼光审视自己的系统。

主线场景的第二步：警报处置的间歇，工程师顺手检查了自己的工作台——它跑着客户数据的脱敏副本，本身就是高价值目标。安全从业者的设备失守是最讽刺也最常见的事故。

换个身份：用攻击方的眼光看自己

加固的第一步是威胁建模（5.1 的阶段三用在自己身上）：我的工作台面临什么威胁？物理层面——设备丢失或被扣压，磁盘上的数据直接暴露；网络层面——咖啡馆网络里的扫描与嗅探，我的机器暴露了哪些服务；供应链层面——我装的第三方工具是否可信（2.1 的签名校验就是为此）。三层威胁对应三类措施，本节聚焦前两层。

物理层：全盘加密。 安装 Kali 时选择加密方案（对整个分区含交换空间加密），开机时用口令解锁。它防御的场景非常具体：设备落入他人之手时，没有口令就无法读取磁盘内容——包括你 forgot 删掉但仍在未覆盖区域的文件、浏览器缓存的会话、报告草稿。加密不改变使用体验（解锁后一切如常），只改变"失窃"这个场景的结果。

网络层：服务收敛加防火墙。 先看暴露了什么，再关掉不需要的。防御的姿态是白名单：默认拒绝入站，只放行明确需要的服务。

服务收敛：先看清单再动手

# 第一步：我的机器在对谁开口？
sudo ss -tulpn
# 输出片段（加固前的典型状态）：
# LISTEN 0 4096 0.0.0.0:5900  users:(("x11vnc",...))   ← 远程桌面服务对全网卡开放
# LISTEN 0 511  127.0.0.1:8080 users:(("proxy",...))   ← 代理只听本机 正常

# 逐个审视：这个服务我还需要吗？需要的话 绑定范围对吗？
sudo systemctl disable --now x11vnc.service   # 不再需要的服务：停用并禁用
​

审视的判据三问：这个服务在为哪项工作服务（答不上来就关）；它需要被别人访问吗（不需要就绑本机回环）；它需要被所有人访问吗（不需要就限定来源范围）。三问答完，暴露面通常缩掉一大半——加固的第一课是减少面，而不是叠加防御产品。

防火墙：白名单的姿态

Kali 默认没有启用严格的防火墙规则（为了工具的网络灵活性）。防守侧工作台应该反过来配置：默认拒绝入站，按需放行。

# 用前端工具配置白名单（以常见的前端为例）
sudo ufw default deny incoming     # 默认拒绝入站
sudo ufw default allow outgoing    # 出站默认放行（工具需要联网）
sudo ufw allow from 192.168.56.0/24 to any port 22 proto tcp
# ↑ 只允许靶场网段连我的 SSH 这一条就是"上下文感知"的最小形态
sudo ufw enable && sudo ufw status verbose
# 输出片段：
# To                         Action      From
# 192.168.56.0/24 22/tcp     ALLOW       192.168.56.0/24
# Anywhere                   DENY        Anywhere
​

这段配置体现两个层次：默认姿态（deny incoming）与上下文放行（只有靶场段能连管理端口）。比"全网放行 22 端口"强得多的原因在于它把"谁可以"限定在了"谁需要"。

图 工作台加固的两层防线

加固清单：一台防守侧工作台的基线

把本节内容整理成可勾选的基线清单，其中大半对任何 Linux 工作站通用：

• 安装时启用全盘加密，含交换空间；
• 默认账户为普通用户，管理操作按需提权（1.1 讲过的设计意图，在这里落实）；
• 远程登录禁用口令认证，仅允许密钥，且限定来源范围；
• 入站默认拒绝，每条放行规则注明业务理由；
• 无用服务停用并禁用开机自启；
• 自动安全更新开启（工具链的滚动更新 2.1 已覆盖，系统组件同样需要）；
• 敏感数据只存脱敏副本，按 1.2 的数据条款到期销毁；
• 升级与配置变更有快照或版本记录（3.1、5.3 的纪律延伸到配置层）。

💡 一个验证习惯：加固完成后，用 4.1 的服务识别从另一台靶机扫一遍自己。对自己的机器跑一次授权范围内的"自我评估"，是检验加固成效最诚实的方法——这也正是本章"把自己当被测对象"主线的落点。

加固实录：一台旧笔记本的重生

走一个完整案例。背景：团队里一台退役笔记本要改成事件响应工作机——平时放在机房待命，事件发生时拎起来就走。它的威胁模型很典型：物理上，它可能被落在现场或被无关人员接触；网络上，它会接入客户现场的各种网络；数据上，它按 1.2 的条款会临时存放脱敏样本。

操作分三段。第一段是安装时的选择：全盘加密（含交换分区）、普通用户为默认账户、远程登录只留密钥认证。第二段是服务收敛：开机自启服务从二十一项砍到七项——砍掉的全部用"三问"判据判定：六项是前任使用者留下的便利服务（远程桌面、文件同步），四项是图形工具的后台组件（用不到），四项是开发调试残留。第三段是防火墙：入站默认拒绝，只放行一条——来自团队运维网段的管理端口连接；出站默认放行但记录日志，为的是事后能回答"这台机器昨天连过谁"。

结果：从另一台机器做服务识别，暴露面从"十几个开放端口"缩到"一个 filtered"；加密磁盘在关机状态下拔下接到别的机器，读到的是密文。验收时按 6.2 的验证习惯做了一次自我评估，两小时完成。

解读：这个案例最有价值的产出不是那台机器，而是加固过程的记录——砍掉的服务列表（含理由）、防火墙规则表（含业务注释）、验证输出的存档。它们合在一起构成这台设备的"安全基线文档"，半年后任何人接手，都能知道每条规则为什么存在、验证过什么。加固不是一次动作，是一份可持续维护的文档。

变式：同一套流程用在容器与 WSL 形态上要做形态适配——容器没有"全盘加密"的概念，等价物是对宿主磁盘的加密加镜像内容的最小化（7.1 的窄声明）；WSL 形态的防火墙落在 Windows 侧与 Linux 侧各一层，验收时要两侧都测。威胁建模先行的好处在这里显现：换了形态，威胁模型不变，措施做等价映射即可。

加固问答：三个高频疑问

问：加密会不会拖慢工具运行？ 对现代 CPU 而言，加密指令集已高度优化，日常工具负载下的损耗可以忽略；真正能感知到差异的是大文件持续读写类任务，而那类任务在安全工作里的占比很低。用可忽略的性能代价换"设备失控场景"的结果改写，这笔账不用犹豫。

问：规则一多我自己都记不住，怎么办？ 规则数量的健康线是"一屏能看完"。超过一屏通常说明该做服务收敛而不是继续加规则——先回到三问判据砍暴露面，再给剩下的规则写注释。规则是暴露面的影子，影子太长该修的是物体。

问：加固做到什么程度算够？ 没有绝对答案，但有验证办法：按本节最后的自我评估法，从攻击方视角扫一遍自己，再问一句"比我威胁模型里的对手，我够硬吗"。加固的"够"永远是相对于威胁模型的够，这台概念在 6.4 的紫队方法里会被再次用到。

本节要点回顾

• 先威胁建模：物理、网络、供应链三层威胁对应三类措施；
• 加密管物理：全盘加密一次配置，失窃场景的结果被改变；
• 收敛先于设墙：三问判据砍掉一半暴露面；
• 白名单姿态：默认拒绝入站，放行带上下文与理由；
• 基线清单：八条勾选项，多数对通用 Linux 工作站适用；
• 下一节接力：平台可信后，回到主线的警报——下一节讲日志与检测如何支撑判读。