Cloud Firewall:FAQ about access control policies

Se eu ativar tanto o WAF em modo de proxy transparente quanto o firewall de Internet, as políticas de controle de acesso do Cloud Firewall controlarão 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 de Internet estão ativados simultaneamente, as políticas de controle de acesso criadas para o firewall de Internet também se aplicam 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 sofre alterações.

É possível aumentar a cota das políticas de controle de acesso?

• No método de faturamento legado por assinatura 1,0, caso a cota de políticas de controle de acesso para Borda de Internet, Borda NAT e Borda VPC 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 mais informações, consulte Legacy billing method 1.0 and upgrade instructions.

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

Sim. Caso a capacidade padrão de tráfego VPC protegido 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 de 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 Create access control policies for the Internet firewall.

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

O Cloud Firewall e os 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 nas bordas da rede e na comunicação entre instâncias. Utilize ambos para garantir defesa em profundidade.

Especificamente:

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

• O Cloud Firewall atua em múltiplas bordas de rede:

  • Firewall de Internet: controla o tráfego na borda da Internet

  • Firewalls NAT: controlam o tráfego na borda NAT

  • Firewalls VPC: controlam o tráfego na borda da VPC

  • Firewalls internos: controlam o tráfego entre instâncias 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 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 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 ECS. Os dois tipos diferem em capacidade e comportamento entre grupos:

Para detalhes, consulte Basic security groups and advanced security groups.

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 de permissão e a última política Drop 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, em seguida, 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 padrão Allow, o sistema informa que não é possível resolver um conflito. Como corrigir isso? {#conflict-cannot-be-resolved}

Isso ocorre quando as regras de 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 padrão Allow que você está aplicando.

Acesse a página Security Groups no console do ECS e ajuste as prioridades das regras conflitantes. Para orientações, consulte Modify a security group rule. 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 de grupo de segurança conflitantes 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 padrão Allow. Para detalhes, consulte Internet firewall.

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 padrão Allow.

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

Como eliminar falsos positivos de conexões de saída suspeitas causadas por varreduras baseadas na 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 de portas fechadas acionem alertas falsos. Para detalhes, consulte Create access control policies for the Internet firewall.

Configurei uma política Drop de saída para 0.0.0.0/0 no firewall de Internet, mas algum tráfego ainda é permitido. 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 uma política Drop estiver configurada, o tráfego identificado como Unknown será negado. Para detalhes, consulte Configure the mode of the access control engine.

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 Create access control policies for the Internet firewall.

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 seguintes causas comuns:

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: Falta de política Drop abrangente

Uma política de permissão precisa (por exemplo, permitindo que apenas um IP específico acesse SSH) está configurada, mas outros endereços IP ainda conseguem alcançar o service porque existe uma regra de permissão de prioridade inferior ou uma regra de permissão padrão. Adicione uma política Drop abrangente com a menor prioridade (colocada por último na lista de políticas): defina Protocol como ANY, Port como 0/0, e tanto os endereços IP de origem quanto de 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 Protect > 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 tanto uma política de lista de permissões quanto uma política Drop, endereços IP fora da lista de permissões ainda conseguem alcançar destinos ICMP (ping). Isso geralmente ocorre porque a política integrada "System default. Allow ICMP requests" tem prioridade maior que sua política Drop. Para resolver isso, altere o endereço IP de origem da sua última política Drop 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}

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

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

1. Crie uma política Drop para *.xyz.com e defina sua prioridade como Lowest.

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

Como a política de permissão para abc.xyz.com tem a maior prioridade, ela é avaliada antes do bloqueio por curinga. Todos os outros subdomínios atingem a política de bloqueio por curinga. Para detalhes, consulte Create access control policies for the Internet firewall.

Como usar o Cloud Firewall para fortalecer 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 ele 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 tanto o Bastionhost quanto 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 de 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 de Internet): Permita tráfego do bastion host apenas para 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 Configure access control policies in scenarios in which Cloud Firewall is deployed together with 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 a hora especificada no dia seguinte.

Exemplo: Recurrence Cycle = Toda terça-feira 18:00–08:00 (+1), Effective Date = 20/08/2024–22/08/2024.

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 VPC para um roteador de trânsito 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 de permissão para tráfego VPC 1 → VPC 2 e uma política padrão Drop, ativar ou desativar um cenário de redirecionamento cria temporariamente um roteamento assimétrico. 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 estão invertidos nesses pacotes de resposta, eles não correspondem à política de permissão e são bloqueados pela política Drop. O tráfego TCP não é afetado.

Solução: Se interrupções de tráfego de curto prazo não forem aceitáveis, configure uma política Allow temporária para 0.0.0.0/0 com a maior prioridade no firewall VPC do roteador de trânsito 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.