Ataques DDOS por amplificación de tráfico

viernes, 2 de agosto de 2013 Sin comentarios

 

En los últimos años los ataques de  Denegación de Servicio Distribuido (DDOS) son cada vez más frecuentes y se basan en la falsificación de tráfico IP y la amplificación de este (Usar protocolos cuyos paquetes de respuesta sean de mayor tamaño que la petición enviada).

La falsificación de tráfico es debido sobre todo a redes mal configuradas que permiten que se genere tráfico que no pertenece a su rango de direcciones , a pesar de que el Documento de Buenas Prácticas (BCP 38) , indica que no se debe permitir, sin embargo todavía muchas redes lo permiten y esto permite que los equipos infectados de una botnet puedan falsificar el tráfico indicando que el origen es otro equipo (la víctima) el que genera el tráfico .

De esta forma el tráfico le llega a equipos en Internet que al responder le responden a la dirección de la víctima que se satura por el número de paquetes y volumen que les llega.

La amplificación de tráfico lo que permite es que los atacantes consigan que por un 1k de trafico los equipos al responder le reenvíen una cantidad mayor de datos a la víctima , en algunos protocolos se puede conseguir una amplificación de hasta 1:1000 o superior.

Cuando se falsifica el tráfico el atacante no espera respuesta , por lo que se deben emplear paquetes de datos UDP, que no requieren un establecimiento de conexión , esto descarta inicialmente ya bastantes protocolos comunes, como HTTP, correo, etc que van por TCP, sin embargo hay varios protocolos UDP que se usan bastante:

  • DNS, fue el primero en ser usado,  más información en esta entrada del blog.
  • SNMP (puerto 161) se emplea sobre todo para la monitorización de red, se esta usando bastante ya que hay muchos equipos que llevan una configuración “vulnerable” por defecto,  en http://www.bitag.org/report-snmp-ddos-attacks.php hay un documento que explica bastante bien los problemas.
  • Chargen (puerto 19) , es un protocolo antiguo que se usaba para comprobar que un equipo respondía en Internet,  no tiene mucho sentido desde hace mucho tiempo, pero muchos equipos lo tienen configurado , en  el diario del ISC de SANS,  comentan que se esta también usando para la generación de ataques DDOS , ya que permite una generación algo más reducida (un máximo de 512 caracteres )

SNMP es el caso más problematico , junto al DNS  ya que es un protocolo que se puede emplear para monitorizar y configurar el equipamiento, además:

  1.  Es posible amplificar el tráfico , es decir que enviando un paquete de tamaño reducido conseguir que se generan una respuesta mucho mayor (se habla muchas veces de 1:100  para algunas consultas, pero al parecer es posible llegar a una amplificación cercana a 1:10000 , (por un byte recibido el equipo genera 10000
  2. ) La seguridad del protocolo en su versión 1.0 se basa en una clave (community” ) que muchas veces es “publica” para consultas .
  3.  En muchos dispositivos de red el demonio SNMP escucha en todos los interfaces IP que tiene el equipo, lo que puede dificultar su filtro.
  4. Al ser un protocolo de monitorizacion en muchos dispositivos esta habilitado por defecto , no solamente en dispositivos de red sino también en equipos Linux, SunOS, ADSL, etc.
  5. Muchos equipos llevan configurado el servicio con los valores por defecto, que son públicos.

 

¿Qué se puede  hacer en vuestras instituciones ?.

  1. Por defecto filtrar las consultas SNMP desde el exterior, de forma que salvo las excepciones que necesitéis por monitorización externa este filtrado todas las consultas SNMP desde el exterior.
  2. Permitir solamente el acceso SNMP a las redes externas que os hagan monitorización y solamente como único recurso
  3.  Emplear en lo posible una VPN o un túnel GRE a la hora de las monitorización  externas, de forma que no haga falta hacer lo contemplado en el punto 2.
  4.  Cambiar las claves (comunidades ) de acceso de forma que no sean los nombres por defecto y realizar estos cambios de forma periódica.
  5. Limitar en los equipos no perimetrales lo indicado en los puntos 1 y 2 y 4 , de forma que solamente los equipos que tengan que hacer consultas SNMP pueden hacerlas y no cualquier equipo dentro de vuestra institución.
  6.  Monitorizar los equipos para ver cuando se producen este tipo de conexiones de forma insistente y cuando estas conexiones son ataques de fuerza bruta  (recordar que por SNMP no solo se puede monitorizar sino también cambiar configuraciones en los equipos).

 

 

Categories: Sin categoría Tags: , ,

Ataques de DNS empleando servidores de DNS mal configurados

martes, 2 de julio de 2013 Sin comentarios

Los servidores DNS recursivos y/o de cache son aquellos servidores de DNS que responden a consultas sobre información de la cual no son autoritativos y cumplen con una función muy importante dentro de la infraestructura de una organización a la hora permitir el funcionamiento normal de internet. Sin embargo, es conveniente mantener una serie de precauciones cuando el servicio está expuesto directamente a Internet , ya que desde hace algún tiempo se están usando estos servidores recursivos para la realización de ataques de Denegación de Servicio (DDOS)

DNS funciona mediante un sistema de “pregunta” / respuesta, empleando muchas veces el protocolo UDP, lo que da lugar a dos problemas:

  1. Al ser UDP el trafico se puede falsificar, tanto RedIRIS (que lo comprueba en su backbone) como las instituciones afiliadas cumplen con el documento de buenas prácticas 38, (BCP38) , pero muchas otras redes no.
  2. La consulta puede ocupar pocos bytes, pero la respuesta ser muy larga , es lo que se conoce como amplicación de tráfico que en DNS llega  a ser de aproximadamente 1 a 100 (por un 1Mb de trafico de consultas se consigue 100 veces más como respuestas

Esto hace que un atacante pueda emplear los servidores recursivos abiertos de las instituciones para en base a generar tráfico falsificado desde algunas redes mal configuradas hacer que los servidores de DNS amplifiquen el tráifco se produzca una denegación de servicio.

Además, ha salido publicado en algunos foros técnicos cómo se pueden emplear estos servidores DNS recursivos (haciendo hincapié en los existentes en al comunidad RedIRIS para conseguir una mayor velocidad en la visualización desde direcciones IP de proveedores comerciales, en base a emplear el sistema de cache “Google Content Network GCN)”, lo que puede suponer una violación del acuerdo entre RedIRIS y Google y puede ser perjudicial para las instituciones conectadas a RedIRIS.

Por otra parte, al ser el servicio de DNS un servicio básico para el funcionamiento de Internet, hay que tener en cuenta las diversas vulnerabilidades que pueden tener versiones antiguas del software “BIND”, de ISC, que es mayoritariamente usado por las organizaciones para la gestión de los servicios de DNS.

Desde  RedIRIS hemos comunicado en los grupos de trabajo varias veces los peligros que conllevan estos servidores de DNS abiertos, con los problemas que se pueden producir, como se puede ver en las presentaciones:

[1] Presentación en los grupos de trabajo 2011 ,

[2] Presentación en los grupos de trabajo 2013,
Sin embargo todavía quedan servidores de DNS abiertos en las instituciones y cada vez es más frecuente que lleguen notificaciones de ataques de dengación de servicio empleando direcciones IP de las redes las institiciones afiliadas.

Sería conveniente que configurarais vuestros servidores de DNS para que no fueran recursivos desde el exterior, en http://www.team-cymru.org/Services/Resolvers/instructions.html hay información sobre los pasos para conseguirlo. En las versiones actuales de Bind es muy fácil empleando las vistas:

1. Por defecto no permitir la recursión
2. Crear una vista interna limitada a las direcciones IP internas que permite la recursión.

Tambien en las versiones más recientes de Bind existen varias soluciones incluyendo el llamado “Response Rate Limit” para limitar el número de respuestas que un servidor de DNS puede tener ante las consultas de DNS y como poder “aliviar” estas consultas., este parche se comenta en la presentación antes comentada de los grupos de trabajo de 2013.

Por favor intentar corregir el problema, si estos equipos no son los servidores de DNS oficiales de vuestra organización bloquear el acceso al puerto 53/UDP desde el exterior (las conexiones vía TCP no pueden ser falsificadas con tanta facilidad) y avisar a los responsables del equipo para que apliquen los parches de seguridad oportunos.

Podeís tambien consultar con nuestros compañeros del NOC y la lista IRIS-DNS@listserv.rediris.es, si necesitaís más información.

Categories: Incidentes Tags:

Ficheros borrados

jueves, 21 de marzo de 2013 Sin comentarios

 

 Ayer me llevé la desagradable sorpresa de que me había desaparecido del disco duro un archivo importante, al pasar un recuperador de archivos me encuentro que es irrecuperable porque esta sobre-escrito un archivo para mi desconocido (F:\User manuals\XXXX\fichero_bueno\UserManual.pdf ) ¿Eso es un virus? ¿Un intruso? Hay otros archivos sobreescritos de la misma forma.

 

 

Lo más normal es que no sea un problema de intrusiones /virus , sino el funcionamiento normal de como gestionan los sistemas operativos los ficheros una vez que son borrados.

Por lo general en todos los sistemas operativos los discos duros y dispositivos de almacenamiento se dividen en dos “zonas”, por un lado los datos , que ocupan la mayoría del espacio y por otro la información adicional para acceder a estos, nombre, etc, esta zona se suele llamar en algunos casos “el directorio” . podemos pensar en que un disco duro es una biblioteca, que tiene por un lado estanterías con libros (datos) y  por otro a la entrada hay un archivador con fichas  (por autor, titulo, temática) que nos indican en que estantería esta el libro. (Nota esto es un símil muy básico en los sistemas operativos modernos es más complejo).

Cuando un fichero se borra muchas veces el sistema operativo marca como “libre” la zona de datos y por otro lado solo pone una “muesca” en la información de directorio diciendo que el fichero ha sido borrado, pero no se borran los datos.E sto es lo que emplean muchos sistemas para recuperar ficheros borrados, analizan la información de la entrada de directorio para intentar recuperar los datos, ya que solo están marcados como borrados, pero los datos por lo general si no se escribe mucho en el disco siguen estando ahí.

Por otro lado el sistemas operativo intenta optimizar el espacio disponible del disco duro y eso hace que muchas veces al grabar información se use el espacio que antes ocupaba otro fichero, ya que le pilla “más  a mano” . (depende mucho del sistema operativo, versión, etc.), aunque en la información del directorio

En resumen de toda esta parrafada , lo más normal es que lo que haya pasado es que el fichero se haya borrado y después al instalar algún programa se haya sobre escrito la información , de forma que no se pueda recuperar.

Por eso es muy importante hacer copias de seguridad de la información importante  y guardar copias incrementales antiguas , ya que si solo mantenemos la ultima copia podemos haber borrado la información antes.

A nivel técnico los libros  “File System Forensic Analysis”,de Brian Carrier , http://www.digital-evidence.org/fsfa/  y Forensic Discovery   de Dan Farmer y Wietse Venema (disponible ya en PDF), describen en profundidad los sistemas de ficheros de los principales sistemas operativos, así como herramientas que se pueden utilizar a bajo nivel para analizar estos.

 

DNSChanger , algunas nueces

miércoles, 11 de julio de 2012 Sin comentarios

 

Con el problema de seguridad de DNSChanger, ha habido mucha difusión mediatica y se indicaba que para muchos usuarios el día 9 de Julio iba a ser el cataclismo, al no funcionarles correctamente su conexión a Internet, en http://www.dcwg.org/ hay mucha más información sobre todo esto.

El problema venía siendo arrastrado desde hace mucho tiempo ya que muchos equipos de todo el mundo habían sido infectados y el “virus/gusano/troyano,etc” había cambiado los DNS para apuntar a unos controlados por los atacantes, que aprovechaban las consultas para falsear las consultas, de forma que podían redigir a voluntad las consultas de DNS, por ejemplo haciendo que al buscar www.tubanco.es fueras a otra dirección de internet.

Desde  finales del año pasado el FBI intervino estos servidores y todo el tráfico de DNS era respondido correctamente , pero el mandado judicial acababa este 9 de Julio, por lo que desde RedIRIS se planteo mitigar el problema interceptando las consultas a los servidores que iban a dejar de funcionar y poniendo nosotros un servidor que respondiera (y registrara) las consultas.

Al final desde luego ha habido mucho ruido pero pocas “nueces”, ya que al final había menos de 15 equipos infectados en toda la red de RedIRIS (unos 2 Millones de direcciones IP ), por lo que no parece significativo el número de infecciones.

Gracias a tener registrado las consultas que hacen las máquinas sin embargo hemos podido encontrar algunas “nueces” interesantes como las siguientes:

Un equipo todavía infectado por un conficker.

Conficker es un gusano con más de dos años de actividad que se intenta conectar periodicamente a un equipo para recibir instrucciones, los  nombre de los equipos a los que se intenta conectar se  generan de forma pseudo-aleatoria cada día ,  en http:// confickerworkinggrou.org hay más información incluyendo unas gráficas sobre el número de infecciones que se detectan cada día. ( http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/InfectionTracking  )

Viendo las consultas se se aprecia una máquina haciendo consultas al DNS  buscando dominios “bastante raros” (la IP origen se ha cambiado a AAA.BB.CC.144 ).
2012-07-05 19:48:55.400426 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:61962+ A? zcgqlzyo.ws. (29)
2012-07-05 19:49:00.556635 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:59401+ A? lrgrbypi.com. (30)
2012-07-05 19:49:12.853223 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:19720+ A? kodutaunnpx.ws. (32)
2012-07-05 19:49:23.056254 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain:40718+ A? cxxejithkhp.info. (34)
2012-07-05 19:49:28.227979 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8462+ A? zcrfcywrlh.biz. (32)
2012-07-05 19:49:38.430740 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 40973+ A? ojbpb.net. (27)
.....
2012-07-06 09:37:48.887692 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 8191+ A? ksccwristsl.com. (33)
2012-07-06 09:37:56.168755 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 50429+ A? zakoeer.ws. (28)
2012-07-06 09:38:01.324965 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 46588+ A? temvb.info. (28)
2012-07-06 09:38:06.574691 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 19708+ A? bbiiz.ws. (26)
2012-07-06 09:38:11.777818 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 4578+ A? dtvlrhl.info. (30)
2012-07-06 09:38:16.934003 IP AAA.BB.CC.DDD.1025 > 85.255.113.118.domain: 9185+ A? sclmyhiyxa.biz. (32)

Otro caso curioso  que aparece en los logs es este:

2012-07-09 19:31:28.150676 IP AAA.BB.CC.17.35627 > 67.210.14.61.domain: 19061+ MX? att.net. (25)
2012-07-09 19:31:28.270993 IP AAA.BB.CC.17.35634 > 67.210.14.62.domain: 64862+ A? scc-mailrelay.att.net. (39)
2012-07-09 19:31:28.481642 IP AAA.BB.CC.17.35656 > 67.210.14.61.domain: 13448+ MX? rocketmail.com. (32)
2012-07-09 19:31:28.550584 IP AAA.BB.CC.17.35662 > 67.210.14.62.domain: 51788+ MX? aol.com. (25)
2012-07-09 19:31:30.071473 IP AAA.BB.CC.17.35738 > 67.210.14.61.domain: 32104+ A? mx1.rog.mail.yahoo.com. (40)
2012-07-09 19:31:30.311212 IP AAA.BB.CC.17.35753 > 67.210.14.62.domain: 27165+ A? fpo.mail.dk. (29)
2012-07-09 19:32:23.634079 IP AAA.BB.CC.17.37220 > 67.210.14.62.domain: 20212+ MX? talktalk.net. (30)
2012-07-09 19:32:23.970319 IP AAA.BB.CC.17.37255 > 67.210.14.62.domain: 58452+ MX? kodel.com. (27)
2012-07-09 19:32:24.134301 IP AAA.BB.CC.17.37273 > 67.210.14.62.domain: 44514+ MX? vocollect.com. (31)
2012-07-09 19:32:24.853948 IP AAA.BB.CC.17.37339 > 67.210.14.62.domain: 39530+ MX? uchicago.edu. (30)
.....
2012-07-10 13:20:10.089107 IP AAA.BB.CC.17.49746 > 67.210.14.61.domain: 63686+ MX? yahoo.co.uk. (29)
2012-07-10 13:20:10.128946 IP AAA.BB.CC.17.49750 > 67.210.14.62.domain: 34710+ A? mx-eu.mail.am0.yahoodns.net. (45)
2012-07-10 13:20:12.159913 IP AAA.BB.CC.17.49762 > 67.210.14.61.domain: 64173+ MX? verizon.net. (29)
2012-07-10 13:20:12.239307 IP AAA.BB.CC.17.49766 > 67.210.14.62.domain: 27468+ MX? btinternet.com. (32)
2012-07-10 13:20:12.568931 IP AAA.BB.CC.17.49778 > 67.210.14.61.domain: 37659+ MX? wanadoo.fr. (28)
2012-07-10 13:20:13.268954 IP AAA.BB.CC.17.49782 > 67.210.14.62.domain: 31907+ MX? orange.fr. (27)
2012-07-10 13:20:13.429057 IP AAA.BB.CC.17.49796 > 67.210.14.61.domain: 64758+ MX? yahoo.com. (27)
2012-07-10 13:20:13.488950 IP AAA.BB.CC.17.49799 > 67.210.14.62.domain: 51148+ A? mta6.am0.yahoodns.net. (39)
2012-07-10 13:20:25.361551 IP AAA.BB.CC.17.49814 > 67.210.14.61.domain: 12389+ MX? sbcglobal.net. (31)

Donde se aprecia que el equipo, (que no es un servidor de correo) esta haciendo muchas consutas de DNS de tipo “MX”,  una análisis en mas detalle indica que este equipo, un Linux parece estar comprometido y se esta empleando para enviar SPAM.

También  posible “adivinar” si el equipo infectado en cuestión es un “Mac” e incluso si tiene el IPv6 activado o no, de otro de los equipos infectados:

2012-07-05 20:05:04.088957 IP AAA.BBB.CC.187.49974 > 85.255.115.155.domain: 41711+ PTR? b._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (58)
2012-07-05 20:05:04.089648 IP AAA.BBB.CC.187.61248 > 85.255.115.155.domain: 33128+ PTR? db._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:05:04.089887 IP AAA.BBB.CC.187.63188 > 85.255.115.155.domain: 54465+ TXT? cf._dns-sd._udp.0.CC.BBB.AAA.in-addr.arpa. (59)
2012-07-05 20:06:27.569295 IP AAA.BBB.CC.187.57867 > 85.255.115.155.domain: 4630+ PTR? 187.CC.BBB.AAA.in-addr.arpa. (45)
2012-07-05 20:06:27.609607 IP AAA.BBB.CC.187.62491 > 85.255.115.155.domain: 39982+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.8.1.e.4.Y.Y.Y.Y.X.X.X.X.ip6.arpa. (90)
2012-07-05 20:06:27.653437 IP AAA.BBB.CC.187.60475 > 85.255.115.155.domain: 62266+ PTR? 8.3.9.b.9.d.e.f.f.f.f.d.e.1.a.f.b.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. (90)
2012-07-05 20:06:27.679686 IP AAA.BBB.CC.187.59874 > 85.255.115.155.domain: 13440+ PTR? 1.195.168.192.in-addr.arpa. (44)
2012-07-05 20:06:27.695459 IP AAA.BBB.CC.187.52476 > 85.255.115.155.domain: 22310+ PTR? 1.124.168.192.in-addr.arpa. (44)

Se observa que el equipo hace muchas consultas vía DNS de tipo PTR y TXT a una zona “in-addr.arpa” algo especial , buscando por ahí son consultas típicas del protocolo “Bonjour” de Apple,  http://www.dns-sd.org/ ,  ( 4 primeras lineas ), además el equipo hace conexiones a zonas “ip6.arpa” , lo que indica que además tiene activado el IPv6  (siguientes dos lineas ) y por ultimo las dos ultimas lineas preguntando por la inversa dentro de un rango privado (192.168.124.1) parecen indicar que el equipo se encuentra detras de algún tipo de router / NAT .

 

Categories: Incidentes Tags: , ,