必须先确认服务无业务依赖再操作：用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 <code>服务名看单元文件描述，man <code>服务名看官方说明 - 查谁要它：
systemctl list-dependencies --reverse <code>服务名，如果输出里有multi-user.target或basic.target，说明它是启动链一环，不能随便动 - 查端口暴露：
ss -tlnp | grep <code>服务名，确认是否监听0.0.0.0:*而非仅127.0.0.1——后者影响小，前者才是真实攻击面
stop 和 disable 到底该用哪个
systemctl stop 只是临时终止进程，重启后照常拉起；systemctl disable 是删掉开机链接，但手动 start 仍能唤醒。两者得配合用，否则白忙活。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 安全顺序：
sudo systemctl stop <code>服务名→ 观察 2 分钟无报错 →sudo systemctl disable <code>服务名 - 想一步到位：
sudo systemctl disable --now <code>服务名，等价于 stop + disable - 怕误启或被依赖激活？用
sudo systemctl mask <code>服务名，它会把单元文件硬链到/dev/null，连start都拒绝——但解除时得先unmask再enable，多一步 - 注意：
mask不影响已运行实例，关完还得stop一次，否则监听端口还在
哪些服务看起来能关，其实踩坑最多
名字普通不代表安全。这几个服务在 CentOS/RHEL/Ubuntu 桌面或云镜像里默认启用，但关法不对就会连锁故障：
-
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 <code>服务名显示inactive (dead)且Loaded行末尾是disabled；再跑sudo systemctl start <code>服务名，应报Failed to start xxx: Unit xxx is masked（如果用了 mask） - 确认依赖没崩：
journalctl -u <code>服务名--since "1 hour ago" 查最近日志有没有failed to start或dependency failed；重点盯crond、rsyslog、cloud-init（云环境）是否还在正常写日志和执行任务
最常被忽略的是 xinetd 托管服务（如 telnet、chargen）和内核模块级服务（如 cifs、smb），它们不走 systemd，得单独改配置或 modprobe -r。关服务不是终点，是验证开始。
