10.

Ataques al protocolo SSL

10.1. ¿Es seguro SSL?

El protocolo SSL (Secure Sockets Layer) es un protocolo permanentemente seguro puesto
a que los protocolos que se utilizan tienen un cuerpo teórico fuerte y maduro, pero esto no
quiere decir que algunas cosas no pueden salir mal. En efecto muchas cosas pueden salir
mal.
Por ejemplo, la complejidad de estos protocolos es una causante de atentado contra la
usabilidad de los mismos. En las implementaciones se pueden presentar fallos de
seguridad debido a la manera en que han sido programados estos protocolos.
Estos protocolos pueden pasar a ser no tan seguros debido a que puede pasar que se hayan
desarrollado nuevas técnicas de criptoanálisis. Según la Ley de Moore, la capacidad de
computación de los atacantes a la seguridad de estos protocolos va en aumento y esto
también puede ser causa de que dichos protocolos necesiten ser revisados y que versiones
antiguas de SSL sean inseguras.
Respondiendo la pregunta de si el protocolo SSL es seguro, se puede decir que el este
protocolo es seguro en su diseño teórico. Pero esto es una condición necesaria, aunque no
suficiente.
El uso del protocolo SSL es de uso vital en transacciones de tipo comercio electrónico que
se realiza entre clientes y proveedores de productos. Es de uso común en transacciones de
compra de libros o cualquier articulo por medio de internet o cuando usamos la banca
online de alguna agencia bancaria.
Es posible que SSL sea famoso por su uso en la Web. Su uso adecuado permite minimizar
ataques, algunos clásicos como ataques de hombre en el medio contra la información
intercambiada, así como minimizará ataques de suplantación en el acceso a nuestras redes
sociales favoritas.
La “seguridad real” del protocolo SSL tiene que ser matizada. En su uso en la web va
mucho más allá de la idea equívoca de que una página es segura si y solo si se muestra el
famoso “candado amarillo”.
10.2. Fallos de programación en las implementaciones, criptoanálisis y downgrade
Uno de los ejemplos más famosos de ataque a SSL fue la vulnerabilidad anunciada en
mayo de 2008. El investigador Luciano Bello descubrió implementaciones incorrectas de
funciones aleatorias que se utilizaban en OpenSSL/Debian. Esto producía material
“aleatorio” predecible (que siguen alguna secuencia repetitiva o un patrón de generación)
que facilitaba invertir los procesos criptográficos, y como consecuencia de ello
certificados X.509, claves SSH e incluso material cifrado se vieron expuestos.
Una de las implicaciones que se produjeron debido a estas malas implementaciones fue
que se podían reconstruir las claves privadas a través de las claves públicas distribuidas.
Sin estas funciones criptográficas aleatorias estos criptosistemas quedaron indefensos.
Sin embargo, a más de los problemas de implementación hay que sumarle la capacidad de
computo cada vez mayor de los atacantes y los avances en criptoanálisis. Esto
simplificaría la creación de certificados digitales falsos creados a la medida.
Un ejemplo de esto se puede ver en los resultados publicados en la 25 edición de la Chaos
Communication Congress celebrada en Berlín en diciembre de 2008, en la cual
investigadores crearon un certificado SSL “válido” aprovechándose de las peculiaridades
de emisión de ciertas autoridades de certificación, de un ataque de colisión al algoritmo
criptográfico MD5 y de una importante capacidad de cálculo basada en una centena de
consolas PlayStation.
MD5 ya no se usa en las Autoridades de Certificación para calcular el hash del certificado
que va firmado con su clave privada, pero el estándar actual SHA-1 también está
comenzando a tener unos problemas similares a los de su homólogo.
Otro tipo de ataque fue el descubierto por el investigador Moxie Marlinspike. Al crear un
certificado SSL y enviarlo a una Autoridad Certificadora para que lo firme, el campo al
que se le suele prestar más atención es el CN (common name) que especifica el nombre
del servidor. Este investigador descubrió que los estándares de certificado X.509 y SSL
definen la cadena CN como una cadena PASCAL (se declara la longitud de la cadena en
la posición 0 y se pone la cadena en el resto de posiciones). La mayoría de software de
procesamiento de certificados está escrito en C. Este software suele manejar la cadena
como una cadena C, poniendo un NULL al final de la cadena para indicar dónde termina.
El posible problema con esto llega cuando alguien obtiene un certificado de la forma
www.bancolegitimo.com\0www.atacante.org. Este certificado cuando es procesado por
un navegador, sólo se lee la primera parte, www.bancolegitimo.com, permitiendo
falsificar al banco. Como solución más fácil, las entidades certificadoras rechazan todos
los certificados que contuvieran el carácter NULL.
Cuando se detectan certificados fraudulentos, suelen revocarse gracias al número de serie
que incluyen y para esto suele utilizarse el protocolo OCSP (Online Certificate Status
Protocol). De nuevo una configuración incorrecta en el mismo facilitaría ataques al
protocolo SSL.
El protocolo OCSP es un protocolo de consulta online para saber si un determinado
certificado digital ha sido revocado o no.
10.3. Engañando al usuario. Vulnerando SSL en la Web
En la práctica la manera más fácil de vulnerar la seguridad proporcionada por el protocolo
SSL/TLS consiste en engañar al usuario haciéndole pensar que lo está utilizando cuando
en realidad no es así.
El candado amarillo que indica el navegador no es garantía total de que estemos usando
el protocolo SSL debido a que este candado puede ser vulnerado e indicado de distintas
formas.
Por ejemplo, mediante un troyano, ya que este virus engaña al navegador Web y por
consiguiente el navegador nos indica que se está usando SSL cuando en realidad no es así.
El troyano a más de engañar al navegador Web, éste puede obtener control total de la
máquina, capturar contraseñas, redirigir tráfico de datos o de autenticación.
Posiblemente los ataques más interesantes son aquellos que no tienen acceso interno a la
máquina, clásicamente ataques de hombre en el medio cuyo principal objetivo es
interceptar una comunicación entre un cliente y un servidor y ver o alterar la información
en tránsito.
El ataque de hombre en el medio más simple consiste en crear un certificado digital falso.
Es decir, cuando un usuario se conecta vía https a su banco online, un atacante se conecta
en medio de los dos y envía su certificado al cliente haciéndose pasar por el banco. El
navegador Web detecta que el certificado digital no es el reconocido e indica visualmente
al usuario si desea aceptar la conexión. La mayoría de los usuarios sin formación en
seguridad lo aceptarán, pulsando SÍ, con lo que el atacante estará en medio y podrá realizar
lo que desee con los datos en tránsito, así como con las claves capturadas.
El protocolo SSL hará su funcionamiento normal después de aceptado el certificado y el
usuario observará el candado amarillo correspondiente. Por el contrario, si un usuario con
un mínimo de conocimientos pulsara NO, el ataque no tendría lugar.
En otros casos el robo de certificados firmados por una autoridad de confianza puede
suponer muchos problemas. El impacto de este ataque implica que, cualquier persona u
organismo con capacidad de implementar un ataque de hombre en el medio sería capaz de
“transmitir” una web https falsa de Yahoo, Google y otros sin que el navegador protestase.
Por suerte, estos certificados han podido revocarse por su número de serie.
10.4. Uso seguro de SSL. Recomendaciones
Utilizar la versión más moderna del protocolo SSL debidamente configurado e intentar
que las implementaciones de dicho protocolo estén corregidas de fallos conocidos.
Depende de la necesidad de mantener la compatibilidad entre sistemas.
En el caso de su uso en la Web, tenemos 5 consejos para mitigar problemas conocidos:
 Mantener el navegador web actualizado para que la implementación del protocolo
SSL está libre de vulnerabilidades conocidas.
 Añadir en la Url (cuando sea posible) la dirección directa https de la página a la
que nos deseamos conectar. El add-on para firefox “HTTPS Everywhere” puede
ayudar a automatizar esto.
  Denegar acceso a una página Web cuando el certificado no sea válido. Esto es
especialmente crítico para el acceso a cuentas bancarias, datos personales, etc. En
otro caso, el usuario baremará la relación riesgo-acceso a esa web.
 Configurar los navegadores web para que hagan comprobaciones OCSP por
defecto y que si la conexión OCSP falla, el certificado por defecto no sea dado por
bueno. Esto evitará ataques basados en negación de servicio al OCSP y uso de
certificados revocados.
 Ciertos complementos software podrían ayudar a detectar plagios. Por ejemplo, en
firefox el add-on “Certificate Patrol” monitoriza cambios en servidores https de
forma que, si un día el certificado de SSL de Gmail es diferente al registrado,
notifica ese cambio.

11. Análisis y Gestión de Riesgos

11.1. Riesgos y protecciones en los sistemas de información

Cuando tenemos un incidente es demasiado tarde para evitarlo y podríamos ser culpables
de negligencia. hay mil situaciones posibles: fallos nuestros, de nuestros proveedores,
catástrofes naturales, gente interesada en robar, espionaje, etc.
La responsabilidad no termina porque la culpa sea ajena. Sea quien sea el culpable, hay
que intentar atajar las consecuencias. Cuando uno no puede anticiparse a los hechos, lo
profesional es preparar planes de acción para mitigar los incidentes y establecer soluciones
alternativas.
Sólo el responsable del negocio sabe lo que le interesa proteger y de qué o de quién.
Aunque hay medidas generales que prácticamente interesan a todo el mundo, otras habrá
que adecuarlas a cada caso. Para realizar esto nos puede ser de ayuda el análisis de impacto
de los incidentes.
11.2. Análisis de impacto y análisis de riesgos
Se llama análisis de impacto al ejercicio de imaginarnos las consecuencias de que haya un
incidente, accidental o deliberado. O sea, responder preguntas del tipo:
 ¿qué pasaría si se revela un dato confidencial?
 ¿Qué pasaría si manipulan nuestra información?
 ¿Qué pasaría si nos quedamos sin servicio durante X horas?
Hay que preguntar al responsable de la información o el servicio. A efectos del análisis de
riesgos, esta estimación del impacto es un dato de entrada.
La normativa relativa a la protección de datos de carácter personal puede ser un ejemplo.
Otras veces hay obligaciones de servicio, como puede ser el suministro eléctrico o que
funcione el teléfono. Otras veces es simplemente la estrategia empresarial que ha
determinado la Dirección.
De lo anterior decimos que esto no es un tema técnico, sino más bien es un tema de
Gobierno de la Organización. Normalmente es más importante saber el daño que podría
derivarse de un fallo de seguridad que saber lo que cuesta el sistema de información en sí
mismo.
El análisis de riesgos no es fácil. Cuanto menos, es muy laborioso porque los sistemas son
muy ricos en componentes y las posibles situaciones se multiplican.
Hay que empezar por un buen inventario, qué información maneja y qué servicios tiene
que prestar el negocio. Esto implica entender el negocio. Dentro de los activos no se debe
olvidar otras causas de problemas como las instalaciones físicas y las personas
relacionadas con el sistema.
Tras inventariar activos y amenazas, hay que calificar cada escenario posible para conocer
su impacto y su riesgo. El impacto son las consecuencias para el negocio que nos traemos.
El riesgo va un paso más allá y ordena los incidentes según la probabilidad de que ocurran.
Las palabras impacto y riesgo, a veces se llaman indicadores del estado de seguridad y
sirven para tomar decisiones. El impacto mide lo que puede pasar. El riesgo mide lo que
probablemente pase.
11.3. Gestionando los riesgos
Tenemos 4 formas de afrontar los riesgos:
 Evitar la situación,
 Mitigar el peligro,
 Pasárselo a otro,
 Aceptar lo que hay.
La primera medida es preguntarnos si necesitamos todo lo que tenemos.
La segunda medida es mitigar el impacto, mitigar el riesgo o ambos. El riesgo se lo mitiga
con medidas preventivas. El impacto se reduce con medidas reactivas o de recuperación.
Aceptar riesgos es parte de decisiones rutinarias. Hay que equilibrar riesgos y posibles
beneficios. Muchas personas viajan en avión pese al riesgo de que se desplome.
Estas decisiones son una vez más de gobierno del negocio. No las puede tomar un técnico,
las tiene que tomar la Dirección. Muchas actividades consisten en buena medida en asumir
riesgos para alcanzar unos ciertos beneficios.
El análisis de riesgos proporciona es la información para saber qué nos estamos jugando
y tomar decisiones informadas.
El análisis de riesgos califica las consecuencias y nosotros veremos cuántos recursos
pueden justificarse para la solución. Al final hay que llegar a un equilibrio. La máxima a
recordar es que el coste de las medidas de protección no puede superar el bien protegido.
 En un mundo dinámico, el análisis de riesgos ha de ser tan dinámico como el mundo. El
contexto suele cambiar.
11.4. Recomendaciones. Metodologías
Los análisis pueden ser de detalle, pero no suelen serlo. Y la disponibilidad se limita a
imponer un tiempo máximo de interrupción del servicio.
No podemos decir exactamente que el análisis de riesgos sea 100% independiente del
analista. Se trata de una actividad de consultoría donde hay un factor humano no
despreciable. Lo que hay que hacer es seguir un método de forma que el análisis sea
homologable y estar siempre preparados para poder explicar el porqué de las conclusiones.
Existe un método universal para lo descrito anteriormente y estas son las normas ISO que
establecen una serie de marcos de nomenclatura y actividades. Estas normas no se limitan
sólo a seguridad de la información, sino que unifican riesgos de diferentes tipos para poder
tomar decisiones combinando riesgos laborales, riesgos financieros, riesgos técnicos,
riesgos medioambientales, etc.
Hacer un análisis de riesgos sin herramientas, sería imposible de mantener y de hacer los
análisis marginales pertinentes para los cambios constantes del sistema y del entorno.
Como resultado de esta inquietud podemos citar Magerit y Pilar. Magerit es una guía
práctica para analizar y gestionar riesgos dentro del marco ISO. Y Pilar es una herramienta
que ayuda a gestionar el volumen de información que requiere un análisis de riesgos
profesional.

12. Seguridad en redes WI‐FI

12.1. Introducción a la seguridad de las redes WI‐FI

Son utilizadas por millones de personas en todo el mundo a diario dada la facilidad de
conexión, flexibilidad y movilidad que ofrecen.
La principal diferencia entre las redes inalámbricas y las redes cableadas, como Ethernet,
está en el acceso físico a la red. En las redes cableadas tradicionales, es necesario
conectarse a la misma a través de una toma de red o punto de conexión físico. Las redes
Wi‐Fi envían sus datos a través de señales de radiofrecuencia que viajan por el aire, como
la TV o la radio, por lo que es más sencillo para cualquiera poder tener acceso a estas
comunicaciones.
Pese a que los estándares y especificaciones Wi‐Fi normalmente referencian distancias
teóricas de unos 100 metros, la distancia real que puede alcanzar la señal de las tecnologías
inalámbricas depende del equipamiento empleado por la red y por el atacante. Influyen
muchos factores en esa distancia, como la existencia de obstáculos, la densidad de los
mismos, la potencia de transmisión, la sensibilidad de recepción y la utilización de antenas
de alta ganancia.
Numerosos proyectos y demostraciones han logrado conexiones de cientos de metros
empleando equipamiento estándar, por lo que se puede asumir que en un entorno real el
atacante de una red Wi‐Fi puede estar situado a cientos de metros, incluso varios
kilómetros, de la red.
Los ataques sobre redes Wi‐Fi son muy numerosos, pero podríamos clasificarlos en cuatro
categorías generales:
 Los ataques de negación de servicio (DoS, Denial of Service) son los más
difícilmente evitables por cómo funcionan las tecnologías inalámbricas, ya que
alguien puede generar suficiente “ruido” en la frecuencia empleada por la red Wi‐
Fi y hacer imposible ningún tipo de comunicación inalámbrica. Especialmente
relevante en entornos críticos, como redes Wi‐Fi de monitorización en hospitales
o infraestructuras críticas.
 Por otro lado, es trivial para un atacante interceptar las comunicaciones de la red
Wi‐Fi que viajan por el aire, y tener así acceso a los datos intercambiados si estos
no están cifrados. Este ataque es indetectable y afecta a la confidencialidad de las
comunicaciones.
 Los dos últimos tipos de ataque son la inyección de tráfico y el acceso a la red. Un
atacante sin acceso a la red podría inyectar tráfico y modificar su comportamiento,
pero también podría establecer una conexión no autorizada con la red Wi‐Fi y
disponer de acceso completo a la misma, afectando en ambos casos a la integridad
de las comunicaciones.
Es importante reseñar que es necesario proteger tanto las redes Wi‐Fi, puntos de acceso y
controladores, como los clientes que se conectan a esas redes Wi‐Fi, como ordenadores
de escritorio y portátiles, teléfonos móviles o Smartphones, tabletas, y cualquier otro
dispositivo móvil.
12.2. Seguridad de las redes Wi‐Fi
A la hora de configurar una red Wi‐Fi adecuadamente hay muchas tecnologías y opciones
diferentes, como WEP, WPA y WPA2, 802.1x, etc.
Al momento de configurar una red Wi-Fi hay dos elementos de seguridad a tener en
cuenta, el cifrado de las comunicaciones y la autentificación o control de acceso a la red.
Por un lado, para evitar que nadie pueda capturar las comunicaciones y acceder a su
contenido, es necesario cifrarlas. Las tecnologías que se mencionan anteriormente
permiten cifrar las comunicaciones, pero algunas son inseguras.
Por otro lado, para evitar que alguien pueda acceder a la red de forma no autorizada, es
necesario disponer de mecanismos de autentificación robustos que permitan identificar
quién puede conectarse a la red.
Es muy habitual que los puntos de acceso Wi‐Fi estén configurados por defecto como
abiertos. También es habitual recibir el punto de acceso o router Wi‐Fi del proveedor de
servicios de Internet configurado con WEP (Wired Equivalent Privacy), un mecanismo de
cifrado antiguo e inseguro, aunque requiera utilizar una contraseña.
Las redes Wi‐Fi personales deberían ser configuradas con WPA2 (Wireless Protected
Access 2), en su variante Personal o PSK (Pre‐Shared Key), una opción segura si se
emplean contraseñas suficientemente largas (más de 20 caracteres) y difícilmente
adivinables, que deben configurarse tanto en los clientes como en la red Wi‐Fi. WPA2
ofrece mecanismos de cifrado y de autentificación.
A la hora de seleccionar WPA2 Personal, aparecen dos opciones: TKIP (Temporal Key
Integrity Protocol) y AES (Advanced Encryption Standard). Se recomienda usar AES, al
estar basada en el conjunto de algoritmos criptográficos de referencia en la actualidad.
TKIP es una evolución de los mecanismos de cifrado de WEP, también basada en RC4,
pero con mejoras, que se diseñó para ser utilizada con WPA y los dispositivos Wi‐Fi que
ya soportaban WEP hace años. WPA es más inseguro que WPA2 y es una alternativa que
se diseñó para ser usada sólo temporalmente.
En el caso de empresas y otras organizaciones, es más recomendable que las redes Wi‐Fi
corporativas sean configuradas con WPA2, en su variante corporativa o Enterprise, ya que
es una opción aún más segura al emplear un servidor RADIUS (Remote Authentication
Dial In User Service) para generar y distribuir contraseñas aleatorias y robustas, junto a
los protocolos 802.1X y EAP (Extensible Authentication Protocol) para la autentificación.
12.3. Seguridad de los clientes Wi‐Fi
Dado que las redes Wi‐Fi pueden ser configuradas en la actualidad de forma mucho más
segura que en el pasado, los atacantes han centrado sus actividades también en los clientes
Wi‐Fi, el eslabón más débil de la cadena. Sólo por el hecho de tener un interfaz Wi‐Fi
activo en un dispositivo móvil alguien podría comunicarse con él y atacarlo.
Uno de los ataques más comunes sobre clientes Wi‐Fi es el de punto de acceso falso (evil
twin), donde el atacante suplanta una de estas redes Wi‐Fi preferidas y anunciadas por tu
dispositivo, con el objetivo de que el cliente se conecte a la red del atacante pensando que
es la red Wi‐Fi preferida, por ejemplo, la de tu empresa, aunque estés a kilómetros de
distancia de ésta. el ataque sólo es posible si el dispositivo Wi‐Fi desvela al menos una
red preferida.
El ataque de punto de acceso falso es posible si el dispositivo contiene redes ocultas en su
lista de redes preferidas. Por este motivo se desaconseja configurar las redes Wi‐Fi como
ocultas, ya que esta supuesta medida de protección disminuye la seguridad de los clientes
Wi‐Fi. Las redes Wi‐Fi públicas, que ofrecen acceso a Internet gratuito o de pago, son un
entorno perfecto para los atacantes.
 Para evitar ese tipo de ataques, lo habitual es hacer uso de las VPNs (Virtual Private
Networks) basadas en SSL o IPSec para proteger todo el tráfico enviado a través de una
red insegura, como la red Wi‐Fi pública. El uso de VPNs sobre redes Wi‐Fi inseguras es
una práctica muy común, y aunque se trata de una medida de seguridad recomendada,
debe tenerse en cuenta que presenta vulnerabilidades.
En resumen, es preferible por tanto emplear redes Wi‐Fi seguras, junto a tecnologías
VPNs y conexiones cifradas extremo a extremo, como las basadas en SSL/TLS.
12.4. Recomendaciones de seguridad
Para proteger una red Wi‐Fi es recomendable reducir el alcance de la señal, no configurar
la red Wi‐Fi como oculta y emplear tecnologías de seguridad como WPA2‐AES, en su
versión Personal (o PSK) con contraseñas suficientemente largas y difícilmente
adivinables, o en su versión Enterprise junto al método EAP más adecuado según las
características del entorno Wi‐Fi corporativo. Adicionalmente es recomendable disponer
de mecanismos de detección para poder identificar ataques en la red Wi‐Fi.
Para proteger a los clientes Wi‐Fi es recomendable mantener actualizado tanto el sistema
operativo como los controladores Wi‐Fi, deshabilitar el interfaz Wi‐Fi cuando no se está
utilizando, evitar conectarse a redes Wi‐Fi inseguras, como por ejemplo redes públicas
abiertas o con mecanismos de seguridad débiles como WEP, y mantener actualizada la
lista de redes preferidas, eliminando redes ocultas o aquellas a las que no nos vayamos a
volver a conectar.

13. Seguridad En DNS

13.1. El sistema DNS. Conceptos básicos.

El DNS es un esquema de direccionamiento que es utilizado globalmente ya que este
asocia un nombre a una dirección ip, ya que es mucho más sencillo el recordar
“direcciones humanas” o descriptivas que una “dirección maquina” (protocolo IPv4).
Antes se utilizaba el contenido de un fichero de sistema nombrado Hosts que asociaba una
dirección IPv4 con un nombre del host como una agenda local.
En resumen, los elementos de DNS son; Clientes DNS y Servidores DNS los primeros
son aquellos que hacen peticiones y los servidores DNS se encargan de resolver las
peticiones y si no encuentran respuesta se dirigen hacia un nuevo servidor buscando la
respuesta a la petición.
Debido a la gran demanda que fue surgiendo a nivel mundial, debido al incremento en el
número de peticiones, así como de usuarios, DNS implantó nuevas técnicas para mejorar
la rapidez de las consultas y las exigencias de los usuarios, una de estas es la memoria
caché que guarda la asociación entre el nombre del dominio y sus direcciones IPs
13.2. Ataques al sistema DNS. Motivos.
Los ataques más típicos:
 Pharming: trata sobre el robo de credenciales de usuarios de bancos, tiendas redes
sociales, etc., re direccionando el tráfico desde una página web legítima a una para
suplantarla una de las formas es cambiar la asociación que se tiene en el archivo
Hosts de nombre y direcciones IPs, esto se podría realizar a través de un Troyano.
Actualmente existen varias soluciones para no depender de la arquitectura DNS como:
p2p, Open DNS, Apenas, etc.
 DNS caché poisoning: el atacante consulta al DNS legítimo y lo hace
comprometer con un DNS que controla el atacante (malicioso) por lo que
respondería cuando el cliente haga consultas o peticiones y este además está
asociado a otras páginas o fraudulentas y cuando responde a las peticiones lo hace
como el DNS legítimo y respondiendo con direcciones maliciosas.

 DNS ID Spoofing con Sniffing: (Suplantación de identidad en un DNS), en este

el atacante debe poder escuchar el tráfico del DNS, una vez el usuario haga la
petición el atacante deberá enviar la respuesta antes que la no fraudulenta por el
mismo puerto por el que se ha hecho la petición, con lo que el usuario recibe la
respuesta fraudulenta y aunque reciba después la respuesta legitima de la consulta
este la desecha ya que ha recibido con anterioridad una respuesta con el mismo
nombre o identificador

 DNS caché snooping: se trata de fisgonear en la caché del servidor DNS de una
empresa para obtener información que si a la ves puede no ser tan importante
puede dar paso al pishing, ingeniería social etc.

13.3. Recomendaciones y securización.

Desde un punto de vista del usuario se debe tener bien configurados ordenador y router,
así como tener actualizado el software, configurar correctamente le antivirus, usar
cortafuegos, tener una correcta política de claves, etc.
Hay ciertos estándares para mejorar la arquitectura DNS como: DNSSEC, IETF que
proporcionan autenticación e integridad de los datos intercambiados del DNS
Desde el punto de vista para proteger una infraestructura se debe tener en cuenta un control
de acceso sólido, tener un sistema de monitorización efectivo, capacitar a los empleados
sobre lo que es la ingeniería social, acceder a cache del DNS desde red interna, versiones
actualizadas de software DNS y en general tener configurar correctamente las
configuraciones.