🔥 服务器突然挂了？我被攻击了？一次惊心动魄的故障排查经历

🚨 突如其来的灾难

我服务器上一直有一个服务在跑，但是突然发现我的一个重要网络服务怎么都连不上了 😱

症状如下：

🔴 客户端连接超时
🔴 延迟显示 -1
🔴 各种重试都无效

第一反应：🤯 “完了，服务器是不是被黑了？”

🆘 紧急抢救

既然连不上，那就先重启试试吧（程序员的万能解决方案 😅）

随后我到服务器提供商面板去重启

神奇的事情发生了 ✨ —— 重启后服务立即恢复正常！

但是问题来了：为什么重启就好了？根本原因是什么？

作为一个有追求的技术人，怎么能就这样算了呢？必须要找出真相！🕵️‍♂️

🔍 开始福尔摩斯时间

第一条线索：可疑的登录记录

登录服务器后，发现了第一个异常：

Last failed login: Sat Jul  5 07:54:21 EDT 2025 from 152.200.181.42 on ssh:notty
There were 40 failed login attempts since the last successful login.

😳 40次失败登录？ 这绝对不正常！

第二条线索：系统错误日志

继续深挖，查看系统日志：

journalctl --since "2025-07-05 06:00:00" --until "2025-07-05 07:13:00" -p err

发现了这些可疑的错误：

Jul 05 06:08:13 sshd: error: kex_exchange_identification: Connection closed
Jul 05 06:10:31 sshd: error: kex_exchange_identification: Connection closed  
Jul 05 06:46:52 sshd: fatal: userauth_finish: send failure packet: Connection

🤔 SSH连接错误？感觉离真相越来越近了…

第三条线索：暴力破解攻击！并且ip来自于德国、香港等地

当我查看详细的登录失败记录时，真相大白了！

journalctl | grep "Failed password" | tail -20

映入眼帘的是一连串触目惊心的攻击记录：

Jul 05 07:41:44 Failed password for root from 80.94.95.15
Jul 05 07:42:26 Failed password for root from 123.58.209.224  
Jul 05 07:42:45 Failed password for invalid user odoo15 from 161.35.72.143
Jul 05 07:43:02 Failed password for root from 103.63.25.239
Jul 05 07:47:41 Failed password for root from 152.200.181.42
...

🚨 天哪！我的服务器正在遭受大规模的SSH暴力破解攻击！

🧩 真相大白

现在一切都说得通了！

攻击的影响链条：

🏴‍☠️ 多个IP同时发起SSH暴力破解
- 每隔几秒就有新的攻击尝试
- 来自世界各地的僵尸网络
⚡ 系统资源被疯狂消耗
- 每个SSH连接尝试都要消耗CPU和内存
- 网络连接池被占满
- 文件描述符被耗尽
💥 其他服务受到牵连
- 我的网络服务无法获得足够资源
- 新连接被拒绝
- 表现为”服务挂了”
🔄 重启为什么能解决？
- 清除了所有攻击连接
- 释放了被占用的系统资源
- 服务重新获得正常运行环境

原来我的服务没坏，是被攻击”挤”挂了！ 😂

🛡️ 绝地反击：防御策略

既然找到了根本原因，那就要彻底解决这个问题！我们遇到这种攻击可以有多种方案，譬如修改端口，设置防火墙等

🚀 终极武器：fail2ban

经过研究，我选择了 fail2ban 这个神器：

# 安装fail2ban
yum install epel-release -y
yum install fail2ban -y

# 配置严格的防护策略
cat > /etc/fail2ban/jail.local << 'EOF'
[DEFAULT]
# 封禁24小时，让攻击者冷静冷静
bantime = 86400
# 监控10分钟内的行为
findtime = 600
# 最多容忍3次失败
maxretry = 3

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/secure
# SSH更严格：2次失败就封禁
maxretry = 3  
# SSH攻击者封禁7天
bantime = 604800
EOF

# 启动防护
systemctl enable fail2ban
systemctl start fail2ban

📊 效果验证

配置完成后，可以通过以下命令查看防护效果：

# 查看防护状态
fail2ban-client status sshd

# 查看被封的攻击者
fail2ban-client get sshd banned

# 实时监控攻击
tail -f /var/log/fail2ban.log

看着攻击者的IP一个个被加入黑名单，那感觉简直太爽了！ 😎

💡 经验总结

这次故障排查让我学到了很多：

🎯 关键收获

🔍 日志是最好的朋友
- 系统日志包含了所有的线索
- 学会读懂各种日志格式
- 时间线分析很重要
🌐 网络安全不容忽视
- SSH暴力破解攻击无处不在
- 即使不直接攻击目标服务，也可能造成间接影响
- 防护措施要尽早部署
⚡ 资源耗尽的隐蔽性
- 问题表现可能与根本原因相距甚远
- 系统资源竞争会导致意想不到的故障
- 重启能解决很多问题，但不能只满足于此

🛠️ 实用建议

🚨 立即行动: 如果你的服务器还没有部署 fail2ban，赶紧去配置！
📈 监控重要: 定期检查系统日志，及早发现异常
🔐 安全意识: 修改默认SSH端口、禁用root登录等都是好习惯

🎉 结语

虽然这次”故障”让我紧张了一阵子，但最终的排查过程还是很有成就感的 💪

从表面现象到深层原因，再到最终解决方案，整个过程就像解谜游戏一样有趣。

最重要的是：遇到问题不要慌，日志会告诉你一切！ 📚