VPC에 대해 조금 더 자세히 알아보자 (4) - NACL

 

지금까지 잘 안 다뤘던 서브넷 보안 단계가 있는데 바로 네트워크 ACL, 즉 NACL이다.

#0 먼저 NACL 및 Security Group 흐름에 관하여

1. 예시를 통해 들어오는 요청의 NACL 역할을 알아보자.

요청이 EC2 인스턴스 내부로 이동하는 것이다.

...

네트워크 관점에서는 어떨까?

우선 요청이 서브넷에 들어가기 전 먼저 NACL로 이동한다. NACL에는 몇 가지 인바운드 규칙이 정의괴고 요청이 허용되지 않으면 내부로 들어갈 수 없다. (물론 허용되면 들어가진다) 그래서 NACL은 무상태이다.

첫 번째 요청이 NACL을 통과해서 서브넷 내부에 도달한다.

그리고 Security Group(보안 그룹) 인바운드 규칙을 만난다. 

=> 만약 그 요청이 명시적으로 허용 받지 못하면 거부될 것이다.

 

그리고 NACL은 무상태이고 Security Group은 상태 유지이다.

=> 이 말은 만약 요청이 Security Group의 인바운드 규칙을 통괗서 EC2 인스턴스에 도달하면 EC2 인스턴스는 그 응답으로 애플리케이션 관점에서 응답할 내용을 모두 회신한다.

 

아웃바운드 규칙은 자동으로 Security Group 수준에서 허용되는데 Security Group의 특징이 상태 유지이기 때문이다.

=> 다시 말해 들어간 것은 전부 나올 수 있다는 말이다. 그래서 여기에는 평가되는 규칙이 없다.

 

여기서 Security Group수준에서 아웃바운드 규칙이 항상 허용되는 이유가 상태 유지인데 무엇이냐면 NACL은 상태 없음(무상태)이다. NACL 아웃바운드의 규칙이 평가되고 규칙이 통과하지 못하면 요청도 통과하지 못할 것이다.

 

2. 이번에는 Security Group에서 EC2 인스턴스가 아웃바운드 요청을 한다. (외부로 바인딩된요청을 하는 것, EC2 인스턴스는 먼저 www.google.com  등에 접속할 수 있는 거)

그리고 처음으로 평가될 규칙은 Security Group 아웃바운드 규칙이다. 트래픽이 EC2 인스턴스에서 웹으로 나가도록 허용할지 결정한다. 규칙이 적절하고 요청이 허가되면 요청 또한 NACL 아웃바운드 규칙이 평가될 수 있다. 마지막으로 Security Group수준에서 서브넷의 인바운드 규칙은 무조건 허용된다.

=> Security Group 규칙의 상태 유지 특징 때문이다!

 

#1 NACL (Network Access Control List)란?

NACL은 서브넷을 오가는 트래픽을 제어하는 방화벽과 비슷하다.

서브넷마다 하나의 NACL이 있고 새로운 서브넷에는 기본 NACL이 할당된다.

NACL 규칙 정의에서 규칙에는 숫자가 있고 범위는 1~32766까지이다.

(숫자가 낮을수록 우선순위가 높아서 우선순위가 제일 높은 것은 1, 가장 낮은 것은 32766이다.)

그리고 첫 번째 규칙 비교로 결정이 날 것이다.

예를 들어 CIDR에서 ALLOW를 정의하고 같은 CIDR인 특정 IP를 DENY로 정의하면 ALLOW는 100이고 DENY가 200이니까 IP주소는 허용되는 것이다. (100이 200보다 우선해서!)

 

마지막 규칙은 별표(*)인데 일치하는 규칙이 없으면 모든 요청을 거부한다.

AWS는 규칙을 100씩 추가하는 것을 권장한다. 그 사이에 규칙을 추가하기 좋기 때문이다. 

새로 만들어진 NACL은 기본적으로 모두를 거부한다.

=> 그래서 NACL의 좋은 사용 사례를 들면 서브넷 수준에서 특정한 IP 주소를 차단하는데 적합하다!😀👍

 

<아키텍처에서 NACL 찾기>

NACL은 서브넷 수준에 있으니 public 서브넷 및 private 서브넷 등에 위치하고 있다.

 

#2 Default NACL (기본 NACL 알아보기)

기본 NACL은 연결된 서브넷을 가지고 인바운드와 아웃바운드의 모든 요청을 허용하는 특수성을 가진다. 이게 IPv4를 지원하는 기본 NACL의 모습인데 모든 것이 나가고 들어올 수 있다..!

=> NACL이 모든 것을 드나들도록 허용하지 않으면 AWS를 시작할 때 디버깅을 심각하게 해야한다..

그리고 기본 NACL이라 엄청 개방적인 구조로 설계되어있어서 기본 NACL은 수정하지 않는 것을 추천한다!

 

#3 임시 포트(Ephemeral Ports)에 관해

중요한 부분인 임시 포트에 대해 알아보자!

 

클라이언트와 서버가 연결되면 포트를 사용해야 한다. 즉, IP주소와 포트가 있다. 클라이언트는 규정된 포트의 서버에 연결한다. 예를 들어 HTTP 포트는 80, HTTPS 포트는 443, SSH 포트는 22 등등..이다.

서버가 서비스를 올릴 때 클라이언트는 규정된 포트에 접속한다.

(다만 클라이언트가 서버에서 회신 받을 때는 제외)

서버도 응답을 하려면 클라이언트에 연결해야 한다. 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 된다. 이 포트는 임시라서 클라이언트와 서버 간 연결이 유지되는 동안만 열려 있다.

...

그러면 임시 포트가 무엇일까?

우리의 OS마다 포트 범위는 달라지니 (Window 10의 경우, 49152~65535까지가 무작위 임시 포트로 선택된 포트 범위) 알아두길!

그림으로 구체적인 예시를 들어보겠다.

 클라이언트가 웹 서버에 연결되며 웹 서버에는 고정 IP 및 고정 포트가 있다. 클라이언트에 이렇게 IP가 있고 한 번의 요청 또는 연결에만 임시 포트 50105를 개방하려고 한다. 클라이언트에서는 서버로 전송된 요청에는 목적지 IP 정보와 서버가 연결할 목적지 포트, 그리고 요청과 관련된 페이로드가 있다. 그런데 여기 1번 소스IP는 응답을 위한 것이고 2번은 응답을 위한 임시 포트이다.

그리고 웹 서버가 다시 회신을 위해서 클라이언트와 연결될 때 아래와 같은 응답을 보낸다.

(서버 포트 정보가 있고 목적지IP는 11.22.33.44)

 

마지막으로 포트가 필요하면 클라이언트가 전송했던 임시 포트를 재사용한다.

=> 임시 포트라고 불리는 것은 연결 수명을 위해서만 할당되는 무작위 포트이기 때문

 

#4 NACL에서 중요한 부분인 임시 포트에 관해

설명을 위한 그림

클라이언트가 데이터베이스에 연결된다고 생각해보자.

각 서브넷에 연결된 NACL이 하나 있다. 바로 웹 NACL과 DB NACL이다.

...

클라이언트가 데이터베이스 인스턴스에 연결을 시작하면 허용되어야 하는 규칙은 무엇일까?

첫 번째 NACL은 포트 3306을 통해 TCP부터 데이터베이스의 서브넷 CIDR까지 아웃바운드를 허용해야 한다. 그렇지 않으면 요청이 서브넷을 떠나지 않을 것이기 때문에 주의해야 한다! 데이터베이스 측에서는 EB NACL가 웹 서브넷 CIDR에서 포트 3306으로 TCP를 인바운드할 것이다.

데이터베이스가 클라이언트로 요청에 회신을 할 때 무슨 일이 생길까?

=> 클라이언트에게는 임시 포트가 있어서 이 요청에 대해 무작위 포트가 할당된다. 그러면 DB NACL은 포트 및 임시 포트에서 아웃바운드 TCP를 허용하는데 범위는 1024~65535이다.

웹 서브넷 CIDR로 아웃바운드되면 웹 NACL은 DB 서브넷 CIDR의 임시 포트 범위에서 인바운드 TCP를 허용해야 하낟. 그래서 임시 포트를 제대로 구성하는 것이 매우 중요하다.

NACL의 또 다른 특징은 다중 NACL 및 서브넷이 있다면 각 NACL 조합이 NACL 내에서 허용되어야 한다는 것이다. CIDR 사용 시, 서브넷이 고유의 CIDR을 갖기 때문이다. 그리고NACL에 서브넷을 추가하면 NACL 규칙도 업데이트해서 연결 조합이 가능한지 확인해야만 한다. 

 

#5 NACL과 Security Group의 차이점

<Security Group>

- 인스턴스 수준에서 작동

- 허용 규칙 지원

- 상태 유지이며 규칙과 무관하게 트래픽을 허용

- 모든 규칙이 평가되고 평가된 바탕으로 트래픽 허용 여부를 결정

- 누군가 지정할 때 EC2 인스턴스에 적용

 

<NACL>

- 서브넷 수준에서 작동

- 허용/거부 규칙 모두 지원

- 특정 IP 주소를 거부할 수 있다.

- 무상태이기 때문에 인바운드와 아웃바운드 규칙이 매번 평가

- 가장 높은 우선순위를 가진 것이 먼저 평가

- 연결된 서브넷의 모든 EC2 인스턴스에 적용