문제점
DNS zone 전송(transfer)은 마스터(master)와 슬레이브(slave) 간에 zone 파일을 동기화하기 위한 용 도로 사용되는 기술이다. 그런데, 이 zone 전송 보안 설정을 제대로 하지 않아 심각한 보안문제를 유발 하는 경우가 많다. 이로 인해서 직접 시스템이 다운되거나 장애가 유발되는 것은 아니지만, 문제는 중 요한 정보를 외부에 유출할 가능성이 있다는 것이다. 특히 대규모 사이트 일수록 그 피해가 큰데, 앞에서 언급한 것처럼 zone 전송은 마스터와 슬레이브 간 의 zone 파일 전송이므로 마스터와 슬레이브 사이에만 허용돼야 하지만, 실제로는 접근 통제가 거의 이뤄지지 않고 있다. 국내에서도 손꼽히는 한 대형 포털의 예를 들어 이의 문제점을 살펴보도록 하자.
① 먼저 whois 질의를 통해 해당 도메인의 DNS 정보를 확인한다.
whois xxxx.com NS1.xxxx.COM 211.xx.xx.xx NS2.xxxx.COM 211.xx.xx.xx (정보를 일부 수정하였음)
② 해당 DNS 서버로 zone 전송을 시도해 본다. Zone 전송은 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 전송을 한다는 의미 다. 마스터 DNS인 NS1.xxxx.COM에 질의하면 이같이 전송이 실패했다는 에러 메시지(Transfer failed)가 표시된다. 이는 해당 IP에서의 zone 전송이 거부됐다는 메시지로 NS1.xxxx.COM에서 정상적 으로 차단하고 있다는 것을 알 수 있다. 이번에는 슬레이브 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 IN NS ns2.xxxx.com. 09.xxxx.com. 300 IN A 211.115.xx.xx 100.xxxx.com. 1800 IN CNAME dic.xxxx.com. 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 zone 전송을 자체에서 제공되는 명령어로 실행해 본 것에 불과함에도, 이처럼 많은 정보를 제 공하고 있는 것을 알 수 있으며, 이로 인해 불필요한 정보가 유출될 수 있다. 실제 많은 기업에서 외부 에 노출돼 보이는 웹 서버나 메일 서버뿐 아니라 내부의 개발 서버, 인트라넷 등도 ‘xxxx.도메인명’ 등 으로 사용하고 있는데, zone 전송을 시도해 보면 이 정보가 그대로 보이기 때문에 공격자 입장에서 굳 이 해킹을 통해 알 필요 없이 내부의 시스템/네트워크 구조를 쉽게 파악할 수 있다. 또한 사용하고 있는 IP 대역 등도 노출돼 IDC 등에서 사용하는 IP 대역뿐만 아니라 사내의 IP 대역이나 파이어월 등 보안 장비의 IP까지도 노출될 수 있다. 그럼 zone 전송의 정보유출에 대해 어떻게 대응해야 하는지 알아보자. 너무나 당연한 이야기이지만 원 칙에 충실하면 된다. bind DNS를 사용할 경우에는 ‘/etc/named.conf’에 다음과 같이 설정하면 된다.
- 마스터 서버에서의 설정
options { allow-transfer {192.168.1.3; }; };
여기에서 192.168.1.3은 슬레이브 DNS의 IP이며 당연히 슬레이브에서의 zone 전송만 허용한다는 의 미다.
- 슬레이브 서버에서의 설정
options { allow-transfer {none; }; };
당연히 슬레이브에서는 zone 전송을 제공하지 않으므로 허용할 필요가 없다. 이같이 설정한 후 DNS를 재가동하면 외부에서의 불법적인 zone 전송은 거부한다.
------------------------------------------------------------------------
확인방법
도메인 리스트 취약점
nslookup
> server ns.xxx.com
> ls -d xxx.com
리스트 목록이 나오면 취약~!
------------------------------------------------------------------------
해결 방법
DNS도 DNS SPOOFING을 당할 수 있다. DNS스푸핑을 차단하는 방법은 RECURSION을 제한해야 한다.
RECURSION 설정은 다음과 같다.
NAMED.CONF에 다음과 같이 옵션지정을 한다.
OPTIONS {
directory "va/named";
allow-recursion {127.0.0.1; 10.40.0.0/24; };
};
아니면 recursion을 제공하지 않고자 한다면 다음과 같이 설정한다.
options {
allow-recursion {none;};
};
또다른 설정은
options {
recursion no;
};
설정을 한 후 recursion 설정 허용 여부를 확인하는 방법은 아래아 같다.
http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl
접속하여 해당 도메인 서버 주소나 아이피를 입력하면 허용 유무를 확인 할 수 있다.
참고로 open으로 표시가 된다면 recursion 설정을 해야 된다.
zone-transfer 제한설정
특정 dns 의 zone 설정을 확인하는 방법이다.
명령은 dig 또는 host 명령으로 특정 dns서버의 zone파일을 확인하는 방법이다.
#dig @ns.dacom.net dacom.net
#host -l dacom.net ns.dacom.net
위 명령으로 질의를 하면 SOA, dacom.net의 zone 파일 정보 및 도메인 앞에 붙는 모든 서버들의 목록과 해당 아이피를 확인할 수 있게 된다.
만약 dns서버를 master와 slave를 사용한다면 master서버에서 slave서버의 zone-transfer만 허용하도록 설정한다.
그리고 slave서버를 3차 4차 dns서버로 zone-transfer를 제공하지 않는 다면 사용하지 않는 것으로 꼭꼭!! 설정해야 한다.
dns서버를 master서버만 사용한다면 마찬가지로 zone-transfer는 사용하지 않는 것으로 설정한다.
설정방법
options {
allow-transfer { none;};
};
위 방법은 전체 도메인에 대해 zone-transfer를 제한하는 방법이고 특정 도메인만 제한 하고자 한다면 다음과 같이 설정한다.
zone "network.co.kr" {
type master;
file "network.co.kr.zone";
allow-transfer { none;};
};
dns(Bind)버전정보유출 제한 설정
options {
version "Unknown";
};
'Security > Vulnerability' 카테고리의 다른 글
윈도우 도메인(AD) 기반 취약성 점검 방법 (0) | 2016.11.10 |
---|---|
난독화된 자바스크립트 분석 방법 (0) | 2010.06.23 |