你的数据安全么？Hadoop再曝安全漏洞|黑客利用HadoopYarn资源管理系统未授权访问漏洞进行攻击...

4月30日，阿里云发现，俄罗斯黑客利用Hadoop Yarn资源管理系统REST API未授权访问漏洞进行攻击。

Hadoop是一款由Apache基金会推出的分布式系统框架，它通过著名的 MapReduce 算法进行分布式处理，Yarn是Hadoop集群的资源管理系统。

此次事件主要因Hadoop YARN 资源管理系统配置不当，导致可以未经授权进行访问，从而被攻击者恶意利用。攻击者无需认证即可通过REST API部署任务来执行任意指令，最终完全控制服务器。

利用方式还原及趋势判断

1、通过对比分析，阿里云安全专家观察到，与之前Redis、CouchDB事件相比，Hadoop作为一个分布式计算应用程序框架，让其更容易被“攻陷”，因为：

Hadoop种类和功能繁多，各种组件安全问题，可能会带来更大的攻击面；

针对某一个薄弱点的攻击，可能通过该框架分布式的特性，迅速扩散到所有节点。

2、灰黑产的入侵变现的手段，正在从入侵利用云上普通主机资源挖矿获利（Web服务器、数据库服务器等），转向攻击专用算力应用，以窃取更大的算力进行挖矿获利转变（如Hadoop等分布式计算平台）。从本次样本的分析来看，利用专用算力应用来攻击变现的方式，还处在早期的测试阶段；随着加密货币的进一步繁荣，该类型的攻击风险将会愈发凸显。

总的来说，灰黑产对经济利益的渴求，推动着这个行业的变迁升级。随着加密货币市场热度的攀升，入侵挖矿的灰色产业，也会随之扩大；挖矿这种最有效变现手段对算力不断扩大的需求，必然引导灰黑产的攻击目标逐步转向更高算力的产品和服务。

因此，阿里云安全专家建议，不论是SaaS化服务的算力产品提供商，还是算力的最终使用者，都应该更加的关注安全问题，只有在发展自己的业务的同时切实加强安全水平，才能保障业务长期健康稳定的发展。

附：详细YARN REST API如下所示
http://hadoop.apache.org/docs...

安全建议

针对此类大规模攻击，阿里云平台已可默认拦截，降低漏洞对用户的直接影响；

如果企业希望彻底解决Hadoop安全漏洞，推荐企业使用阿里云MaxCompute （8年以上“零”安全漏洞）存储、加工企业数据；

阿里云数加MaxCompute（原名ODPS）设计之初就是面向多租户，确保租户的数据安全是MaxCompute的必备功能之一。在MaxCompute系统的安全设计和实现上，MaxCompute的工程师们会遵循一些经过实践检验的安全设计原则（如Saltzer-Schroeder原则）。在常用密码算法及安全协议的设计和实现上，也会遵循业界相关标准（如PKCS-及FIPS-系列标准），并坚持最佳安全实践。

这里从如下几个方面来解刨一下MaxCompute的安全特性，让关心MaxCompute数据安全的读者有一个基本的了解。更多产品信息请访问https://www.aliyun.com/produc... 。

1. API认证

认证是一个服务的安全入口。MaxCompute认证采用业界标准的API认证协议来实现，如HmacSHA1。MaxCompute还提供HTTP和HTTPS两种的EndPoint以满足用户对认证安全的不同要求。HTTP EndPoint是明文传输，那么HmacSHA1认证只能保证消息请求的真实性(Authenticity)和完整性(Integrity)，适合于对数据安全不太敏感的用户。HTTPS EndPoint则能提供更多的安全性，比如信道加密，抗重放攻击等。适合于对数据安全比较敏感的用户。

2. 访问控制

当你创建项目空间后，你就是项目空间的owner。一个项目空间只有一个owner，只有owner对项目空间有完全控制权限。你可以上传/下载数据、提交SQL进行数据处理。在没有你的授权的情况下，任何其他用户都无权访问你的项目空间。 注意，MaxCompute平台并没有超级管理员的角色，所以MaxCompute的开发、测试、运维同学都是没有权限看到用户数据的。有人会问了，通过MaxCompute背后的运维管理控制台也不能访问用户数据吗？的确不能。运维同学只有在获得内部授权之后，可以通过该控制台来执行一些运维管理类操作，比如停止一个有恶意行为的用户作业，但该控制台没有操作用户数据的权限。

MaxCompute产品面向的是企业级用户，所以提供了丰富的项目空间内的用户管理及授权功能，有兴趣的同学可以参考MaxCompute用户手册中的相关章节。MaxCompute访问控制粒度非常精细，比如你可以授权一个用户只能读某个table的部分columns，并且可以要求该用户只能在某个时间范围内、而且必须从指定的某些IP地址来进行访问。换句话说，一个企业主可以做到只允许其员工在公司内、在正常上班时间才能访问数据，下班回家就不允许访问了。

3. 数据流控制

MaxCompute设计之初就是要满足数据分享（或数据交换）的场景。所以，只要有授权，用户就可以非常方便的进行跨项目空间的数据访问。比如，在获得相应的访问权限之后，项目空间A中的作业可以直接处理项目空间B中的数据，而不必事先将数据从项目空间B中复制到项目空间A。

数据保护有两层含义，一是防止未授权的数据访问；二是防止获得授权的用户滥用数据。很多商用系统并不提供后一种数据安全保证。但在MaxCompute平台上，用户的这种担忧比较明显：用户希望能确保对自己的数据拥有控制权，而一旦授权他人读取，他人就可能会做复制数据，那么就相当于失去了对数据的控制权。

MaxCompute通过支持数据流控制来防止跨项目空间的数据复制。如果你想确保项目空间中的所有数据都不允许流出去，那么你可以打开项目空间的数据流控设置。你还可以设置项目空间的数据保护策略，以限制哪些数据可以流出到哪些项目空间。

4. 用户作业的隔离运行

MaxCompute支持用户提交各种类型的作业（如SQL/XLib/MR）。为了确保不同用户作业在运行时互不干扰，MaxCompute将用户作业的Worker进程运行在飞天 Container沙箱中。如果用户作业含有Java代码（比如UDF），那么飞天Container沙箱中的Worker进程启动JVM时，还会设置严格的Java 沙箱策略以限制UDF的运行时权限。

5. 作业运行时使用最小权限

最小权限原则是系统安全和容错设计的一个基本指导原则，即让每个任务在运行时使用刚好满足需要（不多也不少）的权限来执行。

MaxCompute的作业运行过程一般是这样：用户提交的SQL/XLib/MR作业会被调度到某一计算集群上运行，运行时每个作业一般对应一组并行跑的Worker进程，Worker进程一般会从数据集群上读数据、处理完成后最终会将数据写回到数据集群。举个例子来理解MaxCompute是如何遵循最小权限原则的。我们假设用户Alice被授权读访问一个项目空间下t1和t2两个table数据，但她提交的某个SQL只需要读t1的数据。在MaxCompute中，这个SQL对应的Worker进程在运行时就只能读t1对应的底层数据文件，而不会有更多的数据访问权限。

MaxCompute最小权限是依赖于底层的飞天分布式操作系统提供的Kerberos认证和Capability访问控制来实现的。Kerberos认证用于解决飞天底层服务模块之间的身份认证，Capability则用于解决底层服务模块之间的访问控制技术。这与上层MaxCompute所提供的认证和访问控制是完全正交的安全机制，对MaxCompute用户是完全透明的。

6. 数据访问审计

MaxCompute还提供精准的、细粒度的数据访问操作记录，并会长期保存。MaxCompute平台体系所依赖的功能服务模块非常之多，我们可以把它称之为底层服务栈。对于数据操作记录来说，MaxCompute会收集服务栈上的所有操作记录，从上层table/column级别的数据访问日志，一直到底层分布式文件系统上的数据操作日志。最底层分布式文件系统上处理的每一次数据访问请求，也都能追溯到是最上层的哪个项目空间中的哪个用户的哪个作业发起的数据访问。

有了服务栈上的各层操作审计之后，即使是内部攻击者（工程师或渗透到内部系统中的黑客）想从内部（绕过MaxCompute服务）直接访问底层分布式文件系统上的用户数据的话，也一定是可以从操作日志中被发现的。所以，通过数据访问审计，用户就可以准确的知道他在MaxCompute上的数据是否存在未授权的数据访问。

7. 风险控制

除了不同层面的防御机制之外，MaxCompute产品还会提供一套安全监控系统，用于监控用户作业及用户数据的安全活动，如AccessKey滥用，项目空间安全配置不当，用户代码运行时触犯安全策略，以及用户数据是否遭受异常访问等。

安全攻击防不胜防，所以MaxCompute会通过安全监控手段来及时发现问题，一旦发现安全问题则会启动相应的处理流程，尽可能将用户损失降到最低。

结语：虽然没有绝对的安全，但安全性在MaxCompute产品设计和实现中享有最高优先级。MaxCompute团队已经汇聚了多领域的安全专家，以保障用户数据安全。同时，我们欢迎更多安全专家的加入，共同增强MaxCompute的数据安全。

本文作者:隐林
原文链接
本文为云栖社区原创内容，未经允许不得转载