Linux 安全加固实战：等保 2.0 下的服务器安全配置

为什么等保 2.0 让 Linux 加固从”可选项”变成”必答题”

等保 2.0 从 2019 年正式实施后，Linux 服务器作为最常见的业务底座，一直是测评的重点对象。很多团队在第一次参加等保测评时都会遇到同一个问题：业务代码写得没问题，但安全基线的整改项有一大半落在操作系统层面。这里说的加固，不是装个杀毒软件或者改个密码那么简单，而是要在不破坏业务可用性的前提下，满足合规要求，同时真正降低被入侵的概率。

我在实际项目里见过不少反例。有的单位为了通过测评，直接关掉 SELinux，甚至停掉防火墙，理由是”不影响业务”；也有的团队把 SSH 端口改成一个冷门端口，但没考虑安全组放行，结果远程登录直接断掉。真正的加固，应该是一套有取舍、有验证的配置组合。

先厘清等保 2.0 对 Linux 服务器的测评重点

等保 2.0 的控制点很多，但落到 Linux 服务器上，最常被检查的其实集中在身份鉴别、访问控制、安全审计、入侵防范、恶意代码防范和资源控制这几个类。下面这张表可以快速帮你看清测评项和 Linux 配置的对应关系。

这张表不是让你逐条去套，而是帮你理解测评员看重的是”有配置依据”。很多时候整改项不合格，不是缺软件，而是缺可落地的配置证据。

第一步：账号和口令，底子不牢地动山摇

账号口令是 Linux 的第一道门。很多老旧服务器上还留着 6 位短密码，甚至存在 uid 为 0 的非 root 账号。等保 2.0 的身份鉴别，是扣分重灾区。

先说密码复杂度。在 CentOS/RHEL 系列上，通常通过 PAM 的 pwquality 模块来控制。

# 安装 pwquality 模块
yum install -y libpwquality

# 在 /etc/pam.d/system-auth 和 password-auth 中增加：
# password requisite pam_pwquality.so retry=3 minlen=12 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1

上面的配置要求密码最短 12 位，至少包含一个数字、一个大写字母、一个小写字母和一个特殊字符。看起来简单，但如果上层应用有同步密码的需求，过严的策略会导致应用账号创建失败。落地前要和开发团队确认。

再说登录失败处理。推荐使用 pam_faillock，在 system-auth 和 password-auth 中配置锁定策略：

auth        required      pam_faillock.so preauth audit deny=5 unlock_time=600
auth        sufficient    pam_unix.so
auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=600

5 次失败锁定 10 分钟。注意：如果前面还有堡垒机或 VPN，需要确认来源 IP 是否被代理隐掉，否则锁定策略可能失效或误锁。

SSH 加固：远程管理入口必须重点设防

SSH 是 Linux 服务器最常用的远程管理通道，也是扫描器最关注的入口。基本的 SSH 加固建议包括：禁用 root 直接登录、按需修改端口、限制登录用户、优先使用密钥认证。

修改 /etc/ssh/sshd_config 的关键配置：

Port 2222
PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes
AllowUsers opsuser deployuser
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

这里有两个常见坑。第一，禁用 root 后，如果某些脚本依赖 root 的 SSH 直连，运维会中断。你需要提前排查是否有这类隐性问题。第二，修改端口后，云安全组或本地防火墙没有同步放行新端口，可能导致连接直接超时。我的习惯是：先用 sshd -t 验证配置，再重启 sshd，并且保持当前会话不退出。

如果是从堡垒机统一入口登录，可以只允许内网网段访问 SSH，在 /etc/hosts.allow 中添加：

sshd: 192.168.0.0/16

遵从这个原则，即便以后要加临时 IP，也只是追加一行然后 reload，不需要改动业务侧。

最小权限：从清理账号到精细化授权

Linux 的权限模型很清晰，但实施时容易走样。最常见的情况是：所有人都有 root 权限，或者用 chmod 777 解决一切。等保要求访问控制和权限分离，具体做这三件事就足够起步：

• 清理不用的系统账户，将其 shell 改为 /sbin/nologin 或直接锁定。
• 用 sudo 做精细化命令授权，而不是给整机 root。
• 定期检查全局可写文件和高危权限文件，封堵后门入口。

比如，只允许 ops 用户重启 Nginx 和 PHP-FPM：

visudo -f /etc/sudoers.d/ops
Cmnd_Alias SERVICES = /bin/systemctl restart nginx, /bin/systemctl restart php-fpm
ops ALL=(root) NOPASSWD: SERVICES

sudo 配置必须用 visudo 检查语法，否则一行配置错误，所有 sudo 都会失效。曾经有客户因为在这里手动改了文件，导致整个 sudo 系统崩溃，最后只能通过物理 console 修复，这个教训值得记住。

日志审计：存文件容易，留证据难

等保 2.0 的安全审计项要求审计记录留存不少于 6 个月，并覆盖日期、用户、操作类型等。很多团队只开了 rsyslog，但日志既没有集中收集，也没有配置轮转。测评现场如果只丢出 /var/log/messages，往往是通不过的。

至少要做到三件事：

1. 开启 auditd，对关键文件配置审计规则。
2. 把日志实时同步到远程日志服务器。
3. 配置 logrotate，避免日志占满磁盘导致业务中断。

一个实用的 auditd 规则，监控 /etc/passwd 和 /etc/shadow 的变更：

auditctl -w /etc/passwd -p wa -k passwd_change
auditctl -w /etc/shadow -p wa -k shadow_change

将上述规则写入 /etc/audit/rules.d/audit.rules 并重启 auditd，之后用 ausearch -k passwd_change 查询变更记录。注意，auditd 自身的日志分区要单独规划，否则 max_log_file 满后系统会停止审计，极端情况下甚至导致机器假死。

文件完整性：别把全家桶都塞进基线

等保的入侵防范项要求”检测对重要文件和目录的篡改行为”。AIDE 是常见选择，但初次初始化时如果范围没控制好，后续就是告警轰炸。我见过有团队把 /var/log 和 /tmp 都纳入检查，结果每天几十封告警，最后运维直接把 AIDE 停掉了。

合理做法是只对系统命令、配置文件、动态库等敏感目录建立基线，排除临时和日志目录：

# /etc/aide.conf 中定义检查范围
/usr/sbin/ p+i+md5+sha256
/usr/bin/ p+i+md5+sha256
/etc/ p+i+md5
!/var/log/
!/tmp/

初始化数据库后，可以配合 cron 每周检查一次，并将报告输出到安全团队。顺便说一句，如果一个系统路径根本不会被业务读写，就不应该出现在告警列表里，这也是减少噪声的关键。

服务与内核参数：加固不是照搬脚本

Linux 默认安装了许多用不到的服务，等保要求”关闭不需要的系统服务、默认共享和高危端口”。但盲目禁用服务可能把依赖关系拆坏。

我建议先做一次端口摸底：

netstat -tulnp | grep LISTEN

然后逐项确认：这个端口对应什么进程？是否需要对外开放？如果不需要，停掉服务或者限制监听地址。对数据库、Redis 这类内部组件，绑定 127.0.0.1 或内网 IP，比简单加防火墙规则更可靠。

/etc/sysctl.conf 里的常用加固参数很多，比如限制 SYN 攻击、关闭 IP 转发等。但内核参数不能盲调。例如 net.ipv4.ip_forward 在 Docker 宿主机上必须为 1，否则容器网络直接不通。任何加固脚本拿过来，都要先读注释、再在测试环境验证。

常见误区：加固不是自废武功

下面这几个误区是我在项目里反复看到的：

• 改个不常见端口就觉得高枕无忧。其实非标准端口只增加扫描成本，挡不住定向探测。
• 把 SELinux 直接禁用，而不是从 permissive 模式逐步过渡。正确做法是先用 permissive 收集 AVC 日志，再为业务域放行。
• 加固完成后不做复查。测评员现场抽查一条配置，发现和加固脚本里的不一样，整个整改周期又要重来。

曾经有个客户，开发在测试环境跑了加固脚本，把 UMASK 从 022 改成 027，结果新创建的应用日志文件权限变成 750，应用进程是另一个用户，直接读不了日志，排查了整整一个下午。所以，每一处变更都要有测试用例。

落地建议：从三件小事开始闭环

如果你第一次接触等保 Linux 加固，不要一开始就上全套复杂方案。先把账号口令、SSH 配置、日志审计这三件事做成基线，再上 AIDE、内核参数、服务裁剪。每做一项，就生成一份变更记录，并重新执行一次业务回归测试。

等保 2.0 不是一次性工程，而是持续改进的闭环。当你的加固步骤沉淀成脚本和文档，后续每一次等保测评都会变得更轻松。这也是从”救火式整改”走向”常态化安全运营”的关键一步。