도메인 탈취 예방과 대응

도메인 탈취는 도메인 자체를 공격해서 일어나지 않습니다. 거의 모든 사례가 등록기관 관리 계정이나 등록자 이메일 계정이 먼저 뚫리면서 시작되고, 그다음 네임서버나 DNS 레코드를 바꾸거나 다른 등록기관으로 이전을 신청하는 순서로 진행됩니다. 따라서 예방의 핵심은 도메인 설정이 아니라 그 도메인을 조작할 수 있는 두 개의 계정을 지키는 일입니다.

탈취가 성공하면 웹사이트 트래픽, 수신 메일, 도메인 인증으로 연결된 외부 서비스가 동시에 넘어갑니다. 복구는 가능하지만 시간이 걸리고, 그 사이의 피해는 되돌리기 어렵습니다. 아래에서 침입 경로, 예방 설정, 발견 시 조치 순서를 정리합니다.

주요 침입 경로

관리 계정 탈취, 등록자 이메일 탈취, 소셜 엔지니어링

최소 예방 세트

계정 2단계 인증 + 도메인 잠금 + 등록자 메일 보호

발견 시 1순위

두 계정의 비밀번호 변경과 전체 세션 로그아웃

레토에 없는 기능

DNS·네임서버 변경 알림, 레지스트리 잠금

탈취는 어디로 들어오는가

경로를 알면 어디를 막아야 하는지가 정해집니다. 실제 사례는 대체로 다음 다섯 가지입니다.

네 번째 경로는 공격이라기보다 관리 실패입니다. 그런데도 결과는 가장 무겁습니다. 만료된 도메인을 제3자가 정상적으로 등록해 버리면 되돌릴 근거를 만들기가 어렵기 때문입니다. 만료 쪽 예방은 도메인 만료 사고 예방에 따로 정리했습니다.

예방 1. 두 개의 계정을 지킵니다

관리 계정과 등록자 이메일 계정은 한 묶음으로 다뤄야 합니다. 한쪽만 강하게 막아도 다른 쪽을 통해 돌아 들어올 수 있습니다.

• 등록기관 관리 계정에 2단계 인증을 켜고, 비밀번호는 다른 서비스와 공유하지 않기
• 등록자 이메일 계정에도 같은 수준의 2단계 인증을 적용 (여기가 가장 자주 빠집니다)
• 2단계 인증 수단은 최소 두 개 등록하고 복구 코드를 계정과 분리된 곳에 보관
• 관리 계정 접근 권한자를 명단으로 관리하고 퇴사 시 즉시 회수
• 관리 계정 로그인은 개인 메일이 아닌 공용 주소 기준으로 두기
• 로그인 알림이 온다면 실제로 읽는 사람이 있게 두기

레토 계정의 2단계 인증은 Feather IT SSO의 보안 탭에서 켭니다. TOTP 방식이라 인증 앱을 등록하면 되고, 대시보드 안에는 이 화면이 없습니다. 계정 보안 일반은 계정 보안에 정리되어 있습니다.

예방 2. 도메인 쪽 설정

계정을 지킨 다음에는 도메인 자체에 걸 수 있는 제동 장치를 켭니다.

1. 도메인 잠금을 켭니다

   도메인 잠금은 레지스트리에 clientTransferProhibited 상태를 걸어 승인 없는 기관이전을 막습니다. 평소 켜 두고 이전할 때만 잠시 해제하는 것이 원칙입니다. 동작 방식은 도메인 잠금과 인증코드에 있습니다.

2. 인증코드는 필요할 때만 발급하고, 유출이 의심되면 재발급합니다

   인증코드를 문서나 메신저에 남겨 두지 않습니다. 재발급하면 이전 코드는 무효가 되므로, 노출이 의심될 때 가장 빠른 대응은 재발급입니다.

3. 등록자 연락처를 공용 주소로 정확하게 유지합니다

   이전 승인 요청과 만료 안내가 등록자 주소로 갑니다. 이 주소가 살아 있는지는 직접 점검해야 합니다. 여기가 개인 메일이거나 닿지 않는 주소면 예방과 대응 모두 무너집니다. 기준은 등록정보 정확성 의무를 보세요.

4. 중요한 도메인에 DNSSEC을 적용합니다

   DNSSEC은 응답이 위조되지 않았음을 검증하게 해 주고, 서명된 상태에서 존이 무단으로 바뀌면 검증 실패로 드러납니다. 지원 확장자에 한해 적용할 수 있습니다. 설정은 DNSSEC에 정리되어 있습니다.

5. 정보 수정 잠금과 이전 자동 거부까지 켭니다

   보안 설정 카드에는 토글이 세 개 있습니다. 정보 수정 잠금 은 연락처와 네임서버 변경을 한 단계 더 막고, 이전 자동 거부 는 들어오는 이전 요청을 자동으로 거부합니다. 이전 계획이 없는 도메인은 세 가지를 모두 켜 두는 편이 안전합니다. 레지스트리가 직접 걸어 주는 레지스트리 잠금은 레토에서 제공하지 않으므로, 도메인 쪽에서 쓸 수 있는 제동 장치는 이 세 토글이 전부입니다.

6. 변경 이력을 주기적으로 직접 확인합니다

   DNS 레코드나 네임서버가 바뀌었을 때 알려 주는 알림 기능은 없습니다. 그래서 이상 징후는 저절로 통보되지 않고, 도메인 상세의 설정 및 이력 탭에 있는 변경 이력 을 직접 열어 확인해야 합니다. 분기 1회처럼 주기를 정해 두고 기록해 둔 기준 값과 지금 값을 대조하세요. 변경자 칸에는 사용자 ID가 나오고 본인이 한 작업만 나 로 표시됩니다.

현재 값을 기준으로 기록해 두는 일이 예방의 마지막 칸입니다. 알림이 오지 않는 이상 비교할 기준이 없으면 바뀐 사실 자체를 알 수 없기 때문입니다. 네임서버, 주요 A 레코드, MX, 도메인 상태값을 문서로 남겨 두고, 바깥에서 보이는 값은 WHOIS 조회로 확인해 대조하세요.

탈취 정황을 발견했을 때

증상은 보통 이렇게 나타납니다. 사이트가 낯선 페이지로 바뀌거나, 메일이 갑자기 들어오지 않거나, 관리 계정 로그인이 거부되거나, 신청하지 않은 이전 진행 안내가 옵니다. 순서를 지켜야 복구 중에 다시 뚫리는 일을 막을 수 있습니다.

1. 등록자 이메일 계정을 먼저 되찾습니다

   메일 계정을 그대로 두면 비밀번호 재설정으로 공격자가 다시 들어옵니다. 비밀번호 변경, 전체 세션 종료, 2단계 인증 재설정, 전달 규칙과 필터 확인을 같이 합니다. 몰래 추가된 자동 전달 규칙이 남아 있는 경우가 많습니다.

2. 등록기관 관리 계정을 잠급니다

   비밀번호를 바꾸고 모든 세션을 로그아웃합니다. 접근 권한자 목록에서 모르는 항목을 제거하고, 등록된 연락처와 결제수단이 바뀌지 않았는지 확인합니다.

3. 이전 진행 여부를 확인하고 진행 중이면 즉시 거부를 요청합니다

   도메인 상태에 pendingTransfer 가 보이면 이전 신청이 접수된 상태입니다. gTLD는 기존 등록기관이 기한 안에 거부하지 않으면 자동 승인되므로 지체하면 안 됩니다. 문의로 도메인 이름과 발견 시각을 함께 알려 주세요.

4. 네임서버와 DNS 레코드를 기록된 값으로 되돌립니다

   바뀐 항목을 목록으로 적어 두고 원래 값으로 복원합니다. 복원 뒤에도 WHOIS와 외부 조회로 실제 응답이 바뀌었는지 확인합니다. 캐시가 남아 있을 수 있으니 전파 시간을 감안합니다.

5. 도메인에 의존하는 서비스를 점검합니다

   메일 수신, 로그인 연동, 결제 알림, 문자 발송처럼 도메인 인증에 기대는 서비스가 정상인지 확인합니다. 그 사이 발급된 인증서나 추가된 인증 레코드가 남아 있지 않은지도 같이 봅니다.

6. 잠금을 다시 켜고 기록을 남깁니다

   도메인 잠금과 인증코드 재발급을 끝낸 뒤, 발견 시각과 변경 내역, 조치 내용을 시간순으로 정리해 둡니다. 분쟁이나 회수 절차로 넘어가면 이 기록이 그대로 증빙이 됩니다. 적용 범위는 분쟁조정정책을 참고하세요.

서브도메인 테이크오버

도메인 자체는 우리 것인데 하위 이름만 남에게 넘어가는 문제입니다. 원인은 거의 항상 방치된 CNAME입니다.

순서는 이렇게 진행됩니다. 외부 서비스를 쓰기 위해 status.example.com 을 그 서비스 호스트로 가리키는 CNAME을 만들어 둡니다. 나중에 서비스를 해지하면서 서비스 쪽 설정만 지우고 DNS 레코드는 남겨 둡니다. 그러면 그 호스트 이름은 비어 있는 상태가 되고, 다른 사람이 같은 서비스에서 같은 이름을 다시 등록하면 우리 하위 도메인으로 그 사람의 페이지가 뜹니다.

피해가 단순한 페이지 변조로 끝나지 않을 수 있습니다. 같은 상위 도메인을 쓰기 때문에 쿠키 범위가 겹칠 수 있고, 사내 주소라는 신뢰를 이용한 피싱에 그대로 쓰입니다.

점검과 예방은 어렵지 않습니다.

• 보유한 모든 하위 도메인의 레코드 목록을 뽑아 각 대상이 지금도 우리가 쓰는 서비스인지 확인
• 외부 서비스를 해지할 때 DNS 레코드 삭제를 해지 절차에 넣기
• 캠페인용, 테스트용, 문서용으로 만든 하위 도메인의 수명을 정해 두기
• CNAME 대상 호스트에 접속했을 때 서비스 쪽의 미등록 안내 화면이 뜨는 레코드를 우선 정리
• 와일드카드 레코드를 꼭 필요한 경우에만 쓰기 (모든 하위 이름이 한 곳으로 향하면 점검 자체가 어려워집니다)

레코드 목록을 확인하는 명령 예시입니다.

dig +short status.example.com CNAME
dig +short www.example.com A

외부 서비스를 연결할 때 생기는 레코드의 종류와 정리 방법은 외부 서비스 연결에 정리되어 있습니다. 하위 도메인 전체 목록과 담당 부서는 도메인 관리 대장에 같이 적어 두세요. 대장 양식은 법인 도메인 관리 체크리스트에 있습니다.