linux服务必须以非root用户运行，显式指定user/group；最小化capabilityboundingset；配置文件权限设为640；监听地址禁用0.0.0.0；加强权限管理与审计。
服务运行用户必须非 root
Linux 服务以 root 身份运行，等于把整台机器的钥匙直接交给它。哪怕只是 nginx 或 redis-server 出现一个未修复的内存越界，攻击者就能直接提权。
实操建议：
- 所有自启服务（
systemd单元）必须显式指定User=和Group=，例如User=www-data；不写默认继承调用者权限，而systemd启动时上下文常为 root - 检查已有服务：运行
ps aux | grep -E "(nginx|redis|httpd)"，确认 USER 列不是root - 禁止在
/etc/init.d/脚本里用su -c临时切用户——这种写法绕过 systemd 的权限管控，且容易漏掉文件句柄继承问题
systemd 服务的 CapabilityBoundingSet 要最小化
默认情况下，systemd 给服务进程赋予了全部 Linux capabilities，比如 CAP_NET_BIND_SERVICE 允许绑定 1024 以下端口，CAP_SYS_ADMIN 几乎等同于 root 权限。不收紧就等于没加固。
实操建议：
- 先查服务真正需要哪些能力：比如
nginx只需CAP_NET_BIND_SERVICE（用于监听 80/443），rsyslog需要CAP_SYSLOG，其余一律禁用 - 在 unit 文件中设置：
CapabilityBoundingSet=CAP_NET_BIND_SERVICE，同时配RestrictCapabilities=true关闭隐式继承 - 别盲目加
CAP_SYS_PTRACE——调试工具如strace确实需要它，但生产环境开启后，攻击者可用它 dump 进程内存、注入代码
服务配置文件权限不能是 644 或 755
像 /etc/nginx/nginx.conf、/etc/redis/redis.conf 这类文件若被普通用户可读，可能泄露敏感路径、上游地址、甚至硬编码密钥；若可写，直接改配置就能执行任意命令（比如 nginx 的 perl 模块或 redis 的 CONFIG SET dir）。
实操建议：
- 配置文件属主设为 root，属组设为对应服务用户（如
root:www-data），权限严格设为640；目录权限设为750 - 避免用
chmod 644“图省事”——这是运维脚本里最常翻车的点，尤其 ansible 的copy模块默认 mode 就是 644 - 检查是否被覆盖：某些包管理器（如 apt）升级时会重置权限，建议在
postinst脚本里补一句chmod 640 /etc/nginx/nginx.conf
监听地址别绑 0.0.0.0，除非真需要外网访问
很多服务默认监听 0.0.0.0:port，意味着只要防火墙没开，内网任意机器都能连上。Redis、elasticsearch、mongodb 因此被扫出大量未授权访问漏洞。
实操建议：
- 优先绑定
127.0.0.1或具体内网 IP（如192.168.10.5），禁止通配；nginx的listen、redis.conf的bind、elasticsearch.yml的network.host都得改 - 不要依赖 iptables/firewalld 做唯一防线——规则可能被误删、服务启动顺序错乱导致短暂暴露
- 对必须对外的服务（如公网 Web），额外启用身份验证（
nginx的auth_basic，redis的requirepass），而不是只靠 bind 控制
权限控制最麻烦的地方不在“设什么”，而在“谁有权限改这些设置”。/etc/systemd/system/*.service 文件本身要是 600，/etc/sudoers.d/ 下的策略也要定期 audit——人总比配置容易出错。