Linux 服务器安全加固实测：SSH、fail2ban 与防火墙该验证哪些指标

TL;DR：先验证暴露面，再谈安全感

Linux 服务器安全加固不是把 SSH（安全远程登录协议）端口改掉、装上 fail2ban（登录失败封禁工具）、再开一个防火墙就算结束。真正有用的做法，是把“如何配置”转成“如何验证”：外部还能不能扫到不该开放的端口，错误密码会不会触发封禁，正常运维会不会被误伤，重启后规则是否仍然生效。本文按一台新上线 VPS（虚拟专用服务器）或独服（独立服务器）的场景，把 SSH（安全远程登录协议）、fail2ban（登录失败封禁工具）与防火墙三块拆开，重点放在可复查指标。

我更建议把这类加固当作上线前验收项。比如新机交付后 30 分钟内，先记录 ss -tulpen 的监听端口，再从外部节点扫一遍 22、80、443、数据库端口和面板端口；配置改完后，保留 24 小时认证日志，观察重复爆破、误封管理员 IP、规则重启丢失等问题。关于主机基础选型，也可以结合 VPS 主机 和 技术教程 分类里的运维经验一起看。

一、SSH：验证的不只是端口，而是登录面

SSH 是 Linux 运维的入口，也是最容易被自动化脚本反复尝试的入口。很多人第一步会把默认 22 端口改成高位端口，这有一定降噪价值，但不要把它当成核心安全措施。真正该验证的指标有四个：是否禁止 root 直接登录，是否优先使用密钥登录，密码登录是否按场景关闭，以及允许登录的用户范围是否足够窄。

在我的测试环境中，我通常先保留一个已有会话不退出，再开第二个终端验证新配置。这样即使 sshd_config 写错，也还有回滚窗口。关键配置可以按这个方向检查：PermitRootLogin no 表示禁止 root 直接登录；PasswordAuthentication no 表示关闭密码登录；PubkeyAuthentication yes 表示启用密钥；AllowUsers deploy adminuser 表示限制可登录用户。每改一项，都先运行 sshd -t 做语法检查，再重载服务，而不是直接重启整台机器。

关闭密码登录前必须确认密钥已经能从外部网络登录。很多新手复制命令时一路回车，结果 ~/.ssh 目录不是 700，authorized_keys 不是 600，最后自己把自己锁在门外。上线前的验收指标可以写得很具体：root 用户无法直接登录；不存在测试账号、弱口令账号；固定办公 IP 登录成功；非授权用户失败并留下日志。

二、fail2ban：看封禁是否真实命中日志

fail2ban 的逻辑并不复杂：它读取日志，按规则匹配失败行为，然后调用防火墙封禁来源 IP。问题在于，不同系统的 SSH 日志位置、systemd journal（系统日志服务）后端、正则规则和防火墙后端可能不同。表面上 fail2ban-client status sshd 显示在运行，不代表它真的抓到了失败登录。

更可靠的验证方式，是制造一次受控失败。比如从一台测试 IP 连续输入错误密码，观察三个点：认证日志是否出现失败记录；fail2ban-client status sshd 的 Currently failed 或 Banned IP list 是否变化；被封禁后该测试 IP 是否无法继续连接。不要拿唯一办公出口 IP 撞规则，可以临时把 bantime 设为 10 分钟，验证完成后再改回正式值。

常见参数里，maxretry 是允许失败次数，findtime 是统计窗口，bantime 是封禁时长。对公网 SSH，我一般不建议把 maxretry 设得太低，否则手机热点、跳板机、CI 部署脚本偶发失败都可能被误伤。更稳的做法是先把 SSH 登录入口收窄，再让 fail2ban 做补充防线。面向中文用户的服务器场景，经常会遇到跨地区运维、临时网络切换、售后协助等情况，规则设置过猛反而会增加工单成本。

三、防火墙：默认拒绝之前先列清业务端口

防火墙最怕两种配置：一种是全开，只做了心理安慰；另一种是默认拒绝后忘了放行业务，导致网站、数据库复制、监控、备份全部异常。无论用的是 ufw、firewalld 还是 nftables（Linux 新一代包过滤框架），上线前都应该先列清端口表。

建议把端口分成三类。第一类是公网必要端口，例如 80 和 443；第二类是仅管理端口，例如 SSH、面板、监控 Agent；第三类是只应内网访问的服务，例如数据库、缓存、消息队列和备份端口。如果第三类端口能从公网扫到，优先级应高于“再装一个安全插件”。数据库监听到 0.0.0.0 但只靠弱密码防守，是很多服务器被拖库的起点。

验证时可以先在服务器本机执行 ss -tulpen 看监听，再从外部节点执行端口扫描。两边结果要对得上：本机监听不等于公网可访问，公网不可访问也不代表服务没在本机暴露。对于使用云控制台安全组的环境，还要把系统防火墙和控制台规则一起记录，因为两层规则叠加后，后期排障容易出现“服务器上看着放行，外面就是不通”的情况。

四、建议保留一张加固验收表

下面这张表不是为了写文档好看，而是为了减少上线后扯皮。管理员、开发、售后或安全负责人只要看同一张表，就能知道当前服务器到底完成了哪些验证。

如果是给客户交付的服务器，我还会记录测试时间、测试来源 IP、系统版本和防火墙后端。对于需要长期运维的独服或 VPS（虚拟专用服务器），这类记录比“我已经加固过了”更有价值。

五、不要忽略日志、备份和恢复路径

安全加固不是一次性动作。SSH、fail2ban 与防火墙只是入口层，后续还要看日志轮转、异常告警、备份恢复和权限分离。比如 /var/log/auth.log 或 journal 日志是否保留足够时间，封禁次数异常增多时有没有告警，管理员离职后密钥是否及时移除，备份服务器是否也套用了同样的访问限制。

这里有一个容易被忽视的点：面板类工具会自动改动防火墙或服务配置。安装面板前后，都应该重新跑一遍端口和 SSH 验证。否则你以为系统已经只开放 80、443 和 SSH，实际面板安装脚本又放开了一组管理端口。WHT 上讨论主机环境时，很多“被扫爆了”“后台突然暴露了”的问题，最后都能追到这种配置漂移。

选择美国、香港或其他地区节点时，可以参考 Hostease 相关评测，但不要把服务商口碑等同于服务器已经安全。服务商能提供稳定基础设施，最终暴露哪些端口、保留哪些账号、设置怎样的封禁阈值，仍然取决于运维执行。

六、结论：先做最小暴露，再做持续复查

总结一下，Linux 服务器安全加固的优先级应该是：先确认登录入口最小化，再让 fail2ban 处理重复爆破，最后用防火墙把公网暴露面压到业务所需范围。每一步都要能被验证，而不是只留下“已安装”“已启用”的状态。

我的建议很直接：新服务器上线前，至少完成一次外部端口扫描、一次失败登录封禁测试、一次 SSH 配置语法检查、一次重启后规则复测。已经在线的服务器，可以先从非高峰时段开始做，只改一项、测一项、记录一项。对中文站长和中小团队来说，这套流程不复杂，但能显著降低弱口令爆破、误开放数据库、规则重启丢失这几类高频风险。

如果预算允许，后续再叠加集中日志、监控告警、备份演练和最小权限账号管理。安全不是靠某个工具一劳永逸，而是靠每次变更后都能复查。SSH、fail2ban 与防火墙，正好适合作为 Linux 服务器的第一张安全验收单。