AWS 기술 블로그
Amazon VPC에서 안전한 DNS 요청 설계하기
들어가며
AWS의 Amazon VPC(이하 VPC)에서 DNS 요청은 기본적으로 Amazon Route 53 Resolver(이하 Route 53 Resolver)를 사용합니다. Private DNS 또는 VPC Endpoint 등 AWS의 일부 서비스는 Route 53 Resolver가 반드시 필요합니다. Route 53 Resolver는 VPC CIDR에 +2를 한 주소(예: 10.0.0.0/16 네트워크의 경우 10.0.0.2)에서 실행되며, VPC 내에서 DNS 쿼리를 처리합니다. EC2 인스턴스의 네임서버 설정을 통해 확인할 수 있고, Amazon Linux 2023의 경우 /etc/resolv.conf에 설정되어 있습니다.
[그림1] VPC에서 Route 53 Resolver를 사용하기 위한 설정
Route 53 Resolver는 DNS 요청을 처리할 때 우선적으로 VPC와 연결된 Private DNS(Private Hosted Zone)을 검색하고, 그 다음으로 AWS 내부 도메인에 대한 쿼리를 처리합니다. 마지막으로 Route 53 Resolver 규칙에 따라 도메인을 처리하며, 별도의 규칙이 설정되지 않은 Public Domain은 기본 규칙인 Internet Resolver를 통해 처리됩니다.
[그림2] Route 53 Resolver가 VPC 내부에서 직접 DNS 요청을 처리하는 구조
이 구조 덕분에 VPC 내 서비스는 빠르고 안정적으로 도메인을 해석할 수 있지만, DNS 요청 트래픽은 Egress 체인이 아닌 전용 내부 경로로 처리됩니다. Egress 체인은 VPC에서 외부 인터넷으로 나가는 아웃바운드 트래픽이 통과하는 일련의 네트워크 구성 요소들을 의미합니다. 따라서 Egress 체인에 구성되는 NAT 게이트웨이, 보안 그룹(이하 SG), 네트워크 ACL(이하 NACL), AWS Network Firewall 등의 VPC 네트워크 보안 설계로는 Route 53 Resolver의 DNS 요청을 통제할 수 없습니다.
이로 인해 DNS 터널링이나 DGA(Domain Generation Algorithm) 등의 DNS 기반 공격 기법에 의한 침투 및 데이터 유출에 대해서 그동안 별도의 통제 방안을 구현하기 어려웠습니다. 이 문제를 해결하기 위해 AWS는 Route 53 Resolver 규칙, Route 53 Resolver DNS Firewall(이하 DNS Firewall), DNS Firewall Advanced와 같은 DNS 전용 보안 기능을 제공합니다. 본 글에서는 이러한 도구들을 단계적으로 적용하여 VPC 내부의 DNS 보안 사각지대를 효과적으로 통제하는 방법을 살펴보겠습니다.
주요 DNS 기반 보안 위협
1) DNS 터널링
DNS 터널링은 네트워크 보안 정책으로 외부 통신이 제한된 환경에서, 공격자가 통제하는 도메인과 네임서버를 활용하여 DNS 요청과 응답에 데이터를 은닉해 외부 시스템과 은밀하게 통신을 수행하는 공격 기법입니다.
전송할 데이터를 Base64 등으로 인코딩하여 서브도메인에 포함한 DNS 요청(예: aHR0cHMudXRwLnR4dC.attacker.hack)으로 전송합니다. DNS Resolver는 해당 쿼리를 attacker.hack 도메인을 소유한 공격자의 네임서버로 전달하고, 네임서버에서 구동 중인 DNS 터널링 도구가 C&C 명령이나 추가 페이로드를 응답합니다.
[그림3] DNS 터널링 시퀀스 다이어그램
이 방식은 은밀하게 백도어로 활용될 수 있습니다. 전송 데이터가 DNS 프로토콜 형식을 준수하므로, DNS 쿼리 로그가 없다면 데이터가 장기간에 걸쳐 유출되어도 모니터링이나 사후 감사가 어렵습니다.
2) DGA(Domain Generation Algorithm) 기반 C&C 서버 통신
DGA는 도메인 생성 알고리즘으로 악성코드의 고정된 Command and Control 서버*(이하 C&C 서버) 도메인이 차단되더라도 지속적으로 통신을 유지하기 위해 사용됩니다.
* C&C 서버: 공격자가 감염된 시스템을 원격으로 제어하고 명령을 전달하는 데 사용하는 악성 서버
악성코드는 DGA를 통해 날짜, 시드 값 등을 조합하여 대량의 난수형 도메인을 자동 생성합니다. 생성된 도메인 목록을 순차적으로 요청하면 대부분 NXDOMAIN(존재하지 않는 도메인)으로 응답하지만, 공격자가 실제로 등록해 둔 극소수 도메인에서는 정상 응답 레코드가 리턴되어 C&C 서버와 연결됩니다.
[그림4] DGA 통신 시퀀스 다이어그램
이러한 특징으로 인해 DGA 알고리즘을 역분석하여 생성 가능한 모든 도메인을 사전 차단하는 것은 이론적으로 가능하지만, 고도화된 DGA는 복잡한 암호화와 다중 시드를 사용하여 분석이 어렵고, 지속적으로 대량 생성되는 도메인을 모두 차단하면 정상 서비스에 영향을 줄 수 있어 현실적으로 한계가 있습니다.
따라서 정적인 차단 리스트로는 사전에 식별하기 힘들고, C&C 서버 도메인이 차단되거나 정지되더라도 악성코드는 곧바로 다른 도메인으로 C&C 서버와의 연결을 시도하므로 탐지와 차단이 매우 어렵습니다.
DNS 보안 설계 ① – DNS Resolver 채널 일원화 및 우회 차단
VPC 내 워크로드는 Route 53 Resolver를 통해 도메인 이름을 해석하도록 기본 설정되어 있습니다. 하지만 사용자가 이를 수정하거나 애플리케이션이 명시적으로 공용 DNS 또는 온프레미스 DNS를 사용하도록 설정할 경우, DNS 요청은 Route 53 기반의 보안 정책을 우회할 수 있습니다. 따라서 DNS 요청 경로를 Route 53 Resolver로 일원화함과 동시에, 외부 DNS 사용 및 IP 직접 접근 시도를 방지하기 위한 IPS 기반 차단 정책을 병행 적용해야 합니다.
<DNS Resolver 우회 차단 예시>
차단 항목 | 위협 시나리오 | 차단 대상 트래픽 | 차단 방식 |
---|---|---|---|
외부 DNS 서버 | 네임서버 변경 등 외부 DNS 요청 | UDP/TCP 53 포트 | DNS 프로토콜 및 포트 차단 |
DNS over TLS(DoT) | TLS 기반 DNS 요청을 통한 우회 | TCP 853 포트 | TLS 기반 DNS 차단 |
DNS over HTTPS(DoH) | HTTPS 기반 DNS 요청을 통한 우회 | TCP 443 포트 및 DoH 도메인 | AlphaSOC 등 HTTPS 기반 DNS 서버 리스트* 차단 |
IP 기반 HTTP(S) 요청 | DNS 사용 없이 https://<IP> 직접 접근 | HTTPS 요청 중 IP literal 사용 | URI 및 호스트 헤더에 IP 사용 차단 |
* AlphaSOC의 HTTPS 기반 DNS 서버 리스트 피드 : https://feeds.alphasoc.net/encrypted_dns.txt
DNS 보안 설계 ② – Amazon GuardDuty로 DNS 위협 탐지 체계 구축
[그림5] Amazon GuardDuty의 기본 데이터 소스를 통한 탐지
Amazon GuardDuty는 VPC Flow Logs, Route 53 Resolver DNS 요청, CloudTrail 관리 이벤트를 기본 데이터 소스로 사용해 위협 인텔리전스와 머신러닝 모델로 실시간 분석합니다. 따라서 DNS 요청 패턴을 모니터링하여 DNS 터널링, DGA 등 DNS 기반 위협을 식별할 수 있습니다. 각 로그를 별도로 저장하지 않아도 GuardDuty를 활성화하면 곧바로 위협 탐지가 시작됩니다.
GuardDuty 탐지 시 담당자에게 알림을 보내고, Lambda와 연동해 인스턴스를 격리하거나 DNS Firewall에 차단 규칙을 추가하는 등 후속 조치를 자동화할 수 있습니다.
<Amazon GuardDuty의 DNS 관련 주요 탐지 항목>
탐지 항목 | 탐지 내용 | 보안 위협 |
---|---|---|
Trojan:EC2/DGADomainRequest | 난수형 도메인을 짧은 주기로 다수 요청 → DGA 의심 | 랜섬웨어·봇넷 초기 정찰 탐지 |
Exfiltration:EC2/DNSTunnelingTrojan:EC2/DNSTunneling | 비정상적인 쿼리/TXT 응답 반복 → DNS 터널링 의심 | 은밀한 데이터 유출 경보 |
Backdoor:EC2/C2DomainRequest.B!DNS | 알려진 C&C 서버 및 멀웨어 호스트 요청 | 공개 위협 인텔리전스 기반 즉시 대응 |
UnauthorizedAccess:EC2/MaliciousDomainRequest | 피싱·익스플로잇 호스팅 도메인 요청 | 사용자 계정·세션 탈취 가능성 탐지 |
또한 GuardDuty의 추가 옵션을 활성화하면 탐지 정밀도가 한층 높아집니다. 먼저 Malware Protection은 DNS 위협으로 의심되는 EC2 인스턴스의 EBS 볼륨을 GuardDuty가 자동으로 스캔합니다. 그 결과 C&C 서버와 통신을 유발한 악성 파일의 경로까지 바로 확인할 수 있습니다. 그리고 Runtime Monitoring은 EC2, 컨테이너 워크로드의 프로세스 등 추가 정보를 수집합니다. 이것은 DNS 터널링, DGA 같은 외부 통신 징후와 내부에서 실제로 실행된 악성 코드 정보를 교차 분석할 수 있어 탐지 정확도를 크게 높일 수 있습니다.
DNS 보안 설계 ③ – AWS 서비스 도메인 요청만 허용하는 Route 53 Resolver 규칙 만들기
Route 53 Resolver는 DNS 요청이 오면, 먼저 VPC에 연결된 Private Hosted Zone(이하 PHZ)에 해당 도메인이 있는지를 검색하고 없으면, Public 도메인을 검색하도록 설정되어 있습니다. 이와 같이 PHZ에 없는 모든 도메인에 대해서는 반복 유형의 인터넷 DNS 요청 방식을 따르게 되며 이를 위한 규칙인 Internet Resolver 규칙은 모든 VPC에 [그림6]와 같이 기본으로 적용되어 있습니다.
[그림6] 모든 VPC에 적용되어 있는 Internet Resolver 규칙
Public 도메인 요청이 불필요한 VPC에서 DNS 요청에 응답하지 않기 위해서는 모든 도메인을 뜻하는 “.” 도메인에 대해 기본적으로 적용되어 있는 Internet Resolver 규칙 대신 다른 규칙을 생성하여 적용합니다. 새로운 규칙은 “.” 도메인에 대한 요청을 미리 지정한 내부 IP 주소로 전달하도록 설정합니다. 이를 위해서는 2가지 작업이 필요합니다.
1) 지정할 내부 IP 주소 확보
지정할 내부 IP는 VPC 내 IP 대역 중 임의(또는 특정할 수도 있음)로 선정하고, 향후 VPC 내 다른 자원이 사용하지 못하도록 하기 위해서 VPC 내 인터페이스를 하나 생성하고 해당 IP 주소를 할당합니다.
[그림7] DNS 포워딩을 수신하기 위한 인터페이스 생성
2) Route 53 Resolver가 DNS 요청을 다른 네임서버로 전달하기 위한 아웃바운드 엔드포인트를 생성
아웃바운드 엔드포인트와 목적지 IP 주소를 확보했으면, 이제부터 기존에 AWS에 기본적으로 적용되어 있는 Public 도메인에 대한 규칙을 새로 추가해 보겠습니다. 즉 “.” 도메인에 대한 DNS 요청을 생성한 IP 주소로 포워딩하도록 규칙을 생성하여 VPC에 적용하면, 아래 화면처럼 기존에 기본 규칙은 재정의(overriding)됩니다. [그림8] 이후 모든 Public 도메인에 대한 DNS 요청은 지정한 IP가 할당된 인터페이스로 전달되며, 이 인터페이스에서는 DNS 요청에 아무런 응답을 하지 않기 때문에 클라이언트는 DNS 요청에 대해 응답을 받지 못합니다.
[그림8] Public 도메인에 대해 포워딩 규칙을 새로 추가
이 경우 Public 도메인 뿐 아니라, AWS 내부 서비스 도메인(amazonaws.com)에 대한 요청도 응답을 받지 못하게 됩니다.
[그림9] Public 도메인과 AWS 서비스 도메인에 대한 DNS 요청 결과]
AWS 내부 서비스에 대한 도메인 요청에 대해서만 허용하기 위해서는 AWS 내부 서비스용 도메인인 amazonaws.com에 대해서는 포워딩 규칙을 적용받지 않도록 예외 처리를 해야 합니다. 이처럼 특정 도메인에 대해 포워딩 규칙을 예외적으로 적용하지 않기 위해서는 해당 도메인에 대한 규칙 유형을 시스템(SYSTEM)으로 설정합니다.
[그림10] amazonaws.com 도메인에 대해 시스템 유형 규칙 추가
위와 같이 구성하여 VPC에 적용하면, 해당 VPC에서 DNS 요청은 AWS 서비스 도메인만 해석되고 그 외 DNS 요청은 차단됩니다.
[그림11] AWS 내부 서비스용 도메인인 amazonaws.com에 대한 예외 규칙 추가한 이후, Public 도메인과 AWS 서비스 도메인에 대한 DNS 요청 결과
DNS 보안 설계 ④ – DNS Firewall로 정책 기반 도메인 통제
DNS Firewall은 VPC 내 DNS 요청을 도메인 기준으로 통제할 수 있는 기능으로, 허용(ALLOW), 차단(BLOCK), 경고(ALERT) 동작을 정의해 데이터 유출이나 악성 도메인과의 통신을 차단할 수 있습니다. DNS 리디렉션 설정으로 기본값인 전체 검사와 최초 검사(리디렉션 도메인 신뢰) 두 가지 방식이 있습니다. 전체 검사는 CNAME 등의 DNS 리디렉션 체인의 모든 도메인이 목록 추가가 필요한 반면, 리디렉션 도메인 신뢰는 첫 번째 요청 도메인만 검사하고 리디렉션 체인을 신뢰합니다.
인터넷 접근이 제한된 VPC에서 허용해야 할 도메인이 소수로 정해져 있는 환경에서는, 업무에 필요한 도메인만 고객 정의 허용 목록(Allowlist)에 등록하고 나머지는 차단하는 방식이 가장 단순하며 관리 부담도 적습니다. 반대로 인터넷 접근이 허용된 VPC에서는 모든 도메인을 직접 관리하기 어렵기 때문에, AWS 관리형 도메인 목록을 차단 목록(Blocklist)으로 지정해 위협 도메인만 BLOCK 또는 ALERT로 처리하고, 필요하면 추가 차단 도메인을 개별 리스트로 관리하는 방식이 효율적입니다.
<AWS 관리형 도메인 목록 현황>
관리형 도메인 목록 | 활용 목표 |
---|---|
AWSManagedCategory-Phishing | 피싱 공격에 사용되는 도메인을 차단 |
AWSManagedCategory-Spam | 스팸 메일 발송·추적 등에 연관된 도메인을 차단 |
AWSManagedDomainsAggregateThreatList | 멀웨어·봇넷·피싱·스팸·DNS 터널링 등 다양한 위협을 통합 차단 |
AWSManagedDomainsAmazonGuardDutyThreatList | GuardDuty 탐지 결과 기반으로 수집된 위협 도메인을 차단 |
AWSManagedDomainsBotnetCommandandControl | 봇넷 C&C 서버 도메인을 차단 |
AWSManagedDomainsGlobalThreatList | 전 세계적으로 확인된 광범위한 위협 도메인을 차단 (집계 피드) |
AWSManagedDomainsMalwareDomainList | 멀웨어 배포·호스팅·전파에 관련된 도메인을 차단 |
DNS Firewall에서 정책을 배포하는 기본 단위는 규칙 그룹입니다. 하나의 규칙 그룹에는 복수 개의 규칙을 담을 수 있고, 각 규칙은 하나의 도메인 리스트를 참조합니다. 도메인 리스트는 사용자 소유 도메인 목록 또는 AWS 관리형 도메인 목록이 될 수 있고, 필요 시 두 유형을 조합할 수 있습니다. 규칙들은 우선순위 번호가 낮은 순으로 처리되며, 매칭된 규칙이 지정한 액션(ALLOW / BLOCK / ALERT)이 적용됩니다. 규칙 그룹은 여러 VPC에 연결해 재사용할 수 있습니다.
[그림12] DNS Firewall 규칙 그룹 구성 예시
VPC에 적용된 DNS Firewall의 규칙 그룹은 크게 세 구간으로 나누어 구성됩니다. 가장 먼저 처리되는 우선순위 1–99 구간과 가장 마지막에 처리되는 9,901-10,000 구간은 AWS Firewall Manager가 조직 전체에 배포한 규칙 그룹입니다. 우선순위 100-9,900은 VPC 개별로 적용되는 규칙 그룹입니다. 이 구조는 조직 공통 정책과 VPC별 정책을 여러 규칙 그룹으로 계층화해 충돌 없이 운용할 수 있도록 돕습니다. 각 구간에는 여러 규칙 그룹을 적용할 수 있습니다. 우선순위에 따라 규칙 그룹 및 그룹 내 규칙을 평가하면서 매칭되는 규칙의 액션이 실행되고 규칙 평가는 종료됩니다. 모든 규칙 그룹을 평가 후 매칭되는 규칙이 없으면 DNS 요청은 기본 동작인 허용(ALLOW)으로 처리됩니다.
[그림13] VPC에 DNS Firewall 규칙 그룹이 연결되어 처리되는 순서
DNS Firewall에서 BLOCK 액션은 세 가지 응답 옵션을 선택할 수 있습니다. 먼저 NODATA는 도메인이 존재하지만 요청한 레코드 유형에 대한 데이터가 없다는 빈 응답을 반환해, 클라이언트가 타임아웃이 발생할 때까지 응답을 대기하도록 합니다. 두 번째로 NXDOMAIN은 도메인이 존재하지 않는다는 응답으로 브라우저나 애플리케이션이 즉시 실패 처리하도록 하여 지연을 최소화합니다. 끝으로 OVERRIDE는 지정된 레코드 값을 반환해 트래픽을 전달하거나 차단 안내 페이지로 유도할 때 사용합니다. 이 세 가지 옵션을 통해 BLOCK 동작을 운영 환경과 요구 사항에 맞게 세밀하게 조정할 수 있습니다.
DNS 보안 설계 ⑤ – DNS Firewall Advanced로 실시간 이상 탐지 및 차단
DNS Firewall Advanced는 머신러닝 기반 분석으로 DNS 터널링 및 DGA(도메인 생성 알고리즘)와 같은 보안 위협에 대응할 수 있습니다. 인터넷에서 가장 많이 조회되는 도메인과 AWS 내부 실제 트래픽 패턴을 학습해 정상 도메인의 구조, 철자, 어휘 분포를 기준으로 랜덤 문자열 및 비정형 패턴의 DNS 요청을 탐지합니다.
DNS Firewall Advanced를 사용하려면 규칙 등록 시 규칙 유형을 도메인 목록 대신 DNS 방화벽 고급 보호기능을 선택하고 보호 기능(DNS 터널링, DGA)과 신뢰도 임계값(높음, 중간, 낮음)에 따른 액션을 지정합니다. 머신러닝 기반의 탐지 기법 특성 상 신뢰도 임계값을 조정해 오탐에 대비한 탐지 민감도를 균형 있게 설정할 수 있습니다. 동일한 규칙 유형을 서로 다른 신뢰도 임계값으로 이중 등록하면, BLOCK과 ALERT을 동시에 정책 운영하는 것이 가능합니다. 첫 번째 규칙은 임계값을 높음으로 두고 액션을 BLOCK으로 지정해 확실한 위협을 즉시 차단하며, 두 번째 규칙은 임계값을 중간 또는 낮음으로 설정해 오탐 가능성이 있는 탐지 액션을 ALERT로 지정함으로써 잠재적인 위협을 모니터링합니다.
[그림14] 동일한 규칙 유형을 신뢰도 임계값에 따라 액션 구분
DNS 보안 설계 ⑥ – Route 53 Resolver Query Logging
[그림15] Route 53 Resolver Query Logging에서의 DNS 요청 로깅 구성
자세한 DNS 활동을 파악하려면 Route 53 Resolver Query Logging을 활성화해야 합니다. 이 기능을 켜면 Resolver가 처리한 모든 쿼리 로그를 CloudWatch Logs, Amazon S3, Kinesis Data Firehose 중 하나 또는 복수로 전송할 수 있습니다. 전송된 로그는 CloudWatch Logs Insights 등을 통해 쉽게 분석할 수 있습니다.
DNS 보안 설계 ⑦ – 조직 전반의 일관된 정책 적용
조직 전체에 동일한 DNS 보안 구성을 배포하려면 AWS Firewall Manager와 Amazon Route 53 Profiles를 함께 사용하는 방식이 효율적입니다.
1) AWS Firewall Manager
Firewall Manager는 DNS Firewall 규칙 그룹을 중앙에서 관리 및 배포하는 AWS 보안 서비스입니다. 관리 계정에서 정책을 작성하면, 지정한 OU나 계정 범위에 속한 모든 VPC에 DNS Firewall 규칙 그룹이 AWS RAM(Resource Access Manager)을 통해 자동 공유 및 연결됩니다. 새로운 VPC 생성 즉시 동일 규칙을 즉시 적용할 수 있습니다.
2) Amazon Route 53 Resolver Profiles
Route 53 Profiles는 Resolver 규칙과 DNS Firewall 규칙 등을 하나로 묶어 프로파일로 저장한 뒤, 적용할 VPC에 연결할 수 있도록 지원합니다. 프로파일 자체는 RAM을 통해 다른 계정에 공유할 수 있어, 여러 계정에서 동일 Resolver 규칙을 쉽게 재사용할 수 있습니다.
<Firewall Manager VS Route 53 Resolver Profiles>
구분 | Firewall Manager | Route 53 Resolver Profiles |
---|---|---|
관리 대상 | DNS Firewall 규칙 그룹 | DNS Firewall 규칙 및 Resolver 규칙 등 Route 53 설정 |
관리 방법 | – AWS Organizations를 통해 정책 공유 및 적용 – 조직 내 준수 상태 모니터링 – 새 VPC에 자동 적용 |
– AWS RAM으로 타 계정에 프로파일 공유 – 각 계정이 프로파일을 VPC별로 수동 연결 |
마치며
본 글에서 제시한 단계별 DNS 보안 설계는 SG·NACL·AWS Network Firewall 등의 Egress 체인으로는 통제할 수 없었던 VPC DNS Resolver 경로를 안전하게 보호합니다.
- DNS Resolver 채널 일원화 및 우회 차단 적용
- GuardDuty로 DNS 기반 위협 탐지
- Route 53 Resolver 규칙으로 기본 차단 정책 수립
- DNS Firewall로 사용자 지정 도메인 목록 및 AWS 관리형 도메인 목록 기반 정책 수립
- DNS Firewall Advanced의 머신러닝 기법으로 시그니처를 우회한 공격 보호 적용
- Resolver Query Logging으로 DNS 요청 로그 수집 및 사후 분석
- Firewall Manager 및 Route 53 Profiles를 활용한 조직 전반에 일관된 DNS 보안 설정 적용
이 7단계 DNS 보안 설계를 통해 Egress 체인을 우회하는 DNS 위협을 차단하고, 트래픽을 빠짐없이 모니터링할 수 있습니다. “항상 검증하고 절대 신뢰하지 않는다”는 제로 트러스트 보안 모델을 기반으로 Amazon VPC에서 안전한 DNS 요청 체계를 구축해 보시기 바랍니다.