Mostrando entradas con la etiqueta VPN. Mostrar todas las entradas
Mostrando entradas con la etiqueta VPN. Mostrar todas las entradas

martes, 26 de agosto de 2025

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



domingo, 12 de abril de 2020

La importancia de la seguridad digital en tiempos de COVID-19


Estamos experimentando cambios radicales en nuestras rutinas en las últimas semanas debido al avance de la pandemia COVID-19. 

De la noche a la mañana, millones de personas comenzaron a trabajar desde sus hogares, sin acceso a sus oficinas, para mitigar el avance del virus. Es un esfuerzo colectivo que exige mucho de todos nosotros, y que también hace hincapié en nuestras estructuras de ciberseguridad de formas nunca antes vistas.

Durante años hemos visto una adopción gradual del trabajo a distancia por parte de empresas y empleados, pero con diferentes velocidades y prioridades de adaptación. No era raro ver que las adaptaciones al sistema de seguridad eran el último paso dado por las empresas y, lamentablemente, esta semana lo percibimos claramente. 

CIOs, técnicos y gestores de TI han pasado los últimos días esforzándose por adaptar sus redes y herramientas para que sus empleados puedan trabajar de forma remota, manteniendo la seguridad de los datos corporativos, y con esta prisa, se está dejando fuera un cuidado importante.

Cuando planificamos una estructura de trabajo remota eficiente y segura en una empresa, estamos hablando de tres fases.
 
La primera consiste en la adopción de una VPN y herramientas de comunicación para el trabajo remoto. La segunda es la migración total de datos y herramientas de seguridad a la nube. Y la tercera son los procesos de autenticación de empleados remotos. 

Lo que hemos visto es que muchas empresas se preocupan sólo por la primera fase y consideran sólo soluciones VPN para garantizar la seguridad del acceso remoto, y esto crea problemas.

VPN, en la práctica, es un túnel que conecta al usuario a la red de datos de una empresa. Una vez dentro de este túnel, el usuario tiene acceso a todo. Y si este acceso no está bien controlado, abre el camino para el fraude y la fuga de datos, especialmente en momentos como este donde todos los empleados trabajan de forma remota. Y aquí tenemos que ser claros: no todos los empleados necesitan acceso a VPN.



Es esencial que los administradores y los administradores de red trabajen en dos frentes, tanto en la VPN como en la nube. Es lo que llamamos <Split tunneling>. Mientras que VPN da acceso a todos los datos de la empresa, incluido el acceso más sensible, un acceso controlado a la nube permite que un empleado debidamente autenticado acceda solo a los datos necesarios y herramientas de colaboración, todas almacenadas correctamente en la nube. Es decir, la segunda fase, la migración del total de servicios y datos a la nube, debe completarse satisfactoriamente. La tercera fase, la autenticación de usuarios, también debe ponerse en práctica rápidamente.

Con el distanciamiento social recomendado por la Organización Mundial de la Salud, estamos compartiendo nuestro tiempo en casa y, a menudo, nuestras computadoras, con miembros de nuestras familias. 

De ahí la necesidad de crear herramientas de autenticación seguras, asegurando así la integridad de la información. Las soluciones como la doble autenticación de Log in ya eran esenciales, y ahora se vuelven más que obligatorias.

No puedes negar que estamos pasando por un momento único que nadie ha predicho. Y su excepcionalidad nos obliga a muchos de nosotros a acelerar la adopción de prácticas y medidas de seguridad que se estaban previendo a largo plazo. 

Pero es importante tener en cuenta que todavía puede perseguir y «no moverse» no es una opción. En tiempos como estos, los riesgos de seguridad se hacen mayores, pero también existe la oportunidad de crear una estructura de legado para que, al final de las dificultades, tengamos empresas y estructuras adecuadamente preparadas para el futuro de la “oficina en cualquier lugar”.

Vea más detalles sobre las soluciones gratuitas que Cisco ha puesto a su disposición en respuesta a la situación actual causada por COVID-19. Acceda a la Guía fácil, aquí.


Escrito por:

martes, 6 de diciembre de 2016

Cómo Configurar VPN IPSec Site-to-Site en Cisco Router



En el artículo de hoy vamos a explicar cómo configurar una VPN (Virtual Private Network) Site To Site en Cisco IOS.

Primeramente, ¿qué es un VPN


Una VPN es una conexión virtual entre dos dispositivos que permite el envío de información de manera segura a través de un medio inseguro como lo es Internet

Con una VPN podemos desarrollar toda una infraestructura de red WAN (Wide Area Network) de forma más rápida y económica en comparación con la contratación del servicio de línea de fijas Frame Relay, ATM u otro tipo de tecnologías.

Nuestra configuración de VPN Site to Site es realizada utilizando el protocolo IPSec (Internet Protocol Security).  


IPSec es un protocolo de capa 3 del modelo OSI que permite desarrollar VPNs brindando las siguientes ventajas:
  • Confidentiality
  • Data integrity
  • Authentication
 
Confidentiality (confidencialidad) significa que la información enviada a través del VPN no podrá ser leída por un usuario o dispositivo tercero que no participe en la comunicación. En otras palabras, la información enviada por la VPN no podrá se accedida por ninguna entidad no autorizada. La confidencialidad se logra en la práctica a través de la implementación de técnicas de cifrado de datos. Para los no entendidos en la materia, el cifrado de información logra convertir un texto original en un formato no entendible (texto cifrado) para todo aquel que no conozca: (1) el algoritmo de cifrado y (2) la llave secreta. En IPSec podemos implementar cifrado de datos utilizando algoritmos simétricos tales como 3DES y AES.

Data integrity (Integridad de la información) significa que la información enviada entre dos dispositivos en una VPN debe de llegar tal cual fue enviada por el dispositivo emisor. En otras palabras, IPSec garantiza que la información, mientras esté en tránsito, no será modificada nivalterada. La integridad de la información en la práctica se logra a través de la implementación de técnicas de Hashing. Un Hash es una función matemática que no tiene inversa, por lo tanto, va partir del resultado no es posible —matemáticamente hablando — conseguir la información original. En IPSec podemos implementar Hashing utilizando algoritmos tales como MD5, SHA-1 y SHA-2.

Authentication (Autenticación) consiste en establecer mecanismos de seguridad para validar la identidad de los dispositivos envueltos en la transmisión de información a través de una VPN. En IPSec tenemos la opción utilizar diferentes mecanismos de autenticación como son: (1) Pre-share Key y (2) Digital Signature.

En la práctica, la implementación de IPSec como protocolo de VPN no es muy user-friendly. Requiere a priori un entendimiento muy detallado por parte del ingeniero de la intríngulis técnica de este protocolo que, de por sí, es complejo.

Una VPN IPSec requiere del establecimiento de dos túneles. El primero llamado IKE Phase 1 (Internet Key Exchange Fase 1) que es utilizado para que los routers se comuniquen directamente entre ellos. Este túnel no es utilizado para el envío de paquetes IP de los usuarios, sino más bien, para el intercambio información de control. Para que el túnel IKE Phase 1 pueda establecerse con éxito, ambos routers deben de estar de acuerdo en las siguientes variables:
  • Hash algorithm
  • Encryption algorithm
  • Diffie-Hellman DH group
  • Authentication method
  • Lifetime
 Después que ambos routers agotan con éxito la primera fase del IPSecIKE Phase 1 —, sí y solo sí se establece la segunda fase — IKE Phase 2 — donde se establece el túnel por donde viaja la información de los usuarios de manera encriptada.



Entonces teniendo como trasfondo la información anterior, vamos a explicar cómo podemos configurar una VPN Site to Site entre dos routers Cisco utilizando IPSec

 Para hacer el proceso de configuración un poco más fácil de entender, vamos a dividir el proceso de configuración en dos etapas: (1) ISAKMP 1; (2) ISAKMP 2 tanto para R1 como para R2. A los túneles IKE también se les llama ISAKMP.



Vamos a comenzar con la configuración de R1.

IKE ISAKMP Phase 1


Paso 1: configuración de ISAKMP Policy.


R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encr 3des
R1(config-isakmp)#hash md5
R1(config-isakmp)#authentication pre-share
R1(config-isakmp)#group 2
R1(config-isakmp)#lifetime 86400

Paso 2: definir la contraseña a utilizar entre los R1 y R2 como pre-share key.


R1(config)#crypto isakmp key cisco address 1.1.1.2

Paso 3: configuración de ACL


R1(config)# ip Access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

IKE ISAKMP Phase 2

Paso 4: configurando IPSec Transform


R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

Paso 5: configuración de CRYPTO MAP


R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)#set peer 1.1.1.2
R1(config-crypto-map)#set transform-set TS
R1(config-crypto-map)#match address VPN-TRAFFIC

Paso 6: aplicando Crypto MAP a una interface pública


R1(config)# interface Fastethernet 0/1
R1(config-if)#crypto map CMAP

El mismo procedimiento de configuración que aplicamos a R1 lo hacemos en R2 con ciertas modificaciones en cuanto a las direcciones IP.

Vamos a comenzar con la configuración de R2.

IKE ISAKMP Phase 1


Paso 1: configuración de ISAKMP Policy.


R2(config)#crypto isakmp policy 1
R2(config-isakmp)#encr 3des
R2(config-isakmp)#hash md5
R2(config-isakmp)#authentication pre-share
R2(config-isakmp)#group 2
R2(config-isakmp)#lifetime 86400

Paso 2: definir la contraseña a utilizer entre los R1 y R2 como pre-share key.


R2(config)#crypto isakmp key cisco address 1.1.1.1

Paso 3: configuración de ACL


R2(config)# ip Access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255

IKE ISAKMP Phase 2


Paso 4: configurando IPSec Transform

R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac

Paso 5: configuración de CRYPTO MAP

R2(config)# crypto map CMAP 10 ipsec-isakmp
R2(config-crypto-map)#set peer 1.1.1.1
R2(config-crypto-map)#set transform-set TS
R2(config-crypto-map)#match address VPN-TRAFFIC

Paso 6: aplicando Crypto MAP a una interface pública


R2(config)# interface Fastethernet 0/1
R2(config-if)#crypto map CMAP

Al aplicar esta configuración en R1 y R2 una VPN IPSec debe de funcionar perfectamente. Para comprobar que los paquetes IP provenientes de ambas redes LAN se envían a través del VPN debemos de ejecutar los siguientes comandos.

R1#ping 20.20.20.1 source FastEthernet 0/0
R1#show crypto session

Ahora en R2:

R2#ping 10.10.10.1 source FastEthernet 0/0
R2#show crypto session



Tomado de: http://blog.capacityacademy.com/2014/09/12/ccna-security-como-configurar-vpn-ipsec-site-to-site-en-cisco-router/

lunes, 14 de marzo de 2016

¿Que es MPLS? (Multiprotocol Label Switching)



El Multiprotocol Label Switching (MPLS) es un protocolo para acelerar y organizar los flujos de tráfico en la red.

MPLS permite que la mayoría de los paquetes sean conmutados a nivel de Capa 2 (la capa de conmutación o Switching) en lugar de hacerlo teniendo que usar mecanismos de la Capa 3 (la capa de enrutamiento o routing).


Cada paquete es etiquetado en la entrada a la red del Service Provider en el router "Ingress". Todos los siguientes routers o switches router realizan la conmutación de los paquetes basándose solamente en esas etiquetas (sin mirar el encabezado IP). Finalmente el router "Egress" remueve la etiqueta y reenvía el paquete hacia su destino final.


La etiqueta determina cual es el camino predeterminado que el paquete va a seguir. Los caminos, o rutas, se llaman LSPs (label-switched paths), los cuales permiten al Service Provider prever cual va a ser el mejor camino para que ciertos tipos de tráfico fluyan a través de una red privada o pública.

Los proveedores de servicio pueden usar MPLS para mejorar la calidad de servicio (QoS) definiendo LSPs que pueden garantizar niveles específicos acordados (SLAs) de latencia, jitter, pérdida de paquetes y tiempo de no disponibilidad.



Por ejemplo, una red puede tener tres niveles de servicio -- un nivel para voz, otro nivel para tráfico sensible al tiempo y otro nivel para tráfico de "máximo esfuerzo".

MPLS también soporta separación de tráfico y la creación de VPNs (Virtual Private Networks), VPLS (Virtual Private LAN Services) y VLLs (Virtual Leased Lines).



MPLS recibe su nombre debido a que puede trabajar con los protocolos IP, ATM y Frame Relay. Cualquiera de estos protocolos puede ser usados para crear un LSP. MPLS fué creada a fines de los años 90s para evitar que existan algunos routers perdiendo valiosa cantidad de tiempo teniendo que examinar las tablas de enrutamiento.


Muchas personas pensaban que MPLS podía ser usado únicamente en redes privadas, pero el protocolo puede ser usado en todas las redes de los Service Provider, incluyendo los Backbones de Internet. Hoy en día, el GMPLS (Generalized Multi-Protocol Label Switching) extiende el MPLS para poder manejar TDM (Time Division Multiplexing), lambda switching y otras clases de tecnologías de Switching.

------------------------------------------------

Tomado de: http://searchenterprisewan.techtarget.com/definition/Multiprotocol-Label-Switching - Posteado por Margaret Rouse

jueves, 25 de agosto de 2011

La familia de firewalls Cisco ASA 5500

Dentro de la familia de productos ofrecida por Cisco en la actualidad el appliance para seguridad (firewall) es el popularmente conocido como ASA (Adaptive Security Appliances). La familia de productos es realmente amplia, por lo que me pareció conveniente hacer una rápida síntesis de los modelos actualmente disponibles. Por supuesto que la información detallada se puede encontrar en el sitio de Cisco, utilizando los enlaces que recojo al final del post.


Cisco ASA 5505
  • Entorno sugerido: Pequeñas oficinas o sucursales, trabajadores remotos.
  • Throughput máximo: 150 Mbps
  • Cantidad máxima de conexiones por segundo: 4.000
  • Paquetes (de 64 bytes) por segundo: 85.000
  • Cantidad máxima de peers para VPNs IPSec: 10
  • Cantidad máxima de sesiones de clientes SSL: 25
Cisco ASA 5510
  • Entorno sugerido: Borde de acceso a Internet
  • Throughput máximo: 300 Mbps.
  • Cantidad máxima de conexiones por segundo: 9.000
  • Paquetes (de 64 bytes) por segundo: 190.000
  • Cantidad máxima de peers para VPNs IPSec: 250
  • Cantidad máxima de sesiones de clientes SSL: 250
Cisco ASA 5520
  • Entorno sugerido: Borde de acceso a Internet
  • Throughput máximo: 450 Mbps.
  • Cantidad máxima de conexiones por segundo: 12.000
  • Paquetes (de 64 bytes) por segundo: 230.000
  • Cantidad máxima de peers para VPNs IPSec: 750
  • Cantidad máxima de sesiones de clientes SSL: 750
Cisco ASA 5540
  • Entorno sugerido: Borde de acceso a Internet
  • Throughput máximo: 650 Mbps.
  • Cantidad máxima de conexiones por segundo: 25.000
  • Paquetes (de 64 bytes) por segundo: 500.000
  • Cantidad máxima de peers para VPNs IPSec: 5.000
  • Cantidad máxima de sesiones de clientes SSL: 2.500
Cisco ASA 5550
  • Entorno sugerido: Borde de acceso a Internet, red de campus
  • Throughput máximo: 1,2 Gbps.
  • Cantidad máxima de conexiones por segundo: 36.000
  • Paquetes (de 64 bytes) por segundo: 600.000
  • Cantidad máxima de peers para VPNs IPSec: 5.000
  • Cantidad máxima de sesiones de clientes SSL: 5.000
Cisco ASA 5580-20
  • Entorno sugerido: Data center, campus
  • Throughput máximo: 10 Gbps.
  • Cantidad máxima de conexiones por segundo: 90.000
  • Paquetes (de 64 bytes) por segundo: 2.500.000
  • Cantidad máxima de peers para VPNs IPSec: 10.000
  • Cantidad máxima de sesiones de clientes SSL: 10.000
  • End-of-Sale anunciado: 31 de julio de 2012
Cisco ASA 5580-40
  • Entorno sugerido: Data center, campus
  • Throughput máximo: 20 Gbps.
  • Cantidad máxima de conexiones por segundo: 150.000
  • Paquetes (de 64 bytes) por segundo: 4.000.000
  • Cantidad máxima de peers para VPNs IPSec: 10.000
  • Cantidad máxima de sesiones de clientes SSL: 10.000
  • End-of-Sale anunciado: 31 de julio de 2012
Cisco ASA 5585-X con SSP-10
  • Entorno sugerido: Borde de acceso a Internet, campus.
  • Throughput máximo: 4 Gbps.
  • Cantidad máxima de conexiones por segundo: 50.000
  • Paquetes (de 64 bytes) por segundo: 1.500.000
  • Cantidad máxima de peers para VPNs IPSec: 5.000
  • Cantidad máxima de sesiones de clientes SSL: 5.000
Cisco ASA 5585-X con SSP-20
  • Entorno sugerido: Data center, campus
  • Throughput máximo: 10 Gbps.
  • Cantidad máxima de conexiones por segundo: 125.000
  • Paquetes (de 64 bytes) por segundo: 3.000.000
  • Cantidad máxima de peers para VPNs IPSec: 10.000
  • Cantidad máxima de sesiones de clientes SSL: 10.000
Cisco ASA 5585-X con SSP-40
  • Entorno sugerido: Data Center, campus
  • Throughput máximo: 20 Gbps.
  • Cantidad máxima de conexiones por segundo: 200.000
  • Paquetes (de 64 bytes) por segundo: 5.000.000
  • Cantidad máxima de peers para VPNs IPSec: 10.000
  • Cantidad máxima de sesiones de clientes SSL: 10.000
Cisco ASA 5585-X con SSP-60
  • Entorno sugerido: Data center, campus
  • Throughput máximo: 40 Gbps.
  • Cantidad máxima de conexiones por segundo: 350.000
  • Paquetes (de 64 bytes) por segundo: 9.000.000
  • Cantidad máxima de peers para VPNs IPSec: 10.000
  • Cantidad máxima de sesiones de clientes SSL: 10.000
Enlaces sugeridos

Cualquier comentario o consulta que consideres importante respecto a este tema,
 incorporalo a continuación en forma de comentario.
Muchas gracias.
Oscar Gerometta

miércoles, 24 de agosto de 2011

El cifrado AES, ¿está roto o no?

Un equipo de investigadores ha encontrado la primera vulnerabilidad en el estándar de cifrado AES reduciendo la longitud efectiva de la clave en 2 bits. Esto implica que las longitudes habituales de 128, 192 y 256 bits se han visto reducidas a 126, 190 y 254 bits. ¿Significa que está roto?

AES (Advanced Encryption Standard) es en realidad el algoritmo Rijndael, que pasó a ser un estándar de cifrado aprobado por el gobierno de los Estados Unidos en 2003 para cifrar información clasificada. En su versión de 128 bits está permitido para información "Secreta" mientras que para información "Top Secret" requiere claves de 192 o 256 bits. De hecho, fue el primero algoritmo público usado para cifrar información "Top Secret" gubernamental.

Andrey Bodgdanov de la universidad católica de Leuven, Christian Rechberger del ENS de París y Dmitry Khovratovich del departamento de investigación de Microsoft ya apuntan que el ataque no tiene una gran relevancia práctica. Aunque el descubrimiento es considerado un avance importante en la investigación de la seguridad del algoritmo AES, puesto que la experiencia dice que en ciertos algoritmos, se avanza "despacio" hasta romperlo. Esta vulnerabilidad ha sido confirmada por los desarrolladores de AES, Joan Daemen y Vincent Rijmen.

Los investigadores emplearon un ataque Meet-in-the-Middle, una aproximación que ha sido principalmente empleada con algoritmos de hashing, combinándolo con un ataque "Biclique". Este método ha permitido a los investigadores calcular la clave de un par texto plano/texto cifrado más rápidamente que empleando un ataque de fuerza bruta en el espacio total de la llave. O sea, se ha reducido el número de claves que deben ser probadas. La fuerza bruta total con clave de 128 bits serían 2^128 posibilidades. Con este ataque serían necesarias "solo" 2^126.

En el sentido estrictamente académico, en algoritmo está "roto" puesto que se ha reducido (aunque sea en 2 bits) el espacio de claves necesario para calcular la clave por fuerza bruta. Sin embargo, "roto" no significa que no pueda ser usado con seguridad todavía. Por ejemplo, un ataque contra una llave de 128 bits requiere diez millones de años empleando un parque de un billón de equipos probando cada uno de ellos un billón de claves. Al reducir en dos bits dicha clave, el tiempo se reduciría a 3 millones de años.

Hasta 2005, el único ataque que se conocía contra AES contemplaba una reducción del número de rondas de cifrado, o sea, una modificación en su implementación "artificial" que no suele encontrarse habitualmente. Los detalles del ataque fueron presentados en la conferencia CRYPTO 2011 y pueden ser descargados desde la web de investigación de Microsoft.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/4687/comentar

Más Información:

Biclique cryptanalysis of the full AES
https://research.microsoft.com/en-us/projects/cryptanalysis/aes.aspx

Borja Luaces
bluaces@hispasec.com

Sergio de los Santos
ssantos@hispasec.com
Twitter: @ssantosv

Tomado de: http://www.hispasec.com/unaaldia/4687