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-services/aws-s3-a
This commit is contained in:
+80
-90
@@ -1,4 +1,4 @@
|
||||
# AWS - VPC & Networking Basic Information
|
||||
# AWS - VPC & Networking बुनियादी जानकारी
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -25,171 +25,161 @@ Moreover, in order to **access Internet**, there are some interesting configurat
|
||||
|
||||
## VPC
|
||||
|
||||
Amazon **Virtual Private Cloud** (Amazon VPC) enables you to **launch AWS resources into a virtual network** that you've defined. This virtual network will have several subnets, Internet Gateways to access Internet, ACLs, Security groups, IPs...
|
||||
Amazon **Virtual Private Cloud** (Amazon VPC) आपको उस वर्चुअल नेटवर्क में AWS संसाधन लॉन्च करने की अनुमति देता है जिसे आप परिभाषित करते हैं। यह वर्चुअल नेटवर्क कई subnets, Internet Gateways (इंटरनेट एक्सेस के लिए), ACLs, Security groups, IPs आदि रखेगा।
|
||||
|
||||
### Subnets
|
||||
|
||||
Subnets helps to enforce a greater level of security. **Logical grouping of similar resources** also helps you to maintain an **ease of management** across your infrastructure.
|
||||
Subnets सुरक्षा का एक उच्च स्तर लागू करने में मदद करते हैं। समान संसाधनों का तार्किक समूह बनाकर आप अपने इंफ्रास्ट्रक्चर का प्रबंधन आसान रख सकते हैं।
|
||||
|
||||
- Valid CIDR are from a /16 netmask to a /28 netmask.
|
||||
- A subnet cannot be in different availability zones at the same time.
|
||||
- **AWS reserves the first three host IP addresses** of each subnet **for** **internal AWS usage**: he first host address used is for the VPC router. The second address is reserved for AWS DNS and the third address is reserved for future use.
|
||||
- It's called **public subnets** to those that have **direct access to the Internet, whereas private subnets do not.**
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/N_WTrTrDAHwN61FMKJvLSHVua2EM0IazHH1fSTg8JQfTChm-dLN9mn7wkjz2MlpD-uOUqtWdMZpqKOp4VxaHy5-5X66GD1K8y1UGc27r-GbHdFty9ImpXdcjEsC7u4vjxKme_B_HwDOUnG6camxENYECTw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="https://lh3.googleusercontent.com/MmjfVzGmV4jM7tO8lVoTKONoeqbq6E40DGeKUoo4kN-lmMDKnEiGNB-gGVx3EvjK9UV844im225CA8aAjomHf1Modt3MramHrHZdEGbeSZncWhVuT9R8f7tQZ2pXjdSJxeNfErmJ-0mmcUaV6dcU0TAd2A=s2048" alt=""><figcaption></figcaption></figure>
|
||||
- एक 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** कहा जाता है।
|
||||
|
||||
### Route Tables
|
||||
|
||||
Route tables determine the traffic routing for a subnet within a VPC. They determine which network traffic is forwarded to the internet or to a VPN connection. You will usually find access to the:
|
||||
Route tables किसी VPC के भीतर एक subnet के ट्रैफिक रूटिंग को निर्धारित करते हैं। ये तय करते हैं कि कौन सा नेटवर्क ट्रैफिक इंटरनेट या VPN कनेक्शन की ओर अग्रेषित होगा। आमतौर पर आप निम्न चीज़ों के लिए रूट पाएंगे:
|
||||
|
||||
- Local VPC
|
||||
- NAT
|
||||
- Internet Gateways / Egress-only Internet gateways (needed to give a VPC access to the Internet).
|
||||
- In order to make a subnet public you need to **create** and **attach** an **Internet gateway** to your VPC.
|
||||
- VPC endpoints (to access S3 from private networks)
|
||||
|
||||
In the following images you can check the differences in a default public network and a private one:
|
||||
|
||||
<figure><img src="https://lh3.googleusercontent.com/q4ASpcLAYqijdNMLhMLl8EoowDtTMU5I_7YCVfk7-5hxDyeQOik9ImHnD2SYy32XUA2qXjEbXTAxA1lP--znJASdhYOdBveDcrD42f9XBKZ3EmjJCazN3YPLC6oS0xtRMmfORuwCszmMt-KrAkH07_izwg=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="https://lh5.googleusercontent.com/30psylXAI0gRN6_LK-reP00aGIlMma64E1qafCVPunn6nS-y5jAO6Y2JiempKcf6-LFi7ScicYcOh7BbHEya2VWtksnFX_8SPXQf97tKkg2tNZzrArWbiDCCn2m2LP1QUq6MZ_KayH3yir7t8zpO7CEQOw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
- Internet Gateways / Egress-only Internet gateways (VPC को Internet का access देने के लिए जरूरी)।
|
||||
- किसी subnet को public बनाने के लिए आपको अपने VPC में एक **Internet gateway** **create** और **attach** करना होगा।
|
||||
- VPC endpoints (private नेटवर्क से S3 तक पहुँच के लिए)
|
||||
|
||||
### ACLs
|
||||
|
||||
**Network Access Control Lists (ACLs)**: Network ACLs are firewall rules that control incoming and outgoing network traffic to a subnet. They can be used to allow or deny traffic to specific IP addresses or ranges.
|
||||
**Network Access Control Lists (ACLs)**: Network ACLs वे फ़ायरवॉल नियम हैं जो किसी subnet के इनकमिंग और आउटगोइंग नेटवर्क ट्रैफिक को नियंत्रित करते हैं। इन्हें किसी विशिष्ट IP पता या रेंज के लिए ट्रैफिक allow या deny करने के लिए उपयोग किया जा सकता है।
|
||||
|
||||
- It’s most frequent to allow/deny access using security groups, but this is only way to completely cut established reverse shells. A modified rule in a security groups doesn’t stop already established connections
|
||||
- However, this apply to the whole subnetwork be careful when forbidding stuff because needed functionality might be disturbed
|
||||
- अक्सर access allow/deny करने के लिए security groups का उपयोग होता है, लेकिन subnet स्तर पर पूरी तरह से established reverse shells को काटने का यह एकमात्र तरीका हो सकता है। security group में बदला हुआ नियम पहले से established कनेक्शनों को तुरंत नहीं रोकता।
|
||||
- हालाँकि, यह पूरे subnetwork पर लागू होता है—इसलिए कुछ चीज़ें बंद करते समय सावधान रहें क्योंकि आवश्यक कार्यक्षमता प्रभावित हो सकती है।
|
||||
|
||||
### Security Groups
|
||||
|
||||
Security groups are a virtual **firewall** that control inbound and outbound network **traffic to instances** in a VPC. Relation 1 SG to M instances (usually 1 to 1).\
|
||||
Usually this is used to open dangerous ports in instances, such as port 22 for example:
|
||||
Security groups एक वर्चुअल **फ़ायरवॉल** हैं जो VPC में instances के लिए inbound और outbound नेटवर्क ट्रैफिक को नियंत्रित करते हैं। Relation 1 SG to 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_ is a **static IPv4 address** designed for dynamic cloud computing. An Elastic IP address is allocated to your AWS account, and is yours until you release it. By using an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account.
|
||||
An _Elastic IP address_ एक **static IPv4 address** है जिसे dynamic cloud computing के लिए डिज़ाइन किया गया है। एक Elastic IP पता आपके AWS अकाउंट को आवंटित किया जाता है, और जब तक आप इसे रिलीज़ नहीं करते यह आपका रहता है। एक Elastic IP का उपयोग करके, आप किसी instance या सॉफ़्टवेयर की विफलता को जल्दी से दूसरे instance पर उस पते को remap करके छिपा सकते हैं।
|
||||
|
||||
### Connection between subnets
|
||||
|
||||
By default, all subnets have the **automatic assigned of public IP addresses turned off** but it can be turned on.
|
||||
डिफ़ॉल्ट रूप से, सभी subnets में **automatic assigned of public IP addresses turned off** रहता है लेकिन इसे ऑन किया जा सकता है।
|
||||
|
||||
**A local route within a route table enables communication between VPC subnets.**
|
||||
|
||||
If you are **connection a subnet with a different subnet you cannot access the subnets connected** with the other subnet, you need to create connection with them directly. **This also applies to internet gateways**. You cannot go through a subnet connection to access internet, you need to assign the internet gateway to your subnet.
|
||||
यदि आप एक subnet को किसी दूसरे subnet से कनेक्ट कर रहे हैं, तो आप उस दूसरे से जुड़े अन्य subnets तक नहीं पहुँच पाएंगे; आपको उनके साथ सीधे connection बनाना होगा। **यह इंटरनेट gateways पर भी लागू होता है**। आप किसी subnet connection के रास्ते इंटरनेट तक नहीं जा सकते; आपको अपने subnet को इंटरनेट gateway असाइन करना होगा।
|
||||
|
||||
### VPC Peering
|
||||
|
||||
VPC peering allows you to **connect two or more VPCs together**, using IPV4 or IPV6, as if they were a part of the same network.
|
||||
VPC peering आपको दो या अधिक VPCs को IPV4 या IPV6 उपयोग करते हुए एक दूसरे से जोड़ने की अनुमति देता है, जैसे कि वे एक ही नेटवर्क का हिस्सा हों।
|
||||
|
||||
Once the peer connectivity is established, **resources in one VPC can access resources in the other**. The connectivity between the VPCs is implemented through the existing AWS network infrastructure, and so it is highly available with no bandwidth bottleneck. As **peered connections operate as if they were part of the same network**, there are restrictions when it comes to your CIDR block ranges that can be used.\
|
||||
If you have **overlapping or duplicate CIDR** ranges for your VPC, then **you'll not be able to peer the VPCs** together.\
|
||||
Each AWS VPC will **only communicate with its peer**. As an example, if you have a peering connection between VPC 1 and VPC 2, and another connection between VPC 2 and VPC 3 as shown, then VPC 1 and 2 could communicate with each other directly, as can VPC 2 and VPC 3, however, VPC 1 and VPC 3 could not. **You can't route through one VPC to get to another.**
|
||||
एक बार 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 तक नहीं पहुँच सकते।**
|
||||
|
||||
### **VPC Flow Logs**
|
||||
|
||||
Within your VPC, you could potentially have hundreds or even thousands of resources all communicating between different subnets both public and private and also between different VPCs through VPC peering connections. **VPC Flow Logs allow you to capture IP traffic information that flows between your network interfaces of your resources within your VPC**.
|
||||
आपके VPC के भीतर सैकड़ों या हजारों संसाधन हो सकते हैं जो अलग-अलग subnets (public और private दोनों) और VPC peering connections के माध्यम से संवाद कर रहे हैं। **VPC Flow Logs आपको आपके VPC के भीतर आपके संसाधनों के network interfaces के बीच बहने वाली IP ट्रैफ़िक जानकारी कैप्चर करने देते हैं**।
|
||||
|
||||
Unlike S3 access logs and CloudFront access logs, the **log data generated by VPC Flow Logs is not stored in S3. Instead, the log data captured is sent to CloudWatch logs**.
|
||||
S3 access logs और CloudFront access logs के विपरीत, **VPC Flow Logs द्वारा जनरेट किया गया log data S3 में संग्रहीत नहीं किया जाता। बल्कि, पकड़ा गया log data CloudWatch logs को भेजा जाता है**।
|
||||
|
||||
Limitations:
|
||||
|
||||
- If you are running a VPC peered connection, then you'll only be able to see flow logs of peered VPCs that are within the same account.
|
||||
- If you are still running resources within the EC2-Classic environment, then unfortunately you are not able to retrieve information from their interfaces
|
||||
- Once a VPC Flow Log has been created, it cannot be changed. To alter the VPC Flow Log configuration, you need to delete it and then recreate a new one.
|
||||
- The following traffic is not monitored and captured by the logs. DHCP traffic within the VPC, traffic from instances destined for the Amazon DNS Server.
|
||||
- Any traffic destined to the IP address for the VPC default router and traffic to and from the following addresses, 169.254.169.254 which is used for gathering instance metadata, and 169.254.169.123 which is used for the Amazon Time Sync Service.
|
||||
- Traffic relating to an Amazon Windows activation license from a Windows instance
|
||||
- Traffic between a network load balancer interface and an endpoint network interface
|
||||
- यदि आप एक 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 के बीच ट्रैफ़िक
|
||||
|
||||
For every network interface that publishes data to the CloudWatch log group, it will use a different log stream. And within each of these streams, there will be the flow log event data that shows the content of the log entries. Each of these **logs captures data during a window of approximately 10 to 15 minutes**.
|
||||
जो भी network interface CloudWatch log group को डाटा प्रकाशित करता है, वह एक अलग log stream उपयोग करेगा। और इन streams में प्रत्येक में flow log event data होगा जो log entries की सामग्री दिखाता है। इनमें से प्रत्येक **logs लगभग 10 से 15 मिनट की विंडो के दौरान डाटा कैप्चर करते हैं**।
|
||||
|
||||
## VPN
|
||||
|
||||
### Basic AWS VPN Components
|
||||
|
||||
1. **Customer Gateway**:
|
||||
- A Customer Gateway is a resource that you create in AWS to represent your side of a VPN connection.
|
||||
- It is essentially a physical device or software application on your side of the Site-to-Site VPN connection.
|
||||
- You provide routing information and the public IP address of your network device (such as a router or a firewall) to AWS to create a Customer Gateway.
|
||||
- It serves as a reference point for setting up the VPN connection and doesn't incur additional charges.
|
||||
- Customer Gateway वह resource है जिसे आप AWS में बनाते हैं ताकि आपके तरफ़ के VPN connection का प्रतिनिधित्व हो सके।
|
||||
- यह मूल रूप से आपकी साइट-टू-साइट VPN कनेक्शन की तरफ़ पर एक भौतिक डिवाइस या सॉफ़्टवेयर एप्लिकेशन होता है।
|
||||
- आप अपने नेटवर्क डिवाइस (जैसे router या firewall) का public IP address और routing जानकारी AWS को प्रदान करते हैं ताकि Customer Gateway बनाया जा सके।
|
||||
- यह VPN connection सेटअप करने के लिए एक reference point के रूप में कार्य करता है और इससे अतिरिक्त चार्ज नहीं लगता।
|
||||
2. **Virtual Private Gateway**:
|
||||
- A Virtual Private Gateway (VPG) is the VPN concentrator on the Amazon side of the Site-to-Site VPN connection.
|
||||
- It is attached to your VPC and serves as the target for your VPN connection.
|
||||
- VPG is the AWS side endpoint for the VPN connection.
|
||||
- It handles the secure communication between your VPC and your on-premises network.
|
||||
- Virtual Private Gateway (VPG) Amazon की तरफ़ वाला VPN concentrator है जो Site-to-Site VPN connection के लिए होता है।
|
||||
- यह आपके VPC से जुड़ा होता है और आपके VPN connection के लिए target के रूप में कार्य करता है।
|
||||
- VPG वह AWS साइड endpoint है VPN कनेक्शन का।
|
||||
- यह आपके VPC और आपके on-premises नेटवर्क के बीच सुरक्षित संचार को संभालता है।
|
||||
3. **Site-to-Site VPN Connection**:
|
||||
- A Site-to-Site VPN connection connects your on-premises network to a VPC through a secure, IPsec VPN tunnel.
|
||||
- This type of connection requires a Customer Gateway and a Virtual Private Gateway.
|
||||
- It's used for secure, stable, and consistent communication between your data center or network and your AWS environment.
|
||||
- Typically used for regular, long-term connections and is billed based on the amount of data transferred over the connection.
|
||||
- Site-to-Site VPN connection आपके on-premises नेटवर्क को एक secure IPsec VPN tunnel के माध्यम से एक VPC से जोड़ता है।
|
||||
- इस प्रकार के कनेक्शन के लिए एक Customer Gateway और एक Virtual Private Gateway की आवश्यकता होती है।
|
||||
- यह आपके डेटा सेंटर या नेटवर्क और आपके AWS वातावरण के बीच सुरक्षित, स्थिर और लगातार संचार के लिए उपयोग किया जाता है।
|
||||
- आमतौर पर यह नियमित, दीर्घकालिक कनेक्शनों के लिए उपयोग किया जाता है और कनेक्शन के माध्यम से भेजी गई डेटा की मात्रा के आधार पर बिल किया जाता है।
|
||||
4. **Client VPN Endpoint**:
|
||||
- A Client VPN endpoint is a resource that you create in AWS to enable and manage client VPN sessions.
|
||||
- It is used for allowing individual devices (like laptops, smartphones, etc.) to securely connect to AWS resources or your on-premises network.
|
||||
- It differs from Site-to-Site VPN in that it is designed for individual clients rather than connecting entire networks.
|
||||
- With Client VPN, each client device uses a VPN client software to establish a secure connection.
|
||||
- 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 स्थापित करता है।
|
||||
|
||||
### Site-to-Site VPN
|
||||
|
||||
**Connect your on premisses network with your VPC.**
|
||||
**अपने on premisses नेटवर्क को अपने VPC से कनेक्ट करें।**
|
||||
|
||||
- **VPN connection**: A secure connection between your on-premises equipment and your VPCs.
|
||||
- **VPN tunnel**: An encrypted link where data can pass from the customer network to or from AWS.
|
||||
- **VPN connection**: आपके on-premises उपकरण और आपके VPCs के बीच एक secure connection।
|
||||
- **VPN tunnel**: एक encrypted लिंक जहाँ डेटा customer नेटवर्क से AWS को या AWS से customer नेटवर्क को पार कर सकता है।
|
||||
|
||||
Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability.
|
||||
प्रत्येक VPN connection में दो VPN tunnels शामिल होते हैं जिन्हें आप उच्च उपलब्धता के लिए समानांतर रूप से उपयोग कर सकते हैं।
|
||||
|
||||
- **Customer gateway**: An AWS resource which provides information to AWS about your customer gateway device.
|
||||
- **Customer gateway device**: A physical device or software application on your side of the Site-to-Site VPN connection.
|
||||
- **Virtual private gateway**: The VPN concentrator on the Amazon side of the Site-to-Site VPN connection. You use a virtual private gateway or a transit gateway as the gateway for the Amazon side of the Site-to-Site VPN connection.
|
||||
- **Transit gateway**: A transit hub that can be used to interconnect your VPCs and on-premises networks. You use a transit gateway or virtual private gateway as the gateway for the Amazon side of the Site-to-Site VPN connection.
|
||||
- **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 का उपयोग करते हैं।
|
||||
|
||||
#### Limitations
|
||||
|
||||
- IPv6 traffic is not supported for VPN connections on a virtual private gateway.
|
||||
- An AWS VPN connection does not support Path MTU Discovery.
|
||||
- IPv6 ट्रैफ़िक virtual private gateway पर VPN connections के लिए समर्थित नहीं है।
|
||||
- AWS VPN connection Path MTU Discovery को सपोर्ट नहीं करता।
|
||||
|
||||
In addition, take the following into consideration when you use Site-to-Site VPN.
|
||||
इसके अलावा, Site-to-Site VPN का उपयोग करते समय निम्न बातों का ध्यान रखें:
|
||||
|
||||
- When connecting your VPCs to a common on-premises network, we recommend that you use non-overlapping CIDR blocks for your networks.
|
||||
- जब आप अपने VPCs को एक सामान्य on-premises नेटवर्क से कनेक्ट कर रहे हों, तो हम सुझाव देते हैं कि आप अपने नेटवर्क्स के लिए non-overlapping CIDR blocks का उपयोग करें।
|
||||
|
||||
### Client VPN <a href="#what-is-components" id="what-is-components"></a>
|
||||
|
||||
**Connect from your machine to your VPC**
|
||||
**अपने मशीन से अपने VPC से कनेक्ट करें**
|
||||
|
||||
#### Concepts
|
||||
|
||||
- **Client VPN endpoint:** The resource that you create and configure to enable and manage client VPN sessions. It is the resource where all client VPN sessions are terminated.
|
||||
- **Target network:** A target network is the network that you associate with a Client VPN endpoint. **A subnet from a VPC is a target network**. Associating a subnet with a Client VPN endpoint enables you to establish VPN sessions. You can associate multiple subnets with a Client VPN endpoint for high availability. All subnets must be from the same VPC. Each subnet must belong to a different Availability Zone.
|
||||
- **Route**: Each Client VPN endpoint has a route table that describes the available destination network routes. Each route in the route table specifies the path for traffic to specific resources or networks.
|
||||
- **Authorization rules:** An authorization rule **restricts the users who can access a network**. For a specified network, you configure the Active Directory or identity provider (IdP) group that is allowed access. Only users belonging to this group can access the specified network. **By default, there are no authorization rules** and you must configure authorization rules to enable users to access resources and networks.
|
||||
- **Client:** The end user connecting to the Client VPN endpoint to establish a VPN session. End users need to download an OpenVPN client and use the Client VPN configuration file that you created to establish a VPN session.
|
||||
- **Client CIDR range:** An IP address range from which to assign client IP addresses. Each connection to the Client VPN endpoint is assigned a unique IP address from the client CIDR range. You choose the client CIDR range, for example, `10.2.0.0/16`.
|
||||
- **Client VPN ports:** AWS Client VPN supports ports 443 and 1194 for both TCP and UDP. The default is port 443.
|
||||
- **Client VPN network interfaces:** When you associate a subnet with your Client VPN endpoint, we create Client VPN network interfaces in that subnet. **Traffic that's sent to the VPC from the Client VPN endpoint is sent through a Client VPN network interface**. Source network address translation (SNAT) is then applied, where the source IP address from the client CIDR range is translated to the Client VPN network interface IP address.
|
||||
- **Connection logging:** You can enable connection logging for your Client VPN endpoint to log connection events. You can use this information to run forensics, analyze how your Client VPN endpoint is being used, or debug connection issues.
|
||||
- **Self-service portal:** You can enable a self-service portal for your Client VPN endpoint. Clients can log into the web-based portal using their credentials and download the latest version of the Client VPN endpoint configuration file, or the latest version of the AWS provided client.
|
||||
- **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 का नवीनतम संस्करण डाउनलोड कर सकते हैं।
|
||||
|
||||
#### 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.**
|
||||
- A **portion of the addresses** in the client CIDR range are used to **support the availability** model of the Client VPN endpoint, and cannot be assigned to clients. Therefore, we recommend that you **assign a CIDR block that contains twice the number of IP addresses that are required** to enable the maximum number of concurrent connections that you plan to support on the Client VPN endpoint.
|
||||
- The **client CIDR range cannot be changed** after you create the Client VPN endpoint.
|
||||
- The **subnets** associated with a Client VPN endpoint **must be in the same VPC**.
|
||||
- You **cannot associate multiple subnets from the same Availability Zone with a Client VPN endpoint**.
|
||||
- A Client VPN endpoint **does not support subnet associations in a dedicated tenancy VPC**.
|
||||
- Client VPN supports **IPv4** traffic only.
|
||||
- Client VPN is **not** Federal Information Processing Standards (**FIPS**) **compliant**.
|
||||
- If multi-factor authentication (MFA) is disabled for your Active Directory, a user password cannot be in the following format.
|
||||
- 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 VPN केवल **IPv4** ट्रैफ़िक का समर्थन करता है।
|
||||
- Client VPN **FIPS** (Federal Information Processing Standards) के अनुरूप नहीं है।
|
||||
- यदि आपके Active Directory के लिए multi-factor authentication (MFA) अक्षम है, तो एक user password निम्न प्रारूप में नहीं हो सकता।
|
||||
|
||||
```
|
||||
SCRV1:<base64_encoded_string>:<base64_encoded_string>
|
||||
```
|
||||
|
||||
- The self-service portal is **not available for clients that authenticate using mutual authentication**.
|
||||
- Self-service portal उन clients के लिए उपलब्ध नहीं है जो mutual authentication का उपयोग करके authenticate करते हैं।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.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** शामिल हैं। कोई भी **user इन विकल्पों को सक्षम कर सकता है** ताकि डेटा सुरक्षा प्राप्त की जा सके। **Data replication** AWS की एक आंतरिक सुविधा है जहाँ **S3 अपने प्रत्येक object को सभी Availability Zones में स्वचालित रूप से replicate करता है** और इस मामले में संगठन को इसे सक्षम करने की आवश्यकता नहीं होती।
|
||||
Amazon S3 REST में डेटा की **सुरक्षा** प्राप्त करने के लिए कई विकल्प प्रदान करता है। विकल्पों में **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** और **MFA** **based delete** शामिल हैं। **उपयोगकर्ता** डेटा सुरक्षा प्राप्त करने के लिए इन किसी भी विकल्प को सक्षम कर सकता है। **Data replication** AWS की एक आंतरिक सुविधा है जहाँ **S3 स्वचालित रूप से प्रत्येक ऑब्जेक्ट को सभी Availability Zones में प्रतिकृत करता है** और इस मामले में संगठन को इसे सक्षम करने की आवश्यकता नहीं होती है।
|
||||
|
||||
With resource-based permissions, you can define permissions for sub-directories of your bucket separately.
|
||||
With resource-based permissions, आप अपने बकेट के सब-डायरेक्टरियों के लिए permissions अलग से परिभाषित कर सकते हैं।
|
||||
|
||||
### Bucket Versioning and MFA based delete
|
||||
|
||||
जब Bucket Versioning सक्षम होता है, तो किसी भी कार्रवाई जो किसी फ़ाइल को बदलने की कोशिश करती है, फ़ाइल का नया version जनरेट कर देगी और साथ ही उसकी पिछली सामग्री भी रखेगी। इसलिए यह उसकी सामग्री को overwrite नहीं करेगा।
|
||||
जब Bucket Versioning सक्षम होता है, तो किसी भी क्रिया जो फ़ाइल को बदलने का प्रयास करती है, फ़ाइल का एक नया संस्करण उत्पन्न करेगी और पहले की सामग्री भी बनाए रखेगी। इसलिए यह उसकी सामग्री को ओवरराइट नहीं करेगा।
|
||||
|
||||
Moreover, MFA based delete S3 bucket में फ़ाइलों के versions को हटने से रोकेगा और साथ ही Bucket Versioning को disabled होने से भी रोकेगा, इसलिए कोई attacker इन फ़ाइलों को बदल नहीं पाएगा।
|
||||
इसके अलावा, **MFA based delete** S3 बकेट में फ़ाइलों के संस्करणों को हटने से रोकेगा और साथ ही Bucket Versioning को disabled होने से भी रोकेगा, इसलिए एक हमलावर इन फ़ाइलों को बदल नहीं पाएगा।
|
||||
|
||||
### S3 Access logs
|
||||
|
||||
किसी bucket पर **S3 access login** सक्षम करना (जो डिफ़ॉल्ट रूप से disabled होता है) और logs को किसी अलग bucket में save करना संभव है ताकि यह पता चल सके कि कौन bucket को access कर रहा है (दोनों buckets एक ही region में होने चाहिए)।
|
||||
कुछ बकेट के लिए **S3 access logging** (जो डिफ़ॉल्ट रूप से disabled है) सक्षम करना संभव है और लॉग्स को किसी दूसरे बकेट में सेव करके यह पता लगाया जा सकता है कि कौन बकेट तक पहुँच रहा है (दोनों बकेट एक ही region में होने चाहिए)।
|
||||
|
||||
### S3 Presigned URLs
|
||||
|
||||
यह संभव है कि आप एक presigned URL जनरेट करें जिसे आमतौर पर bucket में निर्दिष्ट फ़ाइल को **access** करने के लिए उपयोग किया जा सकता है। एक **presigned URL इस तरह दिखता है**:
|
||||
एक presigned URL जनरेट करना संभव है जिसे आमतौर पर बकेट में किसी **निर्दिष्ट फ़ाइल तक पहुँचने के लिए** उपयोग किया जा सकता है। एक **presigned URL इस तरह दिखता है**:
|
||||
```
|
||||
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
|
||||
```
|
||||
A 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 बनाने के लिए केवल आवश्यक permission वही permission है जो दी जा रही है, इसलिए पिछले कमांड के लिए principal को केवल `s3:GetObject` permission की ही ज़रूरत है
|
||||
> presigned URL को जनरेट करने के लिए आवश्यक एकमात्र अनुमति वही अनुमति है जो दी जा रही है, इसलिए पिछले कमांड के लिए principal को केवल `s3:GetObject` अनुमति की आवश्यकता है
|
||||
>
|
||||
It's also possible to create presigned URLs with **other permissions**:
|
||||
> यह भी संभव है कि presigned URLs को **अन्य अनुमतियों** के साथ बनाया जाए:
|
||||
```python
|
||||
import boto3
|
||||
url = boto3.client('s3').generate_presigned_url(
|
||||
@@ -42,24 +42,24 @@ Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'},
|
||||
ExpiresIn=3600
|
||||
)
|
||||
```
|
||||
### S3 एन्क्रिप्शन मैकेनिज़्म
|
||||
### S3 एन्क्रिप्शन तंत्र
|
||||
|
||||
**DEK means Data Encryption Key** और यह वह key है जो हमेशा जेनरेट की जाती है और डेटा को एन्क्रिप्ट करने के लिए उपयोग होती है।
|
||||
**DEK का मतलब Data Encryption Key है** और यह वह key है जिसे हमेशा जेनरेट करके डेटा को encrypt करने के लिए उपयोग किया जाता है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
|
||||
|
||||
यह विकल्प न्यूनतम कॉन्फ़िगरेशन मांगता है और encryption keys का पूरा प्रबंधन AWS द्वारा किया जाता है। आपको बस अपना डेटा अपलोड करना है और S3 बाकी सब संभाल लेगा। प्रत्येक bucket को S3 account में एक bucket key असाइन की जाती है।
|
||||
यह विकल्प न्यूनतम कॉन्फ़िगरेशन मांगता है और encryption keys का पूरा प्रबंधन AWS द्वारा किया जाता है। आपको बस अपना डेटा upload करना है और S3 बाकी सारे पहलुओं को संभाल लेगा। प्रत्येक bucket को S3 account में एक bucket key असाइन किया जाता है।
|
||||
|
||||
- एन्क्रिप्शन:
|
||||
- ऑब्जेक्ट डेटा + created plaintext DEK --> Encrypted data (stored inside S3)
|
||||
- Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) और plain text मेमोरी से डिलीट कर दिया जाता है
|
||||
- डीक्रिप्शन:
|
||||
- Encryption:
|
||||
- Object Data + created plaintext DEK --> Encrypted data (S3 के अंदर स्टोर)
|
||||
- Created plaintext DEK + S3 Master Key --> Encrypted DEK (S3 में स्टोर) और plain text memory से हटा दिया जाता है
|
||||
- Decryption:
|
||||
- Encrypted DEK + S3 Master Key --> Plaintext DEK
|
||||
- Plaintext DEK + Encrypted data --> Object Data
|
||||
|
||||
कृपया ध्यान दें कि इस केस में **key AWS द्वारा मैनेज की जाती है** (rotation केवल हर 3 साल)। अगर आप अपनी खुद की key इस्तेमाल करेंगे तो आप उसे rotate, disable और access control लागू कर सकेंगे।
|
||||
कृपया ध्यान दें कि इस मामले में **key AWS द्वारा मैनेज की जाती है** (rotation केवल हर 3 साल). यदि आप अपनी खुद की key उपयोग करते हैं तो आप उसे rotate, disable और access control लागू कर पाएँगे।
|
||||
|
||||
</details>
|
||||
|
||||
@@ -67,16 +67,16 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
|
||||
|
||||
यह मेथड S3 को key management service का उपयोग करके आपके data encryption keys जेनरेट करने की अनुमति देती है। KMS आपको keys के प्रबंधन में काफी अधिक लचीलापन देता है। उदाहरण के लिए, आप CMK को disable, rotate और उस पर access controls लागू कर सकते हैं, तथा उनके उपयोग के खिलाफ ऑर्डर करने के लिए AWS Cloud Trail का उपयोग कर सकते हैं।
|
||||
यह तरीका S3 को key management service का उपयोग करके आपके data encryption keys जेनरेट करने की अनुमति देता है। KMS आपको यह नियंत्रित करने की काफी लचीलापन देता है कि आपकी keys कैसे मैनेज हों। उदाहरण के लिए, आप CMK को disable, rotate कर सकते हैं, और उनके उपयोग के खिलाफ ऑडिट करने के लिए AWS Cloud Trail का उपयोग कर सकते हैं।
|
||||
|
||||
- एन्क्रिप्शन:
|
||||
- S3 KMS CMK से data keys रिक्वेस्ट करता है
|
||||
- KMS एक CMK का उपयोग करके DEK plaintext और DEK encrypted का पेयर जनरेट करता है और उन्हें S£ को भेजता है
|
||||
- S3 plaintext key का उपयोग करके डेटा को एन्क्रिप्ट करता है, एन्क्रिप्टेड डेटा और encrypted key स्टोर करता है और plaintext key को मेमोरी से डिलीट कर देता है
|
||||
- डीक्रिप्शन:
|
||||
- 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 करता है
|
||||
- KMS CMK के साथ data key को decrypt करके S3 को भेजता है
|
||||
- S3 ऑब्जेक्ट डेटा को decrypt कर देता है
|
||||
|
||||
</details>
|
||||
|
||||
@@ -84,17 +84,17 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
|
||||
|
||||
यह विकल्प आपको अपनी खुद की master key प्रदान करने का मौका देता है जिसे आप AWS के बाहर उपयोग कर रहे होंगे। आपकी customer-provided key तब आपके डेटा के साथ S3 को भेजी जाएगी, जहाँ S3 आपके लिए एन्क्रिप्शन कर देगा।
|
||||
यह विकल्प आपको अपनी खुद की master key प्रदान करने का अवसर देता है जिसे आप शायद AWS के बाहर पहले से उपयोग कर रहे हों। आपका customer-provided key तब आपके डेटा के साथ S3 को भेजा जाएगा, जहाँ S3 आपके लिए encryption करेगा।
|
||||
|
||||
- एन्क्रिप्शन:
|
||||
- उपयोगकर्ता ऑब्जेक्ट डेटा + Customer key को S3 पर भेजता है
|
||||
- Customer key का उपयोग डेटा को एन्क्रिप्ट करने के लिए किया जाता है और एन्क्रिप्टेड डेटा स्टोर किया जाता है
|
||||
- customer key का एक salted HMAC value भी भविष्य के key validation के लिए स्टोर किया जाता है
|
||||
- customer key मेमोरी से डिलीट कर दी जाती है
|
||||
- डीक्रिप्शन:
|
||||
- उपयोगकर्ता customer key भेजता है
|
||||
- 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 provided key का उपयोग करके डेटा decrypt किया जाता है
|
||||
|
||||
</details>
|
||||
|
||||
@@ -102,17 +102,17 @@ ExpiresIn=3600
|
||||
|
||||
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
|
||||
|
||||
SSE-KMS की तरह ही, यह भी key management service का उपयोग करके आपके data encryption keys जेनरेट करता है। हालाँकि इस बार KMS को client द्वारा कॉल किया जाता है, न कि S3 द्वारा। एन्क्रिप्शन क्लाइंट-साइड होता है और एन्क्रिप्टेड डेटा को स्टोर करने के लिए S3 पर भेज दिया जाता है।
|
||||
SSE-KMS की तरह, यह भी key management service का उपयोग करके आपके data encryption keys जेनरेट करता है। हालांकि इस बार KMS को client के माध्यम से कॉल किया जाता है, न कि S3 द्वारा। एन्क्रिप्शन client-side पर होता है और encrypted data को स्टोर करने के लिए S3 को भेजा जाता है।
|
||||
|
||||
- एन्क्रिप्शन:
|
||||
- Client KMS से data key के लिए request करता है
|
||||
- KMS plaintext DEK और CMK के साथ encrypted DEK रिटर्न करता है
|
||||
- दोनों keys वापस भेजे जाते हैं
|
||||
- क्लाइंट फिर plaintext DEK से डेटा को एन्क्रिप्ट करता है और S3 को encrypted data + encrypted DEK भेजता है (जो कि S3 के अंदर encrypted डेटा के metadata के रूप में सेव होता है)
|
||||
- डीक्रिप्शन:
|
||||
- encrypted data के साथ encrypted DEK क्लाइंट को भेजा जाता है
|
||||
- क्लाइंट KMS से CMK का उपयोग करके encrypted key को decrypt करने के लिए कहता है और KMS plaintext DEK वापस भेजता है
|
||||
- क्लाइंट अब encrypted डेटा को decrypt कर सकता है
|
||||
- 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 कर सकता है
|
||||
|
||||
</details>
|
||||
|
||||
@@ -120,21 +120,21 @@ SSE-KMS की तरह ही, यह भी key management service का उ
|
||||
|
||||
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
|
||||
|
||||
इस मेकेनिज़्म का उपयोग करके आप अपनी स्वयं की प्रदान की हुई keys का उपयोग कर सकते हैं और AWS-SDK client का उपयोग करके डेटा भेजने से पहले उसे encrypt कर सकते हैं।
|
||||
इस मैकेनिज्म का उपयोग करके, आप अपनी प्रदान की हुई keys का उपयोग कर सकते हैं और AWS-SDK client के माध्यम से अपने डेटा को S3 पर भेजने से पहले encrypt कर सकते हैं।
|
||||
|
||||
- एन्क्रिप्शन:
|
||||
- क्लाइंट एक DEK जेनरेट करता है और plaintext डेटा को एन्क्रिप्ट करता है
|
||||
- फिर, अपनी custom CMK का उपयोग करके वह DEK को एन्क्रिप्ट करता है
|
||||
- encrypted data + encrypted DEK को S3 पर सबमिट करता है जहाँ यह स्टोर होता है
|
||||
- डीक्रिप्शन:
|
||||
- Encryption:
|
||||
- क्लाइंट एक DEK जेनरेट करता है और plaintext डेटा को encrypt करता है
|
||||
- फिर अपनी custom CMK का उपयोग करके DEK को encrypt करता है
|
||||
- encrypted data + encrypted DEK को S3 में सबमिट किया जाता है जहाँ यह स्टोर होता है
|
||||
- Decryption:
|
||||
- S3 encrypted data और DEK भेजता है
|
||||
- चूँकि क्लाइंट के पास वह CMK पहले से मौजूद है जिसका उपयोग DEK को एन्क्रिप्ट करने के लिए हुआ था, वह DEK को decrypt करता है और फिर plaintext DEK से डेटा को decrypt करता है
|
||||
- चूँकि क्लाइंट के पास वही CMK है जिसका उपयोग DEK को encrypt करने के लिए हुआ था, वह DEK को decrypt करता है और फिर plaintext DEK से डेटा को decrypt करता है
|
||||
|
||||
</details>
|
||||
|
||||
### **Enumeration**
|
||||
|
||||
AWS orgs को compromise करने के पारंपरिक प्रमुख तरीकों में से एक सार्वजनिक रूप से accessible buckets को compromise करना है। **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
|
||||
AWS orgs को compromise करने के पारंपरिक मुख्य तरीकों में से एक सार्वजनिक रूप से उपलब्ध buckets का compromise करना है। **You can find** [**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>
|
||||
@@ -150,7 +150,7 @@ aws s3api list-buckets
|
||||
|
||||
# list content of bucket (no creds)
|
||||
aws s3 ls s3://bucket-name --no-sign-request
|
||||
aws s3 ls s3://bucket-name --recursive
|
||||
aws s3 ls s3://bucket-name --recursive --no-sign-request
|
||||
|
||||
# list content of bucket (with creds)
|
||||
aws s3 ls s3://bucket-name
|
||||
@@ -229,7 +229,7 @@ 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 के माध्यम से एक्सेस करने के लिए उपयोगी हैं।
|
||||
आप virtual hosted-style या path-style endpoint नाम का उपयोग करके dual-stack endpoint के माध्यम से किसी S3 bucket तक पहुंच सकते हैं। ये S3 को IPv6 के माध्यम से एक्सेस करने के लिए उपयोगी होते हैं।
|
||||
|
||||
Dual-stack endpoints निम्नलिखित सिंटैक्स का उपयोग करते हैं:
|
||||
|
||||
@@ -238,7 +238,7 @@ Dual-stack endpoints निम्नलिखित सिंटैक्स क
|
||||
|
||||
### Privesc
|
||||
|
||||
नीचे दिए पृष्ठ में आप देख सकते हैं कि कैसे **abuse S3 permissions to escalate privileges**:
|
||||
निम्नलिखित पृष्ठ में आप यह देख सकते हैं कि कैसे S3 permissions का दुरुपयोग करके 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>
|
||||
|
||||
[**इस रिसर्च के अनुसार**](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 किया जा सकता था।
|
||||
[**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 का उपयोग करते हैं।
|
||||
|
||||
## Amazon Athena
|
||||
|
||||
Amazon Athena एक interactive query service है जो Amazon Simple Storage Service (Amazon **S3**) में सीधे standard **SQL** का उपयोग करके **डेटा का विश्लेषण** करना आसान बनाती है।
|
||||
Amazon Athena एक interactive query service है जो Amazon Simple Storage Service (Amazon **S3**) में सीधे standard **SQL** का उपयोग करके data को analyze करना आसान बनाती है।
|
||||
|
||||
आपको उन monitored S3 buckets में आने वाली सामग्री के फ़ॉर्मेट के साथ एक **relational DB table तैयार करना** होगा। और फिर, Amazon Athena logs से DB को populate कर सकेगा, ताकि आप उस पर query चला सकें।
|
||||
आपको monitored S3 buckets में दिखाई देने वाली सामग्री के फॉर्मेट के साथ एक relational DB table तैयार करना होगा। उसके बाद, Amazon Athena logs से DB को populate कर सकेगा, ताकि आप उस पर query चला सकें।
|
||||
|
||||
Amazon Athena पहले से encrypted S3 data को query करने की क्षमता का समर्थन करता है और यदि इसे configure किया गया है, तो **Athena queried results को encrypt भी कर सकता है जिन्हें बाद में S3 में store किया जा सकता है**।
|
||||
Amazon Athena उस क्षमता का समर्थन करता है कि वह पहले से encrypted S3 data को query कर सके, और यदि कॉन्फ़िगर किया गया हो, तो **Athena query के परिणामों को भी encrypt कर सकता है जिन्हें बाद में S3 में store किया जा सकता है**।
|
||||
|
||||
**परिणामों का यह एन्क्रिप्शन underlying queried S3 डेटा से स्वतंत्र है**, अर्थात् भले ही S3 डेटा encrypted न हो, queried results को encrypt किया जा सकता है। ध्यान रखने योग्य कुछ बातें हैं: Amazon Athena केवल उन डेटा का समर्थन करता है जो निम्नलिखित S3 encryption methods के साथ **encrypted** किए गए हैं, **SSE-S3, SSE-KMS, and CSE-KMS**।
|
||||
**परिणामों का यह encryption queried S3 डेटा के underlying डेटा से स्वतंत्र है**, मतलब कि भले ही S3 डेटा 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 पर ही queries चलाएगा जो query के समान region में हैं**। यदि आपको KMS का उपयोग करके encrypted S3 data को query करने की आवश्यकता है, तो Athena user को query करने में सक्षम बनाने के लिए विशिष्ट permissions की आवश्यकता होगी।
|
||||
SSE-C और CSE-C समर्थित नहीं हैं। इसके अलावा, यह समझना ज़रूरी है कि Amazon Athena केवल उन्हीं encrypted objects पर query चलाएगा जो उसी region में हों जहाँ से query चल रही है। यदि आपको KMS का उपयोग करके encrypted S3 data को query करना है, तो Athena user को query करने के लिए specific permissions की आवश्यकता होगी।
|
||||
|
||||
### Enumeration
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user