Configuração e operação das políticas de pré-filtro do FTD

Introduction

Este documento descreve a configuração e a operação das políticas de pré-filtro do Firepower Threat Defense (FTD).

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• ASA5506X que executa o código FTD 6.1.0-195
• FireSIGHT Management Center (FMC) com 6.1.0-195
• Dois 3925 roteadores Cisco IOS® que executam imagens de 15,2

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Uma política de pré-filtro é um recurso introduzido na versão 6.1 e tem três objetivos principais:

1. Corresponder o tráfego com base nos cabeçalhos internos e externos
2. Fornecer controle de acesso antecipado que permite que um fluxo ignore completamente o mecanismo Snort
3. Trabalhe como espaço reservado para ACEs (Access Control Entries) migradas da ferramenta de migração Adaptive Security Appliance (ASA).

Configurar

Caso de uso da política de pré-filtro 1

Uma política de pré-filtro pode usar um tipo de regra de túnel que permite que o FTD filtre com base no tráfego em túnel do cabeçalho IP interno e/ou externo. No momento em que este artigo foi escrito, o tráfego em túnel refere-se a:

• GRE (Generic Routing Encapsulation - Encapsulamento de roteamento genérico)
• IP em IP
• IPv6 em IP
• Porta 3544 Teredo

Considere um túnel GRE como mostrado na imagem aqui.

Quando você efetua ping de R1 para R2 com o uso de um túnel GRE, o tráfego passa pelo Firewall é como mostrado na imagem.

Se o firewall for um dispositivo ASA, ele verificará o cabeçalho IP externo como mostrado na imagem.

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

Se o firewall for um dispositivo FirePOWER, ele verificará o cabeçalho IP interno como mostrado na imagem.

Com a política de pré-filtro, um dispositivo FTD pode corresponder o tráfego com base nos cabeçalhos internos e externos.

Ponto principal:

Caso de uso da política de pré-filtro 2

Uma política de pré-filtro pode usar um tipo de regra de pré-filtro que pode fornecer controle de acesso antecipado e permitir que um fluxo ignore completamente o mecanismo Snort, como mostrado na imagem.

Tarefa 1. Verificar a política de pré-filtro padrão

Requisito de tarefa:

Verifique a política de pré-filtro padrão

Solução:

Etapa 1. Navegue até Políticas > Controle de acesso > Prefiltro. Já existe uma política de pré-filtro padrão como mostrado na imagem.

Etapa 2. Selecione Editar para ver as configurações de política como mostrado na imagem.

Etapa 3. A política de pré-filtro já está anexada à política de controle de acesso, como mostrado na imagem.

Verificação de CLI (LINA)

As regras de pré-filtro são adicionadas sobre as ACLs:

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

Tarefa 2. Bloquear tráfego em túnel com etiqueta

Requisito de tarefa:

Bloqueie o tráfego ICMP que está encapsulado dentro do túnel GRE.

Solução:

Etapa 1. Se você aplicar esses ACP, poderá ver que o tráfego do Internet Control Message Protocol (ICMP) está bloqueado, independentemente de ele passar pelo túnel GRE ou não, como mostrado na imagem.

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)

Nesse caso, você pode usar uma política de pré-filtro para atender ao requisito da tarefa. A lógica é a seguinte:

1. Você marca todos os pacotes encapsulados dentro do GRE.
2. Você cria uma política de controle de acesso que corresponde aos pacotes marcados e bloqueia o ICMP. 

Do ponto de vista da arquitetura, os pacotes são verificados em relação às regras de pré-filtro do LINA, depois as regras de pré-filtro do Snort e o ACP e, finalmente, o Snort instrui o LINA a descartar. O primeiro pacote faz isso através do dispositivo FTD.

Etapa 1. Defina uma Tag para o tráfego em túnel.

Navegue até Políticas > Controle de acesso > Prefiltrar e crie uma nova Política de pré-filtro. Lembre-se de que a política de pré-filtro padrão não pode ser editada conforme mostrado na imagem.

Dentro da Política de pré-filtro, você pode definir dois tipos de regras:

• Regra de túnel
• Regra de pré-filtro

Você pode considerar esses dois recursos totalmente diferentes que podem ser configurados em uma política de pré-filtro.

Para esta tarefa, é necessário definir uma Regra de Túnel conforme mostrado na imagem.

No que diz respeito às ações:

Etapa 2. Defina a política de controle de acesso para o tráfego marcado.

Embora possa não ser muito intuitivo no início, a Tag de Túnel pode ser usada por uma Regra de Política de Controle de Acesso como uma Zona de Origem. Navegue até Políticas > Controle de acesso e crie uma Regra que bloqueie o ICMP para o tráfego marcado como mostrado na imagem.

Note: A nova política de pré-filtro está anexada à política de controle de acesso.

Verificação:

Ative a captura no LINA e no 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

A partir de R1, tente fazer ping no ponto de extremidade do túnel GRE remoto. O ping falha:

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)

A captura CLISH mostra que a primeira solicitação de eco passou pelo FTD e a resposta foi 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

A captura do LINA confirma isso:

> 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

Ative o CLISH firewall-engine-debug, limpe os contadores de queda do ASP LINA e faça o mesmo teste. A depuração CLISH mostra que para a Echo-Request você correspondeu à regra de pré-filtro e para a Echo-Reply a regra 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 using 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 using 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

A queda do ASP mostra que o Snort descartou os pacotes:

> 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

Nos Eventos de Conexão, você pode ver a Política de Prefiltro e a Regra que você combinou, como mostrado na imagem.

Tarefa 3. Ignorar o mecanismo de snore com regras de pré-filtro do Fastpath

Diagrama de Rede

Requisito de tarefa:

1. Remova as regras de política de controle de acesso existentes e adicione uma regra de política de controle de acesso que bloqueie todo o tráfego.
2. Configure uma regra de política de pré-filtro que ignore o Snort Engine para o tráfego originado da rede 192.168.75.0/24.

Solução:

Etapa 1. A política de controle de acesso que bloqueia todo o tráfego é conforme mostrado na imagem.

Etapa 2. Adicione uma regra de pré-filtro com Fastpath como uma ação para a rede de origem 192.168.75.0/24, como mostrado na imagem.

Etapa 3. O resultado é como mostrado na imagem.

Etapa 4. Salvar e implantar.

Habilitar captura com rastreamento em ambas as interfaces FTD:

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

Tente fazer ping de R1 (192.168.75.39) para R2 (192.168.76.39) através do FTD. O ping falhou:

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)

Captura na interface interna mostra:

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

O rastreamento do primeiro pacote (echo-request) mostra (pontos importantes destacados):

Captura na interface externa mostra:

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

O rastreamento do pacote de retorno mostra que ele está correspondendo ao fluxo existente (52), mas está bloqueado pela 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, using existing 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

Etapa 5. Adicione mais uma regra de pré-filtro para o tráfego de retorno. O resultado é como mostrado na imagem.

Agora, rastreie o pacote de retorno que você vê (pontos importantes destacados):

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

A verificação foi explicada nas respectivas seções de tarefas.

Troubleshoot

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Informações Relacionadas

• Todas as versões do guia de configuração do Cisco Firepower Management Center podem ser encontradas aqui:

https://www.cisco.com/c/en/us/td/docs/security/firepower/roadmap/firepower-roadmap.html#id_47280

• O Cisco Global Technical Assistance Center (TAC) recomenda enfaticamente este guia visual para um conhecimento prático profundo sobre as tecnologias de segurança de próxima geração do Cisco Firepower, incluindo as mencionadas neste artigo:

http://www.ciscopress.com/title/9781587144806

• Para todas as Notas técnicas de configuração e solução de problemas:

https://www.cisco.com/c/en/us/support/security/defense-center/tsd-products-support-series-home.html

• Suporte Técnico e Documentação - Cisco Systems