实战总结：三步教你在 Ubuntu 上防御 SSH 暴力破解
前言：直面真实的互联网
最近刚折腾了一台新的海外 VPS。众所周知，只要你的服务器暴露在公网 IP 下，且开放了 22 端口（SSH 默认端口），它从上线的那一秒起，就每分每秒都在被全世界的自动化脚本扫描和尝试爆破。
黑客并不认识你，他们只是用僵尸网络无差别地尝试弱口令字典。今天，我就把这次从“发现被爆破”到“彻底加固防线”的真实实战经验总结下来，希望能帮到同样拥有小破服务器的你。
第一步：查看你的服务器是否正在被爆破
防御的第一步是“看见”。SSH 的登录尝试记录在系统的认证日志中。根据系统不同，路径通常为：
- Debian/Ubuntu：
/var/log/auth.log - CentOS/RHEL：
/var/log/secure
你可以通过以下命令快速统计当前有多少 IP 正在疯狂尝试密码：
1
2
# Ubuntu 系统
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr
如果输出了一大堆 IP 和对应的尝试次数，恭喜你，你的服务器正在被“重点关照”。
第二步：部署自动防线神器 —— Fail2ban
既然攻击是自动化的，我们的防御也必须自动化。fail2ban 是 Linux 下最经典的防御工具，它的原理很简单：监控日志，如果发现同一个 IP 多次密码错误，就直接调用防火墙把它拉黑。
1. 安装与“小插曲”
在 Ubuntu 上，直接运行安装命令：
1
sudo apt update && sudo apt install fail2ban
⚠️ 踩坑预警： 在安装时，我遇到了一个报错：Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1435 (apt)。
这通常是因为你之前有一个 apt 进程没结束，或者系统的自动更新任务正在后台运行。
- 排查方法：运行
ps -p 1435 -f（替换为报错的进程号）看看它到底在干嘛。 - 解决办法：如果确认是卡死的旧任务，可以用
sudo kill -9 1435强杀，然后执行sudo dpkg --configure -a修复包状态，即可顺利安装。
2. 黄金配置法则
安装好之后，千万不要直接修改自带的 jail.conf，因为系统更新时会覆盖它。正确的做法是新建一个专属配置文件：
1
sudo nano /etc/fail2ban/jail.local
将以下配置粘贴进去：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[DEFAULT]
# 封禁时长（单位：秒）。-1 代表永久封禁（极度推荐，让黑名单越来越干净）
bantime = -1
# 检测的时间窗口（单位：秒）。过去 10 分钟内
findtime = 600
# 允许失败的次数。10 分钟内失败 3 次就开始封禁
maxretry = 3
# 白名单：千万别把自己关在门外！
# /8 和 ::1 分别代表 IPv4 和 IPv6 的本机回环地址，必须保留
# 如果你有固定公网 IP（比如办公室或家里），请加在后面，用空格隔开
ignoreip = 127.0.0.1/8 ::1 203.0.113.50
[sshd]
enabled = true
port = ssh
filter = sshd
backend = systemd
保存退出（Ctrl+O -> Enter -> Ctrl+X），然后启动并设置开机自启：
1
2
sudo systemctl restart fail2ban
sudo systemctl enable fail2ban
第三步：见证奇迹与性能焦虑解答
配置好之后，运行监控命令：
1
sudo fail2ban-client status sshd
你会震撼地发现，短短十分钟内，可能就有几十次失败记录，并且几个恶意 IP 已经被自动拉黑了。
常见疑问：这种级别的爆破，会拖垮我的小 VPS 吗？
答案是：完全不会。
SSH 尝试请求产生的网络流量微乎其微。对于现代硬件来说，处理这种低频并发占用的 CPU 和内存几乎为零。只要我们通过 fail2ban 设置了永久封禁（bantime = -1），那些恶意 IP 尝试三次后就会被防火墙直接丢弃数据包，不再消耗系统资源去验证密码。随着时间的推移，你的服务器反而会越来越“安静”。
当然，这一切的大前提是：你的 root 密码必须足够变态！（建议使用各大云厂商控制台提供的随机密码生成功能，长度 16 位以上，包含大小写+数字+符号）。
总结
通过这次实战，我们用非常低的成本（安装一个软件 + 几行配置），建立起了一套自动化的 SSH 防御机制。
如果未来你想追求绝对的极致安全，可以进一步去配置 SSH 密钥登录并彻底禁用密码认证。但在拥有复杂强密码 + Fail2ban 永久封禁的双重保障下，目前的防线已经足够让我们这些个人开发者高枕无忧了。
安全无小事，祝大家的服务器都能平稳运行！