AWS 네트워크 ACL
일반적으로 EC2를 포함한 AWS 리소스에 대한 외부에서의 접근 제어를 위해서는
보안그룹을 사용하여 허용된 아이피에서만 접근이 가능하도록 설정하는데요. 외부에서의 트래픽을 제어하기 위해 제공되는 보안 계층인 네트워크 ACL에 대해 학습한 내용 공유하려고 합니다.
네트워크 ACL이란
AWS 공식 문서에서는 네트워크 ACL을 "네트워크 ACL(액세스 제어 목록)은 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 선택적 보안 계층" 이라고 정의하고 있습니다.
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-network-acls.html
네트워크 ACL은 아래와 같이 인바운드 규칙과 아웃바운드 규칙을 통해 서브넷으로 유입되는 트래픽과 서브넷 밖으로 나가는 트래픽을 제어하며, 포트 단위까지 제어가 가능하다는 점에서 스위치 장비에서의 확장 ACL(Extended ACL)과 유사합니다.
하지만 인바운드 규칙의 목적지와 아웃바운드 규칙의 출발지가 네트워크 ACL에 연결된 서브넷으로 고정된다는 특징이 있습니다.
네트워크 ACL과 보안그룹의 차이점 비교
어떻게 보면 네트워크 ACL과 동일하게 서버로 유입되는 트래픽 제어라는 목적을 위해 사용되는 보안그룹과의 차이가 네트워크 ACL을 이해하는데 가장 핵심이 될 것 같습니다. 네트워크 ACL은 보안그룹과 비교하여 아래와 같은 특징을 가집니다.
각각의 특징이 의미하는 바에 대해서는 직접 테스트를 통해 보여드리도록 하겠습니다.
네트워크 ACL을 직접 구성하여 보안그룹과의 차이점 확인
아래와 같이 2개의 서브넷에 3개의 EC2 인스턴스를 생성하였습니다.
보안그룹의 경우 동일 보안그룹(premisan-test-sg)에 포함된 인스턴스 간에는 모든 트래픽을 허용하였습니다.(211.46.21.48/32는 제 PC의 아이피입니다.)
네트워크 ACL의 경우 기본적으로 VPC의 기본 네트워크 ACL로 설정되어 있으며, 기본값으로 모든 트래픽을 허용하도록 설정되어 있습니다. 새로운 네트워크 ACL을 생성한 후 테스트에 사용한 VPC를 지정해줍니다.
서브넷 연결 편집에서 EC2 인스턴스를 생성한 public1 서브넷과 public2 서브넷을 포함시킵니다.
네트워크 ACL의 규칙은 번호가 낮은 순서대로 먼저 적용을 받고, 구성된 규칙에 포함되지 않은 트래픽은 * 로 정의된 모든 트래픽을 거부하는 규칙의 적용을 받게 됩니다.
현재 100번 규칙에 의해 모든 트래픽이 허용되고 있기 때문에 * 로 정의된 모든 트래픽을 거부하는 규칙은 사실상 적용되지 않는 것이나 다름 없습니다. 허용만 설정할 수 있는 보안그룹과 달리 네트워크 ACL은 거부에 대한 규칙도 설정할 수 있는 것이 네트워크 ACL의 첫번째 특징입니다.
때문에 현재는 test3 서버에서 test2 서버로 ping 테스트 시 응답이 있는 것을 확인할 수 있습니다.
이제 test3 서버의 아이피인 10.0.20.166/32를 차단하는 ACL 규칙을 만들어봅니다. 100번 규칙에 의해 모든 트래픽이 허용되어 있지만 99번 규칙의 우선순위가 더 높기 때문에 test3 서버에서 test2 서버로 핑 테스트 시 응답이 오지 않는 것을 확인할 수 있습니다.
이번에는 반대로 test3 서버의 트래픽을 거부하는 규칙의 번호를 101로 변경하고 동일하게 핑 테스트를 진행했습니다.
전의 테스트와 달리 101번으로 설정한 test3 서버에 대한 거부 규칙보다 100번의 모든 트래픽 허용 규칙의 우선순위가 높기 때문에 핑 테스트 시 정상적으로 응답이 오는 것을 확인할 수 있습니다. 이 때, 101번 규칙은 없는 것이나 다름 없습니다. 허용만 설정이 가능하여 규칙간 순서의 관계가 없는 보안그룹과 달리, 우선순위에 따라 적용되어 먼저 적용되는 규칙에 의해 차순위 규칙은 무효화될 수 있는 점이 네트워크 ACL의 두번째 특징이 되겠습니다. 이번에는 모든 아이피로부터의 ICMP 트래픽을 차단하는 룰셋을 99번 규칙으로 생성해봅니다.
당연히 test3 서버에서 test2 서버로 핑 테스트 시 응답이 없는 것을 확인할 수 있습니다.
하지만 test2 서버와 동일 서브넷에 있는 test1 서버에서 test2 서버로 핑 테스트 시에는 응답이 있는 것을 확인할 수 있습니다.
그 이유는 인스턴스 단위로 적용을 받는 보안그룹과 달리 네트워크 ACL은 서브넷 단위로 적용을 받기 때문에 동일 서브넷에 있는 인스턴스간에는 네트워크 ACL의 영향을 받지 않기 때문입니다. 네트워크 ACL이 적용되는 방식을 도식화한 그림입니다. 동일 서브넷이 아닌 다른 서브넷(혹은 외부망)과 통신할 때에 네트워크 ACL의 적용을 받는 것을 나타냅니다.
또한 네트워크 ACL은 서브넷 단위로 적용받기 때문에 서브넷에 생성된 모든 리소스에 영향을 주며, 추가적으로 해당 서브넷에 생성되는 리소스에도 영향을 줍니다. 마지막으로 보안그룹과 비교되는 네트워크 ACL의 가장 중요한 특징이 남았는데요. 그것은 상태를 저장하지 않는다는 것입니다. 보안 그룹의 경우 인바운드 트래픽이 허용되어 있다면, 허용된 인바운드 트래픽으로 발생한 응답에 대한 아웃바운드는 자동적으로 허용됩니다. 마치 아래 그림처럼 서버의 아웃바운드 보안그룹을 모두 제거한 상태에서
보안그룹 상의 설정을 통해 test1 서버에서 제 PC의 아이피(211.46.21.48)로 58065, 57334, 57435 포트로 아웃바운드 통신을 허용하지 않았음에도 정상적으로 SSH 통신을 할 수 있는 것은 보안그룹은 OS방화벽과 같이 인바운드를 허용한 요청에 대한 상태를 저장하여 허용한 요청에 대한 응답인 아웃바운드 통신은 자동적으로 허용하는 것입니다.
하지만 이러한 보안그룹의 특성과 달리 네트워크 ACL은 상태를 저장하지 않기 때문에 허용된 인바운드 트래픽에 대한 응답이라 할지라도 명시적으로 아웃바운드에 대해 허용하지 않으면 거부하는 특징을 가집니다. 테스트를 위해 다시 네트워크 ACL을 기본상태로 세팅하고 test1에는 아파치 웹서버를 설치하였습니다.
test3 서버에서 test1 서버로 curl 통신을 시도합니다. 현재는 기본 네트워크 ACL 설정으로 인해 트래픽이 모두 허용되어 있기 때문에 정상적으로 200 응답을 받아오는 것을 확인할 수 있습니다.
이제 네트워크 ACL의 아웃바운드 모두 허용 규칙을 제거하고, test1 서버(10.0.10.191/32)의 80포트로 향하는 아웃바운드 트래픽과 제 PC의 아이피(211.46.21.48/32)를 목적지로 하는 트래픽만 허용해봅니다.
test3 서버에서 test1 서버로 curl 통신 시 연결이 되지 않는 것을 확인할 수 있습니다.
네트워크 ACL의 인바운드 트래픽은 모두 허용되어 있고, test3 서버에서 test1 서버의 80포트로 아웃바운드 트래픽도 허용되어 있는데 왜 test1 서버와 통신이 되지 않는 것일까요?
그 이유는 test3 서버에서 test1 서버로의 아웃바운드는 허용되어 있지만, test1 서버에서 test3 서버로의 아웃바운드는 허용되어 있지 않기 때문입니다.
때문에 test3 서버에서 test1 서버로 http 통신을 하기 위해서는 test1 서버가 test3 서버로 응답을 전송할 아웃바운드 포트도 허용이 필요합니다. 서버-클라이언트 통신 시 클라이언트의 포트는 3만번대 이상에서 임의로 결정되기 때문에 허용할 아웃바운드 포트를 정확히 예측할 수 없습니다. 따라서 test3 서버(10.0.20.166/32)를 목적지로 하는 30000번부터 65535번 포트를 허용하는 ACL을 생성한 뒤, 다시 curl 을 통해 test3 에서 test1 로 http 접속을 시도해봅니다.
test3 서버에서 test1 서버로 http 접속이 정상적으로 완료되어 200 응답을 받은 것을 확인할 수 있습니다.
test1 서버에서 패킷을 캡쳐하여 확인 시 test1 서버(10.0.10.191)의 80포트에서 test3 서버(10.0.20.166)의 52534 포트로 정상적으로 응답을 한 것을 확인할 수 있습니다.
결론
이렇게 테스트를 통해 네트워크 ACL이 어떻게 동작하며, 비슷한 역할을 하는 보안그룹과는 어떠한 차이점이 있는지 알아보았습니다. 네트워크 ACL과 보안그룹 모두 트래픽을 제어한다는 점은 유사하지만 작동 대상과 범위, 그 특징에서 상당부분 차이가 있기 때문에 보안그룹과 네트워크 ACL을 목적에 맞게 함께 설정하여 사용한다면 효과적으로 외부에 대한 트래픽 및 내부 통신간 트래픽을 제어할 수 있는 방법이 될 것 같습니다.