在Debian系统中，要查看服务的安全属性，核心工具就是systemd自带的systemd-analyze和systemctl show命令，配合systemd-analyze security子命令可以直接输出每个已安装服务单元的安全评级。简单来说，你只需要在终端执行一条命令就能看到哪些服务存在安全风险、哪些服务配置了沙箱隔离、哪些服务拥有特权能力。这不是什么高深操作，而是Debian管理员日常加固系统必须掌握的基本功。

很多人以为Linux安全就是装个防火墙、改改密码，其实服务本身的安全属性才是真正的攻击面。systemd作为Debian默认的初始化系统，它管理着系统上每一个服务的启动方式、权限边界和资源限制。如果你不了解这些属性，等于在裸奔。下面我会从工具使用、安全属性解读、加固方法三个层面，把这件事讲透。

一、systemd-analyze security：一键查看所有服务安全状态

这是最直接的入口。在Debian终端中执行以下命令：

systemd-analyze security

输出结果会按安全等级从高到低排列，类似这样：

● sshd.service
  → 保护方式: none
  → 保护级别: 0
  → 特权能力: CAP_NET_BIND_SERVICE
  → 沙箱: no
  → 私有设备: no
  → 私有临时目录: no
  → 私有网络: no

● nginx.service
  → 保护方式: none
  → 保护级别: 0
  → 特权能力: CAP_NET_BIND_SERVICE
  → 沙箱: no
  → 私有设备: no
  → 私有临时目录: no
  → 私有网络: no

这里面每个字段都有含义。"保护方式"显示该服务是否启用了systemd的安全加固特性；"保护级别"是一个0到12的数字，数字越高代表安全隔离越强；"特权能力"列出了服务拥有的Linux能力集，如果出现CAP_SYS_ADMIN、CAP_NET_RAW这类高权限能力，就需要警惕；"沙箱"如果是yes，说明该服务运行在受限环境中；"私有网络"和"私有临时目录"则表示该服务有独立的网络命名空间和临时文件空间，不会和其他服务互相干扰。

这个命令的优势是全局视角，一眼就能看出整个系统哪些服务是"裸奔"状态。在Debian 12 Bookworm上，默认安装的服务大约有几十个，你可以快速定位到那些保护级别为0且拥有高危特权能力的服务。

二、systemctl show：深入查看单个服务的安全详情

如果你想针对某个具体服务深入分析，用systemctl show加上服务名，然后过滤安全相关字段：

systemctl show sshd.service | grep -E '^(Capability|Private|Protect|NoNewPrivileges|AmbientCapabilities|SecureBits|RestrictRealtime)'

这条命令会输出类似以下内容：

CapabilityBoundingSet=cap_net_bind_service
CapabilityPermittedSet=cap_net_bind_service
NoNewPrivileges=no
PrivateTmp=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
ProtectKernelTunables=no
ProtectKernelModules=no
ProtectControlGroups=no
RestrictRealtime=no
RestrictSUIDSGID=no
AmbientCapabilities=

每个字段的含义非常关键。CapabilityBoundingSet定义了服务能使用的最大能力集合；NoNewPrivileges如果设为yes，意味着服务进程及其子进程无法通过execve获得新的特权，这是防止权限提升的重要手段；ProtectSystem设为strict时，/usr和/boot目录对服务只读；ProtectHome设为read-only时，用户主目录对服务不可见；RestrictRealtime设为yes可以防止服务使用实时调度策略，避免资源滥用。

在Debian默认配置中，大部分服务的这些字段都是no或者空值。这意味着默认安装的Debian系统在服务安全层面是非常宽松的。这不是Bug，而是设计哲学——Debian倾向于给用户最大的灵活性，安全加固需要管理员自己动手。

三、理解systemd安全属性的核心字段体系

systemd的安全属性不是零散的开关，而是一套完整的隔离体系。我把最重要的几类整理出来，方便你理解和记忆。

第一类：能力限制（Capabilities）。Linux传统的root权限太粗暴，systemd用capabilities机制做了细粒度拆分。CAP_NET_BIND_SERVICE允许绑定1024以下端口，这是sshd和nginx需要的；但CAP_SYS_ADMIN几乎等于root，如果某个服务有这个能力，一旦被攻破，攻击者就能做任何事。用CapabilityBoundingSet和AmbientCapabilities可以精确控制。

第二类：文件系统隔离（ProtectSystem/ProtectHome）。ProtectSystem=strict让服务只能看到一个空的/usr和/boot；ProtectHome=read-only让服务无法写入用户目录；PrivateTmp=yes给服务一个独立的/tmp，防止通过临时文件攻击其他服务。这些字段组合使用，可以把服务锁在一个极小的文件系统视图里。

第三类：网络隔离（PrivateNetwork）。设为yes时，服务获得独立的网络命名空间，只能看到lo回环接口。对于不需要对外通信的内部服务，比如数据库的本地监听、消息队列，这个设置非常有效。

第四类：进程限制（NoNewPrivileges/RestrictSUIDSGID）。NoNewPrivileges=yes是最简单也最有效的安全措施之一，它阻止进程通过setuid二进制文件提升权限。RestrictSUIDSGID=yes则进一步禁止服务处理任何setuid/setgid文件。

第五类：内核保护（ProtectKernelTunables/ProtectKernelModules）。前者阻止服务修改内核参数，后者阻止服务加载内核模块。对于Web服务、应用服务来说，这两项通常都应该开启。

四、在Debian上实际加固服务的操作方法

知道了字段含义，下一步就是动手加固。systemd提供了两种修改方式：直接编辑单元文件，或者用systemctl set-property临时修改。

推荐的做法是创建drop-in配置文件，不要直接改/lib/systemd/system/下的原始文件，因为系统更新会覆盖。以sshd为例：

sudo mkdir -p /etc/systemd/system/sshd.service.d
sudo nano /etc/systemd/system/sshd.service.d/security.conf

在文件中写入：

[Service]
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
CapabilityBoundingSet=cap_net_bind_service
AmbientCapabilities=

保存后执行：

sudo systemctl daemon-reload
sudo systemctl restart sshd

然后用前面的命令验证：

systemctl show sshd.service | grep -E '^(NoNewPrivileges|ProtectSystem|ProtectHome|PrivateTmp|PrivateDevices)'

你会看到所有字段都变成了yes或strict。这时候再运行systemd-analyze security sshd.service，保护级别会从0跳升到一个较高的数值。

需要注意的是，不是所有服务都适合同样的加固策略。比如需要写入数据的数据库服务，ProtectSystem就不能设为strict，否则它连数据目录都访问不了。又比如需要加载特定内核模块的服务，ProtectKernelModules设为yes会导致启动失败。加固是一个需要测试和平衡的过程，不能一刀切。

五、Debian特有的安全工具和补充手段

除了systemd自带的工具，Debian还有一些辅助手段值得了解。apparmor是Debian默认启用的强制访问控制框架，它在systemd安全属性之外提供了另一层防护。你可以用aa-status查看当前加载的AppArmor配置，用aa-enforce强制启用某个profile。

debian-goodies包里有一个checkrestart工具，可以检测哪些服务在核心库更新后需要重启，间接帮助你发现安全更新是否被正确应用：

sudo apt install debian-goodies
sudo checkrestart

另外，systemd-analyze compare-versions可以用来确认你的systemd版本是否支持某些安全特性。Debian 12使用systemd 252，已经支持绝大部分安全字段；而Debian 11的systemd 247对部分字段的支持有限，升级系统本身也是一种安全加固。

还有一个容易被忽略的点：systemd-analyze plot可以生成服务启动的时序图，虽然不直接涉及安全，但能帮你发现不必要的服务在启动链中，减少攻击面。配合systemd-analyze security一起使用，效果更好。

六、常见误区和实操建议

很多管理员犯的第一个错误是只看保护级别数字，不看具体字段。保护级别是systemd根据多个字段综合计算的，但它不会告诉你具体哪里有问题。必须结合systemctl show逐字段检查，才能真正理解风险所在。

第二个错误是盲目开启所有安全选项。我见过有人把所有Protect字段都设为yes，结果服务全部启动失败，系统几乎瘫痪。正确的做法是先在测试环境验证，再逐步应用到生产环境。

第三个错误是忽略日志。加固后如果服务异常，journalctl是你的第一排查工具：

journalctl -u sshd.service -n 50 --no-pager

最后给一个实操建议：先用systemd-analyze security跑一遍全系统，把保护级别低于4的服务列出来，逐个分析是否真的需要那么高的权限，然后分批加固。这个过程可能需要几天时间，但做完之后，你的Debian系统安全等级会有质的提升。

总结一下，Debian系统的服务安全不是靠感觉，而是靠systemd提供的这套属性体系来量化和控制。systemd-analyze security给你全局视图，systemctl show给你细节视图，drop-in配置文件给你修改手段，AppArmor给你额外防线。把这几样用好，你的Debian服务器就不再是一个任人宰割的目标。