系统安全加固的第一步往往不是装杀毒软件，而是做减法。一台Linux服务器从默认安装状态启动后，后台运行的服务数量可能远超管理员的想象：蓝牙、打印、邮件转发、远程桌面，甚至是一些早已废弃的守护进程。这些服务每一个都是潜在的攻击入口，只要有其中一个存在未修复的漏洞，整个服务器就可能被攻破。所谓“最小化服务”原则，就是只保留业务真正需要的服务，其余全部关闭，这是安全管理的基本功，也是最容易被忽视的一环。
一、为什么要关闭不必要的服务
每多运行一个服务，系统就多开放一个或多个端口，多暴露一套代码逻辑。以经典的打印服务CUPS为例，如果服务器根本不连接打印机，这个服务不仅浪费内存和CPU资源，还在本机开放了631端口。历史上CUPS就曾曝出过远程代码执行漏洞，攻击者可以借助这个本不该存在的服务拿到系统权限。
除了直接漏洞风险，多余的服务还会带来几方面问题。第一，攻击者拿到低权限shell后，常利用本地服务的配置缺陷做权限提升，服务越多提权路径越多；第二，服务数量多导致进程列表杂乱，管理员排查异常进程时容易被干扰，隐蔽的恶意进程更容易藏身；第三，资源占用累积起来并不小，在低配的云主机上尤其明显。
反过来看，做过服务精简的系统，netstat或ss命令输出的监听端口清清爽爽，只有SSH、业务端口等少数几项，审计起来一目了然。这种状态不仅安全性更高，出问题时定位也快得多。
二、如何识别和关闭不必要的服务
识别服务要分两步：先看哪些服务在运行，再判断哪些是业务需要的。查看运行中的服务，以systemd体系为例，执行以下命令列出当前所有处于活动状态的服务：
systemctl list-units --type=service --state=running
如果想看到所有已启用的服务（包括开机自启的），用这条命令：
systemctl list-unit-files --type=service --state=enabled
再结合端口监听情况交叉验证，确认每个开放端口对应的进程：
ss -tulnp
输出中每一行的Local Address:Port就是暴露面，Port对应PID和进程名。如果发现631（CUPS打印）、25（postfix邮件）、111（rpcbind）这类端口，而业务上完全不需要，就应该处理。
关闭服务的操作分三个层次。第一个层次是停止当前运行：systemctl stop cups，这只是临时停掉，重启后可能还会起来。第二个层次是取消开机自启：systemctl disable cups，这样重启后服务不会自动运行，但其他服务依赖它时仍可能被拉起。第三个层次是屏蔽服务，这是最彻底的方式：
systemctl stop cups systemctl disable cups systemctl mask cups
mask操作会把服务的unit文件软链接指向/dev/null，任何尝试启动它的请求都会失败，即使有依赖关系也无法拉起。对于明确永远不需要的服务，建议直接mask掉。解除屏蔽用systemctl unmask cups。
老版本的CentOS 6等系统还在用SysV init体系，操作命令不同：用chkconfig --list查看，chkconfig cups off关闭自启，service cups stop停止服务。不过这类系统早已过了维护期，生产环境建议尽快升级。
三、常见建议关闭的服务清单与注意事项
不同的业务场景需要保留的服务不同，但下面这些服务在典型的Web服务器上通常是多余的，可以考虑关闭：
bluetooth：蓝牙支持，物理服务器和云主机基本用不到cups：打印服务，不接打印机就关avahi-daemon：局域网服务自动发现，服务器环境无意义且有信息泄露风险postfix或sendmail：本机邮件服务，除非应用确实需要发信rpcbind：NFS相关，不使用NFS存储就关闭vsftpd：FTP服务，传输不加密，建议用SFTP替代后关闭tftp：简单文件传输，无认证机制，存在被利用刷流量和提权的风险
关闭服务前有几个注意事项。第一，看清依赖关系，执行systemctl list-dependencies 服务名可以查看哪些服务依赖它，避免关掉一个导致业务异常。第二，一次只改一个服务，改完观察一段时间再继续，批量操作出问题时难以定位。第三，像systemd-journald、sshd这类基础服务千万别关，尤其是通过SSH远程管理时，关掉sshd等于把自己锁在门外。第四，某些被mask的服务是系统底层的保护机制，比如systemd-debug-shell默认是masked状态，不要贸然unmask。
建议的做法是先在测试环境演练一轮，把关闭清单和操作步骤写成文档，再到生产环境执行。每次变更后用ss -tulnp核对端口变化，形成记录。
四、服务安全管理的进阶实践
关闭不必要的服务只是开始，对保留下来的服务同样要做好安全管理。第一个原则是最小权限运行。很多服务包默认提供专用的低权限用户，比如nginx使用nginx用户、MySQL使用mysql用户，不要图方便改成root运行。可以通过编辑unit文件限制服务的能力，例如：
systemctl edit nginx
在打开的覆盖配置中加入资源与权限限制：
[Service] NoNewPrivileges=true ProtectSystem=strict ProtectHome=true PrivateTmp=true LimitNOFILE=65535
这些指令让服务进程拿不到新权限、无法写入系统目录、使用独立临时目录，即使被攻破也能显著限制破坏范围。
第二个层面是访问控制。SSH服务保留的同时，应修改默认端口、禁用root直接登录、强制密钥认证；对外提供的服务优先绑定内网地址或通过防火墙限制来源IP，用firewalld或iptables把暴露面收窄到最小集合。
第三个层面是持续审计。安全加固不是一次性动作，系统更新后可能新增服务，运维人员也可能临时开启某些服务忘记关闭。建议定期执行服务清单比对，把当前启用服务与基线快照对照，发现差异及时处理。同时关注journalctl -u 服务名的日志输出，异常的登录尝试、频繁的连接失败都值得警惕。可以配合自动化工具如Lynis做周期性安全扫描，它会直接提示哪些服务应该关闭、哪些配置存在风险。
总结来说，服务安全管理的核心思路就是暴露面最小化：先识别、再精简、后加固，三步走下来，系统的安全水位会有明显提升。运维工作里最省力的安全措施往往就是这些基础操作，把简单的事情做扎实，比追逐各种花哨的防护工具更有价值。
Linux服务管理systemctl命令服务安全加固修改时间：2026-09-09 13:16:55