`127.0.0.1:65535` 是否相当于 `/dev/null` 的网络?
Is `127.0.0.1:65535` the network equivalent of `/dev/null`?
在 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 的文档中,我没有看到阻止请求的直接方法。例如,有 DIRECT
、PROXY
、SOCKS
,但没有 REJECT
或 DENY
。我假设 PROXY 127.0.0.1:65535
是拒绝请求的官方方式。
假设向 127.0.0.1:65535
发送请求会被拒绝是否安全?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
不,这不安全。
它只是本地计算机上最后一个 端口。我完全可以在没有任何特权的情况下打开它并向它发送数据。
他们只是将其用作有效地址,但 不太可能 使用的端口。不是最好的解决方案,但对于示例代码.
可能足够好
没有特殊规定,65535是代理的有效端口。如果您只是 碰巧 到 运行 一个有效的代理,那么该示例将无法阻止。
通常“9”用作"discard service" 的默认端口。 65535 没什么特别的,只是最大可能的端口号。我假设他们使用它是因为他们相信没有人会听这个端口。
但是,这种方法并不安全,因为 1) 任何人都可以编写监听端口 65535 的服务器套接字;和 2) 端口号可能作为临时端口随机分配给客户端。
除了其他答案,丢弃协议(端口 9) 最接近 /dev/null
。引用自Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null
. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
同时通过代理阻止请求 API 不是典型的用法。相反 webRequest API is better suited for blocking requests. There are discussions to change the example.
我认为这解释了为什么 PAC 事实上的标准没有明确支持拒绝请求,以及为什么使用将流量重定向到未使用的端口或域的变通方法。
在 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 的文档中,我没有看到阻止请求的直接方法。例如,有 DIRECT
、PROXY
、SOCKS
,但没有 REJECT
或 DENY
。我假设 PROXY 127.0.0.1:65535
是拒绝请求的官方方式。
假设向 127.0.0.1:65535
发送请求会被拒绝是否安全?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
不,这不安全。
它只是本地计算机上最后一个 端口。我完全可以在没有任何特权的情况下打开它并向它发送数据。
他们只是将其用作有效地址,但 不太可能 使用的端口。不是最好的解决方案,但对于示例代码.
可能足够好没有特殊规定,65535是代理的有效端口。如果您只是 碰巧 到 运行 一个有效的代理,那么该示例将无法阻止。
通常“9”用作"discard service" 的默认端口。 65535 没什么特别的,只是最大可能的端口号。我假设他们使用它是因为他们相信没有人会听这个端口。
但是,这种方法并不安全,因为 1) 任何人都可以编写监听端口 65535 的服务器套接字;和 2) 端口号可能作为临时端口随机分配给客户端。
除了其他答案,丢弃协议(端口 9) 最接近 /dev/null
。引用自Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node
/dev/null
. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
同时通过代理阻止请求 API 不是典型的用法。相反 webRequest API is better suited for blocking requests. There are discussions to change the example.
我认为这解释了为什么 PAC 事实上的标准没有明确支持拒绝请求,以及为什么使用将流量重定向到未使用的端口或域的变通方法。