Con VPNs IPSEc, existen una gran cantidad de características para la configuración de políticas de seguridad; no sólo permitirá tráfico de tráfico de firewall, pero también permitirá paquetes del protocolo IPSec. Esta sección está diseñada para enseñarnos sobre los métodos específicos de políticas de seguridad para VPNs IPSec.
1 Escenarios VPN IKE/IPSec VPN
Como se muestra en la Figura 1-1, un túnel IPSec es establecido entre el host FW_A y el sub-host FW_B para que PC_A y PC_B pueda interactuar a través del túnel IPSec. Supongamos que FW_A y FW_B se conecta aun a red privada a través de la interfaz GE0/0/1; esta es la zona de confianza; cuando se conecta a Internet a través de la interfaz GE0/0/2, esta es la zona de desconfianza.
Figura 1-1 Red IKE/IPSec
El
El proceso de configuración de las políticas de seguridad es el siguiente:
1. Primero configure la política de seguridad de dominio más amplia para encargar IPSec. Configure el filtrado de paquetes por defecto del dominio FW_A para permitir:
[FW_A] firewall packet-filter default permit all
Configure el filtrado de paquetes por defecto del dominio FW_B para permitir:
[FW_A] firewall packet-filter default permit all
2. Una vez que el IPSec está configurado en los firewalls, PC_A iniciará el acceso a PC_B; analizando la tabla de sesiones del firewall, podemos obtener las condiciones de la política de seguridad.
l Tabla de sesión del host FW_A
[FW_A] display firewall session table verbose
Current Total Sessions: 3
udp VPN: public --> public
Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 00: 55
Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-e0-fc-e4-65-58
<--packets: 4 bytes: 692 -->packets: 6 bytes: 944
1.1.1.1: 500-->2.2.3.2: 500 //Corresponds to ISAKMP negotiation packet, port 500
icmp VPN: public --> public
Zone: trust--> untrust TTL: 00: 00: 20 Left: 00: 00: 16
Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-e0-fc-e4-65-58
<--packets: 0 bytes: 0 -->packets: 1 bytes: 60
192.168.0.2: 14235-->172.16.2.2: 2048 //Corresponds to original IP packets
esp VPN: public --> public
Zone: untrust--> local TTL: 00: 10: 00 Left: 00: 09: 59
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets: 0 bytes: 0 -->packets: 2 bytes: 224
2.2.3.2: 0-->1.1.1.1: 0 //Corresponds to IPSec packets. If AH and ESP encapsulation are both configured, there will be two sessions.
Hay un fenómeno extraño aquí; la dirección de sesión que corresponde al host FW_A enviando un paquete ESP es poco confiable --> local (2.2.3.2:0 ―> 1.1.1.0); en la tabla, parece haber una inconsistencia con la dirección de sesión cuando FW_A recibe paquetes ESP. ¿Por qué es eso? Resulta que cuando FW_A envía el paquete ESP encriptado, no establece una sesión y por lo tanto no pasa por el proceso de reenvío del firewall; naturalmente, tampoco comprobará la política de seguridad. Sin embargo, cuando el firewall recibe el paquete ESP para cifrado, primero debe establecer una sesión para el proceso de reenvío y verificar la política de seguridad; cómo podemos ver, esta sesión corresponde a un recibo de paquetes ESP. Si se envían o reciben paquetes de negociación ISAKMP, el proceso de reenvío debe realizarse ambas veces, por lo que este problema no se produce.
Al analizar la tabla de sesiones podemos obtener la ruta de paquetes FW_A, como se muestra en la Figura 1-2.
Figura 1-2 Ruta del paquete de FW_A
Como se puede ver en la figura anterior, FW_A debe configurar la política de seguridad de la zona confiableàzona no confiable para permitir que los paquetes de PC_A a PC_B pasen; también debe configurar la política de seguridad de la zona local àzona no confiable para permitir que los paquetes de negociación ISAKMP pasen; una política de seguridad de la zona no confiable àzona local debe ser configurada para permitir que los paquetes ESP pasen.
l Tabla de session de sub-host FW_B
[FW_B] display firewall session table verbose
Current Total Sessions: 3
udp VPN: public --> public
Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 00: 36
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets: 1 bytes: 200 -->packets: 2 bytes: 280
1.1.1.1: 500-->2.2.3.2: 500
esp VPN: public --> public
Zone: untrust--> local TTL: 00: 10: 00 Left: 00: 09: 59
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets: 0 bytes: 0 -->packets: 4 bytes: 448
1.1.1.1: 0-->2.2.3.2: 0
icmp VPN: public --> public
Zone: untrust--> trust TTL: 00: 00: 20 Left: 00: 00: 16
Interface: GigabitEthernet0/0/1 NextHop: 172.16.2.2 MAC: 54-89-98-39-60-e2
<--packets: 1 bytes: 60 -->packets: 1 bytes: 60
192.168.0.2: 61095-->172.16.2.2: 2048
Analizando la tabla de sesión, podemos obtener la ruta de paquetes de FW_B, como se muestra en la Figura 1-3.
Figura 1-3 Ruta de paquetes de sub-Host FW_B
Como se puede ver en la figura anterior, FW_B debe configurar la política de seguridad de la zona no confiable à zona confiable para permitir que los paquetes de PC_A a PC_B pasen; también se debe configurar la política de seguridad de la zona no confiable à zona local para permitir que los paquetes de negociación ISAKMP pasen; una política de seguridad de la zona no confiable à zona local debe ser configurada para permitir que los paquetes de ESP pasen.
Cuando PC_B inicia el acceso a PC_A, la ruta del paquete es la opuesta a la ruta del paquete de acceso de PC_B a PC_A, así que no es necesario discutirlo de nuevo.
Concluyendo, en el escenario IKE/IPSec, FW_A y FW_B deben configurar políticas de seguridad que coincidan, como se muestra en la Tabla 1-1.
Tabla 1-1 Políticas de seguridad de firewall coincidentes de host y Sub-host
Dirección de servicio | Dispositivo | Zona de seguridad origen | Zona de seguridad destino | Dirección IP Origen | Dirección IP Destino | Aplicaciones (Protocolo+Puerto Destino) |
PC_A accesa a PC_B | Host FW_A | No Confiable | Local | 2.2.3.2/32 | 1.1.1.1/32 | AH y/o ESP (ESP para este ejemplo) |
Local | No Confiable | 1.1.1.1/32 | 2.2.3.2/32 | UDP+500 | ||
Confiable | No Confiable | 192.168.0.0/24 | 172.16.2.0/24 | * | ||
Sub-Host FW_B | No Confiable | Local | 1.1.1.1/32 | 2.2.3.2/32 | AH y/o ESP (ESP para este ejemplo) UDP+500 | |
No Confiable | Confiable | 192.168.0.0/24 | 172.16.2.0/24 | * | ||
PC_B accesa a PC_A | Host FW_A | No Confiable | Local | 2.2.3.2/32 | 1.1.1.1/32 | AH y/o ESP (ESP para este ejemplo) UDP+500 |
No Confiable | Confiable | 172.16.2.0/24 | 192.168.0.0/24 | * | ||
Sub-Host FW_B | No Confiable | Local | 1.1.1.1/32 | 2.2.3.2/32 | AH y/o ESP (ESP para este ejemplo) | |
Local | No Confiable | 1.1.1.1/32 | 2.2.3.2/32 | UDP+500 | ||
Confiable | No Confiable | 172.16.2.0/24 | 192.168.0.0/24 | * | ||
*: Esto depende del tipo específico de servicio y puede ser configurado con base en la situación, por ejemplo tcp, udp, icmp, etc. | ||||||
Nota: Las VPN IPSec manuales difieren de las VPN IPSec de IKE, ya que no tienen una sesión ISAKMP y, por lo tanto, no es necesario configurar una política de seguridad UDP + 500.
4. Finalmente, cambie la acción de filtrado de paquetes predeterminada para denegar.
Configure el filtrado de paquetes por defecto del dominio FW_A para denegar:
[FW_A] firewall packet-filter default deny all
Configure el filtrado de paquetes por defecto del dominio FW_B para denegar: [FW_B] firewall packet-filter default deny all
2 Escenarios de rutas de IKE/IPSec VPN+NAT
Con rutas IKE/IPSec VPN+NAT, la configuración de políticas de seguridad tiene varias características únicas. Las presentaremos en el segundo escenario de "6.8.1 Descripción General de Escenarios de rutas NAT”.
Como se muestra en la Figura 1-4, un túnel IPSec ha sido establecido entre el host FW_A y el sub-host FW_B; hay un dispositivo NAT entre los dos; la dirección transformada post-NAT es 2.2.2.10 (una dirección del pool de direcciones). Supongamos que FW_A y FW_B se conectan a la red privada por medio de la interfaz GE0/0/1; esta es la zona confiable; el dispositivo upstream se conecta a través de la interfaz GE0/0/2; esta es la zona no confiable.
Figure 1-4 Redes de IKEv1/IPSec VPN+NAT
El proceso de configuración de políticas de seguridad es el siguiente:
1. Primero configure la política de seguridad de domino más amplia para encargar IPSec.
Configure el filtrado de paquetes de dominio por defecto de FW_A para permitir:
[FW_A] firewall packet-filter default permit all
Configure el filtrado de paquetes de dominio por defecto de FW_B para permitir:
[FW_A] firewall packet-filter default permit all
2. Una vez que IPSec se ha configurado en los firewalls, PC_B iniciara el acceso a PC_A; analizando la tabla de sesión del firewall, podemos obtener las políticas de seguridad coincidentes.
l Tabla de sesión del host FW_A
<FW_A> display firewall session table verbose
Current Total Sessions: 3
udp VPN: public --> public
Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 01: 52
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets: 1 bytes: 296 -->packets: 1 bytes: 296
2.2.2.10: 2052-->1.1.1.1: 500
udp VPN: public --> public
Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 01: 58
Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00
<--packets: 1 bytes: 228 -->packets: 5 bytes: 740
2.2.2.10: 2049-->1.1.1.1: 4500
icmp VPN: public --> public
Zone: untrust--> trust TTL: 00: 00: 20 Left: 00: 00: 14
Interface: GigabitEthernet0/0/2 NextHop: 192.168.0.2 MAC: 54-89-98-7f-1e-b2
<--packets: 1 bytes: 60 -->packets: 1 bytes: 60
172.16.1.2: 34201-->192.168.0.2: 2048
El host FW_A tiene un total de tres sesiones: Dos sesiones UDP y una sesión de ICMP. De las dos sesiones UDP, un puerto es 500, y uno es 4500; esto significa que después de que el IKE detectó el Gateway NAT, el paquete externo ISAKMP añadió encapsulación UDP, y el puerto de negociación también cambió de 500 a 4500. El paquete ESP posteriormente transferido también tiene un encabezado UDP agregado, por lo que FW_A no puede ver la sesión de paquetes ESP correspondiente.
Al analizar la tabla de sesiones, podemos obtener la ruta de paquetes FW_A del host, como se muestra en la Figura 1-5.
Figura 1-5 Ruta del paquete de Host FW_A
Como se puede ver en la figura anterior, el host FW_A debe configurar una politica de seguridad de la zona de confianza à zona confiable para permitir que PC_B acceda a PC_A; también debe configurar una política de seguridad de zona no confiable à zona local para permitir que el host FW_A y el sub-host FW_B establezcan el túnel IPSec.
l Tabla de session del sub-host firewall FW_B
<FW_B> display firewall session table verbose
Current Total Sessions: 3
udp VPN: public --> public
Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 01: 45
Interface: GigabitEthernet0/0/2 NextHop: 172.16.0.2 MAC: 00-00-00-d3-84-01
<--packets: 1 bytes: 296 -->packets: 1 bytes: 296
172.16.0.1: 500-->1.1.1.1: 500
udp VPN: public --> public
Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 01: 50
Interface: GigabitEthernet0/0/2 NextHop: 172.16.0.2 MAC: 00-00-00-d3-84-01
<--packets: 5 bytes: 708 -->packets: 1 bytes: 260
172.16.0.1: 4500-->1.1.1.1: 4500
icmp VPN: public --> public
Zone: trust--> untrust TTL: 00: 00: 20 Left: 00: 00: 07
Interface: GigabitEthernet0/0/2 NextHop: 10.1.5.1 MAC: 00-00-00-d3-84-01
<--packets: 1 bytes: 60 -->packets: 1 bytes: 60
172.16.1.2: 34201-->192.168.0.2: 2048
Al analizar la tabla de sesiones, podemos obtener la ruta de paquetes del sub-host FW_B, como se muestra en la Figura 1-6.
Figura 1-6 Ruta de paquetes del sub-Host FW_B
Como se puede ver en la figura anterior, el sub-host FW _ B debe configurar una política de seguridad de zona de confianza à zona no confiable para permitir que los paquetes de PC_B a PC_A pasen; también debe configurar una política de seguridad de zona local à zona no confiable para permitir que el host FW_A y el sub-host FW_B establezcan un túnel IPSec.
Si el dispositivo NAT sólo está configurado para NAT de origen, este escenario sólo permitirá al sub-host FW_B establecer un túnel IPSec con el host FW_A. Si este es el caso, las condiciones de coincidencia para las configuraciones de seguridad de FW_A y sub host son como se muestra en la Tabla 1-2.
Tabla 1-2 Políticas de seguridad de firewall coincidentes de host y sub-host
Dirección de servicio | Dispositivo | Zona de seguridad origen | Zona de seguridad destino | Dirección IP Origen | Dirección IP Destino | Aplicaciones (Protocolo+Puerto Destino) |
PC_B accede a PC_A | Host FW_A | No Confiable | Local | 172.16.0.1/32 | 1.1.1.1/32 | UDP+500 y 4500 |
No Confiable | Confiable | 172.16.1.0/24 | 192.168.0.0/24 | * | ||
Sub-Host FW_B | Local | No Confiable | 172.16.0.1/32 | 1.1.1.1/32 | UDP+500 y 4500 | |
Confiable | No Confiable | 172.16.1.0/24 | 192.168.0.0/24 | * | ||
*: Esto depende del tipo específico de servicio y puede ser configurado con base en la situación, por ejemplo tcp, udp, icmp, etc. | ||||||
Si el host no ha configurado una plantilla de política de IPSec y el servidor NAT está configurado en el dispositivo, host FW_A está permitido de activamente establecer un túnel IPSec con el sub-host FW_B; podemos resumir las condiciones coincidentes para esta política de seguridad de PC_A acceda a PC_B basándonos el método anterior.
7. Por último, cambie el filtrado de paquetes por defecto para denegar.
Configure el fitrlado de paquetes de dominio por defecto FW_A para denegar:
[FW_A] firewall packet-filter default deny all
Configure el fitrlado de paquetes de dominio por defecto FW_B para denegar:
[FW_B] firewall packet-filter default deny all
Preguntas del Dr. WoW:
1. Cuales dos métodos de encapsulamiento soporta IPSec?
2. De los dos protocolos de seguridad de IPSec AH y ESP, ¿cuál soporta cifrado?
3. Cuales dos métodos de autenticación soporta IKEv1?
4. Cuando se establece un IPSec SA, ¿cuáles son las diferencias entre IKEv1 e IKEv2 en términos del número de intercambio de mensajes enviados?
5. Si un dispositivo Gateway NAT está presente en la red en la cual un túnel IPSec está establecido entre dos firewalls, que se debe hacer en términos de los protocolos de seguridad AH y ESP?
6. Cuales dos métodos de detección de pares IKE soportan los firewalls?
7. En un escenario de GRE sobre IPSec, cuando IPSec define la ACL, debería utilizarse la dirección IP de origen y destino original o debería utilizarse la dirección IP de origen y destino encapsulada de GRE?
Para ver la lista de todas las publicaciones técnicas del Dr. WoW, haga clic en aquí
