openEuler 系统等保安全基线配置实战：账号、SSH、权限、审计与内核加固

一、前言

在企业服务器、云计算平台及业务系统建设过程中，操作系统安全是网络安全等级保护建设的重要基础。openEuler 作为面向企业级场景的 Linux 发行版，广泛应用于服务器、云平台及基础设施环境。

在等保建设过程中，除了安装系统补丁、部署防火墙和防病毒软件，还需要对操作系统自身进行安全基线配置，降低弱口令、越权访问、暴力破解、配置错误及日志缺失等安全风险。

本文以 openEuler Linux 服务器为例，介绍一套具有实操性的安全基线配置方法，主要包括：

• 账号口令安全加固
• SSH 远程管理安全
• 用户权限与文件权限控制
• 系统日志与安全审计
• 防火墙及网络访问控制
• 内核参数安全加固
• SELinux 安全机制
• 配置检查与整改验收

本文参考 openEuler 官方安全加固文档，并结合常见的服务器运维场景进行整理。实际执行时，应根据具体 openEuler 版本、业务需求和适用的等保要求进行调整。

二、等保安全基线建设思路

2.1 什么是安全基线

安全基线是针对操作系统、数据库、中间件及网络设备制定的一组最低安全配置要求。

对于 Linux 服务器，安全基线主要关注以下方面：

2.2 等保建设的基本原则

安全基线建设应遵循以下原则：

1. 最小权限原则：用户和服务只获得完成工作所必需的权限。
2. 默认拒绝原则：网络访问、账号授权和服务开放应以必要性为前提。
3. 可审计原则：重要登录、权限变更及管理操作应保留必要记录。
4. 纵深防御原则：结合操作系统、网络设备、身份认证和集中日志系统构建防护体系。
5. 可验证原则：每项配置都应有对应的检查命令和整改记录。

需要注意，安全基线并不等同于等保测评。正式建设应以适用的国家标准、系统定级结果、测评范围和实际业务风险为依据。

三、实施前准备

3.1 确认系统版本

首先确认服务器的操作系统版本、内核版本和运行环境。

cat /etc/openEuler-release
uname -r
uname -m

查看系统当前运行状态：

uptime
systemctl --failed
df -h
free -h

不同 openEuler 版本的 PAM、SSH、SELinux 及安全加固工具可能存在差异，不能直接假定所有配置文件和参数完全一致。

3.2 备份关键配置

执行安全加固之前，先备份关键配置文件。

mkdir -p /root/security-backup

cp -a /etc/ssh /root/security-backup/
cp -a /etc/pam.d /root/security-backup/
cp -a /etc/login.defs /root/security-backup/
cp -a /etc/security /root/security-backup/
cp -a /etc/sysctl.conf /root/security-backup/

如果系统使用 /etc/sysctl.d/ 中的独立配置文件，还应备份相关文件。

建议在生产环境执行前创建虚拟机快照、云盘快照或经过验证的系统备份，并准备控制台登录方式。

3.3 建立整改记录

每项基线至少记录以下信息：

• 基线编号及检查要求
• 检查命令与检查结果
• 当前配置及目标配置
• 整改人员与整改时间
• 整改后的验证结果
• 风险说明及例外审批

这样既便于日常巡检，也便于后续审计和等保测评材料整理。

四、账号与口令安全加固

账号口令是操作系统安全防护的第一道防线。弱口令、长期不变的密码和过度授权账号，都是常见的安全风险。

4.1 检查系统账号

检查本地账号信息：

cat /etc/passwd
cat /etc/shadow

注意：/etc/shadow 包含口令哈希及账号口令状态等敏感信息，不应随意对外提供或写入普通日志。

检查可交互登录的账号：

awk -F: '$7 !~ /(nologin|false)$/ {
    print $1, $7
}' /etc/passwd

对不需要登录的服务账号，应确认其登录 shell 已按业务要求限制。不要简单地将所有系统账号批量修改为 nologin，否则可能影响系统服务正常运行。

4.2 配置口令有效期

编辑 /etc/login.defs：

vi /etc/login.defs

可参考以下配置：

PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 7

参数含义：

• PASS_MAX_DAYS：口令最长有效期。
• PASS_MIN_DAYS：两次修改口令之间的最小间隔。
• PASS_WARN_AGE：口令到期前的提醒天数。

上述数值是示例基线，不是所有系统必须采用的统一值。还应注意，login.defs 的相关参数主要影响新建账号的默认值，已有用户需要单独检查和调整。

检查用户口令有效期：

chage -l 用户名

针对符合业务策略且需要调整的账号，可执行：

chage -M 90 -m 1 -W 7 用户名

实施前应确认服务账号、应急账号及自动化任务不会因口令过期而中断。

4.3 配置口令复杂度

openEuler 的 PAM 认证配置应依据实际版本进行检查。首先查看相关配置：

grep -RniE 'pam_pwquality|pam_pwhistory|pam_unix' \
    /etc/pam.d /etc/security 2>/dev/null

如果系统已安装并使用 pam_pwquality，可以在其实际生效的配置文件中设置口令策略。例如：

minlen = 12
minclass = 3

其中，minlen 表示口令最小长度，minclass 表示要求包含的字符类别数量。

建议根据风险等级设置合理的口令长度和复杂度，并结合口令历史检查、弱口令检测及多因素认证提高安全性。

重要说明： 不同版本可能通过 system-auth、password-auth 或其他 PAM 配置文件管理认证策略。修改前必须确认实际生效路径，不要盲目覆盖 PAM 文件，以免导致用户无法登录。

4.4 限制登录失败次数

登录失败锁定策略可降低口令暴力猜测风险。

先检查相关 PAM 配置：

grep -RniE 'pam_faillock|pam_tally' /etc/pam.d 2>/dev/null

如果当前版本使用 pam_faillock，可根据该版本的 PAM 配置规范设置失败次数和解锁时间。例如，策略目标可设为：

• 连续认证失败 5 次后锁定。
• 锁定时间为 300 秒。
• 对高权限账号加强监控。
• 保留必要的应急解锁流程。

具体配置必须结合当前版本的 PAM 模块顺序和系统认证栈完成，并使用测试账号验证。

不要在未确认认证链的情况下，直接将通用 PAM 配置片段追加到所有文件中。错误的认证模块顺序可能造成系统登录异常。

五、SSH 远程登录安全加固

SSH 是 Linux 服务器最重要的远程管理入口之一。应限制不必要的登录方式，降低暴力破解和凭据泄露风险。

5.1 修改 SSH 配置

先备份配置文件：

cp -a /etc/ssh/sshd_config \
    /etc/ssh/sshd_config.bak

编辑配置：

vi /etc/ssh/sshd_config

可根据业务需求参考以下配置：

PermitRootLogin no
PermitEmptyPasswords no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 4
LoginGraceTime 60
LogLevel VERBOSE

主要作用：

如果业务必须使用密码认证，应根据实际要求配置 PasswordAuthentication，并配合口令复杂度、登录失败限制和来源地址控制。不要将公钥认证策略与现有自动化运维要求冲突地配置。

5.2 验证 SSH 配置

在重启服务前，先进行语法检查：

sshd -t

查看生效参数：

sshd -T | grep -Ei \
'permitrootlogin|permitemptypasswords|pubkeyauthentication|maxauthtries|loglevel'

确认配置正确后再重载服务：

systemctl reload sshd
systemctl status sshd --no-pager

如果当前服务不支持安全重载，可按实际情况安排重启。

生产环境注意事项：

1. 保留一个已经建立的管理会话。
2. 确认普通管理员账号能够正常登录。
3. 验证公钥、sudo 权限和应急登录通道。
4. 不要在未验证其他登录方式前直接关闭密码认证或 root 登录。

SSH 配置错误可能造成远程管理中断，因此应先验证、后应用。

六、用户权限与文件权限加固

6.1 限制默认文件权限

用户创建文件和目录时，默认权限不应过度开放。

可以在适用的 shell 初始化配置中设置：

umask 077

例如，根据系统统一管理策略，在 /etc/profile 或其他实际生效的全局初始化文件中配置。

重新登录后检查：

umask

预期输出：

0077

在常见的权限计算下，新建普通文件通常为 600，新建目录通常为 700。

需要注意，umask 对部分服务进程、非交互式 shell 和应用程序的具体影响取决于其启动方式，不能将其视为所有进程权限的统一控制手段。

6.2 检查高权限用户

检查 UID 为 0 的账号：

awk -F: '$3 == 0 {
    print $1, $3, $7
}' /etc/passwd

通常只应保留经过批准的 root 账号。发现其他 UID 为 0 的账号时，应确认其来源和用途，不能在未调查前直接删除。

检查 sudo 授权：

visudo -c
grep -RniE '^[[:space:]]*[^#].*ALL' \
    /etc/sudoers /etc/sudoers.d 2>/dev/null

对于普通运维账号，应按照岗位职责分配必要的 sudo 权限，避免无必要的全量 root 授权。

6.3 检查关键文件权限

检查常见系统认证文件：

stat -c '%a %U:%G %n' \
    /etc/passwd \
    /etc/shadow \
    /etc/group \
    /etc/gshadow

应结合发行版默认权限和实际安全要求核对文件属主、属组及权限。

不要不加区分地对整个 /etc 目录执行递归 chmod 或 chown，否则可能破坏系统服务和安全模块的正常运行。

6.4 检查全局可写文件

可使用以下命令检查全局可写文件：

find /etc /usr /opt -xdev -type f \
    -perm -0002 -print 2>/dev/null

检查全局可写目录：

find /etc /usr /opt -xdev -type d \
    -perm -0002 -print 2>/dev/null

发现结果后，应逐项确认用途。某些目录可能需要特殊权限设计，不能仅根据扫描结果批量删除权限。

对于 /tmp 等共享临时目录，应检查是否具备适当的粘滞位权限，例如：

stat -c '%a %U:%G %n' /tmp

通常应结合系统实际配置确认其是否采用 1777 等合理权限设置。

七、系统日志与安全审计

安全审计的目的不仅是记录系统运行状态，还要为异常登录调查、权限变更追溯和安全事件分析提供证据。

7.1 检查日志服务

查看系统日志服务状态：

systemctl status rsyslog --no-pager
systemctl status systemd-journald --no-pager

根据系统日志架构和集中日志要求，确保重要日志得到持续采集、保存和保护。

检查近期系统日志：

journalctl -p warning -b --no-pager

查看 SSH 认证相关日志：

journalctl -u sshd --since today --no-pager

具体日志位置和内容可能因版本及日志配置不同而有所差异。

7.2 启用 auditd

如果系统使用 auditd 进行安全审计，可检查软件和服务状态：

rpm -q audit
systemctl status auditd --no-pager

如果尚未安装且软件源可用，可根据维护流程安装：

dnf install -y audit

确认审计服务能够正常启动后，再配置持久化审计规则。

查看当前规则：

auditctl -l

查看审计状态：

auditctl -s

7.3 配置关键文件审计

可将以下内容作为审计规则设计的示例：

-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k scope
-w /etc/ssh/sshd_config -p wa -k sshd_config

规则用途：

• 监控用户和组信息变更。
• 监控口令文件变更。
• 监控 sudo 授权策略变更。
• 监控 SSH 服务配置变更。

正式部署时，应将规则放入适合当前版本的持久化规则文件，并通过系统规定的方式加载。还应注意规则文件是否已由其他管理工具维护，避免重复配置或覆盖现有规则。

验证审计记录：

ausearch -k identity
ausearch -k scope
ausearch -k sshd_config

注意，文件监控规则并不等于完整的命令执行审计。还需要结合系统架构，评估特权命令、关键系统调用、审计日志保护和集中日志备份等要求。

7.4 保护审计日志

建议至少落实以下要求：

• 限制普通用户读取或修改敏感审计日志。
• 设置合理的日志轮转与保留周期。
• 防止日志磁盘写满导致审计中断。
• 对重要日志实施远程集中存储。
• 对日志服务器实施独立的访问控制。
• 定期验证日志采集、检索和时间同步。

日志文件存在并不代表审计有效，还应验证相关事件是否确实被记录，以及日志是否能够被可靠保存和追溯。

八、防火墙与网络访问控制

8.1 检查监听端口

查看当前监听端口：

ss -lntup

查看已启用的服务：

systemctl list-unit-files --type=service --state=enabled

针对每个监听端口，确认对应服务是否为业务所需，并核实其访问范围。

8.2 检查 firewalld

查看防火墙状态：

systemctl status firewalld --no-pager
firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --list-all

如果服务器使用 firewalld，建议只开放业务确实需要的端口，并结合来源地址限制管理访问。

例如，在已经确认 SSH 服务使用 TCP 22 端口、且不会影响现有规则的情况下，可以在相应区域添加指定来源的访问规则：

firewall-cmd --permanent \
  --zone=public \
  --add-rich-rule='rule family="ipv4" source address="192.0.2.10/32" port port="22" protocol="tcp" accept'

firewall-cmd --reload

示例中的 192.0.2.10 是文档演示地址，部署时必须替换为实际获准的管理来源地址，并确认所在区域与现有规则一致。

如果 SSH 仍依赖开放给所有来源的规则，应先规划规则调整顺序，避免旧规则继续允许未授权访问。

注意： 不要直接关闭防火墙，也不要在远程管理过程中未经验证就切换默认区域或清空规则。云平台安全组、主机防火墙及上游网络 ACL 应统一纳入访问控制设计。

九、内核参数安全加固

内核参数可以帮助减少部分网络攻击面，并改善系统在异常流量情况下的安全性。

编辑独立配置文件：

vi /etc/sysctl.d/99-security-baseline.conf

以下为常见的配置示例：

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_syncookies = 1
kernel.randomize_va_space = 2

参数说明：

应用配置前，应核实当前系统版本、网络角色、路由需求和现有配置。特别是承担路由转发职责的主机，不能直接套用普通业务服务器的网络策略。

确认无冲突后加载：

sysctl --system

验证参数：

sysctl net.ipv4.conf.all.accept_redirects
sysctl net.ipv4.conf.all.accept_source_route
sysctl net.ipv4.tcp_syncookies
sysctl kernel.randomize_va_space

检查结果应与经批准的基线一致。

内核参数并不能替代及时修补漏洞、限制网络访问和监测异常行为等工作。

十、SELinux 安全机制

SELinux 可以通过强制访问控制策略限制进程对文件、端口和其他系统资源的访问，是 Linux 主机纵深防御的重要组成部分。

10.1 检查 SELinux 状态

执行：

getenforce
sestatus

常见状态包括：

• Enforcing：强制执行策略。
• Permissive：记录违规但不强制阻止。
• Disabled：未启用 SELinux。

10.2 启用前评估业务兼容性

对于支持 SELinux 的系统，建议在完成策略验证后采用 Enforcing 模式。

先检查配置：

grep -E '^[[:space:]]*SELINUX=' /etc/selinux/config

如果业务兼容性已经验证，可以按照维护流程修改配置文件：

SELINUX=enforcing

但不能假定仅修改配置文件就会立即切换当前运行状态。运行时切换、策略加载及重启要求应以当前版本文档为准。

切换前建议检查：

• 自定义应用目录和文件的 SELinux 标签。
• Web、中间件及数据库的访问策略。
• 自定义监听端口对应的 SELinux 类型。
• 系统日志中的拒绝记录。

出现业务访问异常时，应分析策略和文件标签问题，不要直接将关闭 SELinux 作为默认解决方案。

十一、服务收敛与漏洞修复

安全基线还应关注不必要的服务、软件包和过期漏洞。

11.1 检查启用的服务

查看正在运行的服务：

systemctl --type=service --state=running

查看已启用的服务：

systemctl list-unit-files --type=service --state=enabled

对 FTP、Telnet、远程文件共享以及其他不必要的网络服务，应根据实际业务确认是否需要保留。

不要直接批量禁用所有非核心服务。部分服务可能承担网络配置、存储挂载、时间同步、监控或业务调度职责。

11.2 检查系统更新

查看可用更新：

dnf check-update

根据维护计划安装经验证的安全更新：

dnf upgrade --security

该命令的实际效果取决于已配置的软件仓库及安全更新元数据。如果仓库未提供相应元数据，应使用适用的补丁管理流程确认安全更新。

生产环境更新前，应完成兼容性评估、业务备份和回滚方案设计，并确认是否需要重启内核或相关服务。

十二、基线检查与整改验收

安全基线配置完成后，应开展复核，而不是仅凭执行过命令就认为整改成功。

建议使用以下命令进行基础检查：

# 系统版本
cat /etc/openEuler-release

# SSH 配置语法
sshd -t

# SSH 生效参数
sshd -T | grep -Ei \
'permitrootlogin|permitemptypasswords|maxauthtries|loglevel'

# 口令有效期
chage -l root

# 默认权限掩码
umask

# 审计状态
systemctl is-active auditd
auditctl -s

# 防火墙状态
firewall-cmd --state

# SELinux 状态
getenforce

# 关键内核参数
sysctl net.ipv4.tcp_syncookies
sysctl kernel.randomize_va_space

# 失败的 systemd 服务
systemctl --failed

其中，umask 的输出仅反映当前 shell 环境，不能直接代表所有用户和服务的实际配置。firewall-cmd 检查也只适用于采用 firewalld 的环境。

12.1 整改验收表

建议将检查输出、配置变更记录、例外审批和复测结果一并归档，形成可追溯的整改闭环。

十三、常见问题与注意事项

13.1 为什么修改配置后检查结果没有变化？

常见原因包括：

• 修改了未被实际加载的配置文件。
• 配置被其他文件或管理工具覆盖。
• 服务尚未重载或重启。
• 配置存在语法错误。
• 当前用户环境与全局配置不一致。

应结合配置文件、运行状态和有效参数共同判断。

13.2 为什么不建议直接执行一键加固？

一键加固可能快速统一配置，但不同服务器承担的角色不同。数据库服务器、Web 服务器、容器节点、网络网关和运维跳板机需要不同的安全策略。

直接套用同一套配置可能造成：

• 远程管理中断。
• 业务服务无法启动。
• 应用访问被 SELinux 拒绝。
• 审计日志量异常增长。
• 网络转发或应用通信异常。

建议先进行基线扫描，再逐项整改，并在测试环境验证后推广至生产环境。

13.3 安全基线是否等于等保合规？

不是。

等保建设通常还涉及安全物理环境、网络架构、边界防护、身份鉴别、访问控制、安全审计、集中管理、备份恢复、管理制度及人员管理等内容。

操作系统基线只是整体安全体系的一部分。最终应结合系统定级结果、适用标准、业务场景及测评要求开展综合检查。

十四、总结

openEuler 系统安全基线建设的核心目标，是通过规范账号口令、远程访问、权限控制、日志审计、网络访问、内核参数和服务配置，降低操作系统的攻击面并提高安全事件的可追溯性。

在实际工作中，建议按照以下流程实施：

1. 确认系统版本与业务角色。
2. 备份配置并制定变更计划。
3. 执行基线检查并识别差距。
4. 按风险优先级实施整改。
5. 验证配置生效及业务兼容性。
6. 归档整改证据并持续复查。

安全基线不是一次性的配置任务，而是需要与漏洞管理、日志监控、账号治理、变更管理和应急响应结合的持续性工作。

只有做到配置有标准、整改有记录、结果可验证、异常可追溯，才能真正发挥 openEuler 操作系统安全基线在企业安全运营和等保建设中的作用。