Mucho se habla de Internet of Everything (IoE), la evolución de Internet en la que se interconectan personas, objetos, procesos y datos. Pero más allá de las posibilidades y realidades que se abren están los desafíos técnicos.
Dar base tecnológica a esta nueva Internet requiere el ajuste de muchos elementos: desarrollo de sistemas de sensores y aplicaciones, transporte, procesamiento y almacenamiento de grandes volúmenes de datos, conectividad, seguridad, etc. Por eso hay tecnologías de networking que adquieren nuevo relieve, como es el caso de RFID, IPv6, seguridad y conectividad inalámbrica. Esto significa adecuación de tecnologías a nuevos usos, y entrenamiento y capación para incorporar los conocimientos y habilidades necesarios para implementarlas y gestionarlas.
Tecnologías de conectividad inalámbrica
En este post quiero centrarme en las tecnologías de conectividad inalámbrica disponibles.
Un elemento clave de IoE es el despliegue de redes de sensores (WSN - Wireless Sensor Networks) para la recolección de información en línea que luego ha de ser procesada para generar reportes o impactar en procesos automatizados.
Estas redes de sensores mayoritariamente utilizan conectividad inalámbrica para enviar los datos hacia los puntos de procesamiento. Para esto en la actualidad se utilizan diferentes tecnologías y esa multiplicidad constituye un problema.
Las tecnologías actualmente desplegadas con este propósito son IEEE 802.15.4 (LR-WPAN), Zigbee, 6LoWPAN, Bluetooth (802.15.1), WiFi (IEEE 802.11) o soluciones propietarias. También se utilizan soluciones móviles como GPRS o EDGE.
Esta variedad de tecnologías se debe a la búsqueda en cada caso una solución adecuada para lograr la conectividad necesaria pero también genera la necesidad de una estandarización que permita cubrir los diferentes requerimientos y reducir los costos.
Una de las tendencias en el proceso de estandarización es la adopción de soluciones 4G como UMTS y LTE, y la proyección a 5G.
¿IEEE 802.11 no es una solución?
La aprobación de 802.11ac introdujo una tecnología inalámbrica de bajo costo y alto ancho de banda. Sin embargo aún tiene limitaciones importantes en función de los requerimientos del despliegue de WSN: No está adaptada a las necesidades de ahorro de consumo de energía de los sensores, y por otra parte, al operar sobre la banda de 5 GHz su radio de cobertura es limitado y requiere de nodos intermedios con una arquitectura compleja para asegurar la cobertura de superficies extensas.
Sin embargo, desde el año 2010 se está trabajando en el desarrollo de un nuevo estándar: 802.11ah que debería dar respuesta a estas limitaciones:
- Opera en la banda de 900 MHz que es una banda no-licenciada con poca congestión y mucho mayor penetración (alcance).
- Se estima un alcance de hasta 1000 metros en exteriores.
- Permitirá la asociación de más de 8.000 dispositivos a un único access point (las tecnologías actualmente en uso permiten hasta 256 asociaciones).
- Se está trabajando sobre tasas de transmisión de al menos 100 Kbps (las redes de sensores no requieren mucho ancho de banda).
- Está preparado para topologías de un único salto.
- Tiene un consumo de energía muy bajo.
- Es además una solución de bajo costo.
De esta forma se espera superar las limitaciones actuales de las redes 802.11 para el desarrollo de WSN. Si bien la comisión responsable aún está trabajando en un borrador, se espera contar con una versión utilizable para el año 2016.
Enlaces
Cuando trabajamos en la CLI de Cisco IOS interactuamos con una cantidad más o menos importante de mensajes del sistema operativo a los que genericamente llamamos "mensajes de la consola".
En realidad la denominación de "mensajes de la consola" incluye indistintamente diferentes tipos de mensajes cuyo origen, propósito y significado son muy diferentes.
En principio hay que considerar 2 tipos de mensajes:
- Los mensajes de error que están referidos a situaciones generadas por el ingreso de comandos en el prompt de IOS.
- Los mensajes de estado y eventos, generados por cambios o actualizaciones en la operación de protocolos, interfaces, etc.
En estos mensajes he de focalizarme en este post.
Los mensajes de estados y eventos
Los mensajes de eventos son generados por un sistema de notificaciones que permite que múltiples dispositivos en la red originen mensajes de estado con una estructura común y los almacenen (o no) en un dispositivo (servidor) centralizado para su posterior revisión por el Administrador.
En los dispositivos Cisco el sistema de mensajes de estado y eventos puede enviar estos mensajes a distintas posiciones:
- A la pantalla de la consola (console).
- A una sesión telnet o SSH (monitor).
- A un servidor Syslog alojado en la red.
- A un buffer de memoria local (buffered).
Los mensajes tienen un formato estándar:
*Dec 18 17:10:15.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
- Un registro de tiempo (fecha y hora).
Dec 18 17:10:15.079
- La porción del dispositivo que genera el mensaje.%LINEPROTO
- Nivel de severidad del mensaje:5
- Clave nemotécnica.UPDOWN
- Descripción del mensaje.Line protocol on Interface FastEthernet0/0...
Estos mensajes tienen 8 niveles de severidad diferentes:
- 0 Emergency
- 1 Alert
- 2 Critical
- 3 Error
- 4 Warning
- 5 Notification
- 6 Informational
- 7 Debugging
Los niveles 0 a 4 representan eventos que pueden tener serio impacto en la operación del dispositivo.
El Administrador tiene la posibilidad de definir hasta qué nivel de severidad desea recibir mensajes en cada una de las diferentes posiciones (servidor, consola, etc.). Por ejemplo, almacenar hasta nivel 5 en el servidor de Syslog y recibir hasta nivel 7 en la terminal de consola.
Por defecto se envían todos los mensajes hasta nivel 7 al puerto de consola.
Configuración de los registros
Router(config)#service timestamps
Habilita la inclusión de fecha y hora en el encabezado de los mensajes.
Router(config)#service sequence-numbers
Habilita la inclusión de un número de secuencia en el encabezado de los mensajes.
Router(config)#logging on
Activa el proceso de logging.
Router(config)#logging buffered 200000
Determina el tamaño del buffer de memoria. Los mensajes almacenados en este buffer se pueden revisar con el comando show logging.
El tamaño del buffer se establece en bytes. Por defecto, el tamaño es 4096 bytes y el nivel de severidad es debugging.
Router(config)#logging 172.16.1.2
Indica un servidor de syslog como destino para almacenar los mensajes.
Router(config)#logging trap warnings
Limita los mensajes enviados al servidor de syslog en base al nivel de severidad.
El nivel de severidad también puede expresarse en forma numérica, en este caso: 4.
Router(config)# terminal monitor
Envía los mensajes que por defecto sólo van a la consola, a las terminales virtuales.
Router(config)#logging monitor notifications
Limita los mensajes que se enviará a las terminales virtuales, en base al nivel de severidad.
Cisco IOS permite la activación de una gran cantidad de servicios, muchos de los cuales se encuentran operativos por defecto y por lo tanto representan un potencial riesgo de seguridad. Por este motivo es necesario hacer un análisis de los servicios a utilizar y aquellos que no sean utilizados deberán desactivarse.
Nota:
Diferentes versiones de IOS presentan diferentes servicios activos por defecto. Es por esto importante desactivar explícitamente los servicios que no se utilizan sin dar nada por supuesto.
Router(config)#no ip domain-lookup
Desactiva el cliente DNS son el que opera IOS. Al ejecutar este comando el dispositivo ya no realizará búsquedas de DNS para resolver nombres.
Router(config)#no ip bootp server
BOOTP es un protocolo para asignación automática de direcciones IP que ha caído en desuso, por lo que es conveniente asegurarse que no se encuentre activo el servicio.
Router(config)#no ip dhcp-server
Este comando permite deshabilitar el servicio de DHCP embebido en IOS.
Router(config)#no ip source-route
Otra función del protocolo IP, el ruteo predefinido desde el origen, es una función que suele ser explotada por potenciales atacantes. Si no se ha de utilizar, debe ser desactivada en todos los dispositivos.
Router(config)#no ip http server
Desactiva el web service de IOS, que es el que permite inicialmente acceder a la interfaz web de los dispositivos. Si se ha de utilizar acceso web, se recomienda hacerlo activando el servicio HTTPS.
Router(config)#no cdp run
Desactiva la operación de CDP a nivel global.
Router(config)#interface GigabitEthernet0/0
Router(config-if)#no cdp enable
CDP tiene 2 niveles de activación: global y por interfaces. Este comando desactiva la operación del protocolo en una interfaz específica.
Router(config-if)#ntp disable
Desactiva el procesamiento de paquetes NTP en una interfaz específica.
Router(config-if)#no ip proxy-arp
Proxy ARP es una porción esencial de la operación de IP y ARP que se encuentra activa por defecto en interfaces que tienen activado el protocolo IPv4. Esto es una brecha de seguridad potencial, y por lo mismo debe ser desactivado cuando no es un recurso necesario.
Router(config-if)#no ip redirects
Desactiva en la interfaz los paquetes ICMP que utiliza el protocolo para informar al origen cuando hay mejores alternativas de enrutamiento. Esta es otra función que puede ser explotada por potenciales atacantes.
La gestión remota de dispositivos de red es una práctica extendida y necesaria en el ámbito de la administración de la infraestructura de red.
La gestión remota implica un riesgo de seguridad: la información de configuración y monitoreo de los dispositivos circula en sesiones TCP atravesando diferentes secciones de red, muchas de las cuales no están bajo nuestro control y que por lo tanto han de ser consideradas inseguras. Sin embargo son muchos los que aún utilizan para esta tarea sesiones Telnet.
Telnet es un protocolo adecuado para la gestión remota de dispositivos pero inseguro. Las sesiones Telnet viajan por la red sin cifrar, y por lo tanto quien capture el tráfico de esas sesiones accederá no solo a la información de configuración sino también a las claves que ingresemos que estarán viajando por la red en texto plano.
Es por esto necesario implementar para estas tareas SSH.
Para poder implementar SSH se requieren dos condiciones básicas:
- Que el sistema del dispositivo al que deseamos acceder soporte el servicio SSH.
Cisco IOS hoy soporta SSH en todas sus imágenes, aún las conocidas como IP Base.
- Contar con un cliente SSH.
Esto también es posible ya que no sólo clientes licenciados, sino también otros de acceso libre (p.e. Putty y Tera Term) soportan SSH.
Habilitación de SSH en routers Cisco IOS
Los dispositivos Cisco IOS por defecto tienen habilitado el servicio de Telnet, no el de SSH. Por lo tanto, la utilización de SSH requiere de varios pasos de configuración:
1. Habilitar el servicio SSH.
Router(config)#hostname LAB
Router(config)#ip domain-name ccnp.com
Router(config)#crypto key generate rsa modulus 2048
Genera una llave de cifrado RSA (en este caso de 2048 bits), que luego utilizará SSH.Para que se genere la llave de cifrado es necesario antes contar con hostname y nombre de dominio ya que son elementos utilizados para generar la llave.
Router(config)#username admin privilege 15 secret Clave_4A
Crea un usuario de nivel 15, con su clave de acceso, que será luego utilizado por SSH.Dado que la clave está definida como secret, se guardará cifrada en el archivo de configuración.
Router(config)#ip ssh version 2
Elige utilizar SSH versión 2 solamente para las conexiones remotas que se establezcan.
2. Dado que SSH requiere autenticación utilizando username y clave, hay que habilitar la autenticación local.
Router(config)#line vty 0 5
Router(config-line)#transport input ssh
Define que el único protocolo para el acceso remoto utilizando terminal virtual es SSH.
Router(config-line)#login local
Habilita la autenticación local utilizando las credenciales de usuario y clave que se definieron antes.
Router(config-line)#exit
3. Restringir el acceso exclusivamente desde un conjunto de direcciones IP específicas.
Router(config)#ip access-list standard SSH
Router(config-std-nacl)#permit 192.168.100.0 0.0.0.255
Router(config-std-nacl)#deny any log
Router(config-std-nacl)#exit
Crea una lista de acceso estándar que sólo permite el paso de tráfico generado en la subred 192.168.100.0/24.
El resto del tráfico está denegado, y se guardará registro de los intentos rechazados.
Router(config)#line vty 0 5
Router(config)#access-class SSH in
Aplica la ACL llamada SSH que se creó antes a los accesos por terminal virtual, limitando de esta manera a las direcciones IP de la red 192.168.100.0/24 el acceso por SSH al dispositivo.
Enlaces útiles:
Al momento de enfrentar un inconveniente en la operación de la red es necesario comenzar por identificar el nivel de complejidad del problema; no todas las situaciones tienen la misma complejidad, consecuencias y gravedad. Es por esto preciso diferenciar algunas categorías básicas:
- Caso.
Se da la denominación de caso a un incidente operativo que afecta la operación normal de la red, que ha sido detectado a partir del monitoreo regular de la operación y cuya resolución escapa a las tareas regulares de mantenimiento.
El caso puede surgir de problemas en la operación de la red y se inicia independientemente de su alcance y posibilidad de afectación a la operación de los clientes.
Por lo general los casos se documentan y se reportan a una instancia técnica de soporte interna o externa para su análisis y resolución.
Denominamos caso, por ejemplo, al hecho de que en un sector específico de la red se detecte un problema de enrutamiento que hace que la red no se comporte del modo esperado. Verificada la situación y debidamente documentada, el caso se eleva a la instancia correspondiente para su análisis y respuesta.
- Incidente.
Un incidente es un problema puntual reportado por un usuario en particular. Los incidentes son ocasionales y generalmente reportados por los usuarios requiriendo soporte de parte del proveedor de servicio.
Téngase en cuenta que si bien el incidente se define a partir de un usuario en particular, si el mismo es causado por alguna falla de la red en su operación el mismo puede ser reportado por múltiples usuarios de modo concurrente. En este caso se trata de un incidente de tipo masivo y el análisis de esta concurrencia es parte del proceso de análisis.
Son ejemplos de incidentes, por ejemplo, la dificultad de un usuario particular para levantar una VPN, o el reporte de falta de conectividad a Internet.
- Problema.
Con el término problema se identifica a un acontecimiento en la infraestructura de la red que afecta al desempeño de la misma. El problema puede corresponderse o estar relacionado o no con incidentes reportados de los usuarios, pueden afectar la performance (no la conectividad) y en algunos casos puede ser superado sin que el usuario lo perciba claramente.
Ejemplos de problemas de la red puede ser la inestabilidad de un enlace de transporte o la salida de servicio de un dispositivo colocado de manera redundante.
Otros post relacionados:
Bibliografía asociada:
