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
Copyright (c) 1986-2013 by Cisco Systems, Inc.
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