Este artigo lista problemas comuns que podem ocorrer ao integrar sites ao Web Application Firewall (WAF) 3.0.
Visão geral
-
Capacidades e consultas de configuração pré-onboarding
What is the difference between an origin IP address and a back-to-origin IP address in WAF?
Can the same domain use both cloud product onboarding and CNAME onboarding at the same time?
Does WAF protect multiple origin server IPs under a single domain?
Does WAF support cross-account use of CDN + Anti-DDoS Proxy + WAF architectures?
How does WAF obtain the client source IP and record the client IP through a custom header?
During CNAME onboarding, how does WAF load balance a domain-type origin (such as CNAME)?
The same domain name resolves to multiple cloud product instances. How should I onboard?
Multiple domain names resolve to the same cloud product instance. How should I onboard?
What domain name suffixes are supported for CNAME onboarding?
Does WAF support websites that use NTLM protocol authentication?
Is the WAF QPS limit applied to the entire WAF instance or to each domain individually?
Does a purchased WAF instance support smooth migration to another Alibaba Cloud account?
-
Problemas que podem ocorrer durante o onboarding
How to view the WAF back-to-origin IP ranges and the CNAME provided by WAF?
For the origin IP address in WAF, should I use the public or private IP of an ECS instance?
Why does adding multiple extended certificates fail during cloud product onboarding?
After onboarding a cloud product to WAF, do I still need to configure protected objects?
Why does the error InvalidTLS occur when onboarding a CLB instance via cloud product onboarding?
-
Problemas que podem ocorrer após o onboarding
How to batch export the list of domain information that has been onboarded via CNAME?
After cloud product onboarding, can the origin server get the real client IP?
My website is protected by WAF, but it doesn't appear in the domain list
Why does the upstream_addr field show "-" in logs after onboarding?
Qual é a diferença entre um endereço IP de origem e um IP de back-to-origin no WAF?
-
IP de back-to-origin do WAF: Faixa de IP que o WAF utiliza para encaminhar o tráfego protegido ao servidor de origem. Esses IPs são alocados pela Alibaba Cloud e identificam o WAF como a source das requisições ao seu servidor de origem.
A faixa de IP de back-to-origin é, normalmente, um conjunto fixo de endereços IP.
Do ponto de vista do servidor de origem, todas as requisições de clientes são interceptadas e encaminhadas pelo WAF. O IP real do cliente é 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 hospeda seu negócio, ou o endereço IP resolvido a partir do seu domínio. Esse é o destino que, em última instância, recebe as requisições e retorna as respostas quando os usuários acessam o site.
Um IP de origem pode ser um único endereço IP ou múltiplos endereços IP (com suporte a balanceamento de carga).
O IP de origem é o endereço real do service do seu site, que pode estar implantado em ECS, SLB, OSS da Alibaba Cloud ou em outro provedor de cloud.
O mesmo domínio pode usar onboarding por cloud product e por CNAME simultaneamente?
Não é recomendado. Cada domínio só pode utilizar um modo de onboarding — onboarding por cloud product ou onboarding por CNAME. Integrar o mesmo domínio duas vezes causa conflitos de encaminhamento e desabilita a proteção. Se for necessário migrar um domínio já protegido pelo WAF via CNAME para onboarding por cloud product, primeiro exclua a configuração de onboarding por CNAME desse domínio e depois integre-o novamente no modo de cloud product.
O WAF protege múltiplos IPs de servidor de origem em um único domínio?
Sim. É possível configurar até 20 endereços IP de origem para um único domínio no WAF.
O WAF realiza verificações de integridade nos servidores de origem?
O WAF habilita verificações de integridade por padrão, checando a acessibilidade de todos os IPs de origem. Se um IP de origem deixar de responder, o WAF encaminha as requisições para os demais IPs de origem íntegros.
Quando um IP de origem fica indisponível, o WAF define automaticamente um período de silêncio para esse IP. Após o término do período de silêncio, novas requisições ainda podem ser encaminhadas a ele para teste.
Um IP exclusivo no WAF pode mitigar ataques DDoS?
Um IP exclusivo evita que um ataque DDoS de alto volume direcionado a um domínio torne todos os demais domínios integrados inacessíveis. Para mais informações, consulte Value of exclusive IP addresses.
O WAF pode ser integrado com CDN ou Anti-DDoS Proxy?
O WAF é totalmente compatível com os serviços CDN e Anti-DDoS Proxy. Ao utilizá-los em conjunto, basta configurar o endereço CNAME do WAF como origem do Anti-DDoS Proxy ou CDN. Dessa forma, o tráfego é encaminhado pelo Anti-DDoS Proxy ou CDN ao WAF e, em seguida, do WAF ao servidor de origem, proporcionando segurança abrangente para sua infraestrutura. 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 de arquiteturas CDN + Anti-DDoS Proxy + WAF entre contas diferentes?
Sim. É possível utilizar CDN, Anti-DDoS Proxy e WAF em contas diferentes da Alibaba Cloud para construir 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 enviados? O WAF descriptografa o tráfego HTTPS e registra o conteúdo das requisições?
Ao proteger tráfego HTTPS, o Alibaba Cloud WAF exige o upload do certificado SSL e da chave privada correspondentes para descriptografar o tráfego HTTPS e detectar assinaturas de ataque. Utilizamos um Key Server dedicado para armazenar e gerenciar certificados e chaves. Esse Key Server é baseado no Alibaba Cloud Key Management Service (KMS), garantindo a segurança dos dados, a integridade e a 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 enviados para descriptografar o tráfego HTTPS exclusivamente para detecção em tempo real. Registramos apenas as partes das requisiçõ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 requisições ou respostas sem sua autorização.
O Alibaba Cloud WAF obteve diversas certificações internacionais reconhecidas, 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 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 de 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 não compatível com os requisitos de onboarding, e o WAF o removeu automaticamente. Conclua o registro ICP do domínio e integre-o novamente ao WAF. Para informações sobre o registro ICP da Alibaba Cloud, consulte ICP filing process.
Antes de integrar seu site a uma instância do WAF na China continental, certifique-se de que o domínio possui um registro ICP válido. Para cumprir as leis e regulamentações 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, para impedir que invasores falsifiquem o campo XFF e contornem as regras de detecção do WAF — melhorando a segurança do negócio —, utilize um cabeçalho personalizado para transportar o IP do cliente. Insira 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 utilizará o valor do campo de cabeçalho especificado como IP de origem do cliente. Se você configurar múltiplos campos de cabeçalho, o WAF tentará ler o IP do cliente na ordem em que foram definidos.
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 insira o IP do cliente em um cabeçalho personalizado na requisição. O servidor backend poderá então ler o IP do cliente a partir do campo de cabeçalho especificado na requisição de back-to-origin. Isso se aplica a cenários em que o servidor backend precisa obter o IP do cliente a partir de um cabeçalho personalizado específico para análise de negócios.
Qual é a diferença entre Anti-DDoS e WAF Protection em uma instância ALB? Devo ativar ambos?
Web Application Firewall (WAF) e proteção Anti-DDoS são dois recursos de segurança independentes e complementares. As diferenças principais são as seguintes:
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 ativar essa proteção, atualize a 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 oferecem proteção Anti-DDoS básica e gratuita por padrão. Se o tráfego de ataque exceder o limiar de blackhole, adquira e associe 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 enfrentados pela sua aplicação. Para uma defesa em profundidade abrangente nas camadas de rede e aplicação, ative ambos os recursos de proteção.
O WAF suporta onboarding para protocolo TCP de camada 4?
O WAF suporta a ativação de proteção WAF para tráfego de protocolos HTTP e HTTPS escutados por portas de instâncias CLB (TCP) de camada 4 e instâncias ECS. Não há suporte para encaminhamento e proteção de tráfego em portas que utilizam outros protocolos não HTTP/HTTPS.
Como firewall de aplicação web, o WAF protege primariamente 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 instância ECS é tráfego web, o WAF pode fornecer proteção de encaminhamento. No entanto, se a instância de cloud product de camada 4 transporta tráfego de outros protocolos de camada de aplicação (como FTP, SMTP, etc.), o WAF não consegue 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.
No onboarding via CNAME, como o WAF faz o balanceamento de carga de uma origem do tipo domínio (como CNAME)?
No modo de onboarding via CNAME, quando sua origem possui múltiplos endereços de servidor, é possível selecionar diferentes opções de Load Balancing Algorithm para que o WAF encaminhe as requisições de back-to-origin aos servidores correspondentes, realizando o balanceamento de carga.
Quando Server Address está definido como Domain Name (Such as CNAME), se a resolução desse domínio retornar múltiplos endereços IP, o WAF distribui as requisições dos clientes entre os IPs resolvidos. Ao inserir múltiplos domínios, o WAF expande todos os resultados de resolução e distribui o tráfego entre eles.
Porém, se você inserir apenas um domínio e cada resolução retornar apenas um endereço IP, o WAF não realiza balanceamento de carga — apenas encaminha o back-to-origin para o único resultado resolvido.
O mesmo nome de domínio resolve para múltiplas instâncias de cloud product. Como devo integrar?
Usar onboarding por cloud product: integre todas essas instâncias de cloud product simultaneamente (por exemplo, as portas de service de uma instância CLB) para que o WAF redirecione o tráfego para todas elas.
Usar onboarding via CNAME: após integrar o domínio via CNAME, todas as instâncias de cloud product são protegidas pela política de proteção padrão do WAF.
Múltiplos nomes de domínio resolvem para a mesma instância de cloud product. Como devo integrar?
Usar onboarding por cloud product: após integrar a instância de cloud product, todos os domínios dessa instância são automaticamente protegidos pela política padrão do WAF. No entanto, se você quiser configurar regras de proteção separadas para domínios individuais, adicione manualmente cada domínio como objeto protegido. Para detalhes, consulte Manually add a protected object.
Usar onboarding via CNAME: integre cada domínio individualmente.
Quais sufixos de nome de domínio são suportados para onboarding via CNAME?
O WAF 3.0 suporta a maioria dos sufixos de nome de domínio, incluindo sufixos de domínio chineses. Para a lista completa de sufixos chineses suportados, consulte iana.org.
O WAF 3.0 suporta mais sufixos de domínio do que o WAF 2.0. Se um sufixo de domínio não for suportado no WAF 2.0, recomendamos a atualização para o WAF 3.0.
O WAF suporta autenticação mútua HTTPS (mTLS)?
O onboarding via CNAME e o onboarding transparente não suportam autenticação mútua HTTPS. A solução de onboarding baseada em service do WAF 3.0 oferece esse suporte. Atualmente, os cloud products compatíveis com onboarding baseado em service incluem ALB, MSE, FC e SAE. Essa configuração pode ser feita na seção de onboarding de cloud product do console do WAF.
O WAF suporta os protocolos WebSocket, HTTP/2 ou SPDY?
Protocolo WebSocket: O encaminhamento de tráfego é suportado. Não há proteção de segurança.
Protocolo HTTP/2: Escuta e back-to-origin são suportados.
Protocolo SPDY: Não suportado.
Para impedir que invasores utilizem HTTP/2 cleartext smuggling (h2c) para contornar o WAF, crie uma regra personalizada para interceptar requisições em que 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 utilizam autenticação por protocolo NTLM?
Não. Se um site utiliza autenticação por protocolo NTLM, as requisições de acesso encaminhadas pelo WAF podem falhar na autenticação NTLM no servidor de origem, causando solicitações de autenticação repetidas no cliente. Recomendamos utilizar um método de autenticação diferente para o seu site.
O limite de QPS do WAF se aplica à instância inteira ou a cada domínio individualmente?
O limite de QPS do WAF se aplica à instância inteira do WAF.
Por exemplo, se você configurar três domínios em uma instância do WAF, o QPS combinado deles não poderá exceder o limite especificado. Se o QPS ultrapassar 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 deixa de garantir conformidade com o Acordo de Nível de Serviço (SLA).
Uma instância WAF adquirida permite migração transparente para outra conta Alibaba Cloud?
Instâncias WAF não permitem migração direta e transparente para outras contas Alibaba Cloud. Caso precise utilizar o WAF entre contas diferentes, adote uma das soluções alternativas a seguir:
Cancelar assinatura e readquirir: cancele a assinatura para liberar a instância WAF na conta atual e, em seguida, adquira uma nova instância na conta de destino.
Gerenciamento unificado de múltiplas contas: utilize o recurso Multi-account management para gerenciar a conta de destino dentro do sistema WAF da conta atual.
Como visualizar os intervalos de IP de retorno à origem do WAF e o CNAME fornecido pelo WAF?
Os intervalos de IP de retorno à origem do WAF e os endereços CNAME fornecidos pelo WAF para cada domínio integrado podem ser encontrados no local indicado na figura a seguir, na página da lista de integração.
Solução de problemas quando a instância CLB, NLB ou ECS desejada 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 mais 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. |
|
O WAF ainda não sincronizou a instância CLB, NLB ou ECS. | Para saber como sincronizar ativos manualmente, 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 dessa 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 por meio do Alibaba Cloud Certificate Management Service (Original SSL Certificate) e não foi carregado no Alibaba Cloud Certificate Management Service (Original SSL Certificate).
O certificado do listener HTTPS na instância CLB foi carregado pelo console do CLB. No entanto, esse método de upload não sincroniza automaticamente as informações do certificado com o Digital Certificate Management Service (anteriormente SSL Certificate Management). Como o WAF obtém as informações de certificado apenas do Digital Certificate Management Service, a mensagem certificate is incomplete é exibida.
Um certificado anteriormente 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 ver os passos, consulte Upload an SSL certificate.
No console do CLB, crie um certificado e selecione certificados emitidos pela Alibaba Cloud como source de certificado. Para ver os passos, consulte Use a certificate from Alibaba Cloud SSL Certificates Service.
No console do CLB, selecione o certificado de servidor carregado. Para ver os passos, 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 retorno à origem pela rede pública e não oferece suporte a endereços IP privados.
Por que a adição de múltiplos certificados estendidos falha durante a integração de cloud product?
Uma causa possível é um dos certificados estar inválido. Ao adicionar múltiplos certificados estendidos, certifique-se de que cada certificado selecionado seja válido. Certificados expirados causam falha na adição.
Após integrar um cloud product ao WAF, ainda é necessário configurar objetos protegidos?
Por padrão, após a integração de um cloud product ao WAF, o sistema gera automaticamente um objeto protegido, sem necessidade de configuração adicional. Entretanto, se múltiplos domínios resolvem para a mesma instância de cloud product e você deseja configurar regras de proteção separadas para cada domínio, adicione cada domínio manualmente como objeto protegido. Para mais detalhes, consulte Add a protected object.
Após adicionar os objetos protegidos, selecione o domínio correspondente como objeto efetivo ao configurar as regras de proteção, garantindo proteção granular para múltiplos domínios.
Durante a integração via CNAME, por que o erro ERR_TOO_MANY_REDIRECTS aparece após configurar o retorno à origem via HTTP?
Retorno à origem via HTTP significa que o WAF utiliza o protocolo HTTP para encaminhar as requisições de retorno à origem ao servidor de origem, com a porta padrão de retorno à origem sendo 80. Após ativar esse recurso, independentemente de o cliente acessar o WAF pela porta 80 ou 443, o WAF usa por padrão o protocolo HTTP e a porta 80 para o retorno à origem. Se a porta 80 no servidor de origem não possui nenhum serviço real, ativar esse recurso causa problemas de acesso ao site.
Caso a porta 80 no servidor de origem não tenha serviço real e exista 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 entra em loop de redirecionamento contínuo, gerando o erro ERR_TOO_MANY_REDIRECTS.
Por que o erro InvalidTLS ocorre ao integrar uma instância CLB via integração de cloud product?
Ao integrar uma instância CLB via integração de cloud product, 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 oferece suporte à 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 de realizar a integração de cloud product. Para mais informações, consulte CLB instance types.
O IP público do meu servidor de origem está exposto. Como impedir que invasores ignorem o WAF atacando diretamente o IP público de origem?
Método 1: No modo de integração via CNAME, configure o servidor de origem para aceitar tráfego exclusivamente dos intervalos de IP de retorno à origem do WAF, garantindo que apenas o WAF consiga se comunicar com o servidor de origem. Para mais detalhes, consulte Allow WAF back-to-origin IP ranges.
Método 2: Utilize a integração via cloud product.
Múltiplos cenários de erros 502 após integração ao WAF
Sintoma
Após a integração ao WAF, o acesso ao service de backend retorna código de status 502, ou os logs exibem requisições com código de status 502.
Causas e soluções
Cenário 1: 502 no modo de integração via CNAME
Cenário 2: 5XX intermitente com CLB de camada 7 no modo de integração via cloud product
Análise detalhada da causa
Timeout de inatividade da conexão de retorno à origem do WAF: 3.600 segundos (1 hora)
-
Descrição: Quando a conexão entre o CLB e o WAF fica sem transmissão de dados por 1 hora, o WAF fecha a conexão automaticamente.
Timeout de inatividade da conexão voltada ao cliente do CLB: 15 segundos
-
Descrição: Quando a conexão entre o cliente (instância WAF neste caso) e o CLB fica sem transmissão de dados por 15 segundos, o CLB fecha a conexão automaticamente.
Em casos extremos, no exato 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 requisição de retorno à origem ao CLB. Como o CLB não possui mais o estado da conexão, ele envia um pacote RST para encerrar a requisição. Isso resulta em um registro 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 cloud product do CLB de camada 7 para um valor menor que o timeout de inatividade da conexão voltada ao cliente do CLB — por exemplo, 14 segundos.
Cenário 3: 502 intermitente devido a URI excessivamente longa
Cenário 4: 502 intermitente quando o WAF envia requisições de retorno à origem para múltiplos CLBs de camada 4
Arquitetura de rede atual 
Na arquitetura atual, o WAF é integrado no modo reverse proxy com retorno à origem para múltiplas instâncias CLB de camada 4. O RealServer (RS) de 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 de backend para múltiplas instâncias CLB de camada 4 (protocolo TCP) configuradas com a mesma porta de service de backend, os seguintes problemas podem ocorrer: se requisições do mesmo nó WAF forem enviadas simultaneamente para as instâncias CLB usando o mesmo endereço IP do nó da instância WAF, algumas conexões podem falhar ou expirar.
Caso 1: conflito de 5-tupla, colisão de stream TCP
Quando o WAF protege múltiplos nós CLB, as requisições desses nós podem se originar do mesmo endereço IP de retorno à origem do WAF.
Quando o nó WAF envia requisições de retorno à origem para o CLB1, a conexão (WIP:CPORT->VIP1:VPORT1) é convertida em (WIP:CPORT->DIP:DPORT) ao chegar ao ECS de backend.
Quando o nó WAF envia requisições de retorno à origem para o CLB2, a conexão (WIP:CPORT->VIP2:VPORT2) também é convertida em (WIP:CPORT->DIP:DPORT) ao chegar ao ECS de backend.
Como os números de sequência e estados das duas conexões TCP entram em conflito no servidor de 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 de backend. Esse conflito de 5-tupla pode fazer com que pacotes SYN sejam descartados.
Caso 2: erros de roteamento de pacotes de resposta
Em um caminho completo de requisição, o nó CLB que inicia a requisição difere do nó CLB que recebe o pacote de resposta.
O WAF envia o pacote SYN de retorno à origem através do CLB2, com a 5-tupla WIP:CPORT->VIP1:VPORT1. Ao chegar ao ECS2 de backend, é convertido em WIP:CPORT->DIP:DPORT.
Se o ECS2 possui uma conexão TIME-WAIT nesse momento com a 5-tupla TCP:WIP:CPORT:DIP:DPORT, ao receber o pacote SYN do passo 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 possui uma sessão para essa 5-tupla, o CLB1 envia um pacote Reset bidirecional, fazendo o WAF retornar 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 de balanceador de carga CLB de camada 4 diferentes encaminhem requisições para a mesma porta no mesmo service de backend.
Solução 2
Migre do CLB para o NLB e desative Client IP Affinity na configuração do NLB para resolver o conflito de 5-tupla. Implante o Proxy Protocol no service de backend para obter o IP real do cliente. Para mais detalhes, consulte Use Proxy Protocol.
Passos
Faça login no Network Load Balancer (NLB) console.Na barra de navegação superior, selecione a região onde a instância NLB está implantada.
No painel de navegação à esquerda, escolha .
Selecione o grupo de servidores e, na coluna Actions, clique em Modify Basic Information. Na caixa de diálogo Modify Basic Information, desative Client IP Preservation e salve as alterações.
Solução 3 (Não recomendada)
Abra um Tickets para ativar o modo FULLNAT. Quando múltiplas instâncias CLB encaminham requisições para a mesma porta no mesmo servidor de 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 de 502 nas requisições
Upload de arquivo falha após integração ao WAF
Isso pode ocorrer porque o upload de arquivo excede o limite máximo de 2 GB. Atualmente, o WAF suporta uploads de arquivo de até 2 GB. Quando o corpo da requisição excede 2 GB, o WAF retorna um código de status 413. Utilize o código de status retornado para determinar se o limite de tamanho de transferência de arquivo foi atingido.
Como atualizar um certificado prestes a expirar?
O método de atualização varia conforme o modo de integração:
Para integração via CNAME, consulte Update a domain certificate.
Para integração via cloud product com instâncias ECS, consulte Update the certificate bound to an ECS traffic redirection port.
Para integração via cloud product com instâncias CLB, consulte Update the certificate bound to a CLB traffic redirection port.
Para integração via cloud product com instâncias NLB, consulte Update the certificate bound to an NLB traffic redirection port.
Para integração via cloud product com instâncias ALB, não é necessário atualizar no console do WAF. Basta implantar o certificado na instância ALB a partir do console do Digital Certificate Management Service (formerly SSL Certificate). Para ver os passos, consulte Overview of SSL certificate deployment methods.
Após a integração via cloud product, o servidor de origem consegue obter o IP real do cliente?
Sim. O WAF fornece o IP real do cliente diretamente para a instância de cloud product.
Um conjunto de cifras fraco é reportado ao escanear um domínio integrado ao WAF. Como configurar 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 configurar versões mais recentes do protocolo TLS e conjuntos de cifras fortes.
Protocolos TLS e conjuntos de cifras de alta segurança podem reduzir a compatibilidade com clientes. Após a configuração, usuários com clientes antigos (como o Internet Explorer) podem não conseguir acessar o site. Avalie completamente a compatibilidade dos clientes antes de ativar essa configuração.
Etapa 1: Determinar o local da configuração
A entrada de configuração da versão do protocolo TLS e do conjunto de cifras depende do modo de integração ao WAF.
CNAME onboarding
No modo de integração via CNAME, o local da configuração depende do alvo da varredura. Configure no local correspondente de acordo com o alvo específico da varredura.
Escanear o domínio integrado: Na aba CNAME Record, localize o domínio desejado 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, faça o upload do certificado padrão e configure TLS Version e HTTPS Cipher Suite.
Cloud product onboarding
No modo de integração via cloud product, para instâncias ECS, instâncias CLB de camada 4 (protocolo de escuta TCP) e instâncias NLB, a configuração é feita no lado do WAF. Para os demais cenários de integração via cloud product, a configuração deve ser concluída nos respectivos consoles de cada product.
Ao integrar uma instância CLB de camada 7 via cloud product onboarding, conjuntos de cifras personalizados não são suportados. Só é possível selecionar políticas de segurança TLS fornecidas pelo sistema.
Ao integrar uma instância ALB via cloud product onboarding, caso precise personalizar o conjunto de cifras, é necessário criar 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 desejada, clique em no ícone
, selecione a porta desejada e clique em Actions na coluna Actions, depois selecione Modify. Configure nos campos TLS Version e Cipher Suite.ALB: No console do ALB, após localizar a instância desejada, acesse a aba Listener, localize o listener desejado e configure a TLS Security Policy.
CLB de camada 7 (protocolo de escuta HTTPS): No console do CLB, após localizar a instância desejada, acesse a aba Listener, localize o listener desejado, clique em Manage Certificates e configure a TLS Security Policy na caixa de diálogo exibida.
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 decorrentes de versões antigas do protocolo TLS, recomendamos selecionar TLS 1.2 ou posterior. Se o seu site oferece suporte ao TLS 1.3, selecione Support TLS 1.3.
Ao selecionar Support TLS 1.3, o WAF disponibiliza os três conjuntos de cifras padrão do TLS 1.3: 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 decorrentes de conjuntos de cifras fracos, recomendamos selecionar conjuntos de cifras fortes da lista a seguir.
Conjuntos de cifras fortes | Conjuntos de cifras fracos |
|
|
Recomendações de segurança para conjuntos de cifras: Os conjuntos de cifras ECDHE-RSA-AES128-SHA256 e ECDHE-RSA-AES256-SHA384 utilizam ECDHE para troca de chaves, RSA para autenticação e o modo de criptografia AES-CBC. Em comparação com conjuntos de cifras que utilizam modos de criptografia autenticada como AES-GCM, esses conjuntos oferecem segurança e desempenho inferiores. Algumas ferramentas de varredura de segurança podem identificá-los como conjuntos de cifras fracos. Caso isso ocorra, selecione conjuntos de cifras personalizados e exclua manualmente esses dois conjuntos.
Convenções de nomenclatura de conjuntos de cifras: Como as convenções de nomenclatura diferem entre padrões, o WAF exibe os conjuntos de cifras no formato OpenSSL, enquanto algumas ferramentas de varredura podem usar o padrão IANA. Por exemplo, ECDHE-ECDSA-AES256-SHA384 no OpenSSL corresponde a TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 no padrão IANA. Para consultar rapidamente o mapeamento, visite ciphersuite.info ou utilize outras ferramentas de consulta TLS.
Por que o campo upstream_addr exibe "-" nos logs após a integração?
Quando o campo upstream_addr nos logs exibe -, isso significa que o WAF não enviou uma requisição de retorno à origem para o servidor de origem — por exemplo, quando a requisição foi bloqueada pelo WAF. Recomendamos verificar outros campos como upstream_status e upstream_response_time para uma análise mais aprofundada.
Por que requisições bloqueadas pelo WAF ainda aparecem nos logs do ALB no modo cloud native?
No modo cloud native, o WAF 3.0 utiliza um SDK integrado para incorporar recursos de detecção de segurança diretamente no plano de dados do Application Load Balancer (ALB). Quando uma requisiçã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 requisição em seguida, ele retorna uma página de bloqueio ao cliente, e a requisição não é encaminhada ao servidor backend. O registro do log de acesso não é revogado porque foi gerado antes do bloqueio pelo WAF.
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 possuir um certificado SSL válido. Esse modo não suporta uma configuração em que apenas o WAF possua certificado. Para descarregar o SSL no WAF — permitindo que o WAF se comunique com o servidor de origem via HTTP — é necessário utilizar o modo CNAME.