Rutina de configuración Cisco IOS - Gráfica

En el desarrollo de la tarea diaria es importante saber con qué trabajamos, saber qué se debe hacer y también cómo hacerlo.
En este sentido tienen un lugar importante los procedimientos y rutinas de trabajo. Las rutinas nos permiten operar de modo rápido y seguro, evitando en lo posible errores a través de la adquisición de hábitos de buenas prácticas.
En este sentido hay una rutina de trabajo muy sencilla que facilita la realización de cambios en la configuración de los dispositivos, y que desafortunadamente no siempre respetamos. Si bien no es obligatorio trabajar de esta forma, es una buena práctica adoptar esta u otra rutina de trabajo semejante.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Next-Generation Cryptography

En la actualidad se sugiere que se actualicen las herramientas criptográficas que se implementan en las políticas corporativas de protección de la confidencialidad de la información transmitida.
Para esta actualización se propone la adopción de un conjunto de algoritmos denominados "Suite B".

La Suite B se considera como un estándar público avanzado de criptografía que proporciona sistemas de seguridad de al menos 128 bits de longitud o equivalentes, lo que supera claramente los estándares utilizados hasta el momento y brinda un entorno seguro para el intercambio de información corporativa sobre redes públicas como Internet.

Suite B responde a los requerimientos de múltiples certificaciones de seguridad como PCI (Payment Card Industry), HIPAA (Health Insurance Portability and Accountability Act) y FIPS (Federal Information Processing Standards).

La suite B

Ha sido inicialmente definida por la NSA como adecuada para asegurar información clasificada, y ha sido descrita en el RFC 4869 para su utilización con IPsec. Considera 4 algoritmos criptográficos de dominio público:

• Cifrado basado en AES de 128 o 256 bits en modo Galois/Counter (GCM).
• Firma digital con ECDSA utilizando curvas de 256 y 384 bits.
• Para el intercambio de llaves se utiliza método ECDH.
• Algoritmo de hash se basa en SHA-2.

Para asegurar compatibilidad e interoperabilidad los dispositivos que incorporan Suite B están sometidos a las mismas regulaciones y certificaciones que los que brindan el soporte IPsec tradicional incluyendo FIPS y Common Criteria.

La Suite B evoluciona el conjunto de algoritmos típicamente soportado para la implementación de IPsec:

• Para el cifrado simétrico:
  Inicialmente se sugería DES o 3DES.
  Ahora AES 128 o AES 256.
• Para la firma digital:
  Inicialmente se sugería RSA de 2048 bits.
  Ahora ECDSA.
• Como algoritmo de hash:
  Inicialmente se sugería MD5 o SHA-1
  Ahora SHA-2 (256, 384 o 512 bits)
• Para el intercambio de llaves:
  Se sugería DH
  Ahora ECDH

Suite B en Cisco

Cisco ha participado del desarrollo de esta suite de algoritmos de cifrado desde el inicio, particularmente trabajando en el desarrollo y estandarización del modo de operación Galois/Counter de AES utilizado en el cifrado simétrico de esta suite.

Actualmente la Suite B está incorporada en los principales productos Cisco de manera tal que pueden aplicarse en soluciones VPN IPsec o DMVPN. 

Estos algoritmos están disponibles para su implementación en los routers ISR G2 desde IOS 15.1 o 15.2 según la plataforma. 

También se introdujo en IOS-XE 3.7, con lo que está disponible en CSR 1000v con IOS-XE 3.12 y en ISR 4400 desde IOS-XE 3.9, ISR 4300 desde IOS-XE 3.13.
En Cisco ASA la suite B está disponible a partir de versión 9.0. Requiere AnyConnect 3.1 o superior con licencia Premium.

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Marcado de tráfico para QoS

Cuando se habla de calidad de servicio (QoS) es preciso tener en consideración que para  efectivizar los objetivos de preservación de tráfico que se proponen es necesario completar una serie de tareas específicas.
La primera de esas tareas es la clasificación de tráfico y a continuación el marcado.
El tráfico de la red puede ser marcado aprovechando diferentes campos de los encabezados de capa 2 y/o capa 3 del modelo OSI. Al uso de esos campos está dirigido este apunte sintético en el que recojo las principales convenciones para el marcado de tráfico.

• DSCP
• IP Precedence
• Per-Hop Behavior
• CoS (802.1p)

E incluido al final también las recomendaciones del RFC 4594 a este respecto.

Marcado de tramas para calidad de servicio by Edubooks Ediciones on Scribd

Otras publicaciones sobre el tema

• Post: Modelos de implementación de QoS
• Post: Elementos básicos de QoS
• Post: ¿Qué es AutoQoS?
• Bibliografía: Introducción a Quality of Services

Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en

 el Glosario de Siglas y Términos de Networking

que está disponible en la Librería en Línea de EduBooks.

Diseño de subredes en IPv6

Cuando abordamos el diseño de redes IPv6 inevitablemente surge el tema del "cálculo de subredes

IPv6". Durante un tiempo me he resistido a hablar de este tema. Esta resistencia de mi parte tiene un motivo claro: Cuando mencionamos el término "subred" automáticamente todos los que hemos trabajado redes IPv4 pensamos en los mecanismos habituales de cálculo de la máscara de subred en función de cantidad de nodos y cantidad de subredes necesarias e intentamos trasladar esos conceptos al marco del nuevo protocolo. Esto no es aplicable a IPv6. En IPv6 no existe la máscara de subred.
IPv6 es un protocolo diferente de IPv4, una evolución ciertamente, pero una evolución importante que incorpora una multitud de conceptos nuevos que apuntan a resolver las dificultades que ha presentado IPv4 en los últimos30 años:

• IPv6 incorpora un espacio de direccionamiento más amplio.
  Esto a veces hace pensar en un espacio de direccionamiento inagotable, y si bien no estoy de acuerdo con esa afirmación, no podemos negar que la cantidad de direcciones posibles es claramente muy grande.
• IPv6 incorpora múltiples tipos de direcciones de unicast que no están presentes en IPv4: link local, unique local y globales.
• En el diseño mismo de las direcciones globales IPv6 se considera una estructura jerárquica tripartita: red global | red local | nodo.
• La nomenclatura estándar adoptada para las direcciones utiliza 32 dígitos hexadecimales (cada dígito represente 4 bits) separados en 8 campos de 4 dígitos cada uno.
• IPv6 incorpora nuevos mecanismos de asignación de configuración y de ID de nodo. Asignación stateless de configuración y autoconfiguración de la porción de nodo.

Un tema importante: los diferentes tipos de direcciones de unicast

En IPv6 hay 3 tipos básicos de direcciones unicast: link local, unique local y globales.
De estos 3 tipos, las que se suelen tomar como referencia son las direcciones globales. Estas direcciones tienen una estructura jerárquica de 3 niveles como ya dije, sin que el RFC indique que cada uno de esos niveles tenga asignada una longitud obligatoria. El único límite son los 128 bits.
Sin embargo, en la implementación concreta del direccionamiento global se recomienda observar algunas prácticas:

• Al llamado identificador de red global se recomienda asignar un total de 48 a 56bits.
  Sobre esta base, los organismos regionales de asignación de direcciones suelen asignar prefijos de hasta /32 bits a los ISPs (en algunos casos incluso prefijos más cortos) con la recomendación de que se utilicen prefijos /48 o /56 para los clientes corporativos. De esta manera se aseguran que toda la red de un ISP pueda ser sintetizada (sumarizada) en un único prefijo /32 o menor.
• Por otra parte, se sugiere que el identificador de red local sea un /64, de modo tal que en una red corporativa se pueden utilizar 8 o 16 bits para identificar la red local, permitiendo dividir de esta manera la red corporativa en 256 o 65536 redes internas que se publican como una sola red /56 o /48 hacia el ISP.
• Finalmente se sugiere que los últimos 64 bits se reserven para el identificador de nodo.

De esta forma, sin necesidad de definir una márcara de subred, la estructura misma de la dirección IP y los mecanismos de asignación de direcciones globales dejan entre 8 y 16 bits para la división interna de la red en subredes o redes locales.

¿Por qué dejar 64 bits para el identificador de nodo?
Para quienes estamos acostumbrados a trabajar en la escasez propia de IPv4, utilizar 64 bits para identificar el nodo puede parecer un exceso. Pero debemos recordar que IPv6 no está diseñado a partir de la escasez sino de la funcionalidad y la practicidad.
Entre las funciones nuevas que introduce IPv6 están las direcciones de link local y el proceso de autoconfiguración stateless. En ambos casos se recurre a la generación automática de un identificador de nodo único dentro del segmento sin necesidad de intervención del Administrador al que denominamos autoconfiguración del ID de nodo.
Hay 2 mecanismos definidos con este propósito:

• EUI-64, que opera a partir de la dirección MAC de la interfaz.
• ID Privado, que se genera a partir de una variable pseudo random.

En ambos casos el ID de nodo que se genera automáticamente es un ID de 64 bits de longitud. Por este motivo la recomendación es dejar 64 bits para el ID de nodo siempre. Si no lo hiciéramos no se podrían utilizar los procedimientos de autoconfiguración y sería necesario recurrir a la configuración estática de las interfaces o a la implementación obligatoria de DHCPv6.

¿Cómo habría que diseñar las subredes entonces?
Si tenemos en cuenta lo dicho hasta aquí, tomemos un ejemplo para hacer el diseño del direccionamiento de redes locales (subredes).
Supongamos el el ISP ALFA ha recibido del organismo regional correspondiente el prefijo

2001:abcd::/32

La empresa BETA solicita a nuestro ISP un espacio de direccionamiento global, como consecuencia de lo cual se le asigna el prefijo

2001:abcd:a1::/48

Sobre la base de este prefijo, el Administrador de la red necesita definir 8 redes locales o subredes, las que podría hacer de la siguiente manera:

2001:abcd:a1:0::/64   Gestión de la red
2001:abcd:a1:1::/64   Telefonía
2001:abcd:a1:2::/64   Red inalámbrica interna
2001:abcd:a1:3::/64   Red inalámbrica de visitantes
2001:abcd:a1:4::/64   Ventas
2001:abcd:a1:5::/64   Administración
2001:abcd:a1:6::/64   Gerencia
2001:abcd:a1:7::/64   Operaciones

De esta manera:

• Contamos con una red diferente para cada una de las áreas de la empresa.
• Tenemos la posibilidad de crecer con nuevas redes en la medida en que se requiera, sin que esto signifique una dificultad o requiera rediseño.
• La Empresa publica una única ruta global hacia el ISP (2001:abcd:a1::/48).
• El ISP publica una única ruta global hacia Internet (2001:abcd::/32).
• Internamente se puede implementar autoconfiguración en aquellos dispositivos que no requieran configuración estática o que no soporten o que por política no sea necesario que reciban configuración por DHCPv6.
• El cuarto campo de la dirección IP identifica claramente la red local a la que pertenece cada IP.
• No son necesarios cálculos de máscaras de subred de ningún tipo.

Enlaces relacionados

• Post: Tipos de direcciones IPv6
• Post: Direcciones IPv6 link local
• Post: IPv6 llegó para quedarse
• Post: ¿Estás preparado para IPv6?
• Post: Direccionamiento IPv6 en enlaces punto a punto (1)
• Video: ¿Estás preparado para IPv6?
• Presentación: Introducción al Direccionamiento IPv6
• Presentación: IPv6 en la certificación CCNA R&S
• Bibliografía: Protocolo IPv6 Básico versión 2

Buenas prácticas en la gestión de la red

Un tema recurrente en la gestión (management) de la red es el de las buenas practicas, mejores prácticas o best practices.
En este sentido hay diferentes tipos de recomendaciones de este tipo: buenas prácticas de seguridad, buenas prácticas de configuración, buenas prácticas de gestión, etc.
A solicitud de uno de los miembros del grupo de Facebook, junto con varios miembros hemos confeccionado la lista que presento a continuación. Es preciso tener presente que para este post he mantenido solamente prácticas relacionadas con el acceso y gestión del plano de management de los dispositivos. En futuras entregas veremos de ir generando listas semejantes para otras implementaciones.

Han colaborado en esta lista: Luis Miguel Zavaleta Leiva, Raffic Vera Constante, Eduardo Mendez, Moisés Morales, Gonzalo Hernán Aguilera Gatica y Augusto Iparraguirre Torrau. Muchas gracias a todos.

• Habilitar exclusivamente acceso remoto utilizando SSH (bloquear el Telnet).
• Si se van a utilizar interfaces gráficas aplicar HTTPS (bloquear HTTP).
• Definir una VLAN de gestión y autorizar solamente a dispositivos conectados a esa VLAN el acceso al plano de gestión aplicando ACLs con una política restrictiva.
• Implementar AAA para realizar autenticación, autorización y accounting en el acceso a los dispositivos.
• Si se va a implementar SNMP (tanto sea para monitoreo como para configuración) utilizar SNMP v3 con autenticación y cifrado.
• Implementar un servidor NTP interno y utilizarlo como fuente de sincronización del reloj de todos los dispositivos y sistemas.
• Implementar un servidor de Syslog para utilizarlo como repositorio de los registros de eventos los dispositivos de la red.
• Mantener actualizado el sistema operativo de los dispositivos de la red que lo permitan.
• Implementar un servidor FTP con control de acceso para mantener copias de respaldo actualizadas de configuraciones e imágenes de sistemas operativos.
• Mantener información detallada y actualizada de la red, restringiendo a personal autorizado el acceso a esa documentación.
• Mantener un inventario actualizado de hardware y software de la infraestructura.
• Mantener documentación actualizada de los procedimientos y acciones concernientes a los planes de contingencia y continuidad del negocio en lo que respecta al área de networking.