Akamai Diversity

Akamai 블로그

도메인 네임 보안: 첫 단계

dns.png

모든 인터넷 사용자와 디바이스는 도메인 네임 시스템(DNS)에 의존합니다. DNS는 최근 주요 공격 대상이었으며 2019년에도 다르지 않을 것입니다. 많은 공격의 목표가 기업의 인터넷 연결을 차단하는 것을 넘어서 더 심각한 피해를 주는 데 있습니다. 조직의 도메인 일부 또는 전부를 리디렉션하여 보안 자료에 접속하고, 트래픽을 가로채고, 해당 도메인에 대한 TLS 인증까지 차지하려는 공격도 보고됐습니다.  조직은 정기적으로 DNS를 검토하고 감사해야 합니다. 다음 가이드라인이 검토의 시작점이 될 것입니다.

 

> DNS를 공격하는 이유

DNS는 온라인 사이트를 가지고 있는 모든 조직에게 중요합니다. 도메인 네임 공격은 인터넷에 연결된 조직에 대한 DoS(Denial of Service) 공격, 사이트 변조, 도용 등 여러 방법으로 피해를 주기도 합니다. 도메인 네임은 브랜드 뿐만 아니라 고객이 기업과 상호작용하는 방법을 나타냅니다. 오늘날 도메인 네임은 웹, 음성, 동영상, 채팅, API, 그리고 기업이 제공하거나 소비할 수 있는 모든 서비스에 중요합니다. 한마디로 도메인 네임 관리는 비즈니스에 필수적입니다.

가장 간과되고 있는 DNS 위협은 바로 방치입니다. 많은 조직들이 DNS 설정을 당연하게 여기고 일단 설정한 후 방치해버립니다. 해커들은 이러한 방치와 그에 따른 약점을 이용합니다. 정기 DNS 검토와 감사는 중요한 예방 조치입니다.

 

> 시작하기

해커들은 DNS 루트 영역, DNS 레지스트리/최상위 도메인(TLD, 예: .com, .net, .uk, .jp), 도메인 네임 레지스트라, DNS 네임 레지스트런트(영역이 위임된 엔터티), DNS 영역 파일, 권한 DNS 네임서버, 리커시브 DNS 리졸버를 통해 DNS 아키텍처를 공격할 수 있습니다. 해커들은 또한 DNS 서버로 가는 경로를 하이재킹하거나 IP 주소를 스푸핑할 수 있습니다. 보시는 것처럼 이는 매우 넓은 공격면입니다. 다행스럽게도 DNS는 견고하게 구축되어 있으며 DNS 보안, 안정성, 복원력에 집중하는 조직이 많이 있습니다.

먼저 주목해야 할 분야는 DNS 영역 관리입니다(예: example.com). DNS 영역 관리는 많은 조직들이 보안 및 네트워크 감사 시 신경을 쓰지 않는 부분입니다. 공격 범위와 잠재적 피해를 과소 평가하면 안 됩니다. 영역 및/또는 레지스트라에 대한 권한을 확보하면 수신 이메일을 다른 곳으로 발송하고, 해커가 제어하는 호스트를 통해 트래픽을 전환하고, TLS 인증도 확보할 수 있습니다.

 
dns2.png

 

도메인 네임 레지스트라 및 DNS 영역 파일

도메인 네임 레지스트라는 무엇보다도 권한 도메인 네임서버, 즉 '위임(delegations)' 목록을 관리합니다. 이러한 위임은 해당 도메인에 대해 권한을 가진 DNS 서버의 호스트네임과 IP 주소로 이루어져 있습니다. 권한 DNS 서버는 마스터 영역 파일 사본을 갖고 있으며 '권한 응답' 비트 세트로 DNS 쿼리에 응답합니다. 최근 대규모 해킹이 증가하면서 도메인 소유자의 권한 네임서버 운영 방법이 바뀌었습니다. 기존에는 대부분의 조직이 권한 네임서버를 자체 시스템 상에서 운영했습니다. 지금은 선택할 수 있는 옵션이 더 많습니다. 일부 도메인 네임 레지스트라는 레지스트라가 도메인의 모든 DNS 설정을 운영하고 유지하는 풀서비스 패키지를 제공합니다. 예를 들어 Akamai의 Fast DNS 같은 클라우드 기반 제공업체는 DDoS 공격에 대해 강력한 안정성을 제공하며 인프라 관리를 간소화합니다.

 

> DNS 검토 및 감사

뉴스 기사, 컴퓨터 비상사태 대응팀(CERT), 정부는 'DNS 감사'를 적극 권장하지만 대부분 권고에서 끝나는 경우가 많습니다. 이번 게시물의 나머지 내용은 조직이 DNS 현황을 평가하기 위해 검토해야 하는 주요 영역을 소개합니다. Akamai의 경험, ICANN의 SSAC(Security and Stability Advisory Committee), DNS-OARC(DNS Operations, Analysis, and Research Center), 기타 DNS 전문가의 자료를 바탕으로 권장 사항을 제시합니다.

 

Domain 네임 레지스트라 접속 검토

도메인 관리자는 레지스트라를 검토하고 레지스트라가 조직의 기대에 부합하는지 확인해야 합니다. 레지스트라에 설정된 모든 도메인을 검토하고 조직에서 누가 레지스트라의 온라인 포털에 대한 접속 권한을 갖고 있는지 확인해야 합니다. 해당 사용자에게 레지스트라의 온라인 포털에 대한 접속 권한이 있는지 확인하고 도메인이 여러 레지스트라에 등록된 경우 모든 레지스트라에 대해 이를 확인해야 합니다. 도메인 등록을 하나의 레지스트라로 통합하는 것이 좋을 수도 있습니다. 또한 레지스트라 감사 시 모든 도메인을 점검했는지 확인해야 합니다. 누군가 개인 계정을 사용하여 도메인을 등록한 경우 해당 사용자가 퇴사하면 도메인을 관리할 수 없게 됩니다.

해커는 조직의 DNS 약점을 노립니다. 해커들은 제대로 관리되지 않는 계정을 찾아 공격합니다. 각 레지스트라의 각 영역에 대해 접속 권한을 가진 사용자를 검토하고, 업데이트하고, 기록하는 것이 첫 단계입니다.

 

DNS 역할 및 책임 검토

모범 보안 가이드라인으로 최소 접속 원칙을 지켜야 합니다. 사용자는 업무에 반드시 필요한 최소 수준의 접속 권한만 갖고 있어야 합니다. 사용자의 레지스트라 접속이 업무를 수행하는 데 필요한 접속입니까? 일회성 검토와 더불어 모든 사용자의 접속 레벨을 정기적으로 검토해야 합니다. 또한 레지스트라 포털별로 최소 2명에게 접속 권한을 부여해야 합니다. 관리자 1명이 운영하다가 해당 관리자가 퇴사하면 막대한 피해가 발생할 수 있습니다.

해커들은 종종 소셜 미디어를 활용하여 피싱을 시도합니다. 해커들은 유명한 직원이 구조 조정, 해고 또는 퇴사한 후 레지스트라 권한을 삭제하는 것을 잊을 수도 있다는 것을 알고 소셜 미디어 플랫폼상에서 이들을 손쉽게 목표로 삼습니다.

 

직원 이동

조직의 사전 종료 프로세스에는 사용자 역할 검토가 포함돼야 합니다. 검토 중 조직은 레지스트라 계정이나 DNS 클라우드 사업자에 대한 직원의 접속을 감사하고 모든 접속을 취소할 수 있어야 합니다. 접속 권한을 최대한 빨리 교체하거나 후임 직원에게 부여해야 합니다.

또한, 퇴사하는 직원이 접속 권한을 갖고 있던 모든 기밀을 전환하거나 폐지해야 합니다. 이 작업은 비밀번호와 더불어 이중 인증(2FA) 토큰, 음성 비밀번호, 레지스트라가 파일에 보관할 수 있는 권한 있는 직원 목록에도 실시해야 합니다. 퇴사하는 직원의 상황에 관계없이 이러한 변경 프로세스를 기본으로 실시해야 합니다. 이런 작업은 퇴사하는 직원의 평판을 떨어뜨리는 것이 아니라 조직에 대한 위협을 방어하는 것입니다.

 

모든 등록 정보 업데이트

다음으로 등록 도메인 네임과 연계된 담당자 정보를 검토해야 합니다. 도메인 네임별 만료일이 충분히 길어야 하며(최소한 1년 권장) 자동 갱신 같은 옵션을 적절히 설정해야 합니다. 도메인 네임이 예상치 못하게 소멸되면 심각한 비용이 발생할 수 있으며 최악의 경우 회복할 수 없는 피해를 입거나 경쟁사에게 도메인 네임을 뺏길 수도 있습니다.

도메인은 일반적으로 등록, 기술, 관리, 청구 등의 네 가지 담당자로 구성됩니다. 레지스트라는 이들 역할 중 하나에게만 특정 유형의 정보를 보낼 수 있으며 일부 논란이 있지만 일반적으로 등록 담당자가 우선합니다. 모든 담당자 정보를 최신 상태로 유지해야 합니다. 조직이 성장하거나, 축소하거나, 이동하거나, 인수되는 경우 종종 담당자 업데이트가 간과됩니다.

 

도메인 등록 정보에 대한 업무

도메인 등록 담당자 정보를 수월하게 관리하기 위해 조직은 종종 4가지 도메인 담당자에 1개의 업무 계정을 사용합니다. 업무 계정은 조직마다 다르게 사용하지만 기본적으로 모든 도메인 등록 메시지를 수신할 수 있는 메일링 목록을 엄격하게 설정하는 것입니다. 이 업무는 종종 조직 본사 담당자의 주소, 전화, 팩스 번호를 포함하여 '도메인 관리자' 또는 '호스트 마스터'로 불립니다. 해당 번호에 대한 합법적인 전화 통화와 팩스만 DNS 관리자에게 연결되게 해야 합니다. 직원을 지정하는 것이 아니라 업무를 사용하면 레지스트라를 대대적으로 업데이트하지 않고 직무 책임을 변경하거나 담당자를 추가 및 제거할 수 있습니다. 메일링 목록을 사용하는 경우 정기 감사 중 메일링 목록에 가입된 직원을 검토하여 잠재적인 오용을 제한해야 합니다.


개인 이메일 주소 사용 금지

기업, 정부 또는 조직 도메인 관리자의 연락처로 개인 이메일 주소를 절대 사용하면 안 됩니다. 검토 프로세스 중 도메인 담당자 정보나 레지스트라 권한 계정에 개인 이메일 주소가 사용됐는지 반드시 확인해야 합니다.

  • 직원의 개인 이메일 주소(예: joe@gmail.com)를 담당자 정보로 사용하는 것은 사실상 도메인의 통제권을 해당 직원에게 넘겨주는 것입니다. 직원이 개인 이메일 계정에 어떠한 보안 조치를 사용하는지 모르는 것은 물론 불만이 있는 현직 또는 전 직원으로부터 보복을 당할 수도 있습니다. 모든 도메인 담당자 정보는 조직 또는 상위 조직이 관리하는 이메일 주소를 포함해야 합니다.

  • 직원이 조직이나 기업 이메일 주소(예: jane.q.smith@examplecompany.com)를 사용하는 것도 피해야 합니다. 기업 도메인 네임을 관리하는 직원의 이름을 제공하면 해당 직원이 기업을 노린 소셜 엔지니어링 및 스피어피싱 공격 위험에 노출될 가능성이 높아집니다. 대신 업무 또는 부서 기반 이름(예: hostmaster-technical@example.com, hostmaster-billing@example.com)을 사용하는 것이 좋으며 해당 주소로 발송된 메시지가 여러 사용자에게 전달되는 것이 이상적입니다.
     

피싱 공격 방어

피싱은 레지스트라 계정을 해킹하는 데 주로 사용되는 방법 중 하나입니다. DNS 관리자에 대한 피싱 공격을 예상하고 종합적인 피싱 방어를 준비해야 합니다. 다음과 같은 피싱 대응 기법으로 피싱 공격을 효과적으로 막아낼 수 있습니다.

  • domain_admin@example.com처럼 일반적인 업무 또는 부서 기반 이메일 주소를 사용해야 합니다. 업무 기반 계정에 수신된 피싱 이메일은 관리자가 발견하기 쉽습니다.

  • 연간 보안 검토에 피싱 예방 교육을 포함하고 모든 DNS 관리자가 교육을 이수해야 합니다.

  • 엔드포인트 보안 소프트웨어를 배포하고 DNS 관리자(조직 내 전 직원 포함)가 사용하는 모든 디바이스에 보안 정책을 실행해야 합니다.

  • DNS 관리자와 다른 직원들에 대한 일반적인 피싱 및 멀웨어 공격을 예방하기 위해 이메일 필터링 서비스를 배포해야 합니다.

  • DNS 쿼리를 필터링하여 직원이 알려진 피싱 사이트를 방문하지 못하게 막아야 합니다. Akamai의 Enterprise Threat Protector(ETP)는 DNS 기반의 보안 솔루션입니다.

피싱 공격을 막는 완벽한 방법은 없지만 조직에 올바른 방어 기법을 도입하면 리스크를 줄이는 데 도움이 됩니다.

 

인증정보 업데이트 - 비밀번호 변경

정기적인 비밀번호 변경은 모든 온라인 계정에 효과적이며 도메인 네임 레지스트라 계정도 예외는 아닙니다. DNS 인프라를 감사할 때 레지스트라 권한을 가진 사용자는 모두 인증정보를 교체해야 합니다. 조직에 종합적인 비밀번호 정책이 있더라도 레지스트라 같은 외부 서비스를 간과하기 쉽습니다. 외부 계정은 내부 비밀번호 보안 가이드라인과 교체 일정에 따라야 합니다. 레지스트라 비밀번호는 길고 복잡해야 합니다. 비밀번호 관리자를 사용하면 암호화되고 이중화되며 검색할 수 있는 방법으로 복잡한 비밀번호를 편리하게 생성하고 저장할 수 있습니다. 비밀번호를 암호화되지 않은 형태로 적거나 보관해서는 절대 안 됩니다.

 

레지스트라 계정의 이중 인증(2FA)

레지스트라가 지원하는 경우 모든 계정에 이중 인증(2FA)을 사용해야 합니다. 2FA를 사용하면 레지스트라에 로그인할 때 계정 비밀번호뿐만 아니라 스마트폰 애플리케이션이나 하드웨어 토큰 같은 추가 요소를 사용해야 합니다. 2FA는 피싱 시도를 막을 수 있습니다.

가능하면 SMS 기반 2FA는 피해야 합니다. SMS 기반 2FA는 비밀번호만 사용하는 것보다는 안전하지만 시간 기반 일회용 비밀번호(TOTP), 하드웨어 토큰 또는 푸시 기반 2FA 같은 다른 방법을 권장합니다. NIST의 새로운 디지털 ID 가이드라인은 2FA에 SMS를 사용하지 말라고 권장하고 있습니다(NIST 특별호 800-63B 참조).

레지스트라가 2FA를 지원하지 않는 경우 이 기능을 요청하시기 바랍니다. 이러한 요청에 레지스트라가 긍정적으로 대응하지 않는다면 다른 레지스트라를 알아봐야 합니다. 많은 경우 동일한 TLD, ccTLD, gTLD에 대해 다양한 도메인 레지스트라가 있습니다.

 

레지스트라 보안 정책, 툴, 프로세스의 이해

전 세계에서 수백 개의 도메인 네임 레지스트라가 1500여 개의 TLD를 지원하고 있습니다. 이 중에도 보안이 더 뛰어난 레지스트라가 있습니다. 여러분의 조직에서 레지스트라 업계의 보안 관행을 개선하는 데 도움을 줄 수 있습니다. 레지스트라의 온라인 문서를 검토하여 보안 관행과 정책을 파악하시기 바랍니다. 이런 정보를 찾을 수 없으면 레지스트라에게 해당 정보를 발행해달라고 요청하시기 바랍니다.

예들 들어 레지스트라가 도메인을 운영하는 데 필요한 지원 서비스를 제공합니까? 레지스트라가 휴일에도 문제를 해결할 수 있는 상시 기술 지원을 제공합니까? ICANN 정책에 따라 현재 레지스트라는 레지스트리로부터 받은 도메인 이동 요청을 등록자에게 통보하여 다른 등록자가 도메인을 새로운 레지스트라로 이동해달라고 요청했다는 것을 알려야 합니다. 레지스트라가 이러한 정보를 이메일로만 보냅니까, 아니면 전화나 팩스를 통해 이러한 정보를 요청할 수 있습니까? 레지스트라가 모든 도메인 업데이트를 공지합니까? ICANN의 SSAC(Security and Stability Advisory Committee)는 ICANN 커뮤니티와 협력하여 DNS 운영 및 보안 지침을 제공합니다. ICANN의 SAC 40 악용 또는 오용으로부터 도메인 등록 서비스를 보호하기 위한 조치SAC 44 도메인 네임 등록 계정을 보호하기 위한 등록자 가이드는 레지스트라의 보안 관행을 이해하고 평가하는 데 있어서 훌륭한 지침입니다.

 

개인정보 등록 옵션 검토

많은 도메인 네임 레지스트라는 개인정보 또는 프록시 등록 서비스를 제공합니다. 이들 서비스는 개인 연락처 정보를 숨기고 ICANN 준수 연락처 정보로 교체합니다. 유럽 연합(EU)의 개인정보보호법(GDPR)은 WHOIS 같은 도메인 등록 데이터베이스의 정보 공개 방식을 변경했습니다. GDPR을 준수하려면 원칙적으로 도메인 등록자 정보에 업무 기반 접근법을 사용하고 도메인에서 커뮤니티에 최신 연락처 정보를 제공해야 합니다.

참고: 프록시나 개인정보 등록이 조직 유효성 확인(OV) 및 확장 유효성 확인(EV) SSL/TLS 인증을 확보하는 데 필요한 검증 프로세스를 방해하는 경우가 일부 있습니다. 프록시나 개인정보 등록을 사용하거나 사용하지 않게 하는 프로세스는 레지스트라마다 다를 수 있으며 이러한 서비스에 가입하기 전에 일정을 확실히 이해해야 합니다. 개인정보 등록을 늦게 해제하면 인증 교체나 도메인 이전이 필요한 경우 인증 교체를 하지 못하거나 도메인 이전에 지연이 발생할 수 있습니다. 이러한 리스크는 신중히 고려해야 합니다.

 

영역 내 기록 검토 및 유지

DNS 영역에는 여러 호스트네임서브도메인이 있지만 대다수의 DNS 관리자는 해당 호스트네임이나 서브도메인을 담당하는 부서나 사업부를 모를 수 있습니다. 호스트네임은 A, AAAA, CNAME, TXT 등이 포함된 레코드입니다. 서브도메인은 NS 레코드로 표시되며 영역의 해당 부분에 대한 제어를 다른 네임서버의 영역으로 위임합니다.

DNS 관리자는 조직의 영역 파일에서 개별 엔트리를 담당하는 그룹이나 팀을 알아야 합니다. 조직이 내부 티켓 추적 시스템을 사용하는 경우 그곳에 정보가 저장될 수 있지만 즉시 사용이 쉽지 않을 수 있습니다. 시간에 따른 영역의 변경 사항을 정확히 추적하려면 내부 프로세스를 업데이트해야 할 수 있습니다. 영역 파일의 엔트리별 담당 부서를 확인할 수 있다면 정기적으로 검토하고 레코드가 계속 필요한지 확인해야 합니다. 정상적인 DNS 감사 시 호스트네임과 서브도메인별 담당자를 확인하고 불필요한 엔트리를 삭제해야 합니다.

레코드는 새로운 애플리케이션, 서비스 또는 라이브 데모를 위해 간편하게 추가될 수 있으나 해당 서비스가 중단되거나 이전된 후에도 오랫동안 유지될 수 있습니다. 내부 제품 수명 주기의 일환으로 서비스 중단과 중단 프로세스가 DNS 관리자에게 호스트네임 또는 서브도메인이 더 이상 필요하지 않다는 것을 알리는지 충분히 주의해야 합니다.

위임된 서브도메인은 영역 일부에 대한 제어를 다른 네임서버에게 양도하기 때문에 위임된 서브도메인에 각별히 주의해야 합니다. NS 레코드가 정확하고 여전히 서브도메인의 권한 응답에 사용되는지 확인해야 합니다. 조직이 서브도메인을 써드파티 DNS 제공업체에게 위임하는 경우 해당 업체가 조직에게 알리지 않고 IP 주소의 목적을 변경할 수 있기 때문에 위임된 서브도메인의 응답을 더욱 철저히 확인해야 합니다. 영역이 써드파티 클라우드 제공업체에서 조직이 운영하는 네임서버로 위임된 경우 IP 주소 변경을 추적하고 그에 따라 영역 위임을 업데이트해야 합니다. 퍼블릭 클라우드는 IP 주소를 신속히 재사용하는 경향이 있기 때문에 NS 레코드와 관련 IP 주소를 감사하지 못하면 영역을 뺏길 수 있습니다.

 

네임서버 및 영역 파일 모범 사례

DNS 감사 시 '기본' 및 '보조' 네임서버를 비롯하여 관리 대상인 모든 네임서버의 모든 사용자 계정을 검토해야 합니다. 네임서버 접속 권한을 가진 사용자는 영역 파일을 직접 변경하거나 시스템에서 작동하는 소프트웨어를 변경할 수 있습니다. 악용 또는 설정 오류로 계정이 있는 사용자 모두가 영역 파일이나 서버 구성 유틸리티에 대한 권한을 가질 수 있기 때문에 운영 체제의 파일 시스템 권한이나 접속 수준 보호에만 의존하면 안 됩니다. 접속 로그를 유지하여 서버에 로그인한 사용자를 추적해야 하며, 접속 제어와 책임은 DNS 인프라의 모든 부분에 중요합니다. 이것은 '기본' 네임서버에 영역 파일의 정식 사본이 있고 정기적으로 또는 요청에 따라 '보조' 네임서버가 기본 네임서버에서 정규 사본을 전송하는 기본-보조 모델에서 특히 중요합니다.

 

DNS 영역 파일 수정 관리

영역 파일 관리 또한 감사하여 적절한 변경 관리 프로세스가 존재하고 실행되는지 확인해야 합니다. 영역 파일의 마스터 사본을 수정 제어 시스템이나 다른 접속 제어 스토리지에 저장해야 합니다. 변경 요청이 있으면 DNS 관리자는 최신 영역 파일을 만들고, 검토 프로세스를 거치고, 오류가 있는지 확인한 후에만 새 사본을 생산합니다. 업데이트로 예상치 못한 결과가 발생할 경우를 대비하여 정기적으로 테스트하고 실행하기 쉬운 절차를 마련하고 영역을 마지막으로 알려진 양호한 상태로 되돌려야 합니다. 이때 수정 관리 시스템이 도움을 줄 수 있습니다. DNS 인프라 감사 시, 영역 파일을 유지하는 데 사용되는 수정 관리 시스템에 대해 편집 권한을 가진 계정도 정기적으로 검토해야 합니다.

모든 중요 데이터와 마찬가지로 영역 파일과 변경 로그를 안전한 별도 백업 사이트에 정기적으로 백업해야 합니다. 수정 관리와 더불어 신뢰할 수 있는 백업으로 재해 복구용 '마지막으로 알려진 양호한' 버전의 파일을 만들어야 합니다.

영역 파일의 마스터 사본이 클라우드 DNS 제공업체에 있는 경우 영역 기록을 편집할 수 있는 권한을 가진 모든 계정을 레지스트라 계정에 적용하는 것과 같은 강력한 보안 관행에 따라 관리해야 합니다. 클라우드 제공업체를 사용하는 경우에도 재해 복구에 사용할 영역 파일을 정기적으로 백업해야 합니다. Akamai의 Fast DNS는 세분화된 접속 제어, 이중 인증, 백업 또는 감사용 영역 사본을 손쉽게 다운로드할 수 있는 기능을 제공합니다.

 

레지스트라의 도메인 잠금 여부

도메인 잠금은 도메인 등록의 비인가 변경을 예방하는 방법입니다. 대부분의 도메인 네임 레지스트라는 등록하는 도메인에 대해 클라이언트 잠금으로도 알려진 레지스트라 잠금을 제공합니다. 레지스트라에게 이 서비스를 제공하는지 문의하시기 바랍니다. 가능하면 도메인을 잠그십시오. 모든 도메인은 적어도 클라이언트 갱신 잠금을 제외하고 클라이언트 삭제, 클라이언트 업데이트, 클라이언트 전송 잠금을 설정해야 합니다. 일부 레지스트라는 종종 세 가지 권장 잠금을 설정하는 포털에서 잠금 옵션 하나만 제공합니다. 어러한 잠금은 해커가 도메인을 잠금 해제하지 않고 도메인 등록을 삭제하는 것은 물론 도메인의 비인가 변경이나 전송을 막습니다. 갱신 잠금을 설정하지 않음으로써 도메인을 갱신하거나 레지스트라가 제공하는 경우 자동 갱신 기능을 활용할 수 있습니다. 많은 레지스트라는 레지스트라 잠금이나 클라이언트 잠금을 도메인에 추가하는 데 비용을 부과하지 않습니다. 일부 레지스트라는 등록자에게 아무것도 요구하지 않고 기본적으로 도메인을 잠그기도 합니다.

 

클라이언트/레지스트라 잠금과 더불어 일부 gTLD 또는 ccTLD 운영업체는 레지스트리 잠금으로도 알려진 서버 잠금 서비스를 제공합니다. 서버 잠금은 도메인 업데이트에 보안 레이어를 추가하며 종종 동록자가 전화로 레지스트리 운영업체에게 합의된 'out-of-band' 프로세스를 요청한 경우에만 추가하거나 제거할 수 있습니다. 클라이언트 잠금과 마찬가지로 서버 잠금은 서버 갱신을 제외하고 서버 삭제, 서버 업데이트, 서버 전송 잠금을 추천하며 이유는 앞에서 설명한 것과 같습니다. 레지스트리/TLD 운영업체 중에는 이 서비스를 제공하지 않는 업체도 있습니다. 서버 또는 레지스트리 잠금 서비스를 사용하는 경우 종종 추가 비용이 발생하며 추가 등록자/레지스트라 상호 작용이 일어납니다.

 

서버/레지스트리 잠금을 추가하거나 제거하면 등록 담당자 연락처 정보 업데이트, 위임 기록 업데이트, 도메인 이전 또는 도메인 삭제 등 도메인의 변경 발생 시 최대 일주일까지 지연이 발생할 수 있습니다. 예를 들어 레지스트라 사이에 도메인을 전송하는 경우 전송 프로세스를 시작하려면 도메인을 잠금 해제해야 합니다.

도메인을 변경할 때 WHOIS를 사용하여 잠금이 예상대로 적용되는지 확인해야 합니다. WHOIS 정보를 문의하려면 ICANN의 WHOIS 페이지, 컴퓨터의 터미널을 통한 WHOIS 명령 또는 레지스트라 웹사이트의 WHOIS 페이지를 사용할 수 있습니다. 다음 예는 클라이언트/레지스트라 잠금 적용 시 어떻게 나타나는지 보여줍니다. 

Illustration 1.png

마찬가지로 클라이언트/레지스트라와 서버/레지스트리 잠금에 대해 WHOIS를 확인하는 경우 WHOIS 쿼리에 대해 다음과 같은 응답을 받아야 합니다.

Illustration 2.png

 

유비무환

도메인 네임 레지스트라가 해킹당하고 DNS 관리자 계정이 탈취당했다고 생각해보세요. 이런 문제가 일어날 때까지 기다리면 안 됩니다. DNS를 검토하고 감사를 진행하면서 미리 대비를 해야 합니다. 레지스트라에게 도메인 해킹 시 복구 프로세스를 문의하시기 바랍니다. 레지스트라는 적절한 문서 준비 프로세스를 통해 안내해야 합니다. ICANN의 SAC044는 레지스트라에서 도메인이 해킹당하는 최악의 시나리오에 대해 다음과 같은 문서를 확보하라고 권장합니다.

  • 도메인 등록 기록의 사본(예: 타임스탬프가 있는 WHOIS 조회, 스크린샷 또는 레지스트라의 포털에서 가져온 타임스탬프가 포함된 파일)

  • 결제가 완료됐음을 보여주는 청구 기록

  • 합법적인 등록자가 발행한 콘텐츠와 도메인 네임을 연결하는 로그, 아카이브 또는 금융 거래 내역

  • 등록자와 도메인 네임을 연결하는 광고를 포함한 전화번호부(Yellow Pages), 마케팅 자료 등

  • 레지스트라와 ICANN이 등록자에게 보낸 도메인 네임이 언급된 메시지

  • 등록자와 도메인 네임을 연결하는 법적 문서, 세금 신고서, 정부 발행 ID, 영업세 공지 등

이 목록은 ICANN Board가 임명한 보안 전문가 집단 ICANN SSAC가 제공합니다. 조직은 레지스트라가 탈취된 도메인을 복구하며 힘들게 쌓은 경험을 활용해야 합니다.

 

> 다음 단계

이 가이드는 DNS 검토와 감사의 시작에 불과합니다.  앞으로 DNSSEC, 권한 DNS 인프라, DNS 리소스의 BGP 하이재킹, 안전한 DNS 리졸버, 다양한 DNS 위협을 다룰 예정입니다. Akamai의 블로그Akamai 커뮤니티의 새로운 기사에 주목해주세요.

 

> DNS 검토 및 감사를 위한 추가 참조 가이드

다음은 조직이 검토 툴을 구축하는 데 도움을 주는 추가 리소스와 참조 문서입니다.

 

> 감사의 말

이 문서를 작성하는 데 도움을 준 "Akamai DNS팀"과 Akamai의 다른 동료들에게 감사의 뜻을 전합니다. 한스 캐스카트(Hans Cathcart), 팀 에이프릴(Tim April), 존 리드(Jon Reed), 고든 막스(Gordon Marx), 브루스 반 니스(Bruce Van Nice), 마티어스 쾨버(Mathias Koerber), 로리 휴위트(Rory Hewitt), 제임스 캐시(James Casey), 배리 그린(Barry Greene) 등 많은 분들로부터 도움을 받았습니다.

Leave a comment (코멘트 남기기)