在Debian系统中运行服务时，默认的配置往往赋予服务过大的权限。一个被攻破的Web应用，如果以root身份运行，攻击者就能直接获得整台服务器的控制权。解决这个问题的核心思路不是打补丁，而是从架构上限制服务的能力，让它在即便被完全控制的情况下也掀不起风浪。systemd作为Debian的初始化系统，内置了一套强大的安全加固与权限隔离机制，可以直接在单元文件中声明，无需额外安装SELinux或AppArmor就能实现极细粒度的控制。
理解攻击面：服务真正需要什么加固的第一步是弄清楚服务到底需要哪些权限。一个典型的网络服务，比如Nginx或一个后端API，它需要绑定一个小于1024的端口吗？不一定，我们可以让它监听高位端口，再用iptables转发。它需要访问整个文件系统吗？通常只需要读写特定的日志目录和数据目录。它需要加载内核模块、访问/dev/mem或者修改系统时间吗？绝大多数服务根本不需要。把这些不需要的能力全部剥夺，攻击面就会急剧缩小。systemd提供了几十个指令来精确控制这些行为，我们可以在[Service]区块中逐一配置。
核心隔离：私有文件系统与临时目录最有效的隔离手段之一是PrivateTmp。开启后，服务进程看到的/tmp和/var/tmp是独立的私有目录，其他进程完全看不到它创建的文件。这能有效防止通过共享临时文件发起的提权或信息泄露攻击。配置很简单：
[Service] PrivateTmp=yes
更进一步，如果服务不需要访问用户的家目录，可以设置ProtectHome=yes，这会将/home、/root和/run/user挂载为空目录，服务进程完全看不到任何用户数据。如果服务只需要读取某些特定目录，可以结合ReadOnlyPaths和ReadWritePaths来构建一个白名单式的文件系统视图。例如，一个只处理/var/lib/mydata中数据的服务：
[Service] ProtectSystem=strict ProtectHome=yes ReadWritePaths=/var/lib/mydata ReadOnlyPaths=/etc/myservice
ProtectSystem=strict会将整个宿主机文件系统除了明确放行的路径外全部设为只读，服务根本无法修改任何系统文件。这比传统的chroot更彻底，因为chroot有可能被突破，而命名空间隔离是内核级别的强制限制。
网络隔离：按需开放与私有网络栈很多后台服务根本不需要网络访问，比如定期清理日志的定时任务。直接设置PrivateNetwork=yes，服务进程就会获得一个独立的loopback网络接口，与外部网络完全隔离。如果服务需要监听端口，但不需要主动向外连接，可以结合使用RestrictAddressFamilies来限制协议族。例如，一个仅提供HTTP服务的进程，只需要AF_INET和AF_INET6：
[Service] RestrictAddressFamilies=AF_INET AF_INET6 RestrictAddressFamilies=~AF_UNIX
波浪号表示黑名单模式，禁止使用UNIX域套接字。如果服务不需要与systemd或本地服务通信，禁止AF_UNIX可以阻断一条常见的本地提权路径。对于需要严格网络隔离的场景，还可以使用IPAddressDeny和IPAddressAllow来设置IP级别的访问控制，直接在内核层面过滤，不依赖iptables。
能力边界：CapabilityBoundingSet的精细控制Linux的root权限被细分为多个能力（capabilities），比如CAP_NET_BIND_SERVICE允许绑定特权端口，CAP_SYS_PTRACE允许追踪其他进程。systemd可以精确地增删进程的能力集。最激进的做法是设置CapabilityBoundingSet=空，然后只添加必要的能力。比如一个需要绑定80端口的服务，只需要CAP_NET_BIND_SERVICE：
[Service] CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE
注意AmbientCapabilities用于确保子进程也能继承这个能力。通过这种方式，即使服务进程被注入恶意代码，攻击者也拿不到CAP_SYS_ADMIN或CAP_DAC_OVERRIDE等危险能力，无法挂载文件系统或绕过文件权限检查。
系统调用过滤：SystemCallFilter的深度防御这是systemd提供的最细粒度的安全控制之一。每个进程最终都要通过系统调用与内核交互，如果能限制进程可以发起的系统调用集合，攻击者的利用代码就很难执行。SystemCallFilter可以设置为白名单模式，只允许服务正常运作所需的系统调用。这需要一些分析工作，可以用strace来追踪服务启动和运行时的系统调用列表。一个典型的静态文件Web服务器可能只需要这些调用：
[Service] SystemCallFilter=@basic-io @file-system @network-io @signal SystemCallErrorNumber=EPERM
systemd预定义了多个系统调用集合，@basic-io包含read、write等基本IO，@file-system包含open、stat等文件操作，@network-io包含socket、bind等网络操作。SystemCallErrorNumber指定当进程尝试调用不允许的系统调用时返回的错误码，EPERM比默认的杀死进程更温和，便于调试。如果某个调用被误杀，日志中会清晰记录，方便调整白名单。
用户与命名空间隔离：动态用户与无根运行永远不要让服务以root运行。User=和Group=指令可以指定服务运行的用户。但更先进的做法是使用DynamicUser=yes。开启后，systemd会在服务启动时动态创建一个临时用户，服务停止后该用户被删除。这个用户没有登录权限，UID是随机分配的，极大增加了攻击者利用的难度：
[Service] DynamicUser=yes
结合NoNewPrivileges=yes，可以彻底阻断进程通过setuid二进制文件提权的路径。即使攻击者找到了一个setuid漏洞，内核也会拒绝赋予新权限。对于需要特定用户持久化数据的场景，可以创建一个无登录权限的系统用户，并配合User=和Group=使用。
设备访问与内核模块限制绝大多数服务不需要访问物理设备。设置PrivateDevices=yes会为服务创建一个私有的/dev文件系统，其中只包含最基本的设备节点，如/dev/null、/dev/zero、/dev/random等。服务看不到任何磁盘设备、摄像头或其它硬件。同时，设置ProtectKernelModules=yes可以禁止服务加载或卸载内核模块，防止攻击者植入内核级rootkit。ProtectKernelTunables=yes则保护内核参数不被修改，/proc/sys和/sys对服务变为只读。这三个指令通常一起使用：
[Service] PrivateDevices=yes ProtectKernelModules=yes ProtectKernelTunables=yes内存与进程空间硬化
内存破坏漏洞是最常见的攻击入口之一。systemd提供了MemoryDenyWriteExecute=yes指令，它会阻止进程将内存页同时标记为可写和可执行，这能有效防御JIT喷射攻击和某些类型的shellcode注入。如果服务确实需要动态生成代码，可以不开启此项。此外，ProtectControlGroups=yes可以保护cgroup文件系统，防止进程修改自己的资源限制或逃逸到其他cgroup。RestrictNamespaces=yes则完全禁止服务创建新的命名空间，阻断容器逃逸类的攻击手法。
完整示例：加固一个Python Web应用假设我们有一个基于Gunicorn运行的Python Web应用，监听8080端口，需要读取/etc/myservice/config.yaml，写入日志到/var/log/myservice/，数据存储在/var/lib/myservice/。以下是一个经过深度加固的systemd单元文件：
[Unit] Description=My Secure Web Application After=network.target [Service] Type=simple User=mywebapp Group=mywebapp DynamicUser=yes ProtectSystem=strict ProtectHome=yes PrivateTmp=yes PrivateDevices=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes ReadWritePaths=/var/log/myservice /var/lib/myservice ReadOnlyPaths=/etc/myservice NoNewPrivileges=yes MemoryDenyWriteExecute=yes RestrictNamespaces=yes CapabilityBoundingSet= AmbientCapabilities= RestrictAddressFamilies=AF_INET AF_INET6 SystemCallFilter=@basic-io @file-system @network-io @signal @process @timer SystemCallErrorNumber=EPERM ExecStart=/usr/local/bin/gunicorn -w 4 -b 127.0.0.1:8080 myapp:app Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
这个配置将服务的能力降到了最低。它没有绑定特权端口的能力，只能监听8080。它只能看到自己的数据和日志目录，系统其余部分完全不可见。它不能创建临时文件被其他进程读取，不能加载内核模块，不能修改内核参数，不能执行可写内存页中的代码。即使这个Python应用存在远程代码执行漏洞，攻击者获得了一个shell，他也会发现自己被困在一个几乎空无一物的文件系统中，没有网络工具，无法看到其他进程，无法写入任何系统目录，提权路径被完全切断。
验证与调试加固效果配置完成后，不要盲目信任。使用systemd-analyze security <服务名>可以快速评估安全得分。这个命令会检查单元文件中启用的安全指令，给出一个0到100的评分，并列出未启用的加固选项。得分越高，暴露面越小。对于生产环境的关键服务，应该追求95分以上。如果服务启动失败，检查journalctl -xe的输出，通常是因为某个被禁止的系统调用或文件访问被拒绝。根据日志调整SystemCallFilter的白名单或ReadWritePaths，直到服务正常运行且安全评分不降低。
这种基于systemd的加固方式不需要修改应用代码，不需要额外安装安全模块，所有配置都集中在单元文件中，版本控制友好，迁移方便。在Debian 11和12上，这些指令都得到完整支持。将这套方法论应用到每一个面向公网或处理敏感数据的服务上，服务器的整体安全基线会得到质的提升。
