Diferencia entre IPSec sobre GRE y GRE sobre IPSec y sus limitaciones

 

Por Muhammad Haris Maqsood

IPsec sobre GRE (Encapsulamiento de Enrutamiento Genérico) y GRE sobre IPsec son dos enfoques diferentes para proteger la comunicación en una red. Analicemos cada uno de ellos:

IPSec sobre GRE:

La tecnología IPSec sobre GRE utiliza GRE para encapsular paquetes que han sido encapsulados mediante IPSec.

Explicación:  IPSec sobre GRE implementa el cifrado IPSec en las interfaces de túnel. El sistema detecta los flujos de datos que deben cifrarse en las interfaces de túnel (se configura una ACL para vincular los flujos de datos entre dos segmentos de red de usuario).

Los paquetes que coinciden con la ACL se encapsulan en paquetes IPSec y luego en paquetes GRE antes de transmitirse por el túnel. Los paquetes que no coinciden con la ACL se transmiten directamente por el túnel GRE sin encapsularse con IPSec, lo que significa que no se transmiten de forma segura. Además, un túnel GRE no está protegido por IPSec durante su configuración.

GRE sobre IPSec:

La tecnología GRE sobre IPSec utiliza IPSec para encapsular paquetes que han sido encapsulados por GRE.

Explicación: GRE sobre IPSec implementa el cifrado IPSec en interfaces físicas. El sistema detecta los flujos de datos GRE que deben cifrarse en las interfaces físicas (se configura una ACL para que coincida con los flujos de datos GRE entre dos puertas de enlace). De esta forma, todos los flujos de datos que se transmiten a través del túnel GRE están protegidos por IPSec. El túnel GRE también está protegido por IPSec durante su configuración.

GRE sobre IPSec admite la encapsulación tanto en modo túnel como en modo transporte. El modo túnel utiliza un encabezado IPSec adicional, lo que aumenta el tamaño del paquete y aumenta la probabilidad de fragmentación. Por lo tanto, se recomienda el modo transporte.

Comparación:

Los túneles IPSec solo admiten la encapsulación y el cifrado de paquetes unidifusión, mientras que los túneles GRE admiten la encapsulación tanto de paquetes unidifusión como multidifusión. Sin embargo, los túneles GRE son inseguros. Por lo tanto, debemos aprovechar las ventajas de IPSec y GRE y comunicarnos entre nosotros mediante IPSec sobre GRE o GRE sobre IPSec.

Tomado de: https://harrymaq.medium.com/difference-between-ipsec-over-gre-gre-over-ipsec-b655b7baf9f1

¿Qué es Netflow?

 

Por Oscar Gerometta

En los últimos años ha ganado relevancia, de modo creciente, una herramienta muy particular: NetFlow.
 

Originalmente creada para monitorear comunicaciones individuales, hoy es una herramienta utilizada para el análisis tanto de prestaciones de calidad de servicio como de seguridad.
 

Es por esto que consideré conveniente preguntarnos, ¿qué es NetFlow?

NetFlow es una herramienta de monitoreo desarrollada por Cisco e introducida en las diferentes formulaciones de IOS a partir del año 1996 (Cisco IOS 11.x). 

 

Esta herramienta permite relevar información estadística referida al tráfico en la red cuando ingresa o sale a través de una interfaz.
 

Si bien inicialmente estaba incorporada en la imagen de IOS solamente de algunos dispositivos, progresivamente se ha incorporado a nuevas plataformas de modo que en la actualidad, en redes que utilizan IOS XE, está disponible prácticamente en toda la infraestructura de la red corporativa.
Responde a 2 premisas básicas:

• Es completamente transparente a las aplicaciones y dispositivos que operan en la red.
• No es necesario que sea soportada en todos los dispositivos de la infraestructura de la red.

Su implementación tiene múltiples aplicaciones posibles, las más frecuentes son:

• Registro estadístico de tráfico para realizar un análisis de línea base.
• Facturación de servicios de red a usuarios.
• Monitoreo y análisis del tráfico y aplicaciones que están corriendo en la red.
• Diseño general de seguridad de la red.
• Detección y prevención de ataques DoS o DDoS.
• Monitoreo de tráfico malicioso en la red.

Con este propósito NetFlow releva estadística de comunicaciones utilizando el concepto de flujo (flow).

 

¿Qué es un flujo? Un stream o cadena unidireccional de paquetes entre un sistema de origen y un sistema destino específicos que es identificada tomando como base de referencia 7 parámetros específicos:

• Dirección IP origen.
• Dirección ID destino.
• Puerto TCP o UDP de origen.
• Puerto TCP o UDP de destino.
• Tipo de protocolo (campo del encabezado IP).
• Tipo de servicio (campo del encabezado IP).
• Interfaz lógica de ingreso.

Esta misma definición de flujo se aplica a tráfico IPv4 e IPv6.

 

A esta información básica se puede agregar información complementaria a partir de NetFlow versión 9. Los registros NetFlow solo contienen información estadística, no contenido de los paquetes.

Estos datos se exportan como registros de NetFlow hacia un servidor que concentra esos datos y en donde se analizan.

 

El registro de una comunicación se genera cuando una comunicación TCP llega a su fin, o por un contador de inactividad de la comunicación, o se puede definir por configuración que periódicamente se genere el registro aún cuando la comunicación no ha terminado. 

 

 

Transporte de los registros

 

Los registros de NetFlow se transportan utilizando segmentos UDP que suelen estar dirigidos al puerto 2055 del collector, pero que también puede utilizar otros puertos. 

 

El dispositivo que genera los registros, en general, no retiene los datos correspondientes a los registros que se envían al collector. Esto no permite realizar un seguimiento del transporte de los registros con lo que, si se produjera la pérdida de algún segmento, no se puede recuperar la información.

 

Por este motivo algunas implementaciones de NetFlow utilizan SCTP para asegurar el envío de los registros. Particularmente cuando se trata de NetFlow versión 8 o 9.
 

El inconveniente de este tipo de implementaciones es que se requiere interacción entre cada exporter y cada collector definido; esto puede tener un impacto significativo en la performance de ambos componentes.

Arquitectura de NetFlow
 

 

 

La implementación de NetFlow supone una arquitectura específica:

• Exporter
  Uno o varios dispositivos que tienen Netflow habilitado.
• Collector
  Una consola que recolecta y concentra la información.
• Aplicación de análisis
  Aplicación que procesa los datos generados por el exporter y concentrados en el collector para obtener información significativa.
  Cisco StealthWatch es un ejemplo de este tipo de aplicaciones.

Versiones de NetFlow

 

Desde su lanzamiento NetFlow ha tenido diferentes versiones.

La versión implementada en los dispositivos Cisco actuales es NetFlow v9. Adicionalmente, la herramienta se abrió con múltiples RFCs de la IETF, lo que dio lugar a IPFIX: 

• RFC 3954 - NetFlow versión 9.
• RFC 5101 - Especificación del protocolo de IPFIX para el intercambio de información de flujo de tráfico.
• RFC 5102 - Modelo de información para IPFIX.
• RFC 5103 - Exportación bidireccional usando IPFIX.
• RFC 5153 - Directrices para la aplicación de IPFIX.
• RFC 5470 - Arquitectura de IPFIX.
• RFC 5471 - Pautas para las pruebas de IPFIX.
• RFC 5472 - Pertinencia de IPFIX.

NetFlow es una marca registrada de Cisco.

Pero muchos otros fabricantes han desarrollado herramientas semejantes que cumplen la misma tarea:

• Argus 
• Jflow o cflowd de Juniper Networks
• NetStream de 3Com/HP
• NetStream de Huawei Technologies
• Cflowd de Nokia
• Rflow de Ericsson
• AppFlow de Citrix
• sFlow implementado por varios fabricantes: Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Dell, D-Link, Enterasys, Extreme, F5, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, ZTE, ZyXEL, etc.

Tomado de: http://librosnetworking.blogspot.com/2021/08/que-es-netflow.html

Port Aggregation (EtherChannel)

 

Por Oscar Gerometta

La escalabilidad en la capacidad de las redes LAN es un elemento crítico para la evolución de las mismas. En un área dominada por Ethernet se escala básicamente de 10 en 10: 10 Mbps, 100 Mbps, 1 Gbps…

 
Escalar en la capacidad de los enlaces Ethernet requiere actualización de hardware y esto es un costo significativo. Este es el lugar para el desarrollo e implementación de recursos como Port Aggregation, también conocido como EtherChannel.

EtherChannel es la tecnología propietaria de Cisco derivada de un desarrollo inicial de Kalpana (empresa de switching adquirida por Cisco) para dar respuesta a esta necesidad de escalabilidad y puesta de operación en los años ‘90.

 
Con el paso del tiempo dio lugar a la publicación por parte de la IEEE del estándar 802.3ad denominado Link o Port Aggregation.

Ambos protocolos no son compatibles entre sí, uno es claramente estándar mientras el otro no, sin embargo, muchas veces los términos EtherChannel, Port Aggregation y Link Aggregation se utilizan como sinónimos lo que puede dar lugar a confusiones.

Características del port aggregation
Al configurar port aggregation es conveniente tener presentes algunos puntos:

• El canal port aggregation está conformado por cada uno de los enlaces físicos (entre 2 y 8) que lo integran y una interfaz virtual (interface port-channel).
• El port aggregation conforma una conexión uno a uno. Esto significa que conectan un dispositivo individual a otro dispositivo individual, no uno a varios.
• Una vez configurado un port aggregation cualquier configuración que se aplica a la interfaz port-channel afecta a la operación de todo el canal.
  Cualquier modificación de configuración que se realiza sobre un puerto físico afecta exclusivamente a ese puerto físico.
• Todas las interfaces físicas que se integran en el port-channel deben ser de iguales características físicas (medio físico, capacidad).
• Todas las interfaces físicas deben estar operando a la misma velocidad y en el mismo modo dúplex (por eso se sugiere no dejar estos aspectos librados a la autonegociación).
• Todas las interfaces físicas deben estar asignadas a la misma VLAN o estar configuradas como troncales con iguales características (VLAN nativa, VLANs permitidas, tec.).
• Las interfaces físicas que conforman un un canal pueden tener asignado diferente costo de STP.
• En los switches Catalyst ME, solamente los puertos NNI y ENI soportan negociación dinámica con LACP o PAgP.

Mecanismos de negociación
Hay 2 mecanismos básicos para la definición de un port-channel:

• Configuración estática.
• Negociación dinámica.
  Independientemente del protocolo elegido introduce carga de tráfico y demora en la inicialización de los puertos.
  - PAgP
    Es el protocolo propietario de Cisco.
  - LACP
    Es el protocolo estándar definido por la IEEE.

Link Aggregation Control Protocol

• Corresponde a la especificación IEEE 802.3ad.
• Permite agrupar varios puertos físicos en un único canal lógico.
• Permite la negociación automática del canal.
• Al ser estándar permite interoperabilidad entre fabricantes.
• Verifica la consistencia de configuración de los puertos y gestiona el agregado de enlaces los posibles fallos entre los 2 switches.
• Si se modifica la configuración de un puerto físico ese cambio se traslada automáticamente a los demás puertos físicos que forman el canal.
• Ambos dispositivos intercambian paquetes LACP sobre los puertos del canal.
• El switch con menos prioridad define cuáles son los puertos físicos que participan del canal.
• Los puertos son miembros activos del canal de acuerdo a su prioridad; menor valor de prioridad indica una prioridad más alta.
• Se pueden asociar hasta 16 enlaces físicos a un canal lógico, solamente 8 de esos enlaces serán activos de modo simultáneo.
• LACP permite 2 modos de operación:
  - Activo
    Se activa LACP incondicionalmente.
  - Pasivo
    Sólo se activa LACP si detecta otro dispositivo LACP.

Port Aggregation Protocol

• Proporciona servicios semejantes a los de LACP.
• Es un protocolo propietario de Cisco por lo que no permite interoperabilidad con otras marcas.
• Los paquetes se intercambian a través de los puertos que componen el canal.
• Se comparan las capacidades de los puertos y se establece el canal con aquellos puertos que tienen iguales características.
• Sólo se integran en el canal puertos con idéntica configuración de VLANs o troncales.
• Cuando se modifica uno de los puertos que componen el canal, se modifican automáticamente esos parámetros en todos los puertos del canal.
• No es compatible con LACP.
• PAgP presente 2 modos de operación:
  - Desirable
    Activa PAgP sin condiciones.
  - Auto
    Activa PAgP solamente si detecta en el otro extremo un dispositivo PAgP. 

 

 Tomado de: http://librosnetworking.blogspot.com/2019/05/port-aggregation-etherchannel.html

Filtrado BPDU (BPDU Filter)

 

 

Uso del Filtrado BPDU para desactivar STP en un puerto.

Normalmente, STP opera en todos los puertos de Switch en un esfuerzo por eliminar todos los Bridging Loops (bucles) antes de que puedan formarse. 

Las BPDUs se envían a todos los puertos del switch, incluso en los puertos donde Portfast ha sido habilitado. Las BPDUs también pueden ser recibidas y procesadas si algunas son enviadas por switches vecinos.

Siempre debería permitir a STP funcionar en un switch para prevenir loops. Sin embargo, en casos especiales, cuando necesite prevenir BPDUs que se envíen o procesen en uno o más puertos del switch, se puede usar el Filtrado BPDU para desactivar STP de forma efectiva en esos puertos.

Por defecto, el Filtrado BPDU está deshabilitado en todos los puertos del switch, se puede configurar el Filtrado BPDU como un valor global por defecto que afecta a todos los puertos del switch, el comando es el siguiente:

switch(config)# spanning-tree Portfast bpdufilter default

La palabra “default” indica que el Filtrado BPDU se activará automáticamente en todos los puertos que tienen habilitado Portfast. Si Portfast está deshabilitado en un puerto, entonces el filtrado BPDU no se activará.

También se puede habilitar o deshabilitar el Filtrado BPDU en puertos específicos del switch mediante el siguiente comando:

switch(config-if)# spanning-tree bpdufilter { enable | disable }

Tenga cuidado con habilitar el Filtrado BPDU, solo bajo circunstancias en las que usted esté seguro que un puerto del switch tendrá un solo host conectado y que un loop será imposible. 

Habilite el Filtrado BPDU solo si el dispositivo conectado no puede permitir que BPDU sea aceptado o enviado, de lo contrario, debe permitir que STP funcione en los puertos del switch como una precaución.

Nota: no confunda BPDU Filtering con BPDU Guard. BPDU Guard se usa para detectar BPDU entrante en el puerto donde las BPDUs no se esperan ver, entonces protege la estabilidad de STP previniendo que esas BPDUs sean procesadas.

 Tomado de: https://www.lesand.cl/foro/filtrado-bpdu

 

Variedades de Spanning Tree Protocol (STP)

Sabores de STP

Existen múltiples versiones de Spanning Tree Protocol:

• STP: Es la especificación original de STP, definida en 802.1D. STP es algunas veces llamado Spanning Tree común (Common Spanning Tree - CST) debido a que el protocolo asume una instancia de Spanning Tree para toda la red conmutada, independientemente de la cantidad de  VLANs.
• PVST+: Per-VLAN Spanning Tree Plus es una mejora realizada por Cisco  sobre el STP que proporciona una instancia de 802.1D spanning tree  para cada VLAN configurada en la red.
• RSTP: Rapid STP, ó IEEE 802.1w, es una evolución del STP que provee rápida convergencia en comparación con STP. De todas maneras, RSTP aún proporciona solamente una instancia de STP.
• Rapid PVST+: Es otra mejora de Cisco del RSTP que utiliza PVST+. El Rapid PVST+ proporciona una instancia separada de 802.1w para cada VLAN.
• Multiple Spanning Tree Protocol: MSTP es un estandar IEEE inspirada en la implementación del protocolo propietario de Cisco Multiple Instance STP (MISTP). El MSTP puede mapear multiples VLANs dentro de una instancia de  spanning tree. La implementación Cisco de MSTP se llama MST, la cual provee hasta 16 instancias de RSTP y combina muchas VLANs dentro de la misma topología física y lógica de una instancia de RSTP común. 

 

Tomado de: https://www.networkplayroom.com/2017/09/stp-flavors.html

Traducido al español por Ing. José Torrico Gumucio, Instructor Cisco CCNA/CCNA CyberOps/CCNAS/CCNP - Instructor trainer

Cisco Unified Access Data Plane (UADP) ASIC 2.0

Por Oscar Gerometta

Al introducir los switches Catalyst 9000 hice referencia a que una de sus características distintivas me referí a la introducción en su hardware de los nuevos UADP ASIC 2.0 (UADP - Unified Access Data Plane).

Los switches Cat 9K se basan en estos nuevos circuitos ASIC (Application Specific Integrated Circuit) que agregan flexibilidad a la configuración de los mecanismos de reenvío de tráfico del plano de datos flexibilidad en la asignación de las tablas de información tanto SRAM (Static Random Access Memory) como TCAM (Ternary Content Addressable Memory). 

 

Estas innovaciones convierten a estos ASICs en una excepcional herramienta de hardware ajustable a los requisitos de implementación de cada red. Para esto Cisco ofrece un conjunto de plantillas ya probadas para su adaptación.

La característica destacable de estos circuitos en su versión 1.0 fue la convergencia completa del tráfico cableado e inalámbrico. Este fue el primer ASIC programable que constituyó la base de los switches Catalyst 3650 y 3850.

UADP 2.0

Se trata de la última generación de ASICs.

 

 

 

Entre sus características destacan:

• 7460 millones de transistores (la versión 1 utilizaba 1300 millones de transistores).
• Hasta cuadruplica el rendimiento de otro hardware de la industria.
• Soporta tablas SRAM y TCAM flexibles de 384000 contadores que se adaptan a diferentes implementaciones.
• Las tablas de búsqueda se intercambian entre diferentes núcleos.
• Microcontroladores integrados para gestionar cifrado, fragmentación y NetFlow.
• Soporta hasta 240 Gbps de tráfico agregado.
• Un búfer de paquetes de hasta 32 MB.
• Hasta 64000 x2 registros de NetFlow.

Su programabilidad permite incorporar nuevas tecnologías sin necesidad de implementar nuevo hardware y sin sacrificar performance.

 

Entre las mejoras que permiten está la implementación de SD-Access y programabilidad. Una muestra de su flexibilidad ha sido la incorporación de VXLAN sin necesidad de reemplazo de hardware con solamente una actualización del microcódigo. 

 

Estos circuitos (en algunos casos en su versión 1 o 1.1) están presentes en los switches Cisco Catalyst despachados desde 2013.

 

Tomado de: http://librosnetworking.blogspot.com/2020/06/cisco-uadp-asic-20.html

 

El comando "show ipv6 rip database"

Por Oscar Gerometta

Los comandos de monitoreo de protocolos de enrutamiento IPv6 son comandos específicos de cada protocolo. En el caso de RIPng el comando show ipv6 rip tiene una variantes específica de importancia que es show ipv6 rip database.

El comando en sí mismo fue introducido en IOS 10.0 y tuvo algunas modificaciones de consideración en IOS 12,2(15)T y IOS 15.1(2)S. La variante "database" fue introducida en IOS 12.2(3)T.
 
La adición del argumento "database" permite verificar la información correspondiente a las entradas de la tabla de rutas obtenidas por RIPng.

Un ejemplo de este comando en un dispositivo que implementa RIPng:

Router#show ipv6 rip one database
RIP process "one", local RIB
 2001:72D:1000::/64, metric 2
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:2000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:3000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
     Ethernet1/2001:DB8::1, expires in 120 secs
 2001:72D:4000::/64, metric 16, expired, [advertise 119/hold 0]
     Ethernet2/2001:DB8:0:ABCD::1
 3004::/64, metric 2 tag 2A, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs


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

Router#show ipv6 rip one database

• Pide la información almacenada en la base de datos que corresponde al proceso de RIPng etiquetado con el nombre "one".

RIP process "one", local RIB

• "RIP process"
  Indica el nombre del proceso de RIPng al que corresponde la información de enrutamiento que se muestra a continuación.

 2001:72D:1000::/64, metric 2

• "2002:72D:1000::/64"
  Prefijo IPv6 que identifica la red IPv6 de destino.
• "metric"
  Cantidad de saltos a travesar para alcanzar la red de destino.

     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs

• "Ethernet2"
  Interfaz a través de la cual la ruta ha sido aprendida.
• "2201:DB8:0:ABCD::1"
  Dirección IPv6 que corresponde al próximo salto a través del cual se alcanza la red destino.
• "expires in"
  Tiempo en segundos antes de que la ruta expire.

 2001:72D:2000::/64, metric 2, installed

• "installed"
  Ruta IPv6 que ha sido instalada en la tabla de enrutamiento IPv6 del dispositivo.

     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
 2001:72D:3000::/64, metric 2, installed
     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs
     Ethernet1/2001:DB8::1, expires in 120 secs
 2001:72D:4000::/64, metric 16, expired, [advertise 119/hold 0]

• "expired"
  La ruta está marcada como inaccesible (métrica = 16 saltos) por haber vencido el temporizador de espera.
• "advertise"
  En el caso de una ruta "expirada", período de tiempo en segundos durante el cual la ruta será anunciada como inalcanzable.
• "hold"
  Valor en segundos del temporizados de holddown que se le aplica a la ruta.

     Ethernet2/2001:DB8:0:ABCD::1
 3004::/64, metric 2 tag 2A, installed

• "tag"
  Etiqueta asociada a la ruta IPv6 que se muestra.

     Ethernet2/2001:DB8:0:ABCD::1, expires in 168 secs

Tomado de http://librosnetworking.blogspot.com/2018/07/comandos-show-ipv6-rip-database.html

Estado de la implementación de IPv6

Por Oscar Gerometta

Periódicamente vuelvo a encontrarme con diferentes publicaciones en las que se pone en dudas o se cuestiona la implementación de IPv6. Incluso algunas que siguen considerándola como una propuesta a futuro que podría o no darse.

Ya muchas veces he abordado el tema en este blog, incluso he publicado un manual con los conceptos básicos de IPv6. Pero evidentemente es necesario cada tanto volver sobre el tema.

La implementación de IPv6 no es una posibilidad, es una realidad que no podemos desconocer. Hay mucha información disponible sobre el tema.

La implementación al día de hoy

Como dije, IPv6 no es un proyecto a futuro sino una tecnología ya implementada cuya penetración es creciente cada día. Así lo muestra la información disponible.

Un ejemplo. Google publica en línea el porcentaje de tráfico de sus data centers que utiliza IPv6. Este es el reporte al día de hoy que, como podemos ver, muestra que el 21,09% del tráfico de los data centers de Google es tráfico IPv6 nativo:

Esta información está disponible en línea para quien quiera consultarla en este enlace.

Si lo que queremos es conocer la disponibilidad de conectividad IPv6 a nivel global, este mapa puede servir de primera aproximación:

Una mirada rápida nos permite verificar que el despliegue actual está centrado en América del Norte, Brasil, Europa, India, Japón, Australia y otros países asiáticos. El país con mayor nivel de adopción en este momento es Bélgica con el 62,59% de sus usuarios conectados utilizando IPv6.

Se puede acceder a la información detallada, país por país, desde este enlace.

¿Qué pasa en América Latina?

Como muestra el mapa global, si bien América Latina no se encuentra a la cabeza de la implementación global, tampoco está a la cola de la misma. En los últimos años varios países han disparado sus procesos de adopción

La vista regional del estado de adopción está volcada en este mapa en el que la intensidad del color verde indica un porcentaje creciente de usuarios conectados a IPv6.

Si consideramos el porcentaje de usuarios conectados con IPv6 un índice adecuado de evaluación del proceso, el líder en la región es entonces Uruguay con un 28,4% de sus usuarios conectados a la red IPv6.

Claro que por sus dimensiones, población y peso en la región no podemos ignorar a Brasil que se presenta con un 23,5% de sus usuarios conectados a IPv6.

Lo que es posible verificar de la observación de la información histórica de implementación en la región es que la misma se ha comenzado a desarrollar con mayor intensidad a partir del año 2015.

Esto es para empresas, ¿no para conexiones domiciliarias?

Este es otro prejuicio falso respecto a la implementación de IPv6. No hay un Internet corporativo y otro hogareño. Claro que todo depende de nuestro proveedor de acceso.
 
Pero como un ejemplo, yo estoy en este momento utilizando una conexión hogareño de cable módem, y estoy conectado utilizando IPv6:

Y no se trata solamente de recibir direccionamiento IPv6 global unicast, sino que también opero utilizando IPv6 como primer opción:

Si querés saber si estás verdaderamente operando en la red IPv6 hay varios sitios que permiten verificar esto. Uno de ellos es el sitio de verificación en línea dispuesto por Google:

También es posible utilizar servicios en línea con un análisis más detallados como el de IPv6 Test:

¿Qué debemos esperar a futuro?

A futuro debemos esperar un despliegue creciente de IPv6. Tanto en el ámbito corporativo como en el hogareño.

• Hace ya tiempo que se han agotado las direcciones IPv4 para seguir creciendo.
• El despliegue de IoE es una realidad que ya está instalada y sigue creciendo.
• El requerimiento de direccionamiento IP global es consecuentemente creciente.
• La respuesta para los requerimientos actuales de entonces IPv6.

Podemos discutir la velocidad con la que se realiza el despliegue, pero ya no es posible poner en dudas que se ha de hacer y que debemos ponernos en esta línea de trabajo.

Para quienes mayores precisiones sobre el crecimiento, hay un sitio que hace proyecciones para el despliegue de IPv6 a nivel global y por países. De acuerdo a vyncke.org el despliegue previsible para los próximos 2 años, a nivel global, es el siguiente:

Poner en dudas la implementación de IPv6 parece, entonces, un acto de ignorancia. La pregunta, creo, no es ya si IPv6 se implementará o no sino cuándo la implementaremos y si estamos listos para hacerlo.

Enlaces útiles:

• Estadísticas Google IPv6
• 6lab de Cisco
• Proyecciones de Vyncke.org
• Test IPv6 de Google
• IPv6 Test
• Bibliografía sugerida: Protocolo de Internet versión 6, v3.1
• Presentación: ¿Estás preparado para IPv6?

Tomado de: http://librosnetworking.blogspot.com/2018/03/estado-de-ipv6.html
       

Vulnerabilidad crítica en Cisco ASA y FTD permite ejecución remota de código y DoS

La vulnerabilidad se encuentra en la capa SSL de la funcionalidad VPN de ambos productos y ha recibido la puntuación máxima posible al considerarse crítica.

Cisco ha publicado el pasado día 29 un parche de seguridad para solucionar un fallo crítico en la capa SSL de la funcionalidad VPN de Cisco Adaptive Security Appliance (ASA) con identificador CVE-2018-0101. 

Cisco ha otorgado el CVSS máximo a esta vulnerabilidad y ha publicado la siguiente lista de productos afectados:

• 3000 Series Industrial Security Appliance (ISA)
• ASA 5500 Series Adaptive Security Appliances
• ASA 5500-X Series Next-Generation Firewalls
• ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
• ASA 1000V Cloud Firewall
• Adaptive Security Virtual Appliance (ASAv)
• Firepower 2100 Series Security Appliance
• Firepower 4110 Security Appliance
• Firepower 9300 ASA Security Module
• Firepower Threat Defense Software (FTD)

La vulnerabilidad es explotable cuando la funcionalidad webvpn se encuentra activa y una interfaz se encuentra como 'enabled' en la configuración. Al cumplirse las condiciones, un atacante puede aprovechar el fallo para enviar paquetes XML especialmente manipulados y provocar un intento de duplicar una región libre en memoria, lo que produce el error. Firepower Threat Defense (FTD) también es vulnerable al incluir éste ASA.

El error permite la ejecución remota de código en los productos afectados y el reinicio del dispositivo. La única solución, a parte de desactivar la funcionalidad, es aplicar el parche liberado. Las versiones vulnerables son las 8.x y 9.x de ASA, y las posteriores a 6.2.2 de FTD. Los usuarios de ASA 8.x deben actualizar al menos a la versión 9.1.7.20.

Juan José Oyague

Más información:

Cisco Adaptive Security Appliance Remote Code Execution and Denial of Service Vulnerability:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180129-asa1

CVE-2018-0101:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-0101

Tomado de: HISPASEC - http://unaaldia.hispasec.com/2018/02/vulnerabilidad-critica-en-cisco-asa-y.html