Cloud Firewall:FAQ about access control policies

Se eu ativar o WAF em modo de proxy transparente e o firewall da Internet simultaneamente, as políticas de controle de acesso do Cloud Firewall conseguem controlar o tráfego nas portas de encaminhamento? {#waf-transparent-proxy}

Sim. Quando o Web Application Firewall (WAF) em modo de proxy transparente e o firewall da Internet estão ativados, as políticas de controle de acesso criadas para o firewall da Internet aplicam-se ao tráfego nas portas de encaminhamento.

Observe que auditoria de logs, análise de logs e estatísticas de tráfego não estão disponíveis para o tráfego das portas de encaminhamento. O tráfego em outras portas não é afetado.

Os limites de autorização para políticas de controle de acesso podem ser ampliados?

• No método de faturamento legado por assinatura 1,0, caso a cota de políticas de controle de acesso para Internet Border, NAT Border e VPC Border seja insuficiente, adquira Quota for Additional Policy na página de compra do Cloud Firewall para ampliar a cota.

• No método de faturamento legado de pagamento conforme o uso 1,0, não é possível ampliar a cota de políticas de controle de acesso.

• No novo método de faturamento 2,0, não há cobrança adicional para Quota for Additional Policy.

Para obter mais informações, consulte Método de faturamento legado 1,0 e instruções de upgrade.

Posso aumentar a largura de banda de tráfego protegido da VPC? {#vpc-bandwidth}

Sim. Caso a capacidade padrão de tráfego protegido da VPC não atenda às suas necessidades, configure o parâmetro Protected VPC Traffic para elevar o limite máximo de tráfego entre VPCs:

O Cloud Firewall bloqueia tráfego de blocos CIDR IPv6? {#ipv6}

Sim. Crie políticas de controle de acesso no firewall da Internet para controlar o tráfego de blocos CIDR IPv6. O suporte a IPv6 está disponível em todas as edições do Cloud Firewall. Para detalhes, consulte Criar políticas de controle de acesso para o firewall da Internet.

Quais são as diferenças entre o Cloud Firewall e os grupos de segurança? {#cloud-firewall-vs-security-groups}

Cloud Firewall e grupos de segurança são complementares: os grupos de segurança fornecem filtragem de tráfego no nível do host entre instâncias do Elastic Compute Service (ECS), enquanto o Cloud Firewall oferece proteção centralizada nos limites da rede e no nível entre instâncias. Utilize ambos para defesa em profundidade.

Especificamente:

• Um security group é um firewall virtual de host fornecido pelo ECS que controla o tráfego entre instâncias do ECS.

• O Cloud Firewall atua em múltiplos limites de rede:

  • Internet firewall: controla o tráfego no limite da Internet

  • NAT firewalls: controla o tráfego no limite NAT

  • VPC firewalls: controla o tráfego no limite da VPC

  • Internal firewalls: controla o tráfego entre instâncias do ECS

Além dos recursos oferecidos pelos grupos de segurança, o Cloud Firewall adiciona:

• Controle de acesso baseado em aplicação — controle o tráfego por protocolo (como HTTP) sem precisar especificar portas

• Controle de acesso baseado em nome de domínio — permita que instâncias do ECS enviem solicitações apenas para nomes de domínio específicos

• Prevenção de intrusão — proteção proativa contra vulnerabilidades comuns e ataques de força bruta

• Modo de monitoramento — observe o tráfego sem bloqueá-lo, útil para validação de políticas

• Logs completos de tráfego e análise em tempo real

• Gerenciamento centralizado de segurança — as políticas para firewalls internos no console do Cloud Firewall são sincronizadas automaticamente com os grupos de segurança do ECS

Ordem de correspondência de tráfego: Para tráfego de entrada, o Cloud Firewall avalia primeiro, seguido pelos grupos de segurança. Para tráfego de saída, os grupos de segurança avaliam primeiro, seguidos pelo Cloud Firewall. O tráfego só é permitido se passar tanto pelas políticas do Cloud Firewall quanto pelas regras dos grupos de segurança.

Quais são as diferenças entre grupos de políticas comuns e grupos de políticas empresariais? {#common-vs-enterprise-policy-groups}

Os grupos de políticas para firewalls internos correspondem aos grupos de segurança do ECS e controlam o tráfego de entrada e saída entre instâncias do ECS. Os dois tipos diferem em capacidade e comportamento entre grupos:

Para detalhes, consulte Grupos de segurança básicos e grupos de segurança avançados.

Desativar as políticas padrão do sistema afeta o acesso interno da Alibaba Cloud? {#disable-system-default-policies}

Não. Desativar as políticas padrão do sistema no meio da lista de políticas (como "System default. Allow ICMP requests") não afeta o acesso interno normal da Alibaba Cloud. Ative apenas a primeira política allow e a última política deny para obter o comportamento de controle de acesso desejado.

Configurei uma política de controle de acesso de saída HTTP ou HTTPS para um nome de domínio. Como verifico se a política é válida? {#check-http-https-policy}

Utilize o comando curl para enviar uma solicitação HTTP ou HTTPS real ao domínio e verifique a contagem de acertos da política e os logs de auditoria no console do Cloud Firewall.

Por exemplo:

curl -k "https://www.aliyundoc.com"

Ao aplicar as políticas Allow padrão, o sistema informa que não é possível resolver um conflito. Como corrigir isso? {#conflict-cannot-be-resolved}

Isso ocorre quando as regras do grupo de segurança associadas ao endereço IP de destino têm a mesma prioridade, tipo de protocolo, intervalo de portas e objetos de autorização das políticas Allow padrão que você está aplicando.

Acesse a página Security Groups do console do ECS e ajuste as prioridades das regras conflitantes. Para orientações, consulte Modificar uma regra de grupo de segurança. Se precisar de ajuda, envie um ticket.

Por que o ícone Quick Apply está indisponível? {#quick-apply-unavailable}

O ícone Quick Apply fica indisponível quando existem regras conflitantes no grupo de segurança para o endereço IP de destino. Resolva os conflitos de regras nos grupos de segurança do ECS associados ao endereço IP antes de aplicar as políticas Allow padrão. Para detalhes, consulte Firewall da Internet.

O ícone Quick Apply também pode estar indisponível pelos seguintes motivos:

• Os grupos de segurança associados ao endereço IP são grupos de segurança avançados. Grupos de segurança avançados não suportam políticas Allow padrão.

• O firewall da Internet está desativado para o endereço IP.

Como elimino falsos positivos de conexões de saída suspeitas causadas por varreduras via Internet? {#false-positives}

Este é um comportamento conhecido quando o acesso de entrada não está restrito às portas necessárias.

Por que isso acontece: Quando um atacante varre uma porta fechada no seu servidor, o servidor (ou um gateway NAT) retorna um pacote ICMP (Internet Control Message Protocol) indicando que a porta está inacessível. O Cloud Firewall não consegue correlacionar esse pacote ICMP a uma solicitação de entrada, tratando-o como uma conexão de saída iniciada pelo seu servidor. Se o endereço IP do scanner constar na biblioteca de inteligência contra ameaças, o Cloud Firewall gera um alerta.

Por outro lado, quando um pacote SYN chega a uma porta aberta, o servidor retorna um pacote SYN-ACK e o Cloud Firewall trata ambos como parte da mesma conexão — nenhum alerta é gerado.

Solução: Crie uma política de controle de acesso de entrada que permita tráfego apenas nas portas exigidas pelas suas cargas de trabalho. Isso evita que respostas de varredura em portas fechadas acionem alertas falsos. Para detalhes, consulte Criar políticas de controle de acesso para o firewall da Internet.

Configurei uma política Deny de saída para 0.0.0.0/0 no firewall da Internet, mas parte do tráfego ainda é permitida. Por quê? {#deny-not-blocking-all}

O Cloud Firewall permite temporariamente o tráfego quando ainda não consegue identificar o nome de domínio ou o tipo de aplicação do tráfego, para que políticas subsequentes possam concluir a identificação. Isso se aplica a dois cenários:

• Nome de domínio ainda não identificado: Existe uma política baseada em nome de domínio com alta prioridade, e o Cloud Firewall identificou o IP de origem, o IP de destino e o tipo de aplicação — mas não o nome de domínio. O Cloud Firewall permite que o tráfego continue para que o nome de domínio possa ser resolvido por políticas subsequentes.

• Tipo de aplicação ainda não identificado: Existe uma política baseada em aplicação com alta prioridade, e o Cloud Firewall identificou o IP de origem, o IP de destino e a porta — mas não o tipo de aplicação. O Cloud Firewall permite que o tráfego continue para que o tipo de aplicação possa ser identificado.

Para evitar esse comportamento, utilize uma das seguintes abordagens:

Opção 1: Ativar o modo estrito

No modo estrito, o Cloud Firewall continua avaliando as políticas até que o tipo de aplicação ou o nome de domínio seja identificado. Se houver uma política Deny configurada, o tráfego identificado como Unknown será negado. Para detalhes, consulte Configurar o modo do mecanismo de controle de acesso.

Opção 2: Usar apenas políticas de Camada 4

Crie políticas de controle de acesso de Camada 4 com Application definido como ANY e sem nomes de domínio especificados para Destination. Quando o tráfego corresponde a uma política de Camada 4, o Cloud Firewall aplica a ação da política imediatamente, sem aguardar a identificação da camada de aplicação. Para detalhes, consulte Criar políticas de controle de acesso para o firewall da Internet.

Por que uma política de controle de acesso de alta prioridade não corresponde ao tráfego? {#high-priority-policy-not-matching}

Se uma política de controle de acesso de alta prioridade não corresponder ao tráfego conforme esperado, verifique as causas comuns a seguir:

Causa 1: Incompatibilidade de restrição de origem

A política de alta prioridade especifica uma restrição de IP de origem, mas o IP de origem real nos logs de tráfego não está dentro do intervalo permitido. Revise o IP de origem nos logs e atualize a configuração de IP de origem da política adequadamente.

Causa 2: Ausência de política deny abrangente

Uma política allow precisa (por exemplo, permitindo que apenas um IP específico acesse SSH) está configurada, mas outros endereços IP ainda conseguem alcançar o serviço porque existe uma regra allow de menor prioridade ou uma regra allow padrão. Adicione uma política deny abrangente com a prioridade mais baixa (colocada por último na lista de políticas): defina Protocol como All Protocols, Port como 0/0 e os endereços IP de origem e destino como 0.0.0.0/0. Isso bloqueia todo o tráfego não correspondido pelas políticas anteriores.

Para verificar se a política entrou em vigor, teste a conectividade a partir de um host que não esteja na mesma VPC ou na mesma região do recurso protegido.

Causa 3: Entradas ausentes no catálogo de endereços

Uma política está configurada para usar um catálogo de endereços para IPs de origem, mas o tráfego esperado não é correspondido porque o IP de origem do tráfego não está listado no catálogo. No console do Cloud Firewall, acesse Protection Config > Policy Configuration > Address Book para verificar as entradas do catálogo de endereços e adicionar os endereços IP ausentes.

Causa 4: Interferência de política padrão do sistema

Após configurar uma política de lista de permissões e uma política deny, endereços IP fora da lista de permissões ainda conseguem alcançar alvos ICMP (ping). Isso geralmente ocorre porque a política integrada "System default. Allow ICMP requests" tem prioridade maior que sua política deny. Para resolver isso, altere o endereço IP de origem da sua última política deny para 0.0.0.0/0.

Como permitir acesso apenas a um subdomínio específico e bloquear o restante do domínio? {#subdomain-access-control}

Use duas políticas com prioridades diferentes — uma política allow para o subdomínio de destino e uma política deny para o padrão curinga. A política allow deve ter prioridade maior que a política deny.

Usando xyz.com como exemplo para permitir apenas abc.xyz.com:

1. Crie uma política para block o acesso a *.xyz.com e defina sua prioridade como Lowest.

2. Crie uma política para allow o acesso a abc.xyz.com e defina sua prioridade como Highest.

Como a política allow para abc.xyz.com tem a prioridade mais alta, ela é avaliada antes do bloqueio curinga. Todos os outros subdomínios atingem a política de bloqueio curinga. Para detalhes, consulte Criar políticas de controle de acesso para o firewall da Internet.

Como usar o Cloud Firewall para reforçar o controle de acesso nos nomes de domínio de um bastion host? {#bastionhost}

O Bastionhost é uma plataforma de gerenciamento de operações e manutenção (O&M) que lida com autenticação de identidade, gerenciamento de contas e auditoria. Como armazena informações confidenciais de contas e suporta acesso baseado em nome de domínio, usuários não autorizados que chegarem à página de login do bastion host podem potencialmente acessar um grande número de ativos.

Ao adquirir o Bastionhost e o Cloud Firewall, o Bastionhost é adicionado automaticamente como um tipo de ativo no Cloud Firewall, e o bastion host adquirido é sincronizado automaticamente com a lista de ativos do Cloud Firewall. Isso permite aplicar controle de acesso, prevenção de intrusão e análise de tráfego de rede aos endereços IP públicos do bastion host a partir de um único local.

Configure as seguintes políticas:

• Controle de acesso de entrada (firewall da Internet): Permita tráfego da Internet ou da Internet em áreas especificadas para as portas abertas do bastion host.

• Controle de acesso de saída (firewall da Internet): Permita tráfego do bastion host apenas para os endereços IP públicos necessários.

• Prevenção de intrusão: Ative o firewall para o bastion host redirecionar seu tráfego de entrada e saída através do Cloud Firewall para proteção.

Para um tutorial completo de configuração, consulte Configurar políticas de controle de acesso em cenários onde o Cloud Firewall é implantado junto com o Bastionhost.

Uma política de controle de acesso entra em vigor se o intervalo de recorrência abranger dois dias civis? {#spanning-two-days}

Sim. Quando o Recurrence Cycle abrange dois dias civis (por exemplo, das 18:00 às 08:00 do dia seguinte) e a hora inicial da Effective Date cai dentro desse intervalo, a hora final da política passa para o horário especificado no dia seguinte.

Exemplo: Recurrence Cycle = Toda terça-feira 18:00–08:00 (+1), Effective Date = 2024.08.20–2024.08.22.

A política entra em vigor das 18:00 de 20 de agosto de 2024 até as 08:00 de 21 de agosto de 2024.

O que fazer se o tráfego unidirecional em um firewall de VPC para um transit router for bloqueado ao alterar o cenário de redirecionamento de tráfego? {#unidirectional-traffic-blocked}

Isso é causado por uma assimetria de roteamento que ocorre durante a transição ao ativar ou desativar um cenário de redirecionamento de tráfego.

Why it happens: Se você tiver uma política allow para tráfego VPC 1 → VPC 2 e uma política Deny padrão, ativar ou desativar um cenário de redirecionamento cria temporariamente um roteamento assimétrico. Os pacotes de resposta para tráfego ICMP e UDP são tratados como tráfego novo e não solicitado, sendo redirecionados para o Cloud Firewall. Como os IPs de origem e destino são invertidos nesses pacotes de resposta, eles não correspondem à política allow e são bloqueados pela política Deny. O tráfego TCP não é afetado.

Solução: Se uma interrupção temporária do tráfego não for aceitável, configure uma política Allow temporária para 0.0.0.0/0 com a prioridade mais alta no firewall de VPC do transit router da Cloud Enterprise Network (CEN) antes de ativar ou desativar o firewall. Isso permite o tráfego reverso durante a transição. Após o firewall ser totalmente ativado ou desativado, exclua a política temporária.