공격 지점을 줄여서 DDoS 공격 대비하기

DDoS(Distributed denial of service) 공격은 악의의 공격자가 감당할 수 없는 규모의 트래픽이나 커넥션 요청을 네트웍, 시스템, 어플리케이션에 전송함으로서 야기됩니다. 예상하신 대로 AWS 고객도 어떻게 하면 이런 종류의 공격으로 부터, 어플리케이션을 보호할 수 있는지 많이 질문합니다. AWS에서는 여러분이 DDoS 상황에서도 복원력이 높은  아키텍쳐를 만드는 방법과 어떻게 AWS 확장성을 잘 활용할 수 있는지에 관한 베스트 프랙티스를 제공하고 있습니다.

먼저 최근에 공개한 AWS Best Practices for DDoS Resiliency(영문 백서)를 보시면 어플리케이션 가용성을 보호하고, DDoS 공격에 좀 더 잘 대비하기 위한 참고 아키텍쳐를 잘 알 수 있습니다. 이 글에서는 그 중에서도 공격을 방어하기 입장에서 공격받을 지점을 줄이는 사례를 좀 더 자세히 공유해 드리겠습니다.

간단히 설명하자면, 어플리케이션에 도달할 수 있는 가능한 트래픽의 유형을 줄이는 것을 뜻합니다. 간단한 예로 웹어플리케이션을 만들때, 인터넷으로 80과 443 포트만을 오픈하는 것입니다. 이를 통해서 DDoS 공격에 흔히 사용되는 다양한 공격 기법들을 막을 수 있습니다.

이 글에서는 Amazon Virtual Private Cloud (VPC) 를 활용하여 여러분들의 어플리케이션에 대한 접근을 어떻게 통제할 수 있는지, 네트웍 접근제어목록(network access control lists (ACLs))과 보안그룹(security groups)을 통해 공개된 통로를 어떻게 최소화 할 수 있는지 등에 관한 내용을 다룹니다. 이 내용들은 여러분들이 DDoS 복원 아키텍쳐(DDoS-resilient architecture)를 구축 할 때 고려하셔야 하는 몇 가지 베스트 프랙티스 중에 일부입니다.

통상적인 DDoS 공격

AWS VPC에 관한 내용을 시작하기 앞서, DDoS 공격 기법에 어떤 것들이 있는지 이해하고 전송되는 위해 트래픽을 막도록 어떻게 공격 지점을 최소화 할 수 있는지를 이해하는 것이 중요합니다. 가장 흔한 DDoS 공격기법은 반사공격(reflection attack)으로서, 네트웍이 감당할 수 없는 트래픽의 양을 생성하여 정상적인 트래픽을 처리하지 못하도록 하는 것입니다. 반사공격(reflection attack)을 시작하려면, SSDP(Simple Service Discovery Protocol)나 DNS(Domain Name System), NTP(Network Time Protocol), SNMP(Simple Network Management Protocol)과 같은 UDP(User Datagram Protocol)서비스를 제공하는 인터넷 서버들을 스캐닝하게 됩니다.

그리고 대부분 이와 같은 서버들은 구성에 따라, 원 요청보다 큰 결과를 반환하게 됩니다. 이러한 부분을 이용하는 것을 증폭 공격(Amplification Attack)이라고 하며, 이 두 가지 기법을 이용하여 공격자가 소스 IP를 공격 대상 IP로 임의로 변경하여 많은 요청들을 해당 서버들에게 보내게 되면, 10배 혹은 수백배 큰 응답들이 공격 대상에게 전달되어 정상적인 서비스를 방해하도록 하는 것입니다.

아래 그림1은 공격자가 어떻게 요청을 변조하여 DDoS반사/증폭(Reflection/Amplification)공격을 희생자에게 전송시키는지를 보여줍니다.

그림 1. Distributed reflection denial of service attack

보안 그룹 구성

반사공격(Reflection attack) 기법을 통해 공격자들은 전세계 어느 곳으로도 통상적인 UDP서비스를 이용하여 대규모 트래픽을 보낼 수 있게 됩니다. 다행히 이러한 공격들은 쉽게 탐지될 수 있고, AWS의 VPC에 있는 보안그룹(Security Group) 구성을 통해 감소시킬 수 있습니다. 이 기능은 여러분들의 인스턴스에 대한 인바운드, 아웃바운드 통신에서 허용할 포트나 프로토콜을 지정해서 통제할 수 있도록 해줍니다. 지정되지 않는 다른 포트나 프로토콜은 자동으로 접근이 불허됩니다.

아래 그림에선 앞에서 언급했던 웹 어플리케이션에 적용할 수 있는 Amazon VPC레퍼런스 아키텍쳐를 보실 수 있습니다. 좀 더 자세한 내용은 여기를 참조하시기 바랍니다. Security Groups for Your VPC.

그림 2. Reference architecture with Amazon VPC configuration

위의 아키텍쳐에서는 한 개의 퍼블릭 서브넷과 두 개의 프라이빗 서브넷으로 구성된 VPC를 사용합니다. 위 구성을 위해 몇 가지 보안 그룹(Security Group)을 정의해야 하는데, 우선 일반 사용자와 관리자가 인터넷을 통해 접근할 수 있도록 허용하는 것과 내부 리소스들을 DMZ로 부터만 접근이 가능하도록 제한하는 방법이 있습니다. VPC를 만들고 접근을 제한하는 것과 관련된 자세한 내용은 링크를 참조하시기 바랍니다. Your VPC and Subnets.

SSH bastion security group

SSH bastion 서버는 오로지 관리자만이 SSH를 사용하여 접근할 수 있도록 제한하기 위해 하나의 EC2인스턴스에 구성됩니다. 이를 통해 관리자는 TCP 22번 포트를 통해 인터넷이나 허용된 IP로부터 접근할 수 있게 됩니다. SSH bastion으로 접근한 뒤, 관리자는 웹어플리케이션 서버나 MySQL서버로 접근할 수 있습니다. 22번 포트에 대한 DDoS 공격을 받게 되면 SSH 서비스에 대한 부분만 지장을 받게 됩니다. 이로 인해, 공격자가 이 포트를 통해서 어플리케이션에 영향을 주려는 시도가 차단됩니다. 불법적인 접근을 최소화 하기 위해서는, SSH bastion의 보안그룹에 여러분 네트웍의 공용IP만 허용해주는 게 필요합니다. 다음 테이블은 SSH Bastion의 보안그룹을 설정할 때 참조할 수 있는 사례입니다.

ELB 보안 그룹

Elastic Load Balancing (ELB)는 EC2 인스턴스 장애에 대비하여 자동으로 인바운드 트래픽을 라우팅해 줍니다. ELB는 웹 어플리케이션 앞단에서 위치하여 공격받을 수 있는 부분을 줄여주게 되고, 자동으로 용량에 따라 스케일링 해 줍니다. 게다가, ELB는 웹어플리케이션으로 잘 정의된(유효한) 트래픽만 전달하도록 만들어져 있습니다. 이 기능을 통해 DDoS에 저항력 있는 레이어를 부가적으로 구성할 수 있습니다. 사용자가 여러분의 웹어플리케이션으로 접근할 수 있도록 하기 위해선, 우선 인터넷으로부터 80과 443포트를 통해서 만 접근 가능 하도록 하고, 그 다음 각 요청이 웹어플리케이션들이 운영되는 EC2인스턴스로 잘 분배될 수 있도록 보안그룹 설정을 합니다. 다음 테이블은 ELB 보안 그룹을 설정하는데 참조할 만한 규칙을 보여줍니다.

NAT 보안 그룹

본 사례에서, 웹어플리케이션 서버와 MySQL서버는 프라이빗 서브넷에 위치하는데, 이로 인해, 직접적으로 인터넷과 통신할 수 없습니다. ELB를 통해서 서비스하는 부분과는 별개로, 소프트웨어 업데이트 등을 위해 인스턴스가 인터넷과 연결되어야 할 필요가 있습니다. 이를 위해, 고유의 보안그룹을 갖는 network address translation (NAT) 인스턴스를 구성하게 됩니다. NAT 인스턴스를 통해, 프라이빗 서브넷에서 인터넷으로 나가는 아웃바운드 통신을 라우팅할 수 있게 됩니다.자세한 내용은 NAT Instances. 를 참조하시기 바랍니다.

웹 어플리케이션 보안그룹

이 보안 그룹은 모든 웹어플리케이션이 올라가 있는 EC2인스턴스들의 설정에 대한 내용입니다. 이들 인스턴스들은 ELB로부터 오는 웹 요청들만 받아 들이게 됩니다. 공격 지점의 최소화를 위해, 이들 인스턴스에는 VPC 써브넷 IP 범위에서 할당되는 사설 IP만이 부여되어 인터넷으로부터의 직접적인 접근을 막아 주게 됩니다. 그 대신, ELB로부터의 TCP 포트 80, 443과 관리자의 접근을 위한SSH 22번 포트 접근만이 허용됩니다. 다음 테이블은 웹어플리케이션을 위해 보안 그룹을 설정할 때 참조하면 좋습니다.

MySQL 데이터베이스 서버보안 그룹

지금까지와 유사하게 생각해서, MySQL 데이터베이스 쪽은 오로지 웹어플리케이션이 올라가 있는 EC2인스턴스로부터의 접근만을 허용해 주게 됩니다. 이를 위해, MySQL 데이터베이스를 사설 서브넷 상에 두고 사설 IP를 할당하고, 웹 어플리케이션이 올라가 있는 EC2인스턴스로부터의 TCP포트 3306 트래픽만을 받아 들이도록 설정하게 됩니다. 아래 테이블은 MySQL서버를 위한 보안그룹 설정을 보여줍니다.

네트웍 ACL 구성하기

네트웍ACL을 통해, 상용 방화벽과 유사하게, 우선순위가 할당된 Allow, Deny 규칙을 생성하여 VPC를 보호하게 됩니다. 이것은 EC2 인스턴스 수준에서 트래픽을 허용할 지를 결정하는 보안그룹과는 다르게, 서브넷 레벨에서 Allow, Deny 규칙을 설정할 수 있도록 해줍니다.예를 들어, 원하지 않거나 악용될 수 있는 인터넷 IP 주소 혹은 범위를 규정하려면, 어플리케이션으로 들어오는 트래픽 중 해당 IP 범위를 Deny 하도록 구성하게 됩니다. 단일 IP 주소 혹은 전체 IP 서브넷을 타겟으로 할지는 필요에 따라 정하면 됩니다. 다음 테이블은 지금까지 기술한 부분에서 보안 그룹에 적용했던 규칙들에 상응하는 사용자 정의 네트웍 ACL 입니다. 보다 자세한 내용이 필요하면 Network ACLs. 을 참조하시기 바랍니다. (또한 1024에서 65535까지 중 임시 포트 범위를 선택하기 위한 정보가 필요하시면, Ephemeral Ports를 참조하시기 바랍니다.)

기타 고려사항

아마존 VPC상에서 보안 그룹과 네트웍 ACL을 구성하는 것은 여러분의 어플리케이션이 공격 받을 수 있는 지점을 줄여줄 수 있는 효과적인 방법입니다. 각각의 규칙들이 비슷해 보일 지라도 공격 지점을 줄여주는 데 중요한 몫을 하게 됩니다. 보안 그룹은 어플리케이션 상의 리소스에 접근할 수 있는 트래픽을 설정할 수 있게 해주며, 네트웍 ACL은 서브넷 레벨에서 명시적으로 Deny 해야 하는 포트, 프로토콜, 트래픽 소스들을 설정할 수 있게 해준다는 면에서 DDoS 방어에서 중요한 의미를 가집니다. 지금 여러분들은 두 가지 중요 기능, VPC와 보안 그룹을 설정하는 방법에 대해 안내를 받았으며, 이 외에도, DDoS에 대해 복원력이 높은 아키텍쳐를 구성할 수 있는 다음과 같은 서비스들(Amazon CloudWatch를 통한 모니터링, Amazon CloudFront, Amazon Route 53, Elastic Load Balancing, 과 Auto Scaling을 통한 스케일링) 을 고려해야만 합니다.

이 글은 AWS 보안 블로그 How to Help Prepare for DDoS Attacks by Reducing Your Attack Surface의 한국어 번역으로서 AWS 코리아 보안 담당 솔루션 아키텍트인 임기성님이 번역해 주셨습니다.