Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

src/pentesting-cloud/kubernetes-security/kubernetes-network-attacks.md

@@ -4,16 +4,16 @@
 
 ## Introduction
 
-Kubernetes में, यह देखा गया है कि एक डिफ़ॉल्ट व्यवहार **सभी कंटेनरों के बीच कनेक्शन स्थापित करने की अनुमति देता है जो एक ही नोड पर स्थित हैं**। यह नामस्थान भिन्नताओं की परवाह किए बिना लागू होता है। इस प्रकार की कनेक्टिविटी **लेयर 2** (ईथरनेट) तक फैली हुई है। नतीजतन, यह कॉन्फ़िगरेशन संभावित रूप से सिस्टम को कमजोरियों के प्रति उजागर करता है। विशेष रूप से, यह एक **दुष्ट कंटेनर** के लिए **ARP स्पूफिंग अटैक** को अन्य कंटेनरों के खिलाफ निष्पादित करने की संभावना खोलता है जो उसी नोड पर स्थित हैं। ऐसे हमले के दौरान, दुष्ट कंटेनर धोखे से अन्य कंटेनरों के लिए निर्धारित नेटवर्क ट्रैफ़िक को इंटरसेप्ट या संशोधित कर सकता है।
+Kubernetes में, यह देखा गया है कि एक डिफ़ॉल्ट व्यवहार **समान नोड पर निवास करने वाले सभी कंटेनरों** के बीच कनेक्शन स्थापित करने की अनुमति देता है। यह नामस्थान भिन्नताओं की परवाह किए बिना लागू होता है। ऐसी कनेक्टिविटी **लेयर 2** (Ethernet) तक फैली हुई है। परिणामस्वरूप, यह कॉन्फ़िगरेशन प्रणाली को कमजोरियों के लिए संभावित रूप से उजागर करता है। विशेष रूप से, यह एक **दुष्ट कंटेनर** के लिए एक **ARP स्पूफिंग हमले** को अन्य कंटेनरों के खिलाफ निष्पादित करने की संभावना खोलता है जो समान नोड पर स्थित हैं। ऐसे हमले के दौरान, दुष्ट कंटेनर धोखे से अन्य कंटेनरों के लिए लक्षित नेटवर्क ट्रैफ़िक को इंटरसेप्ट या संशोधित कर सकता है।
 
-ARP स्पूफिंग हमलों में **हमलावर द्वारा स्थानीय क्षेत्र नेटवर्क पर गलत ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) संदेश भेजना शामिल है। इसके परिणामस्वरूप **हमलावर के MAC पते को नेटवर्क पर एक वैध कंप्यूटर या सर्वर के IP पते के साथ जोड़ा जाता है**। ऐसे हमले के सफल निष्पादन के बाद, हमलावर डेटा को इंटरसेप्ट, संशोधित या यहां तक कि ट्रांजिट में रोक सकता है। यह हमला OSI मॉडल की लेयर 2 पर निष्पादित होता है, यही कारण है कि Kubernetes में इस स्तर पर डिफ़ॉल्ट कनेक्टिविटी सुरक्षा चिंताओं को बढ़ाती है।
+ARP स्पूफिंग हमलों में **हमलावर द्वारा स्थानीय क्षेत्र नेटवर्क पर गलत ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) संदेश भेजना शामिल है। इसके परिणामस्वरूप **हमलावर के MAC पते को नेटवर्क पर एक वैध कंप्यूटर या सर्वर के IP पते के साथ जोड़ा जाता है**। ऐसे हमले के सफल निष्पादन के बाद, हमलावर डेटा को इंटरसेप्ट, संशोधित या यहां तक कि ट्रांजिट में रोक सकता है। यह हमला OSI मॉडल की लेयर 2 पर निष्पादित होता है, यही कारण है कि Kubernetes में इस लेयर पर डिफ़ॉल्ट कनेक्टिविटी सुरक्षा चिंताओं को उठाती है।
 
-परिदृश्य में 4 मशीनें बनाई जाने वाली हैं:
+परिदृश्य में 4 मशीनें बनाई जाएंगी:
 
-- ubuntu-pe: नोड पर भागने और मैट्रिक्स की जांच करने के लिए विशेषाधिकार प्राप्त मशीन (हमले के लिए आवश्यक नहीं)
+- ubuntu-pe: नोड पर भागने और मेट्रिक्स की जांच करने के लिए विशेषाधिकार प्राप्त मशीन (हमले के लिए आवश्यक नहीं)
 - **ubuntu-attack**: **दुष्ट** कंटेनर डिफ़ॉल्ट नामस्थान में
-- **ubuntu-victim**: **शिकार** मशीन kube-system नामस्थान में
-- **mysql**: **शिकार** मशीन डिफ़ॉल्ट नामस्थान में
+- **ubuntu-victim**: **पीड़ित** मशीन kube-system नामस्थान में
+- **mysql**: **पीड़ित** मशीन डिफ़ॉल्ट नामस्थान में
 ```yaml
 echo 'apiVersion: v1
 kind: Pod
@@ -102,16 +102,16 @@ kubectl exec -it mysql bash -- bash -c "apt update; apt install -y net-tools; ba
 
 ### ARP
 
-सामान्यत: **नोड के अंदर पोड-से-पोड नेटवर्किंग** एक **ब्रिज** के माध्यम से उपलब्ध है जो सभी पोड्स को जोड़ता है। इस ब्रिज को “**cbr0**” कहा जाता है। (कुछ नेटवर्क प्लगइन्स अपने स्वयं के ब्रिज को स्थापित करेंगे।) **cbr0 ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) समाधान को भी संभाल सकता है। जब एक इनकमिंग पैकेट cbr0 पर आता है, तो यह ARP का उपयोग करके गंतव्य MAC पते को हल कर सकता है।
+सामान्यत: **नोड के अंदर पॉड-से-पॉड नेटवर्किंग** एक **ब्रिज** के माध्यम से उपलब्ध है जो सभी पॉड्स को जोड़ता है। इस ब्रिज को “**cbr0**” कहा जाता है। (कुछ नेटवर्क प्लगइन्स अपनी खुद की ब्रिज स्थापित करेंगे।) **cbr0 ARP** (एड्रेस रिज़ॉल्यूशन प्रोटोकॉल) समाधान को भी संभाल सकता है। जब एक इनकमिंग पैकेट cbr0 पर आता है, तो यह ARP का उपयोग करके गंतव्य MAC पते को हल कर सकता है।
 
-यह तथ्य यह संकेत करता है कि, डिफ़ॉल्ट रूप से, **एक ही नोड में चलने वाला हर पोड** किसी अन्य पोड के साथ **संवाद** करने में सक्षम होगा (नेमस्पेस के स्वतंत्र) एथरनेट स्तर (लेयर 2) पर।
+यह तथ्य यह संकेत करता है कि, डिफ़ॉल्ट रूप से, **एक ही नोड में चलने वाला हर पॉड** किसी अन्य पॉड के साथ **संवाद** करने में सक्षम होगा जो उसी नोड में है (नेमस्पेस के स्वतंत्र) एथरनेट स्तर (लेयर 2) पर।
 
 > [!WARNING]
-> इसलिए, एक ही नोड में पोड्स के बीच A**RP Spoofing हमले करना संभव है।**
+> इसलिए, एक ही नोड में पॉड्स के बीच A**RP Spoofing हमले करना संभव है।**
 
 ### DNS
 
-कुबेरनेट्स वातावरण में आप आमतौर पर 1 (या अधिक) **DNS सेवाएं चलती हुई पाएंगे** जो आमतौर पर kube-system नेमस्पेस में होती हैं:
+कुबरनेट्स वातावरण में आप आमतौर पर 1 (या अधिक) **DNS सेवाएं चलती हुई पाएंगे** जो आमतौर पर kube-system नेमस्पेस में होती हैं:
 ```bash
 kubectl -n kube-system describe services
 Name:              kube-dns
@@ -136,23 +136,23 @@ Port:              metrics  9153/TCP
 TargetPort:        9153/TCP
 Endpoints:         172.17.0.2:9153
 ```
-In the previous info you can see something interesting, the **IP of the service** is **10.96.0.10** but the **IP of the pod** running the service is **172.17.0.2.**
+पिछली जानकारी में आप कुछ दिलचस्प देख सकते हैं, **सेवा का IP** **10.96.0.10** है लेकिन **सेवा चला रहे पोड का IP** **172.17.0.2** है।
 
 यदि आप किसी भी पोड के अंदर DNS पते की जांच करते हैं, तो आपको कुछ ऐसा मिलेगा:
 ```
 cat /etc/resolv.conf
 nameserver 10.96.0.10
 ```
-हालांकि, **पॉड** को उस **पता** तक पहुँचने का तरीका **नहीं पता** है क्योंकि इस मामले में **पॉड रेंज** 172.17.0.10/26 है।
+हालांकि, **पॉड** को उस **पते** तक पहुँचने का तरीका **नहीं पता** है क्योंकि इस मामले में **पॉड रेंज** 172.17.0.10/26 है।
 
-इसलिए, **पॉड** **DNS अनुरोधों को 10.96.0.10 के पते पर** भेजेगा जिसे cbr0 द्वारा **172.17.0.2** में **अनुवादित** किया जाएगा।
+इसलिए, पॉड **10.96.0.10** के पते पर **DNS अनुरोध** भेजेगा जिसे cbr0 द्वारा **172.17.0.2** में **अनुवादित** किया जाएगा।
 
 > [!WARNING]
-> इसका मतलब है कि एक **पॉड का DNS अनुरोध** **हमेशा** **ब्रिज** की ओर जाएगा **सेवा IP को अंत बिंदु IP में अनुवादित** करने के लिए, भले ही DNS सर्वर पॉड के समान उपनेटवर्क में हो।
+> इसका मतलब है कि एक पॉड का **DNS अनुरोध** **हमेशा** **ब्रिज** की ओर जाएगा ताकि **सेवा IP को अंत बिंदु IP में अनुवादित** किया जा सके, भले ही DNS सर्वर पॉड के समान उपनेटवर्क में हो।
 >
-> यह जानकर, और यह जानकर कि **ARP हमले संभव हैं**, एक **पॉड** एक नोड में **उपनेटवर्क** में **प्रत्येक पॉड** और **ब्रिज** के बीच **ट्रैफ़िक को इंटरसेप्ट** करने में सक्षम होगा और DNS सर्वर से **DNS प्रतिक्रियाओं को संशोधित** करेगा (**DNS Spoofing**).
+> यह जानकर, और यह जानकर कि **ARP हमले संभव हैं**, एक **पॉड** एक नोड में **उपनेटवर्क** में **प्रत्येक पॉड** के बीच **ट्रैफ़िक को इंटरसेप्ट** करने में सक्षम होगा और **DNS सर्वर** से **DNS प्रतिक्रियाओं को संशोधित** करेगा (**DNS Spoofing**)।
 >
-> इसके अलावा, यदि **DNS सर्वर** **हमलावर के समान नोड में** है, तो हमलावर क्लस्टर में किसी भी पॉड के सभी DNS अनुरोधों को (DNS सर्वर और ब्रिज के बीच) **इंटरसेप्ट** कर सकता है और प्रतिक्रियाओं को संशोधित कर सकता है।
+> इसके अलावा, यदि **DNS सर्वर** **हमलावर के समान नोड में** है, तो हमलावर क्लस्टर में किसी भी पॉड के सभी **DNS अनुरोधों** को (DNS सर्वर और ब्रिज के बीच) **इंटरसेप्ट** कर सकता है और प्रतिक्रियाओं को संशोधित कर सकता है।
 
 ## समान नोड में पॉड्स में ARP Spoofing
 
@@ -233,11 +233,11 @@ arpspoof -t 172.17.0.9 172.17.0.10
 ```
 ## DNS Spoofing
 
-जैसा कि पहले ही उल्लेख किया गया है, यदि आप **DNS सर्वर पॉड** के उसी नोड में एक पॉड को **समझौता** करते हैं, तो आप **MitM** के साथ **ARPSpoofing** का उपयोग करके **ब्रिज** और **DNS** पॉड को **संशोधित** कर सकते हैं और **सभी DNS प्रतिक्रियाओं** को **बदल** सकते हैं।
+जैसा कि पहले ही उल्लेख किया गया है, यदि आप **DNS सर्वर पॉड** के उसी नोड में एक पॉड को **समझौता** करते हैं, तो आप **MitM** के साथ **ARPSpoofing** का उपयोग करके **ब्रिज और DNS** पॉड को **संशोधित** कर सकते हैं और **सभी DNS प्रतिक्रियाओं** को **बदल** सकते हैं।
 
 आपके पास इसे परीक्षण करने के लिए एक बहुत अच्छा **उपकरण** और **ट्यूटोरियल** है [**https://github.com/danielsagi/kube-dnsspoof/**](https://github.com/danielsagi/kube-dnsspoof/)
 
-हमारे परिदृश्य में, **हमलावर पॉड** में **उपकरण** को **डाउनलोड** करें और एक \*\*फाइल नाम `hosts` \*\* बनाएं जिसमें आप जिन **डोमेन** को **स्पूफ** करना चाहते हैं, उन्हें शामिल करें जैसे:
+हमारे परिदृश्य में, **हमलावर पॉड** में **उपकरण** को **डाउनलोड** करें और एक \*\*फाइल नाम `hosts` \*\* बनाएं जिसमें आप जिन **डोमेन** को **स्पूफ** करना चाहते हैं, जैसे:
 ```
 cat hosts
 google.com. 1.1.1.1
@@ -261,12 +261,12 @@ google.com.		1	IN	A	1.1.1.1
 ```
 > [!NOTE]
 > यदि आप अपना खुद का DNS स्पूफिंग स्क्रिप्ट बनाने की कोशिश करते हैं, यदि आप **बस DNS प्रतिक्रिया को संशोधित करते हैं** तो यह **काम नहीं करेगा**, क्योंकि **प्रतिक्रिया** में **src IP** **दुष्ट** **पॉड** का IP पता होगा और इसे **स्वीकृत** नहीं किया जाएगा।\
-> आपको **DNS** का **नया DNS पैकेट** उत्पन्न करने की आवश्यकता है जहां पीड़ित DNS अनुरोध भेजता है (जो कुछ ऐसा है जैसे 172.16.0.2, 10.96.0.10 नहीं, वह K8s DNS सेवा IP है और DNS सर्वर IP नहीं है, इसके बारे में अधिक जानकारी परिचय में है)।
+> आपको **नया DNS पैकेट** उत्पन्न करने की आवश्यकता है जिसमें **src IP** उस **DNS** का हो जहाँ पीड़ित DNS अनुरोध भेजता है (जो कुछ ऐसा है जैसे 172.16.0.2, न कि 10.96.0.10, यह K8s DNS सेवा का IP है और न कि DNS सर्वर का IP, इसके बारे में अधिक जानकारी परिचय में है)।
 
 ## ट्रैफ़िक कैप्चर करना
 
-उपकरण [**Mizu**](https://github.com/up9inc/mizu) एक सरल लेकिन शक्तिशाली API **ट्रैफ़िक व्यूअर है जो Kubernetes** के लिए है, जो आपको **सूक्ष्म सेवाओं के बीच सभी API संचार** को **देखने** में सक्षम बनाता है ताकि आप अपने डिबग और समस्या निवारण में मदद कर सकें।\
-यह चयनित पॉड में एजेंट स्थापित करेगा और उनके ट्रैफ़िक की जानकारी एकत्र करेगा और आपको एक वेब सर्वर में दिखाएगा। हालांकि, इसके लिए आपको उच्च K8s अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।
+उपकरण [**Mizu**](https://github.com/up9inc/mizu) एक सरल लेकिन शक्तिशाली API **ट्रैफ़िक व्यूअर है जो Kubernetes के लिए** आपको **सूक्ष्म सेवाओं के बीच सभी API संचार** देखने में सक्षम बनाता है ताकि आप अपने डिबग और समस्या निवारण में मदद कर सकें।\
+यह चयनित पॉड में एजेंट स्थापित करेगा और उनके ट्रैफ़िक की जानकारी एक वेब सर्वर में दिखाएगा। हालाँकि, इसके लिए आपको उच्च K8s अनुमतियों की आवश्यकता होगी (और यह बहुत छिपा हुआ नहीं है)।
 
 ## संदर्भ