Skip to main content

Tips para proteger su nombre de dominio

Información asociada al registro de un dominio

En el mundo de los dominios genéricos o gTLDs, quien registra un nombre (el registrante del dominio) debe suministrar al registrador (qué es un registrador?) su nombre (sea persona natural o jurídica), su dirección física y de correo electrónico, un número de teléfono y un número de fax (estos datos los debe suministrar también para los contactos administrativo y técnico del dominio). Adicionalmente, el registrante debe indicar los servidores de resolución o nameservers que estarán asociados al dominio (aunque, con frecuencia, los registradores que ofrecen servicios de hosting se encargan de definir los nombres de estos servidores para los dominios que han registrado sus clientes).

El registrante debe también definir el status del dominio (qué son los status de EPP para los dominios?), que por defecto indica que el dominio está en 'OK', es decir, que está funcionando (o resolviendo, en el argot técnico del DNS). El status puede ser modificado para indicar que el dominio no puede ser borrado, transferido a otro registrador o que se encuentra suspendido.

Esta información alimenta la base de datos de WHOIS (qué es el WHOIS?) que debe ser mantenida por el registrador respecto de todos los dominios registrados por él. El acceso a esta base de datos es libre y gratuito y cualquier persona puede acceder a la información de contacto de quien haya registrado cualquier dominio genérico.

Prever las amenazas y mitigarlas

Esa característica propia del WHOIS, de poder ser consultado por cualquier persona, hace que lo usen tanto quienes buscan ejercer actividades legítimas como quienes quieren usar esa información con propósitos dañinos. Por esta razón los registrantes deben ser inteligentes respecto de la información que incluyen en el WHOIS de sus dominios, para evitar ser víctimas de delincuentes digitales que robar sus dominios u otras cosas más.

Los atacantes solamente necesitan conocer el nombre de usuario y la clave de acceso a la cuenta que cada registrante tiene con su respectivo registrador. Simplificando un poco para efectos de esta explicación, cada registrante tiene una cuenta con su registrador a través de la que administra sus medios de pago, sus formas de contacto, los servicios que recibe del registrador y todos los dominios que ha registrado.

Los atacantes adivinan, roban o utilizan técnicas de ingeniería social para dar con las combinaciones de usuario/clave que les abren las puertas a las cuentas de sus víctimas. Por eso, es importante que al crear y manejar sus cuentas con los registradores, los registrantes usen claves fuertes, las cambien con frecuencia y busquen, en lo posible, registrar sus dominios con registradores que ofrezcan múltiple autenticación (lea acá la Guía de NIST sobre administración de claves corporativas [PDF, 220 KB]).

Por otro lado, existen registradores que ofrecen servicios de protección contra el robo o hijacking de los dominios que los registrantes deberían considerar, así su costo parezca inicialmente considerable. Las pérdidas ocasionadas por el robo de un dominio pueden llegar a ser significativas, bastante más altas que el costo de los servicios de protección contra esta clase de amenazas.

Recomendaciones básicas

El Comité Asesor en Seguridad y Estabilidad de ICANN (SSAC, por sus siglas en inglés) publicó en 2009 y 2010 los documentos SAC040 (Measures to Protect Domain Registration Services Against Exploitation or Misuse) y SAC044 (A Registrant's Guide to Protecting Domain Name Registration Accounts). Estos documentos incluyen una serie de recomendaciones que los registrantes y los registradores pueden tener en cuenta para registrar y administrar sus dominios de una forma segura.

Entre las recomendaciones básicas que todo registrante debe tener en cuenta se pueden mencionar las siguientes, incluyendo algunas que fueron ya incluidas en SAC04 y SAC044:

  • Respecto de los registrantes que son personas jurídicas, evitar incluir los nombres de personas naturales entre los contactos de WHOIS. Por ejemplo, en lugar de que el contacto administrativo de los dominios de su compañía sea Carlos Álvarez, es mejor que sea 'Departamento de Sistemas'.

    Esto evita que el señor Álvarez se convierta en un objetivo de los atacantes que se interesen en los dominios, que de otra manera pueden definirlo a él como objetivo de un ataque de ingeniería social bien preparado. Por otro lado, si el señor Álvarez un día deja de ser empleado de la compañía, puede pasar que nadie recuerde que él es el contacto para los dominios y la compañía termine perdiéndolos o viéndose afectada de otra manera cuando el registrador le escriba a Álvarez y no haya respuesta.

  • En los emails listados en la información de WHOIS, evitar incluir emails de personas específicas y, en su lugar, incluir emails genéricos que sean revisados por departamentos o grupos de empleados y que sean solamente dedicados a la administración de los dominios. Por ejemplo, en lugar de listar el email carlos.alvarez@su_compania.com, debería listarse un email como sistemas@su_compania.com o admin_domain@su_compania.com.

    Al hacerlo de esta forma, se evita que, cuando el señor Álvarez no trabaje más para la compañía, el registrador envíe mensajes a su dirección de correo y nunca sean respondidos. Recuerde que los registradores deben suspender o cancelar los dominios cuando, en ciertas circunstancias, escriben al registrante o al contacto administrativo de un dominio y no reciben una respuesta.

  • El registrante debe definir varios status para el dominio: dejarlo con el status 'OK', que es asignado por defecto, puede facilitar a los atacantes el robo del dominio. No es obligatorio, ni mucho menos, pero sí tiene sentido que los status que sean definidos incluyan 'transferProhibited' (que impide las transferencias de un registrador a otro), 'deleteProhibited' (que impide que el dominio sea borrado) y 'updateProhibited' (que impide que, por ejemplo, sean modificados los nameservers y consiguientemente todo el tráfico dirigido al dominio termine siendo redirigido a servidores controlados por un tercero).

  • Finalmente, el registrante debe designar al menos dos nameservers para el dominio. Es raro encontrarlos, pero a veces se ven dominios a los que solamente les fue asignado un nameserver. Cuando esto es así, los dominios están sujetos a un single point of failure puesto que para detener la resolución del dominio todo lo que se necesita es que ese único servidor deje de funcionar.

  • Nunca liste direcciones creadas bajo el mismo dominio como emails de contacto de WHOIS. Por ejemplo, si el dominio es [loquesea_ejemplo.com], el email del registrante en el WHOIS no debería ser empresa@[loquesea_ejemplo.com]. En un caso como este, si por cualquier razón llegara a perder el control del dominio, muy probablemente perdería acceso al email y, por consiguiente, recuperarlo sería sustancialmente más difícil.

En general, administre siempre sus dominios con mucha precaución. A ellos están asociados la presencia en línea de su empresa, su email, el negocio del que usted y sus empleados dependen. Recuerde siempre que usted es su propia primera línea de defensa y que de usted depende configurar su entorno de manera que sea un poco más seguro y los delincuentes del día a día prefieran seguir de largo, en lugar de tener que dedicar tiempo y esfuerzo a robar sus dominios cuando pueden conseguir otros más fácilmente.

Comments

    Domain Name System
    Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."