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

This commit is contained in:
Translator
2026-02-27 14:14:57 +00:00
parent cbd211cb35
commit 16a822aea1
2 changed files with 129 additions and 129 deletions
@@ -1,4 +1,4 @@
# AWS - VPC & 네트워킹 기본 정보
# AWS - VPC & Networking Basic Information
{{#include ../../../../banners/hacktricks-training.md}}
@@ -25,143 +25,143 @@ Moreover, in order to **access Internet**, there are some interesting configurat
## VPC
Amazon **Virtual Private Cloud** (Amazon VPC)는 사용자가 정의한 가상 네트워크에 **AWS 리소스를 런치**할 수 있게 해줍니다. 이 가상 네트워크는 여러 서브넷, Internet Gateways(인터넷 접근을 위해), ACLs, Security groups, IP 등을 가집니다.
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...
### Subnets
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.
- 유효한 CIDR은 /16 넷마스크부터 /28 넷마스크까지입니다.
- 하나의 subnet은 동시에 다른 가용 영역(Availability Zone)에 있지 못합니다.
- **AWS는 각 subnet의 처음 세 개의 호스트 IP 주소를 내부 AWS 용도로 예약합니다**: 첫 번째 호스트 주소는 VPC 라우터용, 두 번째는 AWS DNS용, 세 번째는 향후 사용을 위해 예약됩니다.
- **직접 인터넷에 접근 가능한 서브넷은 public subnets라 부르고, 그렇지 않은 것은 private 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**: the 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.**
### Route Tables
Route table은 VPC 내에서 서브넷의 트래픽 라우팅을 결정합니다. 인터넷 또는 VPN 연결로 전달되는 네트워크 트래픽을 결정합니다. 보통 다음에 대한 액세스를 찾을 수 있습니다:
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:
- Local VPC
- NAT
- Internet Gateways / Egress-only Internet gateways (VPC에 인터넷 접근을 주기 위해 필요)
- 서브넷을 public으로 만들려면 VPC에 Internet gateway를 **생성**하고 **연결(attach)** 해야 합니다.
- VPC endpoints (private 네트워크에서 S3에 접근하기 위해)
- 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)
### ACLs
**Network Access Control Lists (ACLs)**: Network ACL은 서브넷으로 들어오고 나가는 네트워크 트래픽을 제어하는 방화벽 규칙입니다. 특정 IP 주소나 범위에 대한 트래픽을 허용하거나 거부하는 데 사용될 수 있습니다.
**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.
- 보통은 security groups로 허용/거부하는 경우가 많지만, 이것이 이미 확립된 리버스 셸을 완전히 차단하는 유일한 방법입니다. security group의 수정된 규칙은 이미 확립된 연결을 즉시 중단하지 않습니다.
- 그러나 이는 전체 서브넷에 적용되므로, 필요한 기능이 방해받지 않도록 금지할 항목을 신중히 결정해야 합니다.
- Its 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 doesnt stop already established connections
- However, this apply to the whole subnetwork be careful when forbidding stuff because needed functionality might be disturbed
### Security Groups
Security groups는 VPC 내 인스턴스로의 인바운드 및 아웃바운드 네트워크 트래픽을 제어하는 가상 **방화벽**입니다. 관계는 보통 1 SG 대 다수 인스턴스(일반적으로 1:1).
보통 인스턴스에서 포트 22 같은 위험한 포트를 열기 위해 사용됩니다:
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:
<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_는 동적 클라우드 컴퓨팅을 위해 설계된 **정적 IPv4 주소**입니다. Elastic IP 주소는 AWS 계정에 할당되며, 해제할 때까지 계정 소유입니다. Elastic IP를 사용하면 인스턴스나 소프트웨어 장애 시 해당 주소를 계정 내 다른 인스턴스로 빠르게 재매핑하여 장애를 가릴 수 있습니다.
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.
### Connection between subnets
기본적으로 모든 서브넷은 **공인 IP 자동 할당(auto-assign public IP)** 이 꺼져 있지만, 이를 켤 수 있습니다.
By default, all subnets have the **automatic assigned of public IP addresses turned off** but it can be turned on.
**A local route within a route table enables communication between VPC subnets.**
서브넷을 서로 연결할 때, 한 서브넷을 통해 다른 서브넷에 연결된 서브넷들에 접근할 수는 없습니다. 각 서브넷과 직접 연결을 만들어야 합니다. **이것은 Internet gateways에도 적용됩니다.** 인터넷에 접근하려면 인터넷 게이트웨이를 서브넷에 직접 할당해야 합니다.
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.
### VPC Peering
VPC peering IPV4 또는 IPV6을 사용하여 **둘 이상의 VPC를 마치 동일한 네트워크의 일부인 것처럼 연결**할 수 있게 합니다.
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의 리소스가 다른 VPC의 리소스에 접근할 수 있습니다**. VPC 간의 연결은 기존 AWS 네트워크 인프라를 통해 구현되어 고가용성이며 대역폭 병목이 없습니다. **피어 연결은 동일한 네트워크의 일부인 것처럼 동작하므로**, 사용 가능한 CIDR 블록 범위에 제한이 있습니다.
VPC에 대해 **중복되거나 겹치는 CIDR** 범위가 있으면 **VPC를 피어링할 수 없습니다.**
AWS VPC**오직 그 피어와만 통신**합니다. 예를 들어 VPC 1 VPC 2가 피어링되어 있고 VPC 2 VPC 3도 피어링되어 있다면, VPC 1과 VPC 2는 직접 통신할 수 있고 VPC 2 VPC 3도 직접 통신할 수 있지만, VPC 1 VPC 3은 통신할 수 없습니다. **한 VPC를 통해 다른 VPC로 라우팅할 수 없습니다.**
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.**
### **VPC Flow Logs**
VPC 내에는 수백에서 수천 개의 리소스가 서로 다른 퍼블릭/프라이빗 서브넷 및 VPC 피어링 연결을 통해 통신할 수 있습니다. **VPC Flow Logs는 VPC 내 리소스의 네트워크 인터페이스 간에 흐르는 IP 트래픽 정보를 캡처**할 수 있게 해줍니다.
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**.
S3 액세스 로그나 CloudFront 액세스 로그와 달리, **VPC Flow Logs로 생성된 로그 데이터는 S3에 저장되지 않습니다. 대신 캡처된 로그 데이터는 CloudWatch logs로 전송됩니다**.
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**.
제한 사항:
Limitations:
- VPC peered 연결을 실행 중이라면, 동일한 계정 내에 있는 피어 VPC의 flow logs만 볼 수 있습니다.
- EC2-Classic 환경에서 리소스를 여전히 실행 중이라면 해당 인터페이스의 정보를 가져올 수 없습니다.
- VPC Flow Log가 생성되면 변경할 수 없습니다. 구성 변경을 하려면 로그를 삭제하고 새로 만들어야 합니다.
- 다음 트래픽은 로그로 모니터링되거나 캡처되지 않습니다: VPC 내의 DHCP 트래픽, Amazon DNS 서버를 향한 인스턴스의 트래픽.
- VPC 기본 라우터를 위한 IP 주소로 향하는 모든 트래픽과, 인스턴스 메타데이터 수집에 사용되는 169.254.169.254 및 Amazon Time Sync Service에 사용되는 169.254.169.123으로의 트래픽은 캡처되지 않습니다.
- Windows 인스턴스의 Amazon Windows activation license와 관련된 트래픽
- Network Load Balancer 인터페이스와 엔드포인트 네트워크 인터페이스 간의 트래픽
- 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
CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페이스는 서로 다른 로그 스트림을 사용합니다. 각 스트림 내에는 로그 항목의 내용을 보여주는 flow log 이벤트 데이터가 있습니다. 각 **로그는 약 10~15분의 창(window) 동안 데이터를 캡처**합니다.
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**.
## VPN
### Basic AWS VPN Components
1. **Customer Gateway**:
- Customer Gateway는 Site-to-Site VPN 연결에서 고객 측을 나타내기 위해 AWS에서 생성하는 리소스입니다.
- 본질적으로 Site-to-Site VPN 연결의 고객 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다.
- 라우팅 정보와 네트워크 장치(예: 라우터나 방화벽)의 공인 IP 주소를 AWS에 제공하여 Customer Gateway를 생성합니다.
- VPN 연결 설정을 위한 참조 지점이며 추가 요금이 발생하지 않습니다.
- 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.
2. **Virtual Private Gateway**:
- Virtual Private Gateway (VPG)는 Site-to-Site VPN 연결의 Amazon 측 VPN 집중기(concentrator)입니다.
- VPC에 연결되어 VPN 연결의 대상(target) 역할을 합니다.
- VPG는 VPN 연결의 AWS 측 엔드포인트입니다.
- VPC와 온프레미스 네트워크 간의 보안 통신을 처리합니다.
- 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.
3. **Site-to-Site VPN Connection**:
- Site-to-Site VPN 연결은 온프레미스 네트워크를 IPsec VPN 터널을 통해 VPC에 연결합니다.
- 이 유형의 연결은 Customer Gateway Virtual Private Gateway가 필요합니다.
- 데이터 센터 또는 네트워크와 AWS 환경 간의 보안, 안정적이고 일관된 통신에 사용됩니다.
- 일반적으로 정기적이고 장기적인 연결에 사용되며 연결을 통해 전송되는 데이터 양에 따라 요금이 부과됩니다.
- 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.
4. **Client VPN Endpoint**:
- Client VPN endpoint는 클라이언트 VPN 세션을 활성화하고 관리하기 위해 AWS에서 생성하는 리소스입니다.
- 개별 장치(노트북, 스마트폰 등)가 AWS 리소스 또는 온프레미스 네트워크에 안전하게 연결할 수 있도록 사용됩니다.
- Site-to-Site VPN과 달리 전체 네트워크를 연결하는 것이 아니라 개별 클라이언트를 위해 설계되었습니다.
- Client VPN에서는 각 클라이언트 장치가 VPN 클라이언트 소프트웨어를 사용하여 보안 연결을 설정합니다.
- 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.
### Site-to-Site VPN
**온프레미스 네트워크를 VPC와 연결**합니다.
**Connect your on premisses network with your VPC.**
- **VPN connection**: 온프레미스 장비와 VPC 간의 보안 연결입니다.
- **VPN tunnel**: 고객 네트워크와 AWS 간에 데이터가 전달될 수 있는 암호화된 링크입니다.
- **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 연결에는 고가용성을 위해 동시에 사용할 수 있는 두 개의 VPN 터널이 포함됩니다.
Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability.
- **Customer gateway**: 고객 게이트웨이 장치에 대한 정보를 AWS에 제공하는 AWS 리소스입니다.
- **Customer gateway device**: Site-to-Site VPN 연결의 고객 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다.
- **Virtual private gateway**: Site-to-Site VPN 연결의 Amazon 측 VPN 집중기입니다. Amazon 측의 게이트웨이로 virtual private gateway 또는 transit gateway를 사용할 수 있습니다.
- **Transit gateway**: VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 트랜짓 허브입니다. Site-to-Site VPN 연결의 Amazon 측 게이트웨이로 transit gateway 또는 virtual private gateway를 사용합니다.
- **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.
#### Limitations
- IPv6 트래픽은 virtual private gateway의 VPN 연결에서 지원되지 않습니다.
- AWS VPN 연결은 Path MTU Discovery를 지원하지 않습니다.
- IPv6 traffic is not supported for VPN connections on a virtual private gateway.
- An AWS VPN connection does not support Path MTU Discovery.
또한 Site-to-Site VPN을 사용할 때 다음 사항을 고려하세요.
In addition, take the following into consideration when you use Site-to-Site VPN.
- VPC를 공통 온프레미스 네트워크에 연결할 때는 네트워크에 대해 겹치지 않는(non-overlapping) CIDR 블록을 사용하는 것이 권장됩니다.
- When connecting your VPCs to a common on-premises network, we recommend that you use non-overlapping CIDR blocks for your networks.
### Client VPN <a href="#what-is-components" id="what-is-components"></a>
**내 기기에서 VPC로 연결**
**Connect from your machine to your VPC**
#### Concepts
- **Client VPN endpoint:** 클라이언트 VPN 세션을 활성화하고 관리하기 위해 생성하고 구성하는 리소스입니다. 모든 클라이언트 VPN 세션이 종료되는 리소스입니다.
- **Target network:** Client VPN endpoint에 연결(associate)하는 네트워크입니다. **VPC의 subnet target network입니다**. 서브넷을 Client VPN endpoint에 연결하면 VPN 세션을 설정할 수 있습니다. 고가용성을 위해 여러 서브넷을 Client VPN endpoint에 연결할 수 있습니다. 모든 서브넷은 동일한 VPC에 있어야 하며, 각 서브넷은 서로 다른 Availability Zone에 속해야 합니다.
- **Route**: Client VPN endpoint는 사용 가능한 목적지 네트워크 경로를 설명하는 라우트 테이블을 가집니다. 라우트 테이블의 각 경로는 특정 리소스나 네트워크로의 트래픽 경로를 지정합니다.
- **Authorization rules:** 권한 규칙은 **어떤 사용자가 네트워크에 접근할 수 있는지 제한**합니다. 특정 네트워크에 대해 접근을 허용할 Active Directory 또는 IdP 그룹을 구성합니다. 이 그룹에 속한 사용자만 지정된 네트워크에 접근할 수 있습니다. **기본적으로 권한 규칙은 없으며**, 사용자가 리소스와 네트워크에 접근하려면 권한 규칙을 구성해야 합니다.
- **Client:** VPN 세션을 설정하기 위해 Client VPN endpoint에 연결하는 최종 사용자입니다. 최종 사용자는 OpenVPN 클라이언트를 다운로드하고 생성한 Client VPN 구성 파일을 사용해 VPN 세션을 설정해야 합니다.
- **Client CIDR range:** 클라이언트 IP 주소를 할당하기 위한 IP 주소 범위입니다. Client VPN endpoint에 대한 각 연결은 client CIDR range에서 고유한 IP 주소를 할당받습니다. 예: `10.2.0.0/16`.
- **Client VPN ports:** AWS Client VPN는 TCP 및 UDP 모두에 대해 포트 443과 1194를 지원합니다. 기본값은 포트 443입니다.
- **Client VPN network interfaces:** 서브넷을 Client VPN endpoint에 연결하면 해당 서브넷에 Client VPN network interfaces가 생성됩니다. **Client VPN endpoint에서 VPC로 전송되는 트래픽은 Client VPN network interface를 통해 전송됩니다**. 그런 다음 소스 네트워크 주소 변환(SNAT)이 적용되어 client CIDR 범위의 소스 IP 주소가 Client VPN network interface IP 주소로 변환됩니다.
- **Connection logging:** Client VPN endpoint에 대해 연결 로깅을 활성화하여 연결 이벤트를 기록할 수 있습니다. 이 정보를 포렌식, 사용 분석 또는 연결 문제 디버그에 사용할 수 있습니다.
- **Self-service portal:** Client VPN endpoint에 대해 셀프 서비스 포털을 활성화할 수 있습니다. 클라이언트는 자격 증명을 사용해 웹 기반 포털에 로그인하고 최신 Client VPN endpoint 구성 파일 또는 AWS가 제공하는 최신 클라이언트를 다운로드할 수 있습니다.
- **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.
#### Limitations
@@ -1,37 +1,37 @@
# AWS - S3, Athena & Glacier Enum
# AWS - S3, Athena & Glacier 열거
{{#include ../../../banners/hacktricks-training.md}}
## S3
Amazon S3는 **대용량 데이터를 저장**할 수 있는 서비스입니다.
Amazon S3는 **대용량 데이터를 저장**할 수 있는 서비스입니다.
Amazon S3는 REST 상태의 데이터에 대한 **보호**를 달성하기 위 여러 옵션을 제공합니다. 옵션에는 **권한** (Policy), **암호화** (Client and Server Side), **Bucket Versioning****MFA** **기반 삭제**가 포함됩니다. **사용자**는 데이터 보호를 위해 이러한 옵션 중 어느 것이든 활성화할 수 있습니다. **데이터 복제** AWS의 내부 기능으로, **S3가 각 객체를 모든 Availability Zones 자동으로 복제**하므로 조직에서 별도로 활성화할 필요가 없습니다.
Amazon S3는 REST 상태의 데이터에 대한 **보호**를 달성하기 위 여러 옵션을 제공합니다. 옵션에는 **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning****MFA** **based delete**가 포함됩니다. **사용자**는 데이터 보호를 위해 이러한 옵션 중 어느 것이든 **활성화할 수 있습니다**. **Data replication** AWS의 내부 기능으로, **S3가 모든 Availability Zones 전반에 각 객체를 자동으로 복제**하므로 조직에서 별도로 활성화할 필요가 없습니다.
리소스 기반 권한을 사용하면 버킷의 하위 디렉터리에 대한 권한을 별도로 정의할 수 있습니다.
리소스 기반 권한을 사용하면 버킷의 하위 디렉토리별로 권한을 별도로 정의할 수 있습니다.
### Bucket Versioning and MFA based delete
Bucket Versioning 활성화되면, 파일을 변경하려는 모든 작업은 해당 파일의 새 버전을 생성하고 이전 내용도 보존합니다. 따라서 기존 내용 덮어지 않습니다.
Bucket Versioning 활성화되면, 파일을 변경하려는 모든 작업은 파일의 새 버전을 생성하고 이전 내용도 유지합니다. 따라서 내용 덮어써지지 않습니다.
또한, MFA 기반 삭제는 S3 버킷의 파일 버전 삭제 Bucket Versioning 비활성화 방지하므로 공격자가 이러한 파일을 변경할 수 없습니다.
또한, MFA based delete는 S3 버킷의 파일 버전 삭제되는 것과 Bucket Versioning 비활성화되는 것을 방지하므로 공격자가 이러한 파일을 변경할 수 없습니다.
### S3 Access logs
특정 버킷에 대해 **S3 access login**을 활성화(기본값은 비활성화)하고 로그를 다른 버킷에 저장하여 누가 버킷에 접근하는지 확인할 수 있습니다(두 버킷은 동일한 리전에 있어야 합니다).
특정 버킷에 대해 기본적으로 비활성화되어 있는 **S3 access login**을 활성화하고 로그를 다른 버킷에 저장하여 누가 해당 버킷에 접근하는지 확인할 수 있습니다(두 버킷은 같은 리전에 있어야 합니다).
### S3 Presigned URLs
버킷의 특정 파일에 **접근**하는 데 사용할 수 있는 presigned URL을 생성할 수 있습니다. **presigned URL은 다음과 같습니다**:
버킷의 특정 파일에 **접근**하는 데 보통 사용할 수 있는 presigned URL을 생성할 수 있습니다. 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에서 object에 접근 권한이 있는 principal의 자격 증명을 사용해 생성 수 있습니** (사용하는 계정에 접근 권한이 없으면 더 짧은 presigned URL이 생성되지만 쓸모가 없습니다)
presigned URL은 **cli에서 객체에 접근 권한이 있는 principal의 자격 증명으로 생성 수 있다** (사용하는 계정에 접근 권한이 없으면 더 짧은 presigned URL이 생성되지만 쓸모다)
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> 사전 서명된 URL을 생성하는 데 필요한 유일한 권한은 부여되는 권한 그 자체이므로, 이전 명령의 경우 주체(principal)가 필요한 유일한 권한은 `s3:GetObject`
> presigned URL을 생성하는 데 필요한 권한은 부여되는 권한 하나뿐이므로, 이전 명령의 경우 주체(principal)가 필요한 유일한 권한은 `s3:GetObject`
또한 **다른 권한**으로 사전 서명된 URL을 생성할 수도 있습니다:
```python
@@ -44,22 +44,22 @@ ExpiresIn=3600
```
### S3 암호화 메커니즘
**DEK는 Data Encryption Key를 의미합니다**. 이 키는 항상 생성되며 데이터를 암호화하는 데 사용됩니다.
**DEK는 Data Encryption Key를 의미하며**, 데이터 암호화를 위해 항상 생성되어 사용되는 키입니다.
<details>
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
이 옵션은 최소한의 구성만 필요하며, 사용되는 암호화 키 관리는 모두 AWS에서 리합니다. 해야 할 **데이터를 업로드하면 S3가 나머지 처리합니다**. S3 계정의 각 버킷에는 bucket key가 할당됩니다.
이 옵션은 최소한의 구성만 필요하며 사용되는 암호화 키 관리는 모두 AWS에서 리합니다. 해야 할 **데이터를 업로드하면 S3가 나머지 모든 작업을 처리합니다**. S3 계정의 각 버킷에는 버킷 키가 할당됩니다.
- 암호화:
- 객체 데이터 + 생성된 평문 DEK --> 암호화된 데이터 (S3에 저장)
- 오브젝트 데이터 + 생성된 평문 DEK --> 암호화된 데이터 (S3에 저장)
- 생성된 평문 DEK + S3 Master Key --> 암호화된 DEK (S3에 저장) 및 평문은 메모리에서 삭제됨
- 복호화:
- 암호화된 DEK + S3 Master Key --> 평문 DEK
- 평문 DEK + 암호화된 데이터 --> 객체 데이터
- 평문 DEK + 암호화된 데이터 --> 오브젝트 데이터
참고: 이 경우 **키는 AWS에서 관리됩니다**(회전 주기: 3년마다). 자체 키를 사용하면 키 회전, 비활성화 및 접근 제어를 적용할 수 있습니다.
Please, note that in this case **the key is managed by AWS** (rotation only every 3 years). If you use your own key you willbe able to rotate, disable and apply access control.
</details>
@@ -67,16 +67,16 @@ ExpiresIn=3600
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
이 방법은 S3가 키 관리 서비스(KMS)를 사용하여 데이터 암호화 키를 생성하도록 허용합니다. KMS는 키 관리 방에 대해 훨씬 더 큰 유연성을 제공합니다. 예를 들어 CMK에 대해 비활성화, 회전 및 접근 제어를 적용할 수 있, AWS Cloud Trail을 사용하여 사용 내역을 감사할 수 있습니다.
이 방법은 S3가 key management service를 사용 데이터 암호화 키를 생성하도록 허용합니다. KMS는 키 관리 방에 대해 훨씬 더 큰 유연성을 제공합니다. 예를 들어 CMK 비활성화하거나 회전시키고 접근 제어를 적용할 수 있으며, AWS Cloud Trail을 사용 사용을 감사할 수 있습니다.
- 암호화:
- S3가 KMS CMK에 데이터 키를 요청
- KMS CMK를 사용하여 평문 DEK와 암호화된 DEK 쌍을 생성하여 S3로 전송
- S3 평문 키 데이터를 암호화하고, 암호화된 데이터와 암호화된 키를 저장한 평문 키를 메모리에서 삭제
- S3가 KMS CMK에 데이터 키를 요청
- KMS CMK를 사용 평문 DEK와 암호화된 DEK 쌍을 생성하여 S£로 전송
- S3 평문 키를 사용해 데이터를 암호화하고 암호화된 데이터와 암호화된 키를 저장한 평문 키를 메모리에서 삭제
- 복호화:
- S3가 객체의 암호화된 데이터 키를 복호화해 달라고 KMS에 요청
- KMS CMK로 데이터 키를 복호화하여 S3로 반환
- S3가 객체 데이터를 복호화
- S3가 오브젝트의 암호화된 데이터 키를 복호화해 달라고 KMS에 요청
- KMS CMK로 데이터 키를 복호화하여 S3로 반환
- S3가 오브젝트 데이터를 복호화
</details>
@@ -84,17 +84,17 @@ ExpiresIn=3600
<summary><strong>Server-side encryption with customer provided keys, SSE-C</strong></summary>
이 옵션은 AWS 외부에서 이미 사용 중일 수 있는 자체 마스터 키를 제공할 수 있는 기회를 니다. 고객이 제공한 키는 데이터와 함께 S3로 전송되, S3가 대신 암호화를 수행합니다.
이 옵션은 AWS 외부에서 이미 사용 중일 수 있는 자체 마스터 키를 제공할 기회를 제공합니다. 고객이 제공한 키는 데이터와 함께 S3로 전송되, S3가 대신 암호화를 수행합니다.
- 암호화:
- 사용자가 객체 데이터 + 고객 키를 S3 전송
- 고객 키로 데이터를 암호화하고 암호화된 데이터 저장
- 향후 키 검증을 위해 고객 키의 솔된 HMAC 값도 저장
- 고객 키는 메모리에서 삭제
- 사용자가 오브젝트 데이터 + 고객 키를 S3 전송
- 고객 키로 데이터를 암호화하고 암호화된 데이터 저장
- 향후 키 검증을 위해 고객 키의 솔된 HMAC 값도 저장
- 고객 키는 메모리에서 삭제
- 복호화:
- 사용자가 고객 키를 전송
- 키는 저장된 HMAC 값과 대조되어 검증
- 검증된 고객 제공 키로 데이터를 복호화
- 사용자가 고객 키를 전송
- 키는 저장된 HMAC 값과 대조되어 검증
- 검증된 고객 제공 키로 데이터를 복호화
</details>
@@ -102,17 +102,17 @@ ExpiresIn=3600
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
SSE-KMS와 유사하게, 이 방법도 KMS를 사용하여 데이터 암호화 키를 생성합니다. 다만 이번에는 KMS가 S3가 아니라 클라이언트를 통해 호출됩니다. 암호화는 클라이언트 측에서 수행되고 암호화된 데이터가 S3로 전송되어 저장됩니다.
SSE-KMS와 유사하게, 이 방식 역시 key management service를 사용 데이터 암호화 키를 생성합니다. 다만 이번에는 KMS가 S3가 아 클라이언트를 통해 호출됩니다. 암호화는 클라이언트 측에서 수행되고 암호화된 데이터가 S3에 저장되기 위해 전송됩니다.
- 암호화:
- 클라이언트가 KMS에 데이터 키 요청
- KMS가 CMK로 평문 DEK와 암호화된 DEK를 반환
- 두 키를 클라이언트로 전달함
- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK(메타데이터로 저장)를 S3 전송
- 클라이언트가 KMS에 데이터 키 요청
- KMS 평문 DEK와 CMK로 암호화된 DEK를 반환
- 두 키가 반환됨
- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK(메타데이터로 S3에 저장)를 S3 전송
- 복호화:
- 암호화된 데이터와 암호화된 DEK가 클라이언트로 전송
- 클라이언트 KMS에 암호화된 키를 CMK로 복호화해 달라고 요청하 KMS 평문 DEK를 반환
- 클라이언트는 평문 DEK로 암호화된 데이터를 복호화
- 암호화된 DEK가 포함된 암호화된 데이터가 클라이언트로 전송
- 클라이언트는 CMK를 사용해 KMS에 암호화된 키의 복호화를 요청하 KMS 평문 DEK를 반환
- 클라이언트는 평문 DEK로 암호화된 데이터를 복호화
</details>
@@ -120,21 +120,21 @@ SSE-KMS와 유사하게, 이 방법도 KMS를 사용하여 데이터 암호화
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
이 메커니즘을 사용하면 자체 제공 키를 활용하 AWS-SDK 클라이언트를 해 데이터를 S3 전송하기 전에 클라이언트 측에서 암호화할 수 있습니다.
이 메커니즘을 사용하면 자체 제공 키를 활용하 AWS-SDK 클라이언트를 사용해 데이터를 S3 전송하기 전에 암호화할 수 있습니다.
- 암호화:
- 클라이언트가 DEK를 생성하고 평문 데이터를 암호화
- 그런 다음 자체 CMK로 DEK를 암호화
- 암호화된 데이터 + 암호화된 DEK를 S3에 제출하여 저장
- 클라이언트가 DEK를 생성하고 평문 데이터를 암호화
- 그런 다음 자체 CMK로 DEK를 암호화
- 암호화된 데이터 + 암호화된 DEK를 S3에 제출하여 저장
- 복호화:
- S3가 암호화된 데이터와 DEK를 전송
- 클라이언트 DEK를 암호화하는 데 사용된 CMK를 이미 가지고 있으므로 DEK를 복호화한 평문 DEK로 데이터를 복호화
- S3가 암호화된 데이터와 DEK를 전송
- 클라이언트 DEK를 암호화하는 데 사용된 CMK를 이미 보유하고 있으므로 DEK를 복호화한 평문 DEK로 데이터를 복호화
</details>
### **Enumeration**
AWS 조직을 침해하는 전통적인 주요 방법 중 하나는 공개적으로 접근 가능한 버킷을 침해하는 것니다. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/index.html#s3-buckets)**.**
전통적으로 AWS 조직을 침해하는 주요 방법 중 하나는 공개적으로 접근 가능한 버킷을 침해하는 것으로 시작합니다. **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>
@@ -227,18 +227,18 @@ aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-poli
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
```
### 듀얼-스택 <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
virtual hosted-style 또는 path-style endpoint 이름을 사용하여 dual-stack endpoint를 통해 S3 버킷에 접근할 수 있습니다. 이는 IPv6 S3에 접근할 때 유용합니다.
virtual hosted-style 또는 path-style 엔드포인트 이름을 사용하여 dual-stack 엔드포인트를 통해 S3 버킷에 접근할 수 있습니다. 이는 IPv6를 통해 S3에 접근할 때 유용합니다.
Dual-stack endpoints는 다음 구문을 사용합니다:
Dual-stack 엔드포인트는 다음 구문을 사용합니다:
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
### Privesc
다음 페이지에서 **S3 permissions을 악용해 권한을 상승시키는 방법**을 확인할 수 있습니다:
다음 페이지에서 **abuse S3 permissions to escalate privileges** 방법을 확인할 수 있습니다:
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -262,23 +262,23 @@ Dual-stack endpoints는 다음 구문을 사용합니다:
../aws-persistence/aws-s3-persistence/README.md
{{#endref}}
## 기타 S3 취약점
## Other S3 vulns
### 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)에 따르면 임의의 버킷 응답을 마치 다른 버킷의 것인 것처럼 캐시하는 것이 가능했다고 합니다. 이는 예를 들어 javascript 파일 응답을 변경하여 S3를 사용해 정적 코드를 호스팅하는 임의의 페이지를 침해하는 데 악용될 수 있었습니다.
[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) 임의의 버킷 응답을 다른 버킷에 속한 것처럼 캐시할 수 있었습니다. 이는 예를 들어 javascript 파일 응답을 변경하여 S3를 사용해 정적 코드를 호스팅하는 임의의 페이지를 손상시키는 데 악용될 수 있었습니다.
## Amazon Athena
Amazon Athena는 표준 **SQL**을 사용하여 Amazon Simple Storage Service (Amazon **S3**)에 있는 데이터를 직접 **분석**하기 쉽게 해주는 인터랙티브 쿼리 서비스입니다.
Amazon Athena는 표준 **SQL**을 **사용하여** Amazon Simple Storage Service (Amazon **S3**) 데이터를 직접 **분석하는** 것을 쉽게 해 주는 대화형 쿼리 서비스입니다.
모니터링할 S3 버킷에 나타날 콘텐츠 형식으로 **관계형 DB 테이블을 준비**해야 합니다. 그러면 Amazon Athena 로그로부터 DB를 채워 쿼리할 수 있게 됩니다.
모니터링할 S3 버킷에 나타날 콘텐츠 형식으로 **관계형 DB 테이블을 준비**해야 합니다. 그러면 Amazon Athena 로그에서 DB를 채워 쿼리할 수 있게 됩니다.
Amazon Athena는 **이미 암호화된 S3 데이터를 쿼리하는 기능**을 지원하며, 구성된 경우 **쿼리 결과를 암호화하여 S3에 저장할 수도 있습니다**.
Amazon Athena는 **이미 암호화된 S3 데이터를 쿼리하는 기능**을 지원하며, 구성된 경우 **Athena가 쿼리 결과를 암호화하여 S3에 저장할 수 있게 할 수도 있습니다**.
**결과 암호화는 쿼리 대상이 되는 S3 데이터의 암호화 여부와는 독립적입니다**, 즉 S3 데이터가 암호화되어 있지 않더라도 쿼리 결과는 암호화될 수 있습니다. 주의할 점은 Amazon Athena**SSE-S3, SSE-KMS, CSE-KMS**로 암호화된 데이터만 지원한다는 것입니다.
**쿼리 결과의 이 암호화는 조회된 S3 데이터 자체의 암호화와는 독립적입니다**, 즉 S3 데이터가 암호화되어 있지 않더라도 쿼리 결과는 암호화될 수 있습니다. 주의할 점은 Amazon Athena**SSE-S3, SSE-KMS, CSE-KMS**로 **암호화된** 데이터만 지원한다는 것입니다.
SSE-C 및 CSE-C는 지원되지 않습니다. 또한 Amazon Athena는 쿼리가 실행되는 것과 동일한 리전에 있는 **암호화된 객체에 대해서만** 쿼리를 실행한다는 점을 이해하는 것이 중요합니다. KMS로 암호화된 S3 데이터를 쿼리해야 하는 경우, Athena 사용자는 쿼리를 수행할 수 있도록 특정 권한이 필요합니다.
SSE-C 및 CSE-C는 지원되지 않습니다. 또한 Amazon Athena는 쿼리 자체와 동일한 리전에 있는 **암호화된 객체에 대해서만** 쿼리를 실행한다는 점을 이해하는 것이 중요합니다. KMS로 암호화된 S3 데이터를 쿼리해야 하는 경우, Athena 사용자는 쿼리를 수행할 수 있도록 특정 권한이 필요합니다.
### Enumeration
```bash