接到过这样一个线上告警一台 CentOS 7.7 服务器 CPU 突然飙到 100%登录上去一看/tmp 下面躺着一个挖矿脚本redis 端口没设密码直接裸奔在公网root 密码还是 8 位弱口令。后来顺着日志一追这个 root 密码过去两年里被发给了至少六个人其中两个人已经离职一年多了。这不是什么高级漏洞攻击就是账号管理和权限控制整个崩了。做运维这么多年我越来越确定一件事CentOS 系服务器被攻破绝大多数不是因为内核漏洞多高级而是账号权限管理太松散。这篇我专门来拆解 CentOS 7.7基于 RHEL 7 系列下的账号管理与权限控制——它是系统安全管理里最基础、也最容易被忽视的一环。我会把底层机制、实操配置、踩坑经验一次讲透适合负责服务器日常维护的运维同学也适合刚接触 Linux 安全管理、想建立系统化思路的读者。1. 为什么账号与权限是 CentOS 7.7 安全的第一道防线1.1 从一次“低级失误”说起账号管理失控的真实案例先把这个案例讲完。那次排查下来问题链条特别清晰运维同事图省事用同一个 root 密码装完了所有服务器密码写在内部 Wiki 上后来有开发人员离职账号没禁用、密码没改、sudo 权限没收回。某天有人用旧密码登上了这台 CentOS 7.7 服务器发现 redis 是 root 身份运行的直接就利用未授权访问拿到了执行权限。从头到尾没用什么 0day就是把“身份认证”和“权限边界”全丢了。这类事故在真实环境里太常见了。我见过很多公司的服务器上一堆人共用一个 root 密码出问题了根本不知道是谁操作过明明只需要查看日志的同事被直接塞了个 root开发环境的账号不清理几年下来 /etc/passwd 里攒了一堆“僵尸账号”。账号管理失控带来的直接后果是无法识别“谁在操作”无法限制“能操作什么”更没法追溯“出了事找谁”。所以我把账号管理与权限控制称为系统安全的第一道防线。它做的事其实就三件身份要认准Authentication、权限要给小Authorization、行为要可查Audit。这三件事做好了即使某天真的有漏洞被利用攻击面也已经被压缩到最小。这也是我在做 CentOS 服务器加固时永远第一个检查的部分。1.2 底层机制/etc/passwd 与 /etc/shadow 的数据结构要在 CentOS 7.7 上把账号管理做好绕不开两个文件/etc/passwd 和 /etc/shadow。很多人用了很久 Linux一看到这两个文件的字段还是懵的这里我一次性讲清楚。/etc/passwd 每行代表一个用户一共七个字段用冒号分隔webadmin:x:1001:1001:Web Admin:/home/webadmin:/bin/bash第 1 段是用户名第 2 段是口令占位符x 表示真正的密码哈希存放在 /etc/shadow 里第 3 段是 UID0 是 root1-999 是系统用户1000 以上是普通用户第 4 段是主组 GID第 5 段是用户说明GECOS 字段第 6 段是家目录第 7 段是登录 shell/sbin/nologin 表示禁止交互登录。/etc/shadow 才是存密码核心信息的地方每行也是冒号分隔共九个字段webadmin:$6$abcdefg$hashhashhash:19200:7:90:7:30:19450:第 1 段是用户名第 2 段是加密后的密码哈希$6$ 开头表示 SHA-512 加密$1$ 是 MD5$5$ 是 SHA-256第 3 段是密码最后一次修改日期以 1970-01-01 起算的天数第 4 段是密码最小修改间隔天数第 5 段是密码最大有效期天数第 6 段是密码过期前多少天开始提醒第 7 段是密码过期后多少天禁用账号第 8 段是账号失效日期第 9 段是保留字段。理解这两个文件是排查账号问题的基础。比如你执行 passwd 命令报“Authentication token manipulation error”大概率是 /etc/passwd 或 /etc/shadow 文件的权限被改坏了。正常情况下 /etc/passwd 是 644 权限/etc/shadow 是 000 权限只有 root 能读写这两个文件的属主一定是 root。一旦这些文件的权限被手动改乱整个认证体系都会出问题。2. 文件权限控制rwx 与特殊权限位的实用逻辑2.1 常规权限位读、写、执行的本质与几个常见误区账号管住了“谁”权限管的是“能对文件和目录做什么”。CentOS 7.7 沿用了 RHEL 7 经典的 POSIX 权限模型每个文件有三个权限组——属主u、属组g、其他o每组三个权限位——读r、写w、执行x。权限位有两种写法用数字最直观r4w2x1。rwx 就是 7r-x 是 5rw- 是 6。比如 chmod 640 表示属主可读写、属组可读、其他人无权限。这个大家都会用但有几个误区我每次都想提醒一遍。第一个误区目录的执行权限x很容易被忽略。文件的 x 表示“能不能执行”目录的 x 表示“能不能进入这个目录、能不能访问里面的文件”。如果目录只有 r 没有 x你可以列出文件名但无法 cd 进去也无法读取文件内容。所以想开放一个目录给别人读最低权限是 r-x而不是只给 r。第二个误区写文件 vs 写目录是两回事。你能否修改一个文件取决于文件本身的 w 权限你能否在这个目录里创建、删除、重命名文件取决于“目录”的 w 权限而不是文件自己的权限。这一点在处理共享目录时特别容易踩坑。第三个误区是 umask。umask 决定新建文件的默认权限CentOS 7.7 默认通常是 022对应新建文件 644新建目录 755。如果想做团队协作目录umask 设为 002让同组用户默认有写权限会更顺滑。umask 改在 /etc/profile 里对所有用户生效也可以在某用户的家目录 .bashrc 里单独设置。实操里我常用的权限调整命令也就这几个chmod 修改文件权限如 chmod 750 /data/webchown 修改属主属组如 chown -R webadmin:webgrp /data/webchgrp 只改属组如 chgrp webgrp /data/sharedumask 查看和设置默认权限掩码。2.2 SUID、SGID、Sticky三枚特殊权限位的用法与风险常规的 rwx 之外RHEL 7 系列还保留着三个特殊权限位分别用数字 4、2、1 表示SUID4、SGID2、Sticky1。这三个权限位很多人知道名字但对它的风险感知不够。SUID 的数字表示是 4加在属主的 x 位置上典型例子是 /usr/bin/passwd。普通用户执行 passwd 修改密码时其实要写 /etc/shadow这个文件普通用户根本没有写权限。关键就在于 passwd 有 SUID 位执行时这个进程会暂时拥有文件属主root的权限从而完成密码修改。这就是 SUID 的意义让普通用户临时以属主身份执行某个程序。风险也很明显一旦一个 shell 或可交互程序被设置了 SUID 位任何用户执行它都等于拿到了 root 权限。所以安全基线里要求定期扫描全盘的 SUID 文件。SGID 的数字表示是 2加在属组的 x 位置上。文件上的 SGID 和 SUID 类似进程会以属组身份运行但更常见也更实用的场景是“目录上的 SGID”。给目录设置 SGID 后任何人在这目录里新建的文件或子目录属组都会自动继承父目录的属组不会变成创建者自己的主组。做团队共享目录时这是必杀技mkdir -p /data/project chown root:projectgrp /data/project chmod 2770 /data/project这样设置以后projectgrp 组成员都能读写这个目录而且新文件自动属于 projectgrp不会出现“A 创建的文件 B 无法修改”的混乱。Sticky 位的数字表示是 1通常加在“其他”的 x 位置上最典型的就是 /tmp。默认 /tmp 权限是 1777任何人可以创建文件但只有文件属主、目录属主和 root 能删除。没有 Sticky 位的 777 目录就是个大坑——任何人都能删除别人在里面的文件。所以如果发现某些共享目录权限是 777 又不带 Sticky 位建议立刻改成 1777或者干脆收紧到 2770。三个特殊权限位的速查表特殊权限数字位置典型作用风险提示SUID4属主 x 位普通用户临时获得属主权限执行程序危险易被提权利用SGID2属组 x 位文件继承属组运行目录内新建项继承属组对目录很实用Sticky1其他 x 位目录内只能删除自己的文件/tmp 标准配置3. sudo 提权与口令策略权限控制的两个实战战场3.1 用 sudo 做权限委派少发 root 密码多配白名单账号权限管理里我反复跟人强调一句话别再把 root 密码发给同事了。服务器需要 root 权限的场景用 sudo 白名单完全能覆盖而且好处是“权限可控、行为可审计”。sudo 的授权文件是 /etc/sudoers修改它必须用 visudo 命令因为 visudo 在保存前会做语法检查防止你手滑写错把整个 sudo 搞挂。sudo 授权的基本格式是用户/组 主机名(可切换的身份) 命令列表比如给用户 webadmin 开放服务管理权限并且只允许操作 systemctl 和 journalctl可以在 visudo 里加一行webadmin ALL(ALL) /usr/bin/systemctl, /usr/bin/journalctl这样 webadmin 执行 sudo systemctl restart nginx 没问题但执行 sudo useradd xxx 会直接被拒绝。更常用的是给整个 wheel 组开放完整 sudo 权限%wheel ALL(ALL) ALL这行在 CentOS 7.7 默认的 /etc/sudoers 里其实是注释状态把占位符取消注释并把运维人员加入 wheel 组就完成了运维权限的初步收敛。sudo 配置有几个细节值得注意。第一命令要写绝对路径用 which systemctl 查一下防止 PATH 注入。第二如果希望某些固定脚本免密执行可以加 NOPASSWD但建议只针对白名单脚本不要整个 ALL 都 NOPASSWD。第三sudo 的执行记录会通过 PAM 写到 /var/log/secure这也方便事后审计——谁在什么时候跑了什么高危命令一查便知。sudo 和 su 的区别也要说清楚su 是切换用户需要目标用户密码切到 root 就等于完全接管sudo 是临时提升权限用当前用户身份认证只执行授权名单内的命令。管理团队服务器我强烈建议只留 sudo 通道把 su 直接限制掉避免 root 密码在内部流传。3.2 口令复杂度、有效期与登录失败锁定账号安全的另一半是口令策略。CentOS 7.7 里口令策略分布在三个地方/etc/login.defs 定义全局默认参数/etc/security/pwquality.conf 控制密码强度校验PAM 配置里做登录失败锁定。先看 /etc/login.defs。密码有效期相关的关键参数PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 7表示密码最长用 90 天最短 7 天内不能改防止反复改回旧密码过期前 7 天提醒。这个文件只影响后续创建或修改的账户对已有用户可以单独用 chage 调整chage -M 90 -m 7 -W 7 webadmin chage -l webadmin # 查看当前策略密码强度由 pam_pwquality 模块控制配置文件是 /etc/security/pwquality.conf。建议至少设置minlen 12 dcredit -1 ucredit -1 lcredit -1 ocredit -1minlen 是密码最小长度dcredit、ucredit、lcredit、ocredit 分别是数字、大写字母、小写字母、特殊字符的最少个数设成 -1 表示“至少包含一位”。配合起来就是 12 位以上、必须包含数字大小写特殊字符。这里有个经验密码策略别一上来就搞得太变态有些同事为了省事会把密码写在便利贴上反而更不安全。12 位加四类字符已经是平衡点。登录失败锁定是用 pam_faillock 模块实现的。CentOS 7.7 可以手动在 /etc/pam.d/system-auth 里加三行注意先备份原文件cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak然后在对应位置插入auth required pam_faillock.so preauth audit deny5 unlock_time900 auth sufficient pam_unix.so nullok try_first_pass auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time900 account required pam_faillock.so配置含义是同一个 IP 或用户连续失败 5 次锁定 15 分钟900 秒。这样能有效减缓暴力破解。配置完以后用错误的密码连续登录几次试试验证锁定逻辑是否生效。注意别把自己锁在外面最好保持当前 ssh 会话别断开确认没问题再退出。4. 实操落地账号全生命周期管理与最小权限检查4.1 创建、锁定与清理账号的标准流程账号管理最忌讳“临时起意”。我自己的标准流程是创建账号之前先想清楚三件事——这个人需要哪些权限、属于哪个组、能登录哪些服务器。想清楚了再动手。创建运维账号的完整流程参考# 1. 创建用户指定家目录、shell、说明 useradd -m -d /home/webadmin -s /bin/bash -c Web Admin webadmin # 2. 设置初始密码并要求首次登录改密 passwd webadmin chage -d 0 webadmin # 3. 加入 wheel 组获得 sudo 权限 usermod -aG wheel webadmin # 4. 限制 SSH 登录范围在 /etc/ssh/sshd_config 里 # AllowUsers webadmin ops01 ops02 # 然后 systemctl restart sshd第 2 步的 chage -d 0 很多人容易忽略它把密码最后修改日期归零强制用户第一次登录就要改密码避免运维拿着初始密码四处广播。第 4 步的 AllowUsers 白名单很重要特别是多账号服务器明确列出谁可以 ssh 登录能减少很多不必要的暴破面。账号生命周期到了终点清理流程比创建更重要。员工离职或项目结束我会按顺序处理收回 sudo 权限从 sudoers 或 wheel 组移除锁定账号passwd -l username 或 usermod -L username终止残留进程检查用户进程并处理清理定时任务检查以该用户身份运行的 crontab归档家目录保留或迁移而不是马上删除便于将来查数据。这里特别提醒锁定账号前先查一下有没有正在跑的进程、有没有 crontab 任务直接删用户容易误伤服务。用 usermod -L 锁定而不是直接 userdel -r 删除也多留了后悔药。另一个常见问题是服务账号。数据库、Web 服务这类程序不要图方便统一用 root 跑。CentOS 7.7 安装一些软件时会自动创建专门账号比如 MySQL 的 mysql 用户、nginx 的 nginx 用户。如果自己编译安装服务也要养成“服务专属账号”的习惯服务进程权限越小被攻击后能造成的破坏就越有限。4.2 四步权限最小化检查堵住权限漏洞权限最小化原则不只是理念可以用命令落地。我每次做 CentOS 安全排查都会跑下面几步基本成了例行体检。第一步检查 UID 0 的账号。UID 0 就是超级用户正常情况下只能有一个 root。如果出现多个 UID 0极可能是被人留了后门awk -F: ($3 0) {print} /etc/passwd第二步检查是否存在空密码账号。账号没有密码哈希等于免密登录这是高危信号awk -F: ($2 ) {print} /etc/shadow第三步扫描全盘 SUID/SGID 文件。找出所有带特殊权限位的文件逐个确认是否合理find / -perm -4000 -type f 2/dev/null find / -perm -2000 -type f 2/dev/null第四步检查全局可写目录和高风险权限。重点看 /tmp、/var/tmp、/dev/shmls -ld /tmp /var/tmp /dev/shm这三个目录正常情况下都是 1777带粘滞位。如果发现变成普通 777就要警惕攻击者很喜欢在 /tmp 下放脚本。另外团队共享目录的权限建议用“属主属组SGID”的组合而不是简单粗暴的 777。权限到人的控制本质就是把“谁能访问”的粒度从“所有人”收敛到“某个组”甚至“某个人”。比如用 sudoers 白名单把运维命令控制到指定用户用 group 权限把敏感目录控制到指定组这才叫真正的权限到人。5. 常见问题与排查技巧实录5.1 高频故障速查表账号权限相关的故障我总结了一张速查表都是日常最容易碰到的症状常见原因排查与解决sudo 执行报 xx is not in the sudoers file用户不在 sudoers 授权列表和 wheel 组用 root 执行 visudo 添加授权或 usermod -aG wheel 用户名passwd 报 Authentication token manipulation error/etc/passwd 或 /etc/shadow 权限/属主异常检查两个文件权限passwd 应为 644、shadow 应为 000属主 root修改 /etc/sudoers 后 sudo 全部失效sudoers 语法错误如果还能用 root用 visudo 修复否则重启进单用户修复用户能创建文件但别人无法修改目录没有 SGID文件属组不对目录设 2770 权限让新文件继承属组用户 SSH 登录被拒绝但密码正确/etc/ssh/sshd_config 的 AllowUsers 没包含该用户检查 AllowUsers 列表将用户加入后重启 sshd账户连续输错密码被锁pam_faillock 生效登录失败锁定时长过后自动解锁被迫手动解锁可删除 /var/run/faillock 对应记录这里面有两个场景想多说几句。第一/etc/sudoers 语法写错导致所有 sudo 失效是运维自己最容易被反杀的操作。如果当前会话还是 root直接用 visudo 修复如果 sudo 都没法用但知道 root 密码可以 su 到 root 修复。千万别把唯一的 root 会话断开否则就得去机房或控制台走单用户模式了。第二忘记 root 密码也是常见事故。CentOS 7.7 的标准处理是重启服务器在 GRUB 界面按 e 进入编辑找到 linux16 开头的行在末尾追加 rd.break 或 init/bin/bash进入紧急模式后重新挂载文件系统再执行 passwd root 重置密码。这个流程有操作细节不同内核版本命令行略有差异建议先在测试机演练一遍不要在生产服务器上临场摸索。5.2 三个值得养成的排查习惯最后一个板块分享三个我长期用的排查习惯算是“独家技巧”。第一个习惯多看 /var/log/secure。这个文件记录了 SSH 登录、sudo 执行、用户切换等关键认证事件。比如想查某台 CentOS 7.7 服务器是不是有人暴力破解直接看grep Failed password /var/log/secure | tail -20排查“谁在何时动过 sudo”也很方便grep sudo /var/log/secure | tail -20第二个习惯用 last、lastb 检查登录历史。last 看成功登录记录lastb 看失败登录记录。我每季度会抽查一轮看看有没有异常的登录时间、登录 IP尤其关注下班时段和异地 IP 的登录。第三个习惯定期扫描特殊权限位并审计 diff。把第 4.2 节的 find 扫描结果保存下来find / -perm -4000 -type f 2/dev/null | sort /root/suid_report_$(date %F).txt这次扫描的结果和上次比对新出现的 SUID 文件就是重点排查对象。实战中很多后门程序就是通过复制一个 SUID shell 来实现提权驻留的这个习惯能帮你尽早发现异常。这套账号权限的安全基线我建议至少每季度复查一遍。服务器的账号又多又杂一不留神就会“长老了”等出了安全事故再去收拾代价就不是你花半天配置能比的了。