是否可以创建只允许端口 443 上的合法网络服务器流量而不允许任何其他服务的防火墙？

Question

我总是使用简单的技巧来绕过大多数阻止我使用任何端口的防火墙。我只是在我的一台服务器上的 443 端口上打开了 ssh，然后将所有流量通过隧道传输。

然而，我现在在一个拥有防火墙的网络上，我以前从未见过，我什至不知道这是可能的。

在此网络上，您只能将 443 端口用于合法的网络服务器流量。如果我打开 ssh 或端口 443 上的任何其他内容并尝试从该网络连接到那里，它会立即被杀死。如果我在该服务器上启动 apache，它就可以工作。

这怎么可能？是否有一些超级复杂的防火墙甚至能够分析加密流量以验证它是合法的 https 流量？如何？

Answer 1

是的，他们在这里不需要任何魔法，只需要对 TCP 数据包内容进行微不足道的匹配。尽管 SSH 和 TLS (SSL) 加密了它们的有效载荷，但协议标头本身仍然是可区分的并且彼此非常不同。例如，SSHv2 连接总是从客户端发送SSH-2.0-(client name and version). 同样，即使您的防火墙无法真正知道 TLS 连接内部是否携带 HTTP，但它可以识别TLS 本身。

这种对 TCP 之上的层的检查通常属于“深度数据包检查”，这是一个相对常见的功能。

绕过这一点的一种明显方法是在TLS内建立 SSH 隧道——例如，使用 stunnel、haproxy 或 sniproxy。（除了普通隧道，其中端口 443 专用于 SSH-over-TLS，它们还可以在基于 SNI 和 ALPN 的同一端口上复用 SSH/HTTP/其他协议。）

虽然这并不总是会打败真正复杂的流量分析，但它仍然会绕过大多数过滤器，这些过滤器只检查“这看起来像 TLS 标头”。

然后是烦人的防火墙—​​—拦截 TLS以解密和重新加密所有流量的防火墙。这些实际上可以看到 TLS 内部，并且可以在阻止其他一切的同时传递 HTTP 请求。（请注意，某些防病毒程序也会做同样的事情。）您可以通过查看服务器证书来识别这种类型；所有代理生成的证书看起来都一样，并且通常不会通过验证，而真正的证书是由各种不同的 CA 颁发的。