> 뉴스 > 테크가이드 > 보안
  • 트위터
  • 페이스북
  • 구플러스
  • 네이버밴드
  • 카카오스토리
     
“네트워크 인프라 보안은 DNS 관리부터”
DNS(Domain Name System)
2008년 03월 19일 00:00:00 데이터넷
DNS 중요성 더욱 증가 … 패치·업데이트 등 취약점 예방 ‘필수’


DNS(Domain Name System)는 단순히 인터넷에 접속된 호스트 장비의 이름과 이에 해당하는 IP 주소를 매치 시켜주는 일만 한다기 보다는 유비쿼터스 환경으로 변모하는 정보화 시대의 물과 공기와도 같은 필수 IT 인프라로 발전돼 왔다. 현재 도메인네임은 더 이상 호스트 장비의 물리적인 이름만을 의미하지 않는다. 전자우편 주소가 전화번호 수보다 많아졌으며, 국가 도메인(.kr)의 규모도 100만 시대가 임박했다. DNS는 인터넷 정보를 담고 있는 거대한 분산 데이터베이스 시스템이다. 네트워크 인프라 보안은 DNS 관리부터 시작돼야 한다. 앞으로 4회에 걸쳐 DNS, DHCP, RADIUS 등 핵심 프로토콜 관리의 중요성과 대응책에 대해 살펴본다. <편집자>


연재순서
1회 : DNS 중요성과 보안 취약점 대응책(이번호)
2회 : DNS 서버 취약점 진단과 베스트 프랙티스
3회 : IP 기반 네트워크 환경 도래에 따른 선결과제
4회 : 핵심 네트워크 서비스에 대한 효율적 관리방안

정재원 // 엑스퍼넷 기술3팀 대리jwjung@expernet.co.kr

직장인 A씨의 일상을 보자. 출근을 하자마자 자신의 노트북을 켠다. 그리고는 차 한 잔을 타 놓고 바탕화면 아이콘에 있는 인터넷 브라우저를 클릭한다. 초기화면으로 등록된 포털사이트의 헤드라인을 눈여겨보며 어제, 오늘 아침까지 무슨 일이 있었는지 살펴본다. 그리고는 회사 메일을 조회해 각종 업무와 관련된 일들을 하나하나씩 하게 된다. 중요한 메일에는 답신 메일을 보내거나 즉각적으로 필요한 조치들을 전화로 연락한다. 또한 점심시간에는 자신의 금융정보를 조회하거나 몇일 전에 인터넷으로 구매한 상품들이 언제 집에 도착하는지, 할인쿠폰이나 적립 혜택은 있는지 들을 관심 있게 들여다본다. 오후에는 사내 웹 인트라넷에 접속해 필요한 정보들을 조회하고 업무에 활용한다.
바야흐로 인터넷으로 하루를 시작해 인터넷으로 끝을 맺는 일상은 이제 더 이상 새로울 것이 없는 것처럼 당연시되고 있는 시대에 살고 있다. 이렇게 일상의 동반자가 돼 버린 인터넷에 접속되지 않으면 업무나 생활도 마비 상태가 된다는 것을 이미 우리는 지난 2003년 1월 25일에 모두 경험한 바 있다. 인터넷의 핵심 정보와 기술은 인터넷 주소창에 입력하는 도메인들을 관리하는 DNS에 있다. 이 DNS 기술에서 취약한 부분과 그 대응책에 대해 자세히 살펴본다.

DNS 침해사례

● 1.25 인터넷 대란
인터넷은 정보화 사회의 핵심 인프라며 DNS는 인터넷의 핵심 애플리케이션 프로토콜이다. DNS에 관심을 가지게 된 데는 벌써 5년이 지났지만 1.25 인터넷 대란의 여파가 크다고 볼 수 있다.
대란 당시 입증된 바와 같이 최근 바이러스는 특정 DNS 서버를 공격하는 등 바이러스 패턴이 갈수록 지능화되고 있다.


● 강력한 신종 DoS 공격
베리사인 켄 실바(Ken Silva) CSO는 지난 2005년 12월에 처음으로 확인된 신종 DoS 공격은 지난 2006년 1월에 가장 기승을 떨쳤으며, 2개월간 1천500건의 개별 IP주소가 이 수법에 영향을 받았다고 했다. 실바는 “이러한 공격은 우리가 예전에 본 적이 없을 정도로 큰 것이었다”고 말했다.
일반적인 DoS 공격은 원격 공격자에게 납치된 감염 PC인 봇(Bot)의 네트워크가 표적이 된 유저의 웹 서버나 네임서버, 메일 서버 등에 대량의 쿼리를 보내는 방법으로 행해진다. 이러한 요구를 처리하려고 하는 피해자의 시스템을 파괴하는 것이 DoS 공격의 목적이다.
그러나 최신의 DoS 공격에서 봇은 DNS 서버에 표적의 주소를 답신처로 설정한 쿼리를 송신한다. 그 결과 봇이 아닌 DNS 서버가 표적을 향해 직접 공격하는 사태가 발생한다. 실바는 이러한 구조에 의해 공격은 한층 더 강력해져 저지하는 것이 어려워진다고 말하고 있다.


DNS 취약점 이용한 공격 방법
DNS는 데이터베이스를 사용해 호스트 네임을 인터넷 프로토콜 주소로 변환시키는 것을 쉽게 해 주는 아주 중요한 인터넷 메커니즘이다. DNS는 초기의 상호 신뢰에 기반한 환경에서 개발된 모델로, 오늘날 인터넷 환경이 악의적으로 변함에 따라 DNS는 캐시 포이즈닝(cache poisoning), 도메인 하이재킹, 맨인더미들(man-in-the-middle) 우회 등을 포함, 많은 유형의 공격 대상이 됐다.

● DNS 구성 프로토콜 취약점에 의한 공격
DNS 프로토콜 자체의 결함을 이용해 공격하는 것으로 과도한 로드를 걸거나 메모리 조작으로 인해 정상적인 DNS 서비스를 불가능하게 만드는 것으로 DoS, DDoS 공격이 예가 될 수 있다.


● DNS 캐시 포이즈닝에 의한 공격
지난 1997년 7월, 웹 브라우저에 www.internic.net을 입력한 사용자들은 자신이 InterNIC의 웹 사이트를 방문했다고 생각하지만 실제로는 AlterNIC에 속한 웹 사이트를 방문한 것이었다. 어떻게 이런 일이 발생한 것일까. 유진 카슈프레프(Eugene Kash pureff)라는 사람이 전 세계 주요 네임 서버의 캐시를 고쳐버리는 프로그램을 실행해 www.internic.net의 주소를 AlterNIC 웹 서버의 주소로 바꿨기 때문이다. 캬슈프레프가 무언가를 바꾼 것은 아니었으므로 사람들이 방문한 웹 사이트는 InterNIC이 아니라 AlterNIC의 콘텐츠 그대로였지만 이런 상황을 생각해보자.
어떤 사람이 www.amazon.com이나 www.yourbank.com 등과 같은 중요한 전자상거래 사이트의 주소가 자기의 웹 사이트를 가리키도록 네임 서버 캐시를 고쳤다. 그리고 그 사이트도 원래의 전자상거래 사이트와 비슷하게 꾸미면 사람들은 별 의심 없이 신용카드번호나 주민등록번호를 입력할 것이다.
호스트명의 IP주소를 변경, 인터넷 사용자를 위조된 웹사이트로 유인하는 등의 파밍(Pharming)과 피싱(Phishing) 등의 공격이 가능해진다는 점에서 전자보다 더 위협적이다. 이는 이용자들이 평소처럼 사이트에서 카드번호, 비밀번호 등을 그대로 사용, 중요한 개인정보들을 그대로 노출시키는 심각한 상황으로 이어질 수 있다. 또 이를 통해 사용자 PC에 악성코드 및 실행파일 등을 강제로 실행시킬 수 있어 그 심각성이 더 크다는 것이 중론이다.

● 재귀 서비스 거부 공격
장악한 DNS 서버나 공격을 위해 설정한 DNS 서버에 DNS 레코드를 저장한다. 그런 뒤 봇넷을 이용해 일반 네임 서버에 리턴 어드레스를 타깃 시스템으로 위조한 작은 UDP/53 쿼리를 보내는 방법으로, 재귀 DNS 서버로 하여금 타깃에 직접적인 공격을 가하게 한다. 이 공격은 DNS 레코드가 전형적인 UDP/53 응답 패킷보다 많을수록 효과가 크다.


● 권한 구역(Authoritative zone) 응답 스푸핑
장악한 웹 서버에 가짜 웹 사이트(피싱 사이트)를 만든 뒤 봇넷을 이용해 요청을 대기하다가, 특정 지역에 대한 DNS 응답을 받으면 장악한 웹 서버로 보내도록 조작한다. 이 공격은 봇에 감염된 컴퓨터상에서 수행되는데, 로컬 호스트 파일을 수정해 가짜 웹사이트로 가도록 한다.

DNS 서버 BIND 취약점
BIND(The Berkeley Internet Name Domain) 패키지는 특정 IP주소를 몰라도 도메인 이름(예: www.expernet.
co.kr)만으로 인터넷상에서 서버에 접근할 수 있는 DNS에 가장 널리 사용되는 제품이므로 공격자의 주 대상이 돼 왔다. 전통적으로 BIND 개발자들이 취약성을 신속히 보완해 왔음에도 불구하고 아직까지 엄청난 수의 DNS 서버들이 잘못 구성되거나 노후 서버에 탑재돼 사용되고 있는 관계로 공격의 대상이 되고 있다.
보안 업그레이드의 중요성을 알지 못하는 관리자와 불필요한 BIND 데몬(“named”)을 운영해 취약한 구성 파일을 가진 시스템은 DoS 공격이나 버퍼 오버플로우 또는 DNS 캐시 포이즈닝과 같은 공격을 허용하게 된다. 잘 알려진 BIND 취약점 중 하나는 서비스 거부 공격으로서 CERT Advisory CA-2002-15(www.cert.org/advisories/CA-2002-15.html)에서 논의되고 있다.
이러한 경우 공격자는 특정 DNS 패킷을 보내 취약한 내부 일관성 검사(consistency check)를 유발시켜 BIND 데몬을 셧다운 시킬 수 있다. 더불어 취약한 BIND는 그것을 호스팅하고 있는 서버를 위험에 빠뜨릴 뿐만 아니라 인터넷상의 다른 시스템을 공격하는 전초기지 역할까지 제공하게 된다.


윈도 DNS 서버 보안 취약점
해당 취약점은 MS 윈도 2000 서버 SP4, MS 윈도 서버 2003 SP1/SP2 시스템이다. 이들 서버 관리자들은 긴급 보안조치로 발표된 사항을 반드시 적용해야 한다. KISA는 윈도 DNS 서버를 운영하고 있을 경우, DNS 서버의 원격 관리 기능을 제거하거나 방화벽 등에서 1024번에서 5000번까지의 포트를 차단하도록 권고하고 있다. 또한 향후 MS에서 보안패치가 발표되면 이를 즉각 적용할 것을 당부하고 있다.

DNS 사용 현황 조사 결과
지난 2005년 10월 메저먼트팩토리(Measurement Factory)와 인포블럭(Infoblox)의 공동 조사에 의하면 전 세계 인터넷상에 750만 개의 인터널 DNS 서버가 존재하는 것으로 파악됐다. 조사 대상으로 샘플링한 130대의 DNS 서버중 75% 이상이 임의의 쿼리에 대해 재귀적(recursive) 네임 서비스가 허용되고 있었다. 또 40% 이상이 임의의 쿼리로부터의 구역 트랜스퍼(zone transfer)를 허용하고 있어 DoS 공격에 네임서버를 노출시켜 내부 네트워크 정보를 공격자에게 알려주는 결과를 초래하고 있었다.
이 중 33%에서는 구역의 권한(authoritative) 네임서버들 모두가 24비트의 동일 서브 네트워크상에 존재해 결과적으로 네트워크 장애나 고의적인 DoS 공격 등에 무방비한 상태로 노출되고 있었다. 각 구역을 위임하는 네임서버 레코드의 60%만이 내부 구역의 네임서버 레코드와 매칭되는 것으로 조사됐다. 매칭되지 않는 레코드들은 리졸브(resolve)가 가능한 서버 수와 예비 서버를 감소시키며, 부하를 증가시키고 구역 정보를 DoS 공격에 노출시켰다. 특히 48%가 BIND의 보안 버전(9.x)을 사용하고 있는 것으로 조사됐다(BIND 사용 점유율 : 68%).


DNS 문제점
● 오픈 DNS

오픈(Open) DNS란 모든 인터넷 사용자들에게 재귀적 질의(recursive query)에 대해 응답을 해주는 DNS를 말한다. 이러한 오픈 DNS는 DDoS 공격 시 악용될 소지가 매우 높을 뿐 아니라 DDoS 공격 등에 악용될 소지가 있어 예방조치가 필요하다. DNS 서버 관리자들이 사전에 이러한 공격에 대비해 예방조치를 취할 경우 그 피해를 최소화시킬 수 있다.

● 불완전한 위임(Lame Delegation)
도메인 이름의 위임 불일치를 의미하며, 위임 불일치는 해당도메인에 대한 네임서비스의 불완전을 초래한다. BIND
8.2.x에서는 불완전한 위임에 대한 버그가 있어 잘못 설정됐더라도 네임서비스가 가능했으나 이후 버전에서는 수정된 상태다. 국내 ISP의 대부분이 네임서버 성능상 BIND 8.2.x를 사용하고 있으나 보안상으론 취약한 상태다.


● 낮은 버전 BIND 운영
전체 DNS 서버중 과거 하위 버전의 BIND를 운영하는 DNS 서버가 약 7% 정도를 차지한다. BIND 4와 8버전에서는 버퍼 오버플로우, 입력 쿼리 검증, 쿼리정보 누출 등의 취약점이 존재한다.
ISC(Internet Software Consortium)의 BIND 8버전에 대한 보안 및 시스템 업데이트 지원이 2007년 8월 27일부터 중단됨에 따라 향후 발생할 수 있는 보안 취약점에 대비하고, 시스템 성능 향상을 위해 BIND 9버전으로의 업그레이드를 권고하고 있다. BIND 9버전은 DNSSEC 기능이 추가되는 등 이전 버전보다 보안기능이 향상됐다.

DNS 보안 취약점에 대한 대응 지침
보안 연구 및 교육으로 유명한 SANS에서 해마다 미국 FBI에 제출하는 보안 취약성 보고서인 SANS 톱 20(www.sans.org/top20/) 보안 리스트는 현재 알려진 수많은 취약점 중 기본적인 보안 취약점에 대한 대응 지침서로, 현재 전 세계적으로 많은 기관에서 활용되고 있으며 보안 전문가들에게 좋은 기초 자료가 되고 있다.
2000년부터 매년 10월에 발표돼 정기적으로 업데이트 되고 있는 20개의 항목은 가장 큰 위협 요인이면서도 쉽게 발견되는 순서로 나열돼 있다. 2004년 발표된 버전 5.0에서는 유닉스/리눅스의 DNS 서버인 BIND가 취약점의 첫 번째로 꼽혔고, 지난해 발표된 BIND 버전 8.0까지도 DNS 서버의 취약점은 지속적으로 발표되고 있다.

● 위험여부 판별 방법
모든 인터넷 사용자는 DNS 질의에 대한 응답으로 부정확한 데이터를 받아올 위험이 있다. 따라서 DNS 서버를 스캔해 최신 버전인지, 패치가 설치돼 있는지를 확인해 보는 것이 좋다. 최신 버전이 아니거나 패치가 적용돼 있지 않는 DNS 서버일 경우 보안 위험에 노출될 확률이 매우 높다. SANS나 시큐니아 등이 제공하는 취약점 보고서 알림 서비스에 가입하거나 오픈 소스 취약점 데이터베이스(www.osvdb.org) 정보를 참조하는 것도 좋은 방법이다.


● DNS 취약점으로부터 보호법
어떤 소프트웨어 패키지든지 설치와 동시에 업데이트와 패치를 적용하고, 로컬 네트워크와의 충돌 여부를 체크한다. 다음은 DNS 취약점으로부터 보호하기 위한 방법이다.

- 모든 공급업체 패치를 적용하거나 DNS 서버를 최신 버전으로 업그레이드한다.
- DNS 설치 숙달에 관한 더 많은 정보를 위해 CERT의 유닉스 보안 체크리스트에 참조된 안전한 네임 서비스에 관한 기사를 예의주시한다.
- 인터넷으로 접속을 할 필요가 없는 내부 네트워크 DNS 서버에는 적절한 방화벽 룰을 적용한다.
- 서버가 DNS TSIG(Transaction Signatures)를 사용하도록 설정해 프라이머리와 세컨더리 DNS 서버 사이의 구역(Zone) 전송을 암호 방식으로 안전하게 한다.
- 유닉스의 경우 chroot() 디렉토리(jail)에서 권한 없는 사용자로 실행되도록 서비스를 제한해 DNS 서버가 장악된 경우 전체 시스템이 노출되지 않도록 한다.
- 재귀적(recursive) DNS 서버는 필요한 경우를 제외하고는 네트워크 차단 이외의 용도로 사용되지 못하도록 한다. 방화벽이나 DNS 설정 파일을 사용한다. 재귀(recursion)와 자동검색(glue fetching)을 비활성화하면 DNS 캐시 포이즈닝을 막는데 도움이 된다.
- 구역 전체에 DNS 보안 익스텐션(DNSSEC)을 사용한다.
- BIND를 실행하는 시스템에서 “named -v” 커맨드는 설치된 버전을 X.Y.Z로 나열해 보여준다. 이 중 X는 메이저 버전, Y는 마이너 버전, Z은 패치 레벨이다. 현재 2개의 메이저 BIND 버전은 8과 9다. 인터넷 시스템 컨소시엄은 모든 BIND 사용자들이 버전 9를 가능한 빨리 사용할 것을 권장하고 있다.
- DNS 서버에는 방화벽, 엔터프라이즈 네트워크 서버, 보안 어플라이언스 같은 많은 일반적인 제품들이 통합돼 있다. 해당 제품들과 임베디드된 DNS 소프트웨어들이 업데이트 됐는지, 공급 업체의 권고 사항에 따르고 있는지를 확인한다.
- DNS 처리를 지원하지 않는 서버(메일, 웹, 파일 서버 등)에는 반드시 필요한 경우를 제외하고는, DNS 서버 애플리케이션이나 데몬을 실행하지 않는다.


버전별 BIND DNS 취약점 발표 현황
만약 운영체제에 패키징된 BIND 버전을 사용한다면 벤더에서 제공하는 패치의 설치 유무를 확인해야 한다. ISC로부터 나온 소스로 구현된 BIND를 운영하고 있다면 최신 버전의 BIND인지 확인해야만 한다.
패치가 되지 않거나 오래된 버전의 BIND는 보안에 취약하다. ISC에서 제작 및 배포하는 BIND DNS의 보안 취약점을 해결하기 위해서는 최신 버전으로의 업그레이드가 반드시 필요하다. 가장 최신 버전에서도 지속적으로 보안상의 취약점이 발표되고 있다.


관련 표준(RFC) 목록표
DNS는 오랫동안 인터넷 상의 성공적인 네임체계로 자리해 왔다. 전 세계에 헤아릴 수 없이 많은 네임서버가 구축돼 있고 모든 호스트는 리졸버 루틴을 통해 인터넷 상에 존재하는 도메인 데이터베이스에 접근해 필요한 정보를 조회하고 있다. 그러나 이 지침서에서 미처 다 다룰 수 없는 상세한 DNS 프로토콜 및 구조에 대한 심층적인 파악과 참조가 가능하도록 관련 IETF 표준 목록을 정리했다.
DNS 관련 전체 RFC 문서는 상당한 수에 이른다. 여기에는 일반적으로 사용되지 않는 기능의 확장을 정의한 문서들을 제외한 문서를 중심으로 추려 정리했다. 또한 향후 사용이 일반화될 수 있는 기능에 대한 문서들과 DNS 운영상의 참고 문서와 DNS 개념 명확화를 위한 문서들을 포함했다.
지금까지 DNS의 중요성과 취약점 및 이에 대한 보안조치 사항들을 알아봤다. 다음 호에서는 DNS 서버의 취약점 진단과 구성 및 설정상의 베스트 프랙티스를 살펴본다.



■ 분산서비스거부(DDoS)
네트워크로 연결돼 있는 많은 수의 호스트들의 패킷을 범람시킬 수 있는 DoS 공격용 프로그램을 분산 설치해 이들이 서로 통합된 형태로 공격. 대상 시스템에 대해 성능 저하 및 시스템 마비를 일으킨다.

■ 재귀적 질의와 반복적 질의
질의 종류에는 재귀적 질의(recursive query)와 반복적 질의(iterative query) 두 가지가 있다. 재귀적 질의는 프로그래밍의 재귀 알고리즘처럼 네임서버가 원하는 대답을 받을 때까지 같은 작업(원격 네임 서버에게 질의를 한 후, 다른 곳을 참조하라는 응답을 받아 다시 다른 원격 네임 서버에게 질의를 하는 작업)을 되풀이 하도록 하는 질의를 말하고, 반복적 질의란 네임서버로 하여금 자신이 알고 있는 최적의 해답만 알려주도록 하는 질의로 질의를 받은 네임서버는 자신의 로컬 데이터를 뒤져 요청 받은 데이터를 찾고, 해답을 찾지 못하면 질문을 받은 도메인 네임에 가장 가까운 네임서버의 이름과 주소를 로컬 데이터 내에서 찾아 질의자에게 알려준다.


■ 불완전한 위임(Lame delegation)이란 네임스페이스(Namespace) 상에서 깨진 링크(Link)를 말한다. 예를 들어 example.co.kr이 두 개의 네임서버를 갖지만, 두 서버 중 하나 혹은 모두가 해당 도메인에 대한 권한(Authority)을 갖지 않는 경우, 즉 프라이머리(Primary), 세컨더리(Secondary) 등의 설정이 안 돼 있을 경우가 불완전한 위임에 해당된다.
■ TSIG란 트랜잭션 서명(transaction signature)을 이용해 DNS 메시지를 안전하게 하는 새로운 메커니즘을 일컫는 것인데, 이것을 간단히 TSIG라 한다. TSIG는 공유하는 비밀값(shared secret)과 단방향 해시(hash) 함수를 이용해 DNS 메시지(특히 응답과 업데이트)를 인증한다. TSIG는 현재 RFC 2845에 기술돼 있고 설정이 상대적으로 쉬우며, 리졸버나 네임서버가 이용하기에 충분할 만큼 가볍고, DNS 메시지(영역 전송 포함)와 동적 업데이트를 안전하게 만들기 충분할 만큼 유연하다.
■ DNSSEC(DNS Security Extensions)란 도메인 접속 정보의 위·변조를 방지하기 위해 네임서버 정보에 ‘공개키 기반구조(PKI)’를 이용해 서명·검증하는 보안 기술로, DNSSEC 기술을 적용할 경우 사용자가 인터넷 접속시 도메인 질의 후 받은 응답이 실제로 요청한 DNS 서버로부터 왔는지 중간에 위·변조 됐는지 여부를 검증할 수 있어 신뢰성 있는 인터넷 접속이 가능하다. DNSSEC은 DNS 보안 국제 표준 기술이다.
ⓒ 데이터넷(http://www.datanet.co.kr) 무단전재 및 재배포금지 | 저작권문의  

     

인기기사

 
가장 많이 본 기사
인사·동정·부음
전체기사의견(0)  
 
   * 200자까지 쓰실 수 있습니다. (현재 0 byte/최대 400byte)
   * 욕설등 인신공격성 글은 삭제 합니다. [운영원칙]
전체기사의견(0)
사명: (주)화산미디어 | 주소: 서울시 강남구 강남대로 124길 26 유성빌딩 2층 | 전화: 070-8282-6180 | 팩스: 02-3446-6170
등록번호: 서울아03408 | 등록년월일: 2014년 11월 4일 | 발행년월일: 2003년 12월 17일 | 사업자등록번호: 211-88-24920
발행인/편집인: 정용달 | 통신판매업신고: 서울강남-01549호 | 개인정보관리 및 청소년보호 책임자: 박하석
Copyright 2010 데이터넷. All rights reserved. mail to webmaster@datanet.co.kr