1. 项目概述为什么服务器整改是等保测评的“硬骨头”每次接到等保测评任务看到待整改的服务器列表里既有CentOS又有Ubuntu不少运维同事的第一反应就是头大。这感觉就像同时要修一辆德系车和一辆日系车虽然都是四个轮子一个方向盘但工具、零件和维修手册完全不同。等保测评全称“网络安全等级保护测评”它不是一次简单的安全扫描而是一套由国家制定的、系统性的安全合规“体检”。测评不通过轻则业务无法上线重则面临通报和处罚。而服务器作为承载核心应用和数据的“地基”自然是测评的重中之重。CentOS和Ubuntu作为Linux阵营的两大主流发行版在开源世界各占半壁江山。CentOS以其极致的稳定性和与RHELRed Hat Enterprise Linux的二进制兼容性深受传统企业、金融和政府机构青睐而Ubuntu则凭借友好的社区、活跃的更新以及优秀的桌面体验在开发者、云计算和新兴互联网公司中广泛流行。这就带来了一个核心矛盾等保测评标准是统一的、普适的安全要求但落实到具体的技术实现上CentOS和Ubuntu的路径截然不同。从账户密码策略、日志审计配置到服务管理、防火墙规则甚至是一些内核参数的调整命令和配置文件的位置都可能天差地别。本次“整改全流程”的目标就是为你梳理出一条清晰的路径让你能拿着一份“等保检查清单”同时搞定CentOS和Ubuntu这两类服务器把混杂的“问题列表”变成可执行的、分门别类的“操作指令集”。整个过程我们将聚焦于等保2.0标准中与操作系统强相关的安全要求避开空洞的理论直接上干货和命令。2. 整改核心思路从“测评结果”到“配置清单”的拆解面对一份等保测评报告尤其是其中关于主机安全的几十甚至上百个“不符合项”切忌埋头就干。没有策略的整改就像没有图纸的装修容易拆东墙补西墙甚至引入新的问题。我的核心思路是“先归类后翻译再验证”。2.1 问题归类与映射测评报告中的问题描述通常是自然语言比如“未启用登录失败处理功能”。我们的第一步是将其映射到具体的技术控制点上。通常主机安全部分会集中在以下几个大类身份鉴别包括口令复杂度、生存周期、登录失败锁定、唯一性标识等。访问控制包括权限分离、最小权限、访问控制列表ACLS、sudo权限管理等。安全审计包括审计范围覆盖用户登录、特权命令、文件访问等、审计记录保护、审计进程保护等。入侵防范包括最小化服务安装、关闭无用端口、防暴力破解、资源控制等。恶意代码防范主要是防病毒软件的安装与更新。资源控制包括会话超时退出、资源阈值报警等。剩余信息保护系统层面涉及较少更多在应用和数据库。数据完整性/保密性通常由应用或加密协议实现系统层面涉及文件完整性校验如AIDE。你需要准备一张表格将报告中的每一个不符合项归类到上述大类中并注明其对应的测评项编号如“安全审计-身份鉴别-a”。这是将杂乱问题系统化的第一步。2.2 技术路径的“翻译”归类之后就进入关键的“翻译”阶段将一个通用的安全要求“翻译”成在CentOS和Ubuntu上分别如何实现的具体命令或配置。例如对于“口令必须包含大小写字母、数字、特殊字符中的至少三种长度至少8位”这个要求CentOS (RHEL系)主要通过/etc/pam.d/system-auth或/etc/pam.d/password-auth文件中的pam_pwquality.so模块来配置。你需要修改/etc/security/pwquality.conf。Ubuntu (Debian系)主要通过/etc/pam.d/common-password文件中的pam_pwquality.so模块来配置。你需要安装libpam-pwquality包并修改/etc/security/pwquality.conf。你看最终目标一致但配置文件的路径和依赖包可能不同。整个整改过程就是不断完成这样的“翻译”工作。我强烈建议你使用一个双栏的Wiki或文档来记录一栏是安全要求另一栏分别是CentOS和Ubuntu的实现步骤和命令这能极大提升后续批量操作的效率。2.3 变更管理与回滚预案在动手修改任何生产服务器之前必须制定变更管理计划。这包括备份备份即将修改的关键配置文件如/etc/ssh/sshd_config,/etc/pam.d/下的文件/etc/sudoers等。可以使用cp file file.bak_$(date %Y%m%d)的方式带上日期。快照如果服务器运行在虚拟化平台VMware, KVM或云上阿里云、腾讯云在整改前创建系统盘快照是最佳的后悔药。分批操作如果服务器数量多先选择一两台非核心业务服务器进行试点整改验证无误后再推广。回滚步骤明确记录下如何撤销每一条修改。最简单的回滚就是恢复备份文件。注意永远不要直接在生产环境上摸索命令。务必在测试环境中先验证所有操作步骤的准确性和兼容性特别是涉及PAMPluggable Authentication Modules可插拔认证模块和防火墙的修改一个配置错误可能导致所有用户包括你自己无法登录。3. 分项整改实操详解CentOS与Ubuntu的“同与不同”下面我们进入实操环节针对几个最常见、最关键的等保整改项对比讲解在CentOS和Ubuntu上的具体实现方法。3.1 身份鉴别强化不止是复杂密码身份鉴别是安全的第一道防线等保对此有细致要求。口令复杂度与生存周期共同点两者都通过pam_pwquality模块实现。首先确保该模块已安装并启用。CentOS 7/8通常已预装。编辑/etc/security/pwquality.confminlen 8 minclass 3 dcredit -1 ucredit -1 ocredit -1 lcredit -1minclass3表示至少包含三类字符大小写、数字、特殊。dcredit-1表示至少包含1个数字以此类推。Ubuntu 18.04/20.04/22.04需要先安装模块sudo apt-get install libpam-pwquality。配置文件同样是/etc/security/pwquality.conf内容与CentOS一致。口令生存周期修改/etc/login.defs文件。这个文件在两者中位置和格式基本相同。PASS_MAX_DAYS 90 # 密码最长使用90天 PASS_MIN_DAYS 1 # 密码最短使用1天防止频繁更改 PASS_WARN_AGE 7 # 密码过期前7天提醒注意此设置仅对新创建的用户生效。对已存在用户需使用chage命令修改例如sudo chage -M 90 -m 1 -W 7 username。登录失败处理与锁定这是防止暴力破解的关键。通过pam_tally2(CentOS 6/7) 或pam_faillock(CentOS 8/RHEL 8, Ubuntu) 模块实现。CentOS 7在/etc/pam.d/system-auth和/etc/pam.d/password-auth文件中于auth部分添加auth required pam_tally2.so deny5 unlock_time600 even_deny_root root_unlock_time300在account部分添加account required pam_tally2.so这表示连续失败5次后锁定账户600秒对root用户同样有效但root锁定300秒。Ubuntu 20.04/22.04 及 CentOS 8推荐使用更新的pam_faillock模块。配置更统一。编辑/etc/pam.d/common-authauth required pam_faillock.so preauth silent deny5 unlock_time600 auth [defaultdie] pam_faillock.so authfail deny5 unlock_time600 auth sufficient pam_faillock.so authsucc deny5 unlock_time600编辑/etc/pam.d/common-accountaccount required pam_faillock.so查看失败记录faillock --user username。解锁用户faillock --user username --reset。实操心得配置登录失败锁定后务必为自己保留一个额外的、使用密钥认证的SSH会话窗口或者确保有通过控制台如云服务器的VNC登录的权限。否则一旦自己误操作触发锁定且没有其他登录途径就只能求助控制台或机房人员了非常被动。3.2 访问控制精细化sudoers的学问等保要求实现权限分离例如系统管理员、安全管理员、审计员三权分立。在Linux层面这主要通过sudo权限的精细划分来实现。核心配置文件是/etc/sudoers永远不要直接用文本编辑器编辑它请使用visudo命令它有语法检查功能能防止配置错误导致所有sudo权限失效。创建用户组首先根据职责创建不同的用户组如sysadmins,secadmins,auditadmins。sudo groupadd sysadmins sudo groupadd secadmins # 将用户加入对应组 sudo usermod -aG sysadmins alice配置sudoers规则在/etc/sudoers或更好的做法是在/etc/sudoers.d/目录下创建独立文件如99-等保-权限。# 允许sysadmins组以root身份运行所有命令但需要密码 %sysadmins ALL(ALL) ALL # 允许secadmins组管理防火墙和审计规则无需密码谨慎使用NOPASSWD %secadmins ALL(ALL) NOPASSWD: /usr/sbin/iptables, /usr/sbin/auditctl, /usr/sbin/augenrules # 允许auditadmins组查看所有日志文件但禁止修改 %auditadmins ALL(ALL) /bin/cat /var/log/*, /usr/bin/tail -f /var/log/*对于Ubuntu服务管理命令可能是ufw(Uncomplicated Firewall) 而非iptables需要相应调整。启用sudo日志审计为了追踪sudo命令的使用在/etc/sudoers中添加Defaults logfile/var/log/sudo.log Defaults log_input, log_output这样所有通过sudo执行的命令、输入和输出都会被记录到/var/log/sudo.log为安全审计提供宝贵数据。3.3 安全审计全覆盖auditd的配置艺术等保对安全审计的要求非常严格要求记录系统内重要用户行为、重要安全事件。Linux内核自带的auditd审计框架是满足这一要求的核心工具。CentOS通常预装Ubuntu可能需要安装sudo apt-get install auditd audispd-plugins。审计规则配置是核心规则文件在/etc/audit/rules.d/audit.rules(CentOS) 或/etc/audit/rules.d/audit.rules(Ubuntu安装后生成)。以下是一些关键规则示例# 1. 审计所有系统调用性能消耗大慎用通常用于关键服务器 -a always,exit -F archb64 -S all -F keySYSCALL_ALL # 2. 审计所有文件的读写、属性更改性能消耗极大仅用于极高安全要求 -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/sudoers -p wa -k privilege_escalation -w /etc/ssh/sshd_config -p wa -k sshd_config # 3. 审计所有特权命令的执行更实用的规则 -a always,exit -F archb64 -S execve -F path/bin/su -F keyprivilege_escalation -a always,exit -F archb64 -S execve -F path/usr/bin/sudo -F keyprivilege_escalation -a always,exit -F archb64 -S execve -F path/usr/bin/passwd -k identity_change # 4. 审计所有登录和认证事件 -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins -w /var/run/utmp -p wa -k session -w /var/log/wtmp -p wa -k session -w /var/log/btmp -p wa -k session # 5. 审计内核模块加载/卸载防rootkit -w /sbin/insmod -p x -k modules -w /sbin/rmmod -p x -k modules -w /sbin/modprobe -p x -k modules -a always,exit -F archb64 -S init_module -S delete_module -k modules配置完成后重启审计服务sudo systemctl restart auditd并设置开机自启sudo systemctl enable auditd。使用ausearch -k 关键字或aureport来查询审计日志。注意事项审计规则对系统性能有直接影响。规则越宽泛如监控所有系统调用日志量越大对磁盘I/O和CPU的消耗也越大。在生产环境中务必根据业务重要性和安全等级从最关键的规则如监控特权命令、敏感文件开始添加并在测试环境评估性能影响。同时要确保/var/log/audit/目录所在分区有足够空间并配置日志轮转/etc/audit/auditd.conf中的max_log_file和num_logs参数。3.4 入侵防范与资源控制防火墙与会话管理防火墙配置这是对外防御的城墙。CentOS 7默认使用firewalld。等保要求通常包括限制管理端口如SSH的源IP。sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.1.0/24 port protocoltcp port22 accept sudo firewall-cmd --permanent --remove-servicessh # 移除默认的ssh开放规则 sudo firewall-cmd --reloadUbuntu默认使用ufw(Uncomplicated Firewall)。操作更简洁。sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp sudo ufw deny 22/tcp # 或者直接禁用默认的22端口规则 sudo ufw enable两者都需要关闭所有非必要的服务和端口。使用ss -tlnp或netstat -tlnp查看监听端口逐一确认其必要性。SSH加固修改/etc/ssh/sshd_config两者通用。bash Protocol 2 # 仅使用SSHv2 PermitRootLogin no # 禁止root直接登录 PasswordAuthentication no # 禁用密码登录强制使用密钥在配置好密钥后设置 PubkeyAuthentication yes # 启用密钥认证 PermitEmptyPasswords no # 禁止空密码 ClientAliveInterval 300 # 客户端活动检测间隔300秒 ClientAliveCountMax 2 # 最多发送2次检测包无响应则断开 AllowUsers user1 user2192.168.1.0/24 # 仅允许特定用户或从特定IP登录修改后重启SSH服务sudo systemctl restart sshdUbuntu或sshdCentOS。会话超时等保要求操作系统设置登录超时自动退出。通过设置TMOUT环境变量实现。 在/etc/profile或/etc/bashrc对所有用户生效末尾添加bash export TMOUT600 # 设置超时时间为600秒10分钟 readonly TMOUT # 设置为只读防止用户修改这样用户在shell中无操作10分钟后会话会自动断开。4. 整改后的验证与持续监控所有配置修改完成后不能简单认为整改就结束了。必须进行系统性验证并建立持续监控机制。4.1 配置合规性验证单项命令验证口令策略grep -E \^minlen|^minclass\ /etc/security/pwquality.conf登录失败锁定模拟失败登录观察faillock --user testuser或/var/log/secure(CentOS) //var/log/auth.log(Ubuntu) 的日志。SSH配置sshd -T | grep -E \permitrootlogin|passwordauthentication\审计服务状态systemctl status auditdauditctl -l查看当前生效规则。防火墙规则sudo firewall-cmd --list-all(CentOS) 或sudo ufw status verbose(Ubuntu)。自动化合规扫描对于服务器数量多的环境建议使用自动化工具进行批量验证。例如OpenSCAP这是一个强大的开源安全合规评估框架内置了符合等保、STIG、CIS Benchmark等多种标准的检查 profile。你可以使用oscap命令行工具对单台或批量服务器进行扫描并生成详细的HTML报告。# CentOS 7 安装与扫描示例 sudo yum install openscap-scanner scap-security-guide oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_centos7_l1_server --results scan_results.xml --report scan_report.html /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xmlLynis一款轻量级的、优秀的安全审计工具可以快速检查系统的安全配置并提供改进建议。sudo lynis audit system4.2 建立持续监控基线整改通过测评只是开始确保配置不被意外更改、安全状态持续可控才是长期挑战。文件完整性监控使用AIDEAdvanced Intrusion Detection Environment或Tripwire建立关键系统文件如/bin,/sbin,/usr/bin,/etc,/etc/ssh等的哈希值基线。一旦文件被修改无论是恶意攻击还是合法变更都能被及时发现。# CentOS/Ubuntu 安装AIDE sudo yum install aide # CentOS sudo apt-get install aide # Ubuntu # 初始化数据库 sudo aide --init sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz # 定期检查可放入cron sudo aide --check集中化日志管理将服务器上的安全相关日志/var/log/secure,/var/log/auth.log,/var/log/audit/audit.log,/var/log/sudo.log等通过rsyslog或syslog-ng实时转发到一台独立的、加固的日志服务器。这既满足了等保关于审计记录保护的要求防止本地日志被篡改或删除也便于进行关联分析和安全事件告警。定期复测与漏洞扫描将等保合规检查纳入日常运维周期。每季度或每半年使用OpenSCAP等工具进行一次全面的合规性复测。同时定期使用Nessus、OpenVAS等漏洞扫描工具对服务器进行漏洞扫描及时修补中高危漏洞。5. 常见问题与避坑指南在实际的等保整改中总会遇到一些“坑”。这里记录了几个典型问题及其解决方案。问题一配置了登录失败锁定后自己也被锁在外面了。原因测试时连续输错密码或配置的锁定阈值deny过低。解决方案预案最重要如前所述务必保留一个通过密钥认证的SSH会话或控制台访问权限。如果还能通过控制台物理机KVM或云服务器VNC登录直接登录后使用faillock --user 用户名 --reset或pam_tally2 --user 用户名 --reset解锁。如果所有途径都被锁且没有预案对于物理服务器可能需要机房现场操作对于云服务器则可能需要通过云控制台挂载系统盘到另一台实例进行修复。这非常麻烦凸显了事前测试和预案的重要性。问题二修改PAM配置后所有用户都无法登录了。原因/etc/pam.d/下的配置文件语法错误例如模块路径错误、参数格式不对。解决方案同样依赖控制台或备用登录方式。登录后使用pam_tally2或faillock检查锁定状态。使用cat -A检查配置文件是否有不可见的特殊字符如Windows换行符^M。最稳妥的方法是在修改PAM文件前在另一个终端窗口保持一个活跃的root会话并先使用pamtester工具测试新配置是否工作pamtester sshd 用户名 authenticate。问题三开启auditd后系统性能明显下降/var/log分区被塞满。原因审计规则过于宽泛如-S all导致日志量爆炸式增长。解决方案精细化规则删除或注释掉-S all这类全局规则。根据等保要求和业务实际只审计最关键的行为特权命令、敏感文件访问、用户登录等。调整审计参数编辑/etc/audit/auditd.conf可以适当增加flush参数值为INCREMENTAL_ASYNC以提升性能调整max_log_file和num_logs控制日志文件大小和数量。确保日志分区足够大/var/log分区在规划时应预留充足空间如50GB以上。配置日志轮转与归档除了auditd自带的轮转可以配置logrotate对/var/log/audit/audit.log进行更激进的压缩和删除策略并将历史日志归档到其他存储。问题四等保测评人员复查时指出某项配置“未生效”。原因配置修改后相关服务未重启或配置放在了错误的文件中如Ubuntu的PAM配置放在了CentOS的路径下。解决方案养成“修改-重启-验证”的习惯每次修改关键服务配置sshd, auditd, pam等立即重启服务并验证功能。使用命令验证配置不要只看文件内容。用sshd -T验证SSH最终配置用auditctl -l验证审计规则用sudo -l -U 用户名验证用户sudo权限。制作检查脚本将关键的验证命令写成一个Shell脚本在整改完成后和测评前统一运行输出一目了然的结果确保万无一失。等保整改不是一次性的运动而是一个将安全要求内化为系统标准配置和日常运维流程的持续过程。面对CentOS和Ubuntu的差异关键在于建立自己的“知识转换库”理解安全要求背后的原理然后熟练地找到在两个平台上的实现路径。当你成功将几十页的测评问题清单转化为一行行确切的命令和配置并看到所有检查项都变成“符合”时那种成就感是运维工作中难得的扎实与安心。