Mas acerca de ICMP y Taller TCP/IP

Topología de redes, usos de las redes...

Moderador: Moderadores

Mas acerca de ICMP y Taller TCP/IP

Notapor Vic_Thor » Mar Ene 01, 2008 4:10 pm

Feliz año a tod@s!!!

Veo que muchos estáis siguiendo las prácticas del Taller TCP/IP y hay bastante interés en ello, gracias por leeros ese tocho ;)

Os presento tres utils que son bastante interesantes:

Código: Seleccionar todo
icmp-reset
icmp-mtu
icmp-quench

las podéis descargar de: http://www.gont.com.ar/tools/icmp-attacks/index.html

Las tres persiguen un mismo objetivo, provocar un DoS o degradar la conexión de un cliente de red cualquiera, son fáciles de usar (las tres siguen practicamente las mismas opciones), de instalar y sus resultados son francamente "entretenidos"

Las descargamos y accedemos a dicho directorio

Hacemos un gunzip *.gz de ellas y luego

Código: Seleccionar todo
tar -xvf icmp-mtu.tar
tar -xvf icmp-quench.tar
tar -xvf icmp-reset.tar

se crearan nuevos directorios, icmp-reset, icp-quench e icmp-mtu

las tres se compilan del mismo modo: sencillamente un make sobre el directorio de cada una de las utilidades.

Bien, generalidades de cada una de ellas (opciones)

Las opciones son similares, que son:

-c ipdelcliente y opcionalmente el puerto, ejemplos:
-c 192.168.0.20
-c 192.168.0.20:1024
-c 192.168.0.20:1024-4999

-s ipdelserver y opcionalmente el puerto, ejemplos:

-s 192.168.0.1
-s 192.168.0.1:1024
-s 192.168.0.1:1027-4999

-t seguido de las palabras server ó client dependiendo de como queramos que se comporte

-t server
-t client

-f seguido de la ip origen (se puede falsificar, ipspoofing) si no se indica se usará la nuestra

-f 192.168.0.123

-n no falsifica el origen, lo contrario a la anterior, no le siguen parametros algunos

-r seguido de un valor expresado en Kilobits, se utiliza para "reducir" el ancho de banda de la víctima hasta un máximo aproximado del valor que pongamos, por ejemplo:

-r 56 (la conexión se degrada a 56Kb mas o menos)

Estas opciones trabajan de forma similar en todas las utilidades icmp-****** hay otras mas específicas, -z tamaño del paquete IP, -l TTL, -q numero de secuencia, -o Tipo de servicio (TOS), -d retardo, etc... pero con las descritas anteriormente tenemos suficiente.

Como habéis seguido el post del Taller TCP/IP no habrá ningún problema en esto de entender los numeros de secuencia TCP, el TTL, TOS y demás zarandajas de estas


ICMP RESET
==========


icmp-reset está pensada para cerrar conexiones TCP abiertas entre un cliente y un server mientras que icmp-quench y icmp-mtu buscan una degradación en el rendimiento de la red, ya sea del lado del cliente (-t client) o del lado del servidor (-t server)

Es decir, por ejemplo, en un icmp-reset, quien cierra la conexión??? pues si hemos especificado -t client será el cliente, si especificamos -t server, será el servidor

icmp-reset necesita enviar cerca de 4000 paquetes y unos 12 segundos para que la conexión sea cerrada, paciencia..... por lo demás su uso es simple y fácil de entender, ejemplo:

Supongamos un equipo que se conecta por Terminal Services o escritorio remoto a un server:

Cliente: 172.28.0.111
Servidor: 80.80.80.80

Una sintaxis posible sería:

Código: Seleccionar todo
icmp-reset -c 172.28.0.111 -s 80.80.80.80:3389 -t client -r 64


como ves no sabemos el puerto origen del cliente (si del servidor, claro) podríamos probar con los puertos dinámicos en Windows 2000 y anteriores

Código: Seleccionar todo
icmp-reset -c 172.28.0.111:1024-4999 -s 192.168.0.1:80 -t client -r 128


o bien, para Windows XP, 2003, Vista y muchos otros sistemas operativos:

Código: Seleccionar todo
icmp-reset -c 172.28.0.111:49152-65535 -s 192.168.0.1:80 -t client -r 128


o una salvajada.... total, por probar ;)

Código: Seleccionar todo
icmp-reset -c 172.28.0.111:1024-65535 -s 192.168.0.1:80 -t client -r 128


observa -t client t -r 128, esto degrada la conexión o ajusta el ancho de banda a 128Kbits y será el cliente quien cerrará y/o perderá la conexión TCP

ICMP MTU
========

Su uso es idéntico a icmp-reset, solo que en lugar de cerrar la conexión esta herramienta busca reducir el rendimiento de la conexión, siguiendo el ejemplo anterior:

Código: Seleccionar todo
icmp-mtu -c 172.28.0.111 -s 80.80.80.80:3389 -t client -r 64


Sin embargo, creo que hay que explicar su funcionamieto,porque teclear eso sin más lo sabe hacer cualquiera, pero el objetivo del Taller TCP/IP y de este post es "saber cómo funcionan las cosas", empezamos:

IP es un protocolo de máximo esfuerzo, pensado para poder "llegar" hasta cualquier tecnología de red "cueste lo que cueste"

Como no todas las redes son iguales, no todas tienen el mismo mtu (Unidad Máxima de Transmisión)

El MTU vamos a imaginarlo como un autobús, uno de 60 plazas necesitará menos viajes para llevar a 240 personas que otro de 25, lógico no?? a mayor cantidad de plazas menos viajes, menos tiempo, menos recursos, etc...

El MTU está íntimamente relacionado con la fragmentación, para llevar a 240 personas en autobuses de 60 plazas "hay que dividirlas" en grupos y poner tantos autobuses como sean necesarios, esto es 240 / 60 = 4 autobuses

Si el autobús es de 25 plazas pues se necesitarían al menos 10 autobuses, como ves a menor MTU mayor fragmentación.

Los encargados de hacer los grupos de personas son los routers, ellos ajustan los paquetes a la MTU de la red a la que están conectados.

La fragmentación es necesaria y como ves tiene muchos inconvenientes.... A principios de los 90 se desarrollaron proyectos para que la fragmentación no fuese necesaria, el "ganador del concurso" fue esta idea:

Calcular los MTU de todas las redes por las que debe pasar un paquete y ajustar el MTU al valor mas pequeño, esto viene implementado en las pilas TCP/IP de los sistemas operativos actuales.

Por ejemplo:

RED1.......MTU 1500
RED2.......MTU 2536
RED3.......MTU 23820

Pues teniendo encuenta esto, los paquetes en origen se colocan en "autobuses" de 1500 plazas, al ser el mas pequeño de los tres.

Por ejemplo, el protocolo 802.11g (el WiFi, jajaj) utiliza MTU's mas grandes seguro que habrás visto mas de una vez unos valores en tu tarjeta o punto de acceso que dicen:

Fragmentation Threshold: (Default: 2346, Range: 256 - 4096)
RTS Threshold: RTS Threshold: (Default: 2347, Range: 0 - 4096)


Eso en definitiva no es otra cosa que las plazas de los autobuses WiFi ;)

Sin embargo la red Ethernet utiliza un MTU de 1500, es menor, portanto cuando conectamos los equipos wireless a la red cableada, el punto de acceso o la propia tarjeta de red inalámbrica ajusta el valor a 1500, entendido no???

Otro ejemplo de eso es cuando usamos pppoe, se ajustan los mtu de ppp a 1500 que es máximo de la trama ethernet...

Las pilas TCP/IP ajustan los paquetes a 1500 bytes de MTU y los marcan con un bit DF a cero, que quiere decir No Fragmentar (el famoso bit DF de las flags de IP)

Cuando un router recibe un paquete en cuyo encabezado IP existe el bit DF activado (a 1), lo descarta y envía un icmp de tipo 3 y código 4 al origen

Ya te estarás preguntando como diántre se sabe el MTU de todas las redes de antemano, pues la respuesta es "no se sabe", entonces?

Entran nuevos nuevos actores en la película.... Next-Hop-MTU-Path y Path MTU discover

Esto funciona así, mas o menos:

Todo host que quiera transmitir lo hará con el bit DF a cero y ajusta el paquete al MTU de su red, es decir, si es muy grande, será el host quien lo fragmente para ajustarlo al MTU de su red y no será el router quien haga esto.

Si ese paquete fuese demasiado grande cuando pasa por un router cualquiera, el router implicado envia un mensaje NEXTHopMTU con el valor límite de la red y será el host quien se adaptará al nuevo entorno, fragmentando el paquete en otros mas pequeños y con el DF a cero de nuevo.

En resumidas cuentas, imagina que el router es como un intercambiador de autobuses, como hacer trasbordo de una estación a otra.... en origen sale un autobus con 50 personas, llega a la parada de intercambio (el router) y resulta que los autobuses que usa esa nueva línea son de 20 plazas, pues el router informa al origen para que le envíen pasajeros de 20 en 20 y no de 50 en 50, ok??

Si hemos comprendido bien todo esto, el ataque está servido y fácil de entender, consiste en hacer creer al host que envia que está transmitiendo paquetes demasiado grandes para llegar al destino sin ser fragmentados, informándole que disminuya el tamaño de los mismos, es decir, es el cliente quien hace autobuses de menos plazas.

Qué ocurre entonces??

Primero, está mas entretenido ajustando las plazas
Segundo, muchos mas paquetes y mas pequeños, con lo que toca recomponerlos
Tercero, todo va mas despacio.

El tamaño mínimo del NextMTUpath es de 68 (que frente a los 1500 hipotéticos es bastante degradación) y se puede ajustar con la opción -m de la herramienta icmp-mtu

ejemplo:

Código: Seleccionar todo
icmp-mtu -c 172.28.0.111 -s 80.80.80.80:3389 -t server -r 64 -m 68


Esto provocará una disminución altísisma que frecuentemente se traduce en una pérdida de conexión, eso sí... observa una cosa... he puesto -t server en lugar de -t client como antes... obvio, puesto que es el server quien informa del nuevo MTU al cliente y no alrevés.

Bueno, creo que ha quedado bastante clarito...

ICMP-QUENCH
===========


Esto es muy, muy, pero que muy parecido a lo descrito para MTU, sólo que los mensajes source quench normalmente los envían los routers (-t server) para informar a sus clientes que dismunuyan "la cantidad de autobuses" y no el número de plazas por cada autobús, es decir, los mismos autobuses, con las mismas plazas pero a menor velocidad.

En condiciones normales se envía este tipo de mensaje porque el buffer o memoria del router está al límite y le pide a sus clietes... "por favor, mas despacito que estoy muy ocupado...."

El resultado es que el host envía paquetes mas lentamente y por tanto la conexión se entorpece o se pierde en el limbo... por lo demás, igual....

Código: Seleccionar todo
icmp-quench -c 172.28.0.111 -s 80.80.80.80:3389 -f 172.28.0.1 -t server -r 64


Se ha incluido la ip del router -f 172.28.0.1 como origen de los paquetes ;)

Nada mas, que ya está bien...

Lo dicho, Feliz Año!!!
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Notapor Arakiss » Mar Ene 01, 2008 4:21 pm

Mil gracias Vic_Thor seguro que nos vendra muy bien a todos,como siempre tus trabajos son excelentes ;) .

Saludos y feliz año!
Avatar de Usuario
Arakiss
<|:-D
<|:-D
 
Mensajes: 1335
Registrado: Mié Ene 11, 2006 3:41 pm
Ubicación: Madrid

Re: Mas acerca de ICMP y Taller TCP/IP

Notapor Ramms+ein » Mar Ene 01, 2008 6:50 pm

Vic_Thor escribió:Veo que muchos estáis siguiendo las prácticas del Taller TCP/IP y hay bastante interés en ello, gracias por leeros ese tocho ;)


Gracias a tí por currártelo tanto.

Ahora mismo pruebo esto!!
<--! Mit diessem herz hab ich die macht -->
Avatar de Usuario
Ramms+ein
:-D
:-D
 
Mensajes: 56
Registrado: Mié Abr 19, 2006 12:52 am
Ubicación: - No Mundo -

Notapor disturb » Mar Ene 01, 2008 7:01 pm

Gracias Vic!
disturb
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 2253
Registrado: Mié Ene 26, 2005 5:30 pm
Ubicación: Málaga

Notapor KuArMaN » Mar Ene 01, 2008 7:16 pm

Qué grande! gracias!
Mi Blog

Imagen

Imagen
Avatar de Usuario
KuArMaN
<|:-)
<|:-)
 
Mensajes: 939
Registrado: Mié Jul 12, 2006 4:24 pm
Ubicación: I'm from Hell.

Notapor NeTTinG » Mié Ene 02, 2008 3:55 pm

Hola:

Muy interesante. Gracias, Vic! ;)

A Fernando Gont ya lo conocía, escribió varios artículos en la revista @rroba sobre protocolos y su seguridad.

Un saludo.

PD: Le he puesto un Post-it ;)
| Blog NeTTinG | Proyecto Destripando iOS |
_____________________________
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas. (Albert Einstein)
Todos recaerán en la necesidad de conocer la única y presumible verdad que el gran embudo emana. (Sire Netting)
Avatar de Usuario
NeTTinG
Wadalbertita
Wadalbertita
 
Mensajes: 6272
Registrado: Mar Sep 20, 2005 5:54 pm
Ubicación: Bajo la trampilla del décimo primer piso.

Notapor SLaYeR » Mié Ene 02, 2008 4:19 pm

Vic, cada vez que dejas tu huella por el foro me dejas de piedra ;)

Gracias!
ImagenImagen "Happy Hacking". Richard Stallman

Cuando la oscuridad nuble tu mente, que la paranoia sea tu guía.

Déjate caer por mi blog
SLaYeR
-<|:·þ
-<|:·þ
 
Mensajes: 2022
Registrado: Lun Sep 12, 2005 9:02 pm
Ubicación: Cuando crees que me ves cruzo la pared...

Notapor Yorkshire » Mié Ene 02, 2008 4:33 pm

Al compilar me sale este aviso:
Código: Seleccionar todo
usuario@pc1:~/hack/icmp-reset$ make
gcc -Wall -D_BSD_SOURCE -c icmp-reset.c
icmp-reset.c: En la función ‘main’:
icmp-reset.c:129: aviso: el puntero que apunta en la asignación difiere en signo
gcc -Wall -D_BSD_SOURCE -o icmp-reset icmp-reset.o

Me ocurre con las tres utilidades, pero me compila.

Sin embargo, hago:
Código: Seleccionar todo
root@pc1:/home/usuario/hack/icmp-reset# ./icmp-reset -c 192.168.1.113 -s 192.168.1.10:3389 -t client -r 64

y no termina nunca ni me cierra la conexión con el TS. :roll:

El 192.168.1.113 es un linux (desde donde ejecuto la instrucción) con una conexión activa a Terminal Server y el 192.168.1.10 es el w2k3 Server EE que proporciona los servicios de TS.

Sigo haciendo pruebas.

Gracias Vic_thor!
Linux registered user #346840
Avatar de Usuario
Yorkshire
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 4488
Registrado: Mié Ene 26, 2005 5:05 pm
Ubicación: -<|:-P[G]

Notapor disturb » Mié Ene 02, 2008 5:14 pm

A mi directamente no me compila...

Código: Seleccionar todo
$ make
gcc -Wall -D_BSD_SOURCE -c icmp-reset.c
icmp-reset.c: In function `main':
icmp-reset.c:131: error: `ICMP_UNREACH_PROTOCOL' undeclared (first use in this function)
icmp-reset.c:131: error: (Each undeclared identifier is reported only once
icmp-reset.c:131: error: for each function it appears in.)
icmp-reset.c:591: error: dereferencing pointer to incomplete type
icmp-reset.c:591: error: `ICMP_UNREACH' undeclared (first use in this function)
icmp-reset.c:592: error: dereferencing pointer to incomplete type
icmp-reset.c:596: error: dereferencing pointer to incomplete type
icmp-reset.c:597: error: dereferencing pointer to incomplete type
make: *** [icmp-reset.o] Error 1
disturb
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 2253
Registrado: Mié Ene 26, 2005 5:30 pm
Ubicación: Málaga

Notapor Ramms+ein » Mié Ene 02, 2008 8:34 pm

He estado probando el icmp-reset, sin embargo en el README.es explica para el -r esto:

Código: Seleccionar todo
La opcion "-r" permite limitar el ancho de banda a ser utilizado por el
ataque (en kbps). En este caso, estariamos limitando el ancho de banda
utilizando para el ataque en 10 kbps (obviamente, se trata de una
estimacion). Esta opcion es util en caso que algun router intermediario
este limitando el ancho de banda utilizado por el protocolo ICMP, y como
consecuencia pueda descartar aquellos paquetes que superen un nivel
predeterminado. Tambien puede ser util en caso que alguno de los sistemas
intervinientes no pueda dar a basto para procesar los paquetes generados
por la herramienta,  y como consecuencia descarte algunos de ellos.


La verdad es que tiene más sentido que limitar la velocidad a "x" kbps cuando lo que queremos es cerrar la conexión previamente establecida.

Respecto a las experiencias que he tenido, la verdad es que resetear si que me ha reseteado la conexión (ssh, broadcasting...). El problema es que me provoca casi un DoS en el cliente. Por ejemplo pongo que intente cerrar una conexión establecida con el servidor de música:

Cliente = 192.168.1.21 :1419-1421
Servidor = 192.168.1.2:8888

Código: Seleccionar todo
 ./icmp-reset -v -s 192.168.1.2:5454 -c 192.168.1.21:2222-2224 -t client -r 1


Como veis esos puertos no estan realmente conectados, pero todas las conexiones se me cierran/ralentizan hasta extremos intolerables :( . He intentado reducirla con el parámetro -r 1, pero nada.

El escenario de pruebas es un server desde el que ejecuto la herramienta contra un cliente conectado vía wireless al router/switch/AP.

¿Alguién más lo ha probado?

PD. A mi me ha compilado sin problemas en Xubuntu Feisty.
Última edición por Ramms+ein el Mié Ene 02, 2008 8:37 pm, editado 1 vez en total
<--! Mit diessem herz hab ich die macht -->
Avatar de Usuario
Ramms+ein
:-D
:-D
 
Mensajes: 56
Registrado: Mié Abr 19, 2006 12:52 am
Ubicación: - No Mundo -

Notapor Death_Master » Mié Ene 02, 2008 8:59 pm

Jajajaja, Víctor tío, tú no duermes, ¿verdad?

Estás hecho un crack, muy interesante el mensaje.

PD: Y muy buenos los SMS de navidades y año nuevo, sobre todo el último... :badgrin:
Omnium potentior est sapientia
Avatar de Usuario
Death_Master
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 2925
Registrado: Mié Ene 26, 2005 10:36 pm
Ubicación: 404

Notapor aLeZX » Jue Ene 03, 2008 12:03 am

Muchísimas gracias, Vic_Thor.

Yo ahora mismo no tengo mucho tiempo para trastear ni con esto ni con prácticamente nada, pero ya llegará el momento.

Estupendo.

Un saludo :wink:
Hay que tener en cuenta que el foro no son más que ceros y unos, nosotros NO. (aLeZX)
El Esperanto es la mejor solución de la idea de Lengua internacional. (Albert Einstein)
Si avanzo, seguidme; si me detengo, paradme; si retrocedo, matadme.
Es más fácil ser una hoja más del pajar que la aguja.


Uno más danzando en el mundo de los blogs: http://alezx.wordpress.com
aLeZX
<|:-)
<|:-)
 
Mensajes: 878
Registrado: Vie Ago 26, 2005 3:29 pm
Ubicación: Vía Láctea, creo.

Notapor Delfi » Mar Ene 08, 2008 10:31 pm

Muchas Gracias Vic_Thor.
Delfi
:-)
:-)
 
Mensajes: 48
Registrado: Sab Jul 21, 2007 6:41 pm

Notapor Arakiss » Sab Feb 02, 2008 5:34 pm

Esto...gracias antes que nada y quiero deciros que la pagina de descarga ya no rula,os agradeceria si alguien lo resube a algun almacen.

Saludos :roll:
Avatar de Usuario
Arakiss
<|:-D
<|:-D
 
Mensajes: 1335
Registrado: Mié Ene 11, 2006 3:41 pm
Ubicación: Madrid

Notapor Sor_Zitroën » Sab Feb 02, 2008 5:38 pm

Funciona sin problemas
[Padre] ¿Crees en el fracaso?
[Hijo] Sí
[Padre] Entonces lo experimentarás
Avatar de Usuario
Sor_Zitroën
-<|:·þ
-<|:·þ
 
Mensajes: 2064
Registrado: Vie Nov 25, 2005 2:01 am


Volver a Redes

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 invitados

cron