Configración Root Guard

 En esta entrada explicaré en qué consiste uno de los fallos de seguridad a nivel de capa 2 que consisten en tomar el rol de root bridge de la red. Para ponernos en situación y comprender las consecuencias de este ataque primero hemos de hablar de Spanning Tree (STP). STP es un mecanismo utilizado para evitar que se formen bucle en la red cuando hay redundancia de enlaces hacia los equipos.  Sin profundizar mucho en el funcionamiento, este procedimiento se lleva a cabo bloqueando el tráfico en uno de los puertos que dan la redundancia de forma que, la información que sale por un puerto (que contine el listado de mac que conoce el equipo) no vuelva a entrar de nuevo por el otro puerto y se forme el bucle.

Normalmente se escoge el switch central de la red para que haga de root bridge, suele ser el equipo donde se concentran todas los enlaces remotos y el que es más propenso a tener menos cambios topológicos. Normalmente suele ser el switch Core o de distribución de la red. La elección de este se realiza mediante intercambio de BPDUs y se toma en cuenta la información contenida en campo Priority ID y la MAC Address. Por defecto todos los switches Cisco vienen configurados con un priority ID de 32768, por lo que cuando dos equipos se montan con la configuración de fábrica el equipo que tomará el role de Root bridge es el que tenga la dirección MAC más baja.

En la siguiente topología he añadido tres equipos con la configuración de fábrica. Como se puede ver al ejecutar sho spannig-tree los tres tienen las misma prioridad por los que a la hora de decidir quién será el root sale como ganador el Switch-1 que el el que tiene la dirección mac más baja.

En este punto si conectamos otro switch con una prioridad más baja, este podría coger el rol de

y provocaría cambios en la topología, provocando posiblemente algún corte en la comunicación

al recalcular de nuevo el STP y provocando que el tráfico no fluya como inicialmente habíamos previsto. En nuestro caso le he asignado al Switc-3 una prioridad de 4096 para forzar que se convierta en root. En las capturas podemos que el root bridge a cambiado al Switch-3 y que el puerto que estaba bloqueado en este último ha pasado a estar en el switch-2 puerto Gi0/0.

Para prevenir este comportamiento y evitar que algún equipo no controlado tome el rol de root podemos hacer uso del la funcion root guad configurado este comando en aquello puerto que están configurado en modo trunk y conectados a algún switch.

Switch-1(config)#int gigabitEthernet 0/0

Switch-1(config-if)#spanning-tree guard root

Switch-1(config)#int gigabitEthernet 0/1

Switch-1(config-if)#spanning-tree guard root

Tras aplicar los comandos podemos ver como el equipo bloquea las peticiones del Switch-3 para hacerse root y el vuelve a hacerse el principal de la red.

Como recomendación general siempre es recomendable cambiar la prioridad por defecto de root en aquello switches que queramos que ejecuten esta función.

WLC9800 NET::ERR_CERT_AUTHORITY_INVALID

 A continuación, os comento la solución a un problema que he tenido actualmente con una controladora Cisco WLC 9800 a la hora de validarse vía https después de haber cambiado los parámetros de la hora.  El tema es que una vez realizado el cambio horario e intentar hacer login de nuevo me he encontrado con el siguiente error.

NET::ERR_CERT_AUTHORITY_INVALID

Para corregir el problema se han de eliminar los certificados trustpoint que hay actualmente en la controladora. Para eliminarlos primero hemos de ejecutar el siguiente comando:

WLC#
WLC#show run | inc crypto
crypto pki server WLC_CA
crypto pki trustpoint TP-self-signed-3478691089
crypto pki trustpoint WLC_CA
crypto pki trustpoint WLC_WLC_TP
crypto pki certificate chain TP-self-signed-3478691089
crypto pki certificate chain WLC_CA

crypto pki certificate chain WLC_WLC_TP

WLC# 

Seguidamente los eliminamos:

No crypto pki server WLC_CA

No crypto pki trustpoint TP-self-signed-3478691089
No crypto pki trustpoint WLC_CA
No crypto pki trustpoint WLC_WLC_TP

Verificamos que todos los certificados se hayan eliminado     

WLC#sho run | inc crypto

WLC#

Seguidamente ejecutamos los siguientes comandos:

no ip http server
no ip http secure-server
ip http server
ip http secure-server
ip http authentication (local)

 

Tras ejecutarlos el certificado ya se ha generado de nuevo:

WLC#sho run | inc crypto
crypto pki trustpoint TP-self-signed-3478691089
crypto pki certificate chain TP-self-signed-3478691089

WLC#

Si volvemos a intentar hacer el login ya podemos saltarnos la alerta de que estamos trabajando con un certificado que no es de confianza y podemos hacer entrar a la controladora sin problemas.

Ver utilizanción de canal en redes Wifi con Wireshark

 

Cuando dos estaciones 802.11 están cercas una de otra y están en el mismo canal, entre ellas pueden oírse. Si además intentan transmitir al mismo tiempo, se produce una colisión y el paquete no llega correctamente a su destino. Para intentar evitar las colisiones en el mundo Wireless se creo un mecanismo denominado CCA (clear channel Assesment) cuyo objetivo es que cualquier estación ha de escuchar el medio y verificar que este esta libre antes de poder empezar a trasmitir. A medida que el numero de dispositivo aumenta la utilización del canal también lo hace y como consecuencia el rendimiento de la red empeora ya que los tiempos para trasmitir se han se han de repartir también.

El término “channel utilization” hace referencia pues a la cantidad de trasmisiones que una estación puede escuchar en un canal determinado, ya sean de su propia red o de las redes vecinas. Dicho de otra manera, vendría a ser un indicativo del uso del canal.

A continuación, os voy a mostrar como ver la ocupación de un canal a través de una captura de paquetes wifi analizado con wireshark.

Cuando un dispositivo es compatible con el protocolo 802.11 e y QBSS (QoS Enhanced Basic Service Set) es posible obtener la utilización del canal analizando los beacon frame. El valor ideal debería situarse por debajo del 40 %. Si la utilización supera el 80% el rendimiento de la red puede verse seriamente afectado.

Para empezar, vamos abrir una captura de paquetes con wireshark y vamos a analizar la trama número 435.

Es un beacon que publica un AP con el SSID Gryffindor

Si analizamos el campo QBSS podemos ver que hay un valor inicial que es un integro y a continuación wireshark nos muestra el porcentaje de utilización.

¿Como calcula Wireshark este porcentaje? Lo realiza cogiendo el valor del integro mostrado y dividiéndolo por 255, de esta forma podemos ver la utilización del canal de un AP determinado en un momento concreto. Pero como podemos aplicar un filtro para ver este valor de forma global. A continuación, vamos a aplicar un filtro para que nos muestre aquellos APs que desde su perspectiva detecten una utilización de canal por encima del 50%.  El valor a poner en el campo filtro es el siguiente:

wlan.qbss.cu >= 127

Con este filtro podemos que el SSID Vodafone5400 que actualmente emite en el canal 1, reporta constantemente una utilización del canal del 63%.

 

En la siguiente captura podemos ver algunos APs cuya utilización del canal están por encima del 70%.

Wireshark: seguimiento de paquetes en múltiples enlaces

 

En determinadas ocasiones podemos vernos obligados a hacer capturas de paquetes en dos puntos distintitos de la red. Una vez hecha la captura es necesario comparar los paquetes en ambos puntos para resolver ciertos problemas como pueden ser, ver si el paquete llega o no o si lo hace con tiempos de respuestas muy altos.

En la siguiente guía voy a mostrar cómo podemos identificar un paquete en ambos puntos de la captura asegurándonos que estamos trabajando en cada uno de los punto con el paquete correcto.

Para hacer la demo he montado la siguiente topología.

Las capturas de paquetes se van a tomar en el PC donde tenemos wireshark instalado y en el firewall a nivel del puerto donde está conectado el switch que da servicio a los equipos de la LAN.

Una vez hecho esto podemos probar de enviar vario pings . Los pings que he utilizado iban con destino a la ip 1.1.1.1.

Si analizamos las capturas recogidas en el PC y filtramos por la ip 1.1.1.1 tenemos los siguientes paquetes:

Si hacemos lo mismo en las capturas recogidas en el firewall podemos ver los siguientes paquetes:

Como observamos la identificación del paquete es diferente en ambas capturas y en la captura del cliente hay más paquetes debido a que quizás se empezó a capturar antes que en el Firewall.

 

Para poder identificar un paquete determinado en ambos puntos vamos a utilizar uno de los campos incluidos dentro de la cabecera del paquete IP, en concreto es el campo “Identification”

Este campo es un valor único que se añade en el paquete que nos serirá para seguir ese paquete determinado en cada una de las capturas.

Como podemos ver ya tenemos acotado uno de los paquetes con lo que podremos hacer los mismo con el resto de paquetes para poder compararlos.

CWNA Capítulo 2 Estandars de 802.11

 En este capitulo se repasa la historia de cada uno de los estandares que han ido apareciendo y las mejoras que aportan cada uno de ellos. En este punto interviene la IEEE (Institute of Electrical and Electronics Engineers) este grupo se encarga de definir 802.11 a nivel de la capa física y la subcapa MAC  de la capa de enlace de datos. 

El grupo que se encarga de la capa PHY epecifica tres tipos de capa fisicas:

Infrarrojos

FHHP (Frequency Hopping Spread-Spectrum)

DSSS (Direct-Sequence-Spread-Spectrum)

En el estandar original, dependiendo de la modulación utilizada, se llegaron a alcarzar data rates de 1o 2 mbps. 

Se ha de tener en cuenta que data rate no es lo mismo que throughput. Dado que para que un dispositivo pueda llegar a trasmitir previamente ha de ocurrir ciertos mecanismos para el acceso al medio y control de las comunicaciones que consumen ancho de banda. Normalmente el throughtput suele ser la mitad del data rate disponible.

Alguna de las enmindas ratificadas por el IEEE 802.11-2020 y las funcionalidades que aportan se detallan a continuación:

802.11a-1999: significa el inicio de la trasmisiones inalambricas operando en la banda de 5Ghz y se comienza a trabajar con una tecnologia de RF denominada Othogonal Frequency-Division multiplexing. Trabaja en la banda denominada U-NII e inicialmente constaba de 12 canales. Es necerario que los equipos que quieran trabajar con esta enmienda soporten data rates de 6, 12, 24  Mbps, con un máximo de 54 Mbps.

802.11b-1999: el medio de la capa fisica que se ha definido es High-Rate DSSS (HR-DSSS) y trabaja dentro de  las frecuencia que va de 2.4000 GHz hasta 2.4835 GHz. Soporta data rates de 1, 2, 5.5 y 11 Mbps.

802.11d-2001: permite que la informacion del codigo de país sea entregado mediante ciertas tramas denominadas beacon y probe response. Gracias a esta información se pueden asegugar que cada dispositivo cumpla con las medidas de regulación cada país en lo que hace referencia al uso de canales y de potencias.

802.11e-2005: define los metodos necesarios para poder aplicar politicas de QoS a nivel de capa 2. Estas medidas sirven para dar prioridad aquellas aplicaciones mas sensibles a retardo en la entrega de las tramas. Una de las aplicaciones mas comunes en la VoIP. Distribute Coordination Fuction (DCF) es uno de los mecanismos principales para cumplir este objetivo. Posteriormente apareció el Enhanced Distributed Channel Acces (EDCA) que también sirve para aplicar politicas de QoS per se basa en protocolos de capas superior. Wi-Fi alliance también tiene una certificación denominada Wi-Fi Multimedia (WMM)

802.11g-2003: utiliza una nueva tecnologia denominada Extended Rate Phisycal (ERP)  que permite data rates de hasta 54 Mbps. Utiliza un modulación similar a la utilizado por 802.11a que se denomina Extended Rate Physical OFDM (ERP-OFDM). Trabaja con los siguientes data rates 6, 9, 12, 18, 24, 36, 48 y 54 Mbps aunque el IEEE define que sean obligatorios los data ratesde 6,12 y 24 Mbps.

802.11h-2003: introduce dynamic frequency selection (DFS) y transmit power control (TCP) mecanismos util para aquells frecuencia de 5 GHz en las que tambien trabajan cierto tipos de radares (U-NNII-2). TPC además sirve para hacer cumplir los valores de regulación de los distintos paises en los que hace refencia a potencias máxima a los que puede trasmitir cada A.

802.11i-2004: define Robust Security Networks (RSN). Para ello se han de cumplir los siguiente puntos:

• Privacidad: CCMP utiliza AES para que el tráfico vaya encriptado para que si alguien intercepta la trama no sea capaz de ver el contenido.
• Integridad de los datos: WEP utiliza ICV para cumplir este objetivo y TKIP utiliza MIC. Ademas todas las tramas tienen un capo en la parte final de la trama denominado frame check sequence (FCS) donde se unitilizan una serie un valor de 32-bits denominado CRC vara verificar que la trama no ha sido manipulada.
• Autenticación: dos metodos principales IEEE 802.1X authorization framework (EAP) o preshared key (PSK)

802.11k-2008: recoge estadisticas y medidas incoporadodas en las tramas. Algunos de los recursos pricipales que aparcen en aquellas tramas que soportan 802.11k son:

• TPC
• Estadisticas de los clientes como SNR, RSSI, data rates.
• Estadisticas del canal: Noise Floor
• Reporte de APs vecinos para agilizar el proceso de roaming.

802.11n-2009: tambié denominado High Troughput (HT). Proporciona data rates de hasta 600 Mbps. Incorpora MIMO que minimiza los problemas de multipah y los convierte en una ventaja. Trabaja tanto en 2.4 GHz como en 5GHZ.

802.11p-2010: util para la comunicaciones en vehiculos que se despalzan a alta velocidad. Trabaja en una banda licenciada en 5.9 GHz. También se le denomina WAVE.

802.11r-2008: introduce Fast Service Set Transition (FT) también conocido como fastroaming. Agiliza el roaming cuando se usa ciertos protocolos de autenticación como WPA-2 Enterprise y WPA-3 Enterprise que cuando se utilizan en comunicaciones como la telefonia IP que requieren la entrega de los paquetes tiempos inferiores a 100 ms.

802.11s-2011: define los eestandares de las capas MAC/PHY de las redes mesh. 

802.11u-2011: se creo para garantizar la interoperabilidad de las redes inalambricas entre distintos fabricantes (WIEN)

802.11v-2011: especifica metodo para recopilar información a cerca de la configuración de los clientes. Define WNM donde se intercambia información como las capacidades de los BSSID, localización de los clientes y modo de reposo de los clientes para que puedan permanecer en el estado de ahorro de energia por intervalos de tiempo más largos.

802.11w-2009: securiza el envio de las tramas para evitar cierto tipos de ataques como DoS. Las tramas 802.11w se deneminan tambien robust management frames. Algunos de management frame protection (MFP) son obligatorios para cumplir en WPA3 para cumplir con la certificacion de Wifi Alliance.

802.11Z-2020: direct link setup (DLS)  permite que el trafico entre dos clientes fluya directamente sin la necesitar de pasar por el AP.

802.11ac: very high throughput (VHT) permite data rates de hasta 6933.3 Mbps. Trabaja solo en 5GHz. Permite agrupaciones de canales de 20,40,80 y 160 MHz y incorpora una nueva modulacion  256QAM. Permite la trasmision y la recepción de has 8 spatial stream.

802.11ad-2012: transmisiones en la frequencia de 60GHz. Utiliza DMG como metodo de transmisión y alcanda data rates de hasta 7Gbps. Utiliza GCMP como metodo de encriptación que utiliza AES.

Crear VLANs en WLANPI

 

En alguna configuración me he encontrado en la necesitad de probar la configurar del trunking en alguno de los puertos de algún switch, pero esta tarea es difícil con un ordenador con Windows 10 ya que por defecto no es posible taggear VLAN. Aunque determinados adaptadores ya tienen drivers que ya permiten realizar esta tarea, todavía hay tarjetas que no lo permiten.

A continuación, se detalla el proceso para poder crear VLAN en la WLANPI para verificar las configuraciones de los puertos o para poder forzar el tráfico de red por una red determinada.

Para comenzar actualizamos la librería de paquetes de nuestra WLANPI con el siguiente comando:



sudo apt-get update



Seguidamente instalaremos el módulo para poder crear las VLAN



sudo apt-install vlan



Seguidamente cargamos el módulo del kernel



sudo modprobe 8021q

Si queremos que la configuración se permanente usamos el siguiente comando:





sudo su -c 'echo "8021q" >> /etc/modules'





Para crear la nueva subinterfaz con la vlan correspondiente ejecutamos el comando





sudo vconfig add eth0 100



En el ejemplo se nos crearía una interfaz que correspondería a la vlan 100

Ahora queda asignarle la ip



sudo ip addr add 10.0.0.1/24 dev eth0.100



Ahora ya solo quedaría crear la interfaz para que sea creada al reiniciar el sistema

auto eth0.100
iface eth0.100 inet dhcp
vlan-raw-device eth0





Reiniciamos el servicio de red



sudo systemctl restart networking.service



Si ejecutamos ifconfig podemos ver que la interfaz ya está creada con la ip que hemos configurado






Ahora ya podemos crear la vlan en el switch:




Creamos también la interfaz de nivel 3






Si enviamos un ping a nuestra WLANPI podemos ver que ésta ya responde.

 

 

WLC 9800 - Configurar AP en Flex

 A continuación voy a explicar como configurar un Access-Point en modo FlexConnect en una controladora WLC 9800. Esta modalidad es util para aquella instalaciones multisede, donde existe solo una controladora en la sede central y varios APs distribuidos por oficinas remotas. Las sedes remotas han de tener conectividad con la sede central. Al configurar el AP en modo Flex-Connect podemos optimizar el trafico de datos permitiendo que todo el trafico que vaya destinado a equipos locales no tenga que subir a la controladora, para volver a ser enviado de nuevo a la oficina remota.

El proceso de configuración del AP ha variado mucho respecto a como se como se configura en controladoras con AireOS. 

La configuración se ha realizado con una controladora virtualizada WLC 9800 y con un access-point de la serie AP2700

Primero crearemos el SSID al que nos conectaremos:

En el ejemplo he creado un SSID que solo emita en la banda de 5 GHz y con encriptación WPA-2 PSK

Flex Profile

Para empezar, configuraremos el Flex Profile y básicamente hemos de configurar las pestañas que se muestran a continuación:

En esta pantalla asignamos un nombre al perfil y le asignamos cual será la VLAN de gestión de al AP.

Seguidamente como el SSID que publicado va a trabajar en una VLAN diferente de la gestión, la hemos de configurar en la pestaña VLAN.

Policy Profile

A continuación configuraremos el Policy Profile. En este apartado es donde configuraremos las opciones para que el trafico en vez de ser enviado a la controladora se quede localmente en el switch al que están conectado los APs. La configuración ha de quedar de la siguiente manera:

El SSID que usado, trabajará en la VLAN10 y esto lo definimos en el siguiente menú:

Tag

A continuación definimos los tags que serán asociados posteriormente los APs.

Policy Tag

En este punto mapeamos las WLAN a los Policy Profiles:

Seguimos con el Site Tags

Site Tag

Aquí definimos el AP Join Profile y es cuando podemos definir que un AP trabaje en modo flexconnect. Desmarcando la opción "Enable local Site" se activa la opción para seleccionar un Flex Profile.

AP Tag

Por último quedaría asociar todos los Tags al AP correspondiente en el siguiente menú:

Acto seguido el AP se reiniciara y arrancará en modo flexconnect..

Por último solo quedaría la configuración del switch. Dado que vamos a usar diferentes VLAN para la gestión del AP y para la conexión de los clientes, el puerto del switch ha de estar en modo Trunk y como VLAN nativa, la que vayamos a usar para la gestión del AP. Dado que en mi caso el AP usará la VLAN 1 para la gestión no he de hacer nada especial en la configuración

Con esto ya tendríamos todo configurado a nivel  de configuradora. Solo quedaría definir un servidor DHCP para que asigne las IPs a los usuarios que en mi caso lo tengo en un firewall Meraki.