Linux服务器等保三级安全加固实战：从身份鉴别到入侵防范全流程指南

1. 项目概述：为什么等保三级整改是Linux运维的“必修课”

最近在帮一家金融科技公司做安全合规审计，核心任务就是把他们生产环境的几十台Linux服务器，从“能用”的状态，提升到符合网络安全等级保护三级（简称“等保三级”）的要求。这活儿听起来像是填表格、写文档的“面子工程”，但真正上手后才发现，这是一次对系统架构、安全策略和运维习惯的深度重构。等保三级不是终点，而是一个持续的安全基线。对于任何涉及用户敏感信息、金融交易或关键业务系统的公司，尤其是互联网、金融、政务、医疗这些行业，过等保三级几乎是硬性门槛。它不仅是合规要求，更是抵御真实网络攻击、保障业务连续性的实战手册。

这次整改，我们面对的是一个典型的混合环境：CentOS 7、Ubuntu 20.04都有，跑着Web应用、数据库和中间件。初始状态很常见——root密码简单、SSH端口默认、审计日志没开全、文件和权限管理松散。等保三级的测评项有上百条，但核心思想就一个：从技术和管理两个层面，构建“可信、可控、可管”的计算环境。技术层面，关注身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范等；管理层面，则涉及制度、人员、建设流程和应急预案。这篇总结，我就聚焦在技术整改的“硬骨头”上，把我们在Linux操作系统层面踩过的坑、验证过的方案，掰开揉碎了讲清楚。无论你是运维工程师、安全负责人，还是技术负责人，这些实操细节都能帮你少走弯路。

2. 等保三级核心要求与Linux映射解读

等保2.0标准下的三级要求，对操作系统提出了非常具体和严格的控制点。我们不能盲目操作，必须先把标准条款“翻译”成具体的Linux技术动作。

2.1 身份鉴别与访问控制：从“谁能进”到“能干啥”

这是安全的第一道门。等保要求包括：口令复杂度、定期更换、登录失败处理、特权用户权限分离等。

• 口令策略强化：这远不止是修改/etc/login.defs里的PASS_MAX_DAYS（密码最大天数）。我们采用了pam_pwquality模块（CentOS 7/RHEL系）或pam_pwquality结合pam_cracklib（Ubuntu）。关键配置在/etc/security/pwquality.conf或/etc/pam.d/system-auth文件中。

  # /etc/security/pwquality.conf 示例 minlen = 12 # 密码最小长度12位 dcredit = -1 # 至少包含一个数字 ucredit = -1 # 至少包含一个大写字母 lcredit = -1 # 至少包含一个小写字母 ocredit = -1 # 至少包含一个特殊字符 minclass = 3 # 至少包含上述四类字符中的三类 maxrepeat = 2 # 同一字符最多连续出现2次

  注意：强制修改策略后，一定要给现有用户一个宽限期，并通过chage -l <username>检查密码过期状态，避免批量锁死账户导致业务中断。

• 登录失败处理与账户锁定：防止暴力破解。使用pam_tally2或pam_faillock模块。

  # 在 /etc/pam.d/password-auth 和 /etc/pam.d/system-auth 中添加（RHEL/CentOS 7+） auth required pam_faillock.so preauth silent audit deny=5 unlock_time=600 auth [default=die] pam_faillock.so authfail audit deny=5 account required pam_faillock.so

  这表示连续5次失败后锁定账户600秒。实操心得：unlock_time不宜过短，也不宜永久锁定。对于生产环境，我们配合了监控告警，一旦有账户被锁定，立即通知运维人员排查是正常输错还是攻击行为。

• 特权权限最小化与分离：严禁日常使用root。我们做了三件事：

  1. 禁用root的SSH直接登录：修改/etc/ssh/sshd_config，设置PermitRootLogin no。这是铁律。
  2. 配置sudo精细化授权：不用NOPASSWD，且命令路径必须写全。例如，只允许运维组ops成员在特定主机上重启nginx：

     # /etc/sudoers.d/ops_nginx Cmnd_Alias NGINX_CTL = /usr/sbin/systemctl restart nginx, /usr/sbin/systemctl status nginx %ops ALL=(root) NGINX_CTL

  3. 启用SSH密钥对认证，禁用密码认证：这是更安全的方式。sshd_config中设置PasswordAuthentication no和PubkeyAuthentication yes。

2.2 安全审计：留下所有行为的“黑匣子”

等保三级要求审计覆盖每个用户的重要操作和系统重要安全事件。Linux的审计子系统auditd是核心工具，但默认配置远远不够。

• 关键审计规则配置：规则写在/etc/audit/rules.d/audit.rules中。以下是一些必配项：

  # 审计所有系统调用（syscall）的失败记录（-F exit=-EPERM 或 -F exit=-EACCES） -a always,exit -F arch=b64 -S all -F exit=-EPERM -k access -a always,exit -F arch=b64 -S all -F exit=-EACCES -k access # 审计所有文件的读、写、属性更改、删除（atime可不审，日志量巨大） -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 privilege -w /etc/ssh/sshd_config -p wa -k sshd -w /var/log/secure -p wa -k authlog -w /usr/bin -p wa -k bin_mod -w /usr/sbin -p wa -k sbin_mod # 审计所有特权命令的执行（su, sudo, passwd等） -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid

  配置要点：-k后面跟的是“键值”（key），用于在查询日志时快速过滤。规则不是越多越好，要平衡安全性和性能。审计/usr/bin和/usr/sbin的写入操作，能有效监控是否被植入木马。

• 审计日志管理与轮转：auditd的日志默认在/var/log/audit/audit.log。必须配置日志轮转（/etc/audit/auditd.conf中的max_log_file和num_logs）和归档策略，防止磁盘被撑爆。我们设定单个日志文件最大50MB，保留10个，并每日将旧日志压缩后传输到安全的日志服务器进行集中分析和长期存储。

2.3 入侵防范与恶意代码防范：主动防御与边界清理

等保要求能检测到入侵行为，并能防范恶意代码。

• 文件完整性校验：使用AIDE（Advanced Intrusion Detection Environment）建立系统文件的“健康快照”。初始化数据库后，任何受监控文件的增、删、改都会被检测到。

  # 初始化数据库（选择关键目录，如/etc, /bin, /sbin, /usr/bin, /usr/sbin） aide --init mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz # 每日定时执行检查，并发送报告 aide --check

  避坑技巧：初始化前确保系统是“干净”的。对于频繁变化的日志文件、临时目录，要在/etc/aide.conf中将其排除（!/var/log/*）。更新软件包后，需要重新初始化数据库。

• 入侵检测系统（IDS）：auditd是内核级审计，而像fail2ban这样的应用级IDS可以动态封禁恶意IP。我们配置fail2ban监控/var/log/secure（SSH登录失败）和/var/log/nginx/access.log（Web暴力破解），失败次数超过阈值即调用iptables或firewalld封禁IP一段时间。

• 恶意代码防范：对于Linux服务器，虽然病毒较少，但挖矿木马、勒索软件依然存在。我们部署了开源的ClamAV进行定期扫描，重点是/tmp、/var/tmp、Web上传目录和用户家目录。同时，严格限制非必要端口的开放，从网络层面减少攻击面。

3. 系统安全加固实操全流程

理论懂了，我们来看手把手的实操。假设我们拿到一台全新的 CentOS 7 服务器，目标是将其加固至满足等保三级基线。

3.1 初始环境检查与基准建立

在动手修改任何配置之前，必须做一次全面的“体检”，并建立基准。

1. 系统信息与账户快照：

   # 记录系统版本、内核 cat /etc/redhat-release uname -a # 记录所有用户、组 cat /etc/passwd > /backup/passwd.bak.$(date +%Y%m%d) cat /etc/group > /backup/group.bak.$(date +%Y%m%d) # 记录所有已安装软件包 rpm -qa | sort > /backup/rpm_list.bak.$(date +%Y%m%d) # 记录当前网络监听端口 netstat -tunlp > /backup/netstat.bak.$(date +%Y%m%d) ss -tunlp # 另一种更推荐的方式

   这个备份至关重要，任何误操作都有回滚的依据。

2. 检查现有安全配置：

   # 检查SSH配置 grep -E "^PermitRootLogin|^PasswordAuthentication|^Port" /etc/ssh/sshd_config # 检查密码策略 grep -E "^PASS_" /etc/login.defs cat /etc/security/pwquality.conf 2>/dev/null # 检查sudoers配置 visudo -c # 检查语法

3.2 分步加固实施

步骤一：账户与口令安全

1. 删除或锁定无用账户（userdel,usermod -L）。
2. 按2.1节配置/etc/security/pwquality.conf和PAM模块。
3. 设置所有现有用户的密码过期策略：chage -M 90 <username>（90天强制更换）。
4. 配置pam_faillock实现登录失败锁定。

步骤二：SSH服务加固

1. 修改默认端口：Port 2022（需同时调整防火墙）。
2. 禁用root登录：PermitRootLogin no。
3. 禁用密码认证，启用密钥认证：PasswordAuthentication no,PubkeyAuthentication yes。
4. 限制监听IP（如非必要）：ListenAddress 内网IP。
5. 使用更强加密算法：在sshd_config末尾添加：

   Ciphers aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512,hmac-sha2-256 KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group-exchange-sha256

6. 重启sshd前务必确认：保持当前SSH会话不退出，新开一个窗口用新配置测试连接，成功后再重启服务：systemctl restart sshd。

步骤三：权限与访问控制

1. 配置sudo精细化授权（如2.1节所述）。
2. 检查系统重要文件和目录的权限：

   # 关键目录应属root，权限755或更严格 chmod 750 /root chmod 755 /bin /boot /lib /lib64 /sbin /usr/bin /usr/sbin # 关键配置文件应属root，权限644或600 chmod 600 /etc/shadow /etc/gshadow chmod 644 /etc/passwd /etc/group

3. 设置umask默认值：在/etc/profile和/etc/bashrc中设置umask 027，使新建文件默认权限为640（属主可读写，属组可读，其他无权限）。

步骤四：启用并配置审计（auditd）

1. 安装并启动服务：yum install audit -y && systemctl start auditd && systemctl enable auditd。
2. 将2.2节中的审计规则写入/etc/audit/rules.d/audit.rules。
3. 加载新规则：augenrules --load。
4. 检查规则是否生效：auditctl -l。
5. 配置auditd.conf中的日志轮转参数。

步骤五：配置防火墙（firewalld/iptables）遵循最小开放原则。

# 使用firewalld（CentOS 7默认） systemctl start firewalld systemctl enable firewalld # 放行SSH新端口、HTTP/HTTPS等必要服务端口 firewall-cmd --permanent --add-port=2022/tcp firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https # 移除默认放开的DHCPv6-client等不必要的服务 firewall-cmd --permanent --remove-service=dhcpv6-client # 重载配置 firewall-cmd --reload # 查看生效规则 firewall-cmd --list-all

步骤六：安装与配置入侵检测及防恶意软件

1. 安装配置AIDE（如2.3节）。
2. 安装配置fail2ban：

   yum install epel-release -y yum install fail2ban -y systemctl start fail2ban systemctl enable fail2ban

   创建自定义监狱规则/etc/fail2ban/jail.local，定义监控的日志文件、失败次数和封禁时间。
3. 安装ClamAV并配置定期扫描任务（通过cron）。

3.3 加固后验证与基线生成

所有配置完成后，必须验证。

1. SSH验证：尝试用root密码登录（应失败），用密钥和新端口登录（应成功）。
2. 审计验证：执行一个特权命令（如sudo ls /root），然后检查审计日志：ausearch -k privilege。
3. AIDE验证：手动修改一个受监控文件（如/etc/hosts），运行aide --check应能报告差异。
4. 生成安全基线：使用OpenSCAP等自动化合规扫描工具，生成一份系统当前状态的合规报告，作为后续定期检查的基准。

   yum install openscap-scanner scap-security-guide -y oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_stig --results /root/ssg-results.xml --report /root/ssg-report.html /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

4. 持续运维与合规保持

等保整改不是一劳永逸的，测评通过后，日常运维才是真正的挑战。

4.1 自动化检查与监控

手工检查不现实，必须自动化。

1. 脚本化基线检查：编写Shell或Python脚本，定期检查关键配置（如SSH参数、密码策略、审计服务状态、防火墙规则、AIDE数据库完整性等），并与基准值对比，发现偏差自动告警。
2. 集中日志分析：将所有服务器的/var/log/secure、/var/log/audit/audit.log、/var/log/messages等安全相关日志，通过rsyslog或Filebeat实时发送到ELK（Elasticsearch, Logstash, Kibana）或Graylog等日志平台。在平台上设置告警规则，例如：同一IP短时间内SSH登录失败超过10次、审计日志中出现key=privilege的异常sudo使用等。
3. 漏洞扫描与补丁管理：定期（如每月）使用yum update --security或订阅厂商的安全公告，及时修复系统漏洞。对于业务应用（如Nginx, Tomcat, Redis），同样需要关注其安全更新。

4.2 变更管理与备份恢复

任何对生产环境的变更，都必须走流程。

1. 变更前备份：修改重要配置文件前，必须cp file file.bak.$(date +%Y%m%d)。
2. 使用配置管理工具：如Ansible，将安全配置写成playbook。这样，任何一台新服务器上线，或需要批量修改策略时，都能确保一致性、可追溯和快速回滚。
3. 制定并演练应急预案：包括：在fail2ban误封运维IP时如何解封；在审计日志爆满导致磁盘空间不足时如何紧急清理；在系统被入侵后如何隔离、取证和恢复。预案不能只停留在文档，需要定期演练。

5. 常见问题与排查技巧实录

在实际操作中，我们遇到了不少问题，这里记录几个典型的。

问题一：配置了pam_faillock后，普通用户登录被无限锁定，即使密码正确。

• 排查：检查/var/log/secure，发现大量pam_faillock模块的Authentication failure和Consecutive login failures日志。但用户坚称密码正确。
• 原因：该用户的家目录磁盘空间满了（df -h /home），导致PAM模块无法写入.faillock临时文件，从而误判为失败。
• 解决：清理磁盘空间后，手动清除该用户的失败计数：faillock --user <username> --reset。教训：监控系统磁盘空间，尤其是/home、/var等分区。

问题二：AIDE每日检查邮件告警“数据库读取错误”。

• 排查：aide --check报错 “Couldn’t open file /var/lib/aide/aide.db.gz for reading”。
• 原因：AIDE数据库文件在初始化或更新过程中被损坏，或者被其他进程锁定。
• 解决：停止AIDE相关服务或定时任务，删除旧的数据库文件，从备份中恢复，或在一个系统稳定的时间窗口重新初始化数据库。技巧：将AIDE数据库文件备份到另一台安全服务器。

问题三：等保测评时，测评师使用漏洞扫描器发现“SSH弱加密算法”漏洞。

• 排查：我们明明在sshd_config里配置了强加密算法。
• 原因：sshd服务配置未重载，或者配置语法有误导致未生效。扫描器连接的是旧配置支持的弱算法。
• 解决：首先sshd -T检查当前生效的配置。确认配置文件无误后，执行systemctl reload sshd（注意不是restart，reload不会断开现有连接）。然后用nmap --script ssh2-enum-algos <server_ip>验证扫描结果是否已更新。关键点：任何配置修改后，必须验证其是否真正生效。

问题四：审计日志（audit.log）增长过快，迅速占满磁盘。

• 排查：ausearch发现大量与某个特定、高频发生的业务进程相关的SYSCALL审计记录。
• 原因：审计规则-a always,exit -S all过于宽泛，审计了所有系统调用。
• 解决：优化审计规则，避免审计不必要的、高频的系统调用。例如，使用-F path=限定特定路径，或使用-F exe=限定特定程序。更精细的做法是，只为关键对象（文件、命令）和关键用户（特权用户）设置审计规则，而不是全量审计。同时，确保auditd.conf中的max_log_file_action设置为ROTATE而非IGNORE。

整个等保三级整改过程，像是一次对系统安全认知的升级。最大的体会是，安全不是一个功能开关，而是一个贯穿设计、部署、运维全生命周期的体系。技术配置固然重要，但配套的管理制度、人员意识和应急流程，才是让这些技术措施持续发挥作用的保障。不要为了“过等保”而整改，而要将其视为提升整体运维安全水位的最佳实践。每次安全事件的发生，根源往往不是某个高深的技术漏洞，而是某个被忽略的基础配置或管理流程。把基础打牢，比追求炫技的新工具更实在。