☰

将服务绑定到本地主机并使用 SSH 隧道 - 请求可以被伪造吗？

tag-icon • tag-icon iptables localhost ssh-tunnel interface
将服务绑定到本地主机并使用 SSH 隧道 - 请求可以被伪造吗？

给定一个典型的 Web 服务器，其中包含 Apache2、常见的 PHP 脚本和 DNS 服务器，从安全角度来看，将 phpmyadmin 等管理界面绑定到本地主机并通过 SSH 隧道访问它是否足够？

或者有人知道 phpmyadmin（或任何其他常用脚本）正在监听本地主机的某个端口，是否可以轻松伪造在没有其他身份验证的情况下执行的请求？

  1. 换句话说：互联网上某个地方的某个人是否可以轻松伪造一个请求，以便 Web 服务器能够接受该请求，并认为该请求来自 127.0.0.1（如果服务器仅在 127.0.0.1 上监听）？
  2. 如果存在风险，是否可以在比应用程序更低的级别上以某种方式处理，例如通过使用iptables？这个想法是，如果有人发现 php 脚本或 apache 中的弱点，网络仍然会阻止此请求，因为它不是通过 SSH 隧道到达的？

答案1

... 互联网上某个地方的某个人是否可以轻松地伪造一个请求，以便 Web 服务器能够接受它，并且如果服务器仅在 127.0.0.1 上监听，则认为它源自 127.0.0.1？

这是有可能的，但是极其不太可能。请这样想：当某个进程正在侦听绑定到 127.0.0.1 的端口时，只有当数据包的目标地址为 127.0.0.1 时，传入的 IP 数据包才会到达该进程。除非攻击者破坏了他自己和您的服务器之间的每个路由器，否则这样的数据包绝对不可能路由到您的服务器，因为 127.0.0.1 通常不是可路由的地址。

但假设发生了意想不到的事情，一个发往 127.0.0.1 的伪造数据包到达了您的服务器。在这种情况下，数据包必须通过非环回接口 ( lo) 的网络接口到达。按照惯例，所有发往 127.0.0.0/8 的合法数据包都必须通过该lo接口到达，因此，使用一条简单规则即可轻松识别和阻止发往 127.0.0.0/8 的伪造数据包iptables：

-A INPUT -d 127.0.0.0/8 ! -i lo -j DROP

答案2

如果您将进程的绑定地址更改为 127.0.0.1，这应该足以阻止任何其他机器的远程访问。如果您尝试连接，您将得到连接被拒绝。这将看起来（从远程机器的角度来看）就像进程已停止并且端口已关闭一样。

为了增加安全性，您可以添加 iptables 规则来阻止远程地址的这些端口。这将防止您通过更改配置（错误或升级后）意外启用远程访问。

相关内容