Proteger aplicações web contra ataques do OWASP Top 10 e zero-day

Uma equipe de segurança protege uma aplicação web voltada ao cliente que roda na sua própria origem, muitas vezes atrás de um WAF independente, de appliances ou de fornecedores separados de proteção contra bots e DDoS. Cada uma dessas ferramentas mantém a sua própria política, e a origem ainda responde a qualquer um que descubra o seu endereço. Esta página configura um firewall na frente da aplicação, que recusa redes listadas, pontua cada requisição com WAF e Bot Manager e faz a origem aceitar conexões só da Azion. O resultado é medido pelos ataques bloqueados antes da origem, pela taxa de falsos positivos no tráfego legítimo e pelo tempo para alterar uma política.

Este caso de uso não cobre o abuso específico de APIs, que Proteger APIs públicas contra abuso cobre, nem o account takeover, que Bloquear account takeover em fluxos de login e checkout cobre.

Pré-requisitos

• Uma application que serve a aplicação web por meio de um connector e de um workload. Para criá-los, consulte Primeiros passos com Applications.
• Um firewall vinculado ao deployment desse workload. Para vincular um, consulte Vincule um firewall a um workload.
• WAF e Functions ativados em Main Settings › Modules do firewall. Um firewall novo vem com WAF desativado. Para ativá-lo, consulte Defina as configurações principais de um firewall.
• Bot Manager Lite instalado pelo Azion Marketplace, ou Bot Manager habilitado na conta. Para instalar o Bot Manager Lite, consulte Instale o Bot Manager Lite.
• Acesso ao firewall da sua origem, onde fica a allowlist dos endereços da Azion.
• Um personal token, para as abas de API. Para criar um, consulte Gerencie personal tokens.
• Os valores da sua aplicação. Esta página usa www.example.com como domínio, 198.51.100.7 como um endereço que a sua equipe já bloqueia e webapp como prefixo de cada objeto que cria. Substitua cada valor pelo seu em todos os passos.

Produtos necessários

DDoS Protection mitiga ataques DoS e DDoS em todo workload, antes de qualquer regra de firewall rodar, sem nada para criar ou configurar. Para os tipos de ataque que cobre, consulte Mitigação de ataques.

Arquitetura de referência

Esta página constrói o perímetro de proteção de aplicações web e APIs (WAAP): uma política de firewall na frente do workload, com a origem fechada a qualquer outro caminho.

Leia o diagrama de cima para baixo. DDoS Protection age antes de qualquer regra, e as regras do firewall decidem então cada requisição em ordem. Network Shield, WAF e Bot Manager agem cada um só pela regra que os chama, então a ordem dessas regras é a ordem da política. Toda requisição que passa termina em um connector, e o próprio firewall da origem fecha qualquer outro caminho até ela. A aresta pontilhada carrega registros, não requisições: os eventos do WAF saem para o SIEM pelo Data Stream.

Fluxo de dados

1. A requisição de um visitante chega ao workload em www.example.com. DDoS Protection a avalia primeiro, e o firewall vinculado ao workload a recebe em seguida.
2. A primeira regra compara o endereço do cliente com a network list da equipe e com a lista de nós de saída do Tor. Um cliente listado recebe 403, e nenhuma regra seguinte roda.
3. A segunda regra entrega a requisição ao WAF rule set. Em Blocking, uma requisição cujo score atinge o threshold de uma família recebe 400.
4. A terceira regra executa a instância do Bot Manager em toda requisição que não é um asset estático. Um score no threshold executa a action da instância.
5. Uma requisição que nenhuma regra para chega à application, que a encaminha à origem pelo connector. O firewall da origem aceita a conexão porque ela vem de um prefixo de Azion Origin Shield, e recusa conexões de qualquer outro lugar.
6. Data Stream envia ao SIEM cada requisição que o WAF analisou. Real-Time Events guarda o registro de cada requisição para investigação, ligado a uma recusa pelo seu x-azion-request-id.

Componentes

• firewall: o Platform Resource que aplica a política. O deployment de um workload o nomeia, e ele roda as suas regras em toda requisição a esse workload antes que a application a veja.
• DDoS Protection: a Feature que mitiga ataques DoS e DDoS em todo workload, sempre ativa e sem nada para configurar. Ela age antes de qualquer regra de firewall.
• WAF: pontua cada requisição que uma regra Set WAF lhe entrega contra oito famílias de ameaças, e recusa a requisição no modo Blocking quando um score atinge o seu threshold. Ele filtra o OWASP Top 10 e outros padrões de ataque.
• Bot Manager: pontua cada requisição que uma regra Run Function lhe entrega em busca de sinais de automação, e executa a action que a sua instância define quando o score atinge o threshold.
• Network Shield: adiciona o critério Network, que compara o endereço do cliente com uma lista de endereços, ASNs ou países. Ele recusa fontes sabidamente maliciosas antes que WAF e Bot Manager as pontuem.
• application: o Platform Resource que entrega as requisições que o firewall deixa passar e as encaminha à origem.
• connector: o Platform Resource que alcança a origem. Toda requisição que passa pela política termina nele.
• Origin Shield: Origin IP ACL no connector publica a lista Azion Origin Shield com os prefixos da Azion, que o firewall da origem permite enquanto recusa qualquer outra fonte. Nenhum cliente consegue então alcançar a origem contornando a política.
• Data Stream: envia as requisições que o WAF analisou, com o seu score, as regras correspondidas e a action, a um endpoint que o SIEM lê.
• SIEM: a integração que correlaciona os eventos do firewall com as outras fontes de segurança da equipe.
• Real-Time Events: guarda o registro de cada requisição, com os seus campos de WAF, para que um bloqueio possa ser explicado a partir do request ID que o cliente informa.

Configure os bloqueios de rede

A regra de rede roda primeiro, então uma fonte em que a equipe já não confia é recusada antes que WAF e Bot Manager a pontuem. O WAF é cobrado pelas requisições que pontua, e o Bot Manager pelas requisições que avalia, então uma requisição que esta regra nega não custa nenhum dos dois. A regra lê duas listas. webapp-blocked-addresses guarda os endereços que a sua equipe bloqueia. Azion IP Tor Exit Nodes, a lista 2, é mantida pela Azion, então a regra também corresponde aos nós de saída que a Azion adicionar depois.

O comportamento é Deny (403 Forbidden) em vez de Drop. Um visitante negado vê uma página com um request ID que uma pessoa bloqueada por engano pode informar. Quando a lista recusar só os clientes que você espera, você pode mudar para Drop (Close Without Response).

Um cliente em qualquer uma das listas recebe 403 assim que a regra se propaga, o que leva de 6 a 10 minutos para uma regra nova. Uma alteração posterior nos itens de webapp-blocked-addresses chega ao tráfego em cerca de 100 segundos, sem alteração na regra.

Configure o WAF rule set

O rule set webapp-waf pontua cada requisição contra as oito famílias de ameaças na sensibilidade medium, o nível em que toda família começa. A regra que o aplica corresponde a ${request_uri} starts with /, o que corresponde a toda requisição. Um critério na query string deixaria de fora todo POST que carrega o seu payload no corpo.

A regra começa em Logging. Uma requisição que atinge um threshold é registrada e ainda é servida, e esses registros são a única descrição do seu tráfego como o rule set o vê. Mude a regra para Blocking quando 3 dias de Tuning não tiverem nenhuma requisição que deveria ter sido servida.

O rule set pontua toda requisição que a regra de rede deixa passar e registra o que teria sido bloqueado. Para ler esses registros e transformar um falso positivo em uma exceção, consulte Ajuste um WAF rule set. Para mudar a regra para Blocking, consulte Mude um rule set para blocking.

Configure a pontuação do Bot Manager

A instância do Bot Manager começa em modo de observação: action é allow, então ela não recusa nada, e internal_logs é 2, então toda requisição grava uma linha de report. Execute-a por 24 a 72 horas, tempo suficiente para cobrir os horários de pico, os crawlers semanais e os jobs noturnos. threshold é 18, o valor a partir do qual o Bot Manager documenta começar. Enquanto action for allow, o threshold só define o rótulo classified de cada linha. log_tag é webapp-observe, então cada linha nomeia esta instância.

A regra que executa a instância exclui os assets estáticos, porque uma imagem ou uma folha de estilo não é um cliente, e cada uma é uma requisição que o Bot Manager cobra. Ela não nomeia nenhum caminho, então todas as outras requisições da aplicação são pontuadas.

Crie a instância e a regra como Execute Bot Manager em caminhos selecionados descreve, com estes valores:

• Instância: webapp-bot-observe, com estes argumentos:

  { "threshold": 18, "action": "allow", "internal_logs": 2, "log_tag": "webapp-observe" }

• Regra: webapp - score page requests, com um bloco de critérios: a exclusão de assets estáticos, Request Uri does not match a expressão do guia. A regra não carrega nenhum bloco de caminhos.

• Comportamento: Run Function com webapp-bot-observe.

Toda requisição de página é pontuada e servida, e cada uma grava uma linha de report marcada com webapp-observe. Quando a janela fechar, leia os scores, defina threshold no intervalo entre os grupos legítimo e automatizado e defina action como deny. Para o procedimento, consulte Monitore e calibre o Bot Manager.

Configure a allowlist da origem

Origin IP ACL no connector dá à conta a network list Azion Origin Shield, que guarda todos os prefixos IPv4 e IPv6 que a infraestrutura da Azion usa para se conectar às origens. O firewall da sua origem permite então esses prefixos e nega qualquer outra fonte, para que um cliente que se conecta diretamente ao endereço da origem nunca alcance a aplicação contornando a política de firewall descrita nesta página.

A allowlist é o procedimento que Restrinja uma origem à Azion com Origin IP ACL descreve, executado no connector que alcança a origem da aplicação web. O firewall da origem guarda os prefixos IPv4 e IPv6 da lista e nega qualquer outra fonte.

Verifique a configuração

Espere as regras se propagarem antes de julgar um resultado: uma regra nova chega ao tráfego de 6 a 10 minutos depois de salva, e as respostas se alternam até ela se estabilizar. Repita cada requisição até a resposta se manter.

• Uma fonte listada é recusada antes da inspeção. A partir de um endereço em webapp-blocked-addresses, requisite a página inicial:

  curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/

  O comando imprime 403.

• O WAF pontua um padrão de ataque. A partir de um endereço que não está listado, envie uma query string com formato de injeção:

  curl -i "https://www.example.com/?q=1%27%20OR%20%271%27%3D%271"

  Em Logging, a aplicação responde como de costume. Depois da mudança para Blocking, a mesma requisição recebe:

  HTTP/2 400

  O x-azion-request-id da resposta encontra a requisição no dataset workloadEvents do Real-Time Events, onde wafMatch nomeia as regras internas que corresponderam, 1009 e 1013 para esta query string. Para a busca, consulte Encontre o score de uma requisição bloqueada.

• O Bot Manager pontua as requisições de página. Envie uma requisição sem user agent, que é o que um cliente com script envia:

  curl -A "" https://www.example.com/

  A requisição é servida, e o dataset functionConsoleEvents do Real-Time Events guarda uma linha que começa com [Bot-Protection][webapp-observe] Report:, com o seu score e matched_rules. Para a query, consulte Primeiros passos com Bot Manager.

• Os assets estáticos não são pontuados. Requisite um asset, como https://www.example.com/styles/main.css. Nenhuma linha de report marcada com webapp-observe aparece para ele.

• A origem recusa conexões diretas. A partir de um host fora da Azion, conecte-se ao próprio endereço da origem. O firewall da origem recusa a conexão, enquanto as requisições a www.example.com ainda alcançam a aplicação.

• Os eventos de segurança chegam ao SIEM. No Real-Time Events, a fonte de dados Data Stream lista cada envio do stream, e um Status Code 200 significa que o endpoint do SIEM aceitou o lote.

Medindo resultados

Boas práticas

• Coloque a regra de rede primeiro. O firewall roda as suas regras em ordem, e nenhuma regra seguinte roda para uma requisição que uma negação para. Uma fonte listada nunca chega então ao WAF ou ao Bot Manager, que cobram ambos pelas requisições que veem. Para a ordem das regras, consulte Como Firewall funciona.
• Altere uma lista, não uma regra, para uma fonte que muda com frequência. Uma alteração nos itens de uma lista chega ao tráfego em cerca de 100 segundos, uma regra nova em 6 a 10 minutos, e a lista não soma nada às regras que o seu plano inclui por firewall.
• Mantenha o critério da regra de WAF na URI da requisição. ${request_args} matches .* parece corresponder a toda requisição e deixa de fora toda requisição sem query string. ${request_uri} starts with / corresponde a todas, como em Corresponda à requisição, e não à query string dela.
• Eleve uma família de ameaças por vez. Elevar várias famílias de uma vez produz falsos positivos juntos, sem nada que diga qual elevação produziu qual bloqueio. Para os passos, consulte Eleve a sensibilidade de uma família de ameaças.
• Mantenha o IPv6 na allowlist da origem e atualize-a em até 7 dias. A lista carrega prefixos IPv6 para todo data center, e os servidores atrás de um prefixo novo entram em produção 7 dias depois que a Azion o publica. Uma allowlist que deixa de fora qualquer um dos dois recusa conexões que a Azion abre. Para a atualização, consulte Atualizações da lista.

Guias deste caso de uso