Cisco Security: IKEv1 L2L IOS & ASA

Cisco Security: IKEv1 L2L IOS & ASA

Hola a todos una vez más, de tiempo que no paso por acá… y es que me he encontrado más que ocupado… Sin más y porque no recuerdo lo que iba a publicar la última vez, decidí realizar un post sobre VPN Site to Site teniendo en consideración ambos mundos tanto IOS como ASA, y aun así tener conexión a internet (muchos dicen que se confunden con los NAT… bue).

Con esto y sin más mostramos la topología con la que trabajaremos, en la cual se aprecia un Cisco ASA con versión 8.4 a la izquierda que tiene 2 redes, una publica y una privada, un Cisco Router con IOS 15.1 de igual forma con 2 redes y un Web Server que tiene la  IP publica ya conocida 8.8.8.8/32, entonces la idea es que ambas redes internas 192.168.1.0/24 y 172.16.15.0/24 se puedan comunicar a través de Internet, teniendo una conexión segura.

vpn-s2s-ios-asa

Ok, vamos a partir con el Cisco Router, el cual posee la configuración básica (IP, quad zero)

vpn1

Ya con eso vamos con la con la configuración del NAT, que la mayoría de ustedes ya deben de manejar al revés y al derecho (se peinan), un simple PAT

vpn2

 

Sigue leyendo

TCP Windows Size and Windows Sliding – TCP General Concepts


El término ventana en nuestro contexto, viene de la idea que si alineamos todos los segmentos que son enviados durante una sesión de comunicaciones en una larga fila, o cola de transmisión, pero dejamos solo una pequeña apertura a través de la cuál poder verlos, veríamos solo un subconjunto de ellos.

Ahora…

¿Qué es una “ventana de segmentos”?

Una ventana de segmentos es una colección de segmentos con sus números de secuencia que ya han sido enviados o que no han sido enviados pero son elegibles para enviarse mediante el emisor de la comunicación. Y en el caso de que hallan sido enviados no han sido completamente confirmados o no se ha recibido un ACK por ellos.

¿Qué es el tamaño de la ventana?

Es simplemente el número de segmentos, que podemos ver en esa “apertura” o “subconjunto”.

Vamos al ejemplo práctico, y para ello utilizaremos la siguiente figura de ejemplo para que quede todo más claro.

Image and video hosting by TinyPic


Tanto el emisor como el receptor de la comunicación, tienen bufferes o  porciones de memoria donde colocan los segmentos de la comunicación, que en nuestro caso serían las estructuras lineales o las colas de transmisión, y recepción donde están los segmentos que son enviados y recibidos en la sesión de comunicaciones.

En la imagen de ejemplo el emisor tiene su cola de transmisión con sus segmentos alineados, con los segmentos enumerados del 3 hasta el 7.

La ventana en esta imagen de ejemplo está compuesta por “el borde izquierdo de ventana” o “Left Windows Edge” que comieneza en el segmento 4 y “el borde derecho de ventana” o “Righ Windows Edge” que finaliza con el segmento 6.

El tamaño de la ventana es de 3, ya que comprende los siguientes segmentos: 4, 5, y 6.

Estos segmentos acabados de nombrar son elegibles para ser enviados o ya fueron enviados pero aún no se recibe un ACK para confirmar su entrega por parte del receptor.

Vemos además en la figura que el segmento número 3 ya ha sido enviado y confirmado, por lo tanto el emisor puede eliminar esa copia de la cola de transmisión para liberar sus recursos.

El segmento 7 está listo para ser enviado pero no puede ser enviado ni ser elegible para ser enviado porque no está en la “ventana actual” o “Current Window”.

A todo esto casi se nos olvida…

¿Qué es el concepto “Windows Sliding” o “ventana corrediza”?

Bien para comprender esto, supongamos que el emisor envío el segmento 4 y recibió un ACK por el segmento 4. Al momento en que se recibe el ACK por el segmento 4 la “ventana actual” que comprende los segmentos 4,5,6 se corre 1 segmento hacia la derecha en la cola de transmisión, con lo cual la “ventana actual” o “Current Window” pasa a estar conformada por los segmentos 5,6,7, con lo cuál el anterior segmento número 4 después de ser confirmado mediante el ACK puede ser quitado de la cola de transmisión, y el segmento número 7 pasar a ser elegible para la transmisión o inmediatamente ser transmitido.

Gracias a este mecanismo de “Windows Sliding” el emisor puede mantener el seguimiento en la cola de transmisión de cuáles segmentos pueden ser liberados o quitados, cuáles segmentos están esperando por un ACK, y cuáles segmentos no pueden ser enviados aún.

Además, en el receptor se mantiene el seguimiento en la cola de recepción de cuáles segmentos han sido recibidos y se ha enviado un ACK o confirmación por ellos, cuáles segmentos se espera recibir, y cuáles segmentos incluso si son recibidos no serán aceptados debido a los recursos limitados de memoria.

Un dato extra: los tamaños de ventana o “Window Size” no son iguales en el emisor o receptor, y por lo general deben ser ajustados los tamaños, de eso hablaremos en una futura entrada.

Espero que esta entrada les halla servido para aclarar conceptos que como digo son particularmente difíciles de entender, y espero en futuras entradas continuar profundizando en más detalles del protocolo TCP, si tienes alguna sugerencia de algún tema en particular de TCP no dudes en dejar un comentario abajo, sin más que añadir me despido.

Saludos!

TCP Connection Management – TCP Connection Establishment (Three-Way Handshake).

 

Continuando con la serie “TCP Connection Management”, hoy quiero hablar acerca del “saludo de tres vías” o “Three-Way Handshake”. Solo explicaremos en esta entrada, el establecimiento de una conexión bajo circunstancias normales no anómalas. Antes de comprender el “saludo de tres vías” es necesario entender un par de conceptos.

¿Qué es un segmento?

Un segmento no es nada más que el nombre de la PDU de capa de transporte. En nuestro caso será un encabezado TCP + Padding (bytes de relleno).

Vamos a describir algunos campos del encabezado TCP que importan a la discusión del “saludo de tres vías” o “Three-Way Handshake”.

Es recomendable tener un encabezado TCP a mano, para ir comparándolo con las explicaciones dadas acá. No lo coloco acá principalmente por razones de espacio. Pero buscando en google, o en el post anterior puedes localizarlo.

1. Source port: representa el puerto de origen, un número de 1 a 65535. Es de 16 bits de largo.
2. Destination port: representa el puerto de destino, un número de 1 a 65535. Es es de 16 bits de largo.
3.Secuence number: representa el número de secuencia de un segmento cualquiera, un número de 1 a 4.294.967.296. Es de 32 bits de largo.
4.Acknowledgment Number: representa el número de acuse de recibo del receptor, en base a un segmento enviado. Puede contener un número de 1 a 4.294.967.296 de largo. Tiene un largo de 32 bits este campo.
5. TCP FLAGs: Este campo tiene 8 bits, los cuales son “indicadores” o más formalmente llamados “flags”.

  • SYN: Es utilizado para iniciar una conexión TCP.
  • ACK: Es utilizado para dar “acuses de recibo o confirmar el recibo” al emisor de un segmento.

Nota: el cliente elige un puerto de origen de manera pseudo-aleatoria, que no esté ocupado.

 

Connection Set-up or establishment o “Three-Way Handshake”

El establecimiento de una conexión TCP, es para que dos hosts se pongan de acuerdo para conversar o transmitir datos entre ellos, y saber que la conexión, valga la redundancia está “comenzando”.Para establecer una conexión TCP, es necesario que ocurra un fenómeno llamado “Three-Way Handshake” o “saludo de 3 vías”,  donde los extremos se intercambian “tres mensajes”, o para ser más precisos “tres segmentos” según la terminología de TCP.

En los segmentos intercambiados, van los números de secuencia, los números de puertos, y opciones que servirán para la posterior transmisión de datos. Es importante tener en cuenta que solo son 3 segmentos los intercambiados en este proceso.

En términos generales el establecimiento de conexión o “Three-Way Handshake” es lo siguiente:
1. El cliente envía un segmento con el flag o indicador SYN activado.
2. El servidor responde un segmento con el flag o indicador SYN/ACK activado.
3. El cliente envía un segmento con el flag o indicador ACK activado.

 

Vamos a retomar parte de la imagen del post anterior, y explicar alguna terminología vista en la imágen y utilizada para esta discusión:

 

Three-Way Handshake

 

Sigue leyendo

TCP Connection Management – TCP General Concepts

 

En esta entrada vamos a ver un primer enfoque de TCP, sin profundizar mucho en detalles del protocolo, sólo una primera aproximación.

¿Qué es TCP – Transmission Control Protocol?

Según la RFC 1112, el protocolo de control de transmisión es el protocolo de transporte de circuito virtual primario de la pila de protocolos TCP/IP. TCP proporciona un servicio confiable, de entrega de datos en secuencia u orden, y un flujo de datos en ambas direcciones entre dos hosts. 

TCP es utilizado por aquellas aplicaciones que necesiten un servicio de transporte confiable, orientado a conexión como por ejemplo: el correo electrónico (SMTP), transferencia de archivos (FTP), servicios de terminal virtual (SSH), web (HTTP), etc.

Acá tenemos el encabezado TCP

TCP_Header

Sigue leyendo

Cisco IOS Security: VRF Aware IPSec

Cisco IOS Security: VRF Aware IPSec

Hola a todos!!  de forma atrasada pero cumpliendo les traigo este post de más VPN 😀 esta vez aplicada a VRF, entonces partamos con la primera pregunta que se deben estar haciendo.

¿WTF es una VRF?

Primero que todo VRF es el acrónimo de ‘Virtual Routing Forwarding’ entonces cuando pensamos en VRF,  pensemos en virtualización, una VRF es una instancia de ruteo dentro de un Router,  sería como tener varios mini-routers dentro del mismo equipo físico, por ende en un equipo físico podríamos tener la misma IP o el mismo segmento de red en diferentes interfaces o en la misma interface subdividida. Ahora porque sería necesario usar VRF? Imaginemos una ISP con varios clientes cada uno de ellos teniendo sus propias redes privadas y su propio protocolo de enrutamiento (EIGRP, OSPF, IS-IS, BGP), habría que pensar en poder separar cada uno de estos para que las tablas de rutas de los clientes no se ‘aplastaran’ entre ellas :D. Bien ya que tenemos la idea de que es una VRF y donde o cuando se puede usar pasemos a la parte de VPN  😀

En el siguiente escenario podemos observar 3 routers, 2 clientes y 1 proveedor, por el lado del proveedor crearemos las VRF para los 2 clientes y así poder separar el tráfico de cada uno de ellos. Luego pasaremos a encriptar las redes de ambos clientes en forma separada con IPSec.

VRF-aware-2

Routing Router Proveedor

Generamos las VRF con el simple comando ‘IP VRF <nombre-VRF>’

VRF-aware-3

La interface hacia la nube la dividimos y las encapsulamos con las VLAN 20 y 30 respectivamente (las vlan pueden cambiar es decisión de ustedes), asignando las VRF creadas y la primera IP disponible en el segmento mostrado, hay que tener en cuenta que primero se aplica la VRF y luego la IP, ya que si se realiza de forma inversa la IP será borrada 😀

VRF-aware-4

Creamos 2 loopbacks, asignamos una VRF para cada una de estas y asignamos las IP correspondientes, el resultado a continuación

VRF-aware-5

Ahora nos faltaría generar el enrutamiento para las VRF, para esto usaremos rutas estáticas solo para ver cómo se harían

VRF-aware-6

Con esto estaríamos listos por la parte de enrutamiento con las VRF por el lado del proveedor, los Router de cliente no van a usar VRF por ende con una configuración básica de interfaces y una ruta por defecto hacia el proveedor bastaría.

VRF-aware-7

VRF-aware-8

IPSEC Router

Configuramos el perfil de ISAKMP también conocido como fase 1 como también el perfil IPSec o de fase 2 en los 3 routers

VRF-aware-9

En el Router de proveedor generamos la ACL para hacer match del tráfico interesante el cual será encriptado, en este caso solo generaré una ACL para ser usada con ambos clientes.

VRF-aware-10

Para el cliente A la ACL no varía mucho ya que solo se debería cambiar la posición de las redes origen por destino y destino por origen;  las claves pre compartidas PSK, usaremos un nuevo comando que es  el keyring esto para hacer encajar las VRF con la PSK cisco

VRF-aware-12

Para las PSK de los clientes lo realizaremos de la forma tradicional

VRF-aware-13

Solo faltaría crear el crypto map y aplicarlo a las interfaces en los 3 routers

VRF-aware-14

VRF-aware-15

Realicemos las pruebas, con el siempre usado ping, en este caso debido a que usamos VRF al ping se le debe decir por cual VRF debe ser ejecutado

VRF-aware-16

Verifiquemos el estado de fase 1 y si nuestro tráfico se está encriptando bajo la VRF del cliente A

VRF-aware-19

VRF-aware-17

Success!!! , podemos ver que la VRF protegida es la VRF del cliente A, cuando se realiza una VPN S2S de la forma tradicional  este campo se presenta como ‘none’

Una ves más, con esto concluimos la parte de ‘Cisco IOS Security: VRF Aware IPSec‘, espero que  sido de su agrado  😎 , favor si les gusto o tienen preguntas al respecto no duden en consultar :mrgreen:

Estudio CCNP Route: Lab 2 – IPv6

Siguiendo con nuestra serie de laboratorios de estudio para CCNP Route, dejo a continuación el Lab 2 sobre IP versión 6. En este Lab podrán practicar direccionamiento IPv6, implementación de OSPF versión 3, implementación de EIGRP para versión 6 (Depende del IOS que utilicen), BGP-Multiprotocol para IPv6 y túneles automáticos 6to4.

topology

Descargar Lab: LAB_IPv6
Descargar Solución: Running-configs-solucion-Lab-IPv6

 

Estudio CCNP Route: Lab 1: EIGRP

Hoy he decidido comenzar a compartir material y ejercicios de laboratorios para practicar para el exámen de certificación 642-902 (CCNP Route). A continuación les dejo el Lab N°1 de esta serie que trata sobre EIGRP. Pronto subiré un video con la solución del ejercicio. Por ahora intenten resolverlo solos :) (está hecho bajo GNS3, el cual pueden descargar en http://www.gns3.net/download/ (el IOS no se los puedo pasar, pero una búsqueda rápida los ayudará).

En este ejercicio practicarán:

1.- Configuración básica de EIGRP
2.- Conectividad de EIGRP bajo entornos Frame Relay Hub and Spoke
3.- Sumarización manual
4.- Autenticación de EIGRP
5.- EIGRP stub
6. Administración de ancho de banda WAN de EIGRP.
7. Interfaces pasivas.

Descargar Lab: LAB_EIGRP

Solución: running-configs-solucion-LAB_EIGRP

Cisco IOS Security: GETVPN

Cisco IOS Security: GETVPN

Hace algunos días un ex compañero tenia algunas dudas sobre GETVPN una tecnología de VPN muy poco vista … y es por eso que a continuación veremos de que trata y como configurarlo.

GETVPN o Group Encrypted Transport VPN es una tecnología VPN túnel inferior o sea que no utiliza túneles la cual proporciona seguridad de extremo a extremo para el tráfico de red en un modo nativo y mantenimiento la inteligencia de la red como conexiones full-mesh, routing, QOS. GETVPN Utiliza la capacidad de la red de núcleo para poder enrutar y replicar los paquetes entre diferentes sitios dentro de la empresa. Por lo tanto, es en gran medida adecuado para una empresa que se encuentre corriendo sobre una MPLS. También es adecuado para encriptar tráfico multicast. Una implementación de  GETVPN tiene esencialmente tres componentes que son los siguientes:

  • Key Server (KS)
  • Group Member (GM)
  • Group Domain of Interpretation (GDOI)

Los GM realizan las tareas de encriptación y desencriptación del tráfico y el KS distribuye la llave de encriptación hacia todos los miembros del grupo. Debido a que todos los GM usan la misma llave, cualquier GM puede desencriptar el tráfico encriptado por otro GM. GDOI es un protocolo usado entre el KS y los GM.GDOI no depende de nadie más que de IKE o la fase1 para proteger la distribución de claves,, al igual que con las VPN IPSec tradicionales es posible utilizar métodos como claves pre compartidas o también PKI para la autenticación de IKE. GDOI implementa dos llaves de encriptación diferentes; Key Encryption key (KEK) es utilizada para asegurar el plano de control, mientras que la llave utilizada para la encriptación de datos es la Traffic Encryption Key (TEK).

Ahora a revisar la configuración con el siguiente escenario, en donde tenemos un KS con IP 10.0.1.2, dos GM (R1 y R2) y enrutamiento OSPF en toda la red. Los host poseen la IP 192.168.1.10 y 192.168.2.10 respectivamente.

getvpn-diag

Configuración del KEY Server

Configuración de la fase 1 o perfil de ISAKMP o IKEv1 con la clave pre compartida

ks1

Sigue leyendo

Vulnerabilidad de manipulación de LSAs encontrada en múltiples productos Cisco corriendo OSPF

Alert

Se ha encontrado una vulnerabilidad en algunas versiones de dispositivos Cisco que ejecutan OSPF que permitiría a un atacante no autenticado enviar paquetes LSAs de tipo 1 a una red y causar que algún router borre o modifique completamente la tabla de enrutamiento y tomar control completo de todo el sistema autónomo (AS) que ejecuta OSPF, permitiendo crear agujeros negros o interceptar tráfico de usuarios.

El atacante podría lanzar esta vulnerabilidad inyectando paquetes OSPF modificados. Un ataque exitoso puede causar el borrado completo de las rutas en el router vulnerable, así como también hacer que esos LSA de tipo 1 modificados se propaguen por todo el dominio del AS. Hasta ahora se ha determinado que solamente ciertos LSA1 son vulnerables solamente y no afectan a otros tipos de LSA.

Vale destacar que OSPFv3 no es vulnerable a este ataque ni tampoco FSPF (Fabric Shortest Path First).
Cisco ha lanzado actualizaciones de seguridad que solucionan este problema. Las versiones de IOS vulnerables y las soluciones al problema pueden encontrarlas acá:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130801-lsaospf

Video Clase Introducción a las listas de control de acceso

Encuesta

Síguenos

Lista de correos

Grupos de Google
Suscribirte a Redes Cisco.NET
Correo electrónico:
Consultar este grupo

Puedes ayudarnos!

Síguenos!

Subscribe via RSS

Sitios Recomendados