VPC 보안
Preventive Services
- Security Groups
- Network ACLs
- AWS WAF
- ACM
- AWS Shield
- AWS Firewall Manager
- Gateway Load Balancer
- AWS Network Firewall
- DNSSEC validation
Detective Services
- CloudWatch
- CloudTrail
- VPC Flow Logs
- GuardDuty
- Traffic Mirroring
- Route 53 resolver query logs
Security Group (보안 그룹)
- 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽 역할
- 서브넷 수준이 아니라 인스턴스 수준에서 작동 (EC2 인스턴스의 ENI와 연결됨)
- 하나의 EC2 인스턴스 ENI에 5개까지 보안그룹 연결 가능
- 보안 그룹은 허용 규칙만 지정 가능하고 거뷰 규칙은 지정할 수 없음 (허용하지 않을 경우 거부 상태)
- 보안 그룹은 연결 상태를 추적하는 상태저장 방화벽 (Stateful Firewall)
- 보안 그룹은 생성된 VPC 내에서만 사용 가능
✅ 트래픽을 전송할 경우 반환받는 트래픽은 거부하지 않고 허용한다. (Stateful)
Stateful (상태저장)
- 아웃바운드 규칙에 상관없이 허용된 인바운드 트래픽에 대한 반응으로 외부로 나가는 흐름이 수행
- 사용자가 인스턴스에서 요청을 전송하면 해당 요청의 응답 트래픽은 인바운드 보안 그룹 규칙에 관계없이 인바운드 흐름이 허용
- Windows EC2 인스턴스로 RDP 프로토콜 3389번으로 접속
- EC2 인스턴스에 적용된 보안 그룹의 허용 규칙은 RDP 프로토콜 전체 허용, 모든 트래픽 모든 IP 허용
EC2 인스턴스에서 웹 사이트로 접속시 웹사이트가 정상적으로 로딩되었다. 이는 EC2 인스턴스에서 웹 사이트에 요청을 한 것이기 때문에 허용 규칙이 적용되고 요청을 전송한 인스턴스의 보안그룹 허용규칙이 허용되었기 때문에 상태 저장(연결 상태 추적) 특성에 의해서 인바운드 흐름도 허용되었지만 인스턴스의 보안 그룹에서 모든 트래픽을 허용하는 규칙을 삭제하였을 때 인스턴스의 아웃바운드 트래픽은 HTTP (80번 포트) 또는 HTTPS (443번 포트)를 허용하지 않기 때문에 상태 저장 특성에 의해 인바운드 트래픽도 자동적으로 허용되지 않아 웹사이트가 로딩되지 않았다.
Network Access Control List (NACL)
- 서브넷 내부와 외부의 트래픽을 제어하는 방화벽
- 서브넷 레벨의 연결 방화벽
- 하나의 NACL은 여러 서브넷과 연결 가능
- 하나의 서브넷은 하나의 NACL만 연결 가능
- NACL은 허용, 거부 규칙 모두 지정 가능
NACL은 연결 상태를 추적하지 않은 상태 비저장 방화벽 (Stateless Firewall)
- 인바운드 트래픽에 대한 응답은 아웃바운드 트래픽 규칙을 따름
- 아웃바운드 트래픽에 대한 응답은 인바운드 트래픽 규칙을 따름
- EC2 웹서버 운영시 외부에서 Client가 접속 후 응답 트래픽을 받을 때 NAT을 사용하므로 임시포트 (Ephemeral Ports)
1024-65535를 사용
Network Access Control List (NACL) 규칙 번호
- 가장 낮은 번호가 지정된 규칙부터 시작해서 트래픽이 내부 또는 외부로 전달되도록 허용되는지 결정
- 번호가 가장 낮은 규칙부터 평가
- 규칙에 사용할 수 있는 가장 높은 번호는 32766
| 규칙번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/거부 |
|---|---|---|---|---|---|
| 90 | HTTP(80) | TCP(6) | 80 | 0.0.0.0/0 | 허용 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 거부 |
- 90번 규칙이 먼저 적용되어 HTTP 80번 프로토콜의 트래픽 허용
- 100번 규칙은 90번 적용 HTTP 80을 제외한 모든 트래픽 거부
NACL Test Case
아래 네트워크 ACL 규칙은 퍼블릭 서브넷에 연결되어 있으며 해당 서브넷 안에는 EC2 인스턴스가 존재합니다.
인바운드와 아웃바운드를 각각 다르게 설정하여 인스턴스에서 웹사이트에 페이지를 요청하여 비교해보겠습니다.
👨🏻💻 인바운드 규칙 추가 (443번 포트 거부) (웹사이트 정상 접속)
인바운드 규칙
| 규칙번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/거부 |
|---|---|---|---|---|---|
| 50 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 거부 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 거부 |
📖 웹사이트에서 전달받는 인바운드 트래픽은 임시 포트로 응답받기 때문에 443번 포트를 거부해도 통신이 가능하다.
아웃바운드 규칙
| 규칙번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/거부 |
|---|---|---|---|---|---|
| 40 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 허용 |
| 50 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 거부 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 거부 |
👨🏻💻 인바운드 규칙 수정 (임시 포트 차단) (웹사이트 접속 불가)
인바운드 규칙
| 규칙번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/거부 |
|---|---|---|---|---|---|
| 20 | 사용자 지정 TCP | TCP(6) | 32768 - 65535 | 0.0.0.0/0 | 거부 |
| 50 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 거부 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 거부 |
아웃바운드 규칙
| 규칙번호 | 유형 | 프로토콜 | 포트 범위 | 대상 | 허용/ 거부 |
|---|---|---|---|---|---|
| 40 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 허용 |
| 50 | HTTPS(443) | TCP(6) | 443 | 0.0.0.0/0 | 거부 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 허용 |
| 100 | 모든 트래픽 | 모두 | 모두 | 0.0.0.0/0 | 거부 |
Ephemeral Port는 TCP Connection시에 커널이 임의로 port를 binding하는 경우가 있는데 이런 port를 Ephemeral port라고 부른다. 여기서 임의로 할당되는 port의 범위를 커널에서 관리하기 때문에 설정 또는 OS마다 다르다. AWS에서 제공하는 Amazon Linux AMI인 경우 Ephemeral port range가 32768 - 60999로 설정되어 있다.
EC2 인스턴스 바인딩 Port 범위 확인
cat /proc/sys/net/ipv4/ip_local_port_range
32768 60999
상단 테스트 결과를 보고 인스턴스에서 웹사이트에 요청시에는 443번 포트로 요청하지만 웹사이트에서 인스턴스로 반환할 때는 443번 포트로 반환하는 것이 아니라 임시 포트(휘발성 포트)를 통해 반환한다는 것을 알 수 있다.
- 다수의 Linux 커널(Amazon Linux 커널 포함)이 포트
32768-61000을 사용합니다. - Elastic Load Balancing에서 시작된 요청은 포트
1024-65535를 사용합니다. - Windows Server 2003까지의 Windows 운영 체제에서는 포트
1025-5000을 사용합니다. - Windows Server 2008 이상 버전은 포트
49152-65535를 사용합니다. - NAT 게이트웨이는 포트
1024-65535를 사용합니다. - AWS Lambda 함수는 포트
1024-65535를 사용합니다.
프록시 서버를 구성할 때는 최소한의 권한 원칙으로 OS가 동일하다면 해당 포트로 범위를 좁혀 보안그룹을 구성합니다.
EC2 인스턴스에 접속하여 요청과 응답 로그를 확인하기 위해 VPC 플로우 로그를 생성하여 결과를 S3로 10분 간격으로 전송받아 전송 받은 로그 데이터 중 원하는 데이터만 추출하고자 Athena로 쿼리를 해보았는데 22번 포트로 내 IP가 아닌 다른 IP로 접속 허용된 로그가 있어서 내가 시도하지 않은 로그 데이터만 쿼리해서 추출해보았다.
Client -> EC2
위 사진을 보다시피 dstaddr은 EC2 인스턴스의 퍼블릭 IPv4 주소로 클라이언트가 서버에 접속할 때 클라이언트의 포트는 Ephemeral Port가 부여된 것을 확인할 수 있다.
EC2 -> Client
반대로 서버에서 클라이언트로 응답할 때에는 클라이언트가 서버로 요청했을 때의 포트번호가 src 포트번호로 설정되고 dstaddr에는 클라이언트의 IP 주소가 설정되어 dstport에는 Ephemeral Port가 부여되었다.
VPC Flow Logs 항목 설명
| Column | 내용 |
|---|---|
| version | VPC Flow Log Version |
| vpc-id | 소스 ENI를 포함하는 VPC의 ID |
| subnet-id | 소스 ENI를 포함하는 Subnet의 ID |
| instance-id | 소스 인터페이스와 연관된 인스턴스의 ID |
| interface-id | 소스 ENI의 ID |
| account-id | 소스 ENI를 포함하는 AWS 계정의 Account Number |
| type | 트래픽 유형(IPv4, IPv6) |
| srcaddr | 소스 IP |
| dstaddr | 목적지 IP |
| srcport | 소스 포트 |
| dstport | 목적지 포트 |
| pkt-srcaddr | 소스의 패킷 수준의 IP 주소, NAT 게이트웨이와 같이 트래픽이 통과하는 중간 레이어의 IP 주소를 구분 |
| pkt-dstaddr | 패킷 수준의 IP 주소, pkt-srcaddr 필드와 유사하지만 대상 IP 주소에 대한 필드 |
| protocol | 패킷에 대한 Protocol Number |
| bytes | 캡처 기간 중 전송된 바이트 수 |
| packets | 캡처 기간 중 전송된 패킷 수 |
| start | 캡처 기간의 시작 시간 |
| end | 캡처 기간의 종료 시간 |
| action | ACCEPT: Security Group 또는 NACL에서 허용한 트래픽 REJECT: Security Group 또는 NACL에서 허용하지 않은 트래픽 |
| tcp-flags | TCP Flag는 캡처 기간 동안 OR 처리됨 SYN: 2, SYN-ACK: 18, FIN: 1, RST: 4 |
| log-status | Flow Log의 로깅 상태 OK: 데이터가 선택된 대상에 정상적으로 로깅 NODATA: 캡처 기간 중 ENI에서 전송하거나 수신된 네트워크 트래픽이 없을 경우 SKIPDATA: 캡처 기간 중 일부 Flow Log 레코드를 건너뜀. 내부 용량 제한 또는 내부 오류 원인 가능 |
VPC Flow Logs 특징
- 네트워크 연결 문제 해결 및 보안 문제, 네트워크상 접근 규칙이 정상 작동하는지 확인하기 위해 Flow log 수집, 저장 및 분석 가능
- EC2에 직접 에이전트를 설치하여 데이터 수집 시 해당 인스턴스에 부하를 줄 수 있음
- VPC Subnet과 ENI의 네트워크 트래픽이 CloudWatch Logs를 통해 저장된 후 별도 응용 프로그램 등에서 분석 가능
- 특정 유형의 트래픽을 감지하여 알림을 만들거나 트래픽의 변화와 패턴을 파악하기 위한 통계도 만들 수 있다.
Log에 포함된 정보
- Security Group 및 NACL 규칙에 의해 허용 또는 차단 트래픽 정보
- 소스, 목적지 IP 주소, 포트, 프로토콜 번호, 패킷 바이트, 모니터링 간격 시간, Action (ACCEPT or REJECT)
Log에 포함되지 않는 정보
- Amazon DNS 서버 트래픽 (개인 호스트 영역 쿼리 포함)
- Amazon에서 제공하는 Windows 라이선스 활성화 트래픽
- 인스턴스 메타 데이터 요청 (169.254.169.254)
- DHCP 요청과 응답
- ARP 및 NTP (169.254.169.123)
제한 사항
- 서비스 트래픽은 미러링 된 트래픽보다 우선순위가 높음, 혼잡 발생 시 미러링된 트래픽이 삭제될 수 있음
- 미러링된 트래픽은 Security Group의 영향을 받지 않음
설정 위치에 따른 범위 (VPC vs 서브넷 vs 인스턴스)
VPC: VPC 하위의 모든 ENI (EC2, ELB, RDS 등)Subnet: Subnet 하위의 모든 ENI (EC2, ELB, RDS 등)EC2: ENI에 대한 개별 설정
보안 그룹 vs NACL
| 보안그룹 | 네트워크 ACL |
|---|---|
| 인스턴스 레벨에 적용 (ENI와 연결) | 서브넷 레벨에 적용 |
| 허용 규칙만 지원 | 허용 및 거부 규칙 지원 |
| 상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용됨 | 상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함 |
| 트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가 | 트래픽 허용 여부를 결정할 때 번호가 가장 낮은 규칙부터 순서대로 규칙을 처리 |
| 인스턴스 시작 시 누군가 보안 그룹을 지정하거나 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨 | 연결된 서브넷의 모든 인스턴스에 자동 적용됨 |
Security Group vs NACL
Security Group
- Operates at the instance level (applied to ENI attached to EC2 instance)
- Supports Allow rules only
- Is stateful: Return traffic is automatically allowed
- All rules are evaluated before deciding whether to allow traffic
- Can not block the traffic from specific IP address or CIDR block
Network ACL
- Operates at the Subnet level
- Supports both Allow and Deny rules
- Is stateless: Return traffic must be explicitly allowed by rules
- Rules are processed in number order and if matched no further rules are evaluated
- With Deny rules, traffic can be blocked from specific IP address or CIDR block
위처럼 보안그룹과 NACL의 특성을 고려하여 특정 클라이언트 IP가 웹 서버로 구동되고 있는 EC2 인스턴스의 접근하는 것을 막기 위해서는 거부 규칙이 있는 NACL에서 규칙을 정의하고 NACL의 규칙은 더 낮은 규칙번호가 우선순위를 갖기 때문에 거부하려는 규칙을 허용하려는 규칙보다 더 낮은 규칙번호에 선언하여 서브넷 레벨에서 작동하는 NACL에서 트래픽을 제어할 수 있다.