做等保测评的人最清楚进到一台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个数字”如果写成dcredit1或dcredit0含义就变成了“最多允许1个数字”或“不限制数字数量”这是测评整改时的经典坑。我的建议是统一用minclass来控制字符类别数量语义清晰不会在复查时产生歧义。密码老化期检查相对直白等保要求口令定期更换三级系统常见基线是90天更换一次。需要确认login.defs里的三个值PASS_MAX_DAYS 90 PASS_MIN_DAYS 7 PASS_WARN_AGE 14PASS_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 deny5 unlock_time900 auth [defaultdie] pam_faillock.so authfail audit deny5 unlock_time900 auth sufficient pam_faillock.so authsucc audit deny5 unlock_time900 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 noSSH协议版本为2Protocol 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一般建议TMOUT600或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/sudoersSLES默认管理员组是wheel普通用户加入wheel组后配合sudo配置才能执行管理操作。测评要确认一是wheel组成员列表是否可接受二是sudoers里是否配置了NOPASSWD三是审计所用的管理员账号是否有sudo权限。如果sudoers配置成allnopasswd实际上任何可登录用户都能免密提权这等于架空了访问控制属于严重不符合项。正确做法是保留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 archb64 -S execve -k exec这段规则的意图很明确对关键账号文件、PAM配置、SSH配置、sudo配置的写入和属性变更做监控同时对64位系统上的命令执行做审计。等保要求审计“覆盖到每个用户”execve规则就是实现这一点的核心它把用户执行的命令记录下来后续追查谁在什么时候做了什么操作就有据可依。如果系统承载的应用还在用32位二进制建议把archb64和archb32同时加上。规则写完后的加载命令augenrules --load auditctl -l还有一个细节常被忽略/etc/audit/auditd.conf中的日志轮转参数。默认max_log_file如果太小日志会快速轮转等到测评现场要取证时历史审计记录已经被覆盖。建议至少配置max_log_file 100 num_logs 5 max_log_file_action ROTATE100MB一个文件、保留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。等保场景下审计日志传输建议用TCPUDP存在丢包风险一旦关键日志在传输途中丢失审计链就不完整。有条件的环境还可以给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 todayjournald日志占用过多是常见问题它默认会写进/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 1ip_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运行用户创建的文件就可能对组和其他人开放写权限长期累积出可被利用的文件。检查umaskgrep umask /etc/profile /etc/bash.bashrc /etc/csh.login对于长期不修改的敏感文件可以设置防篡改属性chattr i /etc/ssh/sshd_config lsattr /etc/ssh/sshd_configi属性让文件不可写、不可删除、不可改名。这里有一个大坑如果对/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_filter1sysctl查出来还是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这个脚本把测评组进场最关心的一批证据集中输出整改后也可以用来做回归验证。但脚本只是工具真正的闭环在管理动作上。每次测评整改都会产生一份问题清单建议用如下表格式的跟踪方式推进每个风险项对应整改命令和验证命令责任到人验证完成才允许关闭风险项整改命令验证命令口令复杂度不足修改common-password启用pwquality新设弱口令测试是否被拒绝未配置登录失败锁定在common-auth加入faillock配置连续输错密码后账号被锁定auditd未运行systemctl enable --now auditdauditctl -s查看状态高危端口开放从SuSEfirewall2移除端口并重启ss -tlnp确认端口不在监听日志留存不足配置logrotate与rsyslog转发远端服务器确认收到日志这块表格可以直接挪到自查报告里测评时作为整改证据附上。实际做下来等保测评最大的价值不是那一纸结论而是迫使团队把散落在各台服务器上的安全配置统一成基线并验证它们真实生效。我在实际操练中的体会是SLES的等保测评命令本身都不复杂难的是把配置和业务场景协调好。每次整改前把改动先做成带注释的脚本放到统一目录保存测评前跑一遍自查脚本输出结果打上日期归档。这个习惯看起来笨拙但能在复测时少解释很多。另一个实用建议是所有命令输出尽量现场留存时间戳可以用script命令记录会话或者直接把结果重定向到带日期的文件里最后统一打包作为测评附件比事后翻记录找证据要高效得多。等保测评最终查的是运维习惯命令只是把习惯暴露出来的工具把基线固化下来下一次整改自然就快。