企业官网建设流程全解析

做等保测评的人最清楚，进到一台SUSE Linux Enterprise Server面前，满屏命令里到底哪些是测评项该看的，哪些只是系统运行的正常输出，这中间隔着一整套安全控制点的理解。SLES在企业里多是核心业务的承载系统，等保2.0要求身份鉴别、访问控制、安全审计、入侵防范每一块都要有证据可查，而证据的来源就是一条条命令的输出。这篇文章围绕等保测评在SLES上最常检查的命令，按测评项重新组织成体系，从口令策略一路查到防火墙、审计日志和内核参数，附带参数解释和踩坑记录，适合等保测评师、系统管理员以及做安全自查的同事直接参考。

1. 等保测评在SLES上查什么：先摸清技术底数

1.1 等保2.0在Linux侧的检查项分布

等保2.0对操作系统的检查，集中落在“安全计算环境”这个类别里。二级系统主要看身份鉴别、访问控制、安全审计、入侵防范、资源控制这些基线项，三级系统在同样项上要求更深，比如审计记录留存不少于6个月、双因素身份鉴别、可信验证等。对SLES来说，测评组进场后做的第一件事并不是对着检查表逐条敲命令，而是先做系统画像，把版本、内核、主机名、运行角色摸清楚，否则后面很多判断会走偏。

我常用的三条摸底命令是：

uname -a cat /etc/os-release hostnamectl

这三条命令看起来和测评项无关，但决定了后续参数的取值口径。SLES 12和SLES 15之间，PAM模块路径、防火墙组件、审计规则加载方式都有差异，按旧版经验直接套用，测评现场容易闹出“配置明明写了却不生效”的笑话。比如SLES 12默认用SuSEfirewall2，而SLES 15 SP2以后默认切换到firewalld，如果还在用旧的防火墙检查命令去判断，很容易得出错误结论。

做完系统画像，下一步才是按等保控制点逐项收集证据。实践中我会把检查过程分成六块：身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、资源控制。恶意代码防范在Linux侧主要看是否安装防病毒软件或主机防护代理；资源控制看登录会话数限制、文件描述符限制、磁盘空间分配。这些在测评报告里占的篇幅不大，但每个都要有命令输出作为附件，所以不能漏。

1.2 SLES与其他Linux发行版的测评差异

等保测评师大多从RHEL或CentOS的习惯切入，到了SLES上最常见的反应是找不到熟悉的配置路径。RHEL系的口令策略集中在/etc/pam.d/password-auth，防火墙用firewalld，管理工具是system-config-*；SLES则是另一套逻辑，PAM的公共配置拆在common-auth、common-password、common-account、common-session四个文件里，防火墙早期用SuSEfirewall2，管理工具是YaST。如果照搬RHEL命令，第一步就会把PAM配置路径搞错，影响后面所有判断。

SLES另一个特点是大量系统配置集中在/etc/sysconfig/目录下，例如网络配置、防火墙配置、键盘布局、引导参数都在这里。等保测评时需要关心的SuSEfirewall2配置就位于/etc/sysconfig/SuSEfirewall2，这个目录结构在RHEL上是没有对应物的。还有软件包管理，SLES用zypper而不是yum/dnf，但rpm命令本身通用，检查已安装包用rpm -qa依然好用。

理解这些差异之后，做测评才能把“系统没配置安全项”和“系统配置方式不同但效果等价”区分开。曾见过有的自查报告把SLES的SuSEfirewall2误判成“防火墙未开启”，就是因为测评员用firewalld的检查方法去套SLES 12，最终整改方案完全跑偏。为了避免这类误判，我建议测评前先跑一条命令确认组件：

systemctl list-unit-files | grep -E "firewalld|SuSEfirewall2"

这条命令能看到当前启用的防火墙服务，再决定后续怎么查，比想当然要稳得多。

2. 身份鉴别与访问控制：口令策略、登录限制、权限收敛

2.1 口令复杂度与老化期检查：从PAM到login.defs

身份鉴别是等保测评里权重最高的检查项之一，核心是确认系统对登录用户做了身份标识和鉴别，并且口令有复杂度要求、定期更换。SLES上这部分的证据主要来自两个文件：密码质量策略配置和密码老化策略配置，对应PAM模块与login.defs。

口令复杂度检查命令：

cat /etc/pam.d/common-password cat /etc/security/pwquality.conf grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE" /etc/login.defs

先看pwquality.conf里是否启用了密码质量要求，再看PAM是否真正调用了pam_pwquality.so。很多系统改完/etc/security/pwquality.conf，发现测评依然不通过，原因就是PAM里没有挂载pwquality模块，配置文件写得再漂亮也不会生效。这是自查中最容易看漏的点。

等保三级的口令复杂度一般要求至少8位，且包含大写字母、小写字母、数字、特殊字符中的三类以上。对应到参数上是这样：

minlen = 8 minclass = 3 retry = 3

如果使用dcredit、ucredit、lcredit、ocredit这类参数，注意负号的含义。dcredit=-1表示“必须包含至少1个数字”，如果写成dcredit=1或dcredit=0，含义就变成了“最多允许1个数字”或“不限制数字数量”，这是测评整改时的经典坑。我的建议是统一用minclass来控制字符类别数量，语义清晰，不会在复查时产生歧义。

密码老化期检查相对直白，等保要求口令定期更换，三级系统常见基线是90天更换一次。需要确认login.defs里的三个值：

PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14

PASS_MAX_DAYS是密码最长有效期，PASS_MIN_DAYS是两次修改密码的最短间隔，PASS_WARN_AGE是到期前提醒天数。整改时除了改login.defs，已有的存量账号不一定会自动继承新策略，可能需要用chage命令逐账号调整，尤其要覆盖root和特权账号。检查存量账号可以用：

chage -l root

如果测评现场抽查某个账号的密码有效期不达标，就算login.defs改得正确，也会被判为不完全符合。所以我的习惯是改完配置后生成一份账号列表，批量检查所有账号的chage输出，确保没有漏网的。

2.2 登录失败锁定、SSH安全与空闲超时

登录失败处理是身份鉴别的另一项硬性要求，等保明确要求“登录失败后应采取结束会话、限制非法登录次数等措施”。SLES上我建议使用pam_faillock，从SLES 12 SP2开始这已经是官方推荐方案，有些资料里还在写pam_tally2，在较新版本里这个模块已经逐步退出，照着老教程配置很可能找不到模块。

检查当前是否配置了登录失败锁定：

grep -r "faillock\|tally2" /etc/pam.d/

如果没有任何输出，说明系统没有启用登录失败锁定，这是一个典型的不符合项。整改时在/etc/pam.d/common-auth的最前面加入这样一段：

auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900 auth sufficient pam_faillock.so authsucc audit deny=5 unlock_time=900 account required pam_faillock.so

这段配置表示连续失败5次锁定15分钟。一个必须强调的点：faillock的authfail行必须放在pam_unix之前，并且顺序不能乱。preauth在最前面用于检查用户是否已被锁定；authfail在认证失败后记录次数；authsucc用于认证成功后清除失败计数。一旦顺序写错，可能出现两种后果：所有用户都被锁死无法登录，或者失败计数永远不触发。改完PAM配置之后，务必开两个SSH窗口验证，一个用正确密码确认能登录，一个故意输错密码直到触发锁定，确认锁定提示出现后再解锁。

SSH侧的登录限制同样要检查：

grep -E "PermitRootLogin|MaxAuthTries|Protocol|ClientAliveInterval" /etc/ssh/sshd_config

等保基线一般要求禁止root直接远程登录（PermitRootLogin no），SSH协议版本为2（Protocol 2），单次连接认证失败次数限制在3到5次（MaxAuthTries 3），并且配置空闲会话超时（ClientAliveInterval 300、ClientAliveCountMax 3）。这里要注意，SSH的MaxAuthTries和PAM的faillock是两套独立的计数机制，一个基于SSH会话层，一个基于PAM认证层，测评时会同时看两处的配置，只改任何一处都不算完整。

空闲超时还有一处容易被忽略，就是shell层面的TMOUT。等保要求对登录会话设置空闲超时，防止会话长期挂起被滥用。检查命令：

grep -R "TMOUT" /etc/profile /etc/bash.bashrc

一般建议TMOUT=600或900，单位是秒。SLES上如果改/etc/profile，新会话生效，已经登录的会话不受影响，整改后需要提醒业务方重新登录，否则现场测试时超时策略不生效，会被质疑整改质量。

2.3 权限分离与审计对象排查

访问控制检查项中，权限分离是三级系统必查点。等保要求“应授予管理用户所需的最小权限，实现管理用户的权限分离”，通俗讲就是系统管理员、安全管理员、审计管理员应该由不同账号承担，不能所有管理员共用root，也不能让审计员有系统管理权限。

排查命令：

awk -F: '($3 == 0){print $1}' /etc/passwd

这条命令找出所有UID为0的账号，root之外的UID0账号如果没有明确用途，都是风险点，需要降权或删除。空口令检查同样关键：

awk -F: '($2 == ""){print $1}' /etc/shadow

正常等保基线中不允许任何账号存在空口令，一旦发现立即设置密码并锁定。实际整改中，这条命令经常能捞出一些长期闲置的测试账号，这些账号往往被遗忘，测评时被抓个正着。

sudo权限配置是权限分离的另一处重点：

grep -E "wheel|sudo" /etc/group cat /etc/sudoers

SLES默认管理员组是wheel，普通用户加入wheel组后配合sudo配置才能执行管理操作。测评要确认：一是wheel组成员列表是否可接受，二是sudoers里是否配置了NOPASSWD，三是审计所用的管理员账号是否有sudo权限。如果sudoers配置成all=nopasswd，实际上任何可登录用户都能免密提权，这等于架空了访问控制，属于严重不符合项。正确做法是保留sudo的密码认证，只给明确需要的账号以最小sudo权限，比如只允许执行systemctl、zypper等特定命令，而不是直接提权到root。

访问控制还涉及文件系统权限与会话资源限制，这些内容和后续入侵防范的检查存在交叉，但权限分离的核心思路是一致的：能不给的权限就不给，能用普通账号完成的操作用普通账号完成，所有提权行为都要留下审计证据。

3. 安全审计与日志：audit、syslog、journald三件套

3.1 auditd内核审计规则到底怎么写

安全审计是等保测评重头戏，三级系统“应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计”。SLES上的审计能力来自auditd服务，先确认服务状态：

systemctl status auditd auditctl -s

如果auditd没有运行，测评直接不通过。运行中还要确认规则是否加载，用auditctl -l查看当前动态规则列表。审计规则的持久化配置文件在SLES上是/etc/audit/rules.d/目录下的.rules文件，也有的版本直接维护/etc/audit/audit.rules，加载机制由augenrules统一管理。

一份覆盖等保常见检查点的审计规则示例：

-w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/group -p wa -k identity -w /etc/pam.d/ -p wa -k pam -w /etc/ssh/sshd_config -p wa -k sshd -w /etc/sudoers -p wa -k sudoers -a always,exit -F arch=b64 -S execve -k exec

这段规则的意图很明确：对关键账号文件、PAM配置、SSH配置、sudo配置的写入和属性变更做监控，同时对64位系统上的命令执行做审计。等保要求审计“覆盖到每个用户”，execve规则就是实现这一点的核心，它把用户执行的命令记录下来，后续追查谁在什么时候做了什么操作就有据可依。如果系统承载的应用还在用32位二进制，建议把arch=b64和arch=b32同时加上。

规则写完后的加载命令：

augenrules --load auditctl -l

还有一个细节常被忽略：/etc/audit/auditd.conf中的日志轮转参数。默认max_log_file如果太小，日志会快速轮转，等到测评现场要取证时，历史审计记录已经被覆盖。建议至少配置：

max_log_file = 100 num_logs = 5 max_log_file_action = ROTATE

100MB一个文件、保留5个轮转文件，大致能满足日常日志留存。日志量大的系统需要监控实际增速，曾见过规则配得过重导致每天产生数GB审计日志，磁盘告警后才来排查。审计日志不是越多越好，规则覆盖到关键路径即可，避免把系统拖垮。

3.2 rsyslog集中管理与日志留存时长

三级等保的硬性要求里有一条：审计记录保存时间不少于6个月。本地日志默认根本撑不到6个月，除非做压缩归档，否则单靠/var/log/messages的普通轮转，通常几十天就覆盖了。所以整改时一般两条路：一是配置logrotate保留周期更长的归档文件，二是通过rsyslog把日志实时转发到集中日志服务器。对SLES系统，我建议两条路同时走，本地留一份，远端存一份。

检查rsyslog服务与配置：

systemctl status rsyslog grep -vE "^#|^$" /etc/rsyslog.conf

本地日志转发配置可以这样加：

*.info @@192.168.1.100:514 authpriv.* @@192.168.1.100:514 cron.* @@192.168.1.100:514

单@表示UDP，双@表示TCP。等保场景下审计日志传输建议用TCP，UDP存在丢包风险，一旦关键日志在传输途中丢失，审计链就不完整。有条件的环境还可以给rsyslog配置TLS加密，防止日志在传输链路中被截获篡改。这里有个常见坑：rsyslog配置好之后，如果SuSEfirewall2没有放行514/tcp端口，远端日志服务器收不到任何消息，而且本地没有报错，看起来一切正常。配完转发后一定要在远端用tcpdump或tail日志确认真的收到数据，不要只看本机进程状态。

本地轮转不足的问题，可以通过调整/etc/logrotate.d/syslog的配置解决，比如把rotate次数提高到26周以上，并加上compress压缩历史日志。注意SLES上的logrotate可能由systemd timer触发，不一定挂在cron下，检查时不要只找/etc/cron.d，还要看logrotate.timer的状态：

systemctl status logrotate.timer

如果timer被禁用了，logrotate根本不会跑，日志文件永远不轮转，磁盘早晚被撑爆。这个细节在测评现场出现过多次，也是自查容易漏掉的地方。

3.3 journald日志占用与SLES的日志查看思路

SLES 15之后systemd的journald和rsyslog并行运作，很多运维只习惯查/var/log/messages，把journald里的登录记录漏掉。等保测评时，sshd登录成功与失败记录、sudo提权记录这类关键证据，在journald里往往比messages更完整。检查命令：

journalctl --disk-usage journalctl -u sshd -n 50 journalctl --since today

journald日志占用过多是常见问题，它默认会写进/var/log/journal，如果不对容量做限制，日志量可以无限增长直到占满根分区。查看配置：

grep -E "SystemMaxUse|SystemKeepFree|Storage" /etc/systemd/journald.conf

整改建议把SystemMaxUse设置为2G左右，SystemKeepFree给根分区留出足够余量，Storage设为persistent保证日志持久化。关于日志内容合规性，等保要求审计记录包含日期时间、用户、事件类型、事件是否成功、来源IP等信息，SSH登录记录在journald里可以通过journalctl -u sshd看到完整字段，这是测评取证的重要来源。审计日志在/var/log/audit/audit.log中，里面的记录格式包含序列号、时间戳、用户身份、系统调用、结果，信息足够完整，现场测评时这两处是主要取证对象。

4. 入侵防范与系统加固：防火墙、内核参数、关键文件保护

4.1 SuSEfirewall2启用与放行策略核查

入侵防范在等保中的要求里包括“应关闭不需要的系统服务和高危端口，保证只有授权端口对外开放”。SLES 12和SLES 15早期版本用的防火墙是SuSEfirewall2，配置中心在/etc/sysconfig/SuSEfirewall2，检查命令：

systemctl status SuSEfirewall2 cat /etc/sysconfig/SuSEfirewall2 | grep -E "^FW_"

关键参数有FW_SERVICES_EXT_TCP、FW_SERVICES_EXT_UDP、FW_TRUSTED_NETS、FW_DEV_EXT。FW_SERVICES_EXT_TCP表示对外网网卡开放的TCP端口列表，格式是空格分隔的“端口/协议”条目，例如"22/tcp 80/tcp 443/tcp"。很多整改人员会把格式写成逗号分隔或者漏掉/tcp后缀，防火墙重启后配置不生效，端口照样不通，这是SuSEfirewall2配置里的经典错误。

等保检查高危端口是否开放，不能只看防火墙配置，还要看实际监听端口。配合命令：

ss -tlnp

如果发现3306、6379、27017、11211这类数据库和缓存端口在监听，同时防火墙开放列表里也有它们，那就严重不合规。整改动作是从FW_SERVICES_EXT_TCP中删除对应端口，操作前务必和业务确认，避免把生产端口一刀切。这里更稳妥的方式是通过堡垒机通道访问内部管理端口，而不是直接暴露在互联网接口上。改完配置重启防火墙：

systemctl restart SuSEfirewall2 iptables -L -n

用iptables确认实际生成的规则与预期一致，不要只看配置文件。SLES 15 SP2之后如果系统已经切换到firewalld，则改用firewall-cmd检查：

firewall-cmd --list-all

判断系统到底使用哪套防火墙，可以在自查报告里附上前面提过的systemctl list-unit-files输出，避免测评人员误判。

4.2 内核网络参数：防欺骗、防重定向、防数据转发

等保入侵防范中对网络层的加固要求，落实在系统侧主要靠内核参数。SLES的默认内核参数有一部分已经比较安全，但仍有几个重要项需要人工确认：

sysctl net.ipv4.ip_forward sysctl net.ipv4.conf.all.accept_redirects sysctl net.ipv4.conf.all.accept_source_route sysctl net.ipv4.tcp_syncookies sysctl net.ipv4.conf.all.rp_filter

安全基线的推荐值通常是这样：

net.ipv4.ip_forward = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1

ip_forward是数据转发开关，默认情况下应该是关闭的，除非系统本身承担路由或容器网络职责。这里有一个实际矛盾：装了Docker或K8s节点的SLES系统，ip_forward往往会被容器运行时自动置为1，如果测评时强行改成0，容器的网络直接瘫痪。正确的处理方式是评估业务是否真的依赖转发，如果确实需要转发，需要在整改报告里说明用途，并用访问控制策略补偿风险，而不是盲目改参数。这里体现的是等保整改的核心逻辑：安全目标是降低风险，不是让业务跑不起来。

rp_filter反向路径过滤用来防IP地址欺骗，设置为1后内核会校验数据包来源IP的路由一致性。设置这个参数时要注意，多网卡环境下有的场景会出现丢包，比如负载均衡器和多路径场景。如果业务确实受影响，可以退而求其次设置2（宽松模式），并在报告中说明。tcp_syncookies是防SYN Flood攻击的有效手段，默认推荐开启，基本不会引发副作用。

参数修改用独立的配置文件：

cat > /etc/sysctl.d/99-security.conf <<EOF net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.tcp_syncookies = 1 EOF sysctl --system

加载后再用sysctl核对。注意/etc/sysctl.d/下可能有多个文件定义同一参数，后加载的文件会覆盖先加载的，排查问题时如果参数值不符合预期，要用grep -r把整个目录搜一遍，确认有没有其他文件在“抢配置”。

4.3 关键目录文件权限与umask基线

等保的访问控制项还涉及关键文件权限，SLES上需要重点检查的对象包括/etc/shadow、/etc/passwd、/etc/sudoers、/etc/ssh/sshd_config。基线要求如下：

ls -l /etc/shadow /etc/passwd /etc/sudoers /etc/ssh/sshd_config

正常情况下/etc/shadow权限是640或600，/etc/sudoers是440，/etc/passwd是644。如果权限过宽，比如/etc/shadow变成644，任何普通用户都能读哈希，这属于严重风险，整改直接用chmod修正。还有一个容易忽略的项是全局可写文件，用如下命令寻找：

find / -xdev -type f -perm -0002 -print 2>/dev/null

这条命令输出所有对所有人可写的文件，正常情况下应该只有少量临时目录内的文件。它反映的是umask基线是否被破坏。SLES默认umask在/etc/profile里设置为022，如果某个服务启动脚本把umask改成002，运行用户创建的文件就可能对组和其他人开放写权限，长期累积出可被利用的文件。

检查umask：

grep "umask" /etc/profile /etc/bash.bashrc /etc/csh.login

对于长期不修改的敏感文件，可以设置防篡改属性：

chattr +i /etc/ssh/sshd_config lsattr /etc/ssh/sshd_config

i属性让文件不可写、不可删除、不可改名。这里有一个大坑：如果对/etc/shadow也加了i属性，系统在修改密码时会写入失败，passwd命令报错却说不清原因，排查半天才发现是chattr的锅。所以我的建议是i属性只加在很少变动的配置文件上，账号文件千万慎重。一旦加了i属性，后续要改配置必须先chattr -i解除，流程上要写进变更记录，否则运维同学会被坑得很惨。

文件完整性校验方面，等保三级有对系统运行程序完整性的验证要求。SLES可以用rpm -Va对已安装包的文件做校验：

rpm -Va | head -50

这条命令输出与包数据库校验值不一致的文件列表。注意，业务操作中经常合法修改配置文件，rpm -Va会列出大量配置文件的差异，这些不一定是安全问题，要结合修改记录判断。如果想让完整性验证更有说服力，可以补装AIDE类的完整性监控工具，对重点目录建立基线，定期比对。等保现场如果看到有系统化的完整性校验机制，入侵防范项的得分会顺很多。

5. 常见测评整改问题与自查脚本实录

5.1 SLES测评中我常看到的几个坑

SLES的等保整改踩坑率比RHEL高不少，原因多半是对发行版生态不熟。第一个高频坑是PAM的faillock顺序写错。有次排查一台SLES 15的登录故障，所有账号输入正确密码也登录不了，错误日志里全是faillock的deny记录，后来发现是配置里authfail的位置放在了pam_unix的后面，导致认证流程先走了unix判定，再走faillock时顺序错乱，系统把所有成功认证的用户也计入了失败。解决办法是进单用户模式或带外控制台，把common-auth恢复成正确顺序。

第二个坑是SuSEfirewall2的端口列表格式。FW_SERVICES_EXT_TCP的正确写法是"22/tcp 80/tcp"，空格分隔。有人图方便写成了"22,80"或者"22/tcp,80/tcp"，防火墙重启后端口一个都没放行，业务直接中断。这个容易在测试阶段就暴露，但如果整改窗口紧，现场压力会非常大。

第三个坑是audit规则不生效。SLES的持久化规则是通过augenrules机制从/etc/audit/rules.d/生成最终规则文件，如果你直接手改最终文件而不跑augenrules，重启后规则会被覆盖，相当于白改。正确做法是修改rules.d下的文件，再执行augenrules --load，最后auditctl -l验证。

第四个坑是sysctl配置的优先级。遇到一台SLES 12，明明在/etc/sysctl.d/99-security.conf里设置了rp_filter=1，sysctl查出来还是0，排查发现/etc/sysctl.conf里也定义了这个参数，加载顺序导致旧配置覆盖了新配置。所以检查时不能只看一个文件，要把所有候选文件全部搜出来。

第五个坑是日志留存整改只配了logrotate，没确认定时触发机制。SLES的logrotate可能由systemd timer调度，特别是在最小化安装的SLES 15上，如果没有启用logrotate.timer，日志永远不会轮转。测评现场一查磁盘占用，发现/var/log都快满了，存档更是不存在。配完任何周期任务都要记得验证一次实际执行情况。

5.2 自查脚本与整改闭环思路

针对SLES等保测评的高频检查项，我整理了一个简易自查脚本，可以直接放在服务器上定期执行：

#!/bin/bash DATE=$(date +%Y%m%d) OUT=/root/security_check_$DATE.txt { echo "===== 身份鉴别 =====" grep -E "pwquality|minlen|minclass" /etc/pam.d/common-password /etc/security/pwquality.conf grep -E "PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE" /etc/login.defs echo "===== 登录失败锁定 =====" grep -r "faillock" /etc/pam.d/ echo "===== SSH安全 =====" grep -E "PermitRootLogin|MaxAuthTries|Protocol" /etc/ssh/sshd_config echo "===== audit状态 =====" systemctl is-active auditd auditctl -s | head -3 echo "===== 防火墙 =====" systemctl is-active SuSEfirewall2 echo "===== 高危端口 =====" ss -tlnp | grep -E ":(3306|6379|27017|11211)" echo "===== 日志留存 =====" systemctl is-active rsyslog journalctl --disk-usage } > $OUT cat $OUT

这个脚本把测评组进场最关心的一批证据集中输出，整改后也可以用来做回归验证。但脚本只是工具，真正的闭环在管理动作上。每次测评整改都会产生一份问题清单，建议用如下表格式的跟踪方式推进，每个风险项对应整改命令和验证命令，责任到人，验证完成才允许关闭：

这块表格可以直接挪到自查报告里，测评时作为整改证据附上。实际做下来，等保测评最大的价值不是那一纸结论，而是迫使团队把散落在各台服务器上的安全配置统一成基线，并验证它们真实生效。

我在实际操练中的体会是，SLES的等保测评命令本身都不复杂，难的是把配置和业务场景协调好。每次整改前把改动先做成带注释的脚本，放到统一目录保存，测评前跑一遍自查脚本，输出结果打上日期归档。这个习惯看起来笨拙，但能在复测时少解释很多。另一个实用建议是，所有命令输出尽量现场留存时间戳，可以用script命令记录会话，或者直接把结果重定向到带日期的文件里，最后统一打包作为测评附件，比事后翻记录找证据要高效得多。等保测评最终查的是运维习惯，命令只是把习惯暴露出来的工具，把基线固化下来，下一次整改自然就快。