1. 项目背景与问题发现
那天凌晨2点37分，我正喝着第三杯咖啡检查线上服务监控，突然发现某台边缘服务器的CPU使用率曲线出现异常波动。这种非业务高峰期的资源消耗激增，往往意味着两种可能：要么是代码发布出了问题，要么就是有人正在"拜访"我们的服务器。
登录机器后，我习惯性地先扫了一眼/var/log/auth.log，果然发现了大量异常登录尝试记录。这些记录呈现出明显的自动化攻击特征：连续数百次使用不同用户名尝试SSH登录，IP地址遍布全球各地。更让人警觉的是，部分尝试已经使用了我们内部员工的常见用户名组合。
提示：养成定期检查auth.log的习惯，建议至少每周一次。对于暴露在公网的服务器，这个频率应该提高到每天。
2. 攻击特征深度分析
2.1 日志特征提取
通过以下命令快速统计异常登录尝试：
bash复制grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr
分析结果显示，攻击者主要采用三种策略：
- 字典攻击：使用admin/root/administrator等默认账户名
- 组合攻击：尝试公司名+常见后缀（如company_dev, company_admin）
- 爆破攻击：对特定账号连续尝试弱密码（如123456, password@123）
2.2 攻击时间模式
提取时间戳分析发现，攻击存在明显的时间规律：
- 每日UTC时间8:00-11:00为高峰期（对应亚洲时区的工作时间）
- 周末攻击频次下降约40%
- 每次攻击持续时间约15-30分钟
这种模式表明攻击者很可能使用了自动化工具，但保留了人工介入的可能性。
3. 应急响应措施
3.1 即时阻断
首先使用fail2ban进行临时封禁：
bash复制fail2ban-client set sshd banip <攻击IP>
同时更新iptables规则，限制单个IP的连接速率：
bash复制iptables -A INPUT -p tcp --dport 22 -m connlimit --connlimit-above 3 -j DROP
3.2 敏感信息排查
重点检查以下位置是否存在信息泄露：
bash复制# 检查历史命令记录
cat ~/.bash_history
# 检查crontab异常任务
crontab -l
# 检查最近修改的文件
find / -type f -mtime -7 -print
4. 系统加固方案
4.1 SSH安全增强
修改/etc/ssh/sshd_config关键配置：
code复制Port 2222 # 修改默认端口
PermitRootLogin no
PasswordAuthentication no # 强制使用密钥登录
MaxAuthTries 3
ClientAliveInterval 300
4.2 防火墙策略优化
使用UFW配置精细化规则：
bash复制ufw allow 2222/tcp
ufw limit 2222/tcp # 限制连接速率
ufw enable
4.3 监控体系升级
部署OSSEC实现实时告警：
bash复制apt install ossec-hids-server
# 配置邮件告警规则
5. 深度防御措施
5.1 双因素认证部署
安装Google Authenticator模块：
bash复制apt install libpam-google-authenticator
修改PAM配置：
code复制auth required pam_google_authenticator.so
5.2 日志分析自动化
使用Logwatch+自定义规则实现每日安全报告：
bash复制apt install logwatch
vim /usr/share/logwatch/default.conf/logwatch.conf
5.3 蜜罐系统部署
在边缘网络部署Cowrie蜜罐：
bash复制docker run -p 2222:2222 cowrie/cowrie
6. 后续监控与改进
建立安全事件响应SOP：
- 每日检查关键日志摘要
- 每周分析攻击模式变化
- 每月进行安全配置审计
- 每季度模拟渗透测试
配置Prometheus监控关键指标：
- 异常登录尝试次数
- 敏感文件修改记录
- 特权命令执行情况
7. 经验总结与避坑指南
在实际操作中，有几个容易忽视的关键点：
- 密钥管理方面：
- 禁止将私钥存储在服务器上
- 使用ssh-agent管理密钥链
- 定期轮换密钥对（建议每90天）
- 日志管理常见问题：
- /var/log分区空间不足导致日志丢失
- 未配置logrotate导致日志文件过大
- 敏感信息明文记录（如密码参数）
- 性能与安全的平衡：
- 加密算法选择：优先选择chacha20-poly1305而非AES-256-CBC
- 会话保持时间不宜过长（建议300-600秒）
- 连接限制要考虑业务实际并发量
这次事件给我们的最大启示是：安全防护不是一次性工作，而是一个持续的过程。攻击者的技术在与时俱进，我们的防御体系也需要不断演进。现在我们的服务器已经实现了从"被动防御"到"主动监测"的转变，下一步计划引入基于行为的异常检测机制。