适应国内网络环境和加速docker构建

[LeeHDsniper]

1. 在Dockerfile中加入更换linux源为USTC源，加速apt-get
2. 优化gitlab Dockerfile中从ppa下载nginx、git等特定软件包速度太慢问题，将所需deb包打包发布到码云，加速下载并从本地安装
3. 修改pip源为豆瓣源
4. 修改ruby gem和bundler源为https://gems.ruby-china.org/源，加速下载
5. 修改php composer源为https://pkg.phpcomposer.com/
6. 将一些下载速度较慢的软件包发布到码云，修改了下载链接，码云地址https://gitee.com/leehdsniper/vulhub-package
7. 由于各类原因，仅在 elasticsearch 所有环境的Dockerfile中加入了软件包签名验证，所有签名从 elasticsearch官网获取，其他软件包需自行验证签名

[phith0n]

因为vulhub是一个长期的工作，而且随着环境的增加，维护的难度会越来越大。

所以vulhub当初立项的时候，考虑的几个要素是：

1. 稳定。几乎所有的环境，都使用官方源、官网、官方github项目等作为软件的下载、升级方式。
2. 开放。几乎所有基础环境，都基于hub.docker.com，然后利用放在base目录下的Dockerfile源码来编译得到。不使用第三方镜像，不使用docker commit。

最理想的状态是，即使10年以后，我们仍然能由vulhub的源码，得到所有漏洞环境。所以，我不赞成使用第三方源。

当然，国内下载速度太慢这个问题仍然困扰部分用户。我们现在的解决方案是：

1. 将软件编译、安装的部分，放在base目录下，然后编译为基础镜像，放在dockerhub中。只要dockerhub官方不倒闭或不封号，以后就不用再重新编译这个软件。
2. 漏洞环境尽量不再执行编译操作，而是在基础镜像的基础上，通过配置文件、命令参数等方式来构造漏洞环境。

这样，使用vulhub的用户，只需要用国内的dockerhub镜像（如daocloud加速器），即可快速运行漏洞环境。

当然，现在还有不少漏洞环境仍然包含编译的过程，我们需要慢慢进行优化。

[phith0n]

我觉得这个PR很好，我可以借着这个机会来说一下我的一些想法。

当初做vulhub的初衷之一，是为了解决安全从业人员一个痛点：历史漏洞的复现和学习。

举个简单例子，心脏滴血是一个非常经典的漏洞。在漏洞初次出现的时候，大家只需要使用手头上已经有的Apache等web服务器，即可复现该漏洞。

但在4年后的今天，我们手上的大部分主机都已经不再存在这个漏洞，我们要学习这个漏洞，必然需要去找老旧的机器或者从源码开始编译openssl。这些工作对于现在的安全从业者来说成本是很高的。

可以预见，随着时间的推移，这些老漏洞越来越难以复现。vulhub将这些环境的编译方法写在Dockerfile里，并将编译好的环境放在dockerhub里，都是定格时间的一种方法。

所以为了vulhub能使用10年及更久，我考虑的重要因素是上面说到的“稳定”和”开放“，而”速度“这个只能作为次要因素考虑。希望大家能够理解~

[LeeHDsniper]

一点微小的工作引来P神这么认真的回复很感动了，事实上我做这些事去年就开始在做，因为平时工作涉及一部分培训工作，于是去年将所有环境部署测试了一遍，准备后面用作个人学习和工作。当然搭环境的时候也踩了许多坑，当时由于各种原因有没有做详细记录，借着最近有时间做一下。

关于P神说的“稳定”、“开放”两个点我在搭建的时候也思考了一下，除了ustc的源应该还比较靠谱之外，其他的第三方的源确实存在10年之后无法使用的问题，不过10年之后我觉得存储和带宽都已经不会存在现在这么多限制，我们将所有环境直接发布一个镜像就好了哈哈。

去年比较闲的时候和同事一起做了一个类似vulhub-manager那个项目的应用，在参考vulhub-manager的时候发现没有实现以某个环境为对象的管理等一系列功能，我想应该是受限于docker-compose太方便了，以至于实现pydocker的管理显得有点麻烦，但是我们当时想的是要作为培训或者练习靶场使用，必然要设计web界面下的管理和分布部署，所以我又对每个环境测试了下通过docker run来启动整改环境下的容器和容器互联，以便可以实现pydocker进行操作和部署。

这个项目还没有做完，我的想法是实现类似于一键部署整个vulhub环境以及一个功能比较全管理应用。P神有兴趣求指导一下~~

说了这么多，我想说明的是，按照目前所有dockerfile的情况来看，编译好整个环境的速度还是太慢了，反正我在使用的过程中没什么耐心去等8k/s的下载速度，所以我觉得加速可以作为另外一个分支来做，和vulhub本身保持漏洞环境上的同步，毕竟如果vulhub一直有人维护，那么就算已有的第三方源失效，我们也可以采取其他方式实现加速。

再次感谢P神的工作。