做等保测评这些年跑过最多的操作系统就是 CentOS 系后来遇到 Kylin Linux Advanced Server V10 的次数越来越多。一开始我也犯过懒觉得银河麒麟既然是 CentOS 的兼容路线直接拿通用命令过去跑就行结果现场就翻过车有的检查项结果和 CentOS 完全不一样有的命令在这个版本上早就不见了。后来我专门维护了一套针对麒麟 V10 的等保测评命令清单从系统识别到身份鉴别、安全审计、入侵防范、数据备份一个层面一个层面过。这篇文章就把这套清单拿出来顺便把踩过的坑和现场应对办法写清楚。适合刚接手等保测评的运维也适合要把整改项讲给开发听的老伙计。1. 进场先做系统识别版本认不清后面全白干1.1 银河麒麟 V10 的版本怎么认测评进场后的第一件事不急着敲审计命令而是先把系统家底摸清楚。麒麟的版本命名看着差不多实际差异很大比如同样是 V10SP1 和 SP2 在 PAM 模块、auditd 规则、包管理器行为上都有区别如果按老一套 CentOS 习惯去查很容易查空或者查错。这几条命令是我每次必跑的cat /etc/os-release cat /etc/kylin-release uname -a getconf LONG_BIT lscpu hostnamectl/etc/os-release里能看到发行版名称和版本号常见输出是Kylin Linux Advanced Server V10镜像代号出现Halberd海鲨字样也不奇怪这是 V10 系列的常见代号SP1、SP2 镜像包里经常能看到。/etc/kylin-release则是麒麟特有的标识文件CentOS 上没有看到它基本上就能确认是银河麒麟服务器版而不是 CentOS 换壳。uname -a和getconf LONG_BIT用来确认内核版本和系统位数。麒麟 V10 用的内核一般是 4.19 分支比如4.19.90-24.4.v2101.ky10.x86_64这里的v2101是内部版本号ky10代表 Kylin 10。架构上要注意碰到 aarch64飞腾、鲲鹏和 x86_64海光、兆芯两套环境后面安装审计工具、检查内核参数时的命令差异不大但包名和路径偶尔有区别记下来能省很多事。hostnamectl不只是看主机名还能顺便把系统时区和时间同步状态带出来。等保测评报告里有时区、时间同步这种记录项主机时间漂得太厉害后面查审计日志的时间轴就会对不上所以我一般在开头就把时间偏差记下来后面解释日志时间戳的时候有个底。1.2 测评层面与命令清单怎么对照等保 2.0 的基本要求按“一个中心、三重防护”展开落到标准文本里包括安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心、安全管理制度等大部分。行业里常说的“十个层面”一般是把管理制度、人员、建设、运维这些管理类要求也算进去。命令行核查能覆盖的主要是安全计算环境身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范、数据完整性与保密性、数据备份恢复、安全区域边界网络访问控制、边界防护以及安全管理中心里跟集中日志相关的部分。物理安全靠现场看机房管理制度靠访谈和查文档这些命令帮不上忙。所以别再指望一台机器敲几行命令就把整个等保测完命令的作用是把主机层面的证据链补扎实。2. 身份鉴别与访问控制主机层面最容易丢分的两项2.1 密码策略和登录失败锁定核查身份鉴别是安全计算环境里权重很高的检查项测评报告里通常要求口令长度、复杂度、定期更换、失败锁定都有明确配置。我核查时先看/etc/login.defs里的全局策略grep -E PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE /etc/login.defsPASS_MAX_DAYS是密码最长有效期三级要求一般是 90 天以内PASS_MIN_DAYS是两次改密最短间隔防止用户连续改密回到原密码PASS_WARN_AGE是过期提醒天数7 天是常见配置。这几个值只对后续新改的密码生效所以要结合chage -l 用户名看具体账号的实际生效日期避免出现“全局配好了个别账号早超期”的情况。密码复杂度配置在 PAM 层麒麟 V10 沿用了 RHEL 系的做法重点看system-auth和password-auth两个文件grep -E pam_pwquality|pam_cracklib|pam_faillock|pam_tally2 /etc/pam.d/system-auth /etc/pam.d/password-authpam_pwquality或者老的pam_cracklib管复杂度pam_faillock管登录失败锁定。麒麟 V10 上pam_faillock已经取代了老版本的pam_tally2如果看到pam_tally2还在用反而要重点确认是不是没有升级干净。/etc/security/pwquality.conf里的minlen、dcredit、lcredit、ucredit、ocredit才是真正决定复杂度的地方minlen8配合至少包含大小写字母、数字、特殊字符中三类是比较常见的整改目标。登录失败锁定这块我还会顺手确认锁定次数和锁定时间。用pam_faillock的时候规则通常写在system-auth的auth段和account段deny5、unlock_time300是常见配置。2.2 空口令、弱口令与会话超时核查空口令账号是测评组最爱抓的问题也最容易整改。检查方式很简单awk -F: ($2){print 空口令账号: $1} /etc/shadow正常情况下这条命令不该有任何输出有输出就是硬伤。另外要配合检查 UID 为 0 的非 root 账号awk -F: ($30){print $1} /etc/passwd如果跑出多个用户名说明有人把某些账号的 UID 改成了 0这在访问控制里属于权限过大的问题。会话超时主要用于防止终端长时间无人操作被滥用检查点一般在全局的/etc/profile和用户级的 bash 配置里grep -E TMOUT /etc/profile /etc/bashrc /etc/profile.d/* 2/dev/nullTMOUT600表示 10 分钟无操作自动注销等保要求通常是 15 分钟内。注意有些麒麟 V10 版本还在/etc/profile.d/下面放了umask.sh之类的文件里面也可能设置TMOUT所以要带目录扫一遍不要只看主文件。2.3 用户权限、su 和 sudo 管控核查访问控制层面重点看三件事能不能随便切 root、sudo 授权范围是否合理、敏感文件权限是否过宽。su 限制看/etc/pam.d/su里有没有启用pam_wheel.so启用后只有 wheel 组成员才能用 su 切换 rootgrep pam_wheel /etc/pam.d/su grep wheel /etc/group很多机器把pam_wheel.so注释掉了所有普通用户都能 su这基本算一个问题项。sudo 授权看/etc/sudoers和/etc/sudoers.d/用visudo -c校验语法然后列出授权明细grep -Ev ^#|^$ /etc/sudoers ls -l /etc/sudoers.d/重点看是否授权了ALL(ALL) NOPASSWD: ALL这种完全放开的规则。测评报告里如果出现这种授权而业务上说不清理由审计人员会直接记风险。最后别忘了看一眼全局 umask。grep umask /etc/profile /etc/bashrc如果默认值是0022就好某些场景下为了安全会设成0027。这一步经常被忽略但“默认权限收紧”在整改建议里写起来很直观。3. 安全审计与日志管理拿得出手的证据全在这里3.1 内核审计服务 auditd 核查安全审计是等保测评组非常看重的模块很多得分点都落在审计日志能不能覆盖关键用户行为和命令执行上。麒麟 V10 自带auditd但默认不一定启动我进场先看服务状态systemctl status auditd --no-pager如果 auditd 没起来后面的规则、日志全白查。服务正常后查看规则auditctl -l规则里常见的包括对/etc/passwd、/etc/shadow、/etc/sudoers的写操作审计以及USER_LOGIN、USER_ERR等事件类型。用auditctl -l看到的规则是在/etc/audit/rules.d/audit.rules里定义的永久规则要写文件而不是临时加规则否则重启就丢。日志是否在正常记录可以用ausearch按时间倒查ausearch -ts today -m USER_LOGIN ausearch -ts today -m USER_END有输出说明登录类事件在落日志。再确认日志文件ls -l /var/log/audit/audit.log如果这个日志常年不涨说明审计规则可能没有真正覆盖到登录动作空有服务没有内容容易被测评组挑刺。3.2 系统日志、远程日志与轮转策略核查syslog 层面看的是/etc/rsyslog.conf和/etc/rsyslog.d/下的配置grep -Ev ^#|^$ /etc/rsyslog.conf ls -l /etc/rsyslog.d/重点确认有没有远程日志接收配置。等保三级要求日志集中收集没配*.* 日志服务器地址这类转发规则的基本都要记一条。另外注意麒麟 V10 上有时候日志不在熟悉的/var/log/messages而是在/var/log/kern.log或按模块分开的目录查的时候用ls -l /var/log/先看看实际文件别拿 CentOS 的路径硬套。日志留存策略看 logrotategrep -Ev ^#|^$ /etc/logrotate.confrotate 6、weekly、compress这样的配置保证日志有成体系的轮转。测评要求日志至少保存半年以上可以算一下轮转次数和单文件大小如果按天轮转、保留 30 份那就是一个月明显不够要留 6 个月rotate 180以上才凑合。3.3 日志权限与保护要求日志权限也常被忽略。/var/log/audit/audit.log如果普通用户可读可能泄露敏感信息测评组对审计日志的完整性要求是不能被未授权删除、篡改。我用下面几条命令快速核对ls -l /var/log/audit/audit.log ls -l /var/log/messages /var/log/secure 2/dev/null正常情况下这些文件是root:root、权限600或640。如果出现644甚至666直接记录成问题项。运维人员常用chattr a给日志加追加属性防删除看到这种保护要专门记下来属于加分项和整改成效证据。另外麒麟 V10 有的版本里/var/log/secure路径存在但内容为空别慌先看/var/log/auth.log是否在写。现场判断“用哪个日志文件”最靠谱的方法是ls -lt /var/log/ | head看最近时间有更新的文件是哪些再结合 rsyslog 配置里authpriv.*指向的路径确认。4. 入侵防范、恶意代码防范与网络边界核查4.1 防火墙与高危端口服务检查网络边界和区域边界核查命令上看的是防火墙状态和端口监听。麒麟 V10 一般自带 firewalld查看状态systemctl status firewalld --no-pager firewall-cmd --state如果 firewalld 没运行再看 iptables 是否残留规则iptables -L -n然后检查本机监听端口ss -lntpss -lntp的输出里重点看0.0.0.0和*这类监听地址凡是业务上说不清楚的端口比如 3306、6379、8099 裸奔在公网网卡上基本上一查一个准。测评报告里最常见的整改项就是数据库端口没有限制访问来源。危险服务也要扫一遍telnet、rlogin、rsh 这些明文协议服务只要在监听就是硬伤。systemctl list-unit-files --typeservice --stateenabled | grep -E telnet|rlogin|rsh4.2 内核安全参数与补丁更新检查入侵防范不只看防火墙内核参数也是测评组关注点。我常用这几个核查项sysctl kernel.randomize_va_space sysctl fs.suid_dumpable sysctl net.ipv4.tcp_syncookies sysctl net.ipv4.conf.all.accept_redirects sysctl net.ipv4.ip_forward sysctl kernel.dmesg_restrictkernel.randomize_va_space应该是 2fs.suid_dumpable应该是 0net.ipv4.tcp_syncookies应该是 1net.ipv4.ip_forward正常服务器应该为 0。这些值如果不对直接关联到操作系统加固的整改项。注意这些参数写在/etc/sysctl.conf或/etc/sysctl.d/下sysctl -a看到的是当前生效值还要确认配置文件里的持久化设置否则重启后打回原形。补丁更新情况yum check-update --quiet | head -50麒麟 V10 的包管理是 yum/dnf 兼容体系yum check-update能列出有待更新补丁。测评组看到大量安全补丁未装通常会记“存在系统漏洞风险”。但刚进场时别一上来就更新先记录状态更新操作要跟客户确认维护窗口。4.3 完整性校验与加固软件核查文件完整性校验是恶意代码防范里经常提到的手段。rpm 系可以快速校验系统文件rpm -Va 2/dev/null | head -30有输出说明某些被管理的文件校验值变了可能是软件升级也可能是被改过。不过rpm -Va全量跑很慢几百台机器的时候挑关键路径跑或者只跑/etc/shadow、/etc/passwd所在包即可。专用完整性工具看有没有装 aiderpm -qa | grep aide没装的话整改建议里写“安装 aide 并初始化基线”是比较标准的操作。主机加固层面我一般用下面命令看看有没有安全代理或防病毒组件在运行systemctl list-units --typeservice --staterunning | grep -iE agent|guarded|security|defend ps -ef | grep -iE defend|agent | grep -v grep发现这类组件存在测评记录里要写清楚名称和运行状态。如果组件没在工作不要自行启动或关闭先沟通客户确认策略。我碰到过现场因为加固软件占内存被运维手动停了的情况这类问题记录下来让客户去协调比自己动手改安全代理稳妥得多。5. 数据安全性与备份恢复核查5.1 远程管理链路与敏感文件保护数据完整性和保密性层面先看远程管理方式安不安全。SSH 是最常见的入口直接看配置grep -Ev ^#|^$ /etc/ssh/sshd_config重点确认Protocol 2、PermitRootLogin、PasswordAuthentication、MaxAuthTries这几项。Protocol 1是明文旧协议现在基本不会出现但看到了就是严重问题PermitRootLogin yes要确认是否有必要一般都建议改成no或prohibit-passwordMaxAuthTries建议 5 以内防止暴力猜解。再查敏感文件的权限ls -l /etc/shadow /etc/passwd /etc/sudoers/etc/shadow正常是000或--------如果变成 644就是剩余信息保护和保密性双重问题。还有带 SUID/SGID 位的文件列表用find / -perm -4000 -type f扫一遍然后跟业务核对哪些确实需要特权位多出来的要降权限。这个扫描在文件多的服务器上会有点慢建议限定在/usr、/bin、/sbin等系统目录别全盘扫。5.2 备份任务与恢复验证数据备份恢复主要是访谈加查配置。命令上先看计划任务crontab -l ls -l /etc/cron.d/ /etc/cron.daily/ /etc/cron.weekly/有备份脚本的会把脚本内容打开看一眼确认备份目标、保留周期、是否做异地/离线备份。备份目录的权限也要看ls -ld /backup /data/backup 2/dev/null如果备份目录普通用户可写备份文件可能被篡改这是一条数据完整性问题。测评组经常会问“备份有没有定期恢复验证”这个命令查不出来只能通过访谈记录。我会把恢复演练记录作为一个访谈问题写进记录表让客户提供最近一次的恢复测试文档。5.3 剩余信息保护核查剩余信息保护是个容易被忽略的层面主要看敏感信息的残留。比如用户删除时是否清空了 home 目录、临时文件目录是否积累了敏感数据。现场能做的快速检查ls -la /home/ | grep -E ^d.*(old|bak|backup) find /tmp /var/tmp -maxdepth 2 -type f 2/dev/null | head -20发现/home下残留已离职员工的目录或者/tmp里有配置文件、导出的库文件就记成剩余信息保护问题。整改建议通常是清理临时文件、设置临时目录清理策略以及离职人员数据统一删除或归档。6. 测评现场最容易翻车的几个细节与应对办法6.1 版本差异导致的命令失效我在麒麟 V10 上踩过最典型的坑有两个。一个是pam_tally2已经不存在用老命令查登录锁定会直接报“命令未找到”正确的做法是用pam_faillock相关命令或者直接查system-auth配置文件。另一个是/var/log/secure有时候是空文件真正的认证日志在/var/log/messages或/var/log/audit/audit.log里硬按 CentOS 路径去查会把结果漏掉。遇到这类情况我的习惯是先看几样东西再下结论cat /etc/os-release确认具体版本ls -l /var/log/看实际日志文件man 配置文件名确认语法格式。不要一查不到就写“不适用”或直接判不符合先确认是不是查错地方了。6.2 现场命令记录要留下时间戳证据测评不只是敲命令证据记录同样重要。我之前吃过亏现场查完一批配置回办公室整理报告时发现某个输出截图看不清时间客户又不承认当时是那个状态。后来我固定用一个记录脚本每一条命令输出都带时间和命令名function kylin_check() { echo $(date %F %T) [$1] /tmp/kylin_audit.log eval $2 /tmp/kylin_audit.log 21 echo /tmp/kylin_audit.log } kylin_check 系统版本 cat /etc/os-release kylin_check 密码策略 grep -E PASS_MAX_DAYS|PASS_MIN_LEN /etc/login.defs kylin_check auditd状态 systemctl status auditd --no-pager | head -5这样整场测评下来所有命令、输出、执行时间都在一个日志文件里出报告时直接引用客户、测评机构两边都认。执行完把/tmp/kylin_audit.log拷到自己工作目录留存即可。6.3 多台主机测评的优先级安排一次测评面对几十台主机的时候时间永远不够用。我给现场的先后顺序一般是先跑身份鉴别和访问控制相关命令这部分的失分项最好写、最好整改再跑安全审计和日志相关命令因为这些要结合业务判断需要留出沟通时间最后跑数据备份和加固检查。每台机器的时间控制在 10 到 15 分钟先拿输出再在中午或收工前统一跟客户确认疑问项。另外现场尽量用普通账号 sudo执行只读命令不要直接切 root避免改到系统配置。测评组不是来做整改的只负责查和执行只读命令真要改配置列成整改项交给客户运维去处理。这个边界一定要守住。最后再说个小习惯每次进场前我会把上面这些命令整理成一个脚本先在一台测试机跑一遍确认输出格式符合预期再带到现场。这个做法帮我挡掉了至少三次现场事故——比如有次脚本里把chage -l写成了chage -L这俩看着像但一个是查询、一个是锁定账号真要跑错了后果不堪设想。测评命令这东西熟没关系但每次还是值得花五分钟过一遍再落地。