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
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag1.html Página 2 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
IntroducciónAtáques básicosDenegación de ServicioSistemas Distribuidos de Denegación ServicioIntrusión DistribuidaConclusiones
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag2.html Página 3 de 36
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
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag3.html Página 4 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag4.html Página 5 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
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.
Sistemas Distribuidos de Denegación de Servicio
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.
Sistemas Distribuidos de Denegación de Servicio
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>
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag5.html Página 9 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag6.html Página 10 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag7.html Página 11 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag7.html Página 12 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag8.html Página 13 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag8.html Página 14 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag9.html Página 15 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag9.html Página 16 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag10.html Página 18 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag11.html Página 19 de 36
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.
Tipo de ataque: Generación masiva de tramas ICMP, SYN o UDP, así como Smurfing.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag11.html Página 20 de 36
20/11/2003
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag12.html Página 21 de 36
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).
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag12.html Página 22 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag13.html Página 23 de 36
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.
Agente: recibe la orden de realizar ataques contra una o más víctimas.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag13.html Página 24 de 36
20/11/2003
Tipo de ataque: Generación masiva de tramas ICMP, SYN o UDP, así como Smurfing.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag14.html Página 25 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag15.html Página 26 de 36
20/11/2003
Shaft
Estructura: similar a los anteriores
Se considera contemporáneo a TFN.
Cliente: controla a uno o más clientes.
Conductor: controla gran cantidad de demonios.
Agente: recibe la orden de realizar ataques contra una o más víctimas.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag15.html Página 27 de 36
20/11/2003
Tipo de ataque: Generación masiva de tramas ICMP, SYN o UDP, así como Smurfing.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag16.html Página 28 de 36
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)
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag17.html Página 29 de 36
20/11/2003
Mstream
Última en aparecer: 2º trimestre 2000
Estructura: similar a los anteriores
Cliente: controla a uno o más clientes.
Conductor: controla gran cantidad de demonios.
Agente: recibe la orden de realizar ataques contra una o más víctimas.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag17.html Página 30 de 36
20/11/2003
Tipo de ataque: Stream.
Sistemas Distribuidos de Denegación de Servicio
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag18.html Página 32 de 36
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
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag19.html Página 33 de 36
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
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag20.html Página 34 de 36
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.
Sistemas Distribuidos de Denegación de Servicio
http://www.fi.upm.es/~flimon/DDoS/pag21.html Página 35 de 36
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.
Top Related