30 de junio de 2018

Ahora... WPA3

Cuando se publicó inicialmente el protocolo IEEE 802.11 para la implementación de redes inalámbricas se incluyó un método de aseguramiento de estas redes llamado WEP.
Sin embargo este mecanismo previsto inicialmente fue rápidamente roto generando de esta manera la necesidad de nuevos mecanismos de seguridad que permitan el desarrollo de sistemas inalámbricos con un marco de seguridad aceptable para los requerimientos de la industria.

En este contexto la Alianza WiFi (que no es un organismo de estandarización sino una organización orientada a la promoción de tecnologías 802.11) presentó en el año 2003 su propuesta, WPA.
De esta manera dio inicio a una familia de soluciones de seguridad para redes 802.11 que ahora presenta su tercera revisión: WPA3.

WPA considera 2 soluciones básicas que se han conservado a través de todas sus versiones:
  • WPA Personal
    Tambien conocido como WPA-PSK.
    Diseñado para pequeños despliegues (hogar y pequeñas oficinas) ya que al no requerir la presencia de un servidor de autenticación su implementación es más simple.
    Es considerado más débil como método de seguridad y consiguientemente inadecuado para despliegues de tipo corporativo o industrial.
  • WPA Enterprise
    En algunos casos denominado WPA 802.1X ya que implementa como método de autenticación de usuarios en el acceso IEEE 802.1X con la implementación de servidores RADIUS. Esto hace la implementación un poco más compleja pero asegura métodos más robustos de protección para la red inalámbrica.
La historia de WPA
Una vez violada la propuesta de seguridad inicial de IEEE 802.11 diversos fabricantes desarrollaron alternativas propietarias que buscaban dar una respuesta a los requerimientos de las redes corporativas. Sin embargo las soluciones propietarias no cubrían los requerimientos de interoperabilidad o compatibilidad que son indispensables para el despliegue de estas redes.
De allí que la Alianza WiFi asumiera el desafío de elaborar mecanismos de seguridad más robustos que dieran respuesta a la demanda de la industria.
No solo se trató de generar una propuesta de seguridad sino también de asegurar y certificar la compatibilidad de la implementación de diferentes fabricantes, superando así la limitación de las propuestas propietarias presentadas hasta ese momento.
  • 2003 - WPA
    La Alianza WiFi presenta WPA.
    Desde su nacimiento con 2 modalidades básicas: Personal y Enterprise.
    Basado en los borradores de IEEE 802.11i que estaba en desarrollo en ese momento, incorporó nuevos mecanismos de autenticación, mejoró el cifrado incorporando TKIP e incorporó herramientas de control de integridad de la información. Su implementación se pudo hacer con una actualización de software sobre el hardware ya existente.
  • 2004 - WPA2
    Una vez publicado IEEE 802.11i en el mes de junio de ese año la Alianza WiFi presentó WPA2, que algunos consideran como la versión certificada o comercial del estándar.
    Implementa las tecnologías especificadas en el estándar 802.11i con lo que hace que el cifrado de datos utilice AES.
    Desde el año 2006 WPA2 ha sido obligatorio para todos los dispositivos que cubren los requerimientos de certificación de la Alianza WiFi.
  • 2018 - WPA3
    Ya en enero de este año la Alianza WiFi anunció el lanzamiento de una nueva versión de su propuesta de seguridad, con importantes mejoras tanto en su solución personal como enterprise.
WPA3
Está desarrollado sobre la base de 2 ideas rectoras: brindar un mecanismo de seguridad más robusto que sostenga el crecimiento de las redes inalámbricas; facilitar para el usuario la implementación de políticas de seguridad robusta para asegurar su utilización.
  • WPA3 Personal
    Se mejora particularmente la protección en la clave de autenticación.
    Para esto implementa SAE en reemplazo de PSK. Este algoritmo es más resistente a ataques de diccionario lo que hace más difícil los intentos de "adivinar" la clave de autenticación del sistema.
    Esto permite que los usuarios domiciliarios puedan seleccionar claves que sean más simples de recordar con una protección más robusta y sin complicaciones adicionales.
  • WPA3 Enterprise
    Incorpora algoritmos de seguridad más robustos para alinearse con los estándares de seguridad requeridos por la industria.
    Manteniendo los mecanismos ya conocidos de autenticación y cifrado de WPA2 se incorporan nuevos algoritmos para robustecer la protección:
    GCMP-256 como protocolo de autenticación.
    HMAC-SHA384 para la derivación y confirmación de llaves.
    Intercambio ECDH y ECDSA de 384 bits para el establecimiento de llaves y la autenticación.
    BIP-GMAC-256 para una protección robusta de las tramas de gestión de la red 802.11.
¿Cuáles son las novedades entonces?
  • Se mejora la autenticación de la implementación WPA-Personal con la introducción de SAE.
  • Se fortalecen los procedimientos de intercambio de autenticación en WPA-Enterprise.
  • Se fortalece el cifrado de datos con una serie de mecanismos de última generación que dan un marco de cifrado equivalente a 192 bits.
  • Se introduce como obligatoria la protección de las tramas de gestión de las redes 802.11 (PMF) que hasta el momento no estaba contemplada en los esquemas WPA.
Respecto de su implementación:
  • WPA2 continúa siendo obligatorio para todos los dispositivos certificados por la Alianza WiFi.
  • Los nuevos dispositivos que busquen certificación de la Alianza WiFi a partir de diciembre de 2018 deberán soportar también WPA3 obligatoriamente.
  • Se asegura la compatibilidad de WPA3 con WPA2 con un modo de transición, por lo que los dispositivos certificados WPA3 podrán trabajar con dispositivos WPA2.
  • La implementación de WPA3 no exige por sí misma nuevo hardware, por lo que se puede incorporar con una actualización de software.
    Sin embargo, dado que se utilizan algoritmos de cifrado avanzados, los requerimientos de procesamiento son mayores por lo que diferentes fabricantes desplegarán diferentes estrategias. Es posible que en algunos casos WPA3 sólo sea soportado en dispositivos nuevos.
  • La implementación de PMF es obligatoria en los nuevos dispositivos que se certifiquen.
Tengamos presente que para poder implementar WPA3 es necesario que tanto la infraestructura inalámbrica (access points, controladores) como los clientes inalámbricos de nuestras laptops, smartphones, tablets o cámaras soporten la nueva implementación. Por este motivo también es muy importante la introducción del modo de transición para asegurar que los terminales que sólo soportan WPA2 puedan operar en entornos que implementan WPA3.


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


26 de junio de 2018

Comandos: show ip rip neighbors

Completando la revisión de comandos específicos de monitoreo de la operación del protocolo RIP, vamos ahora a revisar el comando show ip rip neighbors. 

Este comando ha sido introducido en IOS 15.1(2)S  y en IOS XE 3.3. Hasta el momento no ha sufrido modificaciones relevantes

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show ip rip neighbors
BFD sessions created for the RIP neighbors
 Neighbor      Interface      SessionHandle
 10.10.10.2    Ethernet0/0    1
 10.10.20.2    Ethernet1/0    2

El comando permite verificar los dispositivos vecinos con los que se estableció una sesión bidireccional (Bidirectional Forwarding Detection) e intercambia información de RIP

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show ip rip neighbors
BFD sessions created for the RIP neighbors
 Neighbor      Interface      SessionHandle
 10.10.10.2    Ethernet0/0    1
 10.10.20.2    Ethernet1/0    2    
  • Neighbor.
    Router vecino con el que se ha levantado una sesión BFD de RIP.
  • Interface.
    Interface del dispositivo vecino que envía la información de RIP.
  • SessionHandle.
    Identificador único de la sesión que permite hacer el seguimiento del vecino. Este identificador es generado por el sistema BFD.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


24 de junio de 2018

comandos: show ip rip database

Los protocolos de enrutamiento son una pieza clave en la operación de los dispositivos capa 3. En este punto Cisco IOS soporta múltiples protocolos de enrutamiento y proporciona múltiples herramientas de monitoreo de su operación.
La primera y más básica herramienta de monitoreo es la tabla de enrutamiento, y en ese punto ya hemos revisado el comando show ip route. Es por esto que ahora comienzo a revisar los comandos de monitoreo específicos de cada protocolo. 

Elijo comenzar por RIP y en particular por show ip rip database. 

Este comando ha sido introducido en IOS 12.0 y a partir de ese punto se ha introducido progresivamente en diferentes releases. Muestra el contenido de la base de datos de información de enrutamiento recogida a través de RIP.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show ip rip database
  10.0.0.0/8       auto-summary
  10.11.0.0/16     int-summary
  10.11.10.0/24    directly connected, Ethernet3
  10.11.11.0/24    directly connected, Ethernet4
  10.11.12.0/24    directly connected, Ethernet5

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show ip rip database
  10.0.0.0/8       auto-summary
  10.11.0.0/16     int-summary
  10.11.10.0/24    directly connected, Ethernet3
  10.11.11.0/24    directly connected, Ethernet4
  10.11.12.0/24    directly connected, Ethernet5   
  • 10.0.0.0/8 auto-summary
    Muestra una entrada sumarizada que se genera automáticamente a partir de la operación del proceso de sumarización automática de rutas, cuando se encuentra activo, al límite de la clase.
  • 10.11.0.0/16 int-summary
    Entrada sumarizada generada manualmente con el comando
    ip summary-address ip.
  • 10.11.11.0/24 directly connected, Ethernet3
    Entrada generada a partir de la red directamente conectada a una interfaz que se encuentra incluida en el proceso de RIP y completamente operativa.

El comando tiene una variante que permite requerir la información aprendida de un prefijo IP específico. Para esto al comando básico se agrega la dirección IP y máscara de subred correspondiente.

Router# show ip rip database 172.19.86.0 255.255.255.0

 172.19.86.0/24
     [1] via 172.19.67.38, 00:00:25, Serial0
     [2] via 172.19.70.36, 00:00:14, Serial1 
  • La red de destino 172.19.86.0/24 está siendo descubierta a través de la operación de RIP.
  • Para ese destino se están aprendiendo 2 caminos posibles.
  • El primero se aprende a partir de 172.19.67.38 a través de la interfaz Serial 0. Esta información ha sido actualizada hace 25 segundos.
  • La ruta alternativa se aprende a partir de 172.19.70.36 a través de la interfaz Serial 1 y ha sido actualizada por última vez hace 14 segundos.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


21 de junio de 2018

Comando: show sessions

Cuando se trata de monitorear sesiones Telnet o SSH en dispositivos Cisco IOS SHOW USERS nos permite monitorear las sesiones ENTRANTES a un dispositivo IOS.
Sin embargo IOS incluye también clientes Telnet y SSH por lo que es posible desde un dispositivos IOS abrir sesiones remotas hacia otros dispositivos. El comando que permite monitorear las sesiones Telnet o SSH SALIENTES o abiertas hacia otros dispositivos es SHOW SESSIONS. 

Este comando ha sido introducido en IOS 10.0 y no ha tenido modificaciones de relevancia desde entonces.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

R1# show sessions
Conn Host              Address           Byte  Idle Conn Name
*  1 10.1.1.9          10.1.1.9           0     0   10.1.1.9

Al revisar algunos foros encontré que algunos foristas indicaban repetidamente que este comando no funciona.
Desconozco exactamente la secuencia de trabajo utilizada en cada caso, pero para disipar dudas armé mi propia maqueta utilizando 2 routers con IOS 15.2 y licencia Advance Enterprise.
Ambos routers (R1 y R2) fueron conectados a través de un enlace serial con encapculación HDLC. La interfaz serial de R1 utilizó la dirección IP 10.1.1.10/30 y la interfaz de R2 utilizó la dirección 10.1.1.9/30

Desde la CLI de R1 ejecuté inicié exitosamente una sesión Telnet a R2 (10.1.1.9) donde a la vez me encontraba conectado por consola. Ya en la CLI de R2 ejecuté un show users que copio más abajo, y como se puede observar, en el resultado se encuentra tanto la sesión de consola como la sesión Telnet.
A continuación salí de la sesión Telnet (sin cerrarla) y regresé a la CLI de R1 donde ejecuté un show sessions en el que se puede ver perfectamente la sesión Telnet abierta hacia R2.

R2#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:00:19
*  2 vty 0                idle                 00:00:00  10.1.1.10

R2#
R1#show sessions
Conn Host                Address             Byte  Idle Conn Name
*  1 10.1.1.9            10.1.1.9               0     0 10.1.1.9

Consecuentemente, al menos en mi caso, los comandos se comportan según lo esperado.

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

R1# show sessions
Conn Host                Address             Byte  Idle Conn Name
*  1 10.1.1.9            10.1.1.9               0     0 10.1.1.9     
  • Conn:Identificador de la sesión.
    El asterisco indica las sesiones activas en este momento.
  • Host:
    Dispositivo remoto al que nos encontramos conectados a través de la sesión Telnet o SSH.
  • Address:
    Dirección IP destino de la sesión Telnet o SSH. 
  • Byte:
    Número de bytes aún no leídos que se muestran para que el usuario los reciba.
  • Idle:
    Tiempo (en minutos) transcurrido desde la última actividad en la sesión.
  • Conn Name:
    Nombre asignado a la conexión.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


16 de junio de 2018

Comando: show users

Cisco IOS permite activar tanto servicios Telnet como SSH para que usuarios remotos puedan acceder a la CLI de los dispositivos, del mismo modo que es posible hacerlo localmente a través del puerto consola.
Es por esto necesario contar con una herramienta que permita monitorear las sesiones de consola así como las de terminar virtual que se encuentran activas en un dispositivo.
El comando que permite acceder a esta información es show users. 

Este comando ha sido introducido en IOS 10.0 y no ha tenido modificaciones de relevancia desde entonces.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show users
    Line     User        Host(s)    Idle   Location
    0 con 0              idle
 *  2 vty 0  rose        idle       0      bashful.cisco.com

Se puede agregar un subcomando que permite visualizar la totalidad de las interfaces virtuales disponibles, incluidas las que no están en uso:

Router# show users all
    Line     User        Host(s)    Idle   Location
*   0 vty 0  rose        idle       0      bashful.cisco.com
    1 vty 1
    2 con 0
    3 aux 0

    4 vty 2

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show users
    Line     User        Host(s)    Idle   Location
    0 con 0              idle
 *  2 vty 0  rose        idle       0      bashful.cisco.com
  • Line:
    Contiene 3 subcampos:
    - El asterisco indica  la línea desde la cual está conectado el usuario que ejecuta el comando.
    - Número absoluto de la línea: 0 y 2 en el ejemplo.
    - Tipo de línea: con (consola), aux (auxiliar), vty (terminal virtual, tty (terminal asincrónica.
  • User:
    ID del usuario que está utilizando la línea.
    Cuando no se enlista un usuario puede significar que el acceso no requiere identificación de usuario (por ejemplo el acceso por consola), o que la línea no está en uso (en el caso del show users all).
  • Host:
    En conexiones salientes identifica el host al cual se encuentra conectado el usuario.
    Si no hay conexiones salientes el valor asignado es "Idle".
  • Idle:
    Intervalo en minutos desde que el usuario ha ingresado los últimos caracteres.
  • Location:
    En las conexiones entrantes, host desde el cual se ha establecido la conexión entrante.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


10 de junio de 2018

Comando: show ssh

Las buenas prácticas de seguridad indican utilizar SSH para el acceso remoto a la CLI de los dispositivos de modo seguro.
Cuando implementamos SSH el comando que permite verificar en el dispositivo el estado de las sesiones SSH en curso es show ssh. 

Este comando no tiene argumentos adicionales. Ha sido introducido en IOS 12.1 (5) y  está presente en todas las plataformas.

Permite verificar la información correspondiente a las sesiones, no la que corresponde a la configuración del protocolo en sí mismo. Para verificar la versión activa y operación del protocolo el comando es show ip ssh.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show ssh

Connection   Version   Encryption    State        Username
   0         1.5       3DES          Session Started  guest

Cuando no se ha activado el protocolo en un dispositivo y por lo tanto no hay sesiones activas, la respuesta del comando es la siguiente:

%No SSH server connections running

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show ssh

Connection   Version   Encryption    State        Username
   0         1.5       3DES          Session Started   guest
  • Connection:
    ID de la terminal de línea virtual que está utilizando para conectarse al dispositivo la sesión que se muestra en la misma fila.
  • Version:
    Versión del protocolo SSH que se está utilizando.
    IOS soporta tanto SSH versión 1 como 2.
    Version 1.5 indica que se está utilizando versión 1 y no está disponible versión 2.
    Version 1.99 indica que se puede utilizar versión 1 o versión 2.
    Version 2.00 indica que solamente está disponible versión  2.
    En este caso
  • Encryption:
    Algoritmo de cifrado que se está utilizando en esta sesión. En este caso es 3DES, podría ser AES de 128 o 256 bits.
  • State:
    Estado de la sesión SSH. En este caso la sesión está ya iniciada y operativa.
  • Username:
    Nombre del usuario que está utilizando esta sesión SSH.



Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.