Decker - 渗透测试编排框架

目的

Decker 是一个渗透测试编排框架。它利用 HashiCorp Configuration Language 2（与 Terraform 相同的配置语言）来实现声明式的 渗透测试即代码，让你的测试可以被版本化、共享、重用，并与团队或社区协作。

decker 配置文件示例：

// variables are pulled from environment
//   ex: DECKER_TARGET_HOST
// they will be available throughout the config files as var.*
//   ex: ${var.target_host}
variable "target_host" {
  type = "string"
}

// resources refer to plugins
// resources need unique names so plugins can be used more than once
// they are declared with the form: 'resource "plugin_name" "unique_name" {}'
// their outputs will be available to others using the form unique_name.*
//   ex: nmap.443
resource "nmap" "nmap" {
  host = "${var.target_host}"
  plugin_enabled = "true"
}
resource "sslscan" "sslscan" {
  host = "${var.target_host}"
  plugin_enabled = "${nmap.443 == "open"}"
}

对列表中的每个项运行插件：

variable "target_host" {
  type = "string"
}
resource "nslookup" "nslookup" {
  dns_server = "8.8.4.4"
  host = "${var.target_host}"
}
resource "metasploit" "metasploit" {
  for_each = "${nslookup.ip_address}"
  exploit = "auxiliary/scanner/portscan/tcp"
  options = {
    RHOSTS = "${each.key}/32"
    INTERFACE = "eth0"
  }
}

结合 for_each 与嵌套值的复杂配置：

variable "target_host" {
  type = "string"
}
resource "nslookup" "nslookup" {
  dns_server = "8.8.4.4"
  host = "${var.target_host}"
}
resource "nmap" "nmap" {
  for_each = "${nslookup.ip_address}"
  host = "${each.key}"
}
// for each IP, check if nmap found port 25 open.
// if yes, run metasploit's smtp_enum scanner
resource "metasploit" "metasploit" {
  for_each = "${nslookup.ip_address}"
  exploit = "auxiliary/scanner/smtp/smtp_enum"
  options = {
    RHOSTS = "${each.key}"
  }
  plugin_enabled = "${nmap["${each.key}"].25 == "open"}"
}

输出格式

提供多种输出格式，可以同时选择多种。

将 DECKER_OUTPUTS_JSON 或 DECKER_OUTPUTS_XML 设置为 "true" 将分别输出 json 和 xml 格式的文件。

在纯文本之外输出 .json 文件：export DECKER_OUTPUTS_JSON="true"
在纯文本之外输出 .xml 文件：export DECKER_OUTPUTS_XML="true"

为什么叫 decker？

当我苦于想不出名字时，我的朋友 Courtney 施以援手，在 SciFi 词汇表中找到了 decker... 而且听起来很酷。

未来的破解者；一名擅长操纵赛博空间的软件专家，尤其擅长规避安全防护。

使用 Docker 运行示例配置

挂载两个卷：

名为 decker-reports 的目录，decker 会在其中为每个执行的插件输出一个文件。文件名为 {unique_resource_name}.report.txt。
examples 目录，包含 decker 配置文件。挂载此卷允许你用喜欢的编辑器在本地编写配置，然后在容器内运行。

传入一个环境变量：

DECKER_TARGET_HOST

配置文件中通过 {var.target_host} 引用它。Decker 会遍历所有名为 DECKER_* 的环境变量，去掉前缀，并将剩余部分转为小写。

docker run -it --rm \
  -v "$(pwd)/decker-reports/":/tmp/reports/ \
  -v "$(pwd)/examples/":/decker-config/ \
  -e DECKER_TARGET_HOST=example.com \
 stevenaldinger/decker:kali decker ./decker-config/example.hcl

当 decker 运行完配置后，查看 ./decker-reports 中的输出。

无需 Docker 运行示例配置

你可能需要设置 decker 写入报告的目录，通过 DECKER_REPORTS_DIR 环境变量。

类似下面这样即可。确保你设置的目录已存在。

export DECKER_REPORTS_DIR="$HOME/decker-reports"

如果你要运行某个示例配置文件，还需要设置目标主机。

export DECKER_TARGET_HOST="<insert hostname here>"

然后直接运行配置文件。切换到本仓库的根目录，运行：

./decker ./examples/example.hcl

贡献

非常欢迎并感激任何贡献。请参阅 docs/contributions.md 了解指南。

开发

建议使用 Docker 进行开发，以获得流畅的体验。这样可以确保所有依赖项都已安装并可用。

请参考下面的 目录结构 了解 Go 代码的概览。

快速开始

（在宿主机上）：make docker_build
（在宿主机上）：make docker_run（将启动 Docker 容器并打开交互式 bash 会话）
（在容器内）：dep ensure -v
（在容器内）：make build_all
（在容器内）：make run

初始化 Git 钩子

运行 make init 添加一个 pre-commit 脚本，该脚本会在每次提交时运行 linting 和测试。

插件开发

Decker 本身只是一个框架，它读取配置文件，确定配置文件中的依赖关系，并按顺序运行插件，确保依赖于其他插件输出（一个插件的输出作为另一个插件的输入）的插件在其依赖的插件之后运行。

decker 的真正威力来自插件。开发一个插件可以简单也可以复杂，只要最终结果是包含编译后插件代码的 .so 文件，以及同一目录下的 .hcl 文件，其中声明了插件期望用户配置的输入。

请查看 docs/building_plugins.md 开始你的第一个插件。只需几分钟，你就可以让一个 “Hello World” decker 插件运行起来。

安装插件

默认情况下，插件应位于相对于 decker 二进制文件目录的 <decker binary>/internal/app/decker/plugins/<plugin name>/<plugin name>.so。可以通过设置 DECKER_PLUGIN_DIRS 环境变量添加额外路径。即使设置了 DECKER_PLUGIN_DIRS，默认插件路径仍然有效。

示例：export DECKER_PLUGIN_DIRS="/path/to/my/plugins:/additional/path/to/plugins"

在 <decker binary>/internal/app/decker/plugins/<plugin name>/<plugin name>.hcl 中应有一个 HCL 文件，与 .so 文件放在一起，定义其输入和输出。目前只支持 string、list 和 map 类型的输入。每个输入应有一个类似下面的 input 块：

input "my_input" {
  type = "string"
  default = "some default value"
}

目录结构

.
├── build
│   ├── ci/
│   └── package/
├── cmd
│   ├── decker
│   │   └── main.go
│   └── README.md
├── deployments/
├── docs/
├── examples
│   └── example.hcl
├── githooks
│   ├── pre-commit
├── Gopkg.toml
├── internal
│   ├── app
│   │   └── decker
│   │       └── plugins
│   │           ├── a2sv
│   │           │   ├── a2sv.hcl
│   │           │   ├── main.go
│   │           │   └── README.md
│   │           └── ...
│   │               ├── main.go
│   │               ├── README.md
│   │               └── xxx.hcl
│   ├── pkg
│   │   ├── dependencies/
│   │   ├── gocty/
│   │   ├── hcl/
│   │   ├── paths/
│   │   ├── plugins/
│   │   └── reports/
│   └── README.md
├── LICENSE
├── Makefile
├── README.md
└── scripts
    ├── build-plugins.sh
    └── README.md

cmd/decker/main.go 是驱动程序。它的任务是解析给定的配置文件，根据文件中的 resource 块加载相应的插件，并用指定的输入运行插件。
examples 包含几个示例配置，帮助你上手 decker。如果你使用 kali Docker 镜像（stevenaldinger/decker:kali），所有配置文件的依赖项都应已安装，一切应能顺利运行。
internal/pkg 存放了大部分实际代码。它包含了 main.go 导入的所有包。
- dependencies 负责构建插件依赖图，并返回一个拓扑排序的数组，确保插件按正确的顺序运行。
- gocty 提供编码和解码 go-cty 值的帮助函数，这些值用于处理动态输入类型。
- hcl 负责解析 HCL 文件，包括创建求值上下文，使块在依赖其他插件块时能够正确解码。
- paths 负责返回 decker 二进制文件、配置文件、插件配置文件和生成报告的路径。
- plugins 负责判断插件是否启用并运行它们。
- reports 负责将报告写入文件系统。
internal/app/decker/plugins 是模块化代码片段，以形式编写，实现了一个简单接口，允许在运行时加载和调用，其输入和输出在插件的配置文件中指定（也是 HCL 格式）。示例可见。

decker

最受欢迎