我总是使用简单的技巧来绕过大多数阻止我使用任何端口的防火墙。我只需在我的其中一台服务器上的端口 443 上打开 ssh,然后通过该端口传输所有流量。
然而,我现在所处的网络有以前从未见过的防火墙,我甚至不知道这是可能的。
在这个网络上,您只能将 443 端口用于合法的 Web 服务器流量。如果我打开 ssh 或端口 443 上的任何其他东西并尝试从这个网络连接到那里,它会立即被终止。如果我在该服务器上启动 apache,它就可以正常工作。
这怎么可能?是否有一些超级复杂的防火墙甚至能够分析加密流量以验证其是否是合法的 https 流量?如何做到的?
答案1
是的,他们不需要任何魔法,只需要对 TCP 数据包内容进行简单的匹配。尽管 SSH 和 TLS (SSL) 加密了他们的有效载荷,协议标头他们自己仍然可以区分,并且彼此之间有很大不同。例如,SSHv2 连接始终以客户端发送 开始SSH-2.0-(client name and version)
。同样,即使您的防火墙无法真的知道 TLS 连接是否带有 HTTP,它可以识别TLS 本身。
这种对 TCP 以上层的检查通常属于“深度数据包检测”,这是一种相对常见的功能。
绕过这个问题的一个明显方法是使用 SSH 隧道里面TLS – 例如,使用 stunnel、haproxy 或 sniproxy。(除了普通隧道(其中端口 443 专用于 SSH-over-TLS)之外,它们还可以基于 SNI 和 ALPN 在同一端口上多路复用 SSH / HTTP / 其他协议。)
虽然这并不总能打败真正复杂的流量分析,但它仍然可以绕过大多数仅检查“这看起来像 TLS 标头吗”的过滤器。
还有一种令人讨厌的防火墙——拦截 TLS解密并重新加密所有流量。这些可以真正看到 TLS 内部,并且可以传递 HTTP 请求,同时阻止其他所有内容。 (请注意,某些防病毒程序也会执行相同的操作。)您可以通过查看服务器证书来识别这种证书;所有代理生成的证书看起来都一样,并且通常无法通过验证,而真正的证书是由各种不同的 CA 颁发的。