SSH隧道实战：direct-tcp请求攻击链
背景与实验环境
作为SANS学位课程的一部分，我通过AWS免费层EC2实例在日本部署了Cowrie SSH/Telnet蜜罐，用于模拟脆弱服务器并记录暴力破解和攻击者交互行为。同时基于ISC导师Guy Bruneau的GitHub指南[1]，在独立VPS上搭建ELK SIEM平台集中分析日志。
关键发现：direct-tcp请求异常
蜜罐运行一个月内捕获到1000+不同IP发起的direct-tcp连接请求，其中75%以上指向单一目标IP 77.88.21.158:25。日志显示请求源地址为127.0.0.1（本地回环），但Kibana中实际源IP为外部地址（例如125.20.251.66）。
技术深度分析
流量伪装机制
- 端口映射证据：图1显示源端口32069（红框标注）与PCAP抓包中的SSH初始连接端口42948（蓝框标注）对应
- SSH指纹特征：攻击流量携带SSH-2.0-OpenSSH_7.4标识（绿框标注）
- 隧道建立时序：获得有效SSH凭据后，隧道通常在1秒内完成建立
攻击者行为模式
- 初始侦察：专注攻击端口2222，采用间隔2小时的低频暴力破解
- 系统特征：TTL值小于50（初始可能为64），指向Linux/MAX OSX系统[3]
- 客户端指纹：SSH哈希指纹为acaa53e0a7d7ac7d1255103f37901306
代理链目的地解析
目标IP 77.88.21.158:25经核实为俄罗斯Yandex邮件SMTP服务器[4]，是多国常见封锁对象。攻击者通过将邮件客户端代理设置为127.0.0.1:1080，使流量经SSH隧道绕道访问。
潜在危害
- 恶意流量归因：服务器可能被用于黑客攻击、欺诈或DDoS，导致责任转嫁
- 带宽滥用：代理流量消耗资源，可能触发云服务商限流或产生额外费用
- IP黑名单风险：服务器IP可能被防火墙封禁，影响正常业务
防御启示
- 强化SSH密码策略，防范暴力破解
- 监控非常规端口（如2222）的连接行为
- 部署网络流量分析工具识别隧道流量
参考文献
[1] https://github.com/bruneaug/DShield-SIEM
[2] https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/
[3] https://www.imperva.com/learn/performance/time-to-live-ttl/
[4] https://search.censys.io/hosts/77.88.21.158
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/