DNS 보안
도메인 이름에 무엇이 있겠느냐 할지 모르지만 데이터가 위험에 처해 있을 때는 사실상 여기에 모든 것이 다 들어 있다고 해도 과언이 아니다. DNS의 약점은 컴퓨팅 기능을 클라우드로 옮김으로써 공격에 대해 위험한 입장에 처할 수 있다는 것이다. SaaS(Software-as-a-Service) CRM 제품을 사용하고 있다고 가정해 보자. 영업사원이 당신의 SaaS 서비스 사업자 URL을 입력할 때 그의 브라우저가 벤더 서버에 연결돼 있음을 그리고 이것이 불량이 아니라는 사실을 어떻게 장담할 수 있겠는가?
컴캐스트(Comcast)의 인터넷 포털인 컴캐스트닷넷(Comcast.net)의 하이재킹 사건을 상기해 보자. 지난 5월 공격자들은 컴캐스트의 네트워크 솔루션 관리 계정으로의 액세스를 확보하고 고객을 감염된 페이지로 방향 전환시켰다. 회사에서 도메인 제어권을 되찾는 데는 몇 시간이 걸렸다. 공격자들이 조금만 더 영리했어도 이들은 단순히 당황하게 만드는 게 아니라 고객 데이터를 감염시킴으로써 컴캐스트에 막대한 경제적 손실을 가져다 줄 수 있었을 것이다.
보안문제 가장 큰 골치
20년 동안이나 인터넷 이름 분석 시스템의 근간을 이뤄 온 DNS의 보안은 IO액티브 연구원 댄 카민스키(Dan Kaminsky)가 도메인 이름 하이재킹을 불과 몇 분 만에 실행 가능한 사소한 공격으로 만들어 버릴 수 있는 결함을 발견해냄으로써 올해 들어 집중 조명을 받게 됐다.
이것이 실제로 얼마나 위험한지는 카민스키가 결함을 공유했던 16개 업체들에 의해 지난 7월 인터넷 역사에서 가장 대대적으로 동시 다발적인 보안 소프트웨어 패치가 나왔다는 사실로 미뤄 짐작할 수 있다. 시스코, MS, 썬 같은 주요 DNS 서버 제조업체들이 모두 같은 날 각자의 패치를 발표한 것이다.
DNS를 신뢰할 수 없다면 비즈니스 부문에서 인터넷을 통해 기간 업무 애플리케이션에 액세스할 수 있게 하거나, SaaS 사업자에게 전송되는 민감한 데이터가 인터셉트 당하지 않으리라 자신하는 것은 무리다. 이러한 생각은 독자들도 같이 공유하고 있는 것으로 드러났는데, 최근 본지에서 실시한 클라우드 컴퓨팅 설문조사 결과에 따르면 현재까지 보안은 가장 자주 언급되는 문제거리였다.
DNS에 처해진 보안 위험을 줄일 수 있는 해결책들 가운데 지금까지 나온 것들 중 최고는 DNSSec(DNS Security Extensions)으로, 이것은 DNS 이름 분석의 신빙성과 무결성을 보장하는 프로토콜 그룹이다. DNSSec은 완벽하지는 않지만 DNS 서버를 괴롭히고, 사용자를 공격자가 선택한 사이트로 방향 조정하는 많은 공격들을 중단시킬 수 있을 것이다.
현재 기업들은 민감한 데이터를 클라우드로 이동시킬 때 SSL에만 의존하고 있다. SSL은 전자 인증서를 이용해 서버를 인증하고 암호화를 제공한다. 전자 인증서가 검증이 되면 SSL 인증이 스푸핑(spoofing)에 대해 보호를 해줄 것이다. 하지만 공격자가 DNS를 건드려 예를 들어 citi.com을 찾는 모든 사람을 자신의 서버로 오게 방향 조정할 경우, 그는 로그인을 위해 SSL의 기능을 중지시킬 수 있으며, 사용자에게는 어떠한 에러 메시지도 가지 않을 것이다. 또 한 가지 문제는 인증서가 만기되거나 검증받지 못하거나, 도메인 이름이 맞지 않는 등의 SSL 오류가 단순한 불편함으로 취급되는 경우가 너무 많다는 것이다. 사실 개발자와 사용자는 SSL 증명서 경고를 무시하는 경향이 있다.
DNSSec의 역할은 공격자가 사용자를 속일 수 있는 지점에 도달하기 이전에 공격을 중단시키는 것이다. 이상적으로 볼 때 DNSSec는 적절한 사이트로 사용자가 접속되도록 보장해 줄 것이며, SSL은 서버를 인증하는 데 사용될 것이다. 그리고 실제로도 이를 위해 얼마간의 움직임이 보이고 있는데, 미 예산관리국에서는 2009년 12월을 모든 .gov 사이트에 DNSSec를 배치하는 최종 기한으로 정하고 1월부터는 .org 도메인에 단계별로 배치하도록 했다.
하지만 지금으로서는 이 정도가 전부다. 베리사인(VeriSign)의 경우 그 규모가 만만치 않다는 이유로 자신이 관리하고 있는 가장 인기 있는 두 도메인인 .com과 .net에 아직 이행을 하지 않고 있으며, 마이크로소프트는 클라이언트나 자체 DNS 서버에서 DNSSec 소프트웨어를 제공하는 날짜를 아직 정하지 않고 있다. 그리고 DNSSec 인지 DNS 서버를 배치한 서비스 사업자도 거의 없는 실정이다.
데이터 도난 가능성
“내가 원래부터 의도했던 서버와 통신을 하고 있다”는 믿음은 클라이언트/서버 모델에서 기본이라 할 수 있으며, 조직에서 SaaS와 클라우드 컴퓨팅으로 이동을 하기 시작하면 더더욱 중요해진다. 여기서는 도메인 이름이 일관되게 유지되는 동안 IP 주소가 바뀌기 때문이다.
직원들이 SaaS 사업자에게 데이터를 전송할 수 있게 할지를 고려하는 수석 보안 임원의 관점에서 볼 때 DNS 응답이 정확하고 권한이 있는 소스로부터 나오는 것인지를 보장할 수 있는 방법이 없다. 이러한 사각지대는 공격자가 애플리케이션을 도청하거나 대화를 조작하려면 먼저 신뢰하는 사용자로 하여금 자신들의 서버로 접속하도록 해야 한다는 점에서 이들에게 이득이 된다.
DNS 요청에 대해 응답을 만들어 낼 수 있는 DNS 스푸핑은 공격자가 DNS 이름 룩업(lookup)에 있는 서버의 실제 IP 주소를 자기가 제어하는 IP 주소로 바꿈으로써 사용자를 자기가 제어하는 서버로 방향조정할 수 있게 해준다. 좋은 소식은 인기 있는 웹 사이트의 DNS 하이재킹이 어떠한 일정 기간 동안에 성공하기가 힘들다는 것이다. 대형 클라우드 컴퓨팅 사업자와 같이 덩치가 큰 사이트가 하이재킹 당했을 경우 사용자는 수상쩍은 기미를 눈치챌 것이며, 다른 곳으로 방향조정을 해야 하는 횟수가 많기 때문에 진짜 사이트의 소유자에게 경보가 주어질 것이다.
마찬가지로 많은 사용자를 지원하는 캐싱 DNS 서버에 대한 공격도 오랫동안 숨겨지기 힘들다. 둘 중 어떤 경우든 그 부작용은 사용자 측 종단에서 접속이 느려지거나 단절되는 것이며, 타깃이 되는 SaaS나 클라우드 업체 사이트에서는 조사가 계속 이뤄지기 충분할 만큼 트래픽 양이 급격히 줄어들 것이다. 나아가 피셔(phisher)가 영어를 난도질하지 않을 수 없는 것처럼 대부분의 공격자는 큰 사이트를 확실하게 위조할 만큼의 능력을 갖고 있기 힘들다.
하지만 다만 한 시간이라 하더라도 바쁜 업무 시간에 고객의 데이터를 위조된 사이트로 옮기고 있는 직원 때문에 생길 수 있는 손실을 상상해 보라. 그리고 고도로 타깃화된 공격은 눈에 띄기가 더욱 힘들며 따라서 탐지하기도 더 힘들다. 불만을 품은 직원은 회사의 경계 안에서 프록시 서버를 통해 트래픽을 방향조정할 수 있으며, 이것은 전체 인터넷을 방향조정하는 것보다 훨씬 더 쉽다. 특히 공격자가 물리적으로 네트워크에 액세스할 수 있을 경우에는 더욱 그러하다.
모든 레벨의 DNS에서 새로운 프로세스 필요
DNS 시큐리티 익스텐션에는 공중 키 암호화를 이용해 레코드(record)에 서명 및 검증하는 데까지 DNS의 기능을 확장하는 표준 스위트가 포함돼 있다. SSL과 개념상으로 유사하게 DNS의 뿌리나 .com, .gov 및 .org 같은 탑 레벨의 도메인에 있는 트러스트 앵커(trust anchor)는 자신들의 영역에서 서명을 한다. 그런 다음에는 example.com, example. gov, 혹은 example.org 같은 서브도메인들이 자신들의 도메인에서 DNS 레코드에 서명을 한다.
서명은 레코드가 신뢰할 수 있는 영역에서 인증됐다는 사실을 나타낸다. DNSSec 인지 컴퓨터나 캐싱 네임 서버는 탑 레벨 도메인에서 시작해 당신이 관심 있는 도메인 이름까지 내려간다. 모든 레코드가 확인이 되면 검증된 DNS 이름을 갖게 된다. 이론상으로 보면 DNSSec은 꽤 단순해 보이지만 실제로 세부적으로 들어가면 매우 복잡하다. 현실적으로 말하자면 DNSSec을 배치하기 위해서는 모든 레벨의 DNS에서 새로운 프로세스가 필요하며, 이것은 도메인 관리의 모든 면면에 영향을 미친다.
예를 들어 도메인 이름 소유주가 등록기관에 의해 어떻게 검증되고 승인될지를 관리하는 정책 프레임워크가 지정되고 시행돼야만 DNSSec으로 보호 받는 도메인이 발급이 된다. 결국 소유주의 확실성을 인증할 수 없다면 도메인 이름에 서명을 하는 것은 아무런 소용이 없다. 프로세스는 SSL에서 사용되는 웹 서버 인증서를 발급하기 이전에 인증서 관리 기관에서 도메인 소유주를 검증하는 방식과 비슷할 필요가 있을 것이다. 그런 다음에는 키 관리를 해야 할 필요가 있는데, 이것은 언제나 흥미진진한 프로세스다. 다시 말해 철저한 조사 프로세스는 복잡하고 노동 집약적이며 많은 비용이 들어가는 일이다.
다양한 보안 서비스 |
시큐어64 DNS 사이너
DNSSec용으로 DNS를 구성하기는 쉬운 일이 아니지만 다행히도 여기서 도움을 받을 수 있는 업체가 하나는 있다. 지난 6월 시큐어64(Secure64)에서 시큐어64 DNS 사이너(Signer)를 발표한 것이다. DNS 사이너는 시큐어63의 OS를 돌리는 하드웨어 어플라이언스로 모든 DNSSec 키 관리 및 서명 기능을 관리하는 데 역점을 두고 있다. 이 어플라이언스는 HP 하드웨어에서 돌아가며, TCG(Trusted Computing Group)의 TPM(Trusted Platform Module)을 이용해 영역 키(zone key)를 보호한다. 설치는 기존의 DNS 인프라를 거의 변경할 필요가 없기 때문에 비교적 간단하며, 업체측에서는 키와 영역 관리 작업이 수월해진다는 이점을 강조하고 있다.
하지만 DNSSec이 작동할 수 있게 허용하기 위해서는 네트워크에 복잡한 변경이 요구될 수 있다. 예를 들어 DNS 트래픽을 점검하는 방화벽과 같은 네트워크 장비에 간섭하기 위해서는 DNSSec 레코드가 방해받지 않고 전달이 돼야 하지만, DNSSec 레코드는 512 바이트 이상이며 DNS 크기의 패킷에는 적합지 않다. 이것은 주로 DNS 프록시 서버에서 문제가 되는데, 여기서는 포트 쌍들이 패킷을 전달하는 방식을 주장할 뿐만 아니라 요구되는 프로토콜, 즉 DNS가 적합한지를 검증하려 한다.
DNS 서버와 DNS 스텁 리졸버(stub resolver: 이름을 IP 어드레스로 분석하는 책임을 맡고 있는 컴퓨터 소프트웨어) 또한 DNSSec 레코드를 지원하고 검증하도록, 그리고 동시에 서명되지 않은 DNS 응답을 수용하고 캐싱하도록 구성돼야 한다. 지금까지 마이크로소프프는 호스트 운영 시스템에서 DNSSec을 언제 지원할 것이라는 데 대해 아무런 언급도 하지 않고 있다. 마이크로소프트의 DNS 서버는 DNSSec 레코드를 캐싱할 수 있지만 이들을 검증하지는 않는다. DNSSec 인지 캐싱 서버와 스텁 리졸버가 없이는 DNSSec도 아무런 소용이 없다.
마지막으로 DNSSec이 그리 빠른 시일 내에 모든 도메인에 적용되지는 못할 것이다. 적용이 된다 하더라도 SSL이 모든 웹 사이트에 의해 사용되지 못하는 것과 마찬가지로 인증과 암호화가 필요한 도메인에서나 사용이 될 것이다. 그 결과 DNS를 사용하는 애플리케이션에게 요청된 도메인 이름이 검증이 되는지 되지 않는지를 말해 줄 수 있는 수단이 있어야 하게 됐는데, 이로 인해 만기된, 혹은 신뢰성 없는 응답 같은 오류가 발생했을 때 DNSSec 보호 이름 분석을 어떻게 처리할 것인가라는 새로운 고민거리가 대두되었다.
SSL을 이용해 웹 브라우저는 사람들에게 에러를 무시할 수 있는 옵션을 준다. 이러한 선택이 주어지면 대부분은 보통 잘못 이동을 해서 유효하지도 않고 따라서 신뢰할 수 없는 SSL 세션임에도 이것을 계속하곤 한다. 사용자에게 위험한 행동을 할 수 있는 기회를 주지 않으면서 이들이 원하는 대로 할 수 있게 해줄 다른 웹 브라우저를 찾아가도록 만드는 위험을 감수할 것인지, 애플리케이션 개발자들로서는 진퇴양난의 상황에 처해 있는 셈이다.
배치 현황
.org 도메인을 관리하고 있는 PIR(Public Interest Registry)은 지난 5월 2009년 초부터 .org 서명을 시작하고 제한된 도메인과 레지스트라에 단계적으로 DNSSec을 배치할 계획이라고 발표했다. 이렇듯 점진적으로 배치하는 이유는 DNSSec이 미지의 영역이기 때문이다. 현재까지 탑 레벨의 도메인으로서 이 프로토콜을 사용하기 시작한 곳은 멕시코, 푸에르토리코 및 스웨덴 등 몇 되지 않는 실정이다. 정리돼야 할 정책적 및 기술적인 문제들로는 필요한 소프트웨어에서부터 키 생성 및 관리, 그리고 도메인 소유주 조사 방식 결정 등 여러 가지가 있다. 한편 미 연방 정부의 DNSSec 프로젝트 또한 단계적으로 진행이 되고 있다.
루트 서버를 운영하고 .com과 .net 탑 레벨 도메인을 관리하고 있는 베리사인은 한층 더 신중하게 접근하고 있다. 이 회사는 DNSSec 표준 문서 개발에 참여하고 있으며 테스트 베드도 운영하고 있기 때문에 DNS 보안에 투자를 하고 있는 셈이다. 하지만 베리사인은 또한 자사에서 관리하는 탑 레벨 도메인과 루트 서버의 안정성과 가용성을 보장해야 하는 책임을 지고 있으며, 그 사업 규모는 만만치 않다.
베리사인의 CTO인 켄 실바는 .com에서 활동 중인 도메인이 7700만 개가 넘으며, com 서버가 받는 초당 질의 수는 60만 건이 넘는다고 밝혔다. DNSSec 레코드는 DNS 레코드보다 더 크기 때문에 새로운 부하를 처리하기 위해서는 그 스토리지와 네트워크 용량 또한 늘려야 할 것이다. 그리고 탑 레벨 도메인 서버에서의 용량 확장은 한 가지 문제에 불과하다. 모든 캐싱 네임 서버 또한 스토리지와 네트워크 용량을 확장해야 할 뿐만 아니라 자신들이 검색하고 전달하는 DNSSec 레코드를 검증하기 위해 암호 기능도 추가해야 한다.
도메인 소유주는 키를 관리하고 DNSSec 레코드가 적절히 서명되도록 관리할 필요가 있다. 만기된 DNSSec 키는 오류거나 신뢰할 수 없는 것으로 취급돼야 하는데, 이들은 결과적으로 호스트가 서비스에 액세스할 수 없게 만들기 때문이다. 도메인이 매출을 창출하고 있을 경우에는 DNSSec의 오류로 인해 큰 손실을 보게 될 수도 있다. 이러한 문제는 극복할 수 없는 것은 아니지만 베리사인은 DNSSec에 매우 신중한 태도로 접근하고 있는데 이것은 사실 이 회사로서는 당연한 일이기도 하다.
인증 수단
서비스를 확실하게 식별하기 위해서는 이것을 인증할 수단이 필요하다. SSL/TLS(Transport Layer Security)는 인증과 암호화 기능을 제공하는 데서 잘 알려져 있고 널리 쓰이고 있는 프로토콜이다. SSL 프로토콜은 어떠한 약점도 보이지 않고 있지만 SSL/TLS 라이브러리의 이행들 가운데 어떤 것들은 그렇지 못하다.
SSL/TLS가 경계선 밖으로의 데이터 이동을 보안하기에 효과적인 방법이 되기 위해서는 몇 가지 요소들이 충족돼야 하는데, 우선 이것은 SaaS나 클라우드 컴퓨팅 같은 웹 애플리케이션에 정확히 적용돼야 한다. 우리가 만나 본 수많은 개발자들은 웹 서비스, SOAP 및 REST를 사용하고 SSL/TLS를 배치한 애플리케이션들이 전자 인증서의 신빙성이나 유효성을 점검하지 않는 경우가 많다고 말했다.
그 이유는 보통 유효하지 못한, 혹은 신뢰할 수 없는 자가 서명 인증서로 인한 SSL/TLS 오류 때문에 생기는 다운타임이 막대한 손실을 가져다 주기 때문이다. 따라서 보통 웹 서비스에 액세스할 수 있는 사람을 제한하는 네트워크 방화벽이나, 웹 서비스 트래픽에 문제가 있는지 점검하는 XML 방화벽 같은 다른 보안 기능들로도 충분하다고 간주하고 있다.
하지만 우리 생각은 다르다. SSL/TLS를 하나의 보안 프로토콜로 안전하게 사용하기 위해서는 인증서의 유효성이 반드시 검증돼야 하며 오류가 있는 곳에서는 신뢰가 다시 수립될 수 있을 때까지 접속이 중지돼야 한다. 이것은 굳이 성가실 필요가 없다. 아직은 인증서가 신뢰성을 갖추도록 하기 위해 회사에서 굳이 공인 인증기관으로부터 전자 인증서를 구입하지 않아도 되기 때문이다. 클라이언트 수가 얼마 되지 않는 애플리케이션의 경우 자체 인증 기관을 운영해서 인증서를 발급하는 것만으로도 충분하다.
여기서 ‘아직은’이라고 표현한 것은 웹 서비스에 의존하는 IT 프로세스가 늘어남에 따라 더 이상 이 방법으로 지탱하기는 힘들어질 것이기 때문이다. 얼마 되지 않는 인터넷 보안의 역사를 보면 비천한 악당에서부터 조직화된 범죄자에 이르기까지 모든 공격자들은 자신들이 폭력을 행사할 수 있게 해주는 기술을 추종해 왔음을 알 수 있다. DNSSec이 널리 채택되려면 아직 몇 해 남았지만 SSL/TLS는 바로 지금 사용할 수 있다.
하지만 클라우드 및 SaaS 사업자들이 SSL/TLS를 적절히 사용하고 있다고 섣불리 가정해서는 안 된다. 민감한 데이터를 다루는 어떠한 애플리케이션이든 적절히 인증서를 사용하고 있고 서비스를 안전하게 인증할 것이라는 확인을 반드시 받아 두어야 한다.
DNSSec의 경우 CIO는 깐깐해질 필요가 있다. 운영 시스템 업체들에게 DNSSec 인지 소프트웨어를 이용해 DNSSec 응답을 인증하도록 압력을 가하기 시작하라. 애플리케이션 업체들에게는 예를 들어 웹 브라우저가 서명된 DNS 응답과 서명되지 않은 응답을 구분할 수 있도록 DNSSec을 지원하라고 주장하라. 서비스 사업자들에게는 자신들의 네임 서버에서DNSSec을 지원하라고 요구해야 한다.
다양한 테스트 사례를 참고하고 DNSSec이 그에 따라 진행이 되면 자체 DNSSec DNS 서버를 배치하고 자체 영역에 서명을 하는 것을 고려해 보라. 비보안 DNS는 인터넷을 사용하는 모든 사람에게 문제가 되며 우리는 반드시 그 해결을 위해 힘을 모아야 할 필요가 있다.
저작권자 © 데이터넷 무단전재 및 재배포 금지
