Configuración y funcionamiento de las políticas de filtros previos de FTD

Introducción

Este documento describe la configuración y el funcionamiento de las políticas de filtros previos de Firepower Threat Defence (FTD).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• ASA5506X que ejecuta el código FTD 6.1.0-195
• Dos routers Cisco IOS® 3925 que ejecutan 15.2 imágenes
• FireSIGHT Management Center (FMC) que ejecuta 6.1.0-195

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Una política de prefiltro es una función introducida en la versión 6.1 y tiene tres objetivos principales:

1. Hacer coincidir el tráfico basado en encabezados internos y externos.
2. Proporcione un control de acceso temprano que permite que un flujo omita por completo el motor Snort.
3. Trabaje como marcador de posición para las entradas de control de acceso (ACE) que se migran desde la herramienta de migración Adaptive Security Appliance (ASA).

Configurar

Caso práctico de directiva de prefiltro 1

Una política de prefiltro puede utilizar un tipo de regla de túnel que permite a FTD filtrar basándose en el tráfico tunelizado de encabezado IP interno y/o externo. En el momento en que se escribió este artículo, el tráfico tunelado se refiere a:

• IP en IP
• IPv6 en IP
• Puerto Teredo 3544
• Encapsulación de routing genérico (GRE)

Considere un túnel GRE como se muestra en la imagen:

Cuando hace ping de R1 a R2 con el uso de un túnel GRE, el tráfico pasa a través del firewall:

Si el firewall es un dispositivo ASA, verifica el encabezado IP del router:

ASA# show conn
GRE OUTSIDE 192.168.76.39:0 INSIDE  192.168.75.39:0, idle 0:00:17, bytes 520, flags

Si el firewall es un dispositivo FirePOWER, comprueba el encabezado IP interno:

Con la política de filtro previo, un dispositivo FTD puede hacer coincidir el tráfico basado en encabezados internos y externos.

Punto principal

Caso práctico de directiva de prefiltro 2

Una política de filtro previo puede utilizar un tipo de regla de filtro previo que puede proporcionar control de acceso temprano y permitir que un flujo omita por completo el motor Snort:

Tarea 1: Verificar política de prefiltro predeterminada

Tarea requerida

Verifique la política de filtro previo predeterminada.

Solución

1. Vaya a Políticas > Control de acceso > Prefiltro. En este ejemplo, ya existe una política de filtro previo predeterminada:

2. Seleccione Editar para ver la configuración de la política:

3. La política de filtro previo ya está adjunta a la política de control de acceso:

Verificación de CLI (LINA)

Las reglas de prefiltro se agregan sobre las ACL:

firepower# show access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list CSM_FW_ACL_; 5 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 3 advanced permit ipinip any any rule-id 9998 (hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 4 advanced permit 41 any any rule-id 9998 (hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 5 advanced permit gre any any rule-id 9998 (hitcnt=5) 0x52c7a066
access-list CSM_FW_ACL_ line 6 advanced permit udp any any eq 3544 rule-id 9998 (hitcnt=0) 0xcf6309bc

Tarea 2: Bloqueo del tráfico tunelizado con etiqueta

Tarea requerida

Bloquee el tráfico ICMP que se tuneliza dentro del túnel GRE.

Solución

1. Si aplica estos ACP, puede ver que el tráfico ICMP (Internet Control Message Protocol) está bloqueado, incluso si pasa a través del túnel GRE o no:

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

En este ejemplo, puede utilizar una directiva de filtro previo para cumplir los requisitos de la tarea. La lógica es la siguiente:

• Etiquetar todos los paquetes encapsulados dentro de GRE.
• Cree una política de control de acceso que coincida con los paquetes etiquetados y bloquee el ICMP. 

Desde el punto de vista de la arquitectura, los paquetes se comprueban con las reglas de prefiltro de LInux de forma nativa (LINA), a continuación, las reglas de prefiltro de Snort y ACP y, por último, Snort indica a LINA que descarte. El primer paquete pasa a través del dispositivo FTD.

1. Defina una etiqueta para el tráfico tunelado.

2. Navegue hasta Políticas > Control de Acceso > Prefiltro y cree una nueva Política de Prefiltro. Recuerde que no se puede editar la política de filtros previos predeterminada:

Dentro de la directiva de filtros previos, defina dos tipos de reglas:

• Regla de túnel
• Regla de filtro previo

Puede considerar estas dos funciones totalmente diferentes que se pueden configurar en una política de prefiltro. Para esta tarea, es necesario definir una regla de túnel:.

En esta tabla se definen las acciones con una breve descripción de cada una:

2. Defina la política de control de acceso para el tráfico etiquetado

• Aunque no es muy intuitivo al principio, la etiqueta de túnel puede ser utilizada por una regla de política de control de acceso como zona de origen. Navegue hasta Políticas > Control de acceso y cree una Regla que bloquee el ICMP para el tráfico etiquetado:

Nota: La nueva directiva de filtros previos se adjunta a la directiva de control de acceso.

Verificación

Habilite la captura en LINA y en CLISH:

firepower# show capture
capture CAPI type raw-data trace interface inside [Capturing - 152 bytes]
capture CAPO type raw-data trace interface outside [Capturing - 152 bytes]

> capture-traffic
Please choose domain to capture traffic from:
  0 - br1
  1 - Router

Selection? 1

Please specify tcpdump options desired.
(or enter '?' for a list of supported options)
Options: -n

Desde R1, intente hacer ping al extremo del túnel GRE remoto; el ping falla:

R1# ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

La captura CLISH muestra que la primera solicitud de eco pasó a través de FTD y la respuesta fue bloqueada:

Options: -n
18:21:07.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 0, length 80
18:21:07.759939 IP 192.168.76.39 > 192.168.75.39: GREv0, length 104: IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 65, seq 0, length 80
18:21:09.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 1, length 80
18:21:11.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 2, length 80
18:21:13.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 3, length 80
18:21:15.759939 IP 192.168.75.39 > 192.168.76.39: GREv0, length 104: IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 65, seq 4, length 80

La captura LINA confirma lo siguiente:

> show capture CAPI | include ip-proto-47
 102: 18:21:07.767523  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 107: 18:21:09.763739  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 111: 18:21:11.763769  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 115: 18:21:13.763784  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
 120: 18:21:15.763830  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
>
> show capture CAPO | include ip-proto-47
  93: 18:21:07.768133  192.168.75.39 > 192.168.76.39:  ip-proto-47, length 104
  94: 18:21:07.768438  192.168.76.39 > 192.168.75.39:  ip-proto-47, length 104

Habilite CLISH firewall-engine-debug, borre los contadores de caídas de LINA ASP y complete la misma prueba. La depuración CLISH muestra que para la solicitud de eco coincidió con la regla de prefiltro y para la regla de respuesta de eco la regla ACP:

10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 New session
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 8, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 pending rule order 3, 'Block ICMP', AppId
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 uses prefilter rule 268434441 with tunnel zone 1
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 Starting with minimum 0, id 0 and SrcZone first with zones 1 -> -1, geo 0 -> 0, vlan 0, sgt tag: 65535, svc 3501, payload 0, client 2000003501, misc 0, user 9999997, icmpType 0, icmpCode 0
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 match rule order 3, 'Block ICMP', action Block
10.0.0.1-8 > 10.0.0.2-0 1 AS 1 I 0 deny action

El descarte de ASP muestra que Snort descartó los paquetes:

> show asp drop

Frame drop:
  No route to host (no-route)                                     366
  Reverse-path verify failed (rpf-violated)                         2
  Flow is denied by configured rule (acl-drop)                      2
  Snort requested to drop the frame (snort-drop)                    5

En los Eventos de conexión, puede ver la Política de filtro previo y la Regla que coincidió:

Tarea 3: Omitir motor Snort con reglas de filtro previo de ruta rápida

Diagrama de la red

Tarea requerida

1. Quite las reglas actuales de la directiva de control de acceso y agregue una regla de directiva de control de acceso que bloquee todo el tráfico.
2. Configure una regla de directiva de filtro previo que omita el motor Snort para el tráfico originado en la red 192.168.75.0/24.

Solución

1. Política de control de acceso que bloquea todo el tráfico:

2. Agregue una regla de filtro previo con ruta rápida como acción para la red de origen 192.168.75.0/24:

3. El resultado se muestra en la siguiente imagen:

4. Guardar e implementar.

Habilite la captura con seguimiento en ambas interfaces FTD:

firepower# capture CAPI int inside trace match icmp any any
firepower# capture CAPO int outsid trace match icmp any any

Intente hacer ping desde R1 (192.168.75.39) a R2 (192.168.76.39) a través del FTD; falla el ping:

R1# ping 192.168.76.39
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.76.39, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

La captura en la interfaz interior muestra:

firepower# show capture CAPI

5 packets captured

   1: 23:35:07.281738   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:09.278641   192.168.75.39 > 192.168.76.39: icmp: echo request
   3: 23:35:11.279251   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:13.278778   192.168.75.39 > 192.168.76.39: icmp: echo request
   5: 23:35:15.279282   192.168.75.39 > 192.168.76.39: icmp: echo request
5 packets shown

El seguimiento del primer paquete (petición de eco) muestra (puntos importantes resaltados):

La captura en la interfaz externa muestra:

firepower# show capture CAPO

10 packets captured

   1: 23:35:07.282044   192.168.75.39 > 192.168.76.39: icmp: echo request
   2: 23:35:07.282227   192.168.76.39 > 192.168.75.39: icmp: echo reply
   3: 23:35:09.278717   192.168.75.39 > 192.168.76.39: icmp: echo request
   4: 23:35:09.278962   192.168.76.39 > 192.168.75.39: icmp: echo reply
   5: 23:35:11.279343   192.168.75.39 > 192.168.76.39: icmp: echo request
   6: 23:35:11.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
   7: 23:35:13.278870   192.168.75.39 > 192.168.76.39: icmp: echo request
   8: 23:35:13.279023   192.168.76.39 > 192.168.75.39: icmp: echo reply
   9: 23:35:15.279373   192.168.75.39 > 192.168.76.39: icmp: echo request
  10: 23:35:15.279541   192.168.76.39 > 192.168.75.39: icmp: echo reply
10 packets shown

El seguimiento del paquete de retorno muestra que coincide con el flujo actual (52), pero está bloqueado por la ACL:

firepower# show capture CAPO packet-number 2 trace

10 packets captured

   2: 23:35:07.282227       192.168.76.39 > 192.168.75.39: icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 52, uses current flow

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny ip any any rule-id 268434432 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: ACP_5506-1 - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

5. Añadir una regla de prefiltro más para el tráfico de retorno, la siguiente imagen muestra el resultado

A continuación, realice un seguimiento del paquete de retorno que aparece (puntos importantes resaltados):

Verificación

Utilice esta sección para confirmar que su configuración funciona correctamente. La verificación se ha explicado en las secciones de tareas respectivas.

Troubleshoot

Actualmente, no hay información específica disponible sobre cómo solucionar los problemas de esta configuración.

Información Relacionada

• Todas las versiones de la guía de configuración de Cisco Firepower Management Center se pueden encontrar en Navegación por la documentación de Cisco Secure Firewall Threat Defence

• Cisco Global Technical Assistance Center (TAC) recomienda encarecidamente esta guía visual para obtener un conocimiento práctico en profundidad de las tecnologías de seguridad de última generación de Cisco Firepower, que incluye las mencionadas en este artículo en Cisco Firepower Threat Defence (FTD)

• Para ver todas las notas técnicas sobre configuración y resolución de problemas, consulte Cisco Secure Firewall Management Center

• Soporte Técnico y Documentación - Cisco Systems