Translated ['', 'src/pentesting-cloud/aws-security/aws-services/aws-ec2-

src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md

@@ -2,184 +2,184 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## AWS Networking in a Nutshell
+## AWS नेटवर्किंग का सारांश
 
-A **VPC** contains a **network CIDR** like 10.0.0.0/16 (with its **routing table** and **network ACL**).
+A **VPC** में एक **network CIDR** होता है जैसे 10.0.0.0/16 (जिसके साथ उसका **routing table** और **network ACL**).
 
-This VPC network is divided in **subnetworks**, so a **subnetwork** is directly **related** with the **VPC**, **routing** **table** and **network ACL**.
+यह VPC नेटवर्क **subnetworks** में बाँटा जाता है, इसलिए एक **subnetwork** सीधे **VPC**, **routing table** और **network ACL** से संबंधित होता है।
 
-Then, **Network Interface**s attached to services (like EC2 instances) are **connected** to the **subnetworks** with **security group(s)**.
+फिर, सेवाओं (जैसे EC2 instances) से जुड़े **Network Interface**s उन **subnetworks** से **connected** होते हैं और उन पर **security group(s)** लागू होते हैं।
 
-Therefore, a **security group** will limit the exposed ports of the network **interfaces using it**, **independently of the subnetwork**. And a **network ACL** will **limit** the exposed ports to to the **whole network**.
+इसलिए, एक **security group** उन नेटवर्क **interfaces using it** के खुले हुए पोर्टों को सीमित करेगा, **subnetwork** से स्वतंत्र रूप से। और एक **network ACL** पूरे नेटवर्क के लिए खुले हुए पोर्टों को **सीमित** करेगा।
 
-Moreover, in order to **access Internet**, there are some interesting configurations to check:
+इसके अलावा, Internet तक पहुँचने के लिए कुछ महत्वपूर्ण कॉन्फ़िगरेशन हैं जिन्हें चेक करना चाहिए:
 
-- A **subnetwork** can **auto-assign public IPv4 addresses**
-- An **instance** created in the network that **auto-assign IPv4 addresses can get one**
-- An **Internet gateway** need to be **attached** to the **VPC**
-- You could also use **Egress-only internet gateways**
-- You could also have a **NAT gateway** in a **private subnet** so it's possible to **connect to external services** from that private subnet, but it's **not possible to reach them from the outside**.
-- The NAT gateway can be **public** (access to the internet) or **private** (access to other VPCs)
+- एक **subnetwork** सार्वजनिक IPv4 पते **auto-assign** कर सकता है
+- नेटवर्क में बनाया गया एक **instance** जो **auto-assign IPv4 addresses** सक्षम करता है, उसे एक पता मिल सकता है
+- एक **Internet gateway** को **VPC** से **attached** होना चाहिए
+- आप **Egress-only internet gateways** भी उपयोग कर सकते हैं
+- आप एक **private subnet** में एक **NAT gateway** भी रख सकते हैं ताकि उस private subnet से external services से कनेक्ट होना संभव हो, पर बाहरी तरफ से उन private संसाधनों तक पहुँचना संभव नहीं होता।
+- NAT gateway **public** (internet access) या **private** (अन्य VPCs तक पहुँच) हो सकता है
 
 ![](<../../../../images/image (274).png>)
 
 ## VPC
 
-Amazon **Virtual Private Cloud** (Amazon VPC) आपको उस वर्चुअल नेटवर्क में AWS संसाधन लॉन्च करने की अनुमति देता है जिसे आप परिभाषित करते हैं। यह वर्चुअल नेटवर्क कई subnets, Internet Gateways (इंटरनेट एक्सेस के लिए), ACLs, Security groups, IPs आदि रखेगा।
+Amazon **Virtual Private Cloud** (Amazon VPC) आपको उस वर्चुअल नेटवर्क में **AWS resources लॉन्च** करने में सक्षम बनाता है जिसे आपने परिभाषित किया है। इस वर्चुअल नेटवर्क में कई subnets, Internet Gateways इंटरनेट एक्सेस के लिए, ACLs, Security groups, IPs आदि होंगे...
 
 ### Subnets
 
-Subnets सुरक्षा का एक उच्च स्तर लागू करने में मदद करते हैं। समान संसाधनों का तार्किक समूह बनाकर आप अपने इंफ्रास्ट्रक्चर का प्रबंधन आसान रख सकते हैं।
+Subnets सुरक्षा के एक उच्च स्तर को लागू करने में मदद करते हैं। समान संसाधनों का **logical grouping** आपके इंफ्रास्ट्रक्चर के प्रबंधन को आसान बनाता है।
 
-- Valid CIDR are from a /16 netmask to a /28 netmask.
-- एक subnet एक ही समय में अलग-अलग availability zones में नहीं हो सकता।
-- **AWS reserves the first three host IP addresses** of each subnet **for** **internal AWS usage**: पहला होस्ट पता VPC राउटर के लिए इस्तेमाल होता है। दूसरा पता AWS DNS के लिए रिज़र्व रहता है और तीसरा पता भविष्य के उपयोग के लिए रिज़र्व रहता है।
-- जिन subnets को इंटरनेट तक सीधे पहुंच होती है उन्हें **public subnets** कहा जाता है, जबकि जिनमें नहीं होती उन्हें **private subnets** कहा जाता है।
+- वैध CIDR एक /16 netmask से लेकर /28 netmask तक होते हैं।
+- एक subnet एक ही समय में विभिन्न availability zones में नहीं हो सकता।
+- **AWS प्रत्येक subnet के पहले तीन host IP addresses आरक्षित करता है** आंतरिक AWS उपयोग के लिए: पहला host address VPC router के लिए उपयोग होता है। दूसरा पता AWS DNS के लिए आरक्षित है और तीसरा पता भविष्य के उपयोग के लिए आरक्षित है।
+- जिन subnets को **इंटरनेट का सीधा एक्सेस** होता है उन्हें **public subnets** कहा जाता है, जबकि private subnets में ऐसा नहीं होता।
 
 ### Route Tables
 
-Route tables किसी VPC के भीतर एक subnet के ट्रैफिक रूटिंग को निर्धारित करते हैं। ये तय करते हैं कि कौन सा नेटवर्क ट्रैफिक इंटरनेट या VPN कनेक्शन की ओर अग्रेषित होगा। आमतौर पर आप निम्न चीज़ों के लिए रूट पाएंगे:
+Route tables एक VPC के भीतर किसी subnet के लिए ट्रैफिक रूटिंग निर्धारित करते हैं। वे निर्धारित करते हैं कि कौन सा नेटवर्क ट्रैफिक इंटरनेट को अग्रेषित किया जाए या VPN कनेक्शन की ओर। आप आम तौर पर निम्नलिखित एक्सेस पाएंगे:
 
 - Local VPC
 - NAT
-- Internet Gateways / Egress-only Internet gateways (VPC को Internet का access देने के लिए जरूरी)।
-- किसी subnet को public बनाने के लिए आपको अपने VPC में एक **Internet gateway** **create** और **attach** करना होगा।
-- VPC endpoints (private नेटवर्क से S3 तक पहुँच के लिए)
+- Internet Gateways / Egress-only Internet gateways (VPC को इंटरनेट एक्सेस देने के लिए आवश्यक)
+- किसी subnet को public बनाने के लिए आपको अपना VPC में एक **Internet gateway** **create** और **attach** करना होगा।
+- VPC endpoints (private networks से S3 तक पहुँचने के लिए)
 
 ### ACLs
 
-**Network Access Control Lists (ACLs)**: Network ACLs वे फ़ायरवॉल नियम हैं जो किसी subnet के इनकमिंग और आउटगोइंग नेटवर्क ट्रैफिक को नियंत्रित करते हैं। इन्हें किसी विशिष्ट IP पता या रेंज के लिए ट्रैफिक allow या deny करने के लिए उपयोग किया जा सकता है।
+**Network Access Control Lists (ACLs)**: Network ACLs फ़ायरवॉल नियम हैं जो एक subnet के लिए इनकमिंग और आउटगोइंग नेटवर्क ट्रैफिक को नियंत्रित करते हैं। इन्हें विशिष्ट IP पतों या रेंजों के लिए ट्रैफिक की अनुमति देने या इनकार करने के लिए उपयोग किया जा सकता है।
 
-- अक्सर access allow/deny करने के लिए security groups का उपयोग होता है, लेकिन subnet स्तर पर पूरी तरह से established reverse shells को काटने का यह एकमात्र तरीका हो सकता है। security group में बदला हुआ नियम पहले से established कनेक्शनों को तुरंत नहीं रोकता।
-- हालाँकि, यह पूरे subnetwork पर लागू होता है—इसलिए कुछ चीज़ें बंद करते समय सावधान रहें क्योंकि आवश्यक कार्यक्षमता प्रभावित हो सकती है।
+- सामान्यतः access allow/deny करने के लिए security groups का उपयोग सबसे अधिक होता है, लेकिन यह ही एकमात्र तरीका है जो स्थापित reverse shells को पूरी तरह काट सकता है। security group में किया गया संशोधित नियम पहले से स्थापित कनेक्शनों को नहीं रोकता।
+- हालाँकि, यह पूरे subnetwork पर लागू होता है — सावधानी बरतें जब कुछ चीज़ों को प्रतिबंधित कर रहे हों क्योंकि आवश्यक कार्यक्षमता प्रभावित हो सकती है।
 
 ### Security Groups
 
-Security groups एक वर्चुअल **फ़ायरवॉल** हैं जो VPC में instances के लिए inbound और outbound नेटवर्क ट्रैफिक को नियंत्रित करते हैं। Relation 1 SG to M instances (आम तौर पर 1 से 1)।\
-आम तौर पर इसका उपयोग instances में खतरनाक पोर्ट खोलने के लिए किया जाता है, जैसे कि पोर्ट 22 उदाहरण के लिए:
+Security groups एक वर्चुअल **firewall** हैं जो VPC में instances के लिए inbound और outbound नेटवर्क ट्रैफिक को नियंत्रित करते हैं। संबंध 1 SG से M instances (अक्सर 1 से 1)।\
+आम तौर पर इसका उपयोग instances में खतरनाक पोर्ट खोलने के लिए किया जाता है, जैसे उदाहरण के लिए पोर्ट 22:
 
 <figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
 
 ### Elastic IP Addresses
 
-An _Elastic IP address_ एक **static IPv4 address** है जिसे dynamic cloud computing के लिए डिज़ाइन किया गया है। एक Elastic IP पता आपके AWS अकाउंट को आवंटित किया जाता है, और जब तक आप इसे रिलीज़ नहीं करते यह आपका रहता है। एक Elastic IP का उपयोग करके, आप किसी instance या सॉफ़्टवेयर की विफलता को जल्दी से दूसरे instance पर उस पते को remap करके छिपा सकते हैं।
+एक _Elastic IP address_ एक **static IPv4 address** है जो dynamic cloud computing के लिए डिज़ाइन किया गया है। एक Elastic IP address आपके AWS account को allocate किया जाता है, और जब तक आप उसे रिलीज़ नहीं करते वह आपका होता है। Elastic IP address का उपयोग करके, आप एक instance या सॉफ़्टवेयर की विफलता को छिपा सकते हैं और तेज़ी से उस पते को अपने खाते के किसी अन्य instance पर remap कर सकते हैं।
 
 ### Connection between subnets
 
-डिफ़ॉल्ट रूप से, सभी subnets में **automatic assigned of public IP addresses turned off** रहता है लेकिन इसे ऑन किया जा सकता है।
+डिफ़ॉल्ट रूप से, सभी subnets में **public IP addresses का automatic assigned बंद** होता है पर इसे चालू किया जा सकता है।
 
-**A local route within a route table enables communication between VPC subnets.**
+**एक local route किसी route table के भीतर VPC subnets के बीच संचार सक्षम करता है।**
 
-यदि आप एक subnet को किसी दूसरे subnet से कनेक्ट कर रहे हैं, तो आप उस दूसरे से जुड़े अन्य subnets तक नहीं पहुँच पाएंगे; आपको उनके साथ सीधे connection बनाना होगा। **यह इंटरनेट gateways पर भी लागू होता है**। आप किसी subnet connection के रास्ते इंटरनेट तक नहीं जा सकते; आपको अपने subnet को इंटरनेट gateway असाइन करना होगा।
+यदि आप एक subnet को किसी अन्य subnet से **connect** कर रहे हैं तो आप उन subnets तक पहुँच नहीं सकते जो दूसरे subnet के साथ connected हैं; आपको उनके साथ सीधे कनेक्शन बनाना होगा। **यह इंटरनेट gateways पर भी लागू होता है।** आप इंटरनेट तक पहुँचने के लिए एक subnet कनेक्शन के माध्यम से नहीं जा सकते; आपको अपने subnet को Internet gateway असाइन करना होगा।
 
 ### VPC Peering
 
-VPC peering आपको दो या अधिक VPCs को IPV4 या IPV6 उपयोग करते हुए एक दूसरे से जोड़ने की अनुमति देता है, जैसे कि वे एक ही नेटवर्क का हिस्सा हों।
+VPC peering आपको **दो या अधिक VPCs को एक साथ कनेक्ट** करने की अनुमति देता है, IPV4 या IPV6 का उपयोग करके, मानो वे एक ही नेटवर्क का हिस्सा हों।
 
-एक बार peer connectivity स्थापित हो जाने पर, **एक VPC में संसाधन दूसरे VPC में संसाधनों तक पहुँच सकते हैं**। VPCs के बीच कनेक्टिविटी मौजूदा AWS नेटवर्क इंफ्रास्ट्रक्चर के माध्यम से लागू होती है, इसलिए यह उच्च उपलब्धता वाला होता है और बैंडविड्थ बोतल-नल नहीं होती। चूँकि **peered connections उसी नेटवर्क का हिस्सा होने जैसा व्यवहार करते हैं**, इसलिए आपके CIDR ब्लॉक्स के उपयोग में सीमाएँ होती हैं।\
-यदि आपकी VPCs के लिए **overlapping या duplicate CIDR** ranges हैं, तो आप VPCs को peer नहीं कर पाएंगे।\
-प्रत्येक AWS VPC केवल अपने peer के साथ ही संचार करेगा। उदाहरण के लिए, यदि आपके पास VPC 1 और VPC 2 के बीच peering connection है, और VPC 2 और VPC 3 के बीच एक और connection है, तो VPC 1 और VPC 2 सीधे आपस में संचार कर सकते हैं, जैसे VPC 2 और VPC 3 कर सकते हैं; तथापि VPC 1 और VPC 3 नहीं कर सकते। **आप एक VPC के माध्यम से रूट करके दूसरे VPC तक नहीं पहुँच सकते।**
+एक बार peer connectivity स्थापित हो जाने पर, **एक VPC के संसाधन दूसरे VPC के संसाधनों तक पहुँच सकते हैं।** VPCs के बीच कनेक्टिविटी मौजूदा AWS नेटवर्क इन्फ्रास्ट्रक्चर के माध्यम से लागू की जाती है, इसलिए यह उच्च उपलब्धता के साथ है और बैंडविड्थ बॉटलनेक नहीं होता। चूँकि **peered connections उसी नेटवर्क का हिस्सा होने जैसा व्यवहार करते हैं**, इसलिए आपके CIDR block रेंज के बारे में कुछ प्रतिबंध होते हैं।\
+यदि आपके VPC के लिए **overlapping या duplicate CIDR** रेंज हैं, तो आप VPCs को peer नहीं कर पाएंगे।\
+प्रत्येक AWS VPC केवल अपने peer के साथ ही संवाद करेगा। उदाहरण के लिए, यदि आपके पास VPC 1 और VPC 2 के बीच एक peering connection है, और VPC 2 और VPC 3 के बीच एक और connection है जैसा दिखाया गया है, तो VPC 1 और VPC 2 सीधे एक दूसरे के साथ संवाद कर सकते हैं, जैसे VPC 2 और VPC 3, परन्तु VPC 1 और VPC 3 नहीं कर पाएंगे। **आप एक VPC के माध्यम से रूट करके दूसरे VPC तक नहीं जा सकते।**
 
 ### **VPC Flow Logs**
 
-आपके VPC के भीतर सैकड़ों या हजारों संसाधन हो सकते हैं जो अलग-अलग subnets (public और private दोनों) और VPC peering connections के माध्यम से संवाद कर रहे हैं। **VPC Flow Logs आपको आपके VPC के भीतर आपके संसाधनों के network interfaces के बीच बहने वाली IP ट्रैफ़िक जानकारी कैप्चर करने देते हैं**।
+आपके VPC के भीतर सैकड़ों या हजारों संसाधन हो सकते हैं जो विभिन्न subnets (public और private दोनों) के बीच और VPC peering connections के माध्यम से अलग-अलग VPCs के बीच संचार कर रहे हैं। **VPC Flow Logs आपको आपके VPC के भीतर आपके resources के network interfaces के बीच प्रवाहित होने वाली IP ट्रैफिक जानकारी capture करने की अनुमति देते हैं।**
 
-S3 access logs और CloudFront access logs के विपरीत, **VPC Flow Logs द्वारा जनरेट किया गया log data S3 में संग्रहीत नहीं किया जाता। बल्कि, पकड़ा गया log data CloudWatch logs को भेजा जाता है**।
+S3 access logs और CloudFront access logs के विपरीत, VPC Flow Logs द्वारा उत्पन्न **log data S3 में store नहीं किया जाता। इसके बजाय, captured log data CloudWatch logs को भेजा जाता है**।
 
 Limitations:
 
-- यदि आप एक VPC peered connection चला रहे हैं, तो आप केवल उन्हीं peered VPCs के flow logs देख पाएंगे जो उसी account के अंदर हैं।
-- यदि आप अभी भी EC2-Classic environment में संसाधन चला रहे हैं, तो दुर्भाग्य से आप उनके interfaces से जानकारी पुनःप्राप्त नहीं कर पाएंगे।
-- एक बार VPC Flow Log बनाया गया, तो उसे बदला नहीं जा सकता। VPC Flow Log कॉन्फ़िगरेशन बदलने के लिए आपको उसे हटाना और फिर नया बनाना होगा।
-- निम्न ट्रैफ़िक logs द्वारा मॉनिटर और कैप्चर नहीं किया जाता: VPC के भीतर DHCP ट्रैफिक, instances से Amazon DNS Server के लिए जाने वाला ट्रैफिक।
-- किसी भी ट्रैफ़िक का गंतव्य VPC default router का IP पता हो और निम्न पतों के लिए आने-जाने वाला ट्रैफिक: 169.254.169.254 (instance metadata के लिए) और 169.254.169.123 (Amazon Time Sync Service के लिए)।
-- Amazon Windows activation license से संबंधित ट्रैफिक किसी Windows instance से
-- network load balancer interface और endpoint network interface के बीच ट्रैफ़िक
+- यदि आप एक VPC peered connection चला रहे हैं, तो आप केवल उन्हीं peered VPCs के flow logs देख पाएंगे जो उसी account के भीतर हैं।
+- यदि आप अभी भी EC2-Classic environment के भीतर resources चला रहे हैं, तो दुर्भाग्यवश आप उनके interfaces से जानकारी प्राप्त नहीं कर पाएंगे
+- एक बार VPC Flow Log बन जाने के बाद, इसे बदला नहीं जा सकता। VPC Flow Log कॉन्फ़िगरेशन बदलने के लिए आपको इसे हटाना होगा और फिर नया बनाना होगा।
+- निम्नलिखित ट्रैफिक logs द्वारा निगरानी और capture नहीं किया जाता: VPC के भीतर DHCP ट्रैफिक, Amazon DNS Server के लिए destined instances से आने वाला ट्रैफिक।
+- किसी भी ट्रैफिक का जो VPC default router के IP पते के लिए destined है और निम्नलिखित पतों से और उन पतों पर आने-जाने वाला ट्रैफिक, 169.254.169.254 (जो instance metadata जमा करने के लिए उपयोग होता है), और 169.254.169.123 (जो Amazon Time Sync Service के लिए उपयोग होता है) capture नहीं किया जाता।
+- एक Windows instance से Amazon Windows activation license से संबंधित ट्रैफिक
+- एक network load balancer interface और एक endpoint network interface के बीच ट्रैफिक
 
-जो भी network interface CloudWatch log group को डाटा प्रकाशित करता है, वह एक अलग log stream उपयोग करेगा। और इन streams में प्रत्येक में flow log event data होगा जो log entries की सामग्री दिखाता है। इनमें से प्रत्येक **logs लगभग 10 से 15 मिनट की विंडो के दौरान डाटा कैप्चर करते हैं**।
+हर network interface जो CloudWatch log group को डेटा प्रकाशित करता है, वह एक अलग log stream उपयोग करेगा। और इन streams के भीतर, flow log घटना डेटा होगा जो log entries की सामग्री दिखाता है। इनमें से प्रत्येक **logs लगभग 10 से 15 मिनट की विंडो के दौरान डेटा capture करते हैं**।
 
 ## VPN
 
 ### Basic AWS VPN Components
 
 1. **Customer Gateway**:
-- Customer Gateway वह resource है जिसे आप AWS में बनाते हैं ताकि आपके तरफ़ के VPN connection का प्रतिनिधित्व हो सके।
-- यह मूल रूप से आपकी साइट-टू-साइट VPN कनेक्शन की तरफ़ पर एक भौतिक डिवाइस या सॉफ़्टवेयर एप्लिकेशन होता है।
-- आप अपने नेटवर्क डिवाइस (जैसे router या firewall) का public IP address और routing जानकारी AWS को प्रदान करते हैं ताकि Customer Gateway बनाया जा सके।
-- यह VPN connection सेटअप करने के लिए एक reference point के रूप में कार्य करता है और इससे अतिरिक्त चार्ज नहीं लगता।
+- एक Customer Gateway वह रिसोर्स है जो आप AWS में बनाते हैं ताकि आपके तरफ के VPN कनेक्शन को प्रस्तुत किया जा सके।
+- यह मूलतः आपकी साइट-टू-साइट VPN कनेक्शन की आपकी तरफ की physical device या software application है।
+- आप routing जानकारी और अपने नेटवर्क डिवाइस (जैसे router या firewall) का public IP address AWS को प्रदान करते हैं ताकि एक Customer Gateway बनाया जा सके।
+- यह VPN कनेक्शन सेटअप करने के लिए एक reference point का काम करता है और यह अतिरिक्त शुल्क नहीं लेता।
 2. **Virtual Private Gateway**:
-- Virtual Private Gateway (VPG) Amazon की तरफ़ वाला VPN concentrator है जो Site-to-Site VPN connection के लिए होता है।
-- यह आपके VPC से जुड़ा होता है और आपके VPN connection के लिए target के रूप में कार्य करता है।
-- VPG वह AWS साइड endpoint है VPN कनेक्शन का।
-- यह आपके VPC और आपके on-premises नेटवर्क के बीच सुरक्षित संचार को संभालता है।
+- एक Virtual Private Gateway (VPG) साइट-टू-साइट VPN कनेक्शन के Amazon तरफ का VPN concentrator है।
+- यह आपके VPC से जुड़ा होता है और आपके VPN कनेक्शन के लिए लक्ष्य के रूप में कार्य करता है।
+- VPG VPN कनेक्शन के लिए AWS साइड endpoint है।
+- यह आपके VPC और आपके on-premises नेटवर्क के बीच secure संचार को संभालता है।
 3. **Site-to-Site VPN Connection**:
-- Site-to-Site VPN connection आपके on-premises नेटवर्क को एक secure IPsec VPN tunnel के माध्यम से एक VPC से जोड़ता है।
-- इस प्रकार के कनेक्शन के लिए एक Customer Gateway और एक Virtual Private Gateway की आवश्यकता होती है।
-- यह आपके डेटा सेंटर या नेटवर्क और आपके AWS वातावरण के बीच सुरक्षित, स्थिर और लगातार संचार के लिए उपयोग किया जाता है।
-- आमतौर पर यह नियमित, दीर्घकालिक कनेक्शनों के लिए उपयोग किया जाता है और कनेक्शन के माध्यम से भेजी गई डेटा की मात्रा के आधार पर बिल किया जाता है।
+- एक Site-to-Site VPN connection आपके on-premises नेटवर्क को एक secure, IPsec VPN tunnel के माध्यम से एक VPC से जोड़ता है।
+- इस प्रकार के कनेक्शन के लिए एक Customer Gateway और एक Virtual Private Gateway आवश्यक होते हैं।
+- यह आपके डेटा सेंटर या नेटवर्क और आपके AWS environment के बीच सुरक्षित, स्थिर और निरंतर संचार के लिए उपयोग किया जाता है।
+- सामान्यतः यह नियमित, दीर्घकालिक कनेक्शनों के लिए उपयोग होता है और कनेक्शन पर स्थानांतरित किए गए डेटा की मात्रा के आधार पर बिल किया जाता है।
 4. **Client VPN Endpoint**:
-- Client VPN endpoint वह resource है जिसे आप AWS में बनाते हैं ताकि client VPN sessions सक्षम और प्रबंधित किए जा सकें।
-- यह व्यक्तिगत डिवाइसों (जैसे laptops, smartphones, आदि) को सुरक्षित रूप से AWS संसाधनों या आपके on-premises नेटवर्क से कनेक्ट होने की अनुमति देने के लिए इस्तेमाल होता है।
-- यह Site-to-Site VPN से अलग है क्योंकि यह पूरे नेटवर्कों को जोड़ने के बजाय व्यक्तिगत clients के लिए डिज़ाइन किया गया है।
-- Client VPN के साथ, प्रत्येक client डिवाइस एक VPN client सॉफ़्टवेयर का उपयोग करके secure connection स्थापित करता है।
+- एक Client VPN endpoint वह रिसोर्स है जिसे आप AWS में बनाते हैं ताकि client VPN sessions को सक्षम और प्रबंधित किया जा सके।
+- इसका उपयोग व्यक्तिगत डिवाइसों (जैसे laptops, smartphones आदि) को securely AWS resources या आपके on-premises नेटवर्क से जोड़ने के लिए किया जाता है।
+- यह Site-to-Site VPN से अलग है क्योंकि यह पूरी नेटवर्क कनेक्ट करने के बजाय व्यक्तिगत clients के लिए डिज़ाइन किया गया है।
+- Client VPN के साथ, प्रत्येक client डिवाइस एक VPN client software का उपयोग करके secure कनेक्शन स्थापित करता है।
 
 ### Site-to-Site VPN
 
 **अपने on premisses नेटवर्क को अपने VPC से कनेक्ट करें।**
 
 - **VPN connection**: आपके on-premises उपकरण और आपके VPCs के बीच एक secure connection।
-- **VPN tunnel**: एक encrypted लिंक जहाँ डेटा customer नेटवर्क से AWS को या AWS से customer नेटवर्क को पार कर सकता है।
+- **VPN tunnel**: एक encrypted लिंक जहाँ डेटा customer नेटवर्क से AWS की ओर या AWS से customer नेटवर्क की ओर जा सकता है।
 
-प्रत्येक VPN connection में दो VPN tunnels शामिल होते हैं जिन्हें आप उच्च उपलब्धता के लिए समानांतर रूप से उपयोग कर सकते हैं।
+प्रत्येक VPN connection में दो VPN tunnels होते हैं जिन्हें आप high availability के लिए समानांतर उपयोग कर सकते हैं।
 
-- **Customer gateway**: एक AWS resource जो AWS को आपके customer gateway device के बारे में जानकारी देता है।
-- **Customer gateway device**: आपकी तरफ़ का वह भौतिक डिवाइस या सॉफ़्टवेयर एप्लिकेशन जो Site-to-Site VPN connection के लिए है।
-- **Virtual private gateway**: Site-to-Site VPN connection के Amazon साइड का VPN concentrator। आप Amazon साइड के लिए virtual private gateway या transit gateway का उपयोग कर सकते हैं।
-- **Transit gateway**: एक transit hub जिसे आप अपने VPCs और on-premises नेटवर्क्स को इंटरकनेक्ट करने के लिए उपयोग कर सकते हैं। आप Site-to-Site VPN connection के Amazon साइड के लिए transit gateway या virtual private gateway का उपयोग करते हैं।
+- **Customer gateway**: एक AWS रिसोर्स जो AWS को आपके customer gateway device के बारे में जानकारी प्रदान करता है।
+- **Customer gateway device**: साइट-टू-साइट VPN कनेक्शन की आपकी तरफ का physical device या software application।
+- **Virtual private gateway**: साइट-टू-साइट VPN कनेक्शन के Amazon तरफ का VPN concentrator। आप Amazon तरफ के लिए virtual private gateway या transit gateway का उपयोग कर सकते हैं।
+- **Transit gateway**: एक transit hub जो आपके VPCs और on-premises नेटवर्क्स को interconnect करने के लिए उपयोग किया जा सकता है। आप Amazon तरफ के लिए transit gateway या virtual private gateway का उपयोग करते हैं।
 
 #### Limitations
 
 - IPv6 ट्रैफ़िक virtual private gateway पर VPN connections के लिए समर्थित नहीं है।
-- AWS VPN connection Path MTU Discovery को सपोर्ट नहीं करता।
+- एक AWS VPN connection Path MTU Discovery का समर्थन नहीं करता।
 
-इसके अलावा, Site-to-Site VPN का उपयोग करते समय निम्न बातों का ध्यान रखें:
+इसके अतिरिक्त, Site-to-Site VPN उपयोग करते समय निम्न बातों को ध्यान में रखें।
 
-- जब आप अपने VPCs को एक सामान्य on-premises नेटवर्क से कनेक्ट कर रहे हों, तो हम सुझाव देते हैं कि आप अपने नेटवर्क्स के लिए non-overlapping CIDR blocks का उपयोग करें।
+- जब आप अपने VPCs को एक साझा on-premises नेटवर्क से कनेक्ट कर रहे हों, तो हम सुझाव देते हैं कि आप अपने नेटवर्क्स के लिए non-overlapping CIDR blocks का उपयोग करें।
 
 ### Client VPN <a href="#what-is-components" id="what-is-components"></a>
 
-**अपने मशीन से अपने VPC से कनेक्ट करें**
+**अपने मशीन से अपने VPC तक कनेक्ट करें**
 
 #### Concepts
 
-- **Client VPN endpoint:** वह resource जिसे आप बनाकर कॉन्फ़िगर करते हैं ताकि client VPN sessions सक्षम और प्रबंधित किए जा सकें। यह वह resource है जहाँ सभी client VPN sessions समाप्त होते हैं।
-- **Target network:** Target network वह नेटवर्क है जिसे आप Client VPN endpoint के साथ associate करते हैं। **एक VPC का subnet एक target network है**। किसी subnet को Client VPN endpoint के साथ associate करने से आप VPN sessions स्थापित कर सकते हैं। उच्च उपलब्धता के लिए आप एक Client VPN endpoint के साथ कई subnets associate कर सकते हैं। सभी subnets को उसी VPC से होना चाहिए। प्रत्येक subnet अलग Availability Zone में होना चाहिए।
-- **Route**: प्रत्येक Client VPN endpoint का एक route table होता है जो उपलब्ध destination network routes का वर्णन करता है। route table में प्रत्येक route ट्रैफ़िक के लिए पथ निर्दिष्ट करता है जो विशिष्ट संसाधनों या नेटवर्क्स की ओर जाता है।
-- **Authorization rules:** एक authorization rule उन users को प्रतिबंधित करता है जो किसी नेटवर्क तक पहुँच सकते हैं। किसी निर्दिष्ट नेटवर्क के लिए, आप Active Directory या identity provider (IdP) समूह कॉन्फ़िगर करते हैं जिसे पहुँच की अनुमति है। केवल उस समूह के सदस्य ही निर्दिष्ट नेटवर्क तक पहुँच पाएंगे। **डिफ़ॉल्ट रूप से कोई authorization rules नहीं होते** और उपयोगकर्ताओं को संसाधनों और नेटवर्क्स तक पहुँच सक्षम करने के लिए आपको authorization rules कॉन्फ़िगर करने होंगे।
-- **Client:** वह end user जो Client VPN endpoint से कनेक्ट होकर VPN session स्थापित करता है। End users को OpenVPN client डाउनलोड करना होगा और वह Client VPN configuration file उपयोग करनी होगी जिसे आपने बनाया है।
-- **Client CIDR range:** client IP पतों को असाइन करने के लिए जिस IP address range का उपयोग किया जाता है। Client VPN endpoint के प्रत्येक कनेक्शन को client CIDR range से एक अनूठा IP पता असाइन किया जाता है। आप client CIDR range चुनते हैं, उदाहरण के लिए `10.2.0.0/16`।
-- **Client VPN ports:** AWS Client VPN पोर्ट 443 और 1194 दोनों के लिए TCP और UDP का समर्थन करता है। डिफ़ॉल्ट पोर्ट 443 है।
-- **Client VPN network interfaces:** जब आप अपने Client VPN endpoint के साथ एक subnet associate करते हैं, तो हम उस subnet में Client VPN network interfaces बनाते हैं। **Client VPN endpoint से VPC की ओर भेजा गया ट्रैफ़िक एक Client VPN network interface के माध्यम से भेजा जाता है**। फिर Source network address translation (SNAT) लागू किया जाता है, जहाँ client CIDR range से आने वाले source IP पते को Client VPN network interface IP पते में translate किया जाता है।
-- **Connection logging:** आप अपने Client VPN endpoint के लिए connection logging सक्षम कर सकते हैं ताकि connection events लॉग हो सकें। आप इस जानकारी का उपयोग फ़ॉरेंसिक्स चलाने, यह विश्लेषित करने के लिए कि आपका Client VPN endpoint कैसे उपयोग किया जा रहा है, या connection समस्याओं को debug करने के लिए कर सकते हैं।
-- **Self-service portal:** आप अपने Client VPN endpoint के लिए self-service portal सक्षम कर सकते हैं। Clients अपने credentials का उपयोग करके web-based portal में लॉग इन कर सकते हैं और Client VPN endpoint configuration file का नवीनतम संस्करण या AWS द्वारा प्रदान किया गया client का नवीनतम संस्करण डाउनलोड कर सकते हैं।
+- **Client VPN endpoint:** वह रिसोर्स जिसे आप बनाते और कॉन्फ़िगर करते हैं ताकि client VPN sessions सक्षम और प्रबंधित हो सकें। यह वही रिसोर्स है जहाँ सभी client VPN sessions समाप्त होते हैं।
+- **Target network:** एक target network वह नेटवर्क है जिसे आप एक Client VPN endpoint के साथ associate करते हैं। **A subnet from a VPC is a target network**। किसी subnet को Client VPN endpoint से associate करने से आप VPN sessions स्थापित कर सकते हैं। आप उच्च उपलब्धता के लिए कई subnets को एक Client VPN endpoint के साथ associate कर सकते हैं। सभी subnets एक ही VPC से होने चाहिए। प्रत्येक subnet को अलग Availability Zone में होना चाहिए।
+- **Route**: प्रत्येक Client VPN endpoint का एक route table होता है जो उपलब्ध destination network routes का वर्णन करता है। route table में प्रत्येक route ट्रैफिक के लिए विशिष्ट संसाधनों या नेटवर्क के लिए पथ निर्दिष्ट करता है।
+- **Authorization rules:** एक authorization rule उन उपयोगकर्ताओं को प्रतिबंधित करता है जो किसी नेटवर्क तक पहुँच सकते हैं। किसी निर्दिष्ट नेटवर्क के लिए, आप Active Directory या identity provider (IdP) समूह को configure करते हैं जिसे पहुँच की अनुमति है। केवल उस समूह के सदस्य उपयोग निर्दिष्ट नेटवर्क तक पहुँच सकते हैं। **डिफ़ॉल्ट रूप से, कोई authorization rules नहीं होते** और उपयोगकर्ताओं को संसाधनों और नेटवर्क तक पहुँचने के लिए आपको authorization rules कॉन्फ़िगर करने होंगे।
+- **Client:** वह end user जो Client VPN endpoint से जुड़कर VPN session स्थापित करता है। End users को एक OpenVPN client डाउनलोड करने और VPN session स्थापित करने के लिए आपने जो Client VPN configuration file बनाई है उसका उपयोग करने की आवश्यकता होती है।
+- **Client CIDR range:** एक IP address range जिससे client IP addresses असाइन किए जाते हैं। Client VPN endpoint से प्रत्येक कनेक्शन को client CIDR range से एक unique IP address असाइन किया जाता है। आप client CIDR range चुनते हैं, उदाहरण के लिए `10.2.0.0/16`.
+- **Client VPN ports:** AWS Client VPN TCP और UDP दोनों के लिए ports 443 और 1194 का समर्थन करता है। डिफ़ॉल्ट पोर्ट 443 है।
+- **Client VPN network interfaces:** जब आप अपने Client VPN endpoint के साथ किसी subnet को associate करते हैं, तो हम उस subnet में Client VPN network interfaces बनाते हैं। **जो ट्रैफिक VPC को Client VPN endpoint से भेजा जाता है वह Client VPN network interface के माध्यम से भेजा जाता है**। Source network address translation (SNAT) फिर लागू किया जाता है, जहाँ client CIDR range से source IP address को Client VPN network interface IP address में translate किया जाता है।
+- **Connection logging:** आप अपने Client VPN endpoint के लिए connection logging सक्षम कर सकते हैं ताकि connection events लॉग किए जा सकें। आप इस जानकारी का उपयोग फॉरेंसिक्स करने, यह विश्लेषण करने के लिए कर सकते हैं कि आपका Client VPN endpoint कैसे उपयोग किया जा रहा है, या connection समस्याओं को debug करने के लिए कर सकते हैं।
+- **Self-service portal:** आप अपने Client VPN endpoint के लिए self-service portal सक्षम कर सकते हैं। Clients अपनी credentials का उपयोग करके web-based portal में लॉग इन कर सकते हैं और Client VPN endpoint configuration file का नवीनतम संस्करण या AWS द्वारा प्रदान किया गया client का नवीनतम संस्करण डाउनलोड कर सकते हैं।
 
 #### Limitations
 
 - **Client CIDR ranges cannot overlap with the local CIDR** of the VPC in which the associated subnet is located, or any routes manually added to the Client VPN endpoint's route table.
 - Client CIDR ranges must have a block size of at **least /22** and must **not be greater than /12.**
-- Client CIDR range में उपयोग किए जाने वाले पतों का एक **हिस्सा availability model का समर्थन करने के लिए** उपयोग होता है, और इन्हें clients को असाइन नहीं किया जा सकता। इसलिए, हम सुझाव देते हैं कि आप **उच्चतम concurrent connections की संख्या को सक्षम करने के लिए आवश्यक IP पतों की दोगुनी संख्या वाले CIDR ब्लॉक को असाइन करें।**
-- Client CIDR range **बनाने के बाद बदला नहीं जा सकता**।
-- Client VPN endpoint के साथ associate किए गए **subnets को उसी VPC में होना चाहिए**।
-- आप एक Availability Zone से एक से अधिक subnet को Client VPN endpoint के साथ associate नहीं कर सकते।
-- Client VPN endpoint **dedicated tenancy VPC** में subnet associations का समर्थन नहीं करता।
+- Client CIDR range के कुछ पते Client VPN endpoint की availability मॉडल का समर्थन करने के लिए उपयोग किए जाते हैं, और ग्राहकों को असाइन नहीं किए जा सकते। इसलिए, हम सलाह देते हैं कि आप उस संख्या के दोगुने IP पतों वाला एक CIDR block असाइन करें जितने concurrent connections आप Client VPN endpoint पर समर्थन करने की योजना बना रहे हैं।
+- Client CIDR range **create करने के बाद बदल नहीं सकती**।
+- Client VPN endpoint के साथ associate किए गए **subnets** एक ही VPC में होने चाहिए।
+- आप **एक Availability Zone से कई subnets** को एक Client VPN endpoint के साथ associate नहीं कर सकते।
+- एक Client VPN endpoint **dedicated tenancy VPC में subnet associations का समर्थन नहीं करता**।
 - Client VPN केवल **IPv4** ट्रैफ़िक का समर्थन करता है।
-- Client VPN **FIPS** (Federal Information Processing Standards) के अनुरूप नहीं है।
-- यदि आपके Active Directory के लिए multi-factor authentication (MFA) अक्षम है, तो एक user password निम्न प्रारूप में नहीं हो सकता।
+- Client VPN **FIPS (Federal Information Processing Standards)** के अनुरूप नहीं है।
+- यदि आपके Active Directory के लिए multi-factor authentication (MFA) disabled है, तो एक user password निम्न प्रारूप में नहीं हो सकता।
 
 ```
 SCRV1:<base64_encoded_string>:<base64_encoded_string>
 ```
 
-- Self-service portal उन clients के लिए उपलब्ध नहीं है जो mutual authentication का उपयोग करके authenticate करते हैं।
+- जो क्लाइंट mutual authentication का उपयोग करके authenticate करते हैं उनके लिए self-service portal उपलब्ध नहीं है।
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md

@@ -4,36 +4,36 @@
 
 ## S3
 
-Amazon S3 एक सेवा है जो आपको **बड़ी मात्रा में डेटा संग्रहित करने** की अनुमति देती है।
+Amazon S3 एक सेवा है जो आपको **बड़े मात्रा में डेटा स्टोर करने** की अनुमति देती है।
 
-Amazon S3 REST में डेटा की **सुरक्षा** प्राप्त करने के लिए कई विकल्प प्रदान करता है। विकल्पों में **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** और **MFA** **based delete** शामिल हैं। **उपयोगकर्ता** डेटा सुरक्षा प्राप्त करने के लिए इन किसी भी विकल्प को सक्षम कर सकता है। **Data replication** AWS की एक आंतरिक सुविधा है जहाँ **S3 स्वचालित रूप से प्रत्येक ऑब्जेक्ट को सभी Availability Zones में प्रतिकृत करता है** और इस मामले में संगठन को इसे सक्षम करने की आवश्यकता नहीं होती है।
+Amazon S3 डेटा को REST पर **सुरक्षा** प्रदान करने के लिए कई विकल्प देता है। विकल्पों में **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** और **MFA based delete** शामिल हैं। **user** इनमें से किसी भी विकल्प को सक्षम करके डेटा सुरक्षा प्राप्त कर सकता है। **Data replication** AWS की एक आंतरिक सुविधा है जहाँ **S3 automatically replicates each object across all the Availability Zones** और इस मामले में organization को इसे सक्षम करने की आवश्यकता नहीं होती।
 
-With resource-based permissions, आप अपने बकेट के सब-डायरेक्टरियों के लिए permissions अलग से परिभाषित कर सकते हैं।
+With resource-based permissions, आप अपने bucket के sub-directories के लिए permissions अलग से परिभाषित कर सकते हैं।
 
 ### Bucket Versioning and MFA based delete
 
-जब Bucket Versioning सक्षम होता है, तो किसी भी क्रिया जो फ़ाइल को बदलने का प्रयास करती है, फ़ाइल का एक नया संस्करण उत्पन्न करेगी और पहले की सामग्री भी बनाए रखेगी। इसलिए यह उसकी सामग्री को ओवरराइट नहीं करेगा।
+जब bucket versioning सक्षम होता है, तो किसी भी कार्रवाई जो फ़ाइल को बदलने की कोशिश करती है, फ़ाइल का एक नया version बनाएगी, साथ ही उसी की पिछली सामग्री भी रखेगी। इसलिए यह उसकी सामग्री overwrite नहीं करेगा।
 
-इसके अलावा, **MFA based delete** S3 बकेट में फ़ाइलों के संस्करणों को हटने से रोकेगा और साथ ही Bucket Versioning को disabled होने से भी रोकेगा, इसलिए एक हमलावर इन फ़ाइलों को बदल नहीं पाएगा।
+Moreover, MFA based delete S3 bucket में फ़ाइलों के versions को delete होने से रोकेगा और साथ ही Bucket Versioning को disable होने से भी। इसलिए एक attacker इन फ़ाइलों को alter नहीं कर पाएगा।
 
 ### S3 Access logs
 
-कुछ बकेट के लिए **S3 access logging** (जो डिफ़ॉल्ट रूप से disabled है) सक्षम करना संभव है और लॉग्स को किसी दूसरे बकेट में सेव करके यह पता लगाया जा सकता है कि कौन बकेट तक पहुँच रहा है (दोनों बकेट एक ही region में होने चाहिए)।
+यह संभव है कि किसी bucket के लिए **S3 access login** को सक्षम किया जाए (जो डिफ़ॉल्ट रूप से disabled होता है) और logs को किसी दूसरे bucket में save किया जाए ताकि पता चल सके कि कौन bucket को access कर रहा है (दोनों buckets एक ही region में होने चाहिए)।
 
 ### S3 Presigned URLs
 
-एक presigned URL जनरेट करना संभव है जिसे आमतौर पर बकेट में किसी **निर्दिष्ट फ़ाइल तक पहुँचने के लिए** उपयोग किया जा सकता है। एक **presigned URL इस तरह दिखता है**:
+यह संभव है कि एक presigned URL generate किया जाए जिसे आमतौर पर bucket में निर्दिष्ट फ़ाइल तक **access the specified file** करने के लिए उपयोग किया जा सके। A **presigned URL looks like this**:
 ```
 https://<bucket-name>.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa
 ```
-एक presigned URL **cli का उपयोग करके उस principal के credentials से बनाया जा सकता है जिसके पास object तक access है** (यदि आप जिस account का उपयोग कर रहे हैं उसके पास access नहीं है, तो एक छोटा presigned URL बनाया जाएगा लेकिन वह बेकार होगा)
+एक presigned URL **cli से उस principal के credentials का उपयोग करके बनाया जा सकता है जिसके पास object तक access है** (यदि जिस account का आप उपयोग कर रहे हैं उसके पास access नहीं है, तो एक छोटा presigned URL बनाया जाएगा पर वह बेकार होगा)
 ```bash
 aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
 ```
 > [!NOTE]
-> presigned URL को जनरेट करने के लिए आवश्यक एकमात्र अनुमति वही अनुमति है जो दी जा रही है, इसलिए पिछले कमांड के लिए principal को केवल `s3:GetObject` अनुमति की आवश्यकता है
->
-> यह भी संभव है कि presigned URLs को **अन्य अनुमतियों** के साथ बनाया जाए:
+> presigned URL जेनरेट करने के लिए आवश्यक केवल अनुमति वही है जो दी जा रही है, इसलिए पिछले कमांड के लिए principal को आवश्यक केवल अनुमति `s3:GetObject` है
+
+यह भी संभव है कि **अन्य अनुमतियों** के साथ presigned URLs बनाए जा सकें:
 ```python
 import boto3
 url = boto3.client('s3').generate_presigned_url(
@@ -44,97 +44,97 @@ ExpiresIn=3600
 ```
 ### S3 एन्क्रिप्शन तंत्र
 
-**DEK का मतलब Data Encryption Key है** और यह वह key है जिसे हमेशा जेनरेट करके डेटा को encrypt करने के लिए उपयोग किया जाता है।
+**DEK means Data Encryption Key** और यह वह कुंजी है जिसे हमेशा उत्पन्न किया जाता है और डेटा को एन्क्रिप्ट करने के लिए उपयोग किया जाता है।
 
 <details>
 
-<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
+<summary><strong>सर्वर-साइड एन्क्रिप्शन S3 प्रबंधित कुंजियों के साथ, SSE-S3</strong></summary>
 
-यह विकल्प न्यूनतम कॉन्फ़िगरेशन मांगता है और encryption keys का पूरा प्रबंधन AWS द्वारा किया जाता है। आपको बस अपना डेटा upload करना है और S3 बाकी सारे पहलुओं को संभाल लेगा। प्रत्येक bucket को S3 account में एक bucket key असाइन किया जाता है।
+यह विकल्प न्यूनतम कॉन्फ़िगरेशन की आवश्यकता रखता है और उपयोग की जाने वाली एन्क्रिप्शन कुंजियों का सारा प्रबंधन AWS द्वारा किया जाता है। आपको बस **अपना डेटा अपलोड करें और S3 बाकी सभी पहलुओं को संभाल लेगा**। किसी S3 account के प्रत्येक bucket को एक bucket key आवंटित की जाती है।
 
-- Encryption:
-- Object Data + created plaintext DEK --> Encrypted data (S3 के अंदर स्टोर)
-- Created plaintext DEK + S3 Master Key --> Encrypted DEK (S3 में स्टोर) और plain text memory से हटा दिया जाता है
-- Decryption:
+- एन्क्रिप्शन:
+- Object Data + created plaintext DEK --> Encrypted data (stored inside S3)
+- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) और plain text मेमोरी से हटा दिया जाता है
+- डिक्रिप्शन:
 - Encrypted DEK + S3 Master Key --> Plaintext DEK
 - Plaintext DEK + Encrypted data --> Object Data
 
-कृपया ध्यान दें कि इस मामले में **key AWS द्वारा मैनेज की जाती है** (rotation केवल हर 3 साल). यदि आप अपनी खुद की key उपयोग करते हैं तो आप उसे rotate, disable और access control लागू कर पाएँगे।
+कृपया ध्यान दें कि इस मामले में **the key is managed by AWS** (rotation केवल हर 3 साल)। यदि आप अपनी खुद की key उपयोग करते हैं तो आप उसे rotate, disable और access control लागू कर सकेंगे।
 
 </details>
 
 <details>
 
-<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
+<summary><strong>सर्वर-साइड एन्क्रिप्शन KMS प्रबंधित कुंजियों के साथ, SSE-KMS</strong></summary>
 
-यह तरीका S3 को key management service का उपयोग करके आपके data encryption keys जेनरेट करने की अनुमति देता है। KMS आपको यह नियंत्रित करने की काफी लचीलापन देता है कि आपकी keys कैसे मैनेज हों। उदाहरण के लिए, आप CMK को disable, rotate कर सकते हैं, और उनके उपयोग के खिलाफ ऑडिट करने के लिए AWS Cloud Trail का उपयोग कर सकते हैं।
+यह विधि S3 को आपकी data encryption keys जनरेट करने के लिए key management service का उपयोग करने की अनुमति देती है। KMS आपको यह निर्धारित करने में बहुत अधिक लचीलापन देता है कि आपकी कुंजियाँ कैसे प्रबंधित होंगी। उदहारण के लिए, आप CMK को disable, rotate और access controls लागू कर सकते हैं, और उनके उपयोग का audit AWS Cloud Trail के माध्यम से कर सकते हैं।
 
-- Encryption:
-- S3 KMS CMK से data keys का request करता है
-- KMS एक CMK का उपयोग करके DEK plaintext और DEK encrypted का pair जेनरेट करता है और इन्हें S3 को भेजता है
-- S3 plaintext key का उपयोग करके डेटा को encrypt करता है, encrypted data और encrypted key को स्टोर करता है और plaintext key को memory से डिलीट कर देता है
-- Decryption:
-- S3 ऑब्जेक्ट के encrypted data key को decrypt करने के लिए KMS से अनुरोध करता है
-- KMS CMK के साथ data key को decrypt करके S3 को भेजता है
-- S3 ऑब्जेक्ट डेटा को decrypt कर देता है
+- एन्क्रिप्शन:
+- S3 KMS CMK से data keys का अनुरोध करता है
+- KMS CMK का उपयोग करके DEK का जोड़ा (plaintext और encrypted) जनरेट करता है और उन्हें S3 को भेजता है
+- S3 plaintext key का उपयोग करके डेटा को एन्क्रिप्ट करता है, एन्क्रिप्टेड डेटा और एन्क्रिप्टेड key स्टोर करता है और मेमोरी से plain text key हटा देता है
+- डिक्रिप्शन:
+- S3 ऑब्जेक्ट के एन्क्रिप्टेड data key को डिक्रिप्ट करने के लिए KMS से अनुरोध करता है
+- KMS CMK के साथ data key को डिक्रिप्ट करता है और इसे S3 को वापस भेजता है
+- S3 ऑब्जेक्ट डेटा को डिक्रिप्ट कर लेता है
 
 </details>
 
 <details>
 
-<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
+<summary><strong>सर्वर-साइड एन्क्रिप्शन customer provided keys के साथ, SSE-C</strong></summary>
 
-यह विकल्प आपको अपनी खुद की master key प्रदान करने का अवसर देता है जिसे आप शायद AWS के बाहर पहले से उपयोग कर रहे हों। आपका customer-provided key तब आपके डेटा के साथ S3 को भेजा जाएगा, जहाँ S3 आपके लिए encryption करेगा।
+यह विकल्प आपको अपनी स्वयं की master key प्रदान करने का अवसर देता है जिसे आप AWS के बाहर पहले से उपयोग कर रहे हो सकते हैं। आपकी customer-provided key तब आपके डेटा के साथ S3 को भेजी जाएगी, जहां S3 आपके लिए एन्क्रिप्शन करेगा।
 
-- Encryption:
-- यूजर ऑब्जेक्ट डेटा + Customer key को S3 को भेजता है
-- Customer key का उपयोग करके डेटा encrypt किया जाता है और encrypted data स्टोर किया जाता है
-- भविष्य के key validation के लिए customer key का एक salted HMAC value भी स्टोर किया जाता है
-- Customer key को memory से हटा दिया जाता है
-- Decryption:
-- यूजर customer key भेजता है
-- key को स्टोर किए गए HMAC value के खिलाफ validate किया जाता है
-- फिर customer provided key का उपयोग करके डेटा decrypt किया जाता है
+- एन्क्रिप्शन:
+- यूज़र ऑब्जेक्ट डेटा + Customer key को S3 को भेजता है
+- Customer key का उपयोग डेटा को एन्क्रिप्ट करने के लिए किया जाता है और एन्क्रिप्टेड डेटा स्टोर किया जाता है
+- भविष्य के key validation के लिए customer key का एक salted HMAC मान भी स्टोर किया जाता है
+- customer key मेमोरी से हटा दी जाती है
+- डिक्रिप्शन:
+- यूज़र customer key भेजता है
+- key को स्टोर किए गए HMAC मान के विरुद्ध मान्य किया जाता है
+- फिर customer provided key का उपयोग डेटा को डिक्रिप्ट करने के लिए किया जाता है
 
 </details>
 
 <details>
 
-<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
+<summary><strong>क्लाइंट-साइड एन्क्रिप्शन with KMS, CSE-KMS</strong></summary>
 
-SSE-KMS की तरह, यह भी key management service का उपयोग करके आपके data encryption keys जेनरेट करता है। हालांकि इस बार KMS को client के माध्यम से कॉल किया जाता है, न कि S3 द्वारा। एन्क्रिप्शन client-side पर होता है और encrypted data को स्टोर करने के लिए S3 को भेजा जाता है।
+SSE-KMS की तरह, यह भी key management service का उपयोग करके आपके data encryption keys जनरेट करता है। हालाँकि, इस बार KMS को client द्वारा कॉल किया जाता है न कि S3। एन्क्रिप्शन क्लाइंट-साइड होता है और फिर एन्क्रिप्टेड डेटा स्टोरेज के लिए S3 को भेजा जाता है।
 
-- Encryption:
-- Client KMS से data key का request करता है
-- KMS plaintext DEK और CMK के साथ encrypted DEK लौटाता है
-- दोनों keys क्लाइंट को भेजे जाते हैं
-- क्लाइंट plaintext DEK से डेटा encrypt करता है और S3 को encrypted data + encrypted DEK भेजता है (encrypted DEK को encrypted data के metadata के रूप में S3 में सेव किया जाता है)
-- Decryption:
-- encrypted DEK के साथ encrypted data क्लाइंट को भेजा जाता है
-- क्लाइंट CMK का उपयोग करके encrypted key को decrypt करने के लिए KMS से अनुरोध करता है और KMS plaintext DEK वापस भेजता है
-- क्लाइंट अब encrypted data को decrypt कर सकता है
+- एन्क्रिप्शन:
+- Client KMS से data key के लिए अनुरोध करता है
+- KMS plaintext DEK और CMK के साथ encrypted DEK वापस करता है
+- दोनों keys वापस भेजे जाते हैं
+- क्लाइंट फिर plaintext DEK से डेटा को एन्क्रिप्ट करता है और S3 को एन्क्रिप्टेड डेटा + encrypted DEK भेजता है (जो एन्क्रिप्टेड डेटा के metadata के रूप में S3 में सेव होता है)
+- डिक्रिप्शन:
+- क्लाइंट को एन्क्रिप्टेड डेटा और encrypted DEK भेजा जाता है
+- क्लाइंट KMS से CMK का उपयोग करके encrypted key को डिक्रिप्ट करने के लिए कहता है और KMS plaintext DEK वापस भेजता है
+- क्लाइंट अब एन्क्रिप्टेड डेटा को डिक्रिप्ट कर सकता है
 
 </details>
 
 <details>
 
-<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
+<summary><strong>क्लाइंट-साइड एन्क्रिप्शन customer provided keys के साथ, CSE-C</strong></summary>
 
-इस मैकेनिज्म का उपयोग करके, आप अपनी प्रदान की हुई keys का उपयोग कर सकते हैं और AWS-SDK client के माध्यम से अपने डेटा को S3 पर भेजने से पहले encrypt कर सकते हैं।
+इस तंत्र का उपयोग करते हुए, आप अपनी स्वयं की प्रदान की गई कुंजियों का उपयोग कर सकते हैं और AWS-SDK क्लाइंट का उपयोग करके अपने डेटा को S3 पर भेजने से पहले एन्क्रिप्ट कर सकते हैं।
 
-- Encryption:
-- क्लाइंट एक DEK जेनरेट करता है और plaintext डेटा को encrypt करता है
-- फिर अपनी custom CMK का उपयोग करके DEK को encrypt करता है
-- encrypted data + encrypted DEK को S3 में सबमिट किया जाता है जहाँ यह स्टोर होता है
-- Decryption:
-- S3 encrypted data और DEK भेजता है
-- चूँकि क्लाइंट के पास वही CMK है जिसका उपयोग DEK को encrypt करने के लिए हुआ था, वह DEK को decrypt करता है और फिर plaintext DEK से डेटा को decrypt करता है
+- एन्क्रिप्शन:
+- क्लाइंट एक DEK जनरेट करता है और plaintext डेटा को एन्क्रिप्ट करता है
+- फिर, अपनी custom CMK का उपयोग करके वह DEK को एन्क्रिप्ट करता है
+- एन्क्रिप्टेड डेटा + एन्क्रिप्टेड DEK को S3 को सबमिट करता है जहाँ यह स्टोर होता है
+- डिक्रिप्शन:
+- S3 एन्क्रिप्टेड डेटा और DEK भेजता है
+- चूँकि क्लाइंट के पास वह CMK पहले से मौजूद है जिसका उपयोग DEK को एन्क्रिप्ट करने में हुआ था, क्लाइंट DEK को डिक्रिप्ट करता है और फिर plaintext DEK का उपयोग करके डेटा को डिक्रिप्ट कर लेता है
 
 </details>
 
-### **Enumeration**
+### **इन्यूमरेशन**
 
-AWS orgs को compromise करने के पारंपरिक मुख्य तरीकों में से एक सार्वजनिक रूप से उपलब्ध buckets का compromise करना है। **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
+AWS orgs को समझौता करने के पारंपरिक मुख्य तरीकों में से एक सार्वजनिक रूप से पहुँच योग्य buckets का समझौता करना है। **आप इस पेज पर** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)** पा सकते हैं।**
 ```bash
 # Get buckets ACLs
 aws s3api get-bucket-acl --bucket <bucket-name>
@@ -229,16 +229,16 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
 ```
 ### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
 
-आप virtual hosted-style या path-style endpoint नाम का उपयोग करके dual-stack endpoint के माध्यम से किसी S3 bucket तक पहुंच सकते हैं। ये S3 को IPv6 के माध्यम से एक्सेस करने के लिए उपयोगी होते हैं।
+You can access an S3 bucket through a dual-stack endpoint by using a virtual hosted-style or a path-style endpoint name. These are useful to access S3 through IPv6.
 
-Dual-stack endpoints निम्नलिखित सिंटैक्स का उपयोग करते हैं:
+Dual-stack endpoints use the following syntax:
 
 - `bucketname.s3.dualstack.aws-region.amazonaws.com`
 - `s3.dualstack.aws-region.amazonaws.com/bucketname`
 
 ### Privesc
 
-निम्नलिखित पृष्ठ में आप यह देख सकते हैं कि कैसे S3 permissions का दुरुपयोग करके privileges बढ़ाए जा सकते हैं:
+आप निम्न पृष्ठ पर देख सकते हैं कि कैसे **abuse S3 permissions to escalate privileges**:
 
 {{#ref}}
 ../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -266,19 +266,19 @@ Dual-stack endpoints निम्नलिखित सिंटैक्स क
 
 ### S3 HTTP Cache Poisoning Issue <a href="#heading-s3-http-desync-cache-poisoning-issue" id="heading-s3-http-desync-cache-poisoning-issue"></a>
 
-[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) यह संभव था कि किसी arbitrary bucket की response को इस तरह cache किया जाए मानो वह किसी दूसरे bucket की हो। इसका दुरुपयोग करके उदाहरण के लिए javascript file responses को बदलकर उन पृष्ठों को compromise किया जा सकता था जो static code स्टोर करने के लिए S3 का उपयोग करते हैं।
+[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) किसी भी bucket की response को ऐसे cache किया जा सकता था जैसे वह किसी दूसरे bucket की हो। इसका दुरुपयोग करके, उदाहरण के लिए javascript file responses को बदलकर और S3 का उपयोग करके static code स्टोर करने वाले किसी भी पेज को compromise किया जा सकता था।
 
 ## Amazon Athena
 
-Amazon Athena एक interactive query service है जो Amazon Simple Storage Service (Amazon **S3**) में सीधे standard **SQL** का उपयोग करके data को analyze करना आसान बनाती है।
+Amazon Athena एक interactive query service है जो Amazon Simple Storage Service (Amazon **S3**) में सीधे standard **SQL** का उपयोग करके डेटा को आसानी से analyze करने में मदद करती है।
 
-आपको monitored S3 buckets में दिखाई देने वाली सामग्री के फॉर्मेट के साथ एक relational DB table तैयार करना होगा। उसके बाद, Amazon Athena logs से DB को populate कर सकेगा, ताकि आप उस पर query चला सकें।
+आपको उन monitored S3 buckets में दिखाई देने वाली सामग्री के format के साथ एक **relational DB table** तैयार करना होगा। फिर, Amazon Athena logs से DB को populate कर पाएगा, ताकि आप उस पर query चला सकें।
 
-Amazon Athena उस क्षमता का समर्थन करता है कि वह पहले से encrypted S3 data को query कर सके, और यदि कॉन्फ़िगर किया गया हो, तो **Athena query के परिणामों को भी encrypt कर सकता है जिन्हें बाद में S3 में store किया जा सकता है**।
+Amazon Athena उस क्षमता का समर्थन करता है कि वह पहले से encrypted S3 data को query कर सके और यदि इसे configure किया गया हो तो **Athena query के results को भी encrypt कर सकती है जिन्हें फिर S3 में store किया जा सकता है**।
 
-**परिणामों का यह encryption queried S3 डेटा के underlying डेटा से स्वतंत्र है**, मतलब कि भले ही S3 डेटा encrypted न हो, queried results encrypt किए जा सकते हैं। एक-दो बातों का ध्यान रखें: Amazon Athena केवल उन डेटा का समर्थन करता है जो निम्नलिखित S3 encryption methods के साथ encrypted हों: **SSE-S3, SSE-KMS, and CSE-KMS**।
+**This encryption of results is independent of the underlying queried S3 data**, अर्थात् भले ही S3 data encrypted न हो, queried results को encrypt किया जा सकता है। ध्यान रखने योग्य बात यह है कि Amazon Athena केवल उन डेटा का समर्थन करता है जो निम्न S3 encryption methods के साथ **encrypted** किए गए हों: **SSE-S3, SSE-KMS, and CSE-KMS**।
 
-SSE-C और CSE-C समर्थित नहीं हैं। इसके अलावा, यह समझना ज़रूरी है कि Amazon Athena केवल उन्हीं encrypted objects पर query चलाएगा जो उसी region में हों जहाँ से query चल रही है। यदि आपको KMS का उपयोग करके encrypted S3 data को query करना है, तो Athena user को query करने के लिए specific permissions की आवश्यकता होगी।
+SSE-C और CSE-C समर्थित नहीं हैं। इसके अतिरिक्त, यह समझना महत्वपूर्ण है कि Amazon Athena केवल उन्हीं **encrypted objects** पर query चलाएगा जो उसी region में हैं जहाँ query चल रही है। यदि आपको KMS का उपयोग करके encrypted S3 data को query करने की आवश्यकता है, तो Athena user को यह query करने के लिए specific permissions चाहिए होंगे।
 
 ### Enumeration
 ```bash