必须先确认服务无业务依赖再操作：用systemctl cat和man查用途，list-dependencies --reverse看启动链，ss -tlnp确认端口暴露情况，stop后观察2分钟无异常再disable，关键服务禁用前需验证SSH、日志、定时任务等核心功能正常。

直接关掉“看着不熟”的服务大概率会断 SSH、丢日志、甚至进不了系统。必须先确认它真没用，再停、再禁、再验证。

怎么查哪些服务正在跑又没被业务用

别只看 systemctl list-units --type=service --state=running 罗列一堆名字就动手——很多是依赖触发的临时服务，比如 dbus-broker.service 或 systemd-resolved.service，关了可能让 polkit 或 DNS 解析失效。

• 先筛出可疑项：重点关注 avahi-daemon、bluetooth、cups、ModemManager、postfix、tuned 这类非核心且和你硬件/用途无关的服务
• 查它干啥：systemctl cat 服务名 看单元文件描述，man 服务名 看官方说明
• 查谁要它：systemctl list-dependencies --reverse 服务名，如果输出里有 multi-user.target 或 basic.target，说明它是启动链一环，不能随便动
• 查端口暴露：ss -tlnp | grep 服务名，确认是否监听 0.0.0.0:* 而非仅 127.0.0.1 ——后者影响小，前者才是真实攻击面

stop 和 disable 到底该用哪个

systemctl stop 只是临时终止进程，重启后照常拉起；systemctl disable 是删掉开机链接，但手动 start 仍能唤醒。两者得配合用，否则白忙活。

• 安全顺序：sudo systemctl stop 服务名 → 观察 2 分钟无报错 → sudo systemctl disable 服务名
• 想一步到位：sudo systemctl disable --now 服务名，等价于 stop + disable
• 怕误启或被依赖激活？用 sudo systemctl mask 服务名，它会把单元文件硬链到 /dev/null，连 start 都拒绝——但解除时得先 unmask 再 enable，多一步
• 注意：mask 不影响已运行实例，关完还得 stop 一次，否则监听端口还在

哪些服务看起来能关，其实踩坑最多

名字普通不代表安全。这几个服务在 CentOS/RHEL/Ubuntu 桌面或云镜像里默认启用，但关法不对就会连锁故障：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• firewalld：不是所有环境都能关。如果你用的是云服务器安全组+外部 WAF，本地 firewalld 确实冗余；但若没配安全组，关了等于裸奔。更稳妥的是 sudo systemctl stop firewalld && sudo systemctl disable firewalld，再补 ufw enable（Ubuntu）或 iptables-restore（CentOS）
• auditd：关它省内存，但 SELinux 策略、faillock 登录锁定、部分合规审计都会失效。生产环境建议留着，开发机可关
• irqbalance：单核或低负载服务器关了没问题；但多网卡+NIC offload 场景下，关了会导致软中断集中在 CPU 0，网卡吞吐暴跌
• polkit：图形界面或需 sudo -i 以外权限控制的场景必须留。纯 CLI 服务器若没用 systemd-run --scope 或容器 rootless 模式，可评估关，但关前确认 sshd 的 PAM 配置没调用 pam_polkit.so

关完必须验证的三件事

很多人执行完 disable 就去喝咖啡，结果半夜告警说监控失联、日志不入库、定时任务漏跑——因为残留没清干净。

• 确认监听消失：ss -tlnp | grep :端口号 应为空；sudo lsof -i :22（SSH）这类关键端口必须还在，其他如 :631（CUPS）、:5353（Avahi）应彻底不见
• 确认没被拉起：systemctl status 服务名 显示 inactive (dead) 且 Loaded 行末尾是 disabled；再跑 sudo systemctl start 服务名，应报 Failed to start xxx: Unit xxx is masked（如果用了 mask）
• 确认依赖没崩：journalctl -u 服务名 --since "1 hour ago" 查最近日志有没有 failed to start 或 dependency failed；重点盯 crond、rsyslog、cloud-init（云环境）是否还在正常写日志和执行任务

最常被忽略的是 xinetd 托管服务（如 telnet、chargen）和内核模块级服务（如 cifs、smb），它们不走 systemd，得单独改配置或 modprobe -r。关服务不是终点，是验证开始。