Análisis del tráfico broadcast que se escapa de la VLAN

Fecha: 27 de marzo del 2017

Escenario

Este análisis sale a partir de una prueba sencilla de detectar hosts en una red mediante la emisión de un ping

a la dirección de broadcast de la red o subred, y todos los dispositivos en ella responden al mismo.

Hoy día muchos dispositivos no responden debido a un parche en el sistema operativo o en su firmware,

ya que esta técnica puede utilizarse en ataques tipo Smurf, pero en el caso de cámaras IP y otros equipos

de estado sólido generalmente responden.

Esta red en particular tiene equipos de control de tiempo real y debe estar aislada “del resto del mundo”,

aquí es donde apareció el enigma de la “VLAN pinchada” ya que dispositivos de otra VLAN respondían a las

solicitudes de eco (ping).

En este escenario en cuestión se generó un ping a la dirección 172.16.255.255 (de una red /16) y respondieron

dispositivos de una VLAN diferente (10.89.80.0/24), recordemos que este tipo de tráfico (broadcast) no debería

ser reenviado por un router o switch de capa 3, aunque exista la posibilidad, pero el escenario sería mas complejo.

La red /16 se debe a que los instaladores generalmente dejan la máscara por default al utilizar direcciones clase B.

Recordemos que existen dos tipos de broadcast (en capa 3) los limitados (255.255.255.255 y no enrutables) y los

dirigidos (172.16.255.255 y posiblemente enrutable), en capa 2 hay un solo tipo de broadcast (FF:FF:FF:FF:FF:FF).

1.- Búsqueda de dispositivos dentro de la VLAN:

Cisco-3650#ping 172.16.255.255 repeat 1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 172.16.255.255, timeout is 2 seconds:

Reply to request 0 from 10.89.80.109, 10 ms (…?)

Reply to request 0 from 10.89.80.150, 10 ms (…?)

Reply to request 0 from 10.89.80.2, 10 ms (…?)

Reply to request 0 from 172.16.1.180, 10 ms (OK)

Reply to request 0 from 172.16.1.40, 10 ms (OK)

Reply to request 0 from 172.16.1.60, 10 ms (OK)

Reply to request 0 from 172.16.1.120, 10 ms (OK)

Cisco-3650#

Detalle: podemos ver que el router/switch L3 genera tráfico de broadcast limitado aún escribiendo 172.16.255.255:

Detalle: ejemplo de una máquina Windows, el paquete sí se transmite con la dirección de broadcast dirigido:

2.- Verificación mediante broadcast limitado:

Con esta prueba eliminamos la posibilidad de que un router nos reenvíe el tráfico hacia otra red/subred que aparezca en la

tabla de enrutamiento (aunque aquí no era el caso). Este tráfico si o si queda en la VLAN (o al menos debería).

Cisco-3650#ping 255.255.255.255 repeat 1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:

Reply to request 0 from 10.89.80.109, 10 ms (…?)

Reply to request 0 from 10.89.80.15, 10 ms (…?)

Reply to request 0 from 10.89.80.2, 10 ms (…?)

Reply to request 0 from 172.16.1.180, 10 ms (OK)

Reply to request 0 from 172.16.1.40, 10 ms (OK)

Reply to request 0 from 172.16.1.60, 10 ms (OK)

Reply to request 0 from 172.16.1.120, 10 ms (OK)

Cisco-3650#

3.- Verificación de los dispositivos dentro de la subred:

Cisco-3650#sh arp | incl 161

Internet 172.16.0.1 - 30e4.db53.2b20 ARPA Vlan16 (este equipo)

Internet 172.16.1.180 0 bc67.1ccc.9b40 ARPA Vlan16

Internet 172.16.1.210 1 3ca8.2a87.a8c0 ARPA Vlan16

Internet 172.16.1.250 0 000c.29f9.1b12 ARPA Vlan16

Internet 172.16.11.40 1 001b.1ba6.7635 ARPA Vlan16

Internet 172.16.11.100 1 001b.1ba6.7e42 ARPA Vlan16

Internet 172.16.21.40 0 0023.2464.d1ee ARPA Vlan16

Internet 172.16.21.41 0 0023.2463.cfd4 ARPA Vlan16

Internet 172.16.39.25 1 a02b.b859.bd8a ARPA Vlan16

Internet 172.16.71.60 1 001b.1bb6.1449 ARPA Vlan16

Cisco-3650#

4.- Verificamos el por qué de la VLAN “pinchada”:

En el equipo con dirección 10.89.80.2 verificamos una conexión realizada por un contratista y en la cual interconecta de forma

ilegal (en términos no técnicos) ambas VLANs, lo que permite compartir el tráfico broadcast entre ambas.

El broadcast llega desde la VLAN 16, entra en la VLAN 80, llega en capa 2 a equipos que lo respondan y estos uylizan la capa 3 para

devolverlo al origen 172.16.0.1 a través de su propio default gateway, por lo que la respuesta llega por otro camino de donde salió.

Fin del asunto.

Oficina-VLAN-80#sh cdp nei

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

Taller-VLAN-80 Ten 1/1/3 163 R S I WS-C3650- Ten 1/1/1

XB11E10+SSY10-A10 Gig 1/0/11 163 S I WS-C2960S Gig 1/0/8 (sospechoso)

Deposito-VLAN-80 Ten 1/1/2 141 R S I WS-C3650- Ten 1/1/2

Total cdp entries displayed : 3

Oficina-VLAN-80#

Oficina-VLAN-80#sh cdp nei detail

---resumido---

Device ID: XB11E10+SSY10-A10

Entry address(es):

IP address: 172.16.1.60 (corresponde a la VLAN donde generamos los broadcasts)

Platform: cisco WS-C2960S-24TS-L, Capabilities: Switch IGMP

Interface: GigabitEthernet1/0/11, Port ID (outgoing port): GigabitEthernet1/0/8

Holdtime : 123 sec

Version :

Cisco IOS Software, C2960S Software (C2960S-UNIVERSALK9-M), Version 12.2(55)SE8, RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Compiled Wed 26-Jun-13 11:40 by prod_rel_team

advertisement version: 2

Protocol Hello: OUI=0x00000C, Protocol ID=0x0112; payload len=27, value=00000000FFFFFFFF010221FF0000000

VTP Management Domain: ''

Native VLAN: 1 (el equipo está mal configurado, realmente la VLAN debería ser la 16)

Duplex: full

Management address(es):

IP address: 172.16.1.60

---resumido---

Total cdp entries displayed : 3

Oficina-VLAN-80#

5.- Solución:

La solución es fácil y consta de varias posibilidades:

5.1.- Evitar las conexiónes a nuestros equipos por personal no autorizado.

5.2.- Desactivar puertos no utilizados o asociarlos a una VLAN dummy.

5.3.- Activar el port-security en los puertos utilizados.

(2017) I see discarded packets…

Rosario, Argentina