等保2.0三级Linux基线加固须按发行版分层落地，不可套用统一脚本；需区分CentOS/麒麟/Debian在PAM配置、SSH认证逻辑、日志路径、服务管理等方面的差异，结合真实运行状态与策略生效范围闭环验证。
等保2.0三级对Linux操作系统基线加固不是“套模板打补丁”，而是必须按发行版特性、内核行为、初始化系统差异分层落地——直接在CentOS 7上跑通的脚本，在麒麟V10或Debian 12上大概率失效，甚至引发服务中断。
账户与口令策略：/etc/shadow空密码检查不能只靠pwdck
很多团队用pwdck -n ALL查空口令，但该命令在Debian/Ubuntu默认未安装，且在麒麟V10上会因PAM模块加载顺序误报。真实风险点是/etc/shadow第二字段为空（如root::18932:0:99999:7:::），这代表无需密码即可登录。
- 通用检查命令：
awk -F: '$2 == "" {print $1}' /etc/shadow，返回非空即存在高危账户 - 口令复杂度必须区分发行版：
RedHat/CentOS 7+走pam_pwquality.so参数（配置在/etc/pam.d/system-auth），而Debian 12+已迁移到/etc/security/pwquality.conf，参数名和默认值不同（如minlenvsminclass） - 麒麟V10强制启用国密SM2证书链后，
sshd若启用了PubkeyAuthentication yes但未同步配置SM2密钥格式支持，会导致合法密钥登录失败，被误判为“认证机制未启用”
SSH远程访问控制：PermitRootLogin不是唯一判断依据
PermitRootLogin prohibit-password在RedHat系常被当作“已禁用root远程登录”的依据，但在麒麟V10中，即使该项为yes，只要/etc/pam.d/sshd中存在auth [success=done] pam_succeed_if.so user != root规则，实际仍禁止root登录——等保测评工具若只读配置文件不验证PAM链，就会漏判。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 必须组合验证：
sshd -t && systemctl show sshd | grep -E "(PermitRootLogin|PasswordAuthentication)"+grep -v "^#" /etc/pam.d/sshd | grep -i "user != root" - Debian默认关闭root SSH登录，但保留
sudo组免密权限（%sudo ALL=(ALL:ALL) NOPASSWD: ALL），等保要求“特权账户操作需二次认证”，此处必须删掉NOPASSWD或改用auth required pam_wheel.so use_uid - SSH加密算法必须显式禁用
ssh-rsa（SHA-1签名），否则不满足等保三级“使用国密或至少SHA-2以上摘要算法”要求；命令：echo "HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-512" >> /etc/ssh/sshd_config
日志审计与服务精简：systemd服务状态不能只看systemctl list-unit-files
systemctl list-unit-files --state=enabled只显示“设为开机启动”的服务，但等保三级要求“关闭非必要服务”，关键是要识别当前运行中、且无业务依赖的服务。比如systemd-resolved在Debian 12默认启用，但若DNS解析全走/etc/resolv.conf静态配置，它就是冗余进程，且其UDP 53端口可能被扫描器利用。
- 真实运行服务清单：
systemctl list-units --type=service --state=running --no-pager - 日志审计必须覆盖
authpriv和local6（等保明确要求记录用户登录、权限变更、关键命令执行），rsyslog配置中*.* /var/log/messages不够，要单独加：auth,authpriv.* /var/log/secure+local6.* /var/log/audit.log - 麒麟V10启用SELinux后，
auditd日志路径可能被重定向到/var/log/audit/audit.log而非/var/log/messages，等保检查若只扫/var/log/secure会漏掉关键审计事件
防火墙策略与USB外设：nftables规则顺序影响默认拒绝生效
等保三级明确要求“默认拒绝所有入站连接，仅放行必要端口”。但很多团队用nft add rule ip filter input tcp dport {22, 443} accept后就认为完成，却忽略了规则插入位置——若该规则插在drop规则之后，实际永远不生效。
- 必须确认默认策略：
nft list chain ip filter input，确保drop是最后一条，或显式设置nft add rule ip filter input counter drop作为兜底 - USB外设禁用不能只卸载
usb-storage模块，还要屏蔽usbhid（键盘鼠标除外）和cdc_ether（USB网卡），并在/etc/modprobe.d/blacklist.conf中写install usb-storage /bin/true，防止热插拔时自动加载 - RedHat 8+和麒麟V10默认启用
firewalld，但等保测评工具常扫描iptables-save输出，此时需用firewall-cmd --direct --get-all-rules导出原始规则，再转换为iptables格式供检查
最易被忽略的是“加固前后一致性验证”：比如修改/etc/login.defs后，新创建用户才生效，已有用户仍沿用旧策略；又比如禁用telnet服务后，若未同步清理/etc/xinetd.d/telnet配置，下次xinetd重载仍可能拉起进程。等保三级不是一次配置完事，而是要建立“配置项→生效范围→验证方式”的闭环映射。
