简介银河麒麟高级服务器操作系统V10 SP3 2303安全三级加固手册是一份面向须满足等保三级要求的运维与安全工程师的实用资料适合在政企、金融等对合规性要求较高的场景中作为系统自查、整改与测评的参考依据。资源包共包含一个PDF格式文档体积约三百二十一KB容量不大却足够精炼手册围绕安全服务、密码强度、账户锁定、系统安全、系统审计、系统设置、磁盘检查、资源分配、系统维护九大领域展开每个事项均附有说明、检查方法及修改建议从关闭不必要服务、配置口令复杂度与过期警告、开启失败登录锁定到设置审计策略、执行磁盘检查和资源限制基本覆盖服务器加固常见的高风险项。已有一千八百零八人学习对准备等保测评或推进日常安全基线建设者很有帮助既可用作逐项加固的操作清单也可当作快速排查问题的参考手册。1. 先弄清这份加固手册管到哪等保三级在银河麒麟 V10 SP3 上的落地范围给银河麒麟高级服务器操作系统 V10 SP3 做等保三级安全加固是运维最容易翻车的一类活。手册目录看着只有九章真上手你会发现到处都是版本坑chkconfig 在 systemd 时代经常对部分服务报 unrecognized servicesecurity-switch 在 SP3 和 SP1/SP2 上命令完全不同audit1 加错 grub 参数系统重启直接卡在引导——这些差异官方文档写得并不细。这份手册把安全服务、密码强度、账户锁定、系统安全、系统审计、系统设置、磁盘检查、资源分配、系统维护九个领域串成了一条能照着走的加固主线适合正在过等保测评、做安全自查或者接手国产化服务器整改的运维人员。下面按我实际装过一遍的顺序从服务禁用到验证命令逐条把版本差异说清。2. 安全服务与密码强度先关掉多余服务再定口令复杂度基线2.1 禁用不必要的系统服务chkconfig 与 systemd 的取舍手册里列了一长串「不必要的系统服务」chargen-dgram、daytime-stream、echo-stream、klogin、tcpmux-server、chargen-stream、discard-dgram、eklogin、krb5-telnet、tftp、cvs、discard-stream、ekrb5-telnet、kshell、time-dgram、daytime-dgram、echo-dgram、gssftp、rsync、time-stream。这些大多是历史遗留的网络服务在 V10 SP3 上默认不装但等保检查会逐项核对状态只要有一个 enabled 就会被记不符合。检查方法用两条命令配合# 从 systemd 视角看这些单元是否存在、是否开机自启 systemctl list-unit-files | grep -E chargen|daytime|echo|klogin|tcpmux|telnet|tftp|discard|kshell|gssftp|rsync|time- # 从传统 SysV 视角再看一遍服务状态 chkconfig --list第一行看 systemd 视角下这些单元是否存在并且是 enabled第二行看传统 SysV 服务列表。SP3 虽然由 systemd 接管但保留了 chkconfig 兼容层两个命令都要跑因为部分服务在 chkconfig 里看是 off、在 systemd 里却是 enabled评估时只认其中一个容易漏项。发现 enabled 的服务按手册的加固方式执行关闭chkconfig 服务名 off如果服务名在 systemd 下管理chkconfig 会提示 unrecognized service这时候用 systemd 的方式关闭systemctl disable --now 服务名这里要提醒一句chkconfig off 只是关了开机自启不会停掉正在运行的进程。我一般的做法是chkconfig 服务名 off之后再补一条systemctl stop 服务名如果它正在运行保证基线检查时服务既不自启也不在线。服务名常见状态建议tftpoff / 未安装保持 off确认未启用rsync视安装情况无业务需求一律 offkrb5-telnet未安装确认未安装daytime-stream未安装确认未安装discard-dgram未安装确认未安装还原动作反过来即可chkconfig 服务名 on。但注意别把服务名写错操作前先chkconfig --list | grep 服务名确认准确名称否则还原命令报错退出状态根本没变。2.2 密码复杂度pwquality.conf 的四个参数怎么填检查 /etc/security/pwquality.conf 里的四个参数dcredit数字、ucredit大写字母、lcredit小写字母、ocredit特殊字符。等保三级的要求是这些参数不能屏蔽且值要小于等于 -1-1 表示至少包含 1 位该类型字符。# 查看四个复杂度参数当前的值未注释且 -1 才符合 grep -E ^(dcredit|ucredit|ocredit|lcredit) /etc/security/pwquality.conf如果输出为空说明参数被注释或者文件里没有显式配置需要按手册的方式加固把已有行注释掉再在文件末尾追加四行配置避免旧配置和新配置冲突。# 注释掉已有的参数行 sed -i s/^\(dcredit\|ucredit\|ocredit\|lcredit\)/#\1/ /etc/security/pwquality.conf # 追加新的复杂度策略 cat /etc/security/pwquality.conf EOF dcredit-1 ucredit-1 ocredit-1 lcredit-1 EOF参数说明要分清-1 是「强制至少包含 1 个这类字符」0 是不强制-2 是至少 2 个。等保三级一般按 -1 起步业务侧密码策略更严的可以改成 -2但不要改成 0否则等于没限制。改完验证用 root 修改一个测试账户的密码输入全小写系统应该立刻拒绝并提示密码太简单。这里有个容易被忽略的点pwquality.conf 对 root 修改其他用户密码时同样生效所以用 root 批量改密码时也要符合复杂度否则会批量失败日志里全是 password too simple。2.3 口令过期前警告login.defs 与 chage 要一起改检查口令过期前警告天数手册给了两道命令# 查看系统默认警告天数 grep PASS_WARN_AGE /etc/login.defs # 查看存量用户实际生效的警告天数 chage -l user第一句看系统默认值第二句看存量用户的实际生效值。符合标准是 PASS_WARN_AGE 在 7 天或以上我一般直接设 30。注意chage -l输出的「密码过期之前警告的天数」不能是 -1表示未设置或 0。加固分两步。先改全局默认# 注释掉原有的 PASS_WARN_AGE 行 sed -i s/^PASS_WARN_AGE/#PASS_WARN_AGE/ /etc/login.defs # 追加新的全局默认值 echo PASS_WARN_AGE 30 /etc/login.defs这里最容易踩的坑/etc/login.defs 里的 PASS_WARN_AGE 只对之后新建的用户生效对已经存在的存量用户没有任何作用。等保检查通常会随机抽几个现有用户执行chage -l如果只改了 login.defs存量用户大概率还是原来的 -1检查直接不过。所以必须配合 chage 对存量用户逐个设置# 对 UID 大于等于 1000 的用户逐个设置 30 天警告 for user in $(getent passwd | awk -F: $31000{print $1}); do chage --warndays 30 $user doneawk 条件$31000用于筛出普通用户root 和系统账户一般不动。如果系统里普通用户的 UID 起始值和默认不同先getent passwd确认再调整阈值。chage --warndays 30设置的是用户生效值和 login.defs 里的 PASS_WARN_AGE 语义一致只是一个管新用户、一个管存量用户两边都要到位。还原方法手册写得很清楚删掉追加的 PASS_WARN_AGE 行再用chage --warndays 原值把用户的告警天数改回去。建议操作前先把原始值记录下来我用chage -l user | grep 警告导出到一个文本里方便还原时对照。3. 账户锁定与会话超时pam_faillock 双文件配置与 TMOUT 陷阱3.1 pam_faillocksystem-auth 和 password-auth 都要动账户锁定这一项等保三级要求 pam_faillock 的 deny 小于等于 5 次、unlock_time 大于等于 600 秒。这里最容易被版本坑绊倒的点是手册明确要求同时修改 /etc/pam.d/system-auth 和 /etc/pam.d/password-auth 两个文件很多运维只改了 system-auth结果 SSH 登录用的 password-auth 栈完全没生效检查还是不过。先看现状# 检查两个 PAM 文件里的 faillock 配置有输出才说明模块已启用 grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth如果没有任何输出说明模块还没启用。加固方式是把两个文件里查找到的 auth 行注释掉在注释行之后添加三段策略。以 system-auth 为例实际配置如下# 认证前检查事先判断是否已锁定 auth required pam_faillock.so preauth audit deny5 even_deny_root unlock_time600 # 认证失败时记录本次失败次数 auth [defaultdie] pam_faillock.so authfail audit deny5 even_deny_root unlock_time600 # 认证成功时清除失败计数 auth sufficient pam_faillock.so authsucc audit deny5 even_deny_root unlock_time600password-auth 里加同样的三行。解释一下这三行的分工preauth 行是在用户输入密码之前检查账户是否已经被锁定如果锁定则直接拒绝authfail 行是认证失败时记录一次失败次数authsucc 行是认证成功时清除失败计数。三行缺一不可少了 preauth 锁定不生效少了 authfail 失败次数不增长少了 authsucc 用户成功登录后计数不会清零达到 deny 次数后连正确密码也会被拒绝。参数里有两个值得斟酌的地方。deny5 表示最多允许 5 次失败满足等保「deny 小于等于 5」的要求unlock_time600 表示锁定持续 600 秒。even_deny_root 决定 root 是否也参与锁定按等保要求 root 不能例外但生产环境一旦 root 被锁如果又没有带外管理通道只能等 600 秒——我一般建议保留 even_deny_root但务必确认机房或带外通道可进系统否则遇到暴力扫描把 root 锁了只能干等或重启体验很差。还要检查 SSH 服务的 PAM 配置。编辑 /etc/ssh/sshd_config确认包含UsePAM yes然后systemctl restart sshd。常见坑是 UsePAM no此时 SSH 登录完全不走 PAM 栈pam_faillock 对 SSH 无效。改完强烈建议做一次「翻车测试」另开一个不会断掉的会话用错误的密码连续尝试 5 次第 6 次开始系统会直接提示账户锁定即使输入正确密码也进不去。确认锁定生效后等 600 秒验证自动解锁或者用 root 执行faillock --reset手动解锁。这条测试流程能避免检查当天才发现锁定没生效。3.2 会话超时TMOUT600 的生效范围与 sed 写法命令行界面超时退出是另一个容易「看着配了、实际没生效」的项目。手册的要求是 /etc/profile 里存在 TMOUT 行且值不超过 600 秒。# 检查 /etc/profile 里的 TMOUT 配置要求有且只有一行、值 600 grep ^TMOUT /etc/profile如果没有任何输出说明没有配置如果输出的值大于 600需要改成 600 或更小。加固# 在 /etc/profile 末尾追加会话超时配置 echo export TMOUT600 /etc/profile # 立即加载生效 source /etc/profilesource 之后用echo $TMOUT验证变量已经加载。这里有两个实际工作中最常见的失效场景。第一个是 TMOUT 只对交互式登录 shell 生效用户通过 SSH 登录后如果再用 su 切换到别的用户、或者进入子 shell有些情况不会继承这个变量。所以除了 /etc/profile我一般会检查一下 /etc/profile.d/ 下有没有其他脚本覆盖 TMOUT以及 /etc/bashrc如果有里是否定义了 TMOUT。曾经遇到一台机器 /etc/bashrc 里定义了 TMOUT300把 profile 里的 600 覆盖了检查的人只 grep /etc/profile 看不到实际生效的是另一个值。第二个是会话超时对运维跑长任务的干扰超过 600 秒没有输入终端会被踢掉后台任务如果没用 nohup 或 tmux 会被 SIGHUP。等保要求 600 是上限生产上我见过有团队改成 360 或 300结果开发跑个数据导入就断连投诉到运维。建议在收到需求时先问清楚会不会跑长任务如果会跑就要求任务侧统一用 tmux/nohup 兜底或者评估能否接受更短超时否则加固的副作用比收益还大。还原方式手册写得很清楚删掉 profile 里 TMOUT 所在行再 source /etc/profile。4. 系统安全strict 模式、box 与 firewalld 的三条线4.1 security-switchSP3 和 SP1/SP2 的差距在这里系统安全这一章版本差异最大也是最容易照搬文档翻车的地方。银河麒麟带有一套安全机制通过 security-switch 命令切换安全模式。等保要求模式为 strict。先看当前模式# 查看当前安全模式 security-switch --get输出不是 strict 时需要切换到 strict# 切换到 strict 模式 security-switch --set strictstrict 模式是银河麒麟比较严格的安全策略开启后权限校验比普通模式严格很多。我在模拟项目X上实操时遇到过这样的翻车某图像处理Demo 的进程需要往 /data 特定目录写文件切到 strict 之后直接被拒绝创建文件看 /var/log/messages 才发现是权限校验拦截。所以这里给个建议strict 模式最好在测试环境验过业务再上生产不要在业务高峰期临时切。切完用security-switch --get确认输出为 strict。一个容易被忽略的细节是 security-switch 切换后某些场景会提示需要重启比如涉及启动链校验的模式切换。我一般是在变更窗口里切完顺手重启一次用security-switch --get确认重启后仍然是 strict否则等保检查当天才发现重启后模式丢了就尴尬了。4.2 box 开关getstatus 与 setstatusbox 是同一套安全机制里的另一个组件这里 SP3 和 SP1/SP2 的检查方式完全不同手册单独做了区分。SP3 用# 查看 box 状态输出 on 为符合 getstatus -m box输出状态为 on 才符合。如果显示 off 或 disable需要开启# 开启 box setstatus box -s enableSP1/SP2 不是 getstatus/setstatus 这套接口而是读取内核映射文件和 grub 参数# SP1/SP2 查看 box 状态值为 1 表示开启 cat /sys/kernel/security/box/status如果值为 0需要修改 /boot/grub2/grub.cfg 内核启动参数在 securitykysec 后面追加 box类似这样linux /vmlinuz-4.19.90-25.9.v2101.ky10.x86_64 root/dev/mapper/klas-root ro resume/dev/mapper/klas-swap rd.lvm.lvklas/root rd.lvm.lvklas/swap rhgb quiet crashkernel1024M,high securitykysec,box kysec_status2这里要强调SP1/SP2 这种改 grub 参数的方式改完必须重新生成 grub.cfg 才能保证重启后仍生效。V10 系列一般用 grub2直接编辑 /boot/grub2/grub.cfg 会在系统更新内核后失效更规范的做法是找到 /etc/grub.d/ 下的模板或者用 grubby 工具去改内核参数改完再执行grub2-mkconfig -o /boot/grub2/grub.cfg重新生成一次确保当前生效。如果你的项目正好是 SP3就不用碰 grub 那套记住 getstatus/setstatus 两个命令即可这是这条线里最值得记的版本差异。4.3 firewalld加固前先想清楚放行策略手册对 firewalld 的要求是确认服务在运行且默认区域里有规则。检查命令# 查看 firewalld 是否在运行 firewall-cmd --state # 查看当前默认区域的所有规则 firewall-cmd --list-all--state 输出 running 表示防火墙在运行--list-all 会列出当前默认 zone 的所有配置重点看 ports、services、protocols、forward-ports、source-ports、icmp-blocks、rich rules 这些字段。如果全部为空说明防火墙虽然开着但没有任何规则这种情况等保检查项会认为没有访问控制机制等于没加固。让 firewalld 开机自启并启动# 设置开机自启并立即启动 systemctl enable firewalld systemctl restart firewalld然后按业务放行必要端口。常见做法是先把 SSH 放行再按业务端口逐个添加。以放行 22 和 8080 为例# 放行 SSH 服务 firewall-cmd --permanent --add-servicessh # 放行业务端口 firewall-cmd --permanent --add-port8080/tcp # 重新加载使持久化规则生效 firewall-cmd --reload # 确认规则已加载 firewall-cmd --list-all这里要说清楚 --permanent 和 --reload 的配合--permanent 写入持久化配置但不立即生效--reload 重新加载配置让持久化规则生效。如果只加 --permanent 不 reload当前运行配置里看不到如果只加不带 --permanent 的规则reload 或重启后丢失等保检查的时候firewall-cmd --list-all输出为空就会被记一个不符合项。生产环境有个高频翻车点在远程操作时先 enable firewalld 再重启如果当前 SSH 不在任何放行规则里防火墙一启动连接立刻断掉。我吃过一次亏之后凡是远程改防火墙都先在当前会话里放行本机 IP 来源的 ssh 服务再执行 reload避免把自己锁在外面。放行本机来源可以用# 放行指定来源 IP 访问 ssh避免远程操作时断连 firewall-cmd --permanent --add-rich-rulerule familyipv4 source address本机IP service namessh accept firewall-cmd --reload5. 审计与磁盘完整性auditd 规则、swatch 与 tripwire5.1 auditdgrub 加 audit1再上 auditctl 规则系统审计这块分两层先保证内核审计功能打开再配 auditd 规则。第一步非常关键很多运维直接配规则发现不生效根源就在内核参数。检查内核是否开启 audit# 查看当前内核命令行里有没有 audit1 cat /proc/cmdline | grep -o audit1如果没有输出要在 grub 内核启动参数里加 audit1。以 SP3 为例用 grubby 修改当前内核参数# 给所有内核添加 audit1 参数 grubby --update-kernelALL --argsaudit1 # 重新生成 grub.cfg grub2-mkconfig -o /boot/grub2/grub.cfg这里有个坑audit1 是内核参数不是系统服务参数改完必须重启内核参数才生效。如果等保检查当天才临时加重启前规则和检查都白做。所以我一般把 grub 参数和 auditd 服务分两步先改参数确认重启后 /proc/cmdline 有 audit1再往下配规则。然后启动 auditd 并检查当前规则# 设置 auditd 开机自启并立即启动 systemctl enable auditd systemctl restart auditd # 列出当前生效的审计规则 auditctl -lauditctl -l 输出为空说明没有规则需要按手册添加。两个最常用的规则# 监控指定文件的读写执行和属性变化关键字为 file auditctl -w /tmp/file1 -k file # 监控 64 位系统下 root 用户执行 execve 系统调用 auditctl -a exit,always -F archb64 -S execve -F uid0第一条 -w 是 watch 模式监控 /tmp/file1 的 read/write/execute/attribute 变化-k file 是给这条规则挂一个关键字方便后续用ausearch -k file检索第二条 -a 是添加系统调用规则archb64 限定 64 位系统调用-S execve 监控执行程序这一系统调用-F uid0 限定 root 用户触发时才记录。等保手册里要求审计覆盖「管理员的操作」这条规则把 root 的所有命令执行都记下来配合 /var/log/audit/audit.log 就能追溯谁在哪天执行了什么。注意 auditctl 添加的规则是临时生效的重启后丢。要让规则持久化我一般写进 /etc/audit/rules.d/ 下的文件比如一个 zz-hardening.rules把这两条按相同语法写进去再执行augenrules --load重新加载。手册里没提持久化但等保检查往往在重启后复查不持久化的规则复查必然为空这是实操里最容易发现的问题。5.2 swatch日志分析软件的安装与跑通swatch 用于审计日志的实时分析手册这一节的要求是安装。检查是否已安装# 查看 swatch 是否已安装 rpm -qa | grep swatch没有输出就安装# 通过 yum 安装 swatch yum install swatchV10 SP3 的 yum 源默认带 swatch 包。安装时最容易出问题的场景是系统源没有配好报 Could not resolve host 或者 mirror 404这在离线内网环境尤其常见。我一般的处理方式是确认 /etc/yum.repos.d/ 下有没有可用的本地源或者挂载麒麟安装 ISO 做本地源# 挂载安装镜像到 /mnt mount -o loop /path/to/Kylin-Desktop-V10-SP3.iso /mnt # 配置本地 yum 源 cat /etc/yum.repos.d/kylin-local.repo EOF [kylin-local] nameKylin Local baseurlfile:///mnt enabled1 gpgcheck0 EOF # 刷新缓存并安装 yum clean all yum install swatch这一段是离线环境的常见做法不是手册原文照着用即可。swatch 装完只是第一步它本身需要配置文件才能监控日志。最小可用配置是写一个 ~/.swatchrc内容类似watch /var/log/secure echo mode然后用swatch -c ~/.swatchrc -t /var/log/secure 后台跑起来。等保检查一般只查 rpm 包有没有装但这块既然装了建议把它真正跑起来否则审计日志分析能力是空的。5.3 tripwire 与 quota/cgroup磁盘与资源控制的基线磁盘完整性和资源分配这两块手册的要求比较轻主要是确认相关组件已安装。tripwire 做文件和磁盘完整性校验quota 做用户/用户组磁盘配额控制cgrouplibcgroup做 CPU 等资源隔离。三项检查命令# 检查三个组件是否已安装 rpm -qa | grep tripwire rpm -qa | grep quota rpm -qa | grep libcgroup没有输出的用 yum 安装# 安装磁盘完整性与资源控制组件 yum install tripwire quota libcgrouptripwire 装完不是立刻能用它需要初始化数据库否则一运行就报错。初始化步骤是设置 site key 和 local key会生成口令然后生成策略文件和基线库命令顺序大概是twadmin --create-polfile /etc/tripwire/twpol.txt和tripwire --init中间会要求输入口令。第一次初始化会生成基准数据库之后用tripwire --check对比文件变更情况。我一般在测试环境里先跑一遍 --init确认数据库生成成功再把 /etc/tripwire 下的配置一并计入交付清单否则检查当天现场跑 tripwire 报错会很被动。quota 这块要注意文件系统是否支持。ext4 需要挂载参数 usrquota/grpquotaxfs 用的是 xfs_quota虽然 rpm 包装了但没挂载参数时配额功能实际不可用。我一般先用mount | grep -E ext4|xfs看挂载参数确认有没有配额支持如果没加会建议在 /etc/fstab 里对应分区补上 usrquota再 remount 生效。5.4 常见问题审计、会话超时与加固还原的坑这一节整理我实际踩过的几个高频坑按「现象 → 原因 → 解决」列出来。第一个是审计规则重启后全部消失。现象重启后 auditctl -l 输出为空ausearch 查不到任何记录。原因auditctl 添加的规则是运行时规则不写进 /etc/audit/rules.d/ 就只对当前会话有效重启后 auditd 重新加载空规则。解决把规则写进规则文件用 augenrules --load 加载再重启验证一次。第二个是 pam_faillock 配置后所有用户无法登录。现象重启或修改配置后SSH 连上就断开console 登录也提示认证失败。原因多半是 system-auth/password-auth 里的 auth 行顺序写错或者模块参数语法有问题PAM 解析到错误配置直接拒绝。解决用带外控制台或救援模式进入系统把备份的 pam 文件恢复回去。这里最重要的不是恢复而是操作前先备份cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak改任何 pam 文件前都必须备份这是装国产化环境这么多年得出的硬教训。第三个是 TMOUT 设置后不生效。现象source /etc/profile 后 echo $TMOUT 有值但重新登录后值又没了。原因有些版本会把 TMOUT 定义在其他加载文件里比如 /etc/profile.d/*.sh或者 /etc/bashrc 后加载把值覆盖回空还有 SSH 的 SendEnv/AcceptEnv 会传递客户端环境的 TMOUT。解决全盘搜索grep -r TMOUT /etc/找出所有定义点统一改成目标值再 source 验证。第四个是 yum install swatch 报源不可用。现象离线环境执行 yum install swatch 长时间卡住后报 Could not resolve host 或 mirror 404。原因默认源指向外网内网不通或者源地址失效。解决用安装 ISO 做本地源按 5.2 里那段 repo 配置切换装完再 yum clean all。第五个是还原操作把服务名写错。现象按手册执行还原时chkconfig 报错退出服务状态和加固前不一致。原因服务名写错或者大小写不对chkconfig 无法识别。解决操作前先chkconfig --list | grep 服务名确认准确名称还原后再次检查状态。6. 验证跑通把九大领域检查命令完整过一遍最后一步是把整套加固效果验证掉这是等保自查和上会前最实用的动作。我一般会准备一份检查清单把九个领域对应的检查命令和符合标准放在一起逐条跑、逐条对照。领域检查命令符合标准安全服务systemctl list-unit-files; chkconfig --list无多余服务 enabled密码强度grep -E ^(dcredit|ucredit|ocredit|lcredit) /etc/security/pwquality.conf四参数均 -1口令警告grep PASS_WARN_AGE /etc/login.defs; chage -l警告天数 7账户锁定grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-authdeny5, unlock_time600会话超时grep ^TMOUT /etc/profileTMOUT600系统安全security-switch --get; getstatus -m boxstrict / onfirewalldfirewall-cmd --state; firewall-cmd --list-allrunning 且有规则系统审计rpm -qa | grep swatch; auditctl -lswatch 已装规则非空磁盘/资源rpm -qa | grep -E tripwire|quota|libcgroup均已安装下面这个脚本可以一条命令把大部分检查项跑完输出保存为文件供复查#!/bin/bash C/tmp/sec_check_$(date %F).log echo services $C systemctl list-unit-files | grep -E chargen|daytime|tftp|rsync $C echo pwquality $C grep -E ^(dcredit|ucredit|ocredit|lcredit) /etc/security/pwquality.conf $C echo account lock $C grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth $C echo session timeout $C grep ^TMOUT /etc/profile $C echo security switch $C security-switch --get $C getstatus -m box $C echo firewalld $C firewall-cmd --state $C firewall-cmd --list-all $C echo audit $C auditctl -l $C echo rpm $C rpm -qa | grep -E swatch|tripwire|quota|libcgroup $C cat $C跑完后重点核对四件事系统能正常登录业务端口通过 firewalld 白名单能访问audit 规则在并且重启后还在pam 锁定真能生效。从那以后我每次加固完都会先把 /etc/pam.d 和 /boot/grub2/grub.cfg 备份一遍再按上面整套命令过一遍确认能登录、能重启、规则不丢才敢把结果交出去。希望这份带版本差异的落地清单帮到你。本文还有配套的精品资源点击获取