做等保测评现在碰到 Kylin Linux 的概率越来越高尤其是银河麒麟高级服务器操作系统 V10 的 Halberd 代号版本。很多同事还在用 CentOS 7 的老一套命令去采集证据结果经常bash: xxx: command not found或者文件路径对不上、PAM 策略结构不一样现场非常尴尬。这篇文章我把在 Kylin Linux 上做等保测评沉淀下来的命令清单、核查思路和踩过的坑完整梳理一遍既适合等保测评工程师照着采集证据也适合运维自己先做一轮基线自查。先说一句心理准备Kylin Linux 虽然和 RHEL/CentOS 系命令兼容度很高但“V10”这个叫法下面有太多变体各行业拿到的版本、内核、预装组件都不一样。所以我下面所有命令到了现场第一件事还是先看版本输出确认再执行。测评采集的原则永远是只读优先、留痕为准不要为了验证一个策略现场去改生产配置。1. 测评第一步摸清系统身份与测评边界1.1 先拿到准确的版本信息等保测评报告里“主机名称、操作系统型号、内核版本、补丁级别”是必填项但很多人只抄一个桌面图标或者hostnamectl就完事这样不够严谨。我建议第一个命令组合如下cat /etc/os-release cat /etc/kylin-release uname -a hostnamectl rpm -q kernel --last/etc/os-release是标准入口VERSION、PRETTY_NAME都会写明是 Kylin Linux Advanced Server V10。/etc/kylin-release则是麒麟特有的发行版信息通常还会带中文化的产品名和里程碑版本。两者都要采集别偷懒只取其中一个。uname -a看内核版本rpm -q kernel --last看内核安装记录。V10 Halberd 这个代号经常让新手困惑因为不同分发批次的内核小版本差异很大后面的ss、auditctl参数兼容性也可能受影响。判断测评对象到底是不是 Halberd最靠谱的就是看/etc/kylin-release里的Milestone和内核版本不要凭安装时选的选项猜。1.2 确认测评边界和网络角色等保测评不是只看操作系统这一个点还要搞清楚主机在业务里的角色是 Web 服务器、数据库服务器、还是管理终端、运维跳板机。先采集网络层信息ip -o -4 addr show ip -o -4 route show hostname cat /etc/hostname cat /etc/hostshostname和/etc/hostname各看一次有些环境里hostname输出的结果被 DHCP 或 cloud-init 改过但配置文件还是旧值。两者不一致本身就是一个写进报告的配置管理问题。同一台机器如果同时跑 Nginx 和 MySQL等保测评的主机层面命令只覆盖操作系统业务应用层面的“身份鉴别、访问控制、安全审计”还要再结合中间件和数据库产品去核查。所以先确认角色能避免后面多采集一堆用不上的输出。1.3 取证过程保持只读这一点很关键。测评命令仍然可能残留风险比如lastb读日志、auditctl -l列出规则这些都是只读的。但有些管理员习惯顺手passwd改密码、chage调过期时间、setenforce 1开 SELinux在生产环境里就是事故。我的做法是先开一个会话录制工具script -q /tmp/evidence_$(hostname)_$(date %Y%m%d).log然后在这个会话里执行后面所有命令把所有输出按时间顺序留在同一个文件里。执行完exit退出 script再把日志打包。这样可以形成一条完整证据链后续写测评报告、应对复测质询都有底。如果现场需要验证登录失败锁定策略绝对不要拿生产账号试错临时创建一个测试账号测完立刻删除并清除对应/etc/shadow条目。这些操作提前和被测方负责人当面确认别自己默默执行。2. 身份鉴别专项账号口令与登录策略核查2.1 账号状态、空口令和口令过期身份鉴别是等保测评里权重很高的地方。第一步是看账号本身有没有空口令、有没有异常账户、root 之外还有哪些 UID 0 用户。Kylin 上我常用这几条awk -F: ($2){print empty $1} /etc/shadow awk -F: ($30){print $1} /etc/passwd cat /etc/shadow | cut -d: -f1,2 --output-delimiter - passwd -S --all chage -l root lastlog --time 30/etc/shadow第二列是口令哈希。如果整段是!!或!一般代表锁定或未设密码如果这一列为空等于这个账号无密码可登这个优先级最高必须立刻整改。但注意第二列是!!的不一定就是坏账号很多系统服务账号默认就是锁定状态测评结论里要区分“锁定”和“空口令”。chage -l root看口令有效期重点检查Maximum number of days between password change。等保三级一般要求口令 90 天以内定期更换如果输出显示99999那就是没有过期策略需要整改。还有一个高频坑passwd -S --all在部分 Kylin 版本上可能不支持--all会报错。现场不要慌用循环或者直接chage -l 用户挨个看更稳妥。口令哈希本身属于敏感信息日志脱敏阶段要把cut -d: -f1,2里的哈希字段用****替换避免直接留在证据文档里。2.2 密码复杂度与失败锁定策略密码策略主要看三个文件/etc/login.defs、/etc/security/pwquality.conf、/etc/pam.d/system-auth。命令组合如下grep -E PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_MIN_LEN|PASS_WARN_AGE /etc/login.defs cat /etc/security/pwquality.conf grep -E pam_pwquality|pam_faillock|pam_unix /etc/pam.d/system-auth cat /etc/security/faillock.confpwquality.conf里的minlen、dcredit、ucredit、lcredit、maxrepeat决定了密码复杂度。常见配置应该是minlen9以上同时包含大小写字母、数字和特殊字符中至少两类。faillock.conf里的deny5和unlock_time900对应等保“登录失败处理”要求连续失败 5 次锁定15 分钟后解锁。但在 Kylin 上有个很常见的坑/etc/pam.d/system-auth和/etc/pam.d/password-auth两套 PAM 配置不一致。SSH 登录走system-auth本地终端/gdm 登录走password-auth测评时如果只查了一个文件很容易漏判。我都是在现场两条grep都跑一遍然后对比差异。另一个坑是pwquality.conf里的参数和 PAM 行内参数同时存在。实际生效规则以 PAM 行中的参数为主配置文件里的可能不起作用。测评判定策略是否达标时应该以 PAM 行内参数和实际测试结果为准不要只看配置文件。2.3 会话超时、Root 远程登录与双因子登录会话超时、root 远程 ssh 限制、双因子认证这几项在 Kylin 上先看这里grep -E TMOUT|HISTSIZE|HISTFILESIZE /etc/profile /etc/bashrc /etc/profile.d/*.sh grep -E ^PermitRootLogin|^Protocol|^ClientAliveInterval|^ClientAliveCountMax /etc/ssh/sshd_config grep -r pam_google_authenticator /etc/pam.d/TMOUT决定空闲多久自动退出等保测评通用要求是空闲会话 15 分钟内超时断开。SSH 侧ClientAliveInterval和ClientAliveCountMax配合可以踢掉长期无效连接。PermitRootLogin如果输出是yes很多人直接判不符合。但等保测评不是“一刀切”如果系统中存在堡垒机或管护平台且 root 被严格纳管也可以作为补偿或整改建议。测评报告里写“部分符合”时一定要附上现场证据。双因子认证在飞腾、鲲鹏平台上的落地方式和 x86 又不一样有的政企环境部署了自家的 CA/USB-KEY 组件。如果grep pam_google_authenticator没有输出不要急着说不满足再看看系统里有没有其他 pam 模块比如pam_pkcs11。3. 访问控制专项权限、sudo、外设与防泄露核查3.1 特权账号、sudo 委派和 SUID 提权风险访问控制里最常出问题的就是特权账号失控。Kylin 上我推荐这个命令组合awk -F: ($30){print $1} /etc/passwd ls -l /etc/sudoers visudo -c grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/ sudo -l -l find / -xdev -perm -4000 -type f -exec ls -l {} \; 2/dev/null | head -n 50/etc/passwd里 UID 0 的账号理论上只能有 root 本身如果看到toor、backup这类 UID 0 账号属于严重风险不能含糊直接记为高风险。sudo -l -l可以看到当前用户被授予的 sudo 权限。重点关注“普通用户是否可以不输密码切到 root”。NOPASSWD不是完全不能有比如备份脚本专用账号、监控账号有特定白名单命令是可以理解的但大范围放开就不行。find扫 SUID 文件时输出会很长Kylin 自带的一些系统文件如pkexec、mount、su本身就有 SUID 位是正常现象。测评的重点不是“数量多不多”而是有没有业务目录下异常新增的 SUID 文件比如/tmp、/home、/opt下的可疑文件。3.2 强制访问控制、防火墙和安全参数访问控制层面不能只看 DAC 权限Kylin 的 SELinux 状态和防火墙策略也是必查项getenforce sestatus -v cat /etc/selinux/config systemctl status firewalld firewall-cmd --list-all --permanent cat /etc/fstab | grep -vE ^#|^$ | grep -E ext4|xfs|tmpfsgetenforce返回Enforcing是理想状态返回Permissive或Disabled要结合系统实际使用情况记录整改项。但现场绝对不要为了测评好看去执行setenforce 1很多国产业务组件在 Kylin 上本来就不兼容 SELinux一位改了可能导致服务起不来。firewall-cmd --list-all --permanent看的是永久规则配合--runtime-to-permanent状态判断。如果发现规则列表空空如也又开了防火墙服务说明要么是策略没落盘要么是运维故意放空。需要继续检查ss -lntup里实际监听端口对照防火墙放行端口找出“监听端口多、防火墙放行少”的管理失控点。3.3 移动介质管控与文件共享防泄露等保三级明确提到防移动介质滥用和非法外联Kylin 上我习惯这样核查lsusb systemctl status usbguard 2/dev/null grep -rE blacklist.*usb-storage|install.*usb-storage /etc/modprobe.d/ cat /etc/fstab | grep -E ext4|xfs systemctl list-unit-files | grep -E nfs-server|smb|samba ss -lntup | grep -E :445 |:2049 如果/etc/modprobe.d/下有install usb-storage /bin/true或者blacklist usb-storage说明系统层面已经禁用 USB 存储这是加分项。有些 Kylin 环境预装了usbguard它比 modprobe 黑名单更灵活可以只允许特定 USB 设备识别。NFS/SMB 共享服务是涉密信息泄露的高发点。ss -lntup如果看到 445 或 2049 在监听要去查看共享目录范围和挂载权限。尤其是把整个/、/home共享出去的配置测评可以直接给高风险。4. 安全审计专项auditd、Syslog 和登录痕迹4.1 auditd 是否在跑、规则有没有落盘安全审计是所有等保测评里最见功底的部分。Kylin 的审计主链路是 auditd先看服务状态再看规则是否持久化systemctl status auditd auditctl -s auditctl -l | wc -l auditctl -l | head -n 20 cat /etc/audit/auditd.conf ls -l /etc/audit/rules.d/auditctl -l输出的是当前实时生效规则一个非常典型的故障是规则只是在命令行里显式加载了但没有写到/etc/audit/rules.d/*.rules重启后全部失效。测评记录里一定要同时采集auditctl -l和/etc/audit/rules.d/的文件内容对比一致才证明审计规则“持久化”了。常见关键规则包括-w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/sudoers -p wa -k identity -w /etc/ssh/sshd_config -p wa -k sshd -a always,exit -S time settimeofday adjtimex clock_settime -k time-change-k设置的 key 是事件分类标识后续用ausearch -k identity直接查。如果auditctl -l里只有几个默认项没有监视 passwd、shadow、sudoers 这些关键文件审计覆盖度就是明显不足的。4.2 登录日志、失败尝试和命令历史登录痕迹核查靠这几个地方last -n 20 lastb -n 20 journalctl -u sshd --since 7 days ago 2/dev/null | grep -E Failed|Accepted | tail -n 30 grep -E Failed password|Accepted password /var/log/secure | tail -n 30 cat /var/log/cron | tail -n 50last读/var/log/wtmplastb读/var/log/btmp。如果这两个文件不存在或者时间为空说明日志轮转策略有坑审计材料不完整。lastb输出大量失败记录时不只是“暴力破解痕迹”还要看有没有对应的防护措施。journalctl -u sshd是更细粒度的源适合和/var/log/secure交叉验证。Kylin 系统中/var/log/secure文件可能出现权限混乱、被截断、甚至缺失的情况必须用 journalctl 做交叉核对。命令历史这块检查/etc/profile里HISTSIZE和HISTFILESIZE同时查看/root/.bash_history的时间戳和权限权限过大或历史记录被清空都要记录。4.3 日志留存周期、logrotate 与远程日志日志留存时长是判定项不只是功能开关。检查命令如下grep -E max_log_file|num_logs|space_left|max_log_file_action /etc/audit/auditd.conf cat /etc/logrotate.conf | grep -E rotate|weekly|daily grep -vE ^#|^$ /etc/rsyslog.conf | tail -n 30 ls -l /var/log/messages /var/log/secure /var/log/audit 2/dev/null/etc/audit/auditd.conf里的max_log_file和num_logs决定本地审计日志能滚多少份比如max_log_file 200、num_logs 5能留 1G 左右。如果max_log_file_action ignore磁盘满了之后 auditd 可能静默丢事件这个比没有规则更危险。logrotate配置决定/var/log/messages等普通日志保留多久。单机日志保留不足 6 个月就是硬伤。远程日志方案一般是 rsyslog 转发到日志中心/etc/rsyslog.conf里能看到*.* 192.168.x.x类似行。在国产化信创环境里远程日志中心极可能是企业内部的 syslog 平台或合规平台现场不要看到 IP 就去 ping 或访问只需要在配置层面记录转发是否启用。5. 入侵防范与恶意代码防范专项进程、服务、补丁与自启动5.1 当前连接、进程和自启动排查入侵防范要求的重心是“能发现、能阻断”。Kylin 上从这几个入口采集ss -lntup ss -unap ps -eo pid,ppid,user,stat,cmd --sort-%cpu | head -n 30 systemctl list-unit-files --typeservice --stateenabled cat /etc/rc.d/rc.local 2/dev/null crontab -l ls -l /etc/cron.d/ss -lntup比netstat更可靠能同时看到进程名和 PID。重点关注两个方向一是监听在0.0.0.0或::上的服务是不是应该对外网开二是有没有进程在大量对外连接。一个 Nginx 进程突然连着外部非标准端口这在等保测评里就是需要重点标记的入侵迹象。systemctl list-unit-files --typeservice --stateenabled输出可能很长重点关注自启动服务里有没有异常名字。Kylin 还会自带一些安全组件不要一看到不认识的kysec相关服务就紧张先看它是否属于产品预装再和运维确认用途。rc.local和crontab里有wget、curl、base64解码类命令片段是很危险的信号尤其是bash -i /dev/tcp/...这类明显反弹模式可以直接进高风险管理流程。5.2 软件包完整性与补丁更新状况Kylin 是 rpm 体系软件完整性检测优先用 rpm:rpm -Va --nodigest 2/dev/null | head -n 50 rpm -qa --last | head -n 20 yum history list all 2/dev/null | head -n 30 cat /etc/yum.repos.d/*.repo | grep -E baseurl|gpgcheck|enabledrpm -Va的输出里第一列有M表示文件权限变了S表示文件大小变了5表示 md5 变了。重点看这几个字符组合如果/bin/ls、/usr/bin/ss这类基础命令被变更属于非常强的入侵指示。但单独一个文件状态变化还需结合变更时间判断不能完全证明被篡改。rpm -qa --last按安装时间倒序看软件包更新节奏。如果系统已经上线一年补丁包还停留在初始版本说明没有持续维护。/etc/yum.repos.d/里的仓库配置文件重点看gpgcheck1和enabled1的组合。Kylin 的 yum 源很多是本地或内网源不能因为仓库地址不是公共网络就判不合格确认仓库更新时间和安全配置才是重点。5.3 防病毒、EDR 与文件完整性工具恶意代码防范这一块在信创主机上是常见失分项。先看有没有装终端防护或扫描类软件rpm -qa | grep -Ei aide|tripwire|chkrootkit|rkhunter|clamav|edr|agent systemctl list-unit-files | grep -Ei aide|tripwire|edr|agent|scan ls /var/lib/aide/ 2/dev/null如果在全部软件包里都搜不到任何防病毒、终端检测产品那“恶意代码防范”测评项就是空白。有些单位采购了商业 EDR 平台但 agent 没有安装在这一台上主机层就是不受管控的测评记录中必须如实体现。如果预装了 AIDE重点不是跑一次扫描而是确认扫描基线和定时任务。首次执行/usr/sbin/aide --init会生成一个数据库之后/usr/sbin/aide --check才比对这个数据库。注意不要为了测评现场重新--init那等于把过去的基线心理上作废了真正有用的证据是“首次初始化时间早于最近一次告警时间”。这个逻辑要在报告里写清楚。6. 数据保密性、完整性与备份恢复核查6.1 分区挂载选项与磁盘加密数据安全等保要求里包含数据的存储介质要有保密性和完整性保护。挂载选项和加密情况通过下面几条看findmnt -lo TARGET,SOURCE,FSTYPE,OPTIONS lsblk -f blkid | grep crypto_LUKS cat /etc/fstab | grep -vE ^#|^$findmnt -lo OPTIONS会显示挂载选项比如/home有没有nosuid、nodev、noexec。尤其是/tmp和/dev/shm如果既没noexec也没nodev存在被利用执行恶意脚本的风险这是现场高频失分项。磁盘加密看blkid的输出中是否有crypto_LUKS。如果数据盘没加密测评可以记录为“数据保密性不足”。这里提醒一句cryptsetup luksDump 设备可以在线读取 LUKS 头信息是安全的但对已经挂载的在线分区做任何cryptsetup写操作都要禁止生产环境误操作会导致整个文件系统无法访问。Kylin 安装时如果没开全盘加密后期在线加密几乎不可行测评结论只能按现状记录并给出备份再加密的整改方向。6.2 文件完整性与关键文件防篡改除了 rpm 验包还要看关键文件是否被加了防篡改属性/usr/sbin/aide --check 2/dev/null | tail -n 20 lsattr /var/log/wtmp /var/log/secure /etc/shadow 2/dev/null ls -ld /var/log/journal /var/log/audit /var/log/audit/ 2/dev/null ls -l /etc/shadowlsattr显示带a属性的文件只能追加不能覆盖带i属性的文件完全不能被修改。如果/var/log/wtmp或/var/log/secure被chattr a保护算加分项但如果/etc/shadow被加了无法修改的i属性反而会影响正常的密码重置运维可能会因此失效这种也要记录为运维风险而不是安全优点。/etc/shadow的权限严格来说应为----------或 root 可读写也就是-rw-------之类。如果看到其他用户组有读权限高风险直接记录。6.3 备份策略、备份产物和恢复演练证据数据备份恢复在等保测评里经常被“有备份脚本”一句话带过实际上必须有证据crontab -l ls -lhR /backup /data/backup 2/dev/null | head -n 60 find /backup /data/backup -name *.tar* -mtime -30 -exec ls -lh {} \; 2/dev/null cat /etc/rsnapshot.conf 2/dev/null现场有两层检查第一层看备份任务是否存在第二层看备份产物是否真的生成了。只看到 crontab 里有tar命令但/backup下没有最近的文件等于没有备份。要特别注意 tar 命令是否排除了不该排除的目录比如备份脚本里--exclude/home结果业务数据放在/home备份就是空转。恢复演练通常不属于操作系统命令采集范围但如果系统中有备份脚本我建议顺手做一次tar -tf验证包结构。真正证明备份可用至少要在测试环境恢复一次再写结论。如果现场没有演练记录测评报告里应给出整改建议如果连备份产物时间都是旧的问题等级再上一档。7. 现场采集收尾证据整理与 Kylin 特有坑盘点7.1 证据打包与完整性留痕所有命令输出采集完成后建议统一打包并计算哈希cd /tmp tar cJf evidence_$(hostname)_$(date %Y%m%d).tar.xz evidence_*.log sha256sum evidence_$(hostname)_$(date %Y%m%d).tar.xz这个哈希值同步记录到测评工作底稿和邮件里后续如果被客户质疑数据被改动能立刻自证。很多测评机构的底稿其实只保存终端截图没有一个可检索的原始命令输出遇到复测或者边界纠纷时非常被动。我现在已经习惯每个项目保留一个这样的 evidence 包。7.2 我总结的 Kylin 测评高频坑第一个是/etc/kylin-release的位置和内容在不同批次上不完全一致有的 V10 版本还保留了/etc/redhat-release的兼容文件但 VERSION 字段可能不准确。所以版本判断永远先看/etc/os-release和uname -r不要相信一两个文件。第二个是 auditd 规则落盘问题。很多 Kylin 环境里auditctl -l能看到规则但/etc/audit/rules.d/是空的说明规则是人工临时加载的重启即丢。这一个坑我至少见过三次测评报告里如果只写“当前有规则”复测时会被打得很难看。第三个是 PAM 策略文件不一致。Kylin 图形环境、SSH 远程登录、本地终端可能走不同 PAM 链路分别以system-auth、password-auth、smartcard-auth为辅。测评身份鉴别策略时只查system-auth是不够的必须把三个文件一起查并对比否则现场容易误判策略达标。第四个是关于“Kylin 自带安全组件”。部分银河麒麟 V10 带了 kysec 相关安全策略组件会集成它自己的访问控制机制。测评时不要一看到多出来的 LSM 或安全模块就当成不符合项先理解组件用途结合厂商技术手册记录。测评结论是否客观取决于你能否分清系统预置机制和真实的配置缺陷这一点在国产系统上尤其需要经验。在大量 Kylin 测评项目里我最大的体会是命令本身并不复杂难的是把每个输出和等保条款对应起来并且能区分“系统差异”和“真实漏洞”。上面的命令清单可以直接抄走当工作底稿用但前提是在每台具体主机上先跑第一步确认版本和边界。这样即便命令细节有出入你也能在第一时间发现问题而不是把自己的判断建立在另一个运维群的二手经验上。