Configurar e Operar Políticas de Pré-Filtro de FTD

Introdução

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

Pré-requisitos

Requisitos

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) que executa a versão 6.1.0-195
• Dois roteadores 3925 Cisco IOS® com imagens 15.2

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. 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 finalidades principais:

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

Configurar

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

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. Na época em que este artigo foi escrito, o tráfego em túnel se refere a:

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

Considere um túnel GRE como mostrado na imagem.

Quando você faz ping de R1 para R2 com o uso de um túnel GRE, o tráfego passa pelo Firewall com a aparência mostrada 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 2 da política de pré-filtragem

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 política pré-filtro padrão

Requisito da tarefa:

Verificar a Política de Pré-Filtro padrão

Solução:

Etapa 1. Navegue até Policies > Access Control > Prefilter. Uma Política de Pré-filtro padrão já existe, conforme mostrado na imagem.

Etapa 2. Escolha Editar para ver as configurações da diretiva como mostrado na imagem.

Etapa 3. A Política de Pré-filtro já está anexada à Política de Controle de Acesso conforme 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 tag

Requisito da tarefa:

Bloqueie o tráfego ICMP que é 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 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 LINA (Linux NAtively), depois às regras de pré-filtro Snort e ACP e, finalmente, o Snort instrui o LINA a descartar. O primeiro pacote passa pelo dispositivo FTD.

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

Navegue até Policies > Access Control > Prefilter 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:

1. Regra de túnel
2. Regra de pré-filtro

Você pode pensar nesses dois recursos como totalmente diferentes que podem ser configurados em uma Política de pré-filtro.

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

No que se refere às ações:

Etapa 2. Defina a Política de Controle de Acesso para o tráfego marcado.

Embora não possa ser muito intuitiva a princípio, 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é Policies > Access Control e crie uma Regra que bloqueie o ICMP para o tráfego marcado como mostrado na imagem.

Observação: a nova Política de pré-filtro é anexada à Política de controle de acesso.

Verificação:

Habilitar captura em LINA e em 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

Em R1, tente fazer ping no ponto final 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 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 CLISH firewall-engine-debug, limpe os contadores de queda LINA ASP e faça o mesmo teste. A depuração CLISH mostra que, para a Solicitação de Eco, você correspondeu à regra de pré-filtro e, para a Resposta de Eco, 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 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

A queda de 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

Em Eventos de conexão, você pode ver a política e a regra de pré-filtro que correspondeu conforme mostrado na imagem.

Tarefa 3. Ignorar Mecanismo Snort com Regras de Pré-Filtro Fastpath

Diagrama de Rede

Requisito da tarefa:

1. Remova as regras atuais de Política de Controle de Acesso 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 Mecanismo Snort para o tráfego originado na rede 192.168.75.0/24.

Solução:

Etapa 1. A política de controle de acesso que bloqueia todo o tráfego é como 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 é o 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 falha:

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)

A 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 (solicitação de eco) mostra (pontos importantes destacados):

A 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 corresponde ao fluxo atual (52), mas é 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, 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

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

Agora, rastreie o pacote de retorno exibido (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.

Troubleshooting

No momento, não há informações específicas disponíveis para solucionar esse problema de configuração.

Informações Relacionadas

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

Navegação na documentação do Cisco Secure Firewall Threat Defense

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

Defesa contra ameaças (FTD) do Cisco Firepower

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

Cisco Secure Firewall Management Center

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