【问题标题】:Is `127.0.0.1:65535` the network equivalent of `/dev/null`?`127.0.0.1:65535` 是 `/dev/null` 的网络等价物吗?
【发布时间】:2018-01-25 16:34:37
【问题描述】:

在 MDN 的 proxy example 中,我看到他们使用 127.0.0.1:65535 作为无效 url (link to the source):

const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
  if (blockedHosts.indexOf(host) != -1) {
    browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
    return deny;
  }
  return allow;
}

65535 端口有什么特别之处吗?假设没有进程会监听该端口是否安全?

Proxy Auto-Configuration (PAC) files 的文档中,我没有看到阻止请求的直接方法。例如,有DIRECTPROXYSOCKS,但没有REJECTDENY。我认为PROXY 127.0.0.1:65535 是拒绝请求的官方方式。

是否可以假设向127.0.0.1:65535 发送请求会拒绝它们?

【问题讨论】:

    标签: firefox proxy network-programming firefox-addon-webextensions pac


    【解决方案1】:

    可以假设向 127.0.0.1:65535 发送请求会拒绝它们吗?

    不,这不安全。

    这只是本地机器上的最后一个端口。我完全能够在没有任何特殊权限的情况下打开它并向它发送数据。

    他们只是将其用作有效地址,但不太可能使用端口。不是最好的解决方案,但可能对于示例代码来说已经足够了

    没有特殊规定,65535 是代理的有效端口。如果您只是碰巧在那里运行了一个有效的代理,该示例将无法阻止。

    【讨论】:

    • 是的,我在 Chrome API 中看到了一个类似的例子,他们将所有请求重定向到“黑洞”。尽管如此,令我惊讶的是,没有直接的方式来表达你的意图。当您对示例代码说足够好时,您是否知道是否有办法使其更健壮(对于生产代码)?
    • proxy API 可能不是选择性地阻止请求的正确位置。 webRequest API 是适合它的工具。
    • 啊,我认为你是对的。是的,我记得甚至有一个相关的拉取请求,它认为阻塞请求是一种非典型用法(github.com/mdn/webextensions-examples/pull/232)。
    【解决方案2】:

    通常“9”用作“丢弃服务”的默认端口。 65535 没什么特别的,只是可能的最大端口号。我认为他们使用它是因为他们相信没有人会监听该端口。

    但是,这种方法并不安全,因为 1) 任何人都可以编写一个服务器套接字来监听端口 65535; 2) 端口号可能作为临时端口随机分配给客户端。

    【讨论】:

      【解决方案3】:

      除了其他答案之外,丢弃协议(端口 9) 最接近于 /dev/null。引用Wikipedia article

      丢弃协议是 Unix 文件系统节点 /dev/null 的 TCP/UDP 等价物。这样的服务保证接收发送给它的内容,并可用于调试需要保证接收发送的有效负载的 TCP 和/或 UDP 代码。

      在各种路由器上,此 TCP 或 UDP 端口 9 用于丢弃协议(或端口 7 用于中继 ICMP 数据报的 Echo 协议)也默认用作代理来中继来自 LAN 唤醒 (WOL) 魔术数据包Internet 到本地网络上的主机,以便远程唤醒它们(这些主机还必须将其网络适配器配置为接受 WOL 数据报,并且路由器必须启用此代理设置,并且还可能在其嵌入式中配置转发规则防火墙以在 Internet 端打开这些端口)。

      通过代理 API 阻止请求也不是典型用法。相反,webRequest API 更适合阻塞请求。有讨论到change the example

      我认为这可以解释为什么 PAC 事实标准中没有明确支持拒绝请求,以及为什么使用将流量重定向到未使用的端口或域的变通方法。

      【讨论】:

      • 请注意,rejecting 连接(正如示例似乎依赖的那样)和 静默接受任何输入(即,事实上,/dev/null 等价的)。它可能会从 Chrome 中引发不同的响应/错误,尽管它当然会有效地阻止它。
      猜你喜欢
      • 2011-07-19
      • 2021-04-09
      • 2011-01-03
      • 1970-01-01
      • 2011-03-01
      • 2014-06-24
      • 1970-01-01
      • 1970-01-01
      • 2012-06-02
      相关资源
      最近更新 更多