Onboarding FAQ - Web Application Firewall: Central de Documentação do Alibaba Cloud

Visão geral

Recursos e dúvidas de configuração pré-integração
Problemas que podem ocorrer durante a integração
Problemas que podem ocorrer após a integração

Qual é a diferença entre um endereço IP de origem e um endereço IP de back-to-origin no WAF?

IP de back-to-origin do WAF: Faixa de IPs que o WAF utiliza para encaminhar o tráfego protegido ao seu servidor de origem. A Alibaba Cloud aloca esses IPs e eles identificam o WAF como a source ao fazer solicitações à sua origem.
- A faixa de IPs de back-to-origin geralmente é um conjunto fixo de endereços IP.
- Do ponto de vista do servidor de origem, o WAF intercepta e encaminha todas as solicitações de cliente. O IP real do cliente fica registrado em um campo de cabeçalho http, como X-Forwarded-For, ou em um cabeçalho personalizado.
IP de origem: Endereço IP público do servidor backend que realmente hospeda seu negócio, ou o endereço IP resolvido a partir do seu domínio. É o destino que recebe as solicitações e retorna respostas quando os usuários acesse o site.
- Um IP de origem pode ser um único endereço IP ou vários endereços IP (com suporte a balanceamento de carga).
- O IP de origem é o endereço de service real do seu site, que pode estar implantado no ECS, slb ou OSS da Alibaba Cloud, ou em outro provedor de cloud.

O mesmo domínio pode usar integração de product cloud e integração CNAME simultaneamente?

Não é recomendado. Cada domínio só pode utilizar um modo de integração: integração de product cloud ou integração CNAME. Integrar o mesmo domínio duas vezes causa conflitos de encaminhamento e desativa a proteção. Se você precisar alterar um domínio já protegido pelo WAF via integração CNAME para a integração de product cloud, primeiro exclua a configuração de integração CNAME desse domínio e depois reintegre-o no modo de product cloud.

O WAF protege vários IPs de servidor de origem sob um único domínio?

Sim. É possível configure até 20 endereços IP de origem para um único domínio do WAF.

O WAF executa verificações de integridade nos servidores de origem?

O WAF ative as verificações de integridade por padrão. Ele verifica a acessibilidade de todos os IPs de origem. Caso um IP de origem pare de responder, o WAF encaminha as solicitações para outros IPs de origem íntegros.

Quando um IP de origem deixa de responder, o WAF defina automaticamente um período de silêncio para esse IP. Após o término desse período, novas solicitações ainda podem ser encaminhadas a ele para testes.

Um IP exclusivo no WAF pode mitigar ataques DDoS?

Um IP exclusivo evita que um ataque DDoS de grande volume em um domínio torne inacessíveis todos os outros domínios integrados. Para mais informações, consulte Value of exclusive IP addresses.

O WAF pode ser integrado ao CDN ou ao Anti-DDoS Proxy?

O WAF é totalmente compatível com os serviços CDN e Anti-DDoS Proxy. Ao usá-los juntos, basta configure o endereço CNAME do WAF como origem para o Anti-DDoS Proxy ou CDN. Isso permite que o tráfego seja encaminhado através do Anti-DDoS Proxy ou CDN para o WAF e, em seguida, do WAF para o servidor de origem, oferecendo segurança abrangente para sua origem. Para mais informações, consulte Protect a website service by using Anti-DDoS Proxy and WAF e Protect a CDN-accelerated domain with WAF.

O WAF suporta o uso entre contas de arquiteturas CDN + Anti-DDoS Proxy + WAF?

Sim. Você pode usar CDN, Anti-DDoS Proxy e WAF em diferentes contas da Alibaba Cloud para crie uma arquitetura de segurança contra ataques DDoS e ataques a aplicações web.

Como o WAF garante a segurança dos certificados e chaves privadas carregados? O WAF descriptografa o tráfego HTTPS e registra o conteúdo das solicitações?

Ao proteger tráfego HTTPS, o Alibaba Cloud WAF exige que você carregue o certificado SSL e a chave privada correspondentes para descriptografar o tráfego HTTPS e detectar assinaturas de ataque. Utilizamos um Key Server dedicado para armazenar e gerencie certificados e chaves. Esse Key Server é baseado no Key Management Service (KMS) da Alibaba Cloud, garantindo a segurança, integridade e disponibilidade dos seus certificados e chaves em conformidade com requisitos regulatórios e de proteção classificada. Para detalhes sobre o KMS, consulte What is Key Management Service?.

O WAF usa o certificado SSL e a chave privada carregados apenas para descriptografar o tráfego HTTPS visando detecção em tempo real. Registramos apenas as partes das solicitações que contêm assinaturas de ataque (payloads) para relatórios de ataque e análise estatística. Não registramos o conteúdo completo de solicitações ou respostas sem sua autorização.

O Alibaba Cloud WAF obteve diversas certificações internacionais autorizadas, incluindo ISO 9001, ISO 20000, ISO 22301, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 29151, BS 10012, CSA STAR, Proteção Classificada Nível 3, SOC 1/2/3, C5, HK Finance, OSPAR e PCI DSS. Como um product padrão da Alibaba Cloud, o WAF possui as mesmas qualificações de conformidade de segurança da plataforma Alibaba Cloud no nível de plataforma cloud.

Meu site está protegido pelo WAF, mas não aparece na lista de domínios

O registro ICP do seu domínio pode ter expirado, tornando-o incompatível com os requisitos de integração, e o WAF o removeu automaticamente. Você deve concluir o registro ICP do domínio e reintegrá-lo ao WAF. Para informações sobre o registro ICP da Alibaba Cloud, consulte ICP filing process.

Importante

Antes de integrar seu site a uma instância do WAF na china continental, garanta que o domínio possua um registro ICP válido. Para cumprir as leis e regulamentos aplicáveis, as instâncias do WAF na china continental removem periodicamente domínios com registros ICP expirados.

Como o WAF obtém o IP de origem do cliente e registra o IP do cliente por meio de um cabeçalho personalizado?

Obter o IP de origem do cliente a partir de um cabeçalho personalizado: Se o seu site possui outros serviços de proxy de camada 7 (como Anti-DDoS Proxy ou CDN) antes do WAF, utilize um cabeçalho personalizado para transportar o IP do cliente. Isso evita que invasores forjem o campo XFF para burlar regras de detecção do WAF e melhora a segurança do negócio. Coloque o IP de origem do cliente em um campo de cabeçalho personalizado (por exemplo, X-Client-IP ou X-Real-IP) e configure o WAF para ler esse campo. O WAF usa o valor do campo de cabeçalho especificado como o IP de origem do cliente. Se você configure vários campos de cabeçalho, o WAF tentará ler o IP do cliente deles em ordem.

Registrar o IP do cliente em um cabeçalho personalizado: Ao adicionar um site ao WAF, ative a marcação de tráfego para que o WAF grave o IP do cliente em um cabeçalho personalizado na solicitação do cliente. O servidor backend poderá então ler o IP do cliente a partir do campo de cabeçalho especificado na solicitação de back-to-origin. Isso se aplica a cenários em que o servidor backend precisa obter o IP do cliente de um cabeçalho personalizado específico para análise de negócios.

Qual é a diferença entre Anti-DDoS e WAF Protection para uma instância ALB? Devo ative ambos?

O Web Application Firewall (WAF) e a proteção Anti-DDoS são dois recursos de segurança independentes e complementares. Suas principais diferenças são:

WAF: Protege principalmente contra ameaças na camada de aplicação (L7), como injeção SQL, ataques de cross-site scripting (XSS) e ataques CC. Para ative essa proteção, faça upgrade da instância ALB para "ALB WAF Enhanced Edition". Essa ação gera cobranças adicionais. Para mais informações, consulte Enable WAF protection for an ALB instance.
Proteção Anti-DDoS: Protege principalmente contra ataques volumétricos nas camadas de rede e transporte (L3/L4). As instâncias ALB fornecem proteção básica Anti-DDoS gratuita por padrão. Se o tráfego de ataque exceder o limiar de blackhole, compre e anexe um EIP Anti-DDoS (Enhanced). Para mais informações, consulte Associate an Anti-DDoS (Enhanced) EIP with an ALB instance.

configure esses recursos com base nos riscos de segurança que sua aplicação enfrenta. Para uma defesa abrangente em profundidade nas camadas de rede e aplicação, ative ambos os recursos de proteção.

O WAF suporta integração para o protocolo tcp de camada 4?

O WAF permite ative a proteção do WAF para tráfego de protocolos http e HTTPS escutado por portas de instâncias CLB (tcp) de camada 4 e ECS. Ele não suporta o encaminhamento e a proteção de tráfego em portas que utilizam outros protocolos não http/HTTPS.

Como firewall de aplicação web, o WAF protege principalmente o tráfego web, ou seja, tráfego http e HTTPS. Portanto, quando o tráfego monitorado por uma porta de instância CLB (tcp) de camada 4 ou ECS for tráfego web, o WAF poderá fornecer proteção de encaminhamento. No entanto, se a instância de product cloud de camada 4 transportar tráfego de outros protocolos de camada de aplicação (como FTP, SMTP, etc.), o WAF não conseguirá encaminhar esse tráfego.

Como exportar em lote a lista de informações de domínios integrados via CNAME?

Chame a API DescribeInstance para obter o ID da sua instância do WAF e, em seguida, chame a API DescribeDomains para consultar a lista de todos os domínios integrados via CNAME.

Durante a integração CNAME, como o WAF faz o balanceamento de carga de uma origem do tipo domínio (como CNAME)?

No modo de integração CNAME, quando sua origem possui vários endereços de servidor, selecione diferentes opções de Load Balancing Algorithm para que o WAF encaminhe solicitações de back-to-origin aos servidores correspondentes, realizando o balanceamento de carga.

Quando Server Address estiver definido como Domain Name (Such as CNAME), se a resolução desse domínio retornar vários endereços IP, o WAF fará o balanceamento de carga das solicitações do cliente entre os endereços IP resolvidos. Se você insira vários domínios, o WAF expandirá todos os resultados de resolução e fará o balanceamento de carga entre eles.

No entanto, se você insira apenas um domínio e cada resolução de domínio retornar apenas um endereço IP, o WAF não realizará balanceamento de carga e encaminhará o back-to-origin apenas para o único resultado resolvido.

O mesmo nome de domínio resolve para várias instâncias de produtos cloud. Como devo integrar?

Integração de product cloud: Integre todas essas instâncias de produtos cloud simultaneamente (por exemplo, as portas de service de uma instância CLB) para que o WAF redirecione o tráfego para todas elas.

Integração CNAME: Após integrar o domínio via CNAME, todas as instâncias de produtos cloud serão protegidas pela política de proteção padrão do WAF.

Vários nomes de domínio resolvem para a mesma instância de product cloud. Como devo integrar?

Integração de product cloud: Após integrar a instância de product cloud, todos os domínios nessa instância são automaticamente protegidos pela política padrão do WAF. Contudo, se desejar configure regras de proteção separadas para domínios individuais, adicione manualmente cada domínio como um objeto protegido. Para detalhes, consulte Manually add a protected object.

Integração CNAME: Integre cada domínio individualmente.

Quais sufixos de nome de domínio são suportados para integração CNAME?

O WAF 3.0 suporta a maioria dos sufixos de nome de domínio, incluindo sufixos de domínio chinês. Para a lista completa de sufixos chineses suportados, consulte iana.org.

O WAF 3.0 suporta mais sufixos de domínio que o WAF 2.0. Se um sufixo de domínio não for suportado no WAF 2.0, recomendamos fazer upgrade para o WAF 3.0.

O WAF suporta autenticação mútua HTTPS (mTLS)?

A integração CNAME e a integração transparente não suportam autenticação mútua HTTPS. A solução de integração baseada em service no WAF 3.0 oferece esse suporte. Atualmente, os produtos cloud que suportam integração baseada em service incluem ALB, MSE, FC e SAE. configure isso na seção de integração de produtos cloud no console do WAF.

O WAF suporta os protocolos WebSocket, http/2 ou SPDY?

Protocolo WebSocket: O encaminhamento de tráfego é suportado. Nenhuma proteção de segurança é fornecida.
Protocolo http/2: Escuta e back-to-origin são suportados.
Protocolo SPDY: Não suportado.

Para evitar que invasores usem contrabando de texto simples http/2 (h2c) para burlar o WAF, crie uma regra personalizada para interceptar solicitações onde o nome do Header seja Upgrade e o valor seja h2c. Para detalhes, consulte Create a custom rule to defend against specific requests.

O WAF suporta sites que usam autenticação de protocolo NTLM?

Não. Se um site usar autenticação de protocolo NTLM, as solicitações de acesso encaminhadas pelo WAF podem falhar na autenticação NTLM no servidor de origem, causando prompts repetidos de autenticação no cliente. Recomendamos usar um método de autenticação diferente para o seu site.

O limite de QPS do WAF se aplica a toda a instância do WAF ou a cada domínio individualmente?

O limite de QPS do WAF aplica-se a toda a instância do WAF.

Por exemplo, se você configure três domínios em uma instância do WAF, o QPS combinado deles não deve exceder o limite especificado. Se o QPS exceder o limite da instância do WAF adquirida, a instância poderá entrar em sandbox. Quando o QPS real excede a especificação ou a instância entra em sandbox, o WAF não garante mais a conformidade com o Service Level Agreement (SLA).

Uma instância do WAF adquirida suporta migração simplificada para outra conta da Alibaba Cloud?

Instâncias do WAF não suportam migração simplificada direta para outras contas da Alibaba Cloud. Se precisar usar o WAF entre contas, utilize uma das soluções alternativas abaixo:

Cancelar assinatura e readquirir: Cancele a assinatura para liberar a instância do WAF na conta atual e readquira-a na conta de destino.
Gerenciamento unificado de múltiplas contas: Use o recurso Multi-account management para gerencie a conta de destino sob o sistema do WAF da conta atual.

Como visualize as faixas de IP de back-to-origin do WAF e o CNAME fornecido pelo WAF?

Encontre as faixas de IP de back-to-origin do WAF e os endereços CNAME fornecidos pelo WAF para cada domínio integrado no local mostrado na figura a seguir, na página da lista de integração.

Solução de problemas quando a instância CLB, NLB ou ECS que você deseja integrar não é encontrada na página de configuração de integração

Causa possível	Ação relacionada
A instância CLB, NLB ou ECS que você deseja integrar não atende às condições de integração.	Verifique a instância em relação às condições de integração. Para detalhes, consulte CLB instance onboarding conditions, NLB instance onboarding conditions e ECS instance onboarding conditions.
A instância CLB que você deseja integrar não possui o listener correspondente configurado.	Para adicionar um listener em uma instância CLB de camada 7, consulte Add an http listener e Add an HTTPS listener. Para adicionar um listener em uma instância CLB de camada 4, consulte Add a tcp listener.
O WAF não sincronizou a instância CLB, NLB ou ECS.	Para etapas de sincronização manual de ativos, consulte Manually sync assets.

Ao adicionar uma porta de redirecionamento de tráfego HTTPS, a mensagem "CLB certificate is incomplete" é exibida. Como resolver?

Sintoma

Ao adicionar uma porta de redirecionamento de tráfego HTTPS, o WAF valida a origem do certificado para essa porta. Após adicionar a porta, a seguinte mensagem pode aparecer: The CLB certificate for port XXX is incomplete. Please reselect a certificate from the SSL Certificate Service in the CLB console.

Causas possíveis

O certificado não foi adquirido através do Certificate Management Service (Original SSL Certificate) da Alibaba Cloud e não foi carregado no Certificate Management Service (Original SSL Certificate) da Alibaba Cloud.
O certificado para o listener da porta HTTPS na instância CLB foi carregado através do console CLB. No entanto, esse método de upload não sincroniza automaticamente as informações do certificado com o Digital Certificate Management Service (antigo SSL Certificate Management). Como o WAF recupera informações de certificado apenas do Digital Certificate Management Service, isso causa a mensagem certificate is incomplete.
Um certificado previamente carregado no Digital Certificate Management Service foi excluído manualmente, e o Certificate Management Service (Original SSL Certificate) não contém mais o seu certificado.

Solução

Carregue seu certificado no Certificate Management Service (Original SSL Certificate). Para etapas, consulte Upload an SSL certificate.
No console CLB, crie um certificado e selecione certificados emitidos pela Alibaba Cloud como origem do certificado. Para etapas, consulte Use a certificate from Alibaba Cloud SSL Certificates Service.
No console CLB, selecione o certificado de servidor carregado. Para etapas, consulte Step 2: Configure the SSL certificate.

Para o endereço IP de origem no WAF, devo usar o IP público ou privado de uma instância ECS?

Use o IP público. O WAF realiza o back-to-origin pela rede pública e não suporta endereços IP privados.

Por que a adição de vários certificados estendidos falha durante a integração de product cloud?

Uma causa possível é que um dos certificados seja inválido. Ao adicionar vários certificados estendidos, garanta que cada certificado selecionado seja válido. Certificados expirados causarão falha na adição.

Após integrar um product cloud ao WAF, ainda preciso configure objetos protegidos?

Por padrão, após a integração de um product cloud ao WAF, o sistema gera automaticamente um objeto protegido, sem necessidade de configuração adicional. No entanto, se vários domínios resolverem para a mesma instância de product cloud e você quiser configure regras de proteção separadas para cada domínio, adicione manualmente cada domínio como um objeto protegido. Para detalhes, consulte Add a protected object.

Após adicionar objetos protegidos, selecione o domínio correspondente como objeto efetivo ao configure regras de proteção para obter proteção granular para múltiplos domínios.

Durante a integração CNAME, por que ERR_TOO_MANY_REDIRECTS é exibido após configure o back-to-origin http?

O back-to-origin http significa que o WAF usa o protocolo http para encaminhar solicitações de back-to-origin ao servidor de origem, sendo a porta padrão de back-to-origin a 80. Após ative esse recurso, independentemente de o cliente acesse o WAF na porta 80 ou 443, o WAF usará por padrão o protocolo http e a porta 80 para back-to-origin. Se a porta 80 no seu servidor de origem não tiver nenhum negócio real, ative esse recurso causará problemas de acesso ao site.

Se a porta 80 no servidor de origem não tiver nenhum negócio real e houver um redirecionamento configurado para a porta 80 (por exemplo, retornando um código de status 301 para redirecionar para a porta 443), o acesso do cliente será continuamente redirecionado, resultando no erro ERR_TOO_MANY_REDIRECTS.

Por que o erro InvalidTLS ocorre ao integrar uma instância CLB via integração de product cloud?

Ao integrar uma instância CLB via integração de product cloud, o erro Waf.Pullin.InvalidTLS (TLS inválido) pode aparecer. Isso provavelmente ocorre porque a instância CLB é uma instância de desempenho compartilhado. O WAF não suporta a obtenção de informações de configuração TLS para instâncias de desempenho compartilhado. Altere a instância para uma instância de desempenho garantido antes que a integração de product cloud seja suportada. Para mais informações, consulte CLB instance types.

O IP público do meu servidor de origem está exposto. Como evito que invasores burlem o WAF atacando diretamente o IP público de origem?

Método 1: No modo de integração CNAME, configure seu servidor de origem para aceitar tráfego apenas das faixas de IP de back-to-origin do WAF, garantindo que apenas o WAF possa se comunicar com o servidor de origem. Para detalhes, consulte Allow WAF back-to-origin IP ranges.

Método 2: Use a integração de product cloud.

Múltiplos cenários para erros 502 após integração ao WAF

Sintoma

Após a integração ao WAF, o acesso ao service backend retorna um código de status 502, ou os logs mostram solicitações com código de status 502.

Causas e soluções

Cenário 1: 502 no modo de integração CNAME

No modo de integração CNAME, um erro 502 ocorre em alguns casos quando o servidor de origem (como uma instância ECS ou CLB) não pode ser alcançado pelo WAF. Recomendamos verificar as regras do grupo de segurança do seu servidor de origem, iptables, firewall ou software de segurança (como Safedog ou Yunsuo) que possam bloquear o acesso do WAF. Por exemplo, pode ser necessário Allow access from back-to-origin CIDR blocks of WAF no seu grupo de segurança ECS.

Garanta também que o nome de domínio e as informações do servidor de origem configurados no console do WAF correspondam ao seu service real. Uma incompatibilidade também causará esse erro.

Cenário 2: 5XX intermitente com CLB de camada 7 no modo de integração de product cloud

Análise detalhada da causa

Tempo limite de ociosidade da conexão de back-to-origin do WAF: 3.600 segundos (1 hora)

Descrição: Quando a conexão entre o CLB e o WAF não tem transmissão de dados por 1 hora, o WAF fecha automaticamente a conexão.

Tempo limite de ociosidade da conexão voltada para o cliente do CLB: 15 segundos

Descrição: Quando a conexão entre o cliente (instância do WAF neste caso) e o CLB não tem transmissão de dados por 15 segundos, o CLB fecha automaticamente a conexão.

Em casos extremos, no momento em que uma conexão persistente expira no lado do CLB (sem transmissão de dados por mais de 15 segundos), o WAF reutiliza essa conexão para enviar uma nova solicitação de back-to-origin ao CLB. Como o CLB não possui mais o estado da conexão, ele envia um pacote RST para encerrar a solicitação. Isso resulta em um log de código de status 502 no lado do WAF.

Solução

Ajuste o Idle persistent connection timeout na configuração de integração de product cloud do CLB de camada 7 para um valor menor que o tempo limite de ociosidade da conexão voltada para o cliente do CLB — por exemplo, 14 segundos.

Cenário 3: 502 intermitente devido a URI excessivamente longa

Análise detalhada da causa

O CLB de camada 7 é o próximo salto após o WAF encaminhar o tráfego. No entanto, o limite de comprimento de URI do CLB é de 32 KB. Quando uma URI de solicitação do WAF excede o comprimento que o CLB pode analisar, o CLB recusa o atendimento da solicitação. O CLB registra um código de status 414 e o WAF retorna um código de status 502.

Solução

Reduza o comprimento da URI. Se a carga útil de dados for grande, use POST para transmissão de dados.

Cenário 4: 502 intermitente quando o WAF envia solicitações de back-to-origin para múltiplos CLBs de camada 4

Arquitetura de rede atual

Na arquitetura atual, o WAF está integrado no modo reverse proxy com back-to-origin para múltiplas instâncias CLB de camada 4. O RealServer (RS) backend escuta na mesma porta e está montado atrás de múltiplas instâncias CLB de camada 4.

Análise detalhada da causa

Quando uma instância ECS serve como servidor backend para múltiplas instâncias CLB de camada 4 (protocolo tcp) configuradas com a mesma porta de service backend, os seguintes problemas podem ocorrer: Se solicitações do mesmo nó do WAF forem enviadas como back-to-origin para instâncias CLB usando o mesmo endereço IP de nó de instância do WAF simultaneamente, algumas conexões podem falhar ou atingir tempo limite.

Caso 1: Conflito de 5 tuplas, colisão de fluxo tcp

Quando o WAF protege múltiplos nós CLB, as solicitações desses nós podem se originar do mesmo endereço IP de back-to-origin do WAF.

Quando o nó do WAF envia solicitações de back-to-origin para o CLB1, a conexão (WIP:CPORT->VIP1:VPORT1) é convertida para (WIP:CPORT->DIP:DPORT) ao chegar ao ECS backend.
Quando o nó do WAF envia solicitações de back-to-origin para o CLB2, a conexão (WIP:CPORT->VIP2:VPORT2) também é convertida para (WIP:CPORT->DIP:DPORT) ao chegar ao ECS backend.
Como os números de sequência e estados das duas conexões tcp entram em conflito no servidor backend, o estabelecimento da conexão falha. Especificamente, ambas as conexões tcp iniciadas são vistas como tendo a mesma 5-tupla (tcp:WIP:CPORT:DIP:DPORT) no servidor backend. Esse conflito de 5-tupla pode causar o descarte de pacotes SYN.

Caso 2: Erros de roteamento de pacotes de resposta

Em um caminho de solicitação completo, o nó CLB que inicia a solicitação difere do nó CLB que recebe o pacote de resposta.

O WAF envia o pacote SYN de back-to-origin através do CLB2, com a 5-tupla WIP:CPORT->VIP1:VPORT1. Ao chegar ao ECS2 backend, é convertido para WIP:CPORT->DIP:DPORT.
Se o ECS2 tiver uma conexão TIME-WAIT neste momento, a 5-tupla é tcp:WIP:CPORT:DIP:DPORT. Ao receber o pacote SYN da etapa 1, o ECS2 determina que o SYN é válido e responde com um pacote SYN-ACK.
Como o ECS2 está montado atrás de múltiplas instâncias slb, ele pode enviar o pacote SYN-ACK de volta para o CLB1. Se o CLB1 não tiver uma sessão para essa 5-tupla, o CLB1 envia um pacote Reset bidirecional, fazendo com que o WAF retorne um 502.

Soluções

Solução 1 (Recomendada)

modifique a arquitetura de rede, por exemplo, use múltiplas instâncias CLB de camada 7 como servidores de origem, para evitar que múltiplos nós balanceadores de carga CLB de camada 4 diferentes encaminhem solicitações para a mesma porta no mesmo service backend.

Solução 2

Migre do CLB para o NLB e desative a Client IP Affinity na configuração do NLB para resolver o conflito de 5-tupla. Implante o Proxy Protocol no service backend para obter o IP real do cliente. Para detalhes, consulte Use Proxy Protocol.

Etapas

Faça login no console Network Load Balancer (NLB).Na barra de navegação superior, selecione a região onde a instância NLB está implantada.
No painel de navegação à esquerda, escolha Network Load Balancer (NLB) > Server Groups.
selecione seu grupo de servidores e, na coluna Actions, clique em Modify Basic Information. Na caixa de diálogo Modify Basic Information, desative a Client IP Preservation e salve as alterações.

Solução 3 (Não recomendada)

Envie um Tickets para ative o modo FULLNAT. Quando múltiplas instâncias CLB encaminham solicitações para a mesma porta no mesmo servidor backend, o FullNAT modifica o endereço de origem, tornando a 5-tupla de cada conexão única e evitando conflitos. ative o modo FULLNAT nos listeners do CLB para evitar conflitos de 5-tupla.

Cenário 5: Problemas de parâmetro do kernel Linux causam retorno 502 nas solicitações

Algumas versões mais antigas do Linux possuem um parâmetro de kernel net.ipv4.tcp_tw_recycle. Esse parâmetro foi descontinuado em versões mais recentes do Linux. Quando esse parâmetro está ativado, embora o TIME-WAIT possa ser recuperado mais rapidamente, novas conexões podem falhar ao serem estabelecidas normalmente. Por exemplo, quando várias máquinas internas acessam através de SNAT com diferenças de timestamp, podem ocorrer falhas de conexão e resets de solicitação.

Verifique se o valor desse parâmetro é 1. Se for 1, recomendamos alterá-lo para 0. Para detalhes, consulte Modify parameters.

Falha no upload de arquivo após integração ao WAF

Isso pode ocorrer porque o upload do arquivo excede o limite máximo de 2 GB. O WAF atualmente suporta uploads de arquivos de até 2 GB. Quando o corpo da solicitação excede 2 GB, o WAF retorna um código de status 413. Use o código de status retornado para determinar se o limite de tamanho de transferência de arquivo foi atingido.

Como atualize um certificado que está prestes a expirar?

O método de atualização varia dependendo do seu modo de integração:

Para integração CNAME, consulte Update a domain certificate.
Para integração de product cloud com instâncias ECS, consulte Update the certificate bound to an ECS traffic redirection port.
Para integração de product cloud com instâncias CLB, consulte Update the certificate bound to a CLB traffic redirection port.
Para integração de product cloud com instâncias NLB, consulte Update the certificate bound to an NLB traffic redirection port.
Para integração de product cloud com instâncias ALB, nenhuma atualização é necessária no console do WAF. Basta implantar o certificado na instância ALB a partir do console do Digital Certificate Management Service (antigo SSL Certificate). Para etapas, consulte Overview of SSL certificate deployment methods.

Após a integração de product cloud, o servidor de origem pode obter o IP real do cliente?

Sim. O WAF fornece o IP real do cliente diretamente à instância do product cloud.

Um conjunto de cifras fraco é relatado ao escanear um domínio integrado ao WAF. Como configure a versão do protocolo TLS e o conjunto de cifras para atender aos requisitos de segurança?

Para garantir que sites HTTPS integrados ao WAF atendam aos requisitos de segurança e conformidade, recomendamos configure protocolos TLS de versão alta e conjuntos de cifras fortes.

Importante

Protocolos TLS e conjuntos de cifras de alta segurança podem reduzir a compatibilidade do cliente. Após a configuração, usuários com clientes antigos (como Internet Explorer) podem não conseguir acesse o site. Avalie totalmente a compatibilidade do cliente antes de ative.

Etapa 1: Determinar o local de configuração

A entrada de configuração para a versão do protocolo TLS e conjunto de cifras depende do modo de integração do WAF.

Integração CNAME

No modo de integração CNAME, o local de configuração depende do alvo da varredura. configure-o no local correspondente com base no alvo específico da varredura.

Escanear o domínio integrado: Na aba CNAME Record, localize o domínio alvo e clique em Edit na coluna Actions. Na página Edit Domain Name, na seção Protocol Type > HTTPS, expanda Advanced Settings e localize TLS Version e HTTPS Cipher Suite.
Escanear o VIP do WAF: Na aba CNAME Record, clique em Default SSL/TLS Settings no lado direito, carregue o certificado padrão e configure TLS Version e HTTPS Cipher Suite.

Integração de product cloud

No modo de integração de product cloud, para instâncias ECS, instâncias CLB de camada 4 (protocolo de escuta tcp) e instâncias NLB, configure no lado do WAF. Para outros cenários de integração de product cloud, a configuração deve ser concluída nos respectivos consoles dos produtos.

Nota

Ao integrar uma instância CLB de camada 7 via integração de product cloud, conjuntos de cifras personalizados não são suportados. selecione apenas políticas de segurança TLS fornecidas pelo sistema.
Ao integrar uma instância ALB via integração de product cloud, se precisar personalizar o conjunto de cifras, crie manualmente uma política de segurança TLS. Para mais informações, consulte TLS security policy.

ECS, CLB de camada 4 (protocolo de escuta tcp), NLB: Na aba Cloud Native, localize a instância alvo, clique no ícone , selecione a porta alvo e clique em Actions na coluna Actions, depois selecione Modify. configure nos locais TLS Version e Cipher Suite.
ALB: No console ALB, após localizar a instância alvo, acesse a aba Listener, localize o listener alvo e configure a TLS Security Policy.
CLB de camada 7 (protocolo de escuta HTTPS): No console CLB, após localizar a instância alvo, acesse a aba Listener, localize o listener alvo, clique em Manage Certificates e configure a TLS Security Policy na caixa de diálogo que aparece.
FC, MSE, APIG, SAE: configure no console do product correspondente.

Etapa 2: Selecionar a versão do protocolo TLS

Para evitar riscos de segurança de versões antigas do protocolo TLS, recomendamos selecione TLS 1.2 ou posterior. Se o seu site suportar TLS 1.3, selecione Support TLS 1.3.

Ao selecione Support TLS 1.3, o WAF fornece os seguintes três conjuntos de cifras TLS 1.3 padrão: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 e TLS_CHACHA20_POLY1305_SHA256. Não é possível personalizar esses conjuntos de cifras.

Etapa 3: Selecionar o conjunto de cifras

Para evitar riscos de segurança de conjuntos de cifras fracos, recomendamos selecione conjuntos de cifras fortes da lista a seguir.

Conjuntos de cifras fortes	Conjuntos de cifras fracos
ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-AES256-SHA ECDHE-RSA-CHACHA20-POLY1305	AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-SHA256 AES256-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES256-SHA AES128-SHA AES256-SHA DES-CBC3-SHA ECDHE-RSA-RC4-SHA

Nota

Recomendações de segurança de conjunto de cifras: Os conjuntos de cifras ECDHE-RSA-AES128-SHA256 e ECDHE-RSA-AES256-SHA384 usam ECDHE para troca de chaves, RSA para autenticação e modo de criptografia AES-CBC. Comparados a conjuntos de cifras que usam modos de criptografia autenticada como AES-GCM, esses conjuntos oferecem menor segurança e desempenho. Algumas ferramentas de varredura de segurança podem identificá-los como conjuntos de cifras fracos. Se isso ocorrer, selecione conjuntos de cifras personalizados e exclua manualmente esses dois conjuntos.
Convenções de nomenclatura de conjunto de cifras: Como as convenções de nomenclatura diferem, o WAF exibe conjuntos de cifras no formato OpenSSL, enquanto algumas ferramentas de varredura podem usar o padrão IANA. Por exemplo, ECDHE-ECDSA-AES256-SHA384 em OpenSSL corresponde a TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 em IANA. Para consultar rapidamente o mapeamento, visite ciphersuite.info ou use outras ferramentas de consulta TLS.

Por que o campo upstream_addr mostra "-" nos logs após a integração?

Quando o campo upstream_addr nos logs mostra -, significa que o WAF não enviou uma solicitação de back-to-origin ao servidor de origem — por exemplo, quando a solicitação foi bloqueada pelo WAF. Recomendamos verificar outros campos, como upstream_status e upstream_response_time para análise adicional.

Por que solicitações bloqueadas pelo WAF ainda são registradas nos logs do ALB no modo cloud native?

No modo cloud native, o WAF 3.0 usa um SDK incorporado para integrar recursos de detecção de segurança diretamente no plano de dados do Application Load Balancer (ALB). Quando uma solicitação chega a uma instância ALB e entra no fluxo de processamento de dados, o ALB gera um log de acesso. Se o WAF bloquear a solicitação em seguida, ele retorna uma página de bloqueio ao cliente, e a solicitação não é encaminhada ao servidor backend. O registro do log de acesso não é revogado porque é gerado antes de o WAF bloquear a solicitação.

No modo cloud native, os certificados SSL precisam ser configurados tanto no WAF quanto na instância ECS de origem?

Sim. No modo cloud native, tanto o WAF quanto a instância ECS de origem devem ter um certificado SSL válido. Este modo não suporta uma configuração onde apenas o WAF possui um certificado. Para descarregar o SSL para o WAF, o que permite que o WAF se comunique com o servidor de origem via http, use o modo CNAME.