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 स्वरूपित फ़ाइलें आउटपुट होंगी।

1. सादे पाठ के अतिरिक्त .json फ़ाइलें आउटपुट करें: export DECKER_OUTPUTS_JSON="true"
2. सादे पाठ के अतिरिक्त .xml फ़ाइलें आउटपुट करें: export DECKER_OUTPUTS_XML="true"

डेकर नाम क्यों?

मेरे दोस्त Courtney ने मेरी मदद की जब मैं एक नाम सोचने में संघर्ष कर रहा था और decker एक SciFi शब्द शब्दकोश में मिला... और यह अच्छा लगा।

एक भविष्य का क्रैकर; एक सॉफ्टवेयर विशेषज्ञ जो साइबरस्पेस में हेरफेर करने में कुशल है, विशेष रूप से सुरक्षा सावधानियों को दरकिनार करने में।

डॉकर के साथ एक उदाहरण कॉन्फ़िग चलाना

दो वॉल्यूम माउंट किए जाते हैं:

1. decker-reports नामक निर्देशिका जहाँ decker प्रत्येक निष्पादित प्लगइन के लिए एक फ़ाइल आउटपुट करेगा। फ़ाइल का नाम {unique_resource_name}.report.txt होगा।
2. examples निर्देशिका जिसमें decker कॉन्फ़िग फ़ाइलें हैं। इस वॉल्यूम को माउंट करने से आप अपने पसंदीदा संपादक का उपयोग करके स्थानीय रूप से कॉन्फ़िग लिख सकते हैं और फिर भी उन्हें कंटेनर में चला सकते हैं।

एक पर्यावरण चर पारित किया जाता है:

1. 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 में देखें।

डॉकर के बिना एक उदाहरण कॉन्फ़िग चलाना

आप संभवतः DECKER_REPORTS_DIR पर्यावरण चर के साथ decker द्वारा रिपोर्ट लिखने की निर्देशिका सेट करना चाहेंगे।

कुछ इस तरह उपयुक्त होगा। बस सुनिश्चित करें कि आप जो भी सेट करते हैं वह एक मौजूदा निर्देशिका है।

export DECKER_REPORTS_DIR="$HOME/decker-reports"

यदि आप उदाहरण कॉन्फ़िग फ़ाइलों में से एक चला रहे हैं तो आपको एक लक्ष्य होस्ट भी सेट करना होगा।

export DECKER_TARGET_HOST="<insert hostname here>"

फिर बस एक कॉन्फ़िग फ़ाइल चलाएँ। इस रेपो की रूट निर्देशिका में जाएँ और चलाएँ:

./decker ./examples/example.hcl

योगदान

योगदान का स्वागत और सराहना की जाती है। दिशानिर्देशों के लिए docs/contributions.md देखें।

विकास

विकास के लिए डॉकर का उपयोग करना एक सहज अनुभव के लिए अनुशंसित है। यह सुनिश्चित करता है कि सभी निर्भरताएँ स्थापित और उपयोग के लिए तैयार होंगी।

गो कोड के अवलोकन के लिए नीचे निर्देशिका संरचना देखें।

त्वरित आरंभ

1. (होस्ट मशीन पर): make docker_build
2. (होस्ट मशीन पर): make docker_run (डॉकर कंटेनर शुरू करेगा और एक इंटरैक्टिव बैश सत्र खोलेगा)
3. (कंटेनर के अंदर): dep ensure -v
4. (कंटेनर के अंदर): make build_all
5. (कंटेनर के अंदर): make run

गिट हुक आरंभ करें

प्रत्येक कमिट पर linting और परीक्षण चलाने वाला pre-commit स्क्रिप्ट जोड़ने के लिए make init चलाएँ।

प्लगइन विकास

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"

.so फ़ाइल के बगल में <decker binary>/internal/app/decker/plugins/<plugin name>/<plugin name>.hcl पर एक HCL फ़ाइल होनी चाहिए जो इसके इनपुट और आउटपुट को परिभाषित करती है। वर्तमान में, केवल 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 ड्राइवर है। इसका काम दिए गए config file को पार्स करना, फ़ाइल के resource ब्लॉकों के आधार पर उपयुक्त प्लगइन्स लोड करना, और निर्दिष्ट इनपुट के साथ प्लगइन्स चलाना है।
• examples में decker के साथ शुरू करने के लिए कुछ उदाहरण कॉन्फ़िगरेशन हैं। यदि आप kali docker image (stevenaldinger/decker:kali) का उपयोग करते हैं, तो सभी कॉन्फ़िग फ़ाइलों के लिए सभी निर्भरताएँ स्थापित होनी चाहिए और चीजें सुचारू रूप से चलनी चाहिए।
• internal/pkg अधिकांश वास्तविक कोड का स्थान है। इसमें main.go द्वारा आयात किए गए सभी पैकेज शामिल हैं।
  • dependencies प्लगइन निर्भरता ग्राफ़ बनाने और एक टोपोलॉजिकल रूप से क्रमबद्ध सरणी लौटाने के लिए जिम्मेदार है जो सुनिश्चित करता है कि प्लगइन्स काम करने के क्रम में चलें।
  • gocty go-cty मानों को एन्कोड और डिकोड करने के लिए हेल्पर्स प्रदान करता है जिनका उपयोग गतिशील इनपुट प्रकारों को संभालने के लिए किया जाता है।
  • hcl HCL फ़ाइलों को पार्स करने के लिए जिम्मेदार है, जिसमें मूल्यांकन संदर्भ बनाना शामिल है जो ब्लॉकों को अन्य प्लगइन ब्लॉकों पर निर्भर होने पर ठीक से डीकोड करने देता है।
  • paths decker बाइनरी, कॉन्फ़िग फ़ाइलों, प्लगइन कॉन्फ़िग फ़ाइलों और उत्पन्न रिपोर्टों के लिए फ़ाइल पथ लौटाने के लिए जिम्मेदार है।