阿里云渗透测试_云服务器渗透测试工具

文章导航:

渗透测试报告自动生成工具

公众号:白帽子左一

领取配套练手靶场、安全全套课程及工具...

在安服仔的日子里,发现其他人输出的渗透测试报告结果不规范,主要在报告质量、内容、字体、及修复方案中存在诸多问题,而且 大部分安服仔需要对每次的项目结果进行统计整理,方便后续跟踪复测。

因此研发了 Savior—渗透测试报告辅助生成系统 , 起这个名字也是为了拯救大多数渗透测试工程师,

告别繁琐的渗透测试报告编写过程及漏洞统计过程。

前端 : Ant Design Pro

后端 : Django REST Framework

数据库 : Mysql

用户管理 : 主要是方便统计漏洞的发现者,后续可能大概也许会添加漏洞统计模块,根据提交数据、漏洞类型、时间等进行统计报表,当前用户管理模块仅允许通过Django后台进行修改,前端只负责展示,主要是我太懒了。

项目管理 : 根据项目的不同可上传项目的专属渗透测报告模板,并可以根据需要进行模板自定义模板(/Demo/demo.docx);

模板自定义 : 不用修改源代码,仅需修改word即可进行模板自定义;

整改建议管理 : 此平台主要就是为了体现标准化输出,因此可通过内置漏洞描述及修复建议进行快速输出,并支持自定义修改(/Demo/常规WEB渗透测试漏洞描述及修复方法.docx);

一键生成: 通过提交报告模块,内联项目模板,快速生成渗透测试报告,真正达到了一键生成,并确保报告内数据准确、字体统一、格式标准;

自动邮件: 在生成报告后可通过用户管理配置的自动邮件发送功能进行邮件通知,可自定义邮件模板,这样再报告给客户的时候就可以直接转发了(暖男功能);

漏洞统计: 每次渗透过后,需要挨个查找报告进行统计整理,现在只要提交报告后,后台会自动联动;

漏洞报表一键导出

漏洞跟踪: 增加了漏洞状态字段,创建报告后,漏洞状态默认为新增,漏洞管理模块可进行复测,包括已整改、未整改两种状态;

Demo :

演示账号 :admin

演示密码 : Savior@404

首先将代码clone到本地:

Docker部署

我们推荐使用Docker进行部署,相对于源码部署更为简单和快速。

部署前请务必先安装 Docker 及 docker-compose 。

修改配置文件

首先复制根目录的 .env.docker 并重命名为 .env , 修改其中的Email Settings和initial Administrator配置。

这两个配置分别控制邮件提醒,以及初始管理帐号密码及邮箱。

同时需要注意以下两点:

1. 务必把邮箱修改为自己邮箱,不然可能会出现非预期错误!

2. 如果使用阿里云、腾讯云服务器,请使用smtp的ssl协议,两家云厂商默认封禁了25端口。

一键启动

访问 即可看到页面。

修改启动端口

如果想修改启动端口,可以修改docker-compose.yaml文件中web容器的ports。

默认为8000:8000,比如要修改为8080端口可改为8080:8000。

所需环境:

前端环境

环境变量设置 创建字符集为utf-8编码的数据库。

复制**.env.docker为.env**,并配置数据库、邮箱、管理员等信息。

后端环境

源码部署环境:

前台页面 :

Django管理后台:

其中Savior平台包含两个后台页面。考虑到安全性,目前用户管理、项目管理托管于Django管理后台(主要是这两个模块不会写),其余功能均可通过前台页面实现。

前台页面 :

Django管理后台 :

访问Django管理后台: ,

请完善API用户的Name、Avatar、Autosentmail三个字段,分别控制报告的作者、头像(图片Url)、生成报告后自动发送渗透测试报告到邮箱。

访问Django管理后台:

请通过APIProjects进行添加项目,可根据不通项目选择不通的渗透测试报告模板。

参数说明:Project logo(项目Logo)、Project center(项目名称)、Project description(项目描述)、Project template(渗透测试报告模板,目前标准模板可使用Demo/demo.docx,如需自定义模板,请参考模版自定义部分)

访问 可进入Savior平台,通过个人设置整改设置添加漏洞模板可进行设置漏洞类型、漏洞描述、修复建议从而达到标准化。

目前整理了一些通用的修复建议模板,请参考Demo/常规WEB渗透测试漏洞描述及修复方法.docx。

目前根据我经常使用的渗透测试报告模板生成了一个demo版本(请参考/Demo/demo.docx)。

当然您也可以根据自己的需求进行模板自定义,其中仅需在WORD模板中进行参数替换,目前Savior中具体参数如下:

以下漏洞详情请利用{%tr for vuls in vuls %}{%tr endfor %}进行循环遍历。

如想列出所有漏洞URL,则使用参数{%tr for vuls in vuls %}{{item.vul_url}}{%tr endfor %}

注: Savior平台渗透测试模板遵循Jinja2语法,更多内容请参考

如果我们完善了用户信息、项目管理、整改设置后,就可以通过前端页面进行创建报告,其大概流程如下:首先完善报告的基本信息。

选择漏洞管理的添加漏洞功能。选择漏洞类型后,漏洞名称、漏洞描述、修复建议会根据整改设置进行自动联动,并可根据需求进行自定义修改。

需要注意的是漏洞详情处如果需要插入XSS语句,请进行url编码后进行输入!

注: 未提交前请勿刷新页面,此时漏洞详情保存为前端。提交后会自动生成渗透测试报告并进行下载。

打开报告会提示更新域,更新请选择是,再选择更新整个目录,此问题主要是为了更新目录,不然渗透测试报告中目录无法自动更新。

如果在用户管理打开了Autosentmail功能,渗透测试报告会自动发送至我们邮箱,方便转给甲方爸爸。

访问Savior平台,选择漏洞列表可进行漏洞统计并进行漏洞复测。

其中漏洞包含三个状态(新发现、已修复、未修复)。

通过选择导出数据功能,可将漏洞列表导出为Excle。

用户管理、项目管理迁移至前端

大数据看板

感谢 echo503 提供的项目帮助

感谢 lp0int 提供的项目帮助

项目框架及 Docker 部署参考 Github-Monitor:( )

原文地址:

什么是K8S?

k8s是什么?

Kubernetes 是一个可移植的云服务器渗透测试工具,可扩展的开源容器编排平台,用于管理容器化的工作负载和服务,方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务,支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

secret

Secret有三种类型云服务器渗透测试工具

Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的目录中云服务器渗透测试工具

/run/secrets/kubernetes.io/serviceaccount

Opaque:base64编码格式的Secret,用来存储密码、密钥等;

kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息。

k8s的组成

k8s是由组件,API,对象等组成.

包含所有相互关联组件的 Kubernetes 集群图如下:

组件

控制平面组件

kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其云服务器渗透测试工具他所有组件都必须通过它提供的API来操作资源数据.

保证集群状态访问的安全

隔离集群状态访问的方式和后端存储实现的方式:API Server是状态访问的方式,不会因为后端存储技术etcd的改变而改变。

etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。

kube-scheduler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况,然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。

cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件

Node 组件

kubelet: 一个在集群中每个节点(node)上运行的代理。 它保证容器(containers)都 运行在 Pod 中。

kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

容器运行时: 负责运行容器的软件。

插件(Addons)

DNS: 集群 DNS 是一个 DNS 服务器,和环境中的其他 DNS 服务器一起工作,它为 Kubernetes 服务提供 DNS 记录。

Web 界面(仪表盘): Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。

容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中,并提供用于浏览这些数据的界面。

集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中,该存储能够提供搜索和浏览接口。

API

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API,以供用户、集群中的不同部分和集群外部组件相互通信。

对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

具体来说,他们可以描述:

容器化应用正在运行(以及在哪些节点上)

这些应用可用的资源

关于这些应用如何运行的策略,如重新策略,升级和容错

Kubernetes 架构

Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

master 流程图

Kubecfg将特定的请求,比如创建Pod,发送给Kubernetes Client。

Kubernetes Client将请求发送给API server。

API Server根据请求的类型,比如创建Pod时storage类型是pods,然后依此选择何种REST Storage API对请求作出处理。

REST Storage API对的请求作相应的处理。

将处理的结果存入高可用键值存储系统Etcd中。

在API Server响应Kubecfg的请求后,Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。

依据从Kubernetes Client获取的信息,Scheduler将未分发的Pod分发到可用的Minion/Node节点上。

节点

节点可以是一个虚拟机或者物理机器,取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务, 这些 Pods 由 控制面 负责管理.

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

可以使用 kubectl 来查看节点状态和其他细节信息:

kubectl describe node �节点名称

一个节点包含以下信息:

地址

HostName:由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。

ExternalIP:通常是节点的可外部路由(从集群外可访问)的 IP 地址。

InternalIP:通常是节点的仅可在集群内部路由的 IP 地址。

状况(conditions 字段描述了所有 Running 节点的状态)

Ready 如节点是健康的并已经准备好接收 Pod 则为 True;False 表示节点不健康而且不能接收 Pod;Unknown 表示节点控制器在最近 node-monitor-grace-period 期间(默认 40 秒)没有收到节点的消息

DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 False

MemoryPressure为True则表示节点存在内存压力,即节点内存可用量低,否则为 False

PIDPressure为True则表示节点存在进程压力,即节点上进程过多;否则为 False

NetworkUnavailable为True则表示节点网络配置不正确;否则为 False

容量与可分配描述节点上的可用资源:CPU、内存和可以调度到节点上的 Pod 的个数上限。

信息关于节点的一般性信息,例如内核版本、Kubernetes 版本(kubelet 和 kube-proxy 版本)、 Docker 版本(如果使用了)和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

控制面到节点通信

节点到控制面

apiserver在安全的 HTTPS 端口(443)上监听远程连接请求

以客户端证书的形式将客户端凭据提供给 kubelet

控制面到节点

API 服务器到 kubelet连接用于

获取 Pod 日志

挂接(通过 kubectl)到运行中的 Pod

提供 kubelet 的端口转发功能。

(注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击,不安全.)

apiserver 到节点、Pod 和服务

SSH 隧道(目前已经废弃)

产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道.

Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。

Konnectivity 服务为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理,以便支持从控制面到集群的通信。

控制器

在 Kubernetes 中,控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。

举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。

控制器模式分为直接控制和通过API服务器来控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中, 并分离出相互作用的组件与您的集群交互的组件。

云控制器管理器中的控制器包括:

节点控制器

节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点(Node)对象。 节点控制器从云提供商获取当前租户中主机的信息。

执行功能:

针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象

利用特定云平台的信息为 Node 对象添加注解和标签

获取节点的网络地址和主机名

检查节点的健康状况。

路由控制器Route 控制器负责适当地配置云平台中的路由,以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。

服务控制器服务(Service)与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互,以配置负载均衡器和其他基础设施组件。

Kubernetes 安全性

云原生安全

云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

云原生安全模型的每一层都是基于下一个最外层,代码层受益于强大的基础安全层(云、集群、容器)。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

Kubetnetes 基础架构关注领域

建议

通过网络访问 API 服务(控制平面)

所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开,同时应由网络访问控制列表控制,该列表包含管理集群所需的 IP 地址集。

通过网络访问 Node(节点)

节点应配置为 仅能 从控制平面上通过指定端口来接受(通过网络访问控制列表)连接,以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话,这些节点不应完全暴露在公共互联网上。

Kubernetes 云访问提供商的 API

每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时,最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

访问 etcd

对 etcd(Kubernetes 的数据存储)的访问应仅限于控制平面。根据配置情况,你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

etcd 加密

在所有可能的情况下,最好对所有驱动器进行静态数据加密,但是由于 etcd 拥有整个集群的状态(包括机密信息),因此其磁盘更应该进行静态数据加密。

集群组件安全

运行的应用程序的安全性关注领域

访问控制授权(访问 Kubernetes API)

认证方式

应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)

Pod 安全策略

服务质量(和集群资源管理)

网络策略

Kubernetes Ingress 的 TLS 支持

容器安全

容器安全性关注领域

容器搭建配置(配置不当,危险挂载, 特权用户)

容器服务自身缺陷

Linux内核漏洞

镜像签名和执行

代码安全

代码安全关注领域

仅通过 TLS 访问(流量加密)

限制通信端口范围

第三方依赖性安全

静态代码分析

动态探测攻击(黑盒)

Kubernetes架构常见问题

Kubernetes ATTACK 矩阵

信息泄露

云账号AK泄露

API凭证(即阿里云AccessKey)是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

API凭证相当于登录密码,用于程序方式调用云服务API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME/.kube/config

Kubeconfig文件包含有关Kubernetes集群的详细信息,包括它们的位置和凭据。

云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到Github的代码等),就可以直接通过API Server接管K8s集群,带来风险隐患。

Master节点SSH登录泄露

常见的容器集群管理方式是通过登录Master节点或运维跳板机,然后再通过kubectl命令工具来控制k8s。

云服务器提供了通过ssh登陆的形式进行登陆master节点.

若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

容器组件未鉴权服务

Kubernetes架构下常见的开放服务指纹如下:

kube-apiserver: 6443, 8080

kubectl proxy: 8080, 8081

kubelet: 10250, 10255, 4149

dashboard: 30000

docker api: 2375

etcd: 2379, 2380

kube-controller-manager: 10252

kube-proxy: 10256, 31442

kube-scheduler: 10251

weave: 6781, 6782, 6783

kubeflow-dashboard: 8080

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)

kubectl 会读取 ~/.kube/config 配置,并与 apiserver 进行交互,协议:http/https

apiserver 会协同 ETCD, kube-controller-manager, scheduler 等组件准备下发新建容器的配置给到节点,协议:http/https

apiserver 与 kubelet 进行交互,告知其容器创建的需求,协议:http/https;

kubelet 与Docker等容器引擎进行交互,创建容器,协议:http/unix socket.

容器已然在集群节点上创建成功

攻击apiserver

apiserver介绍:

在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.

在攻击者眼中Kubernetes APIServer

容器编排K8S总控组件

pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,

endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,

persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …

可控以上所有k8s资源

可获取几乎所有容器的交互式shell

利用一定技巧可获取所有容器母机的交互式shell

默认情况下apiserver都有鉴权:

未鉴权配置如下:

对于这类的未鉴权的设置来说,访问到 apiserver 一般情况下就获取了集群的权限:

如何通过apiserver来进行渗透,可参考:

攻击kubelet

每一个Node节点都有一个kubelet(每个节点上运行的代理)服务,kubelet监听了10250,10248,10255等端口。

10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下,不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.

在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.

/var/bin/kubulet/config/yaml

若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看

根据在pods中获取的信息,我们可以在容器中执行命令

curl -Gks {namespace}/{podname}/{containername} \-d 'input=1' -d 'output=1' -d 'tty=1' \-d 'command=whoami'

上述命令得到websocket地址,连接websocket得到命令结果:

使用wscat工具连接websocket

wscat -c “{websocket}” --no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets/kubernetes.io/serviceaccount

然后即可访问kube-api server,获取集群权限

curl -ks -H "Authorization: Bearer \ ttps://master:6443/api/v1/namespaces/{namespace}/secrets

"

攻击kubelet总体步骤如下:

访问pods获取信息

获取namespace、podsname、containername

执行exec获取token

/var/run/secrets/kubernetes.io/serviceaccount

利用Token访问API Server进行对pods操作。

攻击dashboard

dashboard登陆链接如下:

dashboard界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下,通过dashboard我们可以控制整个集群。

默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.

通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理,不同的serviceaccount拥有不同的集群权限。

但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole(cluster-admin拥有管理集群的最高权限).

为Kubernetes-dashboard绑定cluster-admin 设置如下:

新建dashboard-admin.yaml内容

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard

kubectl create -f dashboard-admin.yaml

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na

etcd对内暴露2379端口,本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

检查是否正常链接

etcdctl endpoint health

读取service account token

etcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole

通过token认访问API-Server端口6443,接管集群:

kubectl --insecure-skip-tls-verify -s --token="[ey...]" -n kube-system get pods

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口,通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时,可以在外部机器对该机器的docker daemon进行直接操作:

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

-H

因此当你有访问到目标Docker API 的网络能力或主机能力的时候,你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器,并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单,访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击kubectl proxy

二次开发所产生的问题

管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能,其实都是间接在和 APIServer 做交互.

如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。

例如:

给用户销毁自己POD的能力

DELETE

类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.

推荐工具

Kube-Hunter扫描漏洞

kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器

下载地址:

CDK(强推)

CDK是一款为容器环境定制的渗透测试工具,在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式,插件化管理。

下载地址:

参考链接

网络安全工程师分享的6大渗透测试必备工具

租用海外服务器,不可避免就是考虑使用安全问题,其中渗透测试可模仿网络黑客攻击,来评估海外服务器网络系统安全的一种方式。互联网中,渗透测试对网络安全体系有着重要意义。

通过渗透工具可提高渗透测试效率。快速云作为专业的IDC服务商,在本文中为大家分享了网络安全工程师推荐的6种必备渗透工具,使用这6种工具后用户可实现更高效的进行渗透测试。

一、NST网络安全工具

NST是基于Fedora的Linux发行版,属于免费的开源应用程序,在32、64平台运行。使用NST可启动LiveCD监视、分析、维护海外服务器网络安全性。可以用于入侵检测、网络浏览嗅探、网络数据包生成、扫描网络/海外服务器等等。

二、NMAP

可以用于发现企业网络种任意类型的弱点、漏洞,也可以用于审计。原理是通过获得原始数据包渠道哪些海外服务器在网络特定段中有效,使用的是什么操作系统,识别正在使用的特定海外服务器的数据包防火墙/过滤器的不同版本和类型。

三、BeEF工具

BeEF工具可以通过针对web浏览器查看单源上下文的漏洞。

四、AcunetixScanner

一款可以实现手动渗透工具和内置漏洞测试,可快速抓取数千个网页,可以大量提升工作效率,而且直接可以在本地或通过云解决方案运行,检测出网站中流行安全漏洞和带外漏洞,检测率高。

五、JohntheRipper

这款工具最常见,可简单迅速的破解密码。支持大部分系统架构类型如Unix、Linux、Windows、DOS模式等,常用于破解不牢固的Unix/Linux系统密码。

六、SamuraiWeb测试框架

SamuraiWeb测试框架预先配置成网络测试平台。内含多款免费、开源的黑客工具,能检测出网站漏洞,不用搭建环境装平台节省大部分时间很适合新手使用。

阿里云、云机器被渗透了怎么办?有什么好的办法?

最近很多阿里云机器以及云主机被渗透数据库进行勒索。那么我们要怎么保证我们的业务上线之后不被有心人利用呢?(阿里云服务器怎么防止被渗透)

渗透测试,是为了证明网络防御按照预期计划正常运行而提供的一种机制。不妨假设,你的公司定期更新安全策略和程序,时时给系统打补丁,并采用了漏洞扫描器等工具,以确保所有补丁都已打上。如果你早已做到了这些,为什么还要请外方进行审查或渗透测试呢?因为,渗透测试能够独立地检查你的网络策略,换句话说,就是给你的系统安了一双眼睛。而且,进行这类测试的,都是寻找网络系统安全漏洞的专业人士。

那么云服务器如何防止被暴力破解,保护数据不被恶意渗透呢?

通常是分为几个层面进行测试的,如下:

一、内网扫描:扫描服务器代码漏洞等。

二、外网扫描:扫描目前市场已知漏洞等。

三、 社会 工程学扫描:排除人为的安全隐患因素。

渗透人员在不同的位置(比如从内网、从外网等位置)利用各种手段对某个特定网络进行测试,以期发现和挖掘系统中存在的漏洞,然后输出渗透测试报告,并提交给网络所有者。网络所有者根据渗透人员提供的渗透测试报告,可以清晰知晓系统中存在的安全隐患和问题。

渗透测试还具有两个显著特点:一是渗透测试是一个渐进的并且逐步深入的过程;二是渗透测试是选择不影响业务系统正常运行的攻击方法进行的测试。

小蚁网络提供专业的渗透测试服务,可模拟黑客攻击对业务系统进行安全性测试,比黑客更早发现导致企业数据泄露、资产受损、数据被篡改的漏洞,并协助企业进行修复。

小蚁网络,作为业内资深的专业云安全服务提供商,致力于为广大互联网企业用户和传统行业的企业用户提供“云服务器、高防IP、高防cdn、香港服务器、大禹抗D 游戏 盾”等云云安全服务以及客户app综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为个人客户上云打造定制,能够满足用户丰富、多元化的应用场景需求。

做了专业的渗透测试之后,我们还要针对我们的app以及网站做专业的入侵防护检测系统(),小蚁卫士入侵防御系统以下简称“小蚁卫士NGIPS”, 它是一种新型应用安全保护技术,它将保护程序像疫苗一样注入到应用程序中,应用程序融为一体,能实时检测和阻断安全攻击,使应用程序具备自我保护能力,当应用程序遭受到实际攻击伤害,就可以自动对其进行防御,而不需要进行人工干预。

小蚁卫士入侵防御系统融合了小蚁网络在攻防技术领域的先进技术及研究成果,使其在精确阻断方面达到国际领先水平,可以对漏洞攻击、蠕虫病毒、间谍软件、木马后门、溢出攻击、数据库攻击、高级威胁攻击、暴力破解等多种深层攻击行为进行防御。入侵防御系统不但能发现攻击,而且能自动化、实时的执行防御策略,有效保障信息系统安全。

入侵防御产品已广泛应用于政府、金融、能源、电信等各行业领域,并积极拓展国际市场。

希望大家每一个产品都能够在梦想的摇篮之中萌芽,这里是 小蚁君为您分享。

官网:

渗透测试应该怎么做呢?

01、信息收集

1、域名、IP、端口

域名信息查询:信息可用于后续渗透

IP信息查询:确认域名对应IP,确认IP是否真实,确认通信是否正常

端口信息查询:NMap扫描,确认开放端口

发现:一共开放两个端口,80为web访问端口,3389为windows远程登陆端口,嘿嘿嘿,试一下

发现:是Windows Server 2003系统,OK,到此为止。

2、指纹识别

其实就是网站的信息。比如通过可以访问的资源,如网站首页,查看源代码:

看看是否存在文件遍历的漏洞(如图片路径,再通过…/遍历文件)

是否使用了存在漏洞的框架(如果没有现成的就自己挖)

02、漏洞扫描

1、主机扫描

Nessus

经典主机漏扫工具,看看有没有CVE漏洞:

2、Web扫描

AWVS(Acunetix | Website Security Scanner)扫描器

PS:扫描器可能会对网站构成伤害,小心谨慎使用。

03、渗透测试

1、弱口令漏洞

漏洞描述

目标网站管理入口(或数据库等组件的外部连接)使用了容易被猜测的简单字符口令、或者是默认系统账号口令。

渗透测试

① 如果不存在验证码,则直接使用相对应的弱口令字典使用burpsuite 进行爆破

② 如果存在验证码,则看验证码是否存在绕过、以及看验证码是否容易识别

风险评级:高风险

安全建议

① 默认口令以及修改口令都应保证复杂度,比如:大小写字母与数字或特殊字符的组合,口令长度不小于8位等

② 定期检查和更换网站管理口令

2、文件下载(目录浏览)漏洞

漏洞描述

一些网站由于业务需求,可能提供文件查看或下载的功能,如果对用户查看或下载的文件不做限制,则恶意用户就能够查看或下载任意的文件,可以是源代码文件、敏感文件等。

渗透测试

① 查找可能存在文件包含的漏洞点,比如js,css等页面代码路径

② 看看有没有文件上传访问的功能

③ 采用…/来测试能否夸目录访问文件

风险评级:高风险

安全建议

① 采用白名单机制限制服务器目录的访问,以及可以访问的文件类型(小心被绕过)

② 过滤【./】等特殊字符

③ 采用文件流的访问返回上传文件(如用户头像),不要通过真实的网站路径。

示例:tomcat,默认关闭路径浏览的功能:

param-namelistings/param-name

param-valuefalse/param-value

3、任意文件上传漏洞

漏洞描述

目标网站允许用户向网站直接上传文件,但未对所上传文件的类型和内容进行严格的过滤。

渗透测试

① 收集网站信息,判断使用的语言(PHP,ASP,JSP)

② 过滤规则绕过方法:文件上传绕过技巧

风险评级:高风险

安全建议

① 对上传文件做有效文件类型判断,采用白名单控制的方法,开放只允许上传的文件型式云服务器渗透测试工具

② 文件类型判断,应对上传文件的后缀、文件头、图片类的预览图等做检测来判断文件类型,同时注意重命名(Md5加密)上传文件的文件名避免攻击者利用WEB服务的缺陷构造畸形文件名实现攻击目的;

③ 禁止上传目录有执行权限;

④ 使用随机数改写文件名和文件路径,使得用户不能轻易访问自己上传的文件。

4、命令注入漏洞

漏洞描述

目标网站未对用户输入的字符进行特殊字符过滤或合法性校验,允许用户输入特殊语句,导致各种调用系统命令的web应用,会被攻击者通过命令拼接、绕过黑名单等方式,在服务端运行恶意的系统命令。

渗透测试

风险评级:高风险

安全建议

① 拒绝使用拼接语句的方式进行参数传递;

② 尽量使用白名单的方式(首选方式);

③ 过滤危险方法、特殊字符,如:【|】【】【;】【’】【"】等

5、SQL注入漏洞

漏洞描述

目标网站未对用户输入的字符进行特殊字符过滤或合法性校验,允许用户输入特殊语句查询后台数据库相关信息

渗透测试

① 手动测试:判断是否存在SQL注入,判断是字符型还是数字型,是否需要盲注

② 工具测试:使用sqlmap等工具进行辅助测试

风险评级:高风险

安全建议

① 防范SQL注入攻击的最佳方式就是将查询的逻辑与其数据分隔,如Java的预处理,PHP的PDO

② 拒绝使用拼接SQL的方式

6、跨站脚本漏洞

漏洞描述

当应用程序的网页中包含不受信任的、未经恰当验证或转义的数据时,或者使用可以创建 HTML或JavaScript 的浏览器 API 更新现有的网页时,就会出现 XSS 缺陷。XSS 让攻击者能够在受害者的浏览器中执行脚本,并劫持用户会话、破坏网站或将用户重定向到恶意站点。

三种XSS漏洞:

① 存储型:用户输入的信息被持久化,并能够在页面显示的功能,都可能存在存储型XSS,例如用户留言、个人信息修改等。

② 反射型:URL参数需要在页面显示的功能都可能存在反射型跨站脚本攻击,例如站内搜索、查询功能。

③ DOM型:涉及DOM对象的页面程序,包括:document.URL、document.location、document.referrer、window.location等

渗透测试

存储型,反射型,DOM型

风险评级:高风险

安全建议

① 不信任用户提交的任何内容,对用户输入的内容,在后台都需要进行长度检查,并且对【】【】【"】【’】【】等字符做过滤

② 任何内容返回到页面显示之前都必须加以html编码,即将【】【】【"】【’】【】进行转义。

7、跨站请求伪造漏洞

漏洞描述

CSRF,全称为Cross-Site Request Forgery,跨站请求伪造,是一种网络攻击方式,它可以在用户毫不知情的情况下,以用户的名义伪造请求发送给被攻击站点,从而在未授权的情况下进行权限保护内的操作,如修改密码,转账等。

渗透测试

风险评级:中风险(如果相关业务极其重要,则为高风险)

安全建议

① 使用一次性令牌:用户登录后产生随机token并赋值给页面中的某个Hidden标签,提交表单时候,同时提交这个Hidden标签并验证,验证后重新产生新的token,并赋值给hidden标签;

② 适当场景添加验证码输入:每次的用户提交都需要用户在表单中填写一个图片上的随机字符串;

③ 请求头Referer效验,url请求是否前部匹配Http(s)😕/ServerHost

④ 关键信息输入确认提交信息的用户身份是否合法,比如修改密码一定要提供原密码输入

⑤ 用户自身可以通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie;

8、内部后台地址暴露

漏洞描述

一些仅被内部访问的地址,对外部暴露了,如:管理员登陆页面;系统监控页面;API接口描述页面等,这些会导致信息泄露,后台登陆等地址还可能被爆破。

渗透测试

① 通过常用的地址进行探测,如login.html,manager.html,api.html等;

② 可以借用burpsuite和常规页面地址字典,进行扫描探测

风险评级:中风险

安全建议

① 禁止外网访问后台地址

② 使用非常规路径(如对md5加密)

9、信息泄露漏洞

漏洞描述

① 备份信息泄露:目标网站未及时删除编辑器或者人员在编辑文件时,产生的临时文件,或者相关备份信息未及时删除导致信息泄露。

② 测试页面信息泄露:测试界面未及时删除,导致测试界面暴露,被云服务器渗透测试工具他人访问。

③ 源码信息泄露:目标网站文件访问控制设置不当,WEB服务器开启源码下载功能,允许用户访问网站源码。

④ 错误信息泄露:目标网站WEB程序和服务器未屏蔽错误信息回显,页面含有CGI处理错误的代码级别的详细信息,例如SQL语句执行错误原因,PHP的错误行数等。

⑤ 接口信息泄露:目标网站接口访问控制不严,导致网站内部敏感信息泄露。

渗透测试

① 备份信息泄露、测试页面信息泄露、源码信息泄露,测试方法:使用字典,爆破相关目录,看是否存在相关敏感文件

② 错误信息泄露,测试方法:发送畸形的数据报文、非正常的报文进行探测,看是否对错误参数处理妥当。

③ 接口信息泄露漏洞,测试方法:使用爬虫或者扫描器爬取获取接口相关信息,看目标网站对接口权限是否合理

风险评级:一般为中风险,如果源码大量泄漏或大量客户敏感信息泄露。

安全建议

① 备份信息泄露漏洞:删除相关备份信息,做好权限控制

② 测试页面信息泄露漏洞:删除相关测试界面,做好权限控制

③ 源码信息泄露漏洞:做好权限控制

④ 错误信息泄露漏洞:将错误信息对用户透明化,在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因

⑤ 接口信息泄露漏洞:对接口访问权限严格控制

10、失效的身份认证

漏洞描述

通常,通过错误使用应用程序的身份认证和会话管理功能,攻击者能够破译密码、密钥或会话令牌, 或者利用其它开发缺陷来暂时性或永久性冒充其云服务器渗透测试工具他用户的身份。

渗透测试

① 在登陆前后观察,前端提交信息中,随机变化的数据,总有与当前已登陆用户进行绑定的会话唯一标识,常见如cookie

② 一般现在网站没有那种简单可破解的标识,但是如果是跨站认证,单点登录场景中,可能为了开发方便而简化了身份认证

风险评级:高风险

安全建议

① 使用强身份识别,不使用简单弱加密方式进行身份识别;

② 服务器端使用安全的会话管理器,在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中,可以安全地存储,在登出、闲置超时后使其失效。

11、失效的访问控制

漏洞描述

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据,例如:访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

渗透测试

① 登入后,通过burpsuite 抓取相关url 链接,获取到url 链接之后,在另一个浏览器打开相关链接,看能够通过另一个未登入的浏览器直接访问该功能点。

② 使用A用户登陆,然后在另一个浏览器使用B用户登陆,使用B访问A独有的功能,看能否访问。

风险评级:高风险

安全建议

① 除公有资源外,默认情况下拒绝访问非本人所有的私有资源;

② 对API和控制器的访问进行速率限制,以最大限度地降低自动化攻击工具的危害;

③ 当用户注销后,服务器上的Cookie,JWT等令牌应失效;

④ 对每一个业务请求,都进行权限校验。

12、安全配置错误

漏洞描述

应用程序缺少适当的安全加固,或者云服务的权限配置错误。

① 应用程序启用或安装了不必要的功能(例如:不必要的端口、服务、网页、帐户或权限)。

② 默认帐户的密码仍然可用且没有更改。

③ 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。

④ 对于更新的系统,禁用或不安全地配置最新的安全功能。

⑤ 应用程序服务器、应用程序框架(如:Struts、Spring、ASP.NET)、库文件、数据库等没有进行相关安全配置。

渗透测试

先对应用指纹等进行信息搜集,然后针对搜集的信息,看相关应用默认配置是否有更改,是否有加固过;端口开放情况,是否开放了多余的端口;

风险评级:中风险

安全建议

搭建最小化平台,该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。在所有环境中按照标准的加固流程进行正确安全配置。

13、使用含有已知漏洞的组件

漏洞描述

使用了不再支持或者过时的组件。这包括:OS、Web服务器、应用程序服务器、数据库管理系统(DBMS)、应用程序、API和所有的组件、运行环境和库。

渗透测试

① 根据前期信息搜集的信息,查看相关组件的版本,看是否使用了不在支持或者过时的组件。一般来说,信息搜集,可通过http返回头、相关错误信息、应用指纹、端口探测(Nmap)等手段搜集。

② Nmap等工具也可以用于获取操作系统版本信息

③ 通过CVE,CNVD等平台可以获取当前组件版本是否存在漏洞

风险评级:按照存在漏洞的组件的安全风险值判定当前风险。

安全建议

① 移除不使用的依赖、不需要的功能、组件、文件和文档;

② 仅从官方渠道安全的获取组件(尽量保证是最新版本),并使用签名机制来降低组件被篡改或加入恶意漏洞的风险;

③ 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁,可以考虑部署虚拟补丁来监控、检测或保护。

详细学习可参考:

Linux运维人员必知必会工具汇总

领域 :工具名称

操作系统 :CentOS、Ubuntu、Redhat、suse、Freebsd

网站服务: nginx、apache、lighttpd、php、tomcat、resin

数据库: MySQL、MariaDB、PostgreSQL

DB中间件 :maxscale、MyCat、atlas、cobar、amoeba、MySQL-proxy

代理相关: lvs、keepalived、haproxy、nginx、heartbeat

网站缓存: squid、nginx、varnish

NoSQL库: Redis、CacheCloud、Memcached、MongoDB、HBase、Cassandra、CouchDB

存储相关 :Nfs、FastDFS、Moosefs(mfs)、Ceph 、Hadoop、glusterfs、lustre

版本管理 :svn、git、gitlab、gogs

监控报警 :nagios、cacti、zabbix、munin、hyperic、mrtg、graphite

域名解析: bind、powerdns、dnsmasq

同步软件: scp、rsync、inotify、sersync、drbd

批量管理: SSH、Ansible、Saltstack、expect、puppet

虚拟化: kvm、xen

云计算: openstack、docker、k8s

内网软件: iptables、zebra、iftraf、ntop、tc、iftop

邮件软件: qmail、posfix、sendmail、zimbra

远程拨号: openvpn、pptp、openswan、ipip

统一认证: openldap

队列工具: ActiveMQ、RabbitMQ、Metaq、MemcacheQ、Zeromq、kafka

打包发布: mvn、ants、Jenkins、Walle

测试软件: ab、JMeter、Webbench、LoadRunner、http_load、tcpcopy

带宽测试 :smokeping

性能测试 ;dd、 fio(IOPS测试)、iozone(磁盘测试)

日志相关: rsyslog、Awstats、flume、storm、ELK(Elasticsearch+Logstash+Kibana)

搜索软件: Sphinx、Xapian、Solr

无人值守: rpm、yum(设计rpm包定制及yum仓库构建)

大数据: HDFS、Hive、Hbase、Zookeeper、Pig、Spark、Mahout、flume、sqoop

项目管理: Jira、Redmine

linux管理: 宝塔Linux面板

渗透测试工具: SQLMap、Webscan

开源邮箱: iRedmail、extmail、Zimbra

软件开发 :Sublime Text、Eclipse、Jetbrains

远程连接: putty、Xshell、SecureCRT、MobaXterm、TeamViewer、向日葵

在此为服务器运维人员推荐使用:宝塔面板

宝塔面板,近200个免费应用提供使用,如:网站管理、系统安全、系统监控、计划任务、文件管理、软件管理、一键部署等为服务器运维人员提供安全高效的完成服务器运维工作。

原文链接:,转发请注明来源!
「阿里云渗透测试_云服务器渗透测试工具」评论列表
仿站
仿站
发布于 2022-12-24 14:33:28  回复
点或者在浏览器会话结束后清理浏览器的cookie;8、内部后台地址暴露漏洞描述一些仅被内部访问的地址,对外部暴露了,如:管理员登陆页面;系统监控页面;API接口描述页面等,这些会导致信息泄露,后台登陆等地址还可能被爆破。渗透测试① 通过常用的地址进行探测,如login.html,man

发表评论