本文教你如何在 45 分钟内对一台暴露在公网的 Ubuntu 22.04 服务器完成 SSH 加固、fail2ban 自动封禁、防火墙入站规则三件套配置，把暴力破解、扫描探测、未授权端口访问的风险压到最低。读完本文你会得到三件可直接落地的产出：第一，一份可复用的 sshd_config 关键参数表，含端口、密钥、登录限制；第二，fail2ban 针对 SSH 与 nginx 的 jail 配置模板，封禁策略与白名单维护方法；第三，一组覆盖 ufw 与 firewalld 的入站规则清单，给团队建立可复用的安全基线，让新机器在交付时就处于最小攻击面状态。
一、为什么先加固 SSH 再启用 fail2ban
如何在保留远程运维便利的同时，把暴露在 22 端口的暴力破解流量降到几乎为零，是 Linux 服务器安全加固的第一个核心问题。仅靠改强密码已经不够，因为公网扫描器每秒可以尝试上千次组合，单点密码即便复杂也可能在监控发现前被试穿。正确的做法是分层防御：SSH 服务本身先关闭密码登录改用密钥，再用 fail2ban 把异常登录尝试自动封禁，最后用防火墙限制只有指定来源 IP 能访问 22 端口。
在做这件事之前先评估两件事：一是当前是否有完整的运维白名单 IP 池，二是是否有跳板机或 VPN 入口可用。如果还没有固定出口 IP，建议先准备一台跳板服务器再动手，避免改完配置自己被锁在外面。云端跳板机的资源选型可以参考云服务器选购指南中的计算与带宽（指网络出口的数据传输速率，单位 Mbps）部分。云服务器（即通过虚拟化技术从物理服务器集群中切分出来的弹性计算资源）做跳板机时配置可以很低，1 核 1G 就够日常 SSH 转发。
二、SSH 服务核心加固清单
打开 /etc/ssh/sshd_config，按下面的参数表逐项调整。核心配置要点：
- Port 22022：把默认 22 端口改成五位非标准端口，能挡住 95% 的随机扫描
- PermitRootLogin no：禁止 root 直接登录，改用普通用户加 sudo
- PasswordAuthentication no：关闭密码登录，强制密钥
- PubkeyAuthentication yes：开启公钥认证
- AllowUsers ops deploy：白名单可登录用户
- MaxAuthTries 3：单次连接最大尝试次数
- ClientAliveInterval 300：闲置 5 分钟发心跳
改完执行 sshd -t 验证配置语法，再 systemctl reload sshd 生效。务必保留当前 ssh 会话再开一个新会话验证密钥登录正常后再退出原会话，避免改坏被锁。实际操作中还要规划好密钥的分发与轮换：建议给每个团队成员单独签发密钥，统一通过配置管理工具下发到 authorized_keys，离职时只需要从配置库中删除对应条目即可全机回收权限。在多人协作环境里，可以考虑引入 SSH 证书机制，由中央 CA 签发短期证书替代静态公钥，让权限随时间自动过期。如果你的服务器是 VPS（Virtual Private Server，虚拟专用服务器，通过虚拟化划分的独立实例），还要确认控制台救援入口可用。需要远程批量同步密钥的流程可以参考美国 VPS 部署教程里的 SSH 与公钥分发部分。
三、fail2ban 自动封禁配置
apt install fail2ban 后在 /etc/fail2ban/jail.local 写入下面的策略。核心字段说明：
- bantime = 3600：单次封禁 1 小时
- findtime = 600：10 分钟窗口
- maxretry = 5：超过 5 次失败即封
- backend = systemd：从 systemd journal 读日志
- ignoreip = 你的运维出口 IP：白名单防误伤
最常用的两个 jail 是 sshd 与 nginx-http-auth。sshd jail 监控 SSH 登录失败，nginx-http-auth jail 监控网站后台的 401 错误。fail2ban-client status sshd 可以查看当前封禁列表，fail2ban-client unban 1.2.3.4 用来手动解封。日志路径会因发行版不同而变化，systemd 系列直接读 journal，老版本读 /var/log/auth.log，配置错了会出现”封不到任何人”或”自封自己”两种典型故障。还要为 fail2ban 配置邮件告警，把每次封禁事件推送到运维群，新机器上线第一天往往会触发数十次封禁，这能帮助团队快速识别正在被针对的扫描源 IP 段。如果业务对误封容忍度低，可以把 bantime 调短到 600 秒并加大 maxretry 阈值。
四、防火墙入站规则与下一步建议
ufw 在 Ubuntu/Debian 上更易用，firewalld 在 RHEL/CentOS/Rocky 上更原生。无论哪种工具，基本原则都是默认拒绝、按需放行：
- ufw default deny incoming：默认拒绝所有入站
- ufw default allow outgoing：默认允许所有出站
- ufw allow from
to any port 22022 proto tcp：白名单 IP 才能访问 SSH - ufw allow 80,443/tcp：放行 HTTP 与 HTTPS
- ufw limit 22022/tcp：对 SSH 端口做连接限速
- ufw enable：开启防火墙
防火墙规则改完用 ufw status numbered 检查顺序，确保拒绝规则没有在放行规则前面。生产服务器还应该加上日志规则，把被拒绝的连接尝试落盘以便审计。如果同时在跑 nginx 反向代理与 WordPress，建议结合WordPress 香港主机购买指南的主机选型与WordPress 性能调优实战的缓存策略一起做，把应用层与系统层的防御统一规划。另外建议把每台机器的 sshd_config、jail.local、ufw 规则纳入版本管理，配合 etckeeper 这类工具记录每次变更，发生问题时可以快速比对到底是哪条改动引入的故障，让运维变更具备可审计性。
总结来说，Linux 服务器安全加固不是单点优化而是分层防御，建议你今天就花 45 分钟按本文清单做三件事：第一，关闭 SSH 密码登录并改用密钥；第二，开启 fail2ban 监控 sshd jail；第三，用 ufw 或 firewalld 把入站端口收敛到最小集合。完成后可以考虑把整套加固脚本沉淀成 Ansible playbook 或 cloud-init 模板，让所有新机器在交付时就具备一致的安全基线，团队也能把人工巡检的精力转移到更高价值的入侵检测、日志聚合、SIEM 接入上面，做到从被动应对走向主动防御。后续延伸建议：把 auth.log 接入 Loki，把 fail2ban 封禁事件接入 Prometheus 告警，把每周一次的安全基线巡检写进运维 SOP，让风险敞口在小时级被发现并修复。