SSH Tunneling in Action: direct-tcp requests [Guest Diary]

[本文为Sihui Neo的客座日记，其为SANS.edu BACS项目的ISC实习生]

作为SANS学位课程的一部分，我有机会设置一个蜜罐来模拟易受攻击的服务器并监控日志活动。我使用AWS免费层EC2实例在日本设置了蜜罐传感器，并部署了Cowrie——一个SSH和Telnet蜜罐，旨在记录攻击者执行的暴力攻击和shell交互。

除了传感器设置外，为了便于在单一平台查看所有日志，我购买了一个单独的虚拟私有服务器，并按照ISC导师Guy Bruneau的GitHub页面[1]的安装说明安装了ELK SIEM。然后设置传感器将所有日志发送到SIEM服务器。

自蜜罐设置以来，日志中一个有趣的观察是direct-tcp连接请求。在一个月内，超过1000个不同IP发出了这些请求，其中超过75%指向单个目标IP。本文将介绍这些连接如何及为何建立，以及目标IP指向何处。

日志是什么样的？

在蜜罐日志中看到的direct-tcp连接请求示例

上述原始事件字段中的示例日志显示请求源自127.0.0.1（本地环回接口），但在Kibana中查看source.ip时，实际源IP是不同的外部地址。

125.20.251.66是实际源IP 使用源IP 125.20.251.66，我查看了direct-tcp连接之前的流量和PCAP流量。

图1. direct-tcp连接请求时来自125.20.251.66的日志，红框中显示源端口32069 在图1中，我提取了Kibana中看到的来自源IP 125.20.251.66的流量日志。红框高亮显示行“direct-tcp connection request to 77.88.21.158:25 from 127.0.0.1:32069”，但源地址显示为125.20.251.66，而源端口匹配32069。

PCAP中还有额外证据。下面的整个流显示使用源端口42948的连接，这确实是初始SSH连接的源端口，如图1蓝框高亮所示，最后一列可见源IP。

图2. 来自125.20.251.66流量的PCAP和TCP流 最后，SSH横幅SSH-2.0-OpenSSH_7.4在图1绿框高亮以及图2底部的TCP流中可见。所有这些表明流量正在被转发或代理以帮助隐藏真实源IP。

那么它是如何工作的？

侦察和初始访问

如前所述，攻击者必须发起连接到蜜罐服务器以创建SSH隧道，为此他们需要有效的SSH登录凭据。这通常通过暴力破解实现。当查看有direct-tcp连接请求的IP的初始活动时，它们具有相似的模式：

• 仅尝试连接到端口2222
• 节流的暴力破解尝试，意味着如果失败，同一IP的暴力破解尝试至少间隔2小时
• TTL小于50，意味着起始TTL可能为64，这可能指示Linux/MAX OSX系统[3]
• SSH客户端哈希指纹：acaa53e0a7d7ac7d1255103f37901306

成功获取有效SSH凭据后，SSH隧道通常会在第二秒内设置。

去向何方？

如前所述，蜜罐中看到超过1000个IP进行了这些代理连接，有趣的是，大多数（超过75%）被看到代理到目标IP 77.88.21.158的端口25。

基于俄罗斯的77.88.21.158端口25似乎是Yandex邮件的smtp服务器[4]，这是许多国家常见被封锁的位置。

参考前面显示的SSH隧道图，这可能意味着客户端将其电子邮件客户端设置为使用‘127.0.0.1:1080’作为代理，指示电子邮件流量通过建立的SSH隧道到达77.88.21.158。

由于蜜罐服务器在端口2222上没有真正的SSH服务，隧道设置后连接很快关闭，PCAP日志未捕获到目标IP的出站流量。

最坏的情况可能是什么？

Direct-tcp连接通常是一种代理连接形式，在这种情况下使用蜜罐服务器作为中介，以掩盖源IP或绕过流量规则。攻击者使用受感染服务器而不是付费或免费VPN的原因是归因和/或可能的一致性。商业VPN需要注册，而点对点网络等服务通常不允许用户选择路由或跳数。

建立SSH隧道不需要root权限，只要您有有效用户凭据登录SSH服务器（本例中为蜜罐），就可以轻松设置。事实上，由于密码泄露、密码重用和默认密码，暴力破解是获得对易受攻击服务器访问的更常见和简单策略之一。

一旦您的服务器被入侵并成功用作代理，您的服务器可能容易受到：

• 恶意流量归因：攻击者可以通过您的服务器路由非法活动（黑客攻击、欺诈、DDoS），使您显得负责。
• 带宽过度使用：代理流量消耗资源，可能导致您的主机/ISP节流，尤其是在云中产生额外成本。
• IP黑名单：您的服务器IP可能最终出现在防火墙黑名单上，阻止您的日常活动。

[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/

为开发设置您自己的证书权威：为何及如何

有多个原因可以设置内部证书权威。有些配置用于支持强认证方案，有些用于额外的灵活性和便利性。我将涵盖第二部分。特别是，对于开发人员来说，拥有内部证书权威以出于开发目的颁发证书可能会有帮助。用于开发和内部测试的网站通常仅由少数个人使用，并且通常仅通过内部网络或VPN访问。通常，这些站点甚至不使用TLS。但有几个原因应考虑在所有站点（包括内部开发站点）上运行TLS：

• 浏览器偏好：浏览器日益“强制”TLS。运行没有TLS的站点可能不方便。特别是，如果您使用严格传输安全等功能，为开发站点（特别是API）设置例外可能很混乱。
• 配置一致性：保持开发环境尽可能接近“真实事物”是最好的。您做的更改越少，某些东西崩溃的可能性就越小。一些高级JavaScript功能（例如，地理定位）甚至可能没有TLS就无法工作。
• 安全性：即使在更隔离的开发环境中，TLS仍然为开发人员提供重要保障，不暴露自己于额外风险。即使您仅管理使用测试数据，攻击者仍可能使用不安全的开发站点注入代码以渗透到开发人员的机器中。

明显、简单的解决方案是仅使用像Let’s Encrypt这样的免费服务来请求开发人员证书。但有几个原因您可能不想这样做：

• 证书请求认证：开发站点不应公开暴露，且网站的简单HTTP认证可能不起作用。或者，您可以使用基于DNS的认证方案，但这需要提供开发人员修改DNS设置的访问权限。这可以安全完成，但需要大量工作才能正确完成。不要忘记Let’s Encrypt还实施速率限制，如果您请求太多证书，可能会超出。
• 证书透明度：公共证书权威必须在其颁发的所有证书透明度日志中发布。如果您使用公共证书权威请求证书，攻击者可以使用它们轻松发现开发系统。
• 灵活性：您的内部证书权威不必遵守公共证书权威必须遵守的相同规则。您的证书可以有效期更长（或更短），它们可以使用内部域名甚至IP地址。这对开发站点有用。

下一步是“如何”。如何设置一个易于使用的证书权威？OpenSSL记录了困难的方式。您创建一个证书权威，接下来使用各种脚本创建单个证书。这有效，但很快变得过时。有一种更好的方式设置支持“ACME”协议颁发证书的证书权威。这更易于集中管理，并且您将对颁发的证书有更多可见性。

最简单和最便宜的开始方式是Smallstep提供的开源解决方案。如果您喜欢支持和额外集成功能，Smallstep还提供几种商业解决方案。作为附加“奖励”，它也可用于管理SSH证书。

Smallstep的说明很好。我遇到的一个问题是，在设置Smallstep作为守护进程运行之前，您需要初始化您的CA。因此按此顺序遵循说明：

• 安装：https://smallstep.com/docs/step-ca/installation/（我在Proxmox上的最小尺寸容器中使用Ubuntu 24.04）
• 如果尚未安装，安装jq。
• 初始化：https://smallstep.com/docs/step-ca/getting-started/
• 作为守护进程运行：https://smallstep.com/docs/step-ca/certificate-authority-server-production/index.html#running-step-ca-as-a-daemon

一旦全部设置完成，您需要做的就是： 1 - 将新证书权威添加为浏览器（和/或操作系统）中的受信任CA 2 - 第一次使用“certbot”请求证书时，添加以下参数：–server https://yourinternalca/acme/acme/directory

您应该能够使用各种验证方案与smallstep。请确保运行smallstep的服务器可以解析您可能使用的任何主机名，但将它们添加到主机文件将起作用。

请注意，您手动添加的CA不必遵守与公共证书权威相同的规则。证书可能有效期更长；您可以为IP地址颁发证书，并且不需要配置撤销或证书透明度。