Archivo

Entradas Etiquetadas ‘DDOS’

NTP : no solo para la hora.

Viernes, 29 de Enero de 2016 Comentarios desactivados

El protocolo NTP es utilizado para la sincronización de la hora en los equipos, necesario no solo para tener los logs bien sincronizados, sino cualquier otra aplicación que requiere tener la hora “exacta”  (controles de acceso, tarificación, etc), de hecho casi todos los sistemas operativos modernos emplean este protocolo para la sincronización horaria.

Por desgracia el protocolo NTP emplea UDP a la hora de realizar las consultas, lo que hace que este siendo muy utilizado para los ataques de denegación de servicio, como ya se comento en  una entrada de este blog,  , estos ataques se basan sobre todo en la posibilidad de falsificar el tráfico IP (spoofing) en algunas redes para así lanzar ataques contra servidores, que muchas veces no tienen NTP.

Por ejemplo la siguiente gráfica muestra dos ataques empleando NTP contra una organización conectada a RedIRIS , el verde aparece el trafico HTTP y HTTPS , mientras que en azul es el trafico NTP.

ntp-ataque

Se puede ver que cuando se produce el trafico NTP se reduce el trafico de ambos protocolos debido a que la saturación de la conexión hace que no se pueda recibir el trafico .

Asi mismo se puede utilizar NTP y otros protocolos  para descubrir equipos con IPv6 aun cuando empleen direccionamiento aleatorio, si los atacantes son capaces de controlar alguno de los servidores intermedios que se emplean públicamente para esta sincronización, aprovechando que en muchas organizaciones no se tiene establecido una jerarquía de sincronización NTP sino que muchos equipos se sincronizan directamente con los equipos de NTP configurados por defecto en los diversos sistemas operativos.

Para mitigar un poco estos ataques desde RedIRIS se pueden aplicar medidas que limiten el trafico NTP en las conexiones de las instituciones afiliadas pero se requiere que  haya definido una jerarquía de servidores a nivel interno de la organización y con RedIRIS de forma el número de equipos que realizan consultas NTP al exterior sea reducido.

Dentro de poco se ira públicando una serie de recomendaciones para la configuración de NTP en las instituciones afiliadas a RedIRIS.

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

 

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: , ,