[AWS-Security] 5.3. 트래픽 라우팅(Route table) 및 가상 방화벽(Security Group, NACL)

1. 라우팅 테이블 (Route table)

라우팅 테이블은 VPC 전체에서 ‘전송된 IP 주소’를 기반으로 트래픽이 전달되어야 하는 목적지를 정의하는 규칙 집합이다.

1.1. 라우팅 테이블의 구성 요소

라우팅 규칙은 크게 두 부분으로 나뉜다.

• 목적지 (Destination) : 트래픽이 최종적으로 가려고 하는 도착지로, IP 주소 범위(CIDR) 형식으로 지정한다.
• 대상 (Target)
  • local : 트래픽이 동일한 VPC 내에서 라우팅됨을 의미한다. 밖으로 나갈 필요 없이 내부 통신으로 수행
  • 게이트웨이/인터페이스 : Internet Gateway(IGW), NAT Gateway, VPC Peering, ENI 등 트래픽이 통과해야 하는 리소스를 지정하여 통신

  라우팅	목적지 (Destination)	대상 (Target)
  Route 1	10.0.0.0/26	local
  Route 2	0.0.0.0/0	igw-1234

1.2. 라우팅 테이블의 작동 방식과 우선순위

• 시나리오 : 트래픽이 IP 주소 10.0.0.1로 전송된다.
  (이 범위는 10.0.0.0/26(Route 1)에도 속하고, 0.0.0.0/0(Route 2)에도 속한다.)
• 경로 우선 순위 : 트래픽이 두 경로 모두 일치하는 경우, 더 구체적인 경로(Longest Prefix Match)를 최우선으로 따른다. 따라서, 10.0.0.1로 가는 트래픽은 Route 1(local)을 타고 내부에서 처리된다.

1.3. Default 라우팅 테이블과 명시적 연결

• VPC 생성 시, 자동으로 Default Route table이 생성된다.
• 이 Default Route table에는 VPC 전체 CIDR 범위에 대해 local로 향하는 단일 규칙이 기본적으로 포함된다.
  (VPC 내의 모든 서브넷은 서로 쉽게 통신 가능)
• 서브넷별 라우팅 분리
  • Default Route table에 IGW 경로를 추가하면, 인터넷에 연결되면 안되는 Private Subnet까지 이 규칙을 따라 Public Subnet이 되어 버린다.
  • ‘Public Subnet’만을 위한 새 라우팅 테이블을 수동으로 생성하여, IGW 경로(0.0.0.0/0 -> igw-id)를 추가하고 Public Subnet에만 명시적으로 연결해야 한다.
    (Private Subnet은 Default Route table을 따르게 하거나, 동일하게 Private 용으로 추가 생성)

1.4. Private Subnet의 NAT Gateway 라우팅

• Private Subnet 안에 있는 인스턴스가 업데이트 등을 위해 외부(ex. 8.8.8.8)로 트래픽을 보내야 할 때에도 길을 알려줘야 한다.
• Private Subnet 전용 Route table을 만들고, 목적지 0.0.0.0/0의 대상을 Internet Gateway(IGW)가 아닌 NAT Gateway(NGW)로 지정하여 추가한다.
• NAT Gateway의 특성 상 밖에서 안으로 들어오는 SSH 연결은 차단 된다.

1.5. Private 인스턴스의 트래픽 아웃바운드 흐름

1. Private Subnet의 인스턴스가 8.8.8.8에 요청한다.
2. Private Subnet과 연결된 라우팅 테이블을 기반으로 요청이 라우팅된다.
3. Private Subnet의 라우팅 테이블은 트래픽을 NAT Gateway로 전달한다.
4. NAT Gateway는 주소 변환을 수행하고, 트래픽을 전달한다.
5. NAT Gateway는 Public Subnet에 있으므로, 전달된 트래픽은 Public Subnet과 연결된 라우팅 테이블을 기반으로 라우팅 된다.
6. Public Subnet의 라우팅 테이블은 트래픽을 Internet Gateway로 전달한다.
7. Internet Gateway는 Public Internet을 통해 트래픽을 목적지 8.8.8.8로 라우팅한다.

Public 인스턴스의 트래픽 아웃바운드 흐름 중간에 대리인 역할을 하는 NAT Gateway를 거칠 필요가 없기 때문에, 훨씬 단순하다.

1. 패킷 생성 : 퍼블릭 인스턴스가 8.8.8.8에 요청한다. (이때 서버 내부에서 출발지 IP는 인스턴스의 ‘Private IP’로 설정되어 있음))
2. 라우팅 테이블 확인
   1. 인스턴스가 속한 Public Subnet의 ‘라우팅 테이블’을 확인한다.
   2. 외부 인터넷(보통 0.0.0.0/0으로 표기)으로 가는 트래픽에 대해 인터넷 게이트웨이(IGW)로 가라고 등록되어 있다.
3. IGW로 전달 : 트래픽이 서브넷의 라우팅 규칙을 따라 인터넷 게이트웨이(IGW)로 바로 전달된다.
4. 주소 변환 (1:1 NAT) : 인터넷 게이트웨이(IGW)가 패킷을 실제 외부 인터넷으로 내보내기 직전, 출발지 IP(프라이빗 IP)를 인스턴스에 매핑되어 있는 ‘Public IP(또는 EIP)’로 변환한다. (AWS에서는 IGW가 이 1:1 네트워크 주소 변환을 논리적으로 처리)
5. 목적지 도착 : 출발지가 퍼블릭 IP로 바뀐 패킷이 최종적으로 Public Intenet망을 타고 목적지(8.8.8.8)에 도달한다.

Private vs Public 아웃바운드 차이점

• Private 인스턴스 : 인터넷과 직접 통신할 수 있는 공인(Public) IP가 없으므로, NAT Gateway라는 통로를 한 번 더 거쳐 NAT Gateway의 Public IP를 통해 나간다.
• Public 인스턴스 : 이미 자신과 연결된 Public IP가 존재하므로, 인터넷 게이트웨이(IGW)가 Private IP를 1:1 매칭되는 Public IP로 바꿔준 뒤 곧바로 내보낸다.

2. 보안 그룹 (Security Group)

보안 그룹 (Security Group)은 인스턴스 안팎으로 허용되는 네트워크 트래픽을 결정하는 규칙들의 집합이다.
IAM 정책이 ‘어떤 API 작업을 할 수 있는지’를 통제한다면, 보안 그룹은 ‘어떤 네트워크 트래픽이 들어오고 나갈 수 있는지’를 통제한다.

2.1. 보안 그룹 규칙의 3가지 핵심 요소

보안 그룹(Security Group)은 명시적으로 허용된 트래픽 외에는 모두 기본적으로 차단 (Deny)하는 방식을 사용한다.

• 방향 및 출발지/도착지
  • 아웃바운드(Outbound) : 인스턴스에서 ‘나가는’ 트래픽이며, 트래픽이 향할 ‘목적지(Destination)’를 지정한다.
  • 인바운드(Inbound) : 인스턴스로 ‘들어오는’ 트래픽이며, 트래픽이 시작된 출발지(Source)를 지정한다.
• 프로토콜 : TCP(6), UDP(17), ICMP(1) 등 통신 규약을 지정한다.
• 포트 범위 : 목적지나 출발지의 특정 포트 번호(SSH-22, HTTPS-443)를 지정한다.

출발지나 목적지에는 IP 주소(CIDR Block)뿐만 아니라 다른 Securit Group의 ID를 입력할 수도 있다. 이는 특정 그룹의 인스턴스들끼리만 통신하게 만들 때 유용하다.

2.2. ‘Default Securit Group’의 특징

VPC를 생성하면 자동으로 ‘Default Security Group’이 생성된다.

• 아웃바운드 : 0.0.0.0/0으로 모든 트래픽 허용
• 인바운드 : 출발지가 자신과 동일한 VPC CIDR 대역인 트래픽만 모두 허용 기본 상태의 Security Group만 있으면 인터넷(외부)에서 들어오는 트래픽은 모두 차단된다.

2.3. Public 접속 허용 딜레마와 해결책

외부 인터넷에서 Public Subnet의 인스턴스로 원격 접속(SSH, 22번 포트)하려면 인바운드 규칙을 열어줘야 한다.

• 문제 : Default Security Group에 허용 규칙을 추가하면, Default Security Group을 동일하게 사용하고 있는 다른 Private Subnet의 인스턴스까지 외부 접속이 허용되어 버린다.
• 해결 (새 Security Group 생성 및 추가 연결)
  • Private Subnet의 다른 인스턴스 방화벽은 건드리지 않기 위해, 새로운 Security Group을 생성해야한다.
  • 새로운 Security Group에 0.0.0.0/0 -> 22 인바운드 허용 규칙을 넣고, Public Subnet의 인스턴스에만 추가로 Attach 한다.
    (인스턴스 한 대 당 최대 5개의 Security Group을 연결할 수 있음)

2.4. Bastion Host

외부와 완전히 차단된 Private Subnet의 인스턴스에 접속하는 방법으로 Bastion Host를 이용할 수 있다.

• Private 인스턴스에 인터넷을 통해 SSH로 직접 연결할 수는 없다.
• 대신 SSH 허용한 Public 인스턴스를 ‘Bastion Host’로 활용한다.
• 접속 흐름 : 로컬 PC -> Public 인스턴스 -> (SSH 접속) -> Private 인스턴스

2.5. 웹 서버에 대한 무차별 SSH 공격 방어

2.5.1. 문제 상황: 과도한 허용 규칙

• 웹 사이트를 운영하기 위해 Public Internet이 들어올 수 있도록 웹 서버 인스턴스의 Security Group을 허용한 상황이다.
• 웹 서버 정상 통신을 위해 모든 포트 범위(0-65535)를 허용하는 것은 위험한 상태이다.
• 웹 트래픽 뿐만 아니라, 서버를 장악하기 위한 SSH 포트(22번)로 무차별 대입 공격(Brute force)을 시도하는 것까지 허용하는 것이다.

2.5.2. 해결 방법: 필요한 트래픽(포트)만 허용

웹 사이트 운영에 필수적인 트래픽은 HTTP(80)와 HTTPS(443)이다.
따라서, 모든 포트 허용을 지우고 통신이 필요한 포트만 허용하는 것이 바람직하다.

출발지	프로토콜 (숫자)	포트 범위
0.0.0.0/0	TCP (6)	80 (HTTP)
0.0.0.0/0	TCP (6)	443 (HTTPS)

3. NACL (Network ACL)

Network ACL은 Security Group과 유사하지만, 특정 인스턴스가 아닌 ‘서브넷 단위’로 적용되는 방화벽이다.

3.1. 규칙 적용 방식 차이: 순서 지정 유무

• Security Group
  • 규칙의 순서를 고려하지 않는다.
  • 일치하는 허용 규칙이 하나라도 있으면 허용된다.
  • Deny에 대한 규칙 등록이 불가능하다.
• NACL
  • 각 규칙에 고유한 번호가 부여되며, 번호 순서대로 평가된다.
  • 트래픽과 일치하는 ‘첫 번째’ 규칙이 발견되면 즉시 그 규칙이 적용되며, 평가는 종료된다.
  • Allow와 Deny에 대한 규칙을 모두 등록할 수 있다.

[예시: NACL 규칙 평가]

규칙 #	타입	프로토콜	포트 범위	출발지	허용/거부
100	HTTPS	TCP	443	0.0.0.0/0	Allow
200	ALL	TCP	ALL	0.0.0.0/0	Deny

-> HTTPS 트래픽이 들어오면, 상위인 100번 규칙이 먼저 검토되며 들어오는 트래픽과 매칭되므로, 100번 규칙이 적용(Allow)되고 하위 규칙은 무시되어 종료된다.

3.2. 상태 저장(Stateful) vs 상태 비저장(Stateless)

트래픽이 나갔다가 ‘응답(Response)’을 받아 돌아올 때, 어떻게 처리되는지를 결정하는 핵심 개념이다.

• Security Group (상태 저장 - Stateful)
  • 인스턴스가 밖으로 요청을 보낼 때, 해당 아웃바운드 트래픽이 허용되어 있다면, 그에 대한 응답 트래픽(인바운드)은 규칙이 등록되어 있지 않아도 자동으로 허용된다.
• NACL (상태 비저장 - Stateless)
  • 트래픽의 상태를 저장하지 않는다.
  • 밖으로 나가는 규칙(Outbound Allow)만 있고 들어오는 규칙(Inbound Allow)이 없다면, 나갔던 트래픽이 응답을 받아 돌아올 때 차단(Drop)된다.
  • NACL에서 정상적인 통신을 하려면, 인바운드와 아웃바운드 규칙 모두 둘 다 명시적으로 구성해야 한다.

AWS vs OCI 가상 방화벽 허용 로직

• AWS (교집합, AND) : 서브넷(NACL)과 인스턴스(Security Group)의 방화벽을 둘 다 모두 허용해야만 트래픽이 통과된다.
• OCI (합집합, OR) : 서브넷(Security List)과 인스턴스(NSG) 중 하나라도 허용하면 트래픽이 통과된다.

3.3. 일반적인 공격: 공개된 데이터베이스 탈취 방어

3.3.1. 문제 상황

• 하나의 Public Subnet 안에 웹 서버 인스턴스와 MongoDB 데이터베이스 인스턴스가 함께 있다.
• 실수로 데이터베이스 인스턴스에 Public IP 주소가 할당되어, Public Internet을 통해 접근할 수 있는 상태이다.
• 해커의 공격 : 누군가 Public IP 대역에 포트 스캔을 수행해 이 데이터베이스를 찾아낸다면, 공격 대상이 될 수 있다.

3.3.2. 취약한 기본 구성 (모두 허용)

서브넷의 NACL이 모든 포트 트래픽을 허용(ALL, 0.0.0.0/0)한다면, 이러한 공격을 막을 수 없다.

3.3.3. 해결 방법: 필요한 포트만 허용

이에 대한 해결책으로, ‘필요한 트래픽’만 허용하도록 NACL을 제어할 수 있다.

• 웹 트래픽 허용 : 웹 서버가 외부와 통신해야 하므로, 인터넷(0.0.0.0/0)과 주고받는 HTTPS(443 포트) 트래픽은 허용한다.

• DB 트래픽 내부 제한 : MongoDB가 사용하는 27017 포트의 통신은 허용하되, 그 범위를 인터넷(0.0.0.0/0)이 아닌 Subnet 내부의 IP 대역(10.0.0.0/24)으로 제한한다.

  방향	규칙 #	프로토콜	포트	출발지/목적지	허용/거부
  Outbound	100	TCP	443	0.0.0.0/0 (인터넷)	Allow
  Outbound	200	TCP	27017	10.0.0.0/24 (내부망)	Allow
  Outbound	*	ALL	ALL	0.0.0.0/0	Deny
  Inbound	300	TCP	443	0.0.0.0/0 (인터넷)	Allow
  Inbound	400	TCP	27017	10.0.0.0/24 (내부망)	Allow
  Inbound	*	ALL	ALL	0.0.0.0/0	Deny

3.3.4. 포괄적인 거부 규칙

• 마지막 (*) 규칙은 명시적으로 허용(100,200,300,400)하지 않은 다른 모든 트래픽을 자동으로 거부하는 역할을 한다.
• 해당 규칙은 AWS에서 자동으로 추가된다.

3.4. 일반적인 공격: 서비스 거부 공격(Dos) 방어

3.4.1. 단순한 서비스 거부(Dos) 공격 차단

• 공격 상황 : 적은 수의 공격자(몇 개의 특정 IP 주소)가 서버에 과부하를 일으키기 위해 엄청나게 많은 가짜 요청을 보내고 있는 상황이다.
• 해결 방법 : NACL은 순서대로 규칙을 평가하는 특징이 있다. 기존에 있던 ‘모든 트래픽 허용’ 규칙보다 더 낮은 번호(우선순위 높음)로, 공격자의 IP를 차단하는 인바운드 규칙을 추가해 차단할 수 있다.
• 결과 : 해당 공격자 IP에서 오는 트래픽은 서브넷 수준(NACL)에서 즉시 차단(Deny)되어 서버에 도달하지 못한다.

3.4.2. 분산 서비스 거부(DDos) 공격의 한계

• 한계 상황 : 수백, 수만 대의 좀비 PC를 동원해 악의적인 요청을 보내는 경우 다른 방법으로의 차단이 필요하다.
• 이유 : 수많은 IP에서 공격이 들어오기 때문에 어떤 IP를 차단해야 할지 특정하기 어렵고, 그렇다고 모든 IP를 다 막아버리면 정상적인 사용자도 서비스를 이용할 수 없게 된다.
• 해결책 : 이런 정교한 대규모 DDoS 공격은 단순한 NACL이나 Security Group만으로 막기는 어렵다. AWS Shield와 같은 정교한 방화벽 도구를 사용해야 한다.