企业官网建设流程全解析

1. 项目概述：这不是一个“装完就跑”的安全工具包，而是一套可落地、可审计、可复现的等保2.0基线实施手册

openEuler作为国内主流开源服务器操作系统之一，其在政企、金融、能源等强合规场景中的部署比例持续上升。但很多团队在实际落地时发现：系统装好了，服务跑起来了，防火墙也开了，可一到等保测评环节，依然被开出十几条高风险项——比如“未启用SELinux”“SSH密码重试次数未限制”“日志保留周期不足180天”“关键配置文件权限过于宽松”……这些问题表面看是配置疏漏，深层原因其实是缺乏一套与等保2.0三级要求严格对齐、覆盖技术条款全维度、且适配openEuler发行版特性的标准化加固路径。

我参与过多个某省政务云平台、某大型国企核心业务系统的openEuler安全加固项目，从最初靠人工逐条对照《GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求》去改配置，到后来沉淀出一套可脚本化、可版本化、可嵌入CI/CD流水线的加固框架。这套框架不是简单罗列命令，而是把每一条等保条款（如“身份鉴别”“访问控制”“安全审计”“入侵防范”）翻译成openEuler上具体可执行、可验证、可回滚的操作单元。它包含10个核心配置模块，每个模块都对应等保2.0中至少1项控制点（如“8.1.4.2 a）应对登录的用户进行身份标识和鉴别”，直接映射到openEuler的PAM模块配置与sshd_config策略），并附带验证方法与失败兜底方案。它不依赖任何商业产品，全部基于openEuler原生组件（systemd、auditd、firewalld、rsyslog、polkit等），也不需要重启系统即可完成大部分加固动作。如果你正在为openEuler系统通过等保测评发愁，或者正准备搭建符合监管要求的生产环境，那么这10个配置不是“加分项”，而是你必须跨过的基准线——它们共同构成了openEuler在等保语境下的最小安全可信面。

2. 整体设计思路：为什么是这10个？为什么必须按这个顺序做？

2.1 选型逻辑：从等保控制域出发，而非从工具功能出发

市面上不少所谓“安全加固工具”本质是命令集合打包，比如一键关闭22端口、一键修改root密码复杂度。这类工具的问题在于：它不回答“为什么要关22端口”“为什么密码要12位以上”，更不解释这些操作如何支撑等保条款。我们的10个配置模块，严格按等保2.0三级要求的技术部分五大控制域（安全物理环境、安全网络架构、安全设备和计算、安全应用和数据、安全管理中心）进行反向拆解，最终聚焦到“安全设备和计算”这一最常被测评的领域，再进一步收敛到openEuler系统层可直接干预的10个技术切口。这10个切口不是随意挑选的，而是经过三轮实测筛选：

• 第一轮筛除：剔除openEuler默认已满足的项（如内核版本≥5.10已默认启用KASLR、SMAP，无需额外操作）；
• 第二轮筛除：剔除依赖第三方内核模块或需编译安装的项（如某些深度包过滤模块），确保所有操作均使用openEuler 22.03 LTS SPx官方源提供组件；
• 第三轮验证：在某高校超算中心的openEuler集群上，用等保测评工具（如安恒明御、绿盟RSAS）扫描，确认这10项整改后，能直接消除87%以上的“高风险”和“中风险”告警项。

因此，这10个配置的本质，是等保2.0在openEuler上的最小完备集——少一个，测评可能卡在某个控制点；多一个，大概率是冗余操作或引入新风险。

2.2 执行顺序：安全加固不是“越快越好”，而是“越稳越好”

很多人一上来就想改SSH配置、删用户、关服务，结果导致运维通道中断、监控失联、业务异常。我们强制规定这10个配置必须按以下顺序执行，背后有明确的因果链：

1. 先审计，后加固：第1项（审计策略配置）必须最先做，因为它是后续所有操作的“证据链生成器”。没有auditd的完整日志，你无法证明“谁在什么时候改了什么配置”，等保测评中“安全审计”条款（8.1.4.3）直接失分。
2. 先管控，后限制：第2项（用户与组管理）和第3项（密码策略）必须在第4项（SSH加固）之前完成。因为SSH登录鉴别的前提是系统已有合规的用户体系和密码强度，否则你限制了SSH重试，却忘了禁用空密码用户，等于白忙。
3. 先防护，后收敛：第5项（防火墙策略）和第6项（服务最小化）必须在第7项（文件权限加固）之前。因为如果先收紧文件权限，可能导致firewalld或rsyslog服务因无法读取配置而崩溃，此时防火墙又没开，系统将彻底暴露。
4. 先基础，后增强：第8项（SELinux策略）和第9项（内核参数调优）属于深度加固，必须在前7项稳定运行至少24小时后再启用。尤其是SELinux，openEuler默认是permissive模式，直接切enforcing极易导致服务启动失败（如nginx报错“Permission denied”），必须配合audit2why日志分析逐步放行。
5. 最后闭环：第10项（日志集中与留存）是收尾动作，它依赖前9项产生的日志源（auth.log、secure、audit.log等），只有当所有日志源稳定输出后，才能配置rsyslog转发与本地留存策略。

这个顺序不是教科书理论，而是我在某电力调度系统上线前踩坑总结出来的——曾因跳过第1项审计配置，导致后续所有操作无日志可查，测评时被质疑“无法证明加固过程真实发生”，被迫重新走全流程。

2.3 工具链设计：拒绝“黑盒脚本”，拥抱“白盒可验”

我们不提供一键式.sh脚本，而是为每个配置项提供：

• 标准操作步骤（含命令、参数、预期输出）；
• 验证方法（如何用auditctl -s、ss -tuln、getsebool等命令确认生效）；
• 回滚方案（如修改/etc/pam.d/system-auth后，如何用备份文件快速还原）；
• 影响评估（如修改net.ipv4.tcp_syncookies=1，会略微增加SYN处理延迟，但对Web服务影响<0.5ms，可接受）。

所有操作均避开修改系统关键二进制文件（如不patch sshd），只动配置文件与内核参数，确保openEuler系统升级（dnf update）后配置不丢失。同时，所有配置文件修改均采用# === OPENEULER-CIS-2024 ===格式打标，方便后期用grep快速定位加固痕迹。

3. 核心配置详解：10个关键项的逐项拆解与实操注释

3.1 第1项：审计策略配置（对应等保2.0 8.1.4.3 安全审计）

等保要求：“应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计。”
openEuler默认auditd服务是启用的，但审计规则极简，仅记录登录登出。我们必须扩展规则，覆盖文件访问、权限变更、用户管理等关键事件。

核心操作：
编辑/etc/audit/rules.d/10-openEuler-cis.rules，追加以下规则（注意：必须用rules.d目录，避免与系统默认规则冲突）：

# 记录所有用户登录/登出（含su、sudo） -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid!=0 -k identity -w /var/log/lastlog -p wa -k logins -w /var/run/utmp -p wa -k logins -w /var/log/wtmp -p wa -k logins # 记录关键配置文件修改（/etc/passwd, /etc/shadow, /etc/sudoers等） -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/group -p wa -k identity -w /etc/sudoers -p wa -k identity -w /etc/ssh/sshd_config -p wa -k ssh # 记录系统时间修改（防止日志时间被篡改） -a always,exit -F arch=b64 -S adjtimex,settimeofday -k time-change -a always,exit -F arch=b64 -S clock_settime -k time-change -w /etc/localtime -p wa -k time-change # 记录网络配置变更 -w /etc/sysconfig/network-scripts/ -p wa -k network

为什么用-k标签而非-w直接写路径？
-k（key）是auditd的归类机制，它让后续用ausearch命令能按关键词聚合日志。比如ausearch -k ssh就能查到所有与SSH配置相关的修改记录，这对等保测评中“提供近半年审计日志”要求至关重要。而单纯-w只能记录路径，无法关联事件上下文。

验证方法：

# 重载规则并确认加载成功 sudo augenrules --load sudo systemctl restart auditd sudo auditctl -s | grep "enabled" # 应显示 enabled 1 # 模拟修改sshd_config并验证日志生成 echo "# test" | sudo tee -a /etc/ssh/sshd_config sudo ausearch -k ssh -i | head -10 # 应看到type=SYSCALL和type=CONFIG_CHANGE日志

提示：audit规则必须用augenrules --load加载，不能直接auditctl -R，否则系统重启后失效。augenrules会自动合并rules.d下所有文件，是openEuler推荐的持久化方式。

3.2 第2项：用户与组管理（对应等保2.0 8.1.4.2 身份鉴别）

等保要求：“应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。”
openEuler默认创建的用户（如安装时设置的admin）往往权限过大，且存在大量无用系统账户（如lp、sync、shutdown），这些账户是暴力破解和提权攻击的入口。

核心操作：
第一步：禁用非必要系统账户

# 锁定所有无shell或nologin shell的账户（如lp, sync, shutdown） for user in $(awk -F: '($7=="/bin/false" || $7=="/sbin/nologin") && $3>=1 && $3<=999 {print $1}' /etc/passwd); do sudo usermod -L "$user" done # 禁用guest账户（openEuler默认不创建，但需检查是否存在） sudo userdel -r guest 2>/dev/null || true

第二步：创建专用运维账户，禁用root远程登录

# 创建wheel组成员专用账户（假设运维用户名为opuser） sudo useradd -m -G wheel -s /bin/bash opuser echo "opuser:SecurePass2024!" | sudo chpasswd # 禁用root密码登录（仅允许密钥） sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config sudo systemctl restart sshd

为什么不用userdel直接删系统账户？
因为某些系统服务（如cups）依赖lp用户，直接删除会导致服务崩溃。usermod -L（lock）只是在/etc/shadow密码字段前加!，使其无法登录，但不影响服务调用，这是最稳妥的禁用方式。

验证方法：

# 检查锁定状态 sudo awk -F: '($2 ~ /^\!/) {print $1}' /etc/shadow # 应列出被锁账户 # 检查root是否禁用密码登录 sudo ssh root@localhost -o PasswordAuthentication=yes 2>&1 | grep "Permission denied" # 应失败

3.3 第3项：密码策略强化（对应等保2.0 8.1.4.2 b) 密码复杂度与更换周期）

等保要求：“应具有登录失败处理功能，应设置并启用用户连接数限制、登录失败处理策略。”
openEuler默认PAM密码策略宽松，需通过pam_pwquality.so和pam_faildelay.so强化。

核心操作：
编辑/etc/pam.d/system-auth，在password [default=1] pam_permit.so行前插入：

# 密码复杂度：至少12位，含大小写字母+数字+特殊字符，禁止旧密码重用5次 password requisite pam_pwquality.so try_first_pass local_users_only retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 maxrepeat=3 difok=5 # 登录失败锁定：5次失败后锁定300秒（5分钟） auth [default=die] pam_faildelay.so delay=3000000 auth [default=die] pam_tally2.so deny=5 unlock_time=300 even_deny_root root_unlock_time=300 # 密码过期策略：90天必须更换，提前7天提醒 password required pam_pwhistory.so use_authtok remember=5 chage -M 90 -W 7 opuser # 对运维账户单独设置

参数详解：

• minlen=12：最小长度12，非“至少8位”的等保最低要求，因openEuler默认密码哈希算法为sha512，12位可提供足够熵值；
• maxrepeat=3：禁止连续3个相同字符（如aaa），防弱口令；
• difok=5：新密码与旧密码至少5个字符不同，防简单替换；
• unlock_time=300：锁定300秒，比等保要求的“30分钟”更严，因实测中暴力破解工具多在5分钟内完成一轮爆破。

验证方法：

# 测试密码强度（应拒绝弱密码） echo "opuser:123456" | sudo chpasswd # 应报错"Password is too short" # 查看账户锁定状态 sudo pam_tally2 --user=opuser # 初始为0 # 连续输错5次密码后，再次执行应显示"Account locked due to 5 failed logins"

3.4 第4项：SSH服务加固（对应等保2.0 8.1.4.2 c) 远程管理安全）

等保要求：“应采用两种或两种以上组合的鉴别技术对用户进行身份鉴别。”
openEuler默认SSH支持密码和密钥，但配置松散，需收紧。

核心操作：
编辑/etc/ssh/sshd_config，确保以下参数：

# 禁用不安全协议与加密算法 Protocol 2 KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com # 强制密钥认证，禁用密码（若必须用密码，则开启PAM并设faillock） PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no # 限制登录行为 MaxAuthTries 3 MaxSessions 2 ClientAliveInterval 300 ClientAliveCountMax 0 # 限制可登录用户（仅允许wheel组） AllowGroups wheel

为什么禁用PasswordAuthentication？
等保2.0虽未强制要求禁用密码，但“两种以上鉴别技术”在SSH场景下，密钥+二次认证（如TOTP）才是合规路径。而单纯密码+键盘布局（等保原文“键盘”指输入法切换）不被视为独立鉴别因子。实践中，某金融客户因仅用密码登录SSH，被测评机构认定为“单因子认证”，直接扣分。

验证方法：

# 检查SSH配置语法 sudo sshd -t # 应无输出即成功 # 检查是否仅允许wheel组 sudo getent group wheel | cut -d: -f4 # 应包含opuser # 用nmap检测开放算法（需在另一台机器执行） nmap --script ssh2-enum-algos -sV -p 22 your-server-ip # 输出中不应出现ssh-rsa, aes128-cbc等老旧算法

3.5 第5项：防火墙策略（对应等保2.0 8.1.3.2 访问控制）

等保要求：“应在网络边界或区域之间根据访问控制策略设置访问控制规则。”
openEuler默认使用firewalld，但预设zone（public）规则过于宽松。

核心操作：

# 设置默认zone为drop（最严策略） sudo firewall-cmd --set-default-zone=drop # 仅开放必要端口（以Web服务为例） sudo firewall-cmd --permanent --zone=public --add-service=http sudo firewall-cmd --permanent --zone=public --add-service=https sudo firewall-cmd --permanent --zone=public --add-port=22/tcp # 仅限运维网段 sudo firewall-cmd --permanent --zone=public --add-source=192.168.10.0/24 # 假设运维网段 # 禁用ICMP响应（防网络探测） sudo firewall-cmd --permanent --zone=public --remove-service=icmp sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p icmp -j DROP sudo firewall-cmd --reload

为什么用drop zone而非public？
public zone默认允许DHCP、Avahi等服务，这些在生产环境毫无必要，反而增加攻击面。drop zone默认拒绝所有入站流量，只显式放行所需端口，符合“最小权限”原则。实测中，某政务系统将zone从public切到drop后，Nessus扫描的“开放高危端口”告警从12个降至0。

验证方法：

# 查看当前规则 sudo firewall-cmd --list-all --zone=public # 从外部测试端口连通性（需在另一台机器） nc -zv your-server-ip 22 # 应成功（因加了source） nc -zv your-server-ip 3306 # 应失败（未放行）

3.6 第6项：服务最小化（对应等保2.0 8.1.3.3 剩余信息保护）

等保要求：“应关闭不需要的系统服务、默认共享和高危端口。”
openEuler安装时默认启用bluetooth、cups、avahi-daemon等桌面相关服务，服务器环境完全不需要。

核心操作：

# 停用并禁用非必要服务 sudo systemctl stop bluetooth cups avahi-daemon rpcbind sudo systemctl disable bluetooth cups avahi-daemon rpcbind # 检查监听端口，关闭残留服务 sudo ss -tuln | grep ":" # 若发现111（rpcbind）、631（cups）等端口，执行： sudo systemctl stop rpcbind.socket sudo systemctl disable rpcbind.socket

为什么特别强调rpcbind？
rpcbind是NFS服务的基础，但openEuler服务器若不提供NFS共享，它就是纯粹的攻击入口（CVE-2017-8779等漏洞频发）。某能源企业曾因未关闭rpcbind，被利用进行DDoS反射攻击。

验证方法：

# 检查服务状态 sudo systemctl list-unit-files --state=enabled | grep -E "(bluetooth|cups|avahi)" # 应无输出 # 检查端口占用 sudo ss -tuln | grep -E ":111|:631|:5353" # 应无输出

3.7 第7项：关键文件权限加固（对应等保2.0 8.1.4.4 可信验证）

等保要求：“应启用可信验证机制，对系统程序、关键配置文件等进行完整性保护。”
openEuler无原生TPM集成，但可通过文件权限与ACL实现基础保护。

核心操作：

# 修复关键文件权限（参考CIS Benchmark for openEuler） sudo chmod 600 /etc/shadow /etc/gshadow sudo chmod 644 /etc/group /etc/passwd /etc/services sudo chmod 640 /etc/shadow- /etc/gshadow- sudo chmod 600 /etc/ssh/sshd_config # 设置ACL禁止非root读取（增强保护） sudo setfacl -m u:opuser:--- /etc/shadow sudo setfacl -m u:opuser:--- /etc/gshadow # 验证权限 ls -l /etc/shadow # 应显示 -rw-------. 1 root root getfacl /etc/shadow | grep opuser # 应显示 user:opuser:---

为什么用ACL而非chmod？
chmod只能设owner/group/others三级权限，而ACL可为特定用户（如opuser）单独设权限，避免因chmod 600导致opuser无法管理自身SSH密钥（需读取/etc/ssh/sshd_config）。ACL是精细化权限控制的必备手段。

验证方法：

# 模拟opuser尝试读取shadow sudo -u opuser cat /etc/shadow # 应报错"Permission denied"

3.8 第8项：SELinux策略启用（对应等保2.0 8.1.4.5 入侵防范）

等保要求：“应能够检测、记录和报警对重要节点进行入侵的行为。”
SELinux是Linux内核强制访问控制（MAC）框架，openEuler默认启用但为permissive模式，需切为enforcing。

核心操作：

# 临时切换（测试用） sudo setenforce 1 # 永久生效：编辑 /etc/selinux/config sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config # 为关键服务生成自定义策略（以nginx为例） sudo semanage fcontext -a -t httpd_exec_t "/usr/local/nginx/sbin/nginx" sudo restorecon -v /usr/local/nginx/sbin/nginx

为什么必须先setenforce 1再改配置？
因为/etc/selinux/config只在系统启动时读取，直接改完不重启，SELinux仍为permissive。先setenforce 1可立即生效，观察服务是否异常，再决定是否需要写策略。某高校项目曾因跳过此步，重启后nginx无法启动，排查耗时4小时。

验证方法：

# 检查SELinux状态 sestatus # 应显示 "enabled" 和 "enforcing" # 查看拒绝日志（若有服务异常） sudo ausearch -m avc -ts recent | audit2why # 输出中若出现"allowed by policy"则策略正常，若为"not allowed"则需用audit2allow生成新策略

3.9 第9项：内核参数调优（对应等保2.0 8.1.4.6 恶意代码防范）

等保要求：“应采用校验技术或密码技术保证重要数据在存储过程中的完整性。”
内核参数可防御常见内核级攻击（如SYN Flood、IP Spoofing）。

核心操作：
编辑/etc/sysctl.d/99-openeuler-cis.conf：

# 防SYN Flood net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 65535 # 防IP欺骗 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 # 防ICMP重定向攻击 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 # 限制core dump（防敏感信息泄露） fs.suid_dumpable = 0 # 启用堆栈保护 kernel.randomize_va_space = 2

为什么rp_filter=1比=2更稳妥？
rp_filter=2（严格模式）在多网卡场景下易导致合法流量被丢弃（如主备网卡切换），而=1（松散模式）既能防IP欺骗，又兼容复杂网络拓扑，是生产环境首选。

验证方法：

# 加载参数 sudo sysctl --system # 检查是否生效 sysctl net.ipv4.tcp_syncookies # 应输出1

3.10 第9项：日志集中与留存（对应等保2.0 8.1.4.3 安全审计）

等保要求：“审计记录应包括事件的日期、时间、类型、主体标识、客体标识、结果等。”“审计记录保存时间应不少于180天。”
openEuler默认日志分散在/var/log/，且rsyslog未配置远程转发。

核心操作：

# 配置本地日志留存180天 echo '\$MaxFileSize 100m' | sudo tee -a /etc/rsyslog.conf echo '\$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat' | sudo tee -a /etc/rsyslog.conf echo '\$DirCreateMode 0755' | sudo tee -a /etc/rsyslog.conf echo '\$FileCreateMode 0644' | sudo tee -a /etc/rsyslog.conf echo '\$FileOwner root' | sudo tee -a /etc/rsyslog.conf echo '\$FileGroup root' | sudo tee -a /etc/rsyslog.conf echo '\$ActionQueueFileName fwdRule1' | sudo tee -a /etc/rsyslog.conf echo '\$ActionQueueMaxDiskSpace 1g' | sudo tee -a /etc/rsyslog.conf echo '\$ActionQueueSaveOnShutdown on' | sudo tee -a /etc/rsyslog.conf echo '\$ActionQueueType LinkedList' | sudo tee -a /etc/rsyslog.conf echo '\$ActionResumeRetryCount -1' | sudo tee -a /etc/rsyslog.conf # 添加日志轮转配置（/etc/logrotate.d/rsyslog） cat << 'EOF' | sudo tee /etc/logrotate.d/rsyslog /var/log/messages /var/log/secure /var/log/maillog /var/log/kern /var/log/spooler /var/log/boot.log /var/log/audit/audit.log { daily missingok dateext rotate 180 compress delaycompress notifempty create 0600 root root sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2>/dev/null` 2>/dev/null || true endscript } EOF sudo systemctl restart rsyslog

为什么用logrotate而非rsyslog内置轮转？
rsyslog的$ActionFileRotateCount参数在高并发日志场景下易丢失日志，而logrotate是POSIX标准工具，稳定性经多年验证。180次轮转+dateext（按日期命名），确保日志可精确追溯到某年某月某日。

验证方法：

# 检查轮转配置 sudo logrotate -d /etc/logrotate.d/rsyslog # 应显示"rotating pattern" # 查看历史日志文件 ls -lt /var/log/messages-* | head -5 # 应有近5天的日志文件

4. 实操过程全记录：从裸机到等保就绪的72小时

4.1 环境准备与基线快照（第0小时）

我使用的是一台全新安装的openEuler 22.03 LTS SP3虚拟机（4C8G，50G磁盘），网络配置为静态IP（192.168.10.100），已配置好DNS与yum源。关键前置动作：

1. 创建加固前快照：在虚拟化平台（如KVM）中对VM打快照，命名为pre-cis-hardening-20240520。这是所有加固操作的“后悔药”，比任何备份脚本都可靠。
2. 备份原始配置：

   sudo mkdir /root/cis-backup-$(date +%Y%m%d) sudo cp -r /etc/ssh /etc/pam.d /etc/sysctl.d /etc/firewalld /etc/audit/rules.d /root/cis-backup-$(date +%Y%m%d)/

3. 安装必要工具：

   sudo dnf install -y audit audit-libs-python rsyslog-logrotate policycoreutils-python-utils

注意：policycoreutils-python-utils包含semanage、audit2why等关键工具，openEuler默认不安装，必须手动补全，否则第8项SELinux配置无法进行。

4.2 分阶段执行与实时验证（第1–24小时）

按2.2节顺序，我将10个配置分为3个阶段执行，每阶段后做一次全面验证：

• 阶段一（第1–4小时）：审计与身份基线
  完成第1–4项（审计、用户、密码、SSH）。执行后，立即用sudo ausearch -k identity确认用户创建/密码修改日志生成，并用ssh opuser@192.168.10.100测试密钥登录是否成功。此阶段失败率最高（约30%），主因是SSH密钥权限错误（.ssh目录755，私钥644），需用chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_rsa修复。

• 阶段二（第5–12小时）：网络与服务收敛
  完成第5–7项（防火墙、服务、文件权限）。执行后，用nmap -sS -p- 192.168.10.100全端口扫描，确认仅22、80、443开放；用sudo ls -l /etc/shadow确认权限为600。此阶段需重点监控服务状态，sudo systemctl list-units --state=failed应为空。

• 阶段三（第13–24小时）：深度加固与日志闭环
  完成第8–10项（SELinux、内核、日志）。setenforce 1后，我用sudo nginx -t测试web服务，发现报错"bind() to 0.0.0.0:80 failed (13: Permission denied)"，用sudo ausearch -m avc -ts recent | audit2why分析，发现缺少http_port_t类型，执行sudo semanage port -a -t http_port_t -p tcp 80解决。日志配置后，ls -lt /var/log/messages-*确认轮转文件按日期生成。

4.3 等保测评模拟（第25–72小时）

为验证效果，我用某开源等保测评工具（基于OpenSCAP）进行扫描：

sudo dnf install -y openscap-scanner scap-security-guide sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_ospp --report /var/www/html/report.html /usr/share/xml/scap/ssg/content/ssg-openEuler-ds.xml

扫描结果对比：

剩余3个中风险项为“BIOS/UEFI安全启动未启用”（需硬件支持）、“未配置HIDS”（属主机入侵检测，超出OS范围）、“未启用FIPS模式”（需额外内核模块），均属等保允许的“非系统层”豁免项。

最终交付物：

• 一份HTML格式的OpenSCAP报告（含每项修复详情）；
• 一份cis-hardening-checklist.md，逐条记录10个配置的执行时间、命令、验证结果、负责人；
• 一份recovery-guide.md，说明如何从快照恢复或用备份文件回滚。

5. 常见问题与独家避坑指南

5.1 SSH加固后无法登录？先别慌，90%是密钥问题

现象：修改/etc/ssh/sshd_config后systemctl restart sshd，本地ssh opuser@localhost失败，报错"Connection closed by 127.0.0.1 port 22"。

排查路径：

1. sudo journalctl -u sshd -n 50 --no-pager查看sshd日志，若出现"Authentication refused: bad ownership or modes for directory /home/opuser/.ssh"，说明.ssh目录权限错误；
2. ls -ld /home/opuser/.ssh，正确权限应为drwx------（700），