|
最近两天，网上有两篇热文传播，作者左耳朵耗子(以下简称耗子)表达了其对“经典网络”安全性的担忧，质疑阿里云“经典网络”存在安全隐患，并呼吁大家尽快使用“VPC”。
我们先来科普下什么是经典网络，什么是私有网络(VPC)，然后再讨论这个“安全”问题是否严重。
“经典网络”是从AWS的EC2-Classic直译过来的，从实际功能看，翻译为“基础网络”更为合理一些，因为它只具备“最基本”的网络功能。
经典网络与VPC的主机隔离设置不同，这也是前面安全性争论的焦点。通过上图我们可以看到，在经典网络下，同一租户，默认采用同一安全组，VM之间是彼此互通的。而不同租户，通常情况下，VM之间是默认彼此完全隔离的。也就是说，一个租户只能看到自己的机器，不可能与其他租户的机器互通的。
那么问题来了，为什么耗子用NMAP可以扫到那么多内网的机器呢？看到那个结果我也有点不寒而栗。
我赶紧去做了个实验，终于想明白了原因所在：
①分别用两个账号从阿里云某区申请ECS主机如下
②测试主机间的连通性 主机A1&主机A2
[root@iZbp1dqkczsim0gy0d180xZ soft]# ping 10.168.176.53 PING 10.168.176.53 (10.168.176.53) 56(84) bytes of data. 64 bytes from 10.168.176.53: icmp_seq=1 ttl=64 time=0.269 ms 64 bytes from 10.168.176.53: icmp_seq=2 ttl=64 time=0.253 ms 64 bytes from 10.168.176.53: icmp_seq=3 ttl=64 time=0.235 ms 64 bytes from 10.168.176.53: icmp_seq=4 ttl=64 time=0.247 ms 64 bytes from 10.168.176.53: icmp_seq=5 ttl=64 time=0.221 ms
同一租户，同一安全组，正常互通
主机A1与主机B1
[root@iZbp1dqkczsim0gy0d180xZ soft]# ping 10.117.27.239 PING 10.117.27.239 (10.117.27.239) 56(84) bytes of data.
^C --- 10.117.27.239 ping statistics --- 36 packets transmitted, 0 received, 100% packet loss, time 34999ms
[root@iZbp1dqkczsim0gy0d180xZ soft]# nmap -v -sT 10.117.27.239/32
Starting Nmap 7.40 ( https:// ) at 2017-02-28 00:17 CST Initiating Ping Scan at 00:17 Scanning 10.117.27.239 [4 ports] Completed Ping Scan at 00:17, 3.02s elapsed (1 total hosts) Nmap scan report for 10.117.27.239 [host down] Read data files from: /usr/bin/../share/nmap Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.07 seconds Raw packets sent: 8 (304B) | Rcvd: 0 (0B) [root@iZbp1dqkczsim0gy0d180xZ soft]#
不同租户，无论ping还是NMAP扫描，都检测不到，说明缺省情况下，租户间是成功隔离的，那么耗子的扫描结果是怎么回事呢？
我们也尝试对B租户整个C类网段进行扫描>>
[root@iZbp1dqkczsim0gy0d180xZ soft]# nmap -v -sT 10.117.27.239/24
Starting Nmap 7.40 ( https:// ) at 2017-02-28 00:22 CST Initiating Ping Scan at 00:22 Scanning 256 hosts [4 ports/host] Completed Ping Scan at 00:22, 4.32s elapsed (256 total hosts) Initiating Parallel DNS resolution of 256 hosts. at 00:22 Completed Parallel DNS resolution of 256 hosts. at 00:22, 0.00s elapsed Nmap scan report for 10.117.27.0 [host down] Nmap scan report for 10.117.27.1 [host down] Nmap scan report for 10.117.27.2 [host down] 此处省略200+条
Nmap scan report for 10.117.27.255 [host down] Initiating Connect Scan at 00:22 Scanning 15 hosts [1000 ports/host] Discovered open port 111/tcp on 10.117.27.50 Discovered open port 80/tcp on 10.117.27.57 Discovered open port 139/tcp on 10.117.27.159 Discovered open port 80/tcp on 10.117.27.188 Discovered open port 80/tcp on 10.117.27.200 此处省略20+条 Discovered open port 1105/tcp on 10.117.27.188 Discovered open port 9090/tcp on 10.117.27.243 Discovered open port 5666/tcp on 10.117.27.50 Discovered open port 873/tcp on 10.117.27.188 ……
果然在10.117.27.0/24这子网下，扫描到大量开放端口的主机，这个结论和“耗子”的结果基本一致，但我用来做测试的主机B1(10.117.27.239)却没有被扫描到。
其实到这里，原因已经很明显了，虽然阿里云的经典网络默认是租户间隔离的，但是会有一些小白用户在申请到主机以后，更改了默认的安全策略，并采用过于粗放的地址放行规则。
我猜想的场景可能是这样的： 小白用户A和B分别申请了一台虚拟机，但这两台机器是不能内网互通的，因为某种原因，小A和小B希望他们的主机能够互通，于是就要更改默认的安全组策略，假设小A机器的地址为a.a.a.a，小B的地址为b.b.b.b。
于是小A打开控制台，开始这样配置>>
结果，小A就允许所有人都来他家参观了，多么痛的领悟。
我们在设置安全规则的时候，要特别严谨，不管是地址端、端口范围还是协议类型，都应该精准再精准。毕竟，安全无小事。NMAP能扫描到这么多暴露的主机，是因为有太多的小白图省事，导致门户大开。
那么这个事情到底有多严重？ 其实也不必过分渲染，如果有云主机的公网IP，你用NMAP去扫一下公网网段，可能也会吓一跳：
同样也都是服务器地址，而且地址也是连续的，网速也是很快的，不管你是经典网络还是VPC网络，都是不能幸免的哦，不管你是阿里云还是什么云，都是一样的哦。
我们可以通过“认真”配置安全组，保证内网IP不被扫到，但只要你对外提供服务，公网IP被扫却是不可避免的。我们的每个地址，其实每天都被扫描探测了无数次，而我们之所以现在还安全，取决于主机安全能力和云平台的整体防御能力，或者：我们的机器对黑客还没有足够的诱惑力。
顺便去看了下其他云服务商的网络提供状况，状况如下：
国内云服务商都有向VPC全面过渡的趋势，而国外两A目前已经不提供非VPC接入。可想而知，存量“经典网络”客户转换成VPC客户，还是有较大负担的，所以，AWS为老客户保留了经典网络(EC2-Classic)，不知道阿里云将来如何完成存量老客户向VPC的迁移。
本着实事求是的态度，我在阿里云、腾讯云、UCloud、青云、金山云上分别申请了云主机，使用NMAP扫描，看看他们的隔离性到底如何。
(此前发布的版本有误，下午经过重新验证)
腾讯云的安全策略是最强的，值得点个赞，这种情况下，无论小白A和小白B怎么粗放配置，都不会形成互通了，想通也通不了。
阿里云的策略太依赖于租户自己的安全技能，小白客户容易中招，前文已经有很多介绍，此处不再赘述。
UCloud同样强制隔离，他们的基础网络其实后端也是靠VPC来实现的，在保证安全的前提下，还提供了灵活性，基于一个“项目打通”功能，可以完成不同租户间的网络互通，这种既安全又灵活的方式，值得借鉴。
青云的策略宽松，基础网络的安全性也最低，虚要依赖于后期配置防火墙策略来实施阻断，但青云的基础网络和VPC并不严格区分，可以灵活转化，建议青云的基础网络客户全部切换为安全高的VPC服务，而青云自己也在力推VPC。
金山大米云主机提供的类似于'经典网络'的功能，默认租户隔离，后台可能也是基于VPC来实现的，由于这是一个体验型的爆款产品，控制台独立于金山云其它产品，不具备通用性，不做过多点评。
注：以上只涉及经典(基础)网络的对比，其它几家云服务商由于只提供VPC网络，所以不做点评，后续我会做一期专门针对VPC网络的横向比较。
所以，所以，所以，云端安全考验着所有云服务商的能力，需要大家不断健全机制和手段，提升客户的上云信心，阿里云在这件事中之所以背锅，很大的原因是没有对小白客户进行足够的教育和警示，同时，阿里云在租户间安全模型设置上，到底是采用“完全”强制隔离还是可“配置”隔离，还需要仔细评估，毕竟我们不能把安全建立在用户自身专业技能上。
相信此事发酵之后，国内的公有云们都会加强对“经典网络”用户的重点关照，也会加大力度推广VPC模式。广大云用户的安全意识也需要快速提升，不是黑客太强，是我们自己太弱，VPC再牛也挡不住猪一样的队友啊。
或许，这会成为“云上网络安全”的里程碑事件！
|
