Entenda a expansão de regras em dispositivos FirePOWER

Opções de download

  • PDF     (1.1 MB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (1.1 MB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (702.2 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:14 de junho de 2017
ID do documento:200522

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Este documento descreve a tradução das regras de controle de acesso para o sensor quando implantado do Firepower Management Center (FMC).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Conhecimento da tecnologia Firepower
  • Conhecimento sobre a configuração de políticas de controle de acesso no FMC

Componentes Utilizados

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

  • Firepower Management Center versão 6.0.0 e superior
  • Imagem do ASA Firepower Defense (ASA 5515-X, ASA 5525-X, ASA 5545-X, ASA 555-X, ASA 5585-X) executando a versão de software 6.0.1 e superior
  • Imagem ASA Firepower SFR (ASA 5515-X, ASA 5525-X, ASA 5545-X, ASA 555-X, ASA 5585-X) executando a versão de software 6.0.0 e superior
  • Sensor Firepower 7000/8000 Series versão 6.0.0 e superior

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. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

Uma regra de controle de acesso é criada com o uso de uma ou várias combinações desses parâmetros:

  • Endereço IP (origem e destino)
  • Portas (origem e destino)
  • URL (categorias fornecidas pelo sistema e URLs personalizadas)
  • Detectores de aplicativos
  • VLANs
  • Zonas

Com base na combinação de parâmetros usados na regra de acesso, a expansão da regra muda no sensor. Este documento destaca várias combinações de regras no FMC e suas respectivas expansões associadas nos sensores.

Entendendo a expansão de regras

Expansão de uma regra baseada em IP

Considere a configuração de uma regra de acesso do FMC, como mostrado na imagem:

Esta é uma regra única no Management Center. No entanto, depois de implantá-lo no sensor, ele se expande em quatro regras, como mostrado na imagem:

268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart)
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart)
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart)
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart)
268435456 allow any any  any any any  any any any  (ipspolicy 2)

  

Quando você implanta uma regra com duas sub-redes configuradas como Origem e dois hosts configurados como endereços de destino, essa regra é expandida para quatro regras no sensor.

Note: Se o requisito é bloquear o acesso com base em redes de destino, uma maneira melhor de fazer isso é usar o recurso de Listas Negras sob Inteligência de Segurança.

Expansão de uma regra baseada em IP usando URL personalizada

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

Esta é uma regra única no Management Center. No entanto, depois de implantá-lo no sensor, ele é expandido em oito regras, como mostrado na imagem:

268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart) (url "twitter.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 any any any  (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 any any any  (log dcforward flowstart) (url "twitter.com")
268435456 allow any any  any any any  any any any  (ipspolicy 2) 

Quando você implanta uma regra com duas sub-redes configuradas como Origem, dois hosts configurados como endereços de destino e dois objetos de URL personalizados em uma única regra no Management Center , essa regra é expandida para oito regras no sensor. Isso significa que para cada categoria de URL personalizada há uma combinação de intervalos de IP/porta de origem e destino, que são configurados e criados.

Expansão de uma regra baseada em IP usando portas

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

Esta é uma regra única no Management Center. No entanto, depois de implantá-lo no sensor, ele é expandido para dezesseis regras, como mostrado na imagem:

268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 80 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 80 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 443 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 443 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 80 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 80 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 443 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 443 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 80 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 80 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 443 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 443 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 80 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 80 any 6 (log dcforward flowstart) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 443 any 6 (log dcforward flowstart) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 443 any 6 (log dcforward flowstart) (url "twitter.com")
268435456 allow any any any any any any any any (ipspolicy 2)

Quando você implanta uma regra com duas sub-redes configuradas como Origem, dois hosts configurados como endereços de destino e dois objetos de URL personalizados destinados a duas portas, essa regra se expande para dezesseis regras no sensor.

Observação: se houver um requisito para usar as portas na regra de acesso, use os detectores de aplicativos que estão presentes para aplicativos padrão. Isso ajuda a expandir as regras de forma eficiente. 

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

Quando você usa detectores de aplicativos em vez de portas, o número de regras expandidas reduz de 16 a 8, como mostrado na imagem:

268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 3.3.3.3 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "twitter.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "facebook.com")
268436480 allow any 1.1.1.1 32 any any 4.4.4.4 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 3.3.3.3 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "twitter.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "facebook.com")
268436480 allow any 2.2.2.2 32 any any 4.4.4.4 32 any any any (log dcforward flowstart) (appid 676:1, 1122:1) (url "twitter.com")

Expansão de uma regra baseada em IP usando VLANs

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

A regra AllowFile tem uma única linha que corresponde a duas IDs de VLAN com alguns detectores de aplicativos, políticas de intrusão e políticas de arquivo. A regra AllowFile expandirá para duas regras.


268436480 allow any any any any any any 1 any (log dcforward flowstart) (ipspolicy 5) (filepolicy 1 enable) (appid 535:4, 1553:4, 3791:4)
268436480 allow any any any any any any 2 any (log dcforward flowstart) (ipspolicy 5) (filepolicy 1 enable) (appid 535:4, 1553:4, 3791:4)

As políticas de IPS e as políticas de arquivo são exclusivas para cada regra de controle de acesso, mas vários detectores de aplicativos são mencionados na mesma regra e, portanto, não participam da expansão. Quando você considera uma regra com dois IDs de VLAN e três detectores de aplicativos, há apenas duas regras, uma para cada VLAN.

Expansão de uma regra baseada em IP com categorias de URL

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

A regra de bloqueio bloqueia categorias de URL para Adultos e pornografia Qualquer Reputação e Reputação de Álcool e Cigarro 1-3. Esta é uma única regra no Management Center, mas quando você a implanta no sensor, ela é expandida em duas regras, como mostrado neste:


268438530 deny any any  any any any  any any any  (log dcforward flowstart) (urlcat 11)
268438530 deny any any  any any any  any any any  (log dcforward flowstart) (urlcat 76) (urlrep le 60)

Quando você implanta uma única regra com duas sub-redes configuradas como Origem e dois hosts configurados como endereços de destino, juntamente com dois objetos de URL personalizados destinados a duas portas com duas categorias de URL, essa regra se expande para trinta e duas regras no sensor.

Expansão de uma regra baseada em IP com zonas

Zonas são números atribuídos que são referenciados em políticas.

Se uma zona é referenciada em uma política, mas essa zona não é atribuída a nenhuma interface no dispositivo para o qual a política está sendo enviada, a zona é considerada como qualquer e qualquer não leva a qualquer expansão de regras.

Se a zona de origem e a zona de destino forem iguais na regra, o fator de zona será considerado como qualquer e somente uma regra será adicionada, já que QUALQUER não leva a qualquer expansão de regras.

Considere a configuração de uma regra de acesso do FMC conforme mostrado na imagem:

Há duas regras. Uma regra tem Zonas configuradas, mas a zona de origem e de destino é a mesma. A outra regra não tem configuração específica. Neste exemplo, a regra de acesso Interfaces não se traduz em uma regra.


268438531 allow any any any any any any any any (log dcforward flowstart)<-----Allow Access Rule
268434432 allow any any any any any any any any (log dcforward flowstart) (ipspolicy 17)<----------Default Intrusion Prevention Rule

No sensor, ambas as regras aparecem como as mesmas porque o controle baseado em zona que envolve as mesmas interfaces não leva a uma expansão.

A expansão de regras para acesso à Regra de Controle de Acesso baseado em zona ocorre quando a zona referenciada na regra é atribuída a uma interface no dispositivo.

Considere a configuração de uma regra de acesso do FMC conforme mostrado abaixo:

A regra Interfaces envolve regras baseadas em zona com zona de origem como Zonas internas e de destino como Internas, Externas e DMZ. Nesta regra, as zonas da interface interna e DMZ são configuradas nas interfaces e o Externo não existe no dispositivo.Esta é a expansão do mesmo:


268436480 allow 0 any any 2 any any any any (log dcforward flowstart) <------Rule for Internal to DMZ)
268438531 allow any any any any any any any any (log dcforward flowstart)<--------Allow Access rule
268434432 allow any any any any any any any any (log dcforward flowstart) (ipspolicy 17)<--------Default Intrusion Prevention: Balanced Security over Connectivity

Uma regra é criada para um par de interface específico que é Interno > DMZ com especificação de zona clara e uma regra interna > interna não é criada.

O número de regras expandidas é proporcional ao número de pares de origem e de destino da zona que podem ser criados para zonas associadas válidas, incluindo as mesmas regras de zona de origem e de destino.

Note: As regras desativadas do FMC não são propagadas e não expandidas para o sensor durante a implantação da política.

Fórmula geral para expansão de regra

Número de regras no sensor = (Número de sub-redes de origem ou hosts) * (Número de destinos S) * (Número de portas de origem) * (Número de portas de destino) * (Número de URLs personalizadas)* (Número de tags de VLAN)* (Número de categorias de URL)*( Número de pares de zonas de origem e destino válidos)

Note: Para os cálculos, qualquer valor no campo é substituído por 1. O valor any na combinação de regras é considerado como 1 e não aumenta ou expande a regra.

Solução de problemas de falha de implantação devido à expansão da regra

Quando houver uma falha de implantação após adicionar a regra de acesso, siga as etapas mencionadas abaixo para os casos em que o limite de expansão da regra foi atingido

Verifique se há mensagens no /var/log/action.queue.log com as seguintes palavras-chave:

Erro - muitas regras - escrevendo a regra 28, max rules 9094

A mensagem acima indica que há um problema com o número de regras que estão sendo expandidas. Verifique a configuração no FMC para otimizar as regras com base no cenário discutido acima.

Informações Relacionadas

TAC Authored

Colaborado por engenheiros da Cisco

  • Raghunath Kulkarni
    Engenheiro do TAC da Cisco
  • Avinash N
    Engenheiro do TAC da Cisco
  • Prashant Joshi
    Engenheiro do TAC da Cisco

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco

Este documento se refere a estes produtos