SLES等保测评命令核查与安全整改实战指南

前些天接了一个等保测评项目，目标机器清一色是SUSE Linux Enterprise Server，版本有12 SP5也有15 SP4。我一开始挺自信，直接把之前做CentOS攒下的那套命令清单拿过去跑，结果第一轮就翻车了：查认证日志翻遍/var/log都找不到secure文件，敲firewall-cmd直接提示command not found，连密码策略该改哪个PAM文件都得重新确认。等保测评命令这事儿，看着是“Linux通用”，但发行版差异确实能把人坑到怀疑人生。这篇就把我在SLES上做等保测评命令核查时踩过的坑、验证过的命令、整改过的配置一次性整理出来，覆盖身份鉴别、访问控制、安全审计、网络边界这些核心模块，适合准备接手SLES测评的工程师，也适合SUSE运维管理员拿来自查整改。

1. 先搞清楚SLES和RHEL的测评命令差异，否则第一步就翻车

1.1 包管理与补丁检查：zypper才是SLES的“yum”

等保测评里基本绕不开补丁和系统更新情况的核查。RHEL和CentOS上大家习惯用yum check-update、yum list updates，到了SLES上这套完全不一样，包管理工具变成了zypper。我第一次在SLES上敲yum的时候，终端直接回了一句“bash: yum: command not found”，场面一度很尴尬。

补丁检查的正确姿势是先看系统版本：

bash复制cat /etc/os-release

SLES 12和SLES 15的版本号、SP级别都会在这里显示清楚，这决定了后面你用哪一套配置路径和命令组合。然后看软件源：

bash复制zypper lr -d

这个命令会列出所有配置好的仓库，注意看URL是否正常、是否启用了可疑的第三方源。等保测评里对软件安装来源是有要求的，如果多了一堆不明来源的repo，测评员一般会记一笔。

再看补丁情况：

bash复制zypper list-patches --severity=critical

这条命令会列出当前系统上可以安装的严重级别补丁。如果输出为空，说明系统补丁状态比较健康；如果有大量critical补丁未装，基本就是不合规项。已安装补丁可以用zypper patches查看。仓库配置目录是/etc/zypp/repos.d/，不是RHEL的/etc/yum.repos.d/，这也是一个容易找错地方的点。

值得注意的一个细节是，SLES底层包格式还是rpm，所以rpm -qa、rpm -q 包名这些命令依然通用。补丁核查时，我习惯先用zypper list-patches看整体状态，再用rpm -q确认具体包的版本，两条路配合使用。

1.2 防火墙、服务管理与日志路径：三处最常见的“翻译”表

等保测评命令不能直接照搬，核心原因就是SLES在很多系统组件上走了自己的路线。我把最容易踩坑的几个差异整理成了对照表，方便快速参考：

先说防火墙。SLES 12默认系统里基本没有firewalld，用的是SuSEfirewall2，管理命令是rcSuSEfirewall2 status，配置文件是/etc/sysconfig/SuSEfirewall2。SLES 15又把默认切到了firewalld，但很多从12升级上来的老机器仍然用SuSEfirewall2。所以正确姿势是先探测再操作，别一上来就firewall-cmd。

服务管理方面，SLES从12开始全面使用systemd，systemctl命令通用。但SUSE保留了自己的rc系列快捷命令，比如rcsshd restart、rcnetwork restart，这些在RHEL上不存在。测评时用systemctl绝对没错，看到对方脚本里用rc命令也别觉得奇怪。

日志路径是最容易翻车的地方。RHEL的认证日志集中在/var/log/secure，SLES根本没有这个文件。SLES上认证日志通常记录在/var/log/messages里，更推荐直接用journalctl -u sshd、journalctl -u login这类方式查，干净又准确。

PAM配置体系也完全不同。RHEL把认证模块集中在system-auth和password-auth，SLES拆成了common-auth、common-account、common-password、common-session四个文件。改密码策略要去/etc/pam.d/common-password，这个路径记错，后面全乱。

最后是强制访问控制。RHEL默认SELinux，看状态用getenforce。SLES默认是AppArmor，检查命令是aa-status和aa-enabled。好多从RHEL转过来的人会在SLES上敲getenforce，然后得到一条command not found。这两个安全体系的设计思路不一样，测评时要分别对待。

2. 身份鉴别核查：账号口令、登录锁定与root远程登录

2.1 密码周期与复杂度：别只盯/etc/login.defs

身份鉴别是等保测评里最基础也最爱出问题的一块。密码周期策略，很多人的第一反应是看/etc/login.defs：

bash复制grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE|PASS_MIN_LEN" /etc/login.defs

这里能看到新创建用户的默认参数。但注意，PASS_*这些参数只影响新建用户，已经在系统里的存量用户，实际生效值在/etc/shadow文件里。也就是说，就算你把/etc/login.defs改成PASS_MAX_DAYS 90，存量用户依然是99999天永不过期。所以测评要再走一步，抽查几个用户的实际状态：

bash复制chage -l testuser

这个命令会输出用户密码最近修改时间、密码过期时间、账号过期时间等。整改时，我一般对普通用户批量执行：

bash复制for u in $(awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd); do chage -M 90 -m 0 -W 7 $u; done

这里特意过滤了UID大于等于1000的用户，把系统用户排除掉。系统账号的口令策略不建议乱动，容易引发PAM异常。

密码复杂度方面，SLES的配置位置是/etc/pam.d/common-password：

bash复制grep pam_pwquality /etc/pam.d/common-password

如果输出里有pam_pwquality.so，说明系统启用了密码质量检查。具体参数在/etc/security/pwquality.conf：

bash复制grep -vE "^#|^$" /etc/security/pwquality.conf

重点关注minlen（最小长度）、dcredit（数字要求）、ucredit（大写字母要求）、lcredit（小写字母要求）、ocredit（特殊字符要求）这几个。常见基线要求是长度不低于8或9，并且包含大小写字母、数字和特殊字符中的至少两类。如果这些值是负数，表示至少需要多少个字符属于对应类别；如果是0，表示该类字符不是必须的。

2.2 登录失败锁定：pam_faillock与pam_tally2别搞混

等保测评关于身份鉴别的另一个关键检查项是连续登录失败锁定。SUSE Linux Enterprise Server 12和15默认使用pam_faillock比较多，老版本可能用pam_tally2。检查命令：

bash复制grep -i faillock /etc/pam.d/common-auth

正常情况下，common-auth里会存在类似这样的两行：

code复制auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900
auth required pam_faillock.so authfail audit deny=5 unlock_time=900

deny=5表示连续失败5次后锁定，unlock_time=900表示锁定900秒。等保测评里对锁定策略有明确要求，如果deny次数太多、unlock_time太短甚至没有锁定，都会成为不合规项。

查看当前登录锁定记录：

bash复制faillock --user testuser

或者直接看/var/run/faillock/目录下的文件。pam_tally2的数据库则是在/var/log/tallylog，查看命令是pam_tally2 --user testuser。

这里必须提醒一句：测评现场不要去实测“连错5次密码会不会锁账号”。万一测的是root账号，一旦触发锁定，可能把整个管理入口封死。正确的验证方式是查看PAM配置逻辑，或者用一个临时普通账号测一下，验证完把测试账号删掉。

2.3 su与sudo的边界：wheel组到底有没有被用起来

等保测评对提权操作权限也是重点核查对象。检查su是否被限制到wheel组：

bash复制grep pam_wheel /etc/pam.d/su

如果能看到auth required pam_wheel.so这类配置，说明只有wheel组成员能切换root。再确认wheel组里有哪些成员：

bash复制grep "^wheel:" /etc/group

很多SLES主机的sudoers配置默认允许wheel组执行所有命令，但su可能没有限制。也就是说，只要进了wheel组，既能sudo又能su，权限扩散面就会比较大。检查sudo配置：

bash复制grep -E "^%wheel|NOPASSWD" /etc/sudoers

看到NOPASSWD不要直接判违规，要看它的作用范围。如果是为了某个自动化脚本设置了白名单命令，并且有明确注释和范围收敛，测评员通常会酌情接受。但如果是%wheel ALL=(ALL) NOPASSWD: ALL这种大范围免密sudo，基本是不合规项。另外，/etc/sudoers文件权限应该是440，属主root:root。

2.4 root远程登录与空口令检查

SSH配置是身份鉴别里绕不开的检查点：

bash复制grep -E "^PermitRootLogin|^PasswordAuthentication" /etc/ssh/sshd_config

好多SLES默认配置里PermitRootLogin是yes，这一点和RHEL不太一样，现场很容易因此被判不合规。要不要直接改成no，得结合业务场景判断：如果这台机器没有带外管理，远程是唯一管理通道，直接禁用root登录可能会把管理通道锁死，折中方案是改成prohibit-password，允许root用密钥登录但禁止密码登录。

空口令和UID 0账号检查：

bash复制awk -F: '($2==""){print $1}' /etc/shadow
awk -F: '($3==0){print $1}' /etc/passwd

正常情况下，第一个命令应该没有输出，第二个命令只输出root。如果UID 0溢出多个账号，那就是严重的越权风险。

3. 访问控制与权限核查：别被SLES的默认权限骗了

3.1 关键文件权限与全局可写、setuid检查

访问控制这一块，先从关键文件权限入手：

bash复制ls -l /etc/passwd /etc/shadow /etc/group /etc/sudoers

这里有一个SLES特有的坑：默认情况下/etc/shadow权限可能是root:shadow 640，不是RHEL常见的root:root 000。第一次看到640权限的测评员往往会误判为权限过大，其实是SUSE的系统设计：shadow组里放的是系统工具账号，普通用户不在这个组里，所以风险是可控的。如果强行把它改成000，反而可能影响部分系统功能正常读取锁定时长等信息。测评时重点是确认shadow组里没有多余的人类用户。

接着检查全局可写文件和setuid文件：

bash复制find / -xdev -perm -002 -type f -print 2>/dev/null
find / -xdev -perm -4000 -type f -print 2>/dev/null

全局可写文件意味着任何用户都能改内容，如果出现在配置目录或脚本目录，风险很高。setuid文件如果出现不认识的程序，需要重点排查。正常存在的通常是/bin/su、/usr/bin/sudo、/usr/bin/passwd、/usr/bin/mount这类系统标准命令。

3.2 用户与组：家目录权限和意外登录shell

用户家目录权限也属于访问控制检查范畴：

bash复制ls -ld /home/* 2>/dev/null

如果家目录是755，属主还是root，那所有用户都能进别人家目录翻东西，显然不合规。一般建议改为750或700。查看哪些用户有登录shell：

bash复制awk -F: '$3>=1000 && $7!="/sbin/nologin" && $7!="/bin/false" {print $1,$3,$7}' /etc/passwd

这条命令会列出UID大于等于1000、但不是nologin或false的账号。如果出现一个你不认识的名字却带着/bin/bash，就要警惕是不是被人加了后门账号。

3.3 强制访问控制、关键挂载与补丁状态

SLES的强制访问控制看AppArmor：

bash复制aa-status
aa-enabled

aa-status会列出当前加载的profile以及enforce、complain两种模式的数量。如果大量关键profile处于complain模式，等于只警告不拦截，防御效果很弱。可以把关键profile切换到enforce模式。注意不是所有profile都需要enforce，但核心系统命令的profile应该处于enforce状态。

关键目录挂载检查：

bash复制mount | grep -E " /tmp | /home | /var | /dev/shm "

等保测评对临时目录和共享内存目录的挂载参数有要求，/tmp和/dev/shm建议带上nodev、nosuid、noexec，/home至少要有nodev和nosuid。如果/tmp是普通根分区的一部分而且没有noexec，现场一般会给一个整改建议。

补丁状态继续用zypper：

bash复制zypper lr -d
zypper list-patches --severity=important

如果系统长期没有打补丁，漏洞一堆，这部分在入侵防范上是比较大的失分点。

4. 安全审计与日志核查：SLES没有/var/log/secure

4.1 auditd状态与审计规则加载

安全审计是等保测评里另一块重头戏。先看审计服务状态：

bash复制systemctl status auditd
auditctl -s

auditctl -s会输出审计功能的启用状态，如果enabled不是1或2，审计就没真正跑起来。再列出现有规则：

bash复制auditctl -l

如果规则列表是空的，说明这台机子虽然装了auditd，却什么都没审计。审计规则的配置文件在/etc/audit/rules.d/目录下，通常是一个audit.rules文件。常见的关键规则示例：

bash复制-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/sudoers -p wa -k sudoers
-a exit,always -F arch=b64 -S execve -k process_execution

这里必须强调一个经验：临时用auditctl -w添加的规则，一旦auditd服务重启就会丢失。正确做法是把规则写进/etc/audit/rules.d/，然后执行：

bash复制augenrules --load
auditctl -l

用auditctl -l确认规则已经加载，而不是改完配置文件就不管了。audit日志默认在/var/log/audit/audit.log，这个路径和RHEL一致。另外建议检查/etc/audit/auditd.conf里的space_left_action和disk_full_action，别等到审计日志把磁盘写满之后才处理。

4.2 日志服务与轮转：journald、rsyslog和logrotate一次说清

日志核查先看服务状态：

bash复制systemctl status rsyslog
systemctl status systemd-journald

SLES默认系统日志走journald，rsyslog负责把传统syslog数据写到/var/log/messages。查SSH登录日志可以直接用journalctl：

bash复制journalctl -u sshd

要看历史登录记录，last和lastlog命令照常可用。这里再说一遍：SLES没有/var/log/secure，认证日志主要进/var/log/messages，别再对着这个不存在的文件干瞪眼了。

日志留存时间也是测评必查项。看logrotate配置：

bash复制cat /etc/logrotate.conf
ls /etc/logrotate.d/

重点看/var/log/messages、audit日志有没有对应的轮转规则，以及轮转周期、保留份数是否满足测评要求。如果日志一周就轮转没了，那等保测评要求的长周期回溯能力肯定是达不到的。整改办法是给对应日志配置足够的rotate份数、打开compress和dateext，让历史日志能留得住、还能压缩省空间。

journald本身也有磁盘占用限制，可以看：

bash复制journalctl --disk-usage

如果journal积压太多，可以设置/etc/systemd/journald.conf里的SystemMaxUse，控制journal日志最多占多少磁盘空间。

4.3 时间同步核查：chrony才是SLES的默认选手

日志时间不同步，审计时间线就是乱的，测评员看到时间漂移明显的系统，会在安全审计里记一个问题。SLES 12和15的默认NTP实现基本是chrony，不是老旧的ntpd。检查方法：

bash复制timedatectl status
chronyc tracking

timedatectl输出里的NTP synchronized字段如果显示yes，说明时间同步在工作。chronyc tracking能看到更详细的同步状态。chrony服务名是chronyd：

bash复制systemctl status chronyd

如果系统配置的是ntpd，也可以用ntpq -p查看同步对端，但新部署的SLES基本不太会用到。检查一下/etc/chrony.conf里的时间服务器配置，别让系统时间跟真实世界越偏越远。

5. 网络边界与入侵防范：从防火墙到SSH加固实测

5.1 先确认你用哪种防火墙：SuSEfirewall2还是firewalld

网络边界检查，第一步是判断这台SLES到底跑的是哪种防火墙。直接探测：

bash复制systemctl is-active firewalld
rcSuSEfirewall2 status

如果第一条输出active，说明是firewalld管理，接着用firewall-cmd --list-all查看放行规则。如果第一条提示not found，第二条能输出状态，那就是SuSEfirewall2，配置文件在/etc/sysconfig/SuSEfirewall2。

SuSEfirewall2配置文件里重点关注几个参数：

bash复制grep -E "^FW_SERVICES_EXT_TCP|^FW_SERVICES_EXT_UDP|^FW_TRUSTED_NETS" /etc/sysconfig/SuSEfirewall2

FW_SERVICES_EXT_TCP和FW_SERVICES_EXT_UDP定义了对外的放行端口，FW_TRUSTED_NETS定义了受信网络。如果配置里对一切来源放行了SSH管理端口但没限制来源IP，测评员通常会对这个风险点做记录。

但不管防火墙是哪种实现，最终判断网络暴露面的还是实际监听端口：

bash复制ss -tlnp

这条命令列出当前所有TCP监听端口和对应进程。防火墙规则和监听端口要结合看：如果某个端口在监听但防火墙没放行，外部访问不到，风险相对可控；如果端口在监听、防火墙也放行了，但业务根本用不上，那就是多余暴露面，应该关闭对应服务。

5.2 SSH配置逐项过：PermitRootLogin、MaxAuthTries、ClientAliveInterval

SSH配置核查不能只看/etc/ssh/sshd_config里的文本，因为很多配置项走的是默认值，配置文件里根本没有写。正确做法是看生效配置：

bash复制sshd -T | grep -E "permitrootlogin|passwordauthentication|maxauthtries|clientaliveinterval"

sshd -T会把当前真正的生效配置都打出来，比翻文件可靠得多。重点关注几个值：

• permitrootlogin：是否允许root直接登录，推荐prohibit-password或no
• passwordauthentication：是否允许密码认证，管理端如果不用密码，可以关闭
• maxauthtries：单次连接最大认证次数，通常要控制在一个较小的值，比如5或更小
• clientaliveinterval：会话空闲超时时间，建议配置一个具体秒数，让闲置会话自动断开

修改配置前先把关键项目备份一遍，编辑完用sshd -t校验语法：

bash复制sshd -t
systemctl restart sshd

远程操作SSH配置时，任何时候都要保留一个已经登录的会话窗口再重启服务，防止配置写错直接断连。

5.3 内核参数、挂载项与不必要服务：入侵防范的剩余动作

入侵防范检查还会涉及一部分内核参数：

bash复制sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv4.conf.all.rp_filter

ip_forward在生产服务器上通常应该为0，除非这台机器本身就是路由器或者网关设备。accept_redirects应该为0，避免接受ICMP重定向导致路由表被篡改。rp_filter应该为1，开启反向路径过滤，防止源地址伪造的报文进入。

文件系统挂载参数前面提过，再补充一下：

bash复制mount | grep -E " /tmp | /dev/shm "

如果/tmp和/dev/shm的挂载参数里没有nodev、nosuid，至少记一个低风险问题。/tmp还建议加noexec，阻止临时目录里执行二进制。

还要检查系统里有没有启动不必要甚至危险的服务：

bash复制systemctl list-unit-files --state=enabled
rpm -q telnet-server rsh-server

rpm -q如果输出package telnet-server is not installed，说明这些老旧的远程管理服务没有装，这是好现象。如果装了，需要卸载并关闭对应服务。

6. 测评没通过的整改动作与复测技巧

6.1 密码策略与登录锁定：一次改到位，千万别只改login.defs

等保测评发现密码策略不合规，整改建议分三个地方一起动，缺一个都会留尾巴。

第一个是/etc/login.defs，修改默认密码周期：

bash复制sed -i 's/^PASS_MAX_DAYS.*/PASS_MAX_DAYS 90/' /etc/login.defs
sed -i 's/^PASS_MIN_DAYS.*/PASS_MIN_DAYS 0/' /etc/login.defs
sed -i 's/^PASS_WARN_AGE.*/PASS_WARN_AGE 7/' /etc/login.defs

第二个是/etc/security/pwquality.conf，收紧密码复杂度：

bash复制minlen = 9
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

其中-1表示密码里至少包含1个数字、1个大写字母、1个小写字母、1个特殊字符。

第三个是登录失败锁定策略，确认/etc/pam.d/common-auth里有pam_faillock两行配置，deny=5、unlock_time=900。如果系统里没启用，需要按顺序加进去，并在/etc/pam.d/common-account里加一行：

code复制account required pam_faillock.so

改完PAM配置之后，用非root账号测试一次登录锁定是否生效。记住，千万别拿root账号去试错，锁死了再进系统就是大麻烦。存量用户的密码周期用前面给的chage循环批量刷新。全部改完，用chage -l抽样验证。

6.2 SSH与审计规则整改：改完要能看到“生效”而不是“配置存在”

SSH整改场景，把/etc/ssh/sshd_config里这几项调整到符合测评要求的水平：

bash复制PermitRootLogin prohibit-password
MaxAuthTries 5
ClientAliveInterval 300
ClientAliveCountMax 0

改完先sshd -t验一下语法，再systemctl restart sshd，最后用sshd -T重新输出这几项，确认真实生效值确实变了。这个“确认生效”的动作非常关键，因为配置文件里写了但没生效的情况在SSH上很常见，比如参数拼写错误、被后面的配置覆盖、或者Include文件冲突。

审计规则整改：

bash复制vi /etc/audit/rules.d/audit.rules

把需要的-w和-a规则写进去，然后：

bash复制augenrules --load
auditctl -l

如果系统里根本没装auditd，先装：

bash复制zypper install audit
systemctl enable --now auditd

整改完成后，auditctl -l必须能看到实际规则，不能只是rules文件里有内容。

6.3 复测技巧：把“整改证据”做成对比

测评整改不是改完配置就算完，还要让测评员能快速看到“整改前是什么样、整改动作是什么、整改后是什么样”，否则现场验证又要重新翻查一遍，白白浪费时间。我习惯用一张对比表把关键项整理清楚：

每个整改项都把“整改前证据”和“整改后验证输出”截图或留存命令行记录，测评员复查时一目了然，基本不会来回扯皮。

最后聊聊我个人在SLES上测评踩过最深的坑。有一次我在一台SLES 12 SP5上改/etc/pam.d/common-auth，为了加pam_faillock的锁定策略，手误把pam_unix.so那行的顺序放错了，保存完新开一个SSH窗口登录直接报错，幸好之前的会话没断，赶紧把文件改回来才没造成事故。从那以后我给自己立了三条规矩：第一，涉及PAM的改动必须先在测试机上验证；第二，远程修改SSH和PAM配置时，永远保留一个已登录的会话窗口，避免自己把自己锁死；第三，凡是改了配置，必须用验证命令重新输出一遍，而不是凭配置内容口头说“已经改了”。SLES的测评命令并不复杂，复杂的是你在不同版本之间来回切换时，肌肉记忆造成的误判。希望这篇命令清单能帮你少踩几个坑，顺利搞定SLES的等保测评。