记录一个关于端口号6666的坑

事情起因

今天想在云服务器上部署一个xxl-job调度中心，以前也使用过，原以为会很轻车熟路，在云服务器上使用了docker进行xxl-job的部署，部署的过程一切都很顺利，直到我想进入xxl-job的后台页面时出现了问题，当我访问http://主机号:6666/xxl-job-admin的时候，不论怎么样 都进入不了后台页面, 一直提示# 无法访问此网站
网址为 http://主机号:6666/xxl-job-admin的网页可能暂时无法连接，或者它已永久性地移动到了新网址。记住这个端口号，后面要考的

排查过程

我一开始以为只是常规的docker 容器没起来，熟练的使用 docker ps查看，

1
2
3
CONTAINER ID   IMAGE                         COMMAND                  CREATED       STATUS       PORTS                                       NAMES
e7331361aa89   xuxueli/xxl-job-admin:2.3.1   "sh -c 'java -jar $J…"   4 hours ago   Up 4 hours   0.0.0.0:6666->6666/tcp, :::6666->6666/tcp   xxl-job-admin

运行的很完美，接下来我查看了下容器的日志 docker logs xxl-job-admin,日志中也没有任何报错，运行的很完美，随即我意识到，可能是云服务器的安全组问题导致的，没开放6666端口，然后我进行了安全组设置，开放了6666端口，这下我以为问题应该能得到解决了，然后我再次进入后台页面，依旧是网页暂时无法连接，这时候我怀疑可能是linux防火墙把这个端口号给挡住了，我 使用 sudo iptables -L -n | grep 6666 查看该端口号是否被防火墙阻挡了，结果防火墙已经把这个端口号放行了，此时此刻我已经感觉有点不对劲了，我怀疑是不是我的nginx 映射我的域名的时候 没把该端口号映射上去导致请求打不到正确的后台地址上，然后我修改了我nginx的配置，结果依旧是无法访问。这个时候我在本地使用了个执行器尝试链接云服务器上的后台地址，这个时候神奇的事情发生了，这个执行器正常且完美的注册到了相应的地址里，此时此刻我更懵逼了，服务是正常运行的，并且可以正常注册执行器，但是为什么就是访问不了后台地址呢？此时我决定使用最愚蠢的办法，我把xxl-job的代码从github上拉了下来，本地跑一下xxl-job的demo，我一开始使用原有的配置，端口号8080进行启动，一切正常，能进入后台页面。随即我修改配置，复现我在云服务器上的配置，我将后台地址端口号改为了6666，此时我在本地重启，发现后台地址没法进去了，这个时候我以为是xxl-job难道不能更换后台端口号么？此时我更换了一个别的端口号，我使用了9090端口号。正常运行了后台页面，此时我意识到 6666这个端口号应该才是问题的根源

答案

随机我进行了搜索为什么6666端口号没法正常进入，然后我得到了答案。
原来谷歌对于一些端口号进行了限制，导致不能正常访问
附上 Google Chrome 默认非安全端口列表，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
1,    // tcpmux
7,    // echo
9,    // discard
11,   // systat
13,   // daytime
15,   // netstat
17,   // qotd
19,   // chargen
20,   // ftp data
21,   // ftp access
22,   // ssh
23,   // telnet
25,   // smtp
37,   // time
42,   // name
43,   // nicname
53,   // domain
77,   // priv-rjs
79,   // finger
87,   // ttylink
95,   // supdup
101,  // hostriame
102,  // iso-tsap
103,  // gppitnp
104,  // acr-nema
109,  // pop2
110,  // pop3
111,  // sunrpc
113,  // auth
115,  // sftp
117,  // uucp-path
119,  // nntp
123,  // NTP
135,  // loc-srv /epmap
139,  // netbios
143,  // imap2
179,  // BGP
389,  // ldap
465,  // smtp+ssl
512,  // print / exec
513,  // login
514,  // shell
515,  // printer
526,  // tempo
530,  // courier
531,  // chat
532,  // netnews
540,  // uucp
556,  // remotefs
563,  // nntp+ssl
587,  // stmp?
601,  // ??
636,  // ldap+ssl
993,  // ldap+ssl
995,  // pop3+ssl
2049, // nfs
3659, // apple-sasl / PasswordServer
4045, // lockd
6000, // X11
6665, // Alternate IRC [Apple addition]
6666, // Alternate IRC [Apple addition]
6667, // Standard IRC [Apple addition]
6668, // Alternate IRC [Apple addition]
6669, // Alternate IRC [Apple addition]

为什么Google认为这些端口不安全呢?

我带着这个疑问去寻找了下答案，在 一篇国外的博客我找到了下面的答案

James 关于 Scala 和 All That Jazz 的博客

为什么 Chrome 认为某些端口不安全？

今天在我的 Twitter 提要中，我注意到 Dan North 的一条沮丧的推文，抱怨为什么 Chrome 似乎任意阻止了与某些端口的连接，并给出了令人困惑的错误代码“net：：ERR_UNSAFE_PORT”。我以前遇到过这种情况，也同样感到沮丧，所以我决定做一些研究，弄清楚谷歌所说的不安全是什么意思。在堆栈溢出和论坛中有一些关于哪些端口被阻止的讨论，但我没有找到太多关于为什么它们被认为是不安全的。

我的第一个假设是，不知何故，Chrome 本身连接到这些端口上的服务是不安全的，因为也许服务协议可能会混淆 Chrome 做错事。然而，这没有意义，然后我发现这不是为了保护 Chrome，而是为了保护在这些端口上运行的服务本身。许多互联网协议被设计为对他们接受的内容非常宽松，这为攻击者提供了一个有趣的攻击机会。

正如具有安全意识的 Web 开发人员所熟知的那样，在代表您在服务器上发出请求时，浏览器对攻击者非常有义务。XSRF 就是一个很好的例子，但好消息是，我们知道如何防范 XSRF。但是，如果攻击者诱骗 Web 浏览器连接到不说 HTTP 的内容怎么办？让我们以 SMTP 服务器为例。如果您以前从未见过SMTP会话，以下是我从维基百科中摘录的示例会话：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: DATA
S: 354 End data with .
C: From: "Bob Example" 
C: To: "Alice Example" 
C: Cc: theboss@example.com
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye

乍一看，这可能看起来不像 HTTP。除了一个重要功能（如 HTTP）外，SMTP 使用换行符分隔其协议的元素。此外，当我们将数据发送到它不理解的SMTP服务器时会发生什么？下面是一个简单的HTTP GET请求，其中包含一个示例SMTP服务器：

1
2
3
4
5
6
7

C: GET / HTTP/1.1
S: 500 5.5.1 Command unrecognized: "GET / HTTP/1.1"
C: Host: www.example.com
S: 500 5.5.1 Command unrecognized: "Host: www.example.com"
C: 
S: 500 5.5.1 Command unrecognized: ""

所以，显然我们的邮件服务器很困惑，但这里需要注意的重要一点是，它并没有完全拒绝我们的连接，而是告诉客户端存在错误，但继续接受命令。那么我们能利用这一点吗？答案是肯定的。如果我，一个攻击者，要制作一个包含表单的页面，该表单会自动提交（使用调用提交方法的 javascript 加载事件 - 类似于基于表单的 XSRF 攻击）到 SMTP 服务器，该怎么办？为了与此服务器进行SMTP通信，我需要能够在邮件中包含新行。使用 application/x-www-form-urlencoded 这是不可能的，因为换行符是 URL 编码的，但是使用 multipart/form-data，我可以创建一个字段，其中包含上述 SMTP 会话中的客户端消息，因此使用我的受害者 Web 浏览器，我可以将电子邮件提交到目标 SMTP 服务器。如上例所示，SMTP 服务器将忽略所有 HTTP 协议，包括方法和标头，以及 multipart/form-data 标头内容，但是一旦它获得了我的字段，其中包含我的 HELO、MAIL FROM、RCPT TO 等命令，它将开始处理它们。

但是，当然，攻击者可以直接连接到SMTP服务器，对吧？对于某些 SMTP 服务器，可以。但是，许多 SMTP 服务器仅受防火墙保护，特别是如果 SMTP 服务器配置为将其用作验证电子邮件来源真实性的安全机制，则攻击者可能希望能够通过此类 SMTP 服务器发送电子邮件。因此，这意味着攻击者可以使用在防火墙后面运行的浏览器来保护 SMTP 服务器作为连接到该 SMTP 服务器的代理，从而使用它发送邮件。

事实证明，一些SMTP服务器实际上会检测到对它们发出的HTTP请求并立即关闭连接（我的服务器SMTP服务器在我尝试使用时会这样做）。但是，并非所有 SMTP 服务器都这样做，因为没有设想客户端服务器（如 Web 浏览器）可以用作受保护网络的开放代理。假设其他类型的服务/服务器，如FTP服务器，甚至IRC服务器，也会这样做，这当然不是一个好主意。

那么，为什么Chrome拒绝连接到某些端口呢？因为 Google 工程师已经浏览了众所周知的端口列表，并计算出使用这些端口的协议对发送 HTTP 请求的容忍度，如果它们是容忍的，他们将其标记为不安全并阻止它，以防止 Google Chrome 成为安全网络的开放代理。所有网络浏览器都应该这样做吗？可能。

有兴趣的可以点进去看一下原文
主要是还是因为一些安全原因，比如防止黑客，例如smtp(25/465/587)端口，即便这些smtp服务被防火墙保护，但黑客也能通过smtp背后的浏览器，对服务端发送一封脚本邮件进行攻击

然后我也找到了，如果非要使用上述这些端口的话，可以按照这篇博客进行配置：
https://www.applenice.net/2019/06/04/ERR-UNSAFE-PORT-On-Browser/

这边把该博主的博客也给记录一下 方便下次查看

HTTP Server

临时需要一个Web Server给内网其他机器共享文件使用，那么最简单的就是使用Python了，只需要一行命令:

1
2
3
4
$ cd share  
$ python2 -m SimpleHTTPServer 8080  
或  
$ python3 -m http.server 8080

那么share目录下的文件就可以共享给其他人下载使用了。

问题

由于8000、8080等端口已有其他服务占用，就使用了6666端口，但是…当在浏览器中访问http://192.168.1.2:6666时，Chrome提示:

1
2
网址为 http://192.168.1.2:6666/ 的网页可能暂时无法连接，或者它已永久性地移动到了新网址。  
ERR_UNSAFE_PORT

用Firefox访问时提示:

此网址使用了一个通常用于网络浏览以外目的的端口。出于安全原因，Firefox 取消了该请求。

好的，我先换个其他端口用。

填坑

那么，当使用6666端口的时候发生了什么，查了一下ERR_UNSAFE_PORT，出现该问题的原因主要是因为6666-6669这几个端口是IRC协议使用的缺省端口，存在很大的安全风险，出于安全考虑，Chrome、Firefox都禁止了对6666端口的访问。

那么如果一定要使用6666端口呢?

我使用的系统是Windows 10，使用Chrome版本为74.0.3729.169，方法如下:

1
Google Chrome的图标->右键->属性->目标

在目标值后面追加:

1
--explicitly-allowed-ports=6666

如果有多个值的话，用逗号隔开即可，关闭浏览器，重启启动，此时访问http://192.168.1.2:6666/ 就可以下载相应的文件了。

使用Firefox的话，可以通过如下方式解决:
在Firefox地址栏输入about:config，右键->新建一个字符串键network.security.ports.banned.override，值的内容填端口号6666，需要放行多个端口的话使用逗号隔开。

出于安全考虑，还是应该更换端口，不可能其他机器都如此设置，增大安全风险。

另外，Chrome认为有风险进行阻断的端口在Chromium源码中已经列出，使用时要注意规避:
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/net/base/port_util.cc

参考:

https://superuser.com/questions/188006/how-to-fix-err-unsafe-port-error-on-chrome-when-browsing-to-unsafe-ports

https://superuser.com/questions/188058/which-ports-are-considered-unsafe-by-chrome

个人学习
记录踩过的坑

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！