zone-transfer 허용의 문제점과 대응방법

Zone transfer 허용의 문제점과 대응 방안
오늘과내일 시스템운영부 홍석범(antihong@tt.co.kr)
0. 들어가기에 앞서
DNS(Domain Name System) 서비스는 인터넷 서비스의 근간이라 할 만큼
매우 중요한 역할을 하고 있다. DNS는 웹 서비스뿐만 아니라 메일 서비스등
과도 밀접하게 연관되어 있고 심지어는 telnet이나 ftp,pop3 서비스에서의
역 질의(reverse lookup)와도 연관되어 있어 DNS에 장애가 발생할 경우에
는 접속 불안, 속도 저하 등 그 피해가 매우 커질 수 있다. 더군다나 DNS는
캐시(Cache)라는 개념이 적용되어 있어 장애를 수정했다 하더라도 바로 적
용되지 않고 장애가 오래 지속될 수 있다는 문제점이 있다. 그럼에도 불구하
고 DNS는 보안의 사각지대라 불릴 만큼 보안 설정이 허술한 것이 사실이다.
여기에서는 특히 보안이 잘 되어 있다는 대기업에서조차 제대로 설정되어
있지 않아 기업이나 조직내 정보유출의 단초가 될 수 있는 zone-transfer
허용의 문제점과 대응방안에 대해 알아보도록 하겠다.
1. zone –transfer란 무엇인가?
zone-transfer, 우리말로 zone전송이라고도 하는 이것은 master와 slave간
에 또는 1차와 2차간에, primary와 secondary DNS간에 zone 파일을 동기
화하기 위한 용도로 사용되는 기술이다. 많은 관리자들이 1차와 2차 DNS를
마치 active/standby처럼, 2차를 백업의 용도로 생각하여 1차가 서비스를 하
다가 만약 1차가 다운되면 대신 2차 DNS가 서비스하는 것으로 생각하지만
이는 잘못된 것이다. 1차와 2차는 백업이 아닌 로드발랜싱의 개념이며 따라
서 1차와 2차가 똑같이 DNS lookup을 서비스하는 것이다. 따라서 양 서버
간에 zone 파일을 동기화하기 위해서는 zone 파일을 NFS등으로 연결하여
사용하는 방법도 있겠지만 DNS 자체에 zone-transfer라는 기능을 제공하고
있어 주로는 이 기능을 이용하고 있다. 참고로 해당 서버간 Zone-transfer
시에는 해당 zone 파일의 SOA필드에 있는 Serial 필드를 보아 갱신할 것인
지 여부를 결정하게 된다.
2. Zone-transfer의 문제점
그렇다면 zone-transfer의 문제점은 무엇일까? 여러 가지 문제점이 있지만
가장 큰 문제점은 인터넷 서비스를 제공하는 많은 대기업의 관리자조차
zone-transfer의 중요성을 망각한 채 또는 실수로 인하여 무방비로 중요한
정보를 외부에 유출하고 있다는 것이다. 앞에서 살펴본 것처럼 zonetransfer는
master와 slave간의 zone 파일 전송이므로 master와 slave간에
만 허용되어 있어야 하지만 실제로는 그렇게 접근 통제가 되고 있지 못하다
는 것이다. 아래에서는 국내에서도 손꼽히는 한 대형 포털의 예를 들어 이의
문제점을 살펴보도록 하자.
(1) 먼저 whois질의를 통해 해당 도메인의 DNS 정보를 확인한다.
whois xxxx.com
NS1.xxxx.COM 211. xx.xx.xx
NS2.xxxx.COM 211. xx.xx.xx
(정보를 일부 수정하였음)
(2) 해당 DNS 서버로 zone-transfer를 시도해 본다. Zone-transfer는
nslookup이나 host, dig등으로 모두 확인 가능한데, 여기에서는 dig으로 사
용해 보겠다.
# dig @NS1.xxxx.COM xxxx.com axfr
; <<>> DiG 9.2.1 <<>> @NS1.xxxx.COM xxxx.com axfr
;; global options: printcmd
; Transfer failed.
참고로 위의 명령어는 NS1.xxxx.COM DNS에 xxxx.com 이라는 도메인에
대해 zone-transfer한다는 의미이다. master DNS인 NS1.xxxx.COM에 질의
를 하자 위와 같이 전송이 실패했다는 에러 메시지(Transfer failed)가 보였
다. 이는 해당 IP에서의 zone-transfer가 거부되었다는 메시지로서
NS1.xxxx.COM에서 정상적으로 차단하고 있다라는 것을 알 수 있다. 이번
에는 slave DNS인 NS2.xxxx.COM에 질의를 해 보았다.
# dig @NS2.xxxx.COM xxxx.com axfr
xxxx.com. 1800 IN SOA ns1.xxxx.com.
hostmaster.ns1.xxxx.com.
xxxx.com. 1800 IN MX 5 mail4.xxxx.com.
xxxx.com. 1800 IN MX 5 mail5.xxxx.com.
xxxx.com. 1800 IN A 211.xx.xx.xx
xxxx.com. 1800 IN NS ns1.xxxx.com.
xxxx.com. 1800 I N N S ns2.xxxx.com.
09.xxxx.com. 300 IN A 211.115.xx.xx
100.xxxx.com. 1800 IN CNAME dic.xxxx.com.
100dev.xxxx.com. 1800 IN A 211.xx.xx.xxx
24mall.xxxx.com. 1800 IN A 61.xx.x.xxx
account.xxxx.com. 1800 IN A 211.xx.xx.xxx
admin.xxxx.com. 1800 IN A 211.xx.xx.xx
.........
확인 결과 이 도메인의 경우 800여 줄이 넘는 zone 정보가 확인되었고 그
중에는 dev.xxx와 같이 개발 서버로 사용되는 것으로 추측되는 서버들의 목
록도 눈에 띄었다. 이는 대단한 해킹기법도 아니고 정상적인 DNS zonetransfer를
자체에서 제공되는 명령어로 실행해 본 것뿐인데도 불구하고 이
처럼 많은 정보를 제공하고 있는 것을 알 수 있는데 이로 인하여 다음과 같
은 문제가 유발될 수 있다.
① 불필요한 정보 유출
가장 심각한 문제라 할 수 있다. 실제 많은 기업에서 외부에 노출되어 보이
는 웹 서버나 메일 서버 뿐만 아니라 내부의 개발서버, 인트라넷등도 “xxxx.
도메인명”등으로 사용하고 있는데, zone-transfer를 해 보면 이 정보들이 그
대로 보이기 때문에 공격자 입장에서 굳이 해킹을 통해 알 필요 없이 내부
의 시스템/네트워크 구조를 쉽게 파악할 수 있게 된다. 실제로 필자도 특정
업체의 모의 해킹등을 할 때 이 방법을 자주 활용하고 있다.
또한 사용하고 있는 IP 대역등도 노출되어 IDC등에서 사용하는 IP 대역뿐만
아니라 사내의 IP대역이나 방화벽 등 보안 장비의 IP도 노출되게 된다. 그리
고, 어떤 업체의 경우 서버의 대수나 규모 등의 정보도 알 수 있게 된다.
② zone 전송을 시도시 zone 파일의 크기에 따라 수M 이상의 트래픽이 전
송될 수 있다. 따라서 악의적인 목적으로 지속적인 전송 시도시 bandwidth
를 가득 채우게 되어 서비스거부(Denial Of Service)공격이 될 수 있다.
3. Zone-transfer 대응 방안
이제 zone-transfer의 의미와 허용되었을 경우 그 위험성에 대해 살펴보았
다. 그럼, 어떻게 대응하여야 할 것인가? 각각의 경우에 대해 알아보자.
(1) zone-transfer가 필요하지 않은 경우
먼저, 자신의 DNS 서버에서 zone-transfer가 필요한지 확인해 보기 바란다.
다음과 같은 경우라면 zone-transfer를 제공할 필요가 없는데 아마도 대부
분이 이 경우에 속할 것이다.
-. 1대의 DNS만 운영할 경우
whois에는 1차와 2차로 등록하도록 되어 있기 때문에 모두 등록은 했지
만 실제 1차만 운영되고 2차는 ns2.kornet.net등 운영하지 않는다면
zone-transfer는 필요 없다.
-. 수동으로 zone 파일을 동기화 할 경우
설사 master/slave 형태로 2대 이상의 DNS를 운영한다 하더라도 자동
zone-transfer가 아닌 수작업으로 동기화하거나 rsync등 다른 방식으로
동기화한다면 역시 zone-transfer는 필요 없다.
-. 동기화가 아닌 NFS등으로 서비스 할 경우
zone 파일을 각각의 개별 서버에서 서비스하는 것이 아니라 별도의 스토
리지등에서 서비스하면서 실제 DNS 에서는 NFS로 연결하여 사용하는
경우 역시 이 기능을 사용할 필요가 없다.
위와 같은 경우 named.conf에서 아래와 같이 설정하면 된다.
options {
allow-transfer {none; };
};
(2) master/slave로 서비스할 경우
대기업이나 포털등 큰 규모의 서비스 업체에서는 대부분 이 방식으로 운영
하고 있다. 여기에서 다시 zone-transfer의 의미를 생각해 본다면 당연히
master에서는 slave에서의 zone-transfer만 허용하도록 하고, slave에서는
다른 slave가 없는 한 zone-transfer를 모두 거부하여야 할 것이다. 그러나
대부분의 관리자가 실수하는 것 중 하나가 바로 master에서는 slave에서만
질의 가능하도록 접근 제어를 하고 있으면서 slave에서는 zone-transfer를
모두 허용해 놓는다는 것이다. 이는 마치 현관문은 엄격하게 출입통제 하지
만 창문은 훤히 열어두는 것과 같은 격으로 실제 많은 공격자들이 이의 문
제점을 악용해 기업 정보에 쉽게 접근하고 있다. 위 포털 업체뿐만 아니라
필자가 질의해 본 몇몇 방송사,대학, 유명 쇼핑몰 업체등의 경우도 대부분
이러한 취약성을 가지고 있었다. 위 업체의 경우 다음과 같이 설정하면 된다.
master 서버에서의 설정)
options {
allow-transfer {192.168.1.3; };
};
여기에서 192.168.1.3은 slave DNS의 IP이며 당연히 slave에서의 zonetransfer만
허용한다는 의미가 된다.
Slave 서버에서의 설정)
options {
allow-transfer {none; };
};
당연히 slave에서는 zone-transfer를 제공하지 않으므로 허용할 필요가 없
다. 설정을 한 이후에는 dig을 이용하여 임의의 IP에서 질의시 zonetransfer가
허용되지 않는지 반드시 확인해 보기 바란다.
(3) 기타
이외, bind 9.x에서부터 지원하기 시작한 TSIG기반의 접근 통제를 이용할 수
있다. 이는 앞에서 살펴본 IP기반의 접근 통제 대신 사전에 미리 공유된 암
호키를 이용하여 트랜잭션 하는 것으로 같이 사용할 경우 더욱 강화된 접근
통제를 구성할 수 있을 것이다.
또한 방화벽을 이용하는 방법도 고민할 수 있다. 이는 zone-transfer의 경
우 udp대신 tcp를 사용한다는 것을 이용하는 것인데, 정상적인 질의시 tcp
도 사용되는 경우가 있으므로 tcp 53 자체를 차단하는 것은 그리 바람직한
것은 아니라고 생각한다.
4. 끝마치며 … ..
보안의 시작은 엄격한 접근 통제에서부터 시작된다고 생각한다. 마치 문단속
만 제대로 하면 안심하고 집을 비울 수 있는 것처럼 말이다. 그러나 앞에서
언급한 바와 같이 현관문은 엄격하게 통제하면서 창문은 훤히 열어두는 이
런 어이없는 경우가 많은 것이 실제 우리의 현실이라 할 수 있다. 언제나 보
안 사고는 예상치 못한 작은 헛점에서부터 시작되는 만큼 자신이 관리하는
시스템/네트워크에서 헛점은 없는지 다시 한번 점검해 보기 바란다.
아울러, 필자가 집필한 “리눅스 서버보안 관리실무” 에서는 서버/네트워크 운
영시 꼭 필요한 보안의 원리와 보안 설정 그리고 관리자가 놓치기 쉬운 보안
에 대해 자세하고 쉽게 설명하고 있으니 꼭 참고하기 바란다.
http://www.superuser.co.kr/linuxsecurityadmin/