Archivo

Archivo del autor

Ataques de amplificación de tráfico: NTP

viernes, 21 de febrero de 2014 Comentarios desactivados

Durante el año 2013 se ha generalizado el uso de protocolos distintos al tradicional DNS a la hora de realizar ataques de denegación de tráfico, el ultimo protocolo que se esta usando es Network Time Protocol (NTP), empleado para que los equipos estén sincronizados a nivel horario.

Ya se comentó anteriormente est tipo de ataques, que se basan en dos situaciones bastante frecuentes,  una normal y otra debida sobre todo a malas configuraciones.

Es habitual y normal que haya muchas peticiones de tráfico que no sean balanceadas (se reciba más información que la que se solicita),esto ocurre en la mayoria de las situaciones (ver un video por internet, acceder a una página WWW, etc), por lo general somos “consumidores” de información y recibimos más información de internet que la que enviamos hacia fuera.

Para la mayoría de los protocolos esta situación no genera problemas de amplificación de tráfico ya que emplean un protocolo orientado a conexión como es TCP, en el cual se establece una negociación entre los equipos antes de enviar información, pero hay otros protocolos como ICMP o UDP que no son orientados a conexión .

Aquí interviene después la segunda situación que es la posibilidad de que un equipo genere tráfico con una dirección IP que no le corresponde (falsificación de direcciones, Spoofing, etc), y que este tráfico llegue hasta Internet.

Como comentábamos el documento de buenas prácticas BCP 38 , http://tools.ietf.org/html/bcp38  comentaba hace casí 15 años la necesidad de que las organizaciones filtraran el tráfico en origen , de forma que este  trafico no deseado no llegue a internet. Este  filtrado fue evolucionando de las tradicionales listas de acceso en los routers a técnicas como el “Reverse Path Forwarding”, (RPF),  implementado en los routers de la mayoria de los fabricantes, como Cisco,  o Juniper  , así en la mayoría de los sistemas operativos   (Linux, *BSD*,etC) , cortafuegos (Fortinet, Paloalto, …).

Por lo general las instituciones conectadas a RedIRIS ya tienen aplicados estos filtros y además en el backbone se realizan comprobaciones adicionales pero se puede colaborar con proyectos como spoofer  para comprobar si una red es susceptible de ser utilizada en ataques DDOS.

Estos ataques de denegación de servicio seguirán existiendo mientras haya redes que permitan la falsificación de tráfico ,aunque en el caso de NTP es algo más complicado y peligroso por diversos factores :

  • NTP es usado por muchos sistemas a la hora de mantener una sincronización horaria, necesaria para diversos protocolos  de enrutamiento , verificación de tiempos de espera y de vida de una conexión, etc. Por eso es crítico en muchos entornos.
  • Muchos servidores de NTP, sobre todo los empleados en enrutadores y commutadores no tienen la posibilidad de filtrar las peticiones de consulta “privilegiadas” en la versión del sistema operativo que están corriendo, por lo que hay que aplicar filtros para impedir su uso desde el exterior.
  • En muchas organizaciones como hardware para correr el servicio de NTP se utilizan enrutadores que disponen de varias direcciones IP (por los distintos interfaces) por lo que es necesario aplicar los filtros en todos los interfaces del equipo .

En el caso de NTP el problema es debido a que los servidores que permiten los paquetes en modo 7  (administrativo) desde otros hosts pueden recibir consultas para obtener una lista de los ultimos 600 servidores/clientes que han obtenido tiempo del servidor en cuestión. Esto puede realizarse mediante el comando monlist de la ultilidad ntpdc.

De esta forma un paquete comando de unos pocos bytes obtiene una respuesta de varios miles de bytes que pueden llegar a saturar el servidor y la red.

Existen 3 soluciones recomendadas a nivel de equipo que es servidor de NTP:

  1.   Actualizar el servicio ntp a versiones posteriores a la 4.2.7p26.
  2.   Deshabilitar el monitor. En el fichero de configuración añadir una linea “disable monitor”
  3.  Añadir “noquery” en la lista de restricciones por defecto y despues permitirla a las maquinas que interese             que reciban esa informacion.
      restrict -4 default noquery
      restrict -6 default noquery

Estas dos lineas anteriores evitaran que se ignoren los paquetes en modo 6 y 7 tanto para IPv4 como IPv6.

Referencias:

Por otro lado es aconsejable que aplique a nivel de red los filtros apropiados para evitar que se acceda desde el exterior de la organización a los servidores NTP que no sean públicos para evitar su uso en los ataques de denegación de servicio

 

Spam académico

martes, 20 de agosto de 2013 Comentarios desactivados

 

Algunos piensan que con esto de la crisis económica todo vale y que ya que recibimos spam todos los días el buscar de forma masiva direcciones de correo y emplear los servidor de listas de las organizaciones para la difusión de convocatorias de congresos, revistas, cursos y demás formas de conseguir financiación adicional o prestigio, yo personalmente creo que hay que hace hincapié en los responsables de las listas de correo internas de cada organización para evitar este tipo de comportamientos.

 

No se ve todos  los días , pero como mínimo una vez al mes se recibe  información desde listas de correo sobre masters, cursos, congresos y demás organizados por departamentos o centros de instituciones afiliadas, donde sin haberlo pedido en ningún momento me han incorporado a una lista de distribución.

Mención aparte merecen algunas organizaciones afiliadas a RedIRIS con difusión internacional que añaden de forma masiva a los usuarios extranjeros que acceden a una de sus cursos/conferencias y charlas y de los que recibimos diariamente quejas de algunos ISP estadounidenses.

 

Aparte de la mala imagen para la organización, generación de spam a los destinatarios, etc,  están los problemas de listas negras.  por lo que un uso irresponsable de los recursos que proporciona la organización pueden provocar perjuicios a otros usuarios  en un momento determinado.

Por favor. recordarle a los administradores de las listas de correo las normas de buen uso , gran parte de vosotros las tiene ya publicadas y aprobadas , por ejemplo en :https://www.google.es/search?q=rediris.es+listas+de+correo+normas&rlz=1C5CHFA_enUS503ES505&oq=rediris.es+listas+de+correo+normas&aqs=chrome.0.69i57j69i62l2.6272j0&sourceid=chrome&ie=UTF-8

 

Y explicitamente en RedIRIS en http://www.rediris.es/mail/abuso/ace.es.html  (perdonar por los tipos mime sin actualizar 😉  se indica claramente que este tipo de contenido viola varios de los puntos que desde RedIRIS se consideran contenido abusivo.

 

un saludo a todos

Categories: Incidentes Tags:

Rendimiento de equipamiento de seguridad en IPv6

martes, 6 de agosto de 2013 Comentarios desactivados

 

 

En  una reunión paralela al IETF 87 en Berlin , de un grupo de “hackers” interesados en la seguridad informática hubo una comparativa entre el rendimiento de algunos dispositivos de seguridad en IPv4 e IPv6, bastante completa y con varios sistemas de pruebas que se están haciendo ya.

En http://www.insinuator.net/2013/08/ipv6-hackers-meeting-ietf-87-in-berlin-slides/ están las presentaciones que se hicieron con varias pruebas.

Hay que indicar que se trata por lo general de equipamiento para redes pequeñas y no de equipamiento de backbone pero es interesante a la hora de saber como se comportan estos fabricantes a nivel de IPv6.

 

 

Categories: Información general Tags: ,

Ataques DDOS por amplificación de tráfico

viernes, 2 de agosto de 2013 Comentarios desactivados

 

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: Información general Tags: , ,

Ataques de DNS empleando servidores de DNS mal configurados

martes, 2 de julio de 2013 Comentarios desactivados

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: