服务器变矿机，老板差点把我开除了

关注 51CTO技术栈，悦享技术，成就 CTO 梦想

“

近期遇到了一次我们自建 Kubernetes 集群中某台机器被入侵挖矿的情况，后续也找到了原因，所幸只是用来挖矿……

图片来自 Pexels

网络安全是个严肃的问题，它总是在不经意间出现，等你反应过来却已经迟了。希望各位读者看完后也有所启发，去检查及加固自己的集群。

入侵现象

检查到某台机器中出现了异常进程：

简单来讲，就是我们的机器被用来挖矿了……

问题出现后，我们第一时间关闭了 Docker，其实应该隔离下环境，把挖矿程序 dump 下来，以便后续分析。

具体原因排查

iptables 为空

出现了异常进程，肯定是被入侵了，我首先看的是 iptables。果不其然，机器上的 iptables 规则是空的，意味着这台机器在裸奔。

kubelet 裸奔

内部同事提出了有可能是 kubelet 被入侵的问题，检查过其他组件后，开始检查 kubelet 组件。

最后检查到 kubelet 日志中有异常：

kubelet 设置不当

确认入侵问题，kubelet 参数设置错误，允许直接访问 kubelet 的 API。

发现是 kubelet 的启动项中，该位置被注释掉：

然后文件中禁止匿名访问的配置没有读取。

该项配置是由于我操作不当注释掉的。

由于是新增加的机器，当晚就发现了问题，整个集群是我在管理的，我跟随着一起排查，所以很快就找到了原因。

当晚我就把其他机器中的配置项重新扫了一遍，假如它们的防火墙失效了，也会有类似的入侵情况发生，还好此次事件控制在 1 台机器中。

改进方案

其实该问题理论上讲是可以避免的，是因为出现了多层漏洞才会被有心人扫到。

我从外到内整理了一下可能改进的策略：

机器防火墙设置，机器防火墙是整个系统最外层，即使机器的防火墙同步失败，也不能默认开放所有端口，而是应该全部关闭，等待管理员连接到 tty 终端上检查。

使用机器时，假如机器不是暴露给外部使用的，公网 IP 可有可无的时候，尽量不要有公网IP，我们的机器才上线1天就被扫描到了漏洞，可想而知，公网上是多么的危险。

使用 kubelet 以及其他系统服务时，端口监听方面是不是该有所考量？能不能不监听 0.0.0.0，而是只监听本机的内网 IP。

使用 kubelet 以及其他程序，设计或是搭建系统时，对于匿名访问时的权限控制，我们需要考虑到假如端口匿名会出现什么问题，是否应该允许匿名访问，如果不允许匿名访问，那么怎么做一套鉴权系统？

系统管理员操作时，是否有一个比较规范化的流程，是不是该只使用脚本操作线上环境？手动操作线上环境带来的问题并不好排查和定位。

我这里不是抛出疑问，只是想告诉大家，考虑系统设计时，有必要考虑下安全性。

总结

发生了入侵事件后，同事开玩笑说，还好没其他经济损失，要不我可能要回家了。

作为集群的管理员，只有自己最清楚问题的严重程度，从本质上来讲，问题已经相当严重了。入侵者相当于拥有了机器上 Docker 的完整控制权限。

因为此次事件的发生，不只是我，还有 SA 的同学基本都被 diao 了一遍，心里还是有点难受的，希望大家能对网络安全问题有所重视，从加固防火墙开始，避免监听不必要的端口，这两项至少是最容易实现的。

了解鸿蒙一手资讯

作者：corvofeng

编辑：陶家龙

出处：https://corvo.myseu.cn/