26 de agosto de 2015

IoE y las redes inalámbricas

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


16 de agosto de 2015

Mensajes de estado y eventos en Cisco IOS

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.


3 de agosto de 2015

Desactivación de servicios en IOS

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.

23 de julio de 2015

Implementación de SSH en Cisco IOS

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:

20 de julio de 2015

Caso, incidente, problema

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:

9 de julio de 2015

Direcciones IPv6 link local

IPv6 es un protocolo completamente diferente de su predecesor, IPv4. Diferente no sólo en la longitud de las direcciones que utiliza (128 bits en total) sino en múltiples aspectos. Uno de ellos: en una misma interfaz pueden encontrarse múltiples direcciones IP simultáneamente.
Uno de los motivos de esta multiplicidad de direcciones es que en IPv6 hay diferentes direcciones de unicast: direcciones unicast globales, direcciones unicast unique local y direcciones unicast link local (sobre estos diferentes tipos sugiero revisar el post "Tipos de direcciones IPv6").

Las direcciones IPv6 link local
Una de las tantas innovaciones que introduce IPv6 son estas direcciones: toda interfaz que implementa IPv6 tiene al menos una dirección asignada, la dirección de link local.
Las direcciones de link local pertenecen a un rango específico definido por el prefijo FE80::/10 (1111 1110 10xx xxxx/10).
La porción de nodo o identificador de interfaz de estas direcciones puede obtenerse por configuración manual o automáticamente. Para la asignación automática aplican 2 procedimientos:
  • EUI-64, utilizado principalmente para la asignación en interfaces de dispositivos de infraestructura.
    Es el implementado por IOS.
  • RFC 3014, utilizado preferentemente en interfaces de dispositivos terminales.
    Es el implementado en sistemas de escritorio como Microsoft o Mac OS X.
Son direcciones utilizadas para el establecimiento de comunicaciones entre interfaces alojadas en el mismo segmento de red (dominio de broadcast) identifican a la interfaz únicamente dentro del enlace al que se encuentra conectada.
Aseguran la operación de múltiples protocolos aún antes de que la interfaz tenga asignada una dirección IPv6 global unicast o unique local. Por este motivo se utilizan en procesos de configuración automática, descubrimiento de vecinos, etc. Son utilizadas para identificar los neighbor de los protocolos de enrutamiento y el próximo salto en la tabla de enrutamiento.
No son ruteables. Los paquetes que tienen una dirección de link local como origen o destino no deben ser reenviados por los dispositivos de capa 3.

Sintetizando
  • Estas direcciones se configuran automáticamente siempre que el protocolo IPv6 esté habilitado en la interfaz, sin necesidad del operador.
  • Pueden ser definidas estáticamente.
    Router(config-if)#ipv6 address FE80::1 link-local
  • Son accesibles solamente dentro del mismo segmento de red.
  • Solamente responden ping desde interfaces en el mismo segmento de red.
  • Se pueden verificar utilizando los comandos show habituales.
    Router#show ipv6 interface
    Router#show ipv6 interface brief
  • Se utilizan para la operación de múltiples procesos como stateless configuration, enrutamiento dinámico y NDP (Neighbor Discovery Protocol).
Enlaces de referencia
Bibliografía sugerida

Siglas, siglas y más siglas

Los que trabajamos en el ámbito de las tecnologías Cisco estamos acostumbrados a lidiar con siglas: EIGRP, CDP, OSPF, NDP, IP, TCP, etc., etc. Algunas propias, otras no, las siglas son parte de nuestra realidad diaria.
Se dice que Cisco Systems es una de las organizaciones que más siglas utiliza en el mundo, y esto hace suponer que debiéramos estar habituados a las mismas. Pero en los últimos tiempos estamos recibiendo una nueva lluvia de conjuntos de letras ya no referidas directamente a protocolos o tecnologías, sino al entorno de aplicación de las mismas, y que debemos comenzar a dominar pues posiblemente convivamos con ellas por muchos años, y por eso me pareció conveniente revisar algunas de ellas:
  • MtoM
    Machine to Machine.
    Alude a comunicaciones digitales establecidas directamente entre dos dispositivos o máquinas.
  • HtoH
    Human to Human.
    Refiere a las comunicaciones clásicas en sentido amplio, establecidas entre dos personas.
  • MtoH
    Machine to Human.
    Referencia a comunicaciones digitales establecidas entre un dispositivo o máquina y una persona.
  • IoT
    Internet of Things.
    Concepto enunciado por Kevin Ashton del MIT que refiere al momento en el que se conecten a Internet más objetos que personas.
    Alude básicamente a una red basada en comunicaciones MtoM.
  • IoE
    Internet of Everything.
    Concepto impulsado por Cisco Systems que busca una visión más amplia que el de IoT y que apunta a una Internet en la que objetos, procesos y personas se comunican entre sí de modos diversos para el intercambio de información en formato digital: MtoM, HtoH, MtoH.
  • IdT
    Internet de Todo.
    Versión en castellano de IoE (no confundir con IoT).
  • IdC
    Internet de las Cosas.
    Versión en castellano de IoT.
  • IT
    Information Technology.
    Conjunto de tecnologías implicadas en el intercambio de información en formato digital.
  • OT
    Operation Technology.
    Conjunto de technologías digitales aplicadas a procesos de producción y gestión.
  • TIC
    Tecnologías de la Información y las Comunicaciones.
    Corresponde a la sigla en inglés ITC (Information Technology and Communications).
  • TEC
    Tecnologías de Enseñanza y Comunicación.
  • TAC
    Tecnologías de Aprendizaje y Comunicación.