viernes, 21 de julio de 2017

Mirando cosas en el DNS interno. Wireshark

Estimados amigos de Inseguros !!!

Uno de los servicios que suele ofrecer a mis clientes es la auditoría de red orientada a la seguridad.

No es una auditoría de seguridad, pero tampoco es una auditoría de red al uso, enumerando equipos, viendo tiempos de respuesta, identificando switches con 2 3 y hasta 4 bocas conectadas a si mismo y a otro switch, en fin, ya sabéis, redes !!!


Lo primero que hago es monitorizar o mejor dicho capturar paquetes de red en distintos horarios y en distintos rangos/redes/vlans o como el cliente tenga el tinglao.
Algunas cosas que hago es pasarle el pcap a una herramienta como Malcom, como vimos aquí,  y de esta manera analizar si hay equipos que se está conectando a fuentes maliciosas conocidas. Una buena fuente de inteligencia en Malcom y podemos detectar ordenadores comprometidos.

Este no es el propósito del post, que como siempre me voy por las ramas, como un mono, colgao !!!

La parte del DNS en las empresas no suele estar muy bien configurada. No al menos desde el punto de vista de la seguridad o mejor dicho el control, ya que esto no tiene que ver mucho con seguridad, sino con tener el IT organizado, pero al final redunda en incidentes.



La mayoría de vosotros teneis una red con Active Directory o una red basada en Dns Bind. Todos los equipos "buscan" su configuración dns para realizar las consultas. Estas van al servidor DNS, si son internas o están en Cache o existe el registro las resuelven, y si no preguntan a los reenviadores por esta información. Correcto, has sacado un 5 en redes del grado medio.

En caso de tener un incidente de seguridad, o sospechas de él, auditar las peticiones al Dns debería ser una buena idea. Imaginar un equipo preguntando cada 2s por un dominio .ru... Estas cosas las debería detectar el IDS pero bueno... Muchas veces no se habilita el log paras las consultas DNS, como vimos en el caso de Windows 2012 

En la red interna, bajo mi humilde punto de vista, TODOS los equipos deben apuntar al servidor Dns de la empresa, y solo este debe tener la capacidad a nivel de firewall de establecer conexiones salientes con destino udp 53 hacia fuera. La cámara de seguridad, el portátil de nosequien, el gadget de nosecuantos, todos, aunque no sean equipos que registremos ( que deberíamos hacer manualmente en el dns) deben apuntar al dns interno, y no al 8.8.8.8 porque como son "dispositivos" no pasa nada.

De esta manera, podemos evitar casos de compromiso en el que un malware usa su propio servidor dns para resolver direcciones. De esta manera si cortamos a nivel de firewall, podríamos evitar un contacto con C&C maligno.

Si queremos entrar un poco más en detalle, podemos analizar el tráfico buscando comportamientos raros raros raros. Hay casos en los que piezas de malware usan lo que se denomina Silent Ip para no revelar la dirección del C&C. Si el atacante no necesita iteración, para evitar ser detectado, cambia la ip real hacia una interna, menos sospechosa. Consultas DNS hacia direcciones ip de nuestra red tipo 192.168.o cosas así, que no correspondan a un servidor DNS, pueden representar este caso.

Para esto usamos la herramienta wireshark que tanto nos gusta. Si eres https://twitter.com/seguridadyredes quizas uses bro o tshark o cualquier de estas herramientas que tanto le gustan en formato "internet negro", pero yo prefiero el gráfico para este caso.

Aparte de visualizar y buscar dominios a priori peligrosos, podemos usar las opciones propias de DNS para mostrar una pequeña estadística de paquetes dns, malformados y algo importante, el tamaño medio del payload. Con este dato podríamos averiguar o tener indicios de un sistema comprometido realizando exfiltración de datos mediante el dns.



Por cierto, antes de que se me pasa, existe la posibilidad de consultar la wiki de wireshark sobre un protocolo pulsando sobre el con las opciones y accediendo a Wiki. Es muy útil cuando encuentras protocolos de red que no estamos muy acostumbrados, además, te da algun truco para filtrar por el, explicacion, está bien. 


https://wiki.wireshark.org/DNS?action=show&redirect=Protocols%2Fdns

Una de las opciones que suele marcar es el menú View, resolución de nombres, habilitar la resolución de nombres para la capa de red. Por defecto lo hace para la capa física, algo que para mi no tiene  mucho sentido ya que no suelo trabajar en esa capa, me refiero a la dirección MAC.


Recuerda que para ver la localización de una dirección debes hacer este pequeño procedimiento.

Estas son algunos de mis pequeños consejos y trucos que hago de vez en cuando en las redes que manejo para ver comportamientos raros.

Para el protocolo NTP suelo hacer lo mismo.

Como sabes, todo lo que vaya por UDP es muy susceptible a ser usado en ataques de ddos por la característica de la impersonalización y facilidad de hacer spoofing ( no handshake...) por lo que hay que estar un poco más "atento" a estos servicios, sobre todo si los exponemos hacia Internet. No es mi consejo, y prefiero tener dns externos para internet, pero si por culquier motivo lo necesitas, monitoriza los incrementos de ancho de banda con tu UTM o Nagios o similar, y establece una política de colas y QOS porque ya hemos visto muchos ataques usando udp para liarla, tipo cámaras IOT etc.

Espero que os sirva de algo todo esto. Vamos a la playa? xD



1 comentario:

  1. Buena,clara y concisa Kino!Las DNS y NTP tan importantes y a veces demasiado olvidados.Como bien apuntas suplantación,amplificación de peticiones...Hay que tener cuidado.

    ResponderEliminar

Gracias por comentar !!

Related Posts Plugin for WordPress, Blogger...