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 Distribuidos
de
Denegación de Servicio

http://www.fi.upm.es/~flimon/DDoS/pag1.html Página 2 de 36
20/11/2003
Introducción
Atáques básicos
Sistemas Distribuidos de Denegación Servicio
Intrusión Distribuida
Conclusiones

20/11/2003
Introducción
Ref. histórica: Mito de Casandra
Informático: Sabe lo que puede pasar. Avisa
Usuario: Le da igual. Eso no puede ser verdad
Cuando ocurre algo: ¡A por el informático!
Mucho dinero y tiempo en infraestructura de alertas
Globalizació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 en
una 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
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 el
imposibilitar 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 grandes
sistemas.
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 la
red atacada.
Por cada trama transmitida, contestarán a la víctima todos aquellos sistemas que tengan
habilitado el contestar a peticiones destinadas a broadcast.
FA (Factor de Amplificación): relación entre tramas recibidas por la víctima y tramas
transmitidas.
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 niveles
de seguridad.
Personal no cualificado: imposible formar buenos administradores de sistemas en poco
tiempo. Se contrata personal sin cualificación ni experiencia.
Defensa legal: Generalmente se internacionalizan los problemas, lo que suele traducirse en
indefensió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 Universidad
de 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. Esta
operació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ón
SYN 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 simple
Telnet 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 utilizar
sockets del tipo SOCK_RAW.
Cada cliente dispone de un fichero con las direcciones de los demonios. En las últimas
versiones 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 la
trama.
Los agentes intentan ocultarse cambiando el nombre del proceso para pasar
desapercibidos.
¿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/TCP
Aplicació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 con
Blowfish. Si no existe utiliza una lista por defecto.
Periódicamente el agente envía trama ICMP_ECHOREPLY con ID 666 y datos "skillz" a
todos 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)
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 los
agentes.
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)
Acceso 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. desplazamiento
138.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_ddos
U. 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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Sistemas Distribuidos de Denegación de Servicio

Similar a Sistemas Distribuidos de Denegación de Servicio (20)

Más de Alan Resendiz

Más de Alan Resendiz (11)

Último

Último (20)

Sistemas Distribuidos de Denegación de Servicio