[AWS] NACL vs Security Group (Stateless와 Stateful 차이)

 

# 요약만 확인하기

 

NACL과 Security Group에 대한 전반적인 개념은 아래 글을 참조하자

• https://cleverdj.tistory.com/122

 

위의 글에서 볼 수 있듯이, NACL은 "서브넷 단위"이고, Security Group은 "서버 단위" 이다

따라서 외부 통신의 경우 NACL과 Security Group을 모두 거쳐야 하고, 내부 통신의 경우 Security Group만 거친다

 

또한 각 규칙에 대해서 Allow 또는 Deny를 지정할 수 있으며 규칙별 중요도(규칙을 적용할 순서)가 있는 NACL과는 다르게, Security Group에선 기본적으로 모두 Deny이며 Allow 하는 규칙만을 만들어낼 수 있으며 순서따윈 없이 한꺼번에 모두 적용시킨다

 

더 보다보면 Stateless/Stateful 방식이라는 용어가 나오는데, 뜻은 아래와 같다

• Stateless : 요청 정보를 따로 저장하지 않아 응답하는 트래픽도 제어를 해줘야 한다 (NACL)
• Stateful : 요청 정보를 저장하여 응답하는 트래픽 제어를 하지 않는다 (Security Group)

 

처음에 딱 보자마자는 이해가 잘 안됐다

왜냐하면 Stateful인 Security Group도 아웃바운드 트래픽을 제어할 수 있도록 되어있는데...무슨 소리인가 싶었다

 

그러고 얻어낸 결론은 아래와 같다

• NACL의 인/아웃바운드 : 다른 서브넷(or 외부)에서의 요청/응답
• Security Group의 인/아웃바운드 : 같은 서브넷 및 다른 서브넷(or 외부)에서의 수신/발신

출처 : Cloud 환경에서의 방화벽 Network ACL 와 Security Group 에 대하여

 

즉, TCP나 ICMP 수신 트래픽들에 대한 "응답"을 Security Group에선 제어를 할 필요가 없다는 뜻이다

 

 

예로 Ping(ICMP 통신)의 경우를 생각해보자

특정 서버로의 통신을 확인을 위한 Ping Test는, 해당 서버로 요청을 보낸 후 그 서버에서의 응답까지 받아내야 한다

 

1) 같은 서브넷 내의 Ping 통신인 경우 (Security Group만 고려)

이렇게 Ping 통신을 하기 위해선 sg1 -> sg2 로의 ping 요청과 sg2 -> sg1 으로의 ping 응답 트래픽이 필요하다

그러나 Security Group은 요청 받은 세션에 대한 정보를 저장하기 때문에(Stateful), 해당 요청에 대한 응답을 위한 아웃바운드 규칙을 만들 필요가 없는 것이다

즉 sg1의 발신과 sg2의 수신에 대한 규칙만 필요하며, 해당 통신에 필요한 규칙은 아래와 같다

• sg1의 아웃바운드 규칙 - sg2로의 ICMP
• sg2의 인바운드 규칙 - sg1에서의 ICMP

sg1의 인바운드/아웃바운드

sg2의 인바운드/아웃바운드

이 상태에서 sg1 -> sg2 핑을 날려보면?

 

 

아주 잘 되는걸 확인할 수 있다

 

2) 다른 서브넷 간의 Ping 통신인 경우 (NACL까지 고려)

이번 경우에서의 Ping 통신은 Security Group 뿐 아니라 NACL까지 필요하다

(Security Group 설정은 위에서 세팅한 그대로 간다)

 

sg1에서의 아웃바운드와 sg2에서의 인바운드만 설정해주면 되던 Security Group과는 다르게, NACL은 각각의 서브넷에서 인바운드/아웃바운드를 같이 설정해줘야 한다

 

NACL을 생성해보면 기본적으로 인바운드/아웃바운드가 모두 Deny되어있다

sg1 서버에 접속하기 위한 SSH 규칙부터 만들어주었으나,,,

인바운드를 열어줬는데 접속이 안된다,,,,

아웃바운드도 열어줘야 한다는 것을 그새 까먹고 있었다

그러나 아웃바운드도 똑같이 22 port로만 열어준다면 아마 똑같이 접속이 안될 것이다

이는 OS가 응답을 할 때 랜덤한 포트로 내보내기 때문이다

해당 랜덤 포트의 범위는 cat /proc/sys/net/ipv4/ip_local_port_range 명령으로 확인할 수 있다

 

 

Amazon Linux 2 에서의 TCP 포트 범위는 32768~60999인걸 확인할 수 있다

(아마 웬만하면 이 범위일 것 같다...서버에 접속이 안되어 확인을 못한다면 그냥 모든 TCP로 규칙을 설정해주자)

 

아무튼 이렇게 아웃바운드까지 설정하고 나니 sg1 서버에 잘 접속된다

 

이제 (원래 목적이었던)Ping을 위한 ICMP 설정을 해주자

 

NACL1에선 sg2 서버로의 ICMP 아웃바운드가 필요하다

따라서 sg2 서버에서의 응답으로 받을 ICMP 인바운드 규칙 또한 필요하다

(TCP와 다르게 ICMP는 포트 번호가 따로 없기 때문에, 그냥 ICMP All로 인바운드/아웃바운드 다 열면 된다)

 

NACL2에선 sg1 서버에서의 ICMP 인바운드가 필요한데, 마찬가지로 ICMP All로 인바운드/아웃바운드를 다 열어주면 된다

 

NACL2의 인바운드/아웃바운드

 

NACL1도 마찬가지로 ICMP All로 sg2에 대한 허용 규칙을 만들어 두었다

 

참고로 규칙 번호는 낮을수록 더 높은 우선순위를 가지며, 운영 도중 규칙을 삽입해야 하는 경우가 생길 수도 있으므로 처음엔 10, 100 단위로 만드는 것이 국물이다

 

 

암튼 이렇게 NACL들을 모두 수정하고 나니 ping 통신도 잘 되었다

 

 

끝

 

NACL vs Security Group 비교 요약

	NACL	Security Group
적용 단위	서브넷 단위	인스턴스 단위
상태 저장 여부	Stateless	Stateful
Order	순서 있음	순서 없음
규칙당 가능한 Action	Allow, Deny	Allow만 가능

 

 

진짜 끝