记一次Kubernetes中严重的安全问题
此事件发生在 2021-03 月份.
近期遇到了一次我们自建Kubernetes集群中某台机器被入侵挖矿, 后续也找到了原因, 所幸只是用来挖矿…
网络安全是个严肃的问题, 它总是在不经意间出现, 等你反应过来却已经迟了. 希望各位读者看完后也有所启发, 去检查及加固自己的集群.
入侵现象
检查到某台机器中出现了异常进程
1 | ./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCm |
简单来讲, 就是我们的机器被用来挖矿了…
问题出现后, 我们第一时间关闭了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的完整控制权限. 如果读者有读过我关于docker系列的内容, 就对权限上了解清楚了.
因为此次事件的发生, 不只是我, 还有SA的同学基本都被diao了一遍, 心里还是有点难受的, 希望大家能对网络安全问题有所重视, 从加固防火墙开始, 避免监听不必要的端口, 这两项至少是最容易实现的.