Analizando Fast-roaming 802.11r

Las redes inalámbricas se crearon para para poder proporcionar conectividad de red a aquellos a los que no es posible llegar a mediante cable de red y para proporcionar conectividad a aquellos dispositivos que necesitan movilidad. Pero que ocurre cuanta un dispositivo se mueve? A medida que se aleja a del AP al que está conectado empieza a disminuir la potencia de la señal, la velocidad de conexión disminuye en cierto momento ha de empezar a escanear la red para ver si en su entorno encuentra otros APs emitiendo el mismo SSID al que poder conectarse.

El proceso de cambio de un AP a otro al inicio de los tiempos ocurría de la siguiente manera. El AP hace proceso de asociación al AP pasando por las etapas que se describen a continuación en funcion de si la autenticación es por preshared key o lo hace con WPA enterprise mediante 802.1X

A medida que el cliente se mueve y va la señal se va debilitando, se van produciendo retransmisiones y varios factores más, el cliente empieza a trasmitir probe request para sondear el entorno y detectar nuevos APs alrededor. Cuando el cliente determina que que hay otra AP mejor (según la programación del driver de la tarjeta de red del dispositivo) se intenta asociar al nuevo AP pasando de nuevo por todo el proceso anteriormente comentado. 

Este proceso es disruptivo ya que por un lado el cliente ha de ir cambiando el canal de la tarjeta de red para descubrir y posteriormente vuelve a haber una desconexión mientras se vuelve a hacer el proceso de autenticación. A continuación vemos como sería el proceso en wireshark. En la captura podemos ver los ACK correspondientes omitidos en el diagrama anterior.

Proceso de autenticación con WPA2-PSK

Como funciona 802.11r?

Cuando un cliente se mueve de un AP a otro AP con fast secure roaming, se intenta reducir el número de paquetes que se intercambian entre el cliente y los APs en el proceso de asociación.

Recordemos que para poder encriptado y desencrptar las tramas debemos disponer de una PTK, ésta viene derivada de una PMK que a su vez se crea gracias a una MSK. La MSK es igual al preshared key con WPA-2 PSK o se obtiene del proceso de EAP cuándo se trata de WPA empresarial.

Para realizar el proceso de roaming necesitamos generar dos PTK, una para cada uno de los APs a los que el cliente se vaya a conectar. Para conseguir esto el procedimiento es el siguiente. Cuando el cliente se asocia con el AP se genera la PMK y ademas se generan dos nuevas claves la PMKR-0 y la PMKR-1. La PMKR-1 se usara para generar la PTK (la clave que permite encriptar y desencrptar las tramas).La PMKR-0 se utilizará para generar las siguientes PMKR-1 en el resto de APs y se almacena la controladoras o en algún punto al que el AP pueda tener acceso. El dispositivo que va a hacer el roaming al nuevo AP ha de proporcionarle información a éste para que sepa llegar al dispositivo donde reside la PMKR-0 y generar la PMKR-1 con la que podrá generar posteriormente la PTK sin necesidad de pasar por el 4 Ways Handshake.

Existen dos formas de pasar esta información:

Over the DS. Como su nombre indica el AP se encarga de enviar esta información mediante la red cableado a los otros APs

Over the AIR en este caso es el cliente quien pasa la información al AP al que quiere hacer romain durante el proceso de autenticación.  

Para saber cual de los dos métodos se está usando lo podemos consultar en el elemento Mobility Domain si el valor del campo es 1 es Over DS si es 0 es over the AIR:

El proceso es el siguiguiente:

En los pasos 1 y 2 es el proceso de asociación inicial. Los pasos se han detallado anteriormente. El proceso de roaming comienza en el paso 3. El cliente envía un FT-Auth. Contine información sobre la ubicación de PMKR-0 y el SNOUNCE. 4. El AP responde con otro FT-Auth con informacion de los NOUNCES.

En este punto el AP tienen los elementos necesarios para encriptar y desencriptar el tráfico (SNOUNCE, ANOUNCE, Source Address, Dest. Address, PMKR-1)

5. El cliente envia un Reasociat. Req.

6 El AP envia un Reassoc. Resp.con la clave GTK para poder desencriptar el trafico broadcast y multicast.

En el campo RSN hay un elemento denominado AKM que define el tipo de fast transition.

• 3 = FT over 802.1x
• 4 = FT over PSK, 
• 9 = FT over WPA3 personal, 
• 3 = FT over WPA3 Enterprise.

Como podemos ver de conexión cuando se realiza roaming se reduce bastante.

Una forma de verificar si 802.11r esta habilitado es revisando si el  elemento mobility domain está habilitado.

Sin 802.11r

Con 802.11r activado

La información sobre el mobility domain apace en las siguientes tramas:

• Beacon
• Probe Req
• Prob Res, Auth
• (Re)Assoc.Req
• (Re)Assc. Resp

El otro campo que también proporciona es el Fast Transition Info Element (FTIE)

ID:55 

Leng: 96 Bytes

Contienen información sobre nounces,keys, IDs, MIC.

Solo hay información sobre Fast Transition en:

• Authentication Frames
• (Re)associ Req.
• (Re)assoc resp

Cuando existe un reasociation frame que decir que el cliente ha hecho roaming. 

 

 

Como usar Iperf para verificar la aplicación de QoS

En redes que pueden presentar problemas de congestión, puede ser necesaria la aplicación de políticas de Calidad de Servicio (QoS). Hay cierto tipo de tráfico como la VoIP que es más susceptible que otro tipo de tráfico a la pérdida de paquetes. Si durante una llamada hay paquetes que se pierden debido a congestión en la red o la latencia es alta, puede significar un espacio en blanco en la conversación o que se escuche robotizada.

A veces detectar si la electrónica de red está bien configurada o no para aplicar calidad QoS o no, puede ser complicado porque en determinadas ocasiones  el tráfico si viene marcado marcado con el tipo de servicio en origen pero otras aplicaciones no lo hacen.

Para verificar el envió de paquetes marcando una categoría de Qos desde origen, podemos usar la utilidad iperf para hacer las pruebas. Iperf es un programa que se instala en dos equipos. Uno hace servidor y se queda a la escucha y el otro que hace de cliente. La funcionalidad principal de iperf es obtener estadísticas de ancho de banda disponible entre los dos enlaces, pero con las opciones correctas podemos realizar test avanzados como el que haremos a continuación.

Iperf puede se descargado desde la siguiente url https://iperf.fr/. Su utilización es mediante lineal de comandos. En equipos basados en debian se puede instalar con el comando

sudo apt install iperf3

Una vez descargado lo ejecutamos en una máquina en modo escucha con el comando: 

iperf3 -s

Seguidamente en la otra maquina que hará cliente ejecutaremos el comando iperf3 -c "ip_del _servidor". Inicialmente lo ejecutaremos sin aplicar la opción para que marque los paquete con calidad de servicio para poder comparar los dos modos en Wireshark. Mientras se lanza el test, capturaremos los paquetes.

Los diferentes tipos de categoría con el valor correspondiente a cada DSCP se muestra a continuación. En la tabla hay también una columna con los valores de UP, que es método que utilizan las redes inalámbricas para categorizar el trafico.

 

Si analizamos los paquetes podemos ver que el valor DSCP asignado es 0 lo que significa no hay aplicado QoS:

Ahora vamos a realizar la prueba pero vamos a pasarle a Iperf la opción para que marque los paquetes con en DSCP 46 que suele ser el código definido para el trafico de voz. Esto lo realizamos con la opcion -S. Iperf usa los valores de ToS para marcar los paquetes. Para convertir los valores de DSCP a ToS solo hay que multiplicar el valor de DSCP * 4. Por ejemplo para voz que su valor DSCP es 46, el valor de ToS es 184

iperf3 -c "ip_del_host" -S 184

Si volvemos a analizar el paquete podemos ver que los paquetes salen marcados como EF46

Con esto ya podemos asegurar de enviar el tráfico etiquetado y si al salir del switch o del AP ya no aparece clasificado puede deberse a un problema de la configuración de la electrónica de red.

 

Análisis de A-MPDU y A-MSDU con Wireshark

En mi ruta para la certificación del CWAP me he encontrado con el punto que hace referencia a la agregación de tramas. He leído la guía oficial y varios artículos donde se hablan bastante de la teoría pero he encontrado poca información para analizar y hacer troubleshooting con Wireshark. Por este motivo me he decidido a realizar esta entrada para ayudar a aquellas persona que como yo se hayan encontrado en la misma situación.

Más adelante pasaré a explicar en detalle la teoría sobre A-MSDU y A-MPDU, pero a grandes rasgos este mecanismo permite enviar múltiples MSDU o MPDU durante a un dispositivo una vez a realizado el proceso de evaluación del medio,  verificar que está libre (CCA) y conseguir su turno para empezar a emitir (DCF Process).

Para empezar voy a empezar a explicar como agregar algunas columnas en Wireshark que me han ayudado a comprende un poco mejor el proceso.

Vamos a crear una columna que nos permitirá saber si el tipo de datos es MSDU o A-MPDU. 

 

A continuación buscamos una trama de tipo QoS Data (wlan.fc.type_subtype == 0x0028) y añadimos los siguientes campos como columnas:

Ahora buscamos un paquete del tipo BlockAck (wlan.fc.type_subtype == 0x0019) y aplicamos los siguientes campos como columnas:

Las comunas quedarán de la siguiente manera:

Para añadir las columnas a mano, estos serian los parámetros:

A continuación paso a detallar las características de A-MSDU:

 

• Encapsula múltiples MSDU (subframe) en una sola trama
• Cada MSDU contiene una dirección de destino (DA) y una dirección de origen (SA) 
• Cada A-MSDU contiene una cabecera en la que solo podemos poner 3 direcciones RA/TA, SA o DA. Pero en cada MSDU el DA puede ser distinto
• Las MSDUs que componen cada uno de los subframes tienen la siguiente información adicional. 

• Una cabecera (14 B) compuesta por la el DA y SA más la longitud del paquete. En la parte final hay un PAD. La longitud del paquete ha de ser un número múltiplo de 4.

• La última subframe es la única que no necesita PAD. 

• Una vez agregadas todas las subframe se le ha de añadir la cabecera de capa 2 al inicio y el FCS al final. A nivel de capa 1 se le añade también el PHY header para poder ser trasmitida 

• La trama en este punto se puede trasmitir.
• El CRC (trailer FCS) es calculado para cada A-MSDU
• Si una de las subframe falla al enviarse se ha de enviar de nuevo toda la A-MSDU

A-MPDU

• Esta compuesto por MPDU en vez de MSDU. Cada agregación se denomina también subframe
• Cada MPDU ya incorpora la cabecera + MSDU + Trailer
• Cada subframe tiene 3 componentes. Una cabecera denominada Delimiter que contiene la longitud y un FCS (CRC). Al final del subframe se en encuentra el PAD para conseguir que la longitud del subframe sea múltiplo de 4. La última subframe no necesita PAD.
• Al inicio de la agregación se le añade la cabecera 802.11 de nivel 2 con el TA y el RA y la cabecera PHY.
• Si uno de los FCS falla solo se descarta esa subframe y es la única que ha de ser retrasmitida.
• A-MPDU es obligatorio en 802.11ac y 802.11ax.
• 802.11n puede usar A-MSDU
• A-MSDU solo permite 1 RA y 1 TA
• En A-MPDU aunque cada subframe tiene su propia cabecera con un RA y TA. Una A-MPDU solo se puede enviar a un RA.
• Cada MPDU se encripta por separado
• Todas las MPDU ha de ser de la misma categoría de QoS
• Cada MPDU tiene su propio header y tráiler esto requiere también un mayor carga del medio.
• La corrupción de datos puede ser detectada en un MPDU individual y no hay que enviar la A-MPDU entera.

Para confirmar que las tramas se han recibido correctamente en el lado remoto, en vez de enviar un ACK individual, lo que se hace es enviar un BlockACK. En el caso de A-MPDU si alguna subframe se ha corrompido en el BlockACK aparece la información sobre el número de subframe que no ha llegado correctamente y se vuelve a trasmitir de nuevo. En el caso de A-MSDU si alguna subframe no llega correctamente, se ha de volver a trasmitir la trama completa. 

A continuación vamos a analizar  en Wireshark como sería la trasmisión de una A-MPDU, observar si alguna se ha recibido con problemas y ver la retrasmisión.

Tenemos la siguiente captura de paquetes:

Inicialmente se envían las tramas con número de secuencia 34,35,36,37. En línea 354 podemos observar como se envía un BlockACK especificando que no ha recibido los paquetes  38,39.40.41...

En la siguiente captura podemos ver el detalle de todas las tramas que no ha recibido.

Como vemos a continuación en la línea 373 se vuelve a enviar la secuencia 39 y 40 y en la línea 375 hay otro BlockACK que confirma que ha recibido el  paquete 39 y 40 (el primer missing frame es el 41)

Hay un punto que me gustaría también comentar y el como descifrar el código que aparece en el Campo Block Ack Bitmap. Mediante BlockACK podemos llegar a confirmar 64 tramas de una sola vez. Este campo lo podemos dividir en 8 bloques de 8 bits que servirá para detallar que tramas se ha recibido o cuales no. El procedimiento es el siguiente. Supongamos que el número de secuencia desde la que vamos a empezar verificar es la número 360. Como se muestra en la captura el Block Ack Bitmat tiene un valor de todos los dígitos de f"f" si convertimos todas las f de HEX a binarios tenemos que serían 64 unos. Cuando un número de secuencia tiene asociado un valor de 1 es que se ha recibido, si el valor es 0 es que no ha llegado bien. Todo unos significa que todo se ha recibido correctamente: 

Ahora vamos a analizar este otro bitmap. 

La tabla resultante seria la siguiente, he agrupado hex de 2 en dos (4 bits para representar 16 que es el valor máximo de cada HEX individual). 

Tal y como muestra Wireshark en la captura anterior,  las tramas 1569, 1571 y 1572, no han llegado correctamente.

A-MSDU

A continuación se muestra una captura de como se analizaría una A-MSDU con wireshark. Para aislar este tipo de tramas podemos aplicar el siguiente display filter:

wlan.qos.amsdupresent == 1

Para poder ver las subframes que contiene la trama se ha de desencriptar la captura.

En la captura podemos ver que la trama contiene dos subframes. Cada subframe tiene información sobre el DA y el SA más la longitud de la trama. Al final observamos el campo pading en la primera subframe, pero éste no aparece en la segunda ya que es la última. La recepción de la trama se confirma con un BlockACK

Amplío la información con la tabla con la duración de cada TxOP en función de la QoS:

 

Instalar Certificado Let's Encrypt en ISE

Para que a la hora de abrir un portal cautivo o la web de administración de ISE no recibamos el mensaje  que el certificado de seguridad no es de confianza, es necesario instalar en el sistema un certificado firmado por una Entidad Emisora de certificados de confianza. Una de estas entidades es Let's encrypt que te permite generar un certificado valido durante 90 días que va muy bien para hacer pruebas en laboratorio.

Para este tutorial, he adquirido el dominio wifilab.es. Este paso es necesario ya que la validación del certificado la realizaré validando a nivel de Dominio (DV). La creación de los certificados que se subirán a ISE los he generado con una maquina Linux y el programa cerbot.

1. Instalamos cerbot en nuestra máquina. Yo lo he realizado en una máquina linux y para instalarlos se ha de ejecutar el siguiente comando: 

sudo apt install certbot

2. Empezamos generando los certificados ejecutando el siguiente comando:

sudo certbot certonly --manual --preferred-challenges dns -d *.wifilab.es

--manual: es para especificar que lo obtendremos manualmente con las especificaciones que nosotros indiquemos de forma manual.

--preferred-challege: dns ya que la validación la haremos por este método

-d para especificar nuestro dominio si ponemos el asterisco delante vale como certificado wildcard.

3. Para la validación de DNS, me he creado un dominio en One.com. En esta web se puede adquirir un dominio por menos de 3 € al año. El dominio que he creado es wifilab.es. Creamos el registro .txt en nuestro dominio para que pueda ser validado.

Con esto podemos hacer la última parte del script donde solicita la validación del registro y se crean los certificados y la clave privada. Los archivos en mi caso se crean dentro del directorio

/etc/letsencrypt/archive/wifilab.es

Es posible que para poder acceder a los archivos y copiarlos a otra carpta para poder subirlos debas ejecutar:

 sudo -i 

para cambiar al modo privilegiado y es posible que debas cambiar los permisos de los ficheros con el comando:

chown -R usuario:grupo /etc/letsencrypt/archive/wifilab.es

(o la ruta donde hayas copiado los archivos).

4. Seguidamente quedaría configurar la parte de ISE. Si no importamos los Certificados de Let'e encrypt al importar los certificados nos da el siguiente error:

Lo que debemos hacer es lo siguiente:

De la pagina de Lets encrypt:

https://letsencrypt.org/certificates/ 

bajar e instalar los siguientes certificados:

 

Acto seguido ya podemos instalar el fullchain certificate con su clave privada en las opciones de Certificados del Sistema y definir donde lo queremos usar, en mi caso solo para el acceso al portal de administrador de ISE:

Se reiniciará la aplicación de ISE

Error al acceder por SSH desde Linux a equipos Cisco

 Recientemente me he encontrado con un problema al intentar accer por SSH desde la consola de Linux a dispositivos Cisco. Cuando intentaba hacer login recibía el siguiente error a la hora de establecer el algoritmo de encriptación.

Para corregir el problema he tenido que editar el fichero ~/ssh/config y añadir las siguientes lineas:

Host 10.5.18.98

    KexAlgorithms +diffie-hellman-group1-sha1

Aún y así me seguía dando el siguiente error:

Para corregir este error se ha de introducir las siguientes líneas:

HostKeyAlgorithms ssh-rsa

PubkeyAcceptedKeyTypes ssh-rsa 

Finalmente ya nos deja finalizar el proceso de conexión.

PIP error: externally-managed-environment

 Recientemente he instalado la última actualización  de Kali con dist-upgrade. Esta maquina la uso también para iniciarme en sripts de python. Después de realizar la actualización me encontrado que al intentar ejecutar el el commando pip para instalar algún módulo el sistema me devuelve el siguiente mensaje:

error: externally-managed-environment

Dado que mi nivel de inglés no son muy buenos y los de linux tampoco no me habia fijado que la respuesta esta en el mismo mensaje. Para poder instalar los módulos hay que ejecutar el comando con el argumento que se detalla al final del mensaje --break-system-packages como el ejemplo a continuación

pip install meraki --break-system-packages

ISE no muestra IP de clientes autenticados por MAB

 Recientemente me he encontrado con un problema en el que ISE no mostraba las IP de los dispositivos autenticados por MAB en el Live Log.

Los dispositivos se conectan a un C3560. Al ejecutar el show ip dhcp binding  se puede observar que el equipo tiene información de las peticiones DHCP pero no las está enviado a ISE.

Los dispositivos de red usan el atributo 8 de RADIUS (framed-IP-address) en las peticiones de acceso para pasar la información de la IP al Servidor de accesos a la red (NAS) o sea nuestro ISE. 

Para que ISE sea capaz de recibir esa información se ha de añadir el siguiente comando en la configuración global de ISE

radius-server attribute 8 include-in-access-req  

Una ver añadido el comando la ip aparecía ya correctamente en los logs