1. 项目概述从合规压力到实战落地最近在帮几个客户做等保测评的整改清一色都是CentOS和Ubuntu服务器。每次测评报告下来看着那一长串的“中危”、“高危”漏洞和不符合项甲方运维兄弟的脸色都不太好看。这活儿干多了我发现一个规律很多问题其实不是技术有多难而是缺乏一个清晰、可落地的全流程操作指南。网上的资料要么太零散只讲某个命令要么太理论照着国家标准条文念真到服务器上敲命令时还是不知道从哪下手。今天我就把自己这些年经手几十台服务器整改的经验梳理成一个从拿到测评报告到最终复测通过的完整流程。核心就围绕两个最主流的Linux发行版CentOS以7.x为主兼顾一些老系统和Ubuntu主要是18.04 LTS和20.04 LTS。你不用再去纠结“等保2.0”里那些拗口的控制点具体对应哪条命令我会直接告诉你在CentOS和Ubuntu上分别该怎么查、怎么改、怎么验证。目标是让你拿到这份指南就像有个老师傅在旁边指点一样一步步把服务器从“千疮百孔”调到“坚如磐石”顺利通过测评。2. 整改核心思路与准备工作2.1 理解等保测评的“靶心”在动手敲命令之前我们必须搞清楚等保测评尤其是二级和三级在操作系统层面到底在查什么。它绝对不是简单装个杀毒软件或者改个密码就完事的。其核心可以概括为四个方向身份鉴别、访问控制、安全审计、入侵防范。所有整改动作都要围绕这四个靶心展开。举个例子“身份鉴别”不仅要求你有密码还要求密码必须足够复杂长度、字符类型、定期更换、失败要锁定。这在CentOS和Ubuntu上对应的就是/etc/pam.d/system-auth或/etc/pam.d/common-password这些PAM模块的配置。再比如“安全审计”不是开了auditd服务就行还得确保关键操作用户登录、特权命令执行、文件修改等都被记录并且日志有保护不能被随意删除。理解了这个逻辑整改就不会迷失在琐碎的命令里。2.2 至关重要的前期准备备份与快照这是我用血泪教训换来的第一条经验整改前必须备份必须做快照很多安全配置是破坏性的。比如你配置了错误的SSH策略可能导致自己都无法远程登录修改了密码策略可能让正在运行的定时任务因为认证失败而崩溃。没有备份一旦操作失误在等保测评的紧张周期里你面临的将是业务中断和更大的压力。我的标准操作流程是整机快照如果服务器是虚拟机VMware, KVM, Hyper-V在操作前创建一个完整的虚拟机快照。这是最快的回滚方式。关键配置文件备份将涉及本次整改的所有关键配置文件复制到安全目录并记录原始MD5值。# CentOS/Ubuntu 通用示例 mkdir -p /root/backup_$(date %Y%m%d) cp -a /etc/ssh/sshd_config /etc/pam.d/system-auth /etc/audit/audit.rules /root/backup_$(date %Y%m%d)/ md5sum /etc/ssh/sshd_config /root/backup_$(date %Y%m%d)/md5.list业务影响评估通知业务方可能的服务重启如SSH、审计服务。最好在变更窗口进行操作。2.3 工具与检查清单工欲善其事必先利其器。除了系统自带的命令我习惯准备一个简单的检查脚本用于整改前后的对比。这个脚本不复杂就是收集关键配置和状态。#!/bin/bash # check_security_baseline.sh echo 系统信息 cat /etc/os-release echo echo SSH 配置关键项 grep -E ^PermitRootLogin|^PasswordAuthentication|^ClientAliveInterval /etc/ssh/sshd_config echo echo 密码策略 grep -E ^PASS_MAX_DAYS|^PASS_MIN_DAYS|^PASS_WARN_AGE /etc/login.defs echo echo 审计服务状态 systemctl status auditd --no-pager 2/dev/null || systemctl status auditd.service --no-pager 2/dev/null echo echo 关键文件权限示例 ls -l /etc/passwd /etc/shadow /etc/group同时准备一份Excel或Markdown格式的整改清单列出测评报告中的每一个不符合项后面跟着“检查命令”、“整改命令”、“整改后验证命令”和“结果”四列。这能极大提升效率避免遗漏。3. 身份鉴别与访问控制强化实战这是等保测评的重灾区也是最容易拿分也最容易丢分的部分。3.1 密码复杂度与生命周期策略等保要求密码必须满足复杂度要求大小写字母、数字、特殊字符组合并定期更换。CentOS和Ubuntu的配置位置略有不同。CentOS 7.x主要修改/etc/login.defs和PAM配置文件。修改登录定义文件vim /etc/login.defs # 找到并修改以下参数示例值需根据实际策略调整 PASS_MAX_DAYS 90 # 密码最长使用90天 PASS_MIN_DAYS 1 # 密码最短使用1天防止频繁更改 PASS_MIN_LEN 10 # 密码最小长度10位 PASS_WARN_AGE 7 # 密码过期前7天提醒配置PAM密码复杂度vim /etc/pam.d/system-auth # 在“password”部分找到包含pam_pwquality.so的行修改或添加如下 password requisite pam_pwquality.so try_first_pass local_users_only retry3 authtok_type minlen10 lcredit-1 ucredit-1 dcredit-1 ocredit-1 enforce_for_root # 参数解释 # minlen10: 最小长度10 # lcredit-1: 至少1个小写字母 # ucredit-1: 至少1个大写字母 # dcredit-1: 至少1个数字 # ocredit-1: 至少1个特殊字符 # enforce_for_root: 对root用户同样生效非常重要如果找不到pam_pwquality.so可能需要安装yum install -y libpwquality。Ubuntu 18.04/20.04 LTSUbuntu使用/etc/pam.d/common-password。修改登录定义文件与CentOS相同修改/etc/login.defs。配置PAM密码复杂度vim /etc/pam.d/common-password # 找到以password requisite pam_pwquality.so开头的行修改为 password requisite pam_pwquality.so retry3 minlen10 difok3 ucredit-1 lcredit-1 dcredit-1 ocredit-1 enforce_for_root # 参数difok3表示新密码中与旧密码不同的字符至少3个。在Ubuntu上通常libpam-pwquality包已默认安装。实操心得设置enforce_for_root是很多人的盲点。等保测评会专门检查root用户的密码策略是否生效。如果不加这个参数root用户往往可以绕过复杂度限制这会被判定为不符合项。修改后务必用普通用户测试修改密码确保策略生效避免把自己锁在外面。3.2 SSH服务安全加固远程登录是入口这里必须严防死守。禁止Root用户直接登录这是铁律。# CentOS/Ubuntu 通用 vim /etc/ssh/sshd_config # 找到 PermitRootLogin修改为 PermitRootLogin no禁用密码认证启用密钥对认证强烈建议这是防暴力破解最有效的手段。# 首先确保已为登录用户配置好公钥~/.ssh/authorized_keys。 # 然后修改配置 PasswordAuthentication no PubkeyAuthentication yes修改默认端口虽然“安全通过隐匿”不是最佳实践但能减少大量自动化扫描骚扰。Port 23456 # 改为一个非22的高端口1024-65535配置会话超时ClientAliveInterval 300 # 300秒5分钟无活动则发送心跳包 ClientAliveCountMax 2 # 发送2次心跳无响应则断开连接限制监听地址和用户按需ListenAddress 192.168.1.100 # 只监听内网IP AllowUsers user1 user2192.168.1.0/24 # 只允许特定用户/网段登录修改后必须重启SSH服务# CentOS 7 systemctl restart sshd # Ubuntu systemctl restart ssh重启前务必确保你有另一种方式访问服务器如控制台并且密钥认证已配置无误我曾见过有人改了端口关了密码结果密钥没配好直接失联只能求助机房。3.3 账户与权限管理检查并锁定无用账户检查/etc/passwd对于nologinshell的系统账户如bindaemon确保其密码被锁定。# 查看账户状态 awk -F: ($2 ! !! $2 ! *) {print $1} /etc/shadow # 锁定一个账户如testuser passwd -l testuser # 或 usermod -L testuser设置正确的文件权限# 关键系统文件权限必须严格 chmod 644 /etc/passwd chmod 000 /etc/shadow # shadow文件只有root可读 chmod 644 /etc/group chown root:root /etc/passwd /etc/shadow /etc/group配置SUDO权限遵循最小权限原则。不要轻易给用户ALL(ALL) ALL权限。使用visudo命令编辑/etc/sudoers为特定用户授权特定命令。# 例如只允许运维用户user1重启nginx user1 ALL(root) /bin/systemctl restart nginx4. 安全审计与日志配置详解等保要求“审计覆盖到每个用户对重要用户行为和重要安全事件进行审计”。Linux下的审计守护进程auditd就是为此而生。4.1 Auditd审计规则配置CentOS通常默认安装了auditdUbuntu可能需要手动安装apt-get install auditd audispd-plugins。审计规则是核心定义了什么事件需要被记录。规则写在/etc/audit/rules.d/audit.rulesCentOS 7/Ubuntu或/etc/audit/audit.rules旧版。以下是一些等保测评中常被检查的关键规则# 1. 审计文件删除、修改、属性变更-w 监视文件路径-p 触发权限-k 给事件打标签 -w /etc/passwd -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/group -p wa -k identity -w /etc/gshadow -p wa -k identity -w /etc/sudoers -p wa -k privilege_escalation -w /etc/ssh/sshd_config -p wa -k ssh_config # 2. 审计所有系统管理命令的执行-a 添加规则exit,always 表示总是记录退出事件 -a always,exit -F archb64 -S execve -k exec_cmd # 监控64位程序的execve系统调用命令执行 -a always,exit -F archb32 -S execve -k exec_cmd # 监控32位程序的execve系统调用 # 3. 审计特权命令的使用例如su, sudo -w /bin/su -p x -k privilege_escalation -w /usr/bin/sudo -p x -k privilege_escalation # 4. 审计用户登录、认证事件 -w /var/log/lastlog -p wa -k logins -w /var/run/faillock -p wa -k logins # 记录认证失败CentOS 7/RHEL 7 -w /var/log/faillog -p wa -k logins # 记录认证失败其他系统 # 5. 审计网络配置变更 -w /sbin/iptables -p x -k network_mod -w /etc/sysconfig/iptables -p wa -k network_mod配置完成后需要重启auditd服务并清空旧规则加载新规则systemctl restart auditd auditctl -R /etc/audit/rules.d/audit.rules # 重新加载规则4.2 审计日志管理与分析审计日志默认保存在/var/log/audit/audit.log。这个文件会不断增长需要配置日志轮转。配置文件通常在/etc/audit/auditd.conf。关键参数# 保持默认或根据磁盘调整 max_log_file 50 # 单个日志文件最大MB数 num_logs 5 # 保留的日志文件数量轮转数量 max_log_file_action ROTATE # 达到最大值后的动作轮转 space_left 100 # 磁盘剩余空间低于100MB时触发动作 space_left_action email # 触发动作发送邮件需配置mail命令 admin_space_left 50 # 管理员紧急剩余空间 admin_space_left_action SUSPEND # 紧急动作暂停审计如何查看审计日志使用ausearch和aureport工具。# 查看所有失败的登录尝试 ausearch -m USER_LOGIN --success no -i # 查看所有使用了sudo命令的事件 ausearch -k privilege_escalation -i # 生成一份总结报告 aureport注意事项开启详细的审计规则如监控所有execve会产生海量日志对磁盘I/O和存储空间是巨大挑战。在生产环境中务必根据业务实际情况精细化定制规则并确保日志分区有足够容量建议单独分区。我曾见过一台开发服务器因为全量审计一周写满了200G的日志盘。5. 入侵防范与恶意代码防范5.1 系统服务与端口最小化“不需要的服务就是最大的漏洞”。等保要求关闭非必要的服务和端口。查看所有监听端口ss -tulnp # 或 netstat -tulnp禁用不必要的服务# CentOS 7 systemctl list-unit-files --typeservice | grep enabled # 查看所有已启动的服务 systemctl stop service_name # 停止服务 systemctl disable service_name # 禁止开机自启 # Ubuntu 类似常见可考虑关闭的服务务必根据实际业务评估bluetooth,cups打印服务postfix如果不用本地邮件avahi-daemonzeroconf。配置防火墙Firewalld/UFW/IptablesCentOS 7 (Firewalld):systemctl start firewalld systemctl enable firewalld firewall-cmd --permanent --add-servicessh --add-servicehttp --add-servicehttps # 放行业务端口 firewall-cmd --permanent --remove-servicedhcpv6-client # 移除可能不需要的服务 firewall-cmd --reload firewall-cmd --list-all # 查看规则Ubuntu (UFW):ufw enable ufw allow 22/tcp comment SSH # 如果改了SSH端口这里要对应 ufw allow 80,443/tcp comment Web ufw status verbose核心原则只开放业务必需的端口默认拒绝所有其他连接。5.2 软件更新与漏洞修复保持系统更新是防范已知漏洞的基础。但生产环境更新需谨慎建议先在测试环境验证。# CentOS yum check-update # 检查可用更新 yum update --security # 仅安装安全更新推荐 # 或 yum update # 更新所有包风险较高 # Ubuntu apt update apt list --upgradable apt upgrade # 更新所有包 # 对于LTS版本专注安全更新更稳妥制定更新策略非业务高峰期进行有完整的回滚预案。对于核心业务服务器我倾向于只应用安全更新CentOS的yum update --security Ubuntu可通过unattended-upgrades工具配置自动安全更新。5.3 安装与配置主机级防病毒软件ClamAV等保三级明确要求“安装防恶意代码软件”。对于Linux服务器虽然病毒较少但ClamAV是一个开源且符合要求的选择。CentOS/Ubuntu 安装ClamAV# CentOS 7 yum install -y epel-release yum install -y clamav clamav-update # Ubuntu apt-get install -y clamav clamav-daemon配置与更新首次安装后需要更新病毒库freshclam # 更新病毒定义数据库配置定时扫描。例如编辑Cron任务每天凌晨扫描关键目录crontab -e # 添加一行例如每天2点扫描 /tmp 和 /home 0 2 * * * /usr/bin/clamscan -r -i /tmp /home --log/var/log/clamav/daily_scan.log-r递归-i只输出感染文件--log记录日志。实操心得ClamAV在服务器上主要用来扫描用户上传的文件、Web目录等防范作为“跳板”传播病毒。它的性能开销需要关注全盘扫描对I/O压力很大务必安排在业务低峰期。病毒库更新可能因为网络问题失败需要在/etc/clamav/freshclam.conf中配置备用镜像源。6. 其他关键项与收尾工作6.1 配置历史命令记录与时间同步历史命令加固等保要求能审计用户操作历史。# 编辑 /etc/profile 或用户家目录的 .bashrc export HISTTIMEFORMAT%F %T # 为历史命令加上时间戳 export HISTSIZE5000 # 保留命令条数 export HISTFILESIZE5000 export HISTCONTROLignoredups # 忽略重复命令 # 可选实时追加历史命令到文件防止意外丢失 shopt -s histappend export PROMPT_COMMANDhistory -a配置NTP时间同步所有服务器的日志时间必须一致否则审计毫无意义。# CentOS 7 yum install -y chrony systemctl start chronyd systemctl enable chronyd chronyc sources -v # 查看时间源状态 # Ubuntu apt-get install -y chrony systemctl start chrony systemctl enable chrony配置/etc/chrony.conf使用可靠的内外部时间源如ntp.aliyun.com或内部NTP服务器。6.2 内核参数安全加固通过sysctl调整内核参数提升系统安全性。编辑/etc/sysctl.conf或/etc/sysctl.d/99-security.conf。# 禁止ICMP重定向防网络拓扑欺骗 net.ipv4.conf.all.accept_redirects 0 net.ipv4.conf.default.accept_redirects 0 net.ipv6.conf.all.accept_redirects 0 # 禁止发送ICMP重定向 net.ipv4.conf.all.send_redirects 0 # 开启SYN Cookie保护防SYN Flood攻击 net.ipv4.tcp_syncookies 1 # 忽略ICMP广播请求防Smurf攻击 net.ipv4.icmp_echo_ignore_broadcasts 1 # 开启恶意ICMP错误消息保护 net.ipv4.icmp_ignore_bogus_error_responses 1 # 开启IP转发检查非网关服务器应关闭 net.ipv4.ip_forward 0 # 开启RPF反向路径过滤防IP欺骗 net.ipv4.conf.all.rp_filter 1 net.ipv4.conf.default.rp_filter 1 # 不响应ICMP时间戳请求 net.ipv4.tcp_timestamps 0 # 限制系统级核心转储core dump fs.suid_dumpable 0使配置生效sysctl -p。6.3 最终检查与报告生成所有整改完成后进行一次全面的自查。运行安全检查脚本使用前面准备的脚本对比整改前后的输出。使用自动化工具辅助检查Lynis优秀的主机安全审计工具。git clone https://github.com/CISOfy/lynis cd lynis ./lynis audit systemOpenSCAP可以根据等保等标准生成合规性报告。整理证据材料将关键的配置截图、命令输出结果、扫描报告等整理成文档。这既是整改记录也是应对测评老师提问的“弹药”。重启测试在变更窗口内重启服务器确保所有配置特别是内核参数、服务自启在重启后依然生效。这是很多“临时生效”配置的照妖镜。7. 常见问题与排查技巧实录在实际整改中你会遇到各种各样的问题。这里记录几个最典型的。7.1 SSH加固后无法登录问题现象修改sshd_config并重启服务后使用密钥或密码均无法连接连接超时或被拒绝。排查思路检查防火墙是否放行了新的SSH端口在服务器本地用ss -tlnp | grep :23456你的端口检查是否在监听。检查SELinux/AppArmor如果启用# CentOS SELinux getsebool -a | grep ssh # 如果ssh端口改了需要告诉SELinux semanage port -a -t ssh_port_t -p tcp 23456 # 查看SSH相关审计日志 ausearch -m avc -ts recent | grep sshUbuntu的AppArmor也可能限制SSH检查/etc/apparmor.d/下相关配置。检查SSH配置语法一个拼写错误就能导致服务启动失败。用sshd -t测试配置文件语法。回滚如果以上都无解立即通过云平台控制台或物理机房Console口登录用备份的配置文件覆盖并重启服务。7.2 密码策略修改后现有用户未立即生效问题现象修改了/etc/login.defs中的PASS_MAX_DAYS但用chage -l username查看用户发现密码过期时间没变。原因与解决/etc/login.defs中的参数只对新创建的用户生效。对现有用户需要手动修改。# 修改单个用户密码过期时间 chage -M 90 username # 设置90天后过期 # 批量修改所有普通用户排除系统用户 awk -F: $3 1000 {print $1} /etc/passwd | xargs -I {} chage -M 90 {}7.3 Auditd服务占用磁盘空间暴涨问题现象/var/log/audit/目录迅速被audit.log塞满。紧急处理立即清理旧日志如果确定不需要cat /dev/null /var/log/audit/audit.log。注意这会清空当前日志文件。临时增加磁盘空间或扩展分区。根本解决优化审计规则。避免使用过于宽泛的规则如-a always,exit -S all。使用-F字段进行过滤例如只审计特定用户-F auid1000。调整auditd.conf中的max_log_file和num_logs并确保日志分区足够大。考虑将审计日志发送到远程的日志服务器使用audisp-remote插件减轻本地存储压力。7.4 防火墙配置错误导致业务中断问题现象配置完防火墙后Web服务或数据库无法从外部访问。排查步骤本地验证在服务器本机用curl localhost:80或telnet localhost 3306测试服务本身是否正常。检查防火墙规则# Firewalld firewall-cmd --list-all --zonepublic # UFW ufw status numbered # Iptables如果底层使用 iptables -L -n -v检查服务绑定地址确保服务不是只绑定在127.0.0.1上。例如MySQL的bind-address参数可能是127.0.0.1需要改为0.0.0.0或业务IP注意安全风险。临时放行如果紧急可以先添加一条宽松规则恢复业务再慢慢排查。# Firewalld 临时放行80端口 firewall-cmd --add-port80/tcp7.5 内核参数优化导致性能问题或网络异常问题现象修改sysctl.conf后出现网络连接变慢、某些应用异常等问题。排查与回滚逐一排查最可能出问题的是TCP相关参数如tcp_tw_recycle在NAT环境下有问题高版本内核已移除、文件描述符数量等。使用默认值注释掉或删除你认为有问题的配置行然后sysctl -p重载。参考官方文档对于数据库如Oracle, PostgreSQL、负载均衡器如Nginx, HAProxy等特定应用有其推荐的内核参数设置不要盲目套用通用安全配置。整改的最终目的是在安全与稳定、性能之间找到平衡点。没有绝对的安全只有相对的风险可控。每一次完整的等保整改都是对系统架构和安全认知的一次深度梳理。我的习惯是在每次整改完成后将最终稳定的配置写成Ansible Playbook或Shell脚本形成自己团队的“安全基线”这样下次再遇到新的CentOS或Ubuntu服务器就能做到快速、标准化的部署这才是长治久安之道。