Tráfico por un túnel EoIP protegido por IPSec

Fecha: 27 de marzo del 2024

Escenario

Este laboratorio es el segundo de la saga donde se análiza tráfico EoIP (Ethernet Over IP) y esta vez analizamos aspectos de seguridad ya que como vimos en el lab anterior el tráfico viaja tal como es (llamémoslo plano) sin ningún tipo de protección.

En este caso se protege mediante IPSec encapsulandolo en un payload ESP (Encapsulation Security Payload) donde la trama se encripta y se firma como auténtica, y se reencapsula en un nuevo paquete IP tal como el escenario anterior.

No demás está la discusión

1.- Generamos un ping de un equipo a otro:

C:\> ping 192.168.0.123 (desde 192.168.0.100)

Haciendo ping a 192.168.0.123 con 32 bytes de datos:

Respuesta desde 192.168.0.123: bytes=32 tiempo<1m TTL=128 (vemos que no se decrementa el TTL

Respuesta desde 192.168.0.123: bytes=32 tiempo<1m TTL=128 porque ambos se encuentran en la

Respuesta desde 192.168.0.123: bytes=32 tiempo<1m TTL=128 misma LAN (guiño guiño))

2.- Análisis de tráfico:

ISAKMP es Internet Security Association Key Management Protocol y es el encargado de generar un canal seguro para acordar cómo enviar el tráfico, una vez que ambos peers están de acuerdo el tráfico fluye (encriptado y firmado).

2.1.- Mutación de la trama en payload encriptado:

2.2.- Verificamos en Wireshark:

Frame 6: 246 bytes on wire (1968 bits), 246 bytes captured (1968 bits)

Ethernet II, Src: 18:fd:74:03:b9:2a, Dst: 18:fd:74:03:b7:9a (layer 2)

Internet Protocol Version 4, Src: 181.111.221.110, Dst: 181.10.139.236 (layer 3)

Encapsulating Security Payload

ESP SPI: 0x09eb88f3 (166430963) (identificador de SA (security association) distingue flujos en un sentido u otro ver

ESP Sequence: 2131 (número de secuencia, el próximo para este SPI será 2132) en la captura de Wireshark arriba)

0000 18 fd 74 03 b7 9a 18 fd 74 03 b9 2a 08 00 45 00

0010 00 e8 08 09 00 00 ff 32 df 05 b5 6f dd 6e b5 0a.

0020 8b ec 09 eb 88 f3 00 00 08 53 5b 00 6c 2e 39 c5 (los valores en negro son la trama original encriptada)

0030 51 3f f3 c8 c3 f8 78 6c ee 9c 0d 02 69 e3 3e fc

0040 7b 58 87 97 a8 15 3b 91 ef 12 b4 01 f9 63 8c 6f

0050 ef be 17 71 9f 8b 24 be 4d 5e f2 31 05 49 b6 74

0060 ab 51 42 12 2e 38 52 fd a9 09 dc 74 83 4a 4b c0

0070 94 6e b5 7d 7f a3 76 22 d4 bd fb a3 27 4b b7 d7

0080 ad 7f 8c da 1e 2e 15 94 48 71 4b ee 1d 9c e3 f2

0090 3c ab e3 8d d2 e4 59 20 13 8f ec 4f 77 44 64 1a

00A0 d9 5a 47 de f1 9d 2d 6e 5e de 92 7c 86 4a 6a 8d

00B0 77 ad 7c 4d 3a 01 d6 24 c4 7a de 4d 2b 86 c7 9a

00C0 e0 d1 29 3b 32 3e eb b6 00 56 f0 46 bd 83 af e9

00D0 39 2c c8 94 85 20 81 de 97 18 0e 86 62 28 51 aa

00E0 87 fb c9 d8 22 70 e9 cd 6a f3 69 76 88 ae bc b9

00F0 6d 4e ec e3 18 54

2.3.- Comparamos una trama/paquete protegido contra otro sin proteger:

3.- Por que la seguridad en un túnel EoIP ?

Si bien no agregarle seguridad hoy día no es sensato, o está visto como una heregía, debemos plantearnos utilizando este escenario como ejemplo, ¿en donde está la fuente de peligro? Si realmente pensamos que

“un hacker podría…” debemos analizar en frío: ¿cómo nos pueden capturar tráfico remotamente? ¿desviando la IP de destino a una IP fantasma? ¿cómo engañamos al BGP de internet para que la lleven al punto X? ¿uno de los routers está comprometido? entonces el EoIP sin proteger sería el menor de los problemas.

¿Nuestro ISP nos puede espiar? Esa es más válida y ahí tenemos un problema, porque sé de casos que nuestro ISP también nos da hosting, nube, etc…o sea, ya tiene nuestros datos.

¿alguien random puede acceder a equipos físicos en otro ISP? esa creo es la más válida.

En forma remota por el momento no se me ocurre cómo. ¿DNS poisoning? pero el túnel va de IP a IP, no por FQDN, ¿por WiFI? ahí ya no interviene el túnel EoIP, a menos que WiFi sea un enlace P2P de mi ISP, pero de por si ya está encriptado.

Dejo la inquietud para otro laboratorio…

(2024) Mutant packets

Rosario, Argentina