gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Translator
2026-02-23 23:59:42 +00:00
parent a863fed692
commit cbd211cb35
2 changed files with 149 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md
+92 -102
View File
@@ -1,4 +1,4 @@
# AWS - VPC & Networking Basic Information
# AWS - VPC & 네트워킹 기본 정보
{{#include ../../../../banners/hacktricks-training.md}}
@@ -6,190 +6,180 @@
A **VPC** contains a **network CIDR** like 10.0.0.0/16 (with its **routing table** and **network ACL**).
이 VPC 네트워크는 **서브네트워크**로 나뉘어 있으며, **서브네트워크**는 **VPC**, **라우팅** **테이블** 및 **네트워크 ACL**과 직접 **연관**되어 있습니다.
This VPC network is divided in **subnetworks**, so a **subnetwork** is directly **related** with the **VPC**, **routing** **table** and **network ACL**.
그 다음, 서비스(예: EC2 인스턴스)에 연결된 **네트워크 인터페이스**는 **보안 그룹**과 함께 **서브네트워크**에 **연결**됩니다.
Then, **Network Interface**s attached to services (like EC2 instances) are **connected** to the **subnetworks** with **security group(s)**.
따라서, **보안 그룹**은 **서브네트워크**와 관계없이 **사용하는** 네트워크 **인터페이스**의 노출된 포트를 제한합니다. 그리고 **네트워크 ACL**은 **전체 네트워크**에 대한 노출된 포트를 **제한**합니다.
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**.
또한, **인터넷에 접근하기 위해** 확인해야 할 몇 가지 흥미로운 구성 요소가 있습니다:
Moreover, in order to **access Internet**, there are some interesting configurations to check:
- **서브네트워크**는 **공용 IPv4 주소를 자동 할당**할 수 있습니다.
- **IPv4 주소를 자동 할당하는 네트워크에서 생성된 인스턴스는 하나를 받을 수 있습니다.**
- **인터넷 게이트웨이**는 **VPC에 연결**되어야 합니다.
- **Egress-only 인터넷 게이트웨이**를 사용할 수도 있습니다.
- **프라이빗 서브넷**에 **NAT 게이트웨이**를 두어 해당 프라이빗 서브넷에서 외부 서비스에 **연결할 수 있지만**, 외부에서 접근할 수는 없습니다.
- NAT 게이트웨이는 **공용**(인터넷 접근) 또는 **프라이빗**(다른 VPC 접근)일 수 있습니다.
- 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)
![](<../../../../images/image (274).png>)
## VPC
Amazon **Virtual Private Cloud** (Amazon VPC)는 정의한 가상 네트워크에 **AWS 리소스를 시작할 수 있게** 해줍니다. 이 가상 네트워크는 여러 서브넷, 인터넷 게이트웨이를 통한 인터넷 접근, ACL, 보안 그룹, IP 등을 가집니다.
Amazon **Virtual Private Cloud** (Amazon VPC)는 사용자가 정의한 가상 네트워크에 **AWS 리소스를 런치**할 수 있게 해줍니다. 이 가상 네트워크는 여러 서브넷, Internet Gateways(인터넷 접근을 위해), ACLs, Security groups, IP 등을 가집니다.
### Subnets
서브넷은 더 높은 수준의 보안을 강화하는 데 도움을 줍니다. **유사한 리소스의 논리적 그룹화**는 인프라 전반에 걸쳐 **관리의 용이성**을 유지하는 데도 도움이 됩니다.
Subnets는 보안을 강화하는 데 도움을 줍니다. **유사한 리소스의 논리적 그룹화**는 인프라 전반에서 **관리 편의성**을 제공합니다.
- 유효한 CIDR은 /16 넷마스크에서 /28 넷마스크까지입니다.
- 서브넷은 동시에 서로 다른 가용 영역에 있을 수 없습니다.
- **AWS는 각 서브넷의 첫 세 호스트 IP 주소를** **내부 AWS 사용**을 위해 **예약합니다**: 첫 번째 호스트 주소는 VPC 라우터에 사용됩니다. 두 번째 주소는 AWS DNS에 예약되어 있으며, 세 번째 주소는 향후 사용을 위해 예약되어 있습니다.
- **인터넷에 직접 접근할 수 있는 서브넷**을 **공용 서브넷**이라고 하며, 프라이빗 서브넷은 그렇지 않습니다.
<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>
- 유효한 CIDR은 /16 넷마스크부터 /28 넷마스크까지입니다.
- 하나의 subnet은 동시에 다른 가용 영역(Availability Zone)에 있지 못합니다.
- **AWS는 각 subnet의 처음 세 개의 호스트 IP 주소를 내부 AWS 용도로 예약합니다**: 첫 번째 호스트 주소는 VPC 라우터용, 두 번째는 AWS DNS용, 세 번째는 향후 사용을 위해 예약됩니다.
- **직접 인터넷에 접근 가능한 서브넷은 public subnets라 부르고, 그렇지 않은 것은 private subnets라 부릅니다.**
### Route Tables
라우팅 테이블은 VPC 내 서브넷의 트래픽 라우팅을 결정합니다. 이들은 어떤 네트워크 트래픽이 인터넷이나 VPN 연결로 전달되는지를 결정합니다. 일반적으로 다음에 대한 접근을 찾을 수 있습니다:
Route table은 VPC 내에서 서브넷의 트래픽 라우팅을 결정합니다. 인터넷 또는 VPN 연결로 전달되는 네트워크 트래픽을 결정합니다. 보통 다음에 대한 액세스를 찾을 수 있습니다:
- 로컬 VPC
- Local VPC
- NAT
- 인터넷 게이트웨이 / Egress-only 인터넷 게이트웨이 (VPC에 인터넷 접근을 제공하는 데 필요).
- 서브넷을 공용으로 만들기 위해서는 **인터넷 게이트웨이**를 **생성**하고 **VPC에 연결**해야 합니다.
- VPC 엔드포인트 (프라이빗 네트워크에서 S3에 접근하기 위해)
다음 이미지를 통해 기본 공용 네트워크와 프라이빗 네트워크의 차이를 확인할 수 있습니다:
<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에 인터넷 접근을 주기 위해 필요)
- 서브넷을 public으로 만들려면 VPC에 Internet gateway를 **생성**하고 **연결(attach)** 해야 합니다.
- VPC endpoints (private 네트워크에서 S3에 접근하기 위해)
### ACLs
**네트워크 접근 제어 목록 (ACLs)**: 네트워크 ACL은 서브넷으로 들어오고 나가는 네트워크 트래픽을 제어하는 방화벽 규칙입니다. 특정 IP 주소나 범위에 대한 트래픽을 허용하거나 거부하는 데 사용할 수 있습니다.
**Network Access Control Lists (ACLs)**: Network ACL은 서브넷으로 들어오고 나가는 네트워크 트래픽을 제어하는 방화벽 규칙입니다. 특정 IP 주소나 범위에 대한 트래픽을 허용하거나 거부하는 데 사용될 수 있습니다.
- 보안 그룹을 사용하여 접근을 허용/거부하는 것이 가장 일반적이지만, 이는 이미 설정된 리버스 셸을 완전히 차단하는 유일한 방법입니다. 보안 그룹의 수정된 규칙은 이미 설정된 연결을 중단하지 않습니다.
- 그러나 이는 전체 서브네트워크에 적용되므로, 필요한 기능이 방해받을 수 있으니 주의해야 합니다.
- 보통은 security groups로 허용/거부하는 경우가 많지만, 이것이 이미 확립된 리버스 셸을 완전히 차단하는 유일한 방법입니다. security group의 수정된 규칙은 이미 확립된 연결을 즉시 중단하지 않습니다.
- 그러나 이는 전체 서브넷에 적용되므로, 필요한 기능이 방해받지 않도록 금지할 항목을 신중히 결정해야 합니다.
### Security Groups
보안 그룹은 VPC 내 인스턴스에 대한 인바운드 및 아웃바운드 네트워크 **트래픽**을 제어하는 가상 **방화벽**입니다. 1 SG와 M 인스턴스의 관계 (보통 1 대 1).\
일반적으로 이는 인스턴스에서 위험한 포트를 열기 위해 사용됩니다. 예를 들어 포트 22와 같은 경우입니다:
Security groups는 VPC 내 인스턴스로의 인바운드 및 아웃바운드 네트워크 트래픽을 제어하는 가상 **방화벽**입니다. 관계는 보통 1 SG 대 다수 인스턴스(일반적으로 1:1).
보통 인스턴스에서 포트 22 같은 위험한 포트를 열기 위해 사용됩니다:
<figure><img src="https://lh5.googleusercontent.com/LliB7eb3cYfkEyOpyw1-eYgWsn2kq1yF6uRn5VYndvOuTvDlURimYx9UvuK8F2impTLmx50mid4MdTXE-Ljt2i_rxaIfnKUdji_hFjCdU9tdoW-axng9-W4tSL71gbbjrPQ7IYY5lAdH_G3UoMRMGGGOxQ=s2048" alt=""><figcaption></figcaption></figure>
### Elastic IP Addresses
_Elastic IP 주소_는 동적 클라우드 컴퓨팅을 위해 설계된 **정적 IPv4 주소**입니다. Elastic IP 주소는 AWS 계정에 할당되며, 이를 해제할 때까지 귀하의 것입니다. Elastic IP 주소를 사용하면 인스턴스나 소프트웨어의 실패를 신속하게 다른 인스턴스로 주소를 재매핑하여 숨길 수 있습니다.
An _Elastic IP address_는 동적 클라우드 컴퓨팅을 위해 설계된 **정적 IPv4 주소**입니다. Elastic IP 주소는 AWS 계정에 할당되며, 해제할 때까지 계정 소유입니다. Elastic IP를 사용하면 인스턴스나 소프트웨어 장애 시 해당 주소를 계정 내 다른 인스턴스로 빠르게 재매핑하여 장애를 가릴 수 있습니다.
### Connection between subnets
기본적으로 모든 서브넷은 **공용 IP 주소의 자동 할당이 꺼져 있지만** 이를 켤 수 있습니다.
기본적으로 모든 서브넷은 **공인 IP 자동 할당(auto-assign public IP)** 이 꺼져 있지만, 이를 켤 수 있습니다.
**라우팅 테이블 내의 로컬 경로는 VPC 서브넷 간의 통신을 가능하게 합니다.**
**A local route within a route table enables communication between VPC subnets.**
서브넷을 다른 서브넷과 **연결할 경우, 다른 서브넷과 연결된 서브넷에 접근할 수 없으며**, 직접 연결을 생성해야 합니다. **이는 인터넷 게이트웨이에도 적용됩니다**. 인터넷에 접근하기 위해 서브넷 연결을 통해 갈 수 없으며, 인터넷 게이트웨이를 서브넷에 할당해야 합니다.
서브넷을 서로 연결할 때, 한 서브넷을 통해 다른 서브넷에 연결된 서브넷들에 접근할 수는 없습니다. 각 서브넷과 직접 연결을 만들어야 합니다. **이것은 Internet gateways에도 적용됩니다.** 인터넷에 접근하려면 인터넷 게이트웨이를 서브넷에 직접 할당해야 합니다.
### VPC Peering
VPC 피어링은 **두 개 이상의 VPC를 연결**할 수 있게 해주며, IPV4 또는 IPV6를 사용하여 마치 동일한 네트워크의 일부인 것처럼 연결합니다.
VPC peering은 IPV4 또는 IPV6을 사용하여 **둘 이상의 VPC를 마치 동일한 네트워크의 일부인 것처럼 연결**할 수 있게 합니다.
피어 연결이 설정되면, **한 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에 라우팅할 수 없습니다.**
피어 연결이 설정되면 **한 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로 라우팅할 수 없습니다.**
### **VPC Flow Logs**
VPC 내에서 수백 또는 수천 개의 리소스가 서로 다른 공용 및 프라이빗 서브넷 간에 통신하고, VPC 피어링 연결을 통해 서로 다른 VPC 간에 통신할 수 있습니다. **VPC Flow Logs는 VPC 내 리소스의 네트워크 인터페이스 간에 흐르는 IP 트래픽 정보를 캡처할 수 있게 해줍니다.**
VPC 내에는 수백에서 수천 개의 리소스가 서로 다른 퍼블릭/프라이빗 서브넷 및 VPC 피어링 연결을 통해 통신할 수 있습니다. **VPC Flow Logs는 VPC 내 리소스의 네트워크 인터페이스 간에 흐르는 IP 트래픽 정보를 캡처**할 수 있게 해줍니다.
S3 접근 로그 및 CloudFront 접근 로그와 달리, **VPC Flow Logs에 의해 생성된 로그 데이터는 S3에 저장되지 않습니다. 대신, 캡처된 로그 데이터는 CloudWatch 로그로 전송됩니다.**
S3 액세스 로그나 CloudFront 액세스 로그와 달리, **VPC Flow Logs로 생성된 로그 데이터는 S3에 저장되지 않습니다. 대신 캡처된 로그 데이터는 CloudWatch logs로 전송됩니다**.
제한 사항:
- VPC 피어링 연결을 실행 중인 경우, 동일한 계정 내의 피어 VPC의 흐름 로그만 볼 수 있습니다.
- EC2-Classic 환경 내에서 리소스를 실행 중인 경우, 불행히도 해당 인터페이스에서 정보를 검색할 수 없습니다.
- VPC Flow Log가 생성되면 변경할 수 없습니다. VPC Flow Log 구성을 변경하려면 삭제한 후 새로 생성해야 합니다.
- 다음 트래픽은 로그에 의해 모니터링되거나 캡처되지 않습니다. VPC 내의 DHCP 트래픽, Amazon DNS 서버를 대상으로 하는 인스턴스의 트래픽.
- VPC 기본 라우터의 IP 주소로 향하는 트래픽과 인스턴스 메타데이터 수집에 사용되는 169.254.169.254 및 Amazon Time Sync Service에 사용되는 169.254.169.123으로의 트래픽.
- Windows 인스턴스의 Amazon Windows 활성화 라이센스와 관련된 트래픽
- 네트워크 로드 밸런서 인터페이스와 엔드포인트 네트워크 인터페이스 간의 트래픽
- 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 인터페이스와 엔드포인트 네트워크 인터페이스 간의 트래픽
CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페이스는 다른 로그 스트림을 사용합니다. 그리고 이러한 스트림 내에는 로그 항목의 내용을 보여주는 흐름 로그 이벤트 데이터가 포함됩니다. 이러한 **로그는 약 10~15분 동안의 데이터 캡처를 수행합니다.**
CloudWatch 로그 그룹에 데이터를 게시하는 각 네트워크 인터페이스는 서로 다른 로그 스트림을 사용합니다. 각 스트림 내에는 로그 항목의 내용을 보여주는 flow log 이벤트 데이터가 있습니다. 각 **로그는 약 10~15분의 창(window) 동안 데이터를 캡처**합니다.
## VPN
### Basic AWS VPN Components
1. **Customer Gateway**:
- Customer Gateway는 VPN 연결의 귀하 측을 나타내기 위해 AWS에서 생성하는 리소스입니다.
- 이는 본인의 Site-to-Site VPN 연결 측의 물리적 장치 또는 소프트웨어 애플리케이션입니다.
- 라우팅 정보와 네트워크 장치(예: 라우터 또는 방화벽)의 공용 IP 주소를 AWS에 제공하여 Customer Gateway를 생성합니다.
- VPN 연결 설정을 위한 참조 지점 역할을 하며 추가 요금이 발생하지 않습니다.
- Customer Gateway는 Site-to-Site VPN 연결에서 고객 측을 나타내기 위해 AWS에서 생성하는 리소스입니다.
- 본질적으로 Site-to-Site VPN 연결의 고객 측에 있는 물리적 장치 또는 소프트웨어 애플리케이션입니다.
- 라우팅 정보와 네트워크 장치(예: 라우터나 방화벽)의 공인 IP 주소를 AWS에 제공하여 Customer Gateway를 생성합니다.
- VPN 연결 설정을 위한 참조 지점이며 추가 요금이 발생하지 않습니다.
2. **Virtual Private Gateway**:
- Virtual Private Gateway (VPG)는 Site-to-Site VPN 연결의 Amazon 측에 있는 VPN 집중기입니다.
- VPC에 연결되어 있으며 VPN 연결의 대상 역할을 합니다.
- Virtual Private Gateway (VPG)는 Site-to-Site VPN 연결의 Amazon 측 VPN 집중기(concentrator)입니다.
- VPC에 연결되어 VPN 연결의 대상(target) 역할을 합니다.
- VPG는 VPN 연결의 AWS 측 엔드포인트입니다.
- VPC와 온프레미스 네트워크 간의 안전한 통신을 처리합니다.
- VPC와 온프레미스 네트워크 간의 보안 통신을 처리합니다.
3. **Site-to-Site VPN Connection**:
- Site-to-Site VPN 연결은 온프레미스 네트워크를 VPC에 안전한 IPsec VPN 터널을 통해 연결합니다.
- Site-to-Site VPN 연결은 온프레미스 네트워크를 IPsec VPN 터널을 통해 VPC에 연결합니다.
- 이 유형의 연결은 Customer Gateway와 Virtual Private Gateway가 필요합니다.
- 데이터 센터 또는 네트워크와 AWS 환경 간의 안전하고 안정적이며 일관된 통신을 위해 사용됩니다.
- 일반적으로 정기적이고 장기적인 연결에 사용되며, 연결을 통해 전송된 데이터 양에 따라 요금이 부과됩니다.
- 데이터 센터 또는 네트워크와 AWS 환경 간의 보안, 안정적이고 일관된 통신에 사용됩니다.
- 일반적으로 정기적이고 장기적인 연결에 사용되며 연결을 통해 전송되는 데이터 양에 따라 요금이 부과됩니다.
4. **Client VPN Endpoint**:
- Client VPN 엔드포인트는 클라이언트 VPN 세션을 활성화하고 관리하기 위해 AWS에서 생성하는 리소스입니다.
- 개별 장치(예: 노트북, 스마트폰 등)가 AWS 리소스 또는 온프레미스 네트워크에 안전하게 연결할 수 있도록 사용됩니다.
- Site-to-Site VPN과는 달리 전체 네트워크를 연결하는 것이 아니라 개별 클라이언트를 위해 설계되었습니다.
- Client VPN을 사용하면 각 클라이언트 장치가 VPN 클라이언트 소프트웨어를 사용하여 안전한 연결을 설정합니다.
- Client VPN endpoint는 클라이언트 VPN 세션을 활성화하고 관리하기 위해 AWS에서 생성하는 리소스입니다.
- 개별 장치(노트북, 스마트폰 등)가 AWS 리소스 또는 온프레미스 네트워크에 안전하게 연결할 수 있도록 사용됩니다.
- Site-to-Site VPN과 달리 전체 네트워크를 연결하는 것이 아니라 개별 클라이언트를 위해 설계되었습니다.
- Client VPN에서는 각 클라이언트 장치가 VPN 클라이언트 소프트웨어를 사용하여 보안 연결을 설정합니다.
### Site-to-Site VPN
**온프레미스 네트워크를 VPC와 연결합니다.**
**온프레미스 네트워크를 VPC와 연결**합니다.
- **VPN 연결**: 온프레미스 장비와 VPC 간의 안전한 연결입니다.
- **VPN 터널**: 고객 네트워크에서 AWS로 또는 그 반대로 데이터가 통과할 수 있는 암호화된 링크입니다.
- **VPN connection**: 온프레미스 장비와 VPC 간의 보안 연결입니다.
- **VPN tunnel**: 고객 네트워크와 AWS 간에 데이터가 전달될 수 있는 암호화된 링크입니다.
각 VPN 연결에는 두 개의 VPN 터널이 포함되어 있으며, 이를 동시에 사용하여 고가용성을 확보할 수 있습니다.
각 VPN 연결에는 고가용성을 위해 동시에 사용할 수 있는 두 개의 VPN 터널이 포함됩니다.
- **Customer gateway**: AWS에 고객 게이트웨이 장치에 대한 정보를 제공하는 AWS 리소스입니다.
- **Customer gateway device**: Site-to-Site VPN 연결 측의 물리적 장치 또는 소프트웨어 애플리케이션입니다.
- **Virtual private gateway**: Site-to-Site VPN 연결의 Amazon 측에 있는 VPN 집중기입니다. Site-to-Site VPN 연결의 Amazon 측 게이트웨이로 가상 프라이빗 게이트웨이 또는 전송 게이트웨이를 사용합니다.
- **Transit gateway**: VPC와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 전송 허브입니다. Site-to-Site VPN 연결의 Amazon 측 게이트웨이로 전송 게이트웨이 또는 가상 프라이빗 게이트웨이를 사용합니다.
- **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를 사용합니다.
#### Limitations
- 가상 프라이빗 게이트웨이에서 VPN 연결에 대한 IPv6 트래픽은 지원되지 않습니다.
- AWS VPN 연결은 경로 MTU 발견을 지원하지 않습니다.
- IPv6 트래픽은 virtual private gateway의 VPN 연결에서 지원되지 않습니다.
- AWS VPN 연결은 Path MTU Discovery를 지원하지 않습니다.
또한 Site-to-Site VPN을 사용할 때 다음 사항을 고려해야 합니다.
또한 Site-to-Site VPN을 사용할 때 다음 사항을 고려하세요.
- VPC를 공통 온프레미스 네트워크에 연결할 때는 네트워크에 대해 겹치지 않는 CIDR 블록을 사용하는 것이 좋습니다.
- VPC를 공통 온프레미스 네트워크에 연결할 때는 네트워크에 대해 겹치지 않는(non-overlapping) CIDR 블록을 사용하는 것이 권장됩니다.
### Client VPN <a href="#what-is-components" id="what-is-components"></a>
**귀하의 머신에서 VPC로 연결합니다.**
**내 기기에서 VPC로 연결**
#### Concepts
- **Client VPN endpoint:** 클라이언트 VPN 세션을 활성화하고 관리하기 위해 생성하고 구성하는 리소스입니다. 모든 클라이언트 VPN 세션이 종료되는 리소스입니다.
- **Target network:** Client VPN 엔드포인트와 연결된 네트워크입니다. **VPC의 서브넷이 대상 네트워크입니다.** 서브넷을 Client VPN 엔드포인트와 연결하면 VPN 세션을 설정할 수 있습니다. 고가용성을 위해 여러 서브넷을 Client VPN 엔드포인트와 연결할 수 있습니다. 모든 서브넷은 동일한 VPC에 속해야 하며, 각 서브넷은 서로 다른 가용 영역에 속해야 합니다.
- **Route**: 각 Client VPN 엔드포인트에는 사용 가능한 목적지 네트워크 경로를 설명하는 라우팅 테이블이 있습니다. 라우팅 테이블의 각 경로는 특정 리소스 또는 네트워크로의 트래픽 경로를 지정합니다.
- **Authorization rules:** 권한 부여 규칙은 **네트워크에 접근할 수 있는 사용자를 제한합니다**. 지정된 네트워크에 대해 접근이 허용된 Active Directory 또는 ID 공급자(IdP) 그룹을 구성합니다. 이 그룹에 속한 사용자만 지정된 네트워크에 접근할 수 있습니다. **기본적으로 권한 부여 규칙이 없으며**, 사용자가 리소스 및 네트워크에 접근할 수 있도록 권한 부여 규칙을 구성해야 합니다.
- **Client:** Client VPN 엔드포인트에 연결하여 VPN 세션을 설정하는 최종 사용자입니다. 최종 사용자는 OpenVPN 클라이언트를 다운로드하고, VPN 세션을 설정하기 위해 생성한 Client VPN 구성 파일을 사용해야 합니다.
- **Client CIDR range:** 클라이언트 IP 주소를 할당할 IP 주소 범위입니다. Client VPN 엔드포인트에 대한 각 연결은 클라이언트 CIDR 범위에서 고유한 IP 주소를 할당받습니다. 클라이언트 CIDR 범위를 선택합니다. 예를 들어, `10.2.0.0/16`입니다.
- **Client VPN ports:** AWS Client VPN은 TCP 및 UDP 모두에 대해 포트 443 및 1194를 지원합니다. 기본값은 포트 443입니다.
- **Client VPN network interfaces:** 서브넷을 Client VPN 엔드포인트와 연결하면 해당 서브넷에 Client VPN 네트워크 인터페이스가 생성됩니다. **Client VPN 엔드포인트에서 VPC로 전송되는 트래픽은 Client VPN 네트워크 인터페이스를 통해 전송됩니다**. 그런 다음 소스 네트워크 주소 변환(SNAT)이 적용되어 클라이언트 CIDR 범위의 소스 IP 주소가 Client VPN 네트워크 인터페이스 IP 주소로 변환됩니다.
- **Connection logging:** Client VPN 엔드포인트에 대한 연결 이벤트를 기록하기 위해 연결 로깅을 활성화할 수 있습니다. 이 정보를 사용하여 포렌식을 수행하거나 Client VPN 엔드포인트 사용 방식을 분석하거나 연결 문제를 디버깅할 수 있습니다.
- **Self-service portal:** Client VPN 엔드포인트에 대한 셀프 서비스 포털을 활성화할 수 있습니다. 클라이언트는 자격 증명을 사용하여 웹 기반 포털에 로그인하고 Client VPN 엔드포인트 구성 파일의 최신 버전을 다운로드하거나 AWS에서 제공하는 클라이언트의 최신 버전을 다운로드할 수 있습니다.
- **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가 제공하는 최신 클라이언트를 다운로드할 수 있습니다.
#### Limitations
- **클라이언트 CIDR 범위는 연결된 서브넷이 위치한 VPC의 로컬 CIDR**과 겹칠 수 없으며, Client VPN 엔드포인트의 라우팅 테이블에 수동으로 추가된 경로와도 겹칠 수 없습니다.
- 클라이언트 CIDR 범위는 **최소 /22**의 블록 크기를 가져야 하며, **/12를 초과해서는 안 됩니다.**
- 클라이언트 CIDR 범위의 **일부 주소**는 Client VPN 엔드포인트의 가용성 모델을 지원하는 데 사용되며, 클라이언트에 할당될 수 없습니다. 따라서 **지원할 최대 동시 연결 수의 두 배에 해당하는 IP 주소를 포함하는 CIDR 블록을 할당하는 것이 좋습니다.**
- **Client VPN 엔드포인트를 생성한 후 클라이언트 CIDR 범위를 변경할 수 없습니다.**
- **Client VPN 엔드포인트와 연결된 서브넷은 반드시 동일한 VPC에 있어야 합니다.**
- **동일한 가용 영역의 여러 서브넷을 Client VPN 엔드포인트와 연결할 수 없습니다.**
- Client VPN 엔드포인트는 **전용 테넌시 VPC에서 서브넷 연결을 지원하지 않습니다.**
- Client VPN은 **IPv4** 트래픽만 지원합니다.
- Client VPN은 **연방 정보 처리 표준(FIPS)** **준수**가 아닙니다.
- 다중 인증(MFA)이 Active Directory에 대해 비활성화된 경우, 사용자 비밀번호는 다음 형식일 수 없습니다.
- **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.
```
SCRV1:<base64_encoded_string>:<base64_encoded_string>
```
- 셀프 서비스 포털은 **상호 인증을 사용하여 인증하는 클라이언트에 대해 사용할 수 없습니다.**
- The self-service portal is **not available for clients that authenticate using mutual authentication**.
{{#include ../../../../banners/hacktricks-training.md}}
src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md
+57 -57
View File
@@ -6,34 +6,34 @@
Amazon S3는 **대용량의 데이터를 저장**할 수 있는 서비스입니다.
Amazon S3는 REST 상태의 데이터에 대한 **보호**를 달성하기 위해 여러 옵션을 제공합니다. 옵션에는 **Permission**(Policy), **Encryption**(Client and Server Side), **Bucket Versioning** 및 **MFA** **based delete**가 포함됩니다. **사용자**는 데이터 보호를 위해 이러한 옵션 중 어느 것이든 활성화할 수 있습니다. **데이터 복제**는 AWS의 내부 기능으로, **S3가 각 객체를 모든 가용 영역(Availability Zones) 전반에 자동으로 복제**하므로 조직에서 별도로 활성화할 필요가 없습니다.
Amazon S3는 REST 상태의 데이터에 대한 **보호**를 달성하기 위한 여러 옵션을 제공합니다. 옵션에는 **권한** (Policy), **암호화** (Client and Server Side), **Bucket Versioning** 및 **MFA** **기반 삭제**가 포함됩니다. **사용자**는 데이터 보호를 위해 이러한 옵션 중 어느 것이든 활성화할 수 있습니다. **데이터 복제**는 AWS의 내부 기능으로, **S3가 각 객체를 모든 Availability Zones에 자동으로 복제**하므로 조직에서 별도로 활성화할 필요가 없습니다.
리소스 기반 권한을 사용하면 버킷의 하위 디렉터리에 대한 권한을 개별적으로 정의할 수 있습니다.
리소스 기반 권한을 사용하면 버킷의 하위 디렉터리에 대한 권한을 별도로 정의할 수 있습니다.
### Bucket Versioning and MFA based delete
Bucket Versioning이 활성화되면 파일을 변경하려는 모든 작업은 해당 파일의 새 버전을 생성하고 이전 내용도 유지합니다. 따라서 내용이 덮어써지지 않습니다.
Bucket Versioning가 활성화되면, 파일을 변경하려는 모든 작업은 해당 파일의 새 버전을 생성하고 이전 내용도 보존합니다. 따라서 기존 내용을 덮어쓰지 않습니다.
또한, MFA based delete는 S3 버킷의 파일 버전이 삭제되는 것과 Bucket Versioning이 비활성화되는 것을 방지하므로 공격자가 해당 파일을 변경할 수 없습니다.
또한, MFA 기반 삭제는 S3 버킷의 파일 버전 삭제와 Bucket Versioning의 비활성화를 방지하므로 공격자가 이러한 파일을 변경할 수 없습니다.
### S3 Access logs
특정 버킷에 대해 **S3 access login**을 활성화할 수 있으며(기본값은 비활성화), 로그를 다른 버킷에 저장하여 누가 버킷에 접근하는지 확인할 수 있습니다(두 버킷은 동일한 리전이어야 합니다).
특정 버킷에 대해 **S3 access login**을 활성화(기본값은 비활성화)하고 로그를 다른 버킷에 저장하여 누가 버킷에 접근하는지 확인할 수 있습니다(두 버킷은 동일한 리전에 있어야 합니다).
### S3 Presigned URLs
버킷 내 지정된 파일에 **접근**하는 데 일반적으로 사용할 수 있는 presigned URL을 생성할 수 있습니다. **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
```
presigned URL은 **cli에서 object에 접근 권한이 있는 principal의 credentials로 생성할 수 있다** (사용하는 account에 접근 권한이 없으면 더 짧은 presigned URL이 생성되지만 쓸모없다)
presigned URL은 **cli에서 object에 접근 권한이 있는 principal의 자격 증명을 사용해 생성할 수 있습니다** (사용하는 계정에 접근 권한이 없으면 더 짧은 presigned URL이 생성되지만 쓸모가 없습니다)
```bash
aws s3 presign --region <bucket-region> 's3://<bucket-name>/<file-name>'
```
> [!NOTE]
> presigned URL을 생성하기 위해 필요한 권한은 부여되는 권한 자체뿐이므로, 이전 명령의 경우 주체(principal)가 필요로 하는 권한은 `s3:GetObject` 하나뿐입니다
> 사전 서명된 URL을 생성하는 데 필요한 유일한 권한은 부여되는 권한 그 자체이므로, 이전 명령의 경우 주체(principal)가 필요한 유일한 권한은 `s3:GetObject`
또한 **다른 권한**으로 presigned URL을 생성할 수도 있습니다:
또한 **다른 권한**으로 사전 서명된 URL을 생성할 수도 있습니다:
```python
import boto3
url = boto3.client('s3').generate_presigned_url(
@@ -44,22 +44,22 @@ ExpiresIn=3600
```
### S3 암호화 메커니즘
**DEK means Data Encryption Key** 이 키는 항상 생성되어 데이터를 암호화하는 데 사용되는 키입니다.
**DEK는 Data Encryption Key를 의미합니다**. 이 키는 항상 생성되며 데이터를 암호화하는 데 사용됩니다.
<details>
<summary><strong>Server-side encryption with S3 managed keys, SSE-S3</strong></summary>
이 옵션은 최소한의 구성만 필요하며 사용되는 암호화 키의 관리는 모두 AWS가 처리합니다. 해야 할 일은 **데이터를 업로드하면 S3가 나머지 모든 부분을 처리합니다**. S3 계정의 각 버킷에는 버킷 키가 할당됩니다.
이 옵션은 최소한의 구성만 필요하며, 사용되는 암호화 키 관리는 모두 AWS에서 처리합니다. 해야 할 일은 **데이터를 업로드하면 S3가 나머지를 처리합니다**. S3 계정의 각 버킷에는 bucket key가 할당됩니다.
- Encryption:
- 암호화:
- 객체 데이터 + 생성된 평문 DEK --> 암호화된 데이터 (S3에 저장)
- 생성된 평문 DEK + S3 Master Key --> 암호화된 DEK (S3에 저장) 및 평문은 메모리에서 삭제됨
- Decryption:
- 복호화:
- 암호화된 DEK + S3 Master Key --> 평문 DEK
- 평문 DEK + 암호화된 데이터 --> 객체 데이터
참고: 이 경우 **키는 AWS가 관리**합니다 (회전은 3년마다). 자체 키를 사용하는 경우 키를 회전, 비활성화하고 접근 제어를 적용할 수 있습니다.
참고: 이 경우 **키는 AWS에서 관리됩니다**(회전 주기: 3년마다). 자체 키를 사용하면 키 회전, 비활성화 및 접근 제어를 적용할 수 있습니다.
</details>
@@ -67,16 +67,16 @@ ExpiresIn=3600
<summary><strong>Server-side encryption with KMS managed keys, SSE-KMS</strong></summary>
이 방법은 S3가 key management service를 사용하여 데이터 암호화 키를 생성하도록 허용합니다. KMS는 키 관리 방식에 대해 훨씬 더 큰 유연성을 제공합니다. 예를 들어 CMK를 비활성화, 회전(rotate)하고 접근 제어를 적용할 수 있으며, AWS Cloud Trail을 통해 사용 내역을 감사할 수 있습니다.
이 방법은 S3가 키 관리 서비스(KMS)를 사용하여 데이터 암호화 키를 생성하도록 허용합니다. KMS는 키 관리 방법에 대해 훨씬 더 큰 유연성을 제공합니다. 예를 들어 CMK에 대해 비활성화, 회전 및 접근 제어를 적용할 수 있고, AWS Cloud Trail을 사용하여 사용 내역을 감사할 수 있습니다.
- Encryption:
- S3가 KMS CMK에 데이터 키를 요청함
- KMS는 CMK를 사용해 평문 DEK와 암호화된 DEK 쌍을 생성하여 S3로 보냄
- S3는 평문 키를 사용해 데이터를 암호화하고, 암호화된 데이터와 암호화된 키를 저장한 뒤 평문 키는 메모리에서 삭제함
- Decryption:
- 암호화:
- S3가 KMS의 CMK에 데이터 키를 요청함
- KMS가 CMK를 사용하여 평문 DEK와 암호화된 DEK 쌍을 생성하여 S3로 전송함
- S3가 평문 키로 데이터를 암호화하고, 암호화된 데이터와 암호화된 키를 저장한 후 평문 키를 메모리에서 삭제함
- 복호화:
- S3가 객체의 암호화된 데이터 키를 복호화해 달라고 KMS에 요청함
- KMS는 CMK로 데이터 키를 복호화하여 S3로 전송함
- S3는 객체 데이터를 복호화함
- 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가 대신 암호화를 수행합니다.
- Encryption:
- 사용자는 객체 데이터 + 고객 키를 S3로 전송
- 고객 키로 데이터를 암호화하고 암호화된 데이터를 저장
- 고객 키의 salted HMAC 값도 향후 키 검증을 위해 저장됨
- 암호화:
- 사용자가 객체 데이터 + 고객 키를 S3로 전송함
- 고객 키로 데이터를 암호화하고 암호화된 데이터가 저장됨
- 향후 키 검증을 위해 고객 키의 솔트된 HMAC 값도 저장됨
- 고객 키는 메모리에서 삭제됨
- Decryption:
- 사용자가 고객 키를 전송
- 복호화:
- 사용자가 고객 키를 전송함
- 키는 저장된 HMAC 값과 대조되어 검증됨
- 고객이 제공한 키로 데이터를 복호화함
- 검증된 고객 제공 키로 데이터를 복호화함
</details>
@@ -102,16 +102,16 @@ ExpiresIn=3600
<summary><strong>Client-side encryption with KMS, CSE-KMS</strong></summary>
SSE-KMS와 유사하게 이 방법도 key management service를 사용하여 데이터 암호화 키를 생성합니다. 다만 이번에는 KMS가 S3가 아니라 클라이언트에서 호출됩니다. 암호화는 클라이언트 측에서 수행되며 암호화된 데이터가 S3로 전송되어 저장됩니다.
SSE-KMS와 유사하게, 이 방법도 KMS를 사용하여 데이터 암호화 키를 생성합니다. 다만 이번에는 KMS가 S3가 아니라 클라이언트를 통해 호출됩니다. 암호화는 클라이언트 측에서 수행되고 암호화된 데이터가 S3로 전송되어 저장됩니다.
- Encryption:
- 암호화:
- 클라이언트가 KMS에 데이터 키를 요청함
- KMS는 평문 DEK와 CMK로 암호화된 DEK를 반환함
- 두 키를 클라이언트로 전송
- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK를 S3에 전송(암호화된 DEK는 S3 내 메타데이터로 저장됨)
- Decryption:
- KMS가 CMK로 평문 DEK와 암호화된 DEK를 반환함
- 두 키를 클라이언트로 전달함
- 클라이언트는 평문 DEK로 데이터를 암호화하고 암호화된 데이터 + 암호화된 DEK(메타데이터로 저장)를 S3에 전송함
- 복호화:
- 암호화된 데이터와 암호화된 DEK가 클라이언트로 전송됨
- 클라이언트가 KMS에 암호화된 키 복호화를 요청하면 KMS가 평문 DEK를 반환함
- 클라이언트가 KMS에 암호화된 키를 CMK로 복호화해 달라고 요청하면 KMS가 평문 DEK를 반환함
- 클라이언트는 평문 DEK로 암호화된 데이터를 복호화함
</details>
@@ -120,21 +120,21 @@ SSE-KMS와 유사하게 이 방법도 key management service를 사용하여 데
<summary><strong>Client-side encryption with customer provided keys, CSE-C</strong></summary>
이 메커니즘을 사용하면 자체 제공 키를 활용하여 AWS-SDK 클라이언트를 통해 데이터를 S3로 전송하기 전에 암호화할 수 있습니다.
이 메커니즘을 사용하면 자체 제공 키를 활용하여 AWS-SDK 클라이언트를 통해 데이터를 S3로 전송하기 전에 클라이언트 측에서 암호화할 수 있습니다.
- Encryption:
- 암호화:
- 클라이언트가 DEK를 생성하고 평문 데이터를 암호화함
- 그런 다음 자체 CMK로 DEK를 암호화함
- 암호화된 데이터 + 암호화된 DEK를 S3에 전송하여 저장
- Decryption:
- S3는 암호화된 데이터와 DEK를 전송
- 클라이언트는 DEK를 암호화하는 데 사용된 CMK를 이미 보유하고 있으므로 DEK를 복호화한 다음 평문 DEK로 데이터를 복호화함
- 암호화된 데이터 + 암호화된 DEK를 S3에 제출하여 저장함
- 복호화:
- 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>
@@ -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
@@ -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
```
### dual-stack <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
### 듀얼-스택 <a href="#dual-stack-endpoints-description" id="dual-stack-endpoints-description"></a>
virtual hosted-style 또는 path-style 엔드포인트 이름을 사용하여 dual-stack 엔드포인트를 통해 S3 버킷에 액세스할 수 있습니다. 이는 IPv6를 통해 S3에 액세스할 때 유용합니다.
virtual hosted-style 또는 path-style endpoint 이름을 사용하여 dual-stack endpoint를 통해 S3 버킷에 접근할 수 있습니다. 이는 IPv6로 S3에 접근할 때 유용합니다.
Dual-stack 엔드포인트는 다음 구문을 사용합니다:
Dual-stack endpoints는 다음 구문을 사용합니다:
- `bucketname.s3.dualstack.aws-region.amazonaws.com`
- `s3.dualstack.aws-region.amazonaws.com/bucketname`
### Privesc
다음 페이지에서 **S3 권한을 악용하여 권한을 상승시키는 방법**을 확인할 수 있습니다:
다음 페이지에서 **S3 permissions을 악용해 권한을 상승시키는 방법**을 확인할 수 있습니다:
{{#ref}}
../aws-privilege-escalation/aws-s3-privesc/README.md
@@ -262,23 +262,23 @@ Dual-stack 엔드포인트는 다음 구문을 사용합니다:
../aws-persistence/aws-s3-persistence/README.md
{{#endref}}
## Other S3 vulns
## 기타 S3 취약점
### 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) 임의의 버킷 응답을 다른 버킷의 응답인 것처럼 캐시할 수 있었습니다. 이는 예를 들어 자바스크립트 파일 응답을 변경하여 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는 Amazon Simple Storage Service (Amazon **S3**)에서 표준 **SQL**을 사용해 데이터를 직접 **분석**할 수 있도록 해주는 대화형 쿼리 서비스입니다.
Amazon Athena는 표준 **SQL**을 사용하여 Amazon Simple Storage Service (Amazon **S3**)에 있는 데이터를 직접 **분석**하기 쉽게 해주는 인터랙티브 쿼리 서비스입니다.
모니터링되는 S3 버킷에 나타날 컨텐츠 형식에 맞는 **관계형 DB 테이블**을 준비해야 합니다. 그런 다음 Amazon Athena는 로그에서 DB를 채워 쿼리를 수행할 수 있게 됩니다.
모니터링할 S3 버킷에 나타날 콘텐츠 형식으로 **관계형 DB 테이블을 준비**해야 합니다. 그러면 Amazon Athena가 로그로부터 DB를 채워 쿼리할 수 있게 됩니다.
Amazon Athena는 **이미 암호화된 S3 데이터를 쿼리할 수 있는 기능**을 지원하며, 구성된 경우 **Athena가 쿼리 결과를 암호화하여 S3에 저장할 수도 있습니다**.
Amazon Athena는 **이미 암호화된 S3 데이터를 쿼리하는 기능**을 지원하며, 구성된 경우 **쿼리 결과를 암호화하여 S3에 저장할 수도 있습니다**.
이 결과 암호화는 쿼리된 기본 S3 데이터와 독립적이므로, S3 데이터가 암호화되어 있지 않더라도 쿼리 결과는 암호화될 수 있습니다. 유의할 점은 Amazon Athena가 **다음 S3 암호화 방법으로 암호화된 데이터**, 즉 **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
@@ -302,7 +302,7 @@ aws athena get-prepared-statement --statement-name <name> --work-group <wg-name>
# Run query
aws athena start-query-execution --query-string <query>
```
## 참고 자료
## 참고자료
- [https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3](https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3)
- [https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html)