sistemas distribuidos de denegación de servicio

Sistemas Distribuidos de Denegación de Servicio

http://www.fi.upm.es/~flimon/DDoS/ Página 1 de 36

20/11/2003

Sistemas Distribuidosde

Denegación de Servicio


http://www.fi.upm.es/~flimon/DDoS/pag1.html Página 2 de 36

20/11/2003


IntroducciónAtáques básicosDenegación de ServicioSistemas Distribuidos de Denegación ServicioIntrusión DistribuidaConclusiones



20/11/2003

Introducción

Ref. histórica: Mito de Casandra

Informático: Sabe lo que puede pasar. AvisaUsuario: Le da igual. Eso no puede ser verdadCuando ocurre algo: ¡A por el informático!

Mucho dinero y tiempo en infraestructura de alertasGlobalización real a través de Internet



20/11/2003

Ataques básicos

Años 80: el SS.OO. proporciona mecanismos suficientes para controlar lo que ocurría enuna máquina: last, who, ps, ...

Aparecen herramientas de borrado de huellas, y publicaciones electrónicas como alt.2600 y Phrack.

Elaboración de Troyanos sustitutos de programas básicos del sistema operativo.

Distribución de los root kit para diversas plataformas.

Aparición de mecanismos de verificación de autenticidad del software mediante checksum(RPM de Red Hat) o mecanismos más sofisticados.

Restablecer la confianza en un sistema asaltado: complejo, por no decir que imposible.



20/11/2003

Denegación de Servicio

Elaboración de métodos sofisticados: Spoofing, Hijacking o Smurfing.

Al estar mejor defendidos los sistemas, ya no es tan importante el entrar en ellos como elimposibilitar su acceso.

DoS: impedir que los usuarios puedan acceder a un determinado sistema.

Precedente: mail bombing.

Coordinación: telefónica, IRC. Lo que implicaba una capacidad limitada frente a grandessistemas.

TCP/IP v4 carece de mecanismos de seguridad para este tipo de ataques. Cuando se diseñóse pensaba sólo en ataques contra la infraestructura de comunicaciones.


http://www.fi.upm.es/~flimon/DDoS/spoofing.html Página 6 de 36

20/11/2003

Spoofing

Falsificación de la dirección IP origen del ataque.

Se emiten tramas IP con una dirección IP de origen falso, ya sea real o inventada.


http://www.fi.upm.es/~flimon/DDoS/hijacking.html Página 7 de 36

20/11/2003

Hijacking

Secuestro de la comunicación entre dos sistemas suplantando a uno de ellos.

Necesario estar situado en la ruta de comunicación.


http://www.fi.upm.es/~flimon/DDoS/smurfing.html Página 8 de 36

20/11/2003

Smurfing

Amplificación de peticiones broadcast.

Envío de trama ICMP con IP origen la víctima y como destino la dirección broadcast de lared atacada.

Por cada trama transmitida, contestarán a la víctima todos aquellos sistemas que tenganhabilitado el contestar a peticiones destinadas a broadcast.

FA (Factor de Amplificación): relación entre tramas recibidas por la víctima y tramastransmitidas.

Ejemplo: /usr/sbin/ping -s <dirección_IP_broadcast> 0 <n>



20/11/2003

Denegación de Servicio: ¿Por qué?

Posibilidad: millones de ordenadores integrados en Internet con escasa o nula seguridad.¡Ideal!

Calidad del software: programadores con escasa experiencia, menores plazos de desarrollo,software más complejo e insuficiente esfuerzo en control de calidad.

Prestaciones vs Seguridad: los propios usuarios reclaman prestaciones y no mejores nivelesde seguridad.

Personal no cualificado: imposible formar buenos administradores de sistemas en pocotiempo. Se contrata personal sin cualificación ni experiencia.

Defensa legal: Generalmente se internacionalizan los problemas, lo que suele traducirse enindefensión legal.



20/11/2003


Escenario: sofisticados mecanismos de coordinación y en ocasiones de comunicación,posibilidad de involucrar miles de ordenadores.

Resultados: ataques casi imposibles de repeler con los medios actuales.

¿Hipótesis?: realidad desde finales de 1999.

Nombres: Trinoo, Tribal Flood Network, TFN2K, Stacheldraht, Shaft, Mstream.



20/11/2003

Trinoo

17/AGO/99: red Trinoo de 227 ordenadores colapsa durante 2 días la red de la Universidadde Minnessota.

Atacante: controla a uno o más maestros.

Maestro: controla gran cantidad de demonios.

Demonio: recibe la orden de realizar ataques contra una o más víctimas.

Tipo de ataque: inundación por tramas UDP.



20/11/2003



20/11/2003

Trinoo (características)

Atacante > Maestro: 27665/TCP

Maestro > Demonio: 27444/UDP

Demonio > Maestro: 31335/UDP

Comunicaciones protegidas por claves simétricas.

El Maestro mantiene una lista de Demonios activos cifrada mediante Blowfish.

Ataque: se enlaza el servicio chargen de un sistema con el servicio echo de otra. Estaoperación se repite hasta que se logra colapsar la red.



20/11/2003



20/11/2003

Tribal Flood Network (TFN)

Estructura:

Atacante: controla a uno o más clientes.

Cliente: controla gran cantidad de demonios.

Demonio: recibe la orden de realizar ataques contra una o más víctimas.

Tipo de ataque: Generación masiva de tramas ICMP, SYN o UDP, así como Smurfing.



20/11/2003


http://www.fi.upm.es/~flimon/DDoS/syn.html Página 17 de 36

20/11/2003

SYN

Las trams SYN, o tramas de sincronización, son el inicio de una comunicación TCP:

En el caso de ataques por inundación de tramas SYN, se envían solicitudes de conexiónSYN hasta colapsar la cola de solicitudes.

Esto implica que el sistema atacado no puede llegar a atender a los clientes reales.



20/11/2003

TFN (características)

Atacante > Cliente: Conexión shell remoto a puerto TCP, UDP, ICMP, sesión SSH, o simpleTelnet a un puerto TCP determinado.

Cliente > Demonio: mediante tramas ICMP_ECHOREPLY

El acceso a los clientes no esta protegido.

Tanto los clientes como los demonios necesitan ejecutar con privilegios de root por utilizarsockets del tipo SOCK_RAW.

Cada cliente dispone de un fichero con las direcciones de los demonios. En las últimasversiones aparecía cifrado mediante Blowfish.



20/11/2003

Tribal Flood Network 2000 (TFN2K)

Estructura: similar a TFN, aunque cambia la terminología.

Atacante: controla a uno o más clientes.

Maestro: controla gran cantidad de demonios.

Agente: recibe la orden de realizar ataques contra una o más víctimas.




20/11/2003



20/11/2003

TFN2K (características)

Atacante > Maestro:Utilización aleatoria de tramas TCP, UDP o ICMP.

Maestro > Agente: Utilización aleatoria de tramas TCP, UDP o ICMP. Comunicación cifrada mediante algoritmo CAST-256 [RFC-2612]. La clave se define en

tiempo de compilación. La información cifrada se codifica en Base-64. Las tramas buenas se mezclan con tramas falsas a direcciones IP aleatorias.El maestro falsifica su dirección IP en las tramas que envía.

Los comandos nunca son confirmados.

Los comandos se codifican en un byte, viajando los parámetros en la zona de datos de latrama.

Los agentes intentan ocultarse cambiando el nombre del proceso para pasardesapercibidos.

¿Error de codificacion?:Al codificar en Base-64 siempre se añade una secuencia de entre 1 y 16 ceros, que en B64

aparece como 0x41 (A).



20/11/2003

Longitud de los paquetes UDP es 3 bytes superior a la declarada en las cabeceras. Longitud de las tramas TCP es siempre 0, según aparece en las cabeceras. Los checksum de las tramas TCP y UDP son incorrectos.



20/11/2003

Stacheldraht

Estructura: similar a los anteriores

Se considera la competencia a TFN2K.

Cliente: controla a uno o más clientes.

Conductor: controla gran cantidad de demonios.




20/11/2003




20/11/2003

Stacheldraht (características)

Cliente > Conductor: 16660/TCPAplicación Stacheldraht Term. Acceso mediante password. Cifrada mediante clave simétrica y Blowfish.

Conductor <> Agente: 65000/TCP, ICMP_ECHOREPLY

Novedad: posibilidad de actualización de los agentes.

Cada agente mantiene una lista de conductores que le pueden controlar. Cifrada conBlowfish. Si no existe utiliza una lista por defecto.

Periódicamente el agente envía trama ICMP_ECHOREPLY con ID 666 y datos "skillz" atodos los conductores conocidos.

Los conductores contestan mediante trama ICMP_ECHOREPLY con ID 667 y datos"ficken".

Este diálogo periódico permite detectarlo.



20/11/2003

Shaft


Se considera contemporáneo a TFN.






20/11/2003




20/11/2003

Shaft (características)

Cliente > Conductor: 20432/TCP

Conductor > Agente: 18753/UDP

Agente > Conductor: 20433/UDP

Novedad: utilización de tickets para control sobre los agentes.

Password y Ticket deben ser correctos para que un agente acepte peticiones.

Intenta camuflarse como un proceso normal dentro del sistema.

Especial interes por disponer de estadísticas: capacidad de generación de paquetes de losagentes.

Existe un cliente por defecto en los fuentes:#define MASTER "23:/33/75/28"Restando 1 al valor decimal de cada carácter ...23:/33/75/28 = 129.22.64.17 (electrochem1.echem.cwru.edu)



20/11/2003

Mstream

Última en aparecer: 2º trimestre 2000







20/11/2003

Tipo de ataque: Stream.


http://www.fi.upm.es/~flimon/DDoS/stream.html Página 31 de 36

20/11/2003

Stream

Agente > Víctima: envía TCP ACK a puertos aleatorios y dirección de remitente falsa(normalmente de otra red).

Víctima: contesta TCP RST al remitente a través del router.

Router > Víctima: ICMP indicando que el destinatario no existe.

Se consigue un elevado consumo de ancho de banda.

Ataque con único origen: pocos efectos.

Ataque con múltiples orígenes: saturación de la red.



20/11/2003

Mstream (características)

Cliente > Conductor: 6723/TCPAcceso mediante password.

Conductor > Agente: 7983/UDP

Agente > Conductor: 9325/UDP

Los agentes deben ejecutar el modo root por usar sockets tipo SOCK_RAW.

Cada conductor mantienen una lista de agentes activos.Codificacion de Caesar: 50 car. desplazamiento138.100.14.35 > cej`cbb`cf`eg



20/11/2003

Detección de DDoS

Solución definitiva: no existe.

Hardware: limitando anchos de banda por servicio.

Gestión de red: estableciendo filtros de entrada.

Administración de sistemas: herramientas de auditoría

National Infrastructure Protection Center (FBI): find_ddosU. Washington: gag y dds

Administración de sistemas: "todos jugamos"

RAZOR: Zombie Zapper

Prevención de riesgos:

SANS Institute: Guía sobre medidas de prevención



20/11/2003

Intrusión Distribuida

DDoS: avance significativo ... pero incompleto.

¿Cómo se realiza el proceso de siembra de demonios?

¿Sería posible automatizar el proceso?

Si esto fuera factible:

Rastreo sistemático de sistemas que cumplan determinadas características. [¡Ya ocurre!]

Siembra masiva en términos de segundos.

Posterior DDoS ... unos segundos más tarde.

Conclusión: "Donde ahora no hay nada ... ahora esta todo"

Este es el "estado del arte" en estos momentos.

¿Y en el futuro?:

Hacer que estas herramientas sean amigables ... aptas para todos los públicos.



20/11/2003

Conclusiones

No existe defensa activa eficaz.

Actuar a posteriori no es útil.

Sólo una fórmula: prevención.

Recomendaciones del CERT/CC

Mantener actualizados los sistemas informáticos.

Filtro de puertos y servicios no utilizados.

Implantación de software antivirus y detección de intrusión.

Creación de los Centros de Emergencia de Datos.



20/11/2003

¡Gracias!

Presentación:http://www.fi.upm.es/~flimon/DDoS

Artículo:http://www.fi.upm.es/~flimon/ddos.pdf

sistemas distribuidos de denegación de servicio

Technology