1. 项目概述从“过检”到“真安全”的思维转变最近在帮几个客户做等保测评的服务器整改从CentOS到Ubuntu从云上到物理机几乎跑了个遍。我发现一个挺普遍的现象很多运维兄弟一听到“等保整改”第一反应就是上网搜一堆命令脚本然后照着清单一条条执行改密码策略、关服务、配防火墙最后报告一交就等着测评老师来“审判”。结果往往是测评时手忙脚乱或者勉强过了但日常运维的便利性大打折扣甚至埋下新的安全隐患。这其实陷入了一个误区把等保整改等同于“命令集执行”。等保测评的核心是要求我们建立一套持续有效、符合规范的安全管理体系。整改不是一次性“打补丁”而是对现有运维体系的一次全面审视和加固。无论是CentOS的稳定厚重还是Ubuntu的灵活敏捷其安全基线的核心思想是相通的。这次我就结合最近几个实际项目把从准备、核查、整改到持续维护的全流程以及两个系统间的差异点掰开揉碎了讲清楚。目标不是给你一份冷冰冰的检查清单而是让你理解每一条要求背后的“为什么”从而能根据自己业务的实际状况制定出既合规又实用的安全策略。2. 等保测评核心要求与服务器安全基线解析等保2.0标准对二级及以上系统的安全要求集中体现在安全通用要求上其中与操作系统尤其是CentOS/Ubuntu这类服务器强相关的部分主要围绕身份鉴别、访问控制、安全审计、入侵防范和恶意代码防范等几个层面。我们的整改工作本质上就是让服务器配置满足这些层面的具体要求。2.1 身份鉴别与访问控制不只是密码复杂度这是最容易理解也最容易流于形式的部分。测评要求通常包括密码复杂度、定期更换、登录失败处理、特权用户权限分离等。密码策略的深层逻辑设置minlen8, minclass3至少包含数字、小写字母、大写字母、特殊字符中的三类只是基础。关键在于这个策略是否在所有可能的登录途径上生效比如你是否检查了SSH密钥登录、数据库本地登录、控制台登录等在Ubuntu上使用pam_pwquality模块在CentOS 7/8上通常也是pam_pwquality但配置文件路径和默认规则可能略有不同。整改时必须修改/etc/security/pwquality.conf并确保/etc/pam.d/system-auth和/etc/pam.d/password-auth文件正确引用了它。登录失败锁定这不仅是防暴力破解更是为了在出现异常登录尝试时能及时告警。配置pam_tally2或pam_faillock模块时要设定合理的锁定阈值和时长。例如连续5次失败锁定15分钟。这里有个关键细节要区分even_deny_root是否锁定root这个参数。从安全角度建议对root也进行锁定但这必须配合确保有其他可用的特权管理通道如通过sudo提权的普通用户或物理控制台否则一旦误锁可能导致无法应急。权限最小化与sudo审计禁止root直接远程SSH登录改用普通用户sudo。这不仅是要求更是最佳实践。整改重点在于精细配置/etc/sudoers。不要简单使用%wheel ALL(ALL) ALL而应该根据管理员的实际职责授予其完成工作所必需的最小命令集合。同时务必启用sudo的日志功能默认已开启至/var/log/secure或auth.log这是事后审计的关键。2.2 安全审计让系统自己“说话”安全审计条款要求审计覆盖到每个用户的重要操作和系统重要安全事件。对于服务器核心就是配置好auditdLinux审计子系统。审计规则的设计哲学不是审计得越多越好。无差别的全量审计会产生海量日志迅速塞满磁盘反而让关键信息被淹没。正确的思路是“关键对象关键操作”。关键文件审计审计所有对/etc/passwd/etc/shadow/etc/sudoers/etc/ssh/sshd_config等身份和权限核心文件的写、属性变更操作。关键命令审计审计useraddusermodpasswdsusudo等特权命令的执行。系统调用审计对于高安全环境可能需要审计execve系统调用监控所有命令执行但这会产生巨大日志量需谨慎评估。CentOS与Ubuntu的auditd差异两者都使用auditd但默认安装状态和规则管理方式可能不同。CentOS通常预装audit包且服务默认启用。Ubuntu Server可能默认未安装需要手动apt install auditd。规则文件都位于/etc/audit/rules.d/但要注意服务重启后确保规则被正确加载到/etc/audit/audit.rules中。日志管理必须配置logrotate对/var/log/audit/audit.log进行定期轮转和压缩防止磁盘爆满。同时要确保系统时间准确通过NTP同步因为审计日志的时间戳是法律效力的重要依据。2.3 入侵防范与恶意代码防范构建纵深防线这一部分要求系统具备检测和防范入侵的能力包括关闭无用端口、服务安装防病毒软件等。端口与服务最小化使用netstat -tunlp或ss -tunlp全面梳理监听端口。关闭所有非必需的服务。一个常见盲区是除了sshd、nginx/apache等业务服务还要检查像rpcbind、cups等桌面环境相关的服务是否在服务器上运行。防火墙的“白名单”思维等保要求采用白名单策略。以firewalldCentOS/RHEL系或ufwUbuntu/Debian系为例不要想着“开放哪些端口”而应该从“拒绝所有”开始逐一添加业务必需的端口和协议。例如业务需要Web80/443和SSH22那么规则就是明确允许这三者其他一律DROP或REJECT。主机层防病毒这是等保三级系统的明确要求。对于Linux服务器虽然病毒较少但安装ClamAV等防病毒软件主要用于扫描上传的文件、Web目录等防止其成为恶意文件的“中转站”。需要定期更新病毒库并设置定时扫描任务。注意防病毒软件的实时监控功能可能会对性能敏感的业务产生影响需在测试环境充分评估。3. CentOS与Ubuntu系统专项整改实操对比虽然安全原理一致但CentOS以RHEL系为代表和Ubuntu以Debian系为代表在包管理、默认配置、安全工具上存在差异整改时需特别注意。3.1 身份鉴别模块配置差异与统一这是差异最集中的地方主要源于PAM可插拔认证模块配置和用户管理工具的不同。密码策略配置CentOS 7/8主要修改/etc/security/pwquality.conf。同时需检查/etc/pam.d/system-auth和/etc/pam.d/password-auth文件确保包含类似password requisite pam_pwquality.so try_first_pass local_users_only retry3 authtok_type的行。Ubuntu 20.04/22.04同样修改/etc/security/pwquality.conf若无则创建。但其PAM主配置文件是/etc/pam.d/common-password。需要在该文件中找到对应行通常是将pam_unix.so的obscure参数替换为pam_pwquality.so的调用。一个典型的修改后行可能是password requisite pam_pwquality.so retry3 minlen8 difok3。统一检查命令无论哪个系统修改后都应用chage -l 用户名查看具体用户的密码策略生效情况并用passwd命令尝试设置弱密码来测试策略是否生效。登录失败锁定配置CentOS 7常用pam_tally2。在/etc/pam.d/system-auth的auth部分添加auth required pam_tally2.so deny5 unlock_time600 even_deny_root root_unlock_time300在account部分添加account required pam_tally2.so。使用pam_tally2 --user 用户名查看失败次数pam_tally2 --user 用户名 --reset清空计数。CentOS 8 / Ubuntu推荐使用更新的pam_faillock。配置更统一在/etc/pam.d/system-auth和/etc/pam.d/password-authCentOS或/etc/pam.d/common-authUbuntu的auth部分添加auth required pam_faillock.so preauth silent audit deny5 unlock_time600 在auth模块后添加auth [defaultdie] pam_faillock.so authfail 在account部分添加account required pam_faillock.so。失败记录查看命令为faillock --user 用户名。重要提示在配置登录失败锁定前务必在另一个已登录的会话中测试或确保有不受此策略影响的备用登录方式如通过云平台控制台登录以防配置错误导致所有管理员账户被锁死。3.2 安全审计与日志配置实战审计规则的编写语法是通用的但安装和管理方式有细微差别。安装与启停# CentOS (通常已安装) sudo systemctl status auditd # Ubuntu sudo apt update sudo apt install auditd -y sudo systemctl enable --now auditd编写审计规则规则文件通常放在/etc/audit/rules.d/目录下例如/etc/audit/rules.d/security.rules。# 监控/etc/passwd文件的写和属性更改 -w /etc/passwd -p wa -k identity # 监控/etc/shadow文件任何访问因为读shadow也需要权限 -w /etc/shadow -p wa -k identity # 监控sudoers文件 -w /etc/sudoers -p wa -k privilege # 监控SSH配置变更 -w /etc/ssh/sshd_config -p wa -k sshd_config # 监控所有用户的提权操作执行sudo -a always,exit -F archb64 -S execve -C uid!euid -F euid0 -k privilege_escalation -a always,exit -F archb32 -S execve -C uid!euid -F euid0 -k privilege_escalation规则中的-k后面跟的是“键值”key用于在查询日志时快速过滤相关事件。使规则生效与查询# 重启auditd服务使规则生效生产环境谨慎可能丢失瞬时事件 sudo systemctl restart auditd # 或者重新加载规则推荐 sudo auditctl -R /etc/audit/rules.d/security.rules # 使用ausearch查询日志 sudo ausearch -k identity --start recent # 查询与“identity”键相关的审计事件 sudo ausearch -ts today -k privilege_escalation # 查询今天发生的提权事件日志轮转配置确保/etc/audit/auditd.conf中配置了合理的max_log_file单个日志文件大小如50M和num_logs保留的日志文件个数如10。同时系统的logrotate通常已包含/etc/logrotate.d/auditd需确认其配置合理。3.3 网络与防火墙策略精细化配置防火墙是入侵防范的第一道关口配置思路要从“默认允许”转变为“默认拒绝”。CentOS (firewalld)# 1. 设置默认区域为drop最严格或public较常用 sudo firewall-cmd --set-default-zonepublic --permanent # 2. 移除区域中所有预定义服务清空起点 sudo firewall-cmd --zonepublic --remove-servicessh --remove-servicedhcpv6-client --permanent # 谨慎操作确保有其他连接方式 # 3. 以白名单方式添加业务所需服务或端口 sudo firewall-cmd --zonepublic --add-servicehttp --permanent sudo firewall-cmd --zonepublic --add-servicehttps --permanent sudo firewall-cmd --zonepublic --add-port22/tcp --permanent # 重新添加SSH但建议改端口 # 4. 重新加载配置 sudo firewall-cmd --reload # 5. 查看生效规则 sudo firewall-cmd --zonepublic --list-allUbuntu (ufw)# 1. 重置规则清空起点 sudo ufw --force reset # 2. 设置默认策略为拒绝所有入站允许所有出站 sudo ufw default deny incoming sudo ufw default allow outgoing # 3. 以白名单方式允许特定端口 sudo ufw allow 22/tcp comment SSH sudo ufw allow 80/tcp comment HTTP sudo ufw allow 443/tcp comment HTTPS # 4. 启用UFW sudo ufw --force enable # --force 避免交互确认 # 5. 查看状态 sudo ufw status verbose关键技巧在应用任何可能断开当前连接的防火墙规则前务必通过云控制台、物理KVM或另一个已建立的SSH会话保持活动进行操作并设置一个cron任务或at命令在几分钟后恢复原规则作为“逃生舱”。例如echo sudo ufw disable | at now 5 minutes。4. 整改全流程实施与持续运维指南整改不是一次性事件而是一个包含准备、实施、验证、固化、持续监控的完整流程。4.1 整改前准备与系统状态备份盲目操作是灾难的开始。在运行任何整改命令前必须做好充分准备。环境隔离与备份克隆环境如果可能使用虚拟机快照、容器镜像或系统克隆功能创建一个与生产环境完全一致的测试环境。所有整改操作先在测试环境验证。配置文件备份对即将修改的关键文件进行备份。可以使用cp命令加时间戳或使用git进行版本管理对于/etc目录尤其有用。sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date %Y%m%d) sudo cp -a /etc/pam.d /root/backup/pam.d.bak.$(date %Y%m%d)系统状态快照记录下当前的关键状态便于对比和回滚。# 记录当前开放端口 sudo ss -tunlp /root/backup/network_ports_before.txt # 记录所有进程 sudo ps aux /root/backup/process_list_before.txt # 记录所有cron任务 sudo crontab -l /root/backup/crontab_backup.txt 2/dev/null for user in $(cut -f1 -d: /etc/passwd); do sudo crontab -u $user -l /root/backup/crontab_all_backup.txt 2/dev/null; done制定详细的整改方案根据等保测评报告中的“不符合项”或自查清单逐条制定整改命令、预期结果、回滚方案。方案中应明确每项操作的责任人和时间窗口。4.2 分阶段实施与验证测试按照对业务影响程度分批次、分窗口实施整改。第一阶段信息收集与无害化加固影响最小安装必要的审计、监控工具如auditdClamAV。更新系统和软件包到最新稳定版需评估业务兼容性。配置NTP时间同步。验证检查工具是否运行正常时间是否同步。第二阶段身份与访问控制加固影响中等需通知用户修改密码复杂度策略。配置登录失败锁定。优化sudo权限。验证创建测试账号尝试使用弱密码、连续输错密码、执行未授权的sudo命令验证策略是否生效。务必在另一个会话中测试防止锁死自己。第三阶段网络与服务加固影响较大需安排维护窗口关闭非必要服务与端口。配置严格的防火墙白名单规则。修改SSH默认端口、禁用root远程登录、使用密钥认证。验证从外部使用nmap扫描服务器端口确认只有白名单端口开放。使用新配置的SSH方式尝试连接。第四阶段审计与日志配置影响小配置auditd规则。配置logrotate。配置远程日志服务器如rsyslog转发到日志审计平台。验证执行被审计的操作如修改/etc/passwd然后使用ausearch命令查看审计日志中是否生成相应记录。4.3 整改后固化与持续监控整改通过测评不是终点如何保持安全状态才是关键。配置固化将所有通过验证的整改配置进行固化。对于CentOS的firewalld和Ubuntu的ufw使用--permanent参数或ufw enable。将测试通过的auditd规则文件永久保存在/etc/audit/rules.d/。将PAM配置、SSH配置等变更确认无误后保存。编写自动化检查脚本编写一个Shell脚本定期如每天检查关键安全配置是否被篡改。例如#!/bin/bash # check_security_baseline.sh LOG_FILE/var/log/security_baseline_check.log echo $(date) - 开始安全检查 $LOG_FILE # 1. 检查密码策略文件权限 if [[ $(stat -c %a /etc/security/pwquality.conf) -ne 644 ]]; then echo [异常] /etc/security/pwquality.conf 权限被修改 $LOG_FILE fi # 2. 检查SSH配置是否允许root登录 if grep -q ^PermitRootLogin yes /etc/ssh/sshd_config; then echo [异常] SSH配置允许Root登录 $LOG_FILE fi # 3. 检查防火墙默认策略 # 对于UFW if which ufw /dev/null; then if ! sudo ufw status | grep -q Status: active; then echo [异常] UFW防火墙未激活 $LOG_FILE fi fi # 对于firewalld if which firewall-cmd /dev/null; then if ! sudo firewall-cmd --state 2/dev/null | grep -q running; then echo [异常] firewalld防火墙未运行 $LOG_FILE fi fi # 4. 检查审计服务状态 if ! systemctl is-active --quiet auditd; then echo [异常] auditd审计服务未运行 $LOG_FILE fi echo $(date) - 安全检查结束 $LOG_FILE将此脚本加入crontab并配置将LOG_FILE中的异常内容发送告警邮件。建立持续监控与响应机制日志集中分析将操作系统日志、应用日志、审计日志统一收集到SIEM安全信息与事件管理平台或ELK栈中进行关联分析。文件完整性监控使用AIDE或Tripwire等工具对/bin/sbin/usr/bin/etc/root等关键目录建立基准数据库定期检查文件是否被篡改。入侵检测系统部署OSSEC或Wazuh等基于主机的入侵检测系统能够实时监控日志、检查rootkit、检测异常行为并主动响应。5. 高频问题排查与避坑指南在实际操作中总会遇到各种“坑”。这里总结几个最常见的问题和解决方法。5.1 身份鉴别类问题问题配置了密码复杂度但用户修改密码时未生效。排查首先检查/etc/security/pwquality.conf语法是否正确。然后使用strace命令跟踪passwd进程看它读取了哪些PAM配置文件strace -e open,openat passwd 21 | grep pam。这能帮你确认系统实际使用的PAM配置链。解决确保所有相关的PAM配置文件system-authpassword-authcommon-password等都正确引用了pam_pwquality.so模块并且没有其他模块如pam_unix.so的obscure参数覆盖了它。问题配置登录失败锁定后自己也被锁在外面。预防如前所述永远在另一个活跃会话中测试。对于云服务器确保控制台VNC或串口登录可用。应急通过云平台控制台或物理控制台登录。如果使用pam_tally2用pam_tally2 --user 用户名 --reset解锁。如果使用pam_faillock用faillock --user 用户名 --reset解锁。如果PAM配置错误导致所有用户无法登录需要从单用户模式或救援模式启动挂载根文件系统回滚/etc/pam.d/目录下的配置文件。5.2 网络与防火墙类问题问题配置防火墙后业务应用无法访问数据库或外部API。排查这是最典型的问题。首先用iptables -nvLCentOS 6/7或nft list rulesetCentOS 8查看底层规则确认firewalld或ufw的规则是否已正确下发。然后在业务服务器上使用tcpdump抓包或在客户端使用telnet IP PORT测试连通性判断是请求未到达还是回复被阻断。解决防火墙规则是状态化的。对于由服务器主动发起的出站连接如调用外部API通常只需要允许相关出站规则即可回复包会被自动放行。但对于需要服务器监听的入站连接如数据库必须在入站规则中明确允许。切记不仅要放行服务端口如果业务涉及返回包路径或相关协议可能还需要考虑放行ESTABLISHEDRELATED状态的数据包现代防火墙如firewalld和ufw默认已处理此逻辑。问题SSH改了端口后防火墙没放行连不上了。避坑流程修改SSH端口必须遵循严格顺序先在防火墙临时添加新端口规则firewall-cmd --add-port新端口/tcp或ufw allow 新端口/tcp。测试使用新端口SSH连接确保成功。修改/etc/ssh/sshd_config中的Port参数。重启sshd服务sudo systemctl restart sshd。再次测试新端口连接。将新端口规则永久添加到防火墙--permanent参数或ufw enable。从防火墙中移除旧端口22的规则。最后保留一个已连接的SSH会话直到所有测试完成作为最后的逃生通道。5.3 安全审计与日志类问题问题auditd日志增长过快迅速占满磁盘。排查使用ausearch或aureport分析日志内容看是哪些规则产生了大量事件。通常过于宽泛的规则如审计所有execve系统调用、审计所有文件read操作是罪魁祸首。解决优化审计规则删除或收紧产生大量噪音的规则。聚焦于关键文件和特权操作。调整auditd参数在/etc/audit/auditd.conf中可以调整flush刷盘频率、freq触发动作的频率等参数但效果有限。强化日志轮转与归档确保logrotate配置合理并考虑将归档后的日志自动压缩并传输到容量更大的存储或日志服务器。使用日志速率限制在审计规则中可以为某些高频事件添加速率限制但这不是标准功能需谨慎。问题等保测评要求记录“系统重要安全事件”但不知道auditd该配什么规则。核心规则集参考除了前面提到的文件监控和提权监控以下规则也常被要求# 监控所有系统管理命令的执行如useradd, usermod, passwd, visudo等需根据实际路径调整 -w /usr/sbin/useradd -p x -k user_management -w /usr/sbin/usermod -p x -k user_management -w /usr/bin/passwd -p x -k password_change -w /usr/sbin/visudo -p x -k sudo_change # 监控系统时间的修改 -a always,exit -F archb64 -S adjtimex,settimeofday,clock_settime -k time_change # 监控文件删除操作仅监控根目录和关键目录避免全盘 -a always,exit -F archb64 -S unlink,unlinkat,rename,renameat -F dir/etc -F dir/root -F dir/var/log -k delete关键在于规则要结合业务实际。例如如果服务器是数据库主机那么监控对数据库配置文件和数据的访问可能比监控useradd更重要。整改的最终目的是让安全要求内化为运维习惯。每次变更前思考安全影响定期回顾审计日志对异常告警保持敏感。当这套流程运转起来你会发现等保测评不再是临阵磨枪的负担而是对日常运维工作的一次次健康体检。