Como Firewall funciona

Uma requisição a um site ou a uma API pode ser recusada antes que qualquer código da aplicação seja executado. Um ponto de controle na frente da aplicação lê o que a requisição carrega: o endereço de onde ela vem, o caminho que ela pede e os headers que ela envia. Ele compara esses dados com condições que você escreveu, e uma requisição que atende a uma delas recebe a ação que você associou a essa condição. Uma requisição que não atende a nenhuma segue até a aplicação sem alteração.

Na Azion, esse ponto de controle é um firewall, uma instância do recurso da plataforma Firewall. Um workload vincula um firewall pelo seu deployment, então toda requisição ao workload atravessa o firewall antes da aplicação por trás dele. As condições e as ações são as regras de Rules Engine para Firewall, e cada regra associa critérios a comportamentos. Três produtos ampliam o que uma regra pode decidir. Web Application Firewall (WAF) pontua uma requisição contra padrões de ataque conhecidos, e Network Shield compara o endereço do cliente dela com uma lista. Bot Manager avalia se o cliente por trás da requisição é um script ou uma pessoa.

Esta página cobre os mecanismos, não os campos: cada critério, operador e comportamento está em Rules Engine para Firewall, e cada limite está em Limites de Firewall. As seções seguem o caminho que uma requisição percorre, como as regras são executadas e o que o cliente recebe. Depois cobrem os produtos habilitados em um firewall, as funções em um firewall, a propagação e a observabilidade. WAF, Network Shield e Bot Manager fecham a página, nessa ordem.

O caminho que uma requisição percorre

Um firewall não inspeciona nada até que um workload o nomeie. O vínculo fica no deployment do workload, não no firewall nem no registro do workload. No Azion Console, ele é o campo Firewall de Deployment Settings, e na API é o strategy.attributes.firewall do deployment. azion create workload-deployment o recebe como --firewall-id. O mesmo deployment nomeia a aplicação, então o firewall e a aplicação sempre andam juntos.

Um firewall não tem domínio próprio. Ele inspeciona as requisições de todo workload cujo deployment o nomeia, e um firewall que nenhum deployment nomeia não inspeciona nenhuma requisição.

Este diagrama acompanha uma requisição, do workload que ela alcança até a resposta que ela recebe:

1. Uma requisição alcança um workload. O firewall que o deployment do workload nomeia recebe a requisição antes da aplicação.
2. O firewall executa as suas regras em ordem e, para cada regra, compara os critérios da regra com a requisição.
3. Uma regra cujos critérios não correspondem não executa nada, e o firewall passa para a próxima regra.
4. Uma regra cujos critérios correspondem executa os seus comportamentos, na ordem em que estão organizados.
5. Um comportamento que interrompe a requisição, como uma negação, responde ao cliente, e nenhuma regra posterior é executada para essa requisição.
6. Uma requisição que nenhuma regra interrompe alcança a aplicação por trás do workload.

A recusa acontece no firewall, então a aplicação nunca recebe uma requisição que uma regra interrompe. Por exemplo, uma regra que nega uma lista de endereços responde 403 a cada um deles, e a aplicação não vê nenhuma dessas requisições. O preço é que a ordem decide. A primeira regra que interrompe uma requisição a resolve, então a posição de uma regra importa tanto quanto o que ela diz. Um firewall pode servir aos deployments de vários workloads, e uma mudança nas suas regras alcança, então, todos eles.

Como as regras são executadas

Uma regra associa critérios, as condições que uma requisição precisa atender, a comportamentos, as ações tomadas quando ela as atende. Os critérios ficam em blocos. Dentro de um bloco, o primeiro critério começa com if, e cada um dos seguintes se junta a ele com and ou or. Quando os critérios correspondem à requisição, a regra executa os seus comportamentos na ordem em que estão organizados e, quando não correspondem, a regra não executa nada. Para cada critério, operador e comportamento, consulte Rules Engine para Firewall.

Ordem das regras

Um firewall executa as suas regras em sequência até que uma delas bloqueie ou restrinja a requisição, ou até que todas as regras tenham sido executadas. Cada regra carrega um order, que a API atribui na ordem de criação a partir de 0, e a lista Rules Engine no Azion Console pode ser reordenada. Um comportamento como Deny (403 Forbidden) encerra a execução das regras: nenhum comportamento posterior e nenhuma regra posterior são executados para essa requisição.

A ordem, portanto, muda resultados que as regras sozinhas não mostram. Por exemplo, uma regra que aplica um rate limit a um caminho de login nunca conta as requisições que uma regra anterior nega, porque essas requisições nunca chegam a ela.

A ordem das regras também define a ordem em que as proteções do firewall agem sobre uma requisição. DDoS Protection age primeiro: avalia se cada requisição traz um ataque DoS ou DDoS e a bloqueia ou a permite antes que qualquer regra seja executada. WAF, Network Shield, Bot Manager e as funções não têm uma ordem fixa própria, porque cada um age apenas por meio de uma regra. Network Shield age pelo critério Network de uma regra, WAF por Set WAF, e Bot Manager e as demais funções por Run Function. Eles agem, portanto, na ordem das regras que os chamam, e nenhum deles age sobre uma requisição que uma regra anterior interrompeu. Dentro de uma regra, Set WAF e Run Function são executados na ordem em que a regra os organiza.

Uma regra pertence ao firewall em que foi criada, e a API a mantém em /v4/workspace/firewalls/<firewall-id>/request_rules desse firewall. Uma regra, portanto, não pode ser compartilhada com outro firewall. Para começar um firewall a partir das regras de outro, clone-o: a lista Firewalls no Azion Console oferece Clone em cada linha. A API descreve um clone como uma cópia profunda do firewall, incluindo as instâncias de função e as regras do Rules Engine dele.

Comportamentos que encerram a lista

A maioria dos comportamentos não pode ser seguida por outro na mesma regra. Apenas Run Function e Set WAF podem ser seguidos por outro comportamento, e Azion Console oferece cada um deles uma vez por regra. Escolher Deny (403 Forbidden), Drop (Close Without Response), Set Rate Limit ou Set Custom Response remove todo comportamento depois dele. Uma regra que executa uma função e depois nega a requisição é, portanto, válida, e uma regra que nega e depois executa uma função não é.

Um comportamento que define uma resposta não se acumula entre regras. Quando os critérios de várias regras que carregam Set Custom Response são atendidos, apenas o da última dessas regras é executado.

Rate limits

Set Rate Limit conta requisições por segundo ou por minuto, conforme define o seu campo Rate Limit Type. O seu campo Limit By as conta por endereço IP do cliente ou entre todos os clientes. A contagem pertence à regra. Uma regra cujos critérios correspondem a mais de uma URI por meio de or compartilha um único rate limit entre todas elas. Um limite separado para cada URI exige, portanto, uma regra para cada URI. A Azion aplica a taxa configurada em cada data center, com um algoritmo leaky bucket.

Uma requisição que excede a taxa não é recusada imediatamente. O Maximum Burst Size define quantas requisições simultâneas entram em fila e são liberadas na taxa configurada, e ele se aplica apenas a uma taxa por segundo. Por exemplo, com uma taxa de uma requisição por segundo e um burst de um, requisições enviadas uma após a outra são retidas por cerca de um segundo cada e depois servidas. Apenas requisições que chegam ao mesmo tempo, além do burst, recebem 429.

Nenhum header de rate limit volta em nenhuma resposta, seja a requisição servida ou recusada. Um cliente, portanto, não tem sinal de quanto tempo esperar antes de tentar de novo. Para os campos e os intervalos de valores deles, consulte Set Rate Limit.

O que o cliente recebe

O comportamento que interrompe uma requisição decide o que o cliente recebe, e uma requisição que nenhuma regra interrompe recebe a resposta da aplicação. Esta tabela lista o que cada resultado retorna:

Uma requisição descartada chega ao curl como um erro, não como um status:

Um script que lê o status code com curl recebe 000, e um navegador mostra um erro de conexão em vez de uma página da Azion. O firewall fecha uma requisição descartada cerca de 0,15 segundo depois que o TLS termina, não por timeout, então um 000 em uma fração de segundo indica um descarte, e não uma falha de rede.

Negar e descartar diferem no que o cliente fica sabendo. Uma negação diz ao cliente que ele foi recusado, e a página de erro dela mostra um request ID que uma pessoa bloqueada por engano pode reportar. Um descarte não diz nada ao cliente. Isso deixa um cliente automatizado sem status a que reagir, e deixa uma pessoa bloqueada por engano sem nada para reportar.

Produtos habilitados em um firewall

Um firewall decide com os critérios e os comportamentos que os seus produtos habilitados disponibilizam. No Azion Console, as Main Settings do firewall carregam as seções General, Modules, Debug Rules e Status. A seção Modules reúne quatro interruptores: DDoS Protection Unmetered, Functions, Network Shield e Web Application Firewall. A API carrega os mesmos quatro no objeto modules do firewall.

Um firewall novo começa com três deles ativados. Um firewall criado pela API apenas com um name retorna o seu objeto modules definido como:

A página Create Firewall no Azion Console começa com os mesmos interruptores ativados. Um firewall criado a partir de um drawer do Console, e não dessa página, começa com Functions desativado, então verifique esse interruptor antes de contar com Run Function.

DDoS Protection está sempre ativado. O seu interruptor carrega a tag Automatically enabled in all accounts e não pode ser desativado, e a API trata ddos_protection como somente leitura.

Cada um dos outros três controla o que uma regra pode usar. Uma opção controlada continua visível no formulário do Rules Engine enquanto o seu produto está desativado, desabilitada e com um rótulo que nomeia o produto de que precisa:

Um firewall precisa de pelo menos um entre Functions, Web Application Firewall ou Network Shield habilitado para funcionar. Os comportamentos nativos não precisam de nenhum produto. Azion Console sempre os oferece, e Deny (403 Forbidden), Drop (Close Without Response) e Set Rate Limit são aplicados em um firewall com Network Shield desativado. Azion Console lê o firewall salvo, então, depois de ativar um produto, salve Main Settings antes que as opções dele fiquem selecionáveis.

Bot Manager não tem interruptor. Ele roda como uma instância de função no firewall, invocada por um comportamento Run Function, então depende de Functions estar ativado. Para essa cadeia, consulte Bot Manager.

Esse controle impede que uma regra dependa de um produto que o firewall não executa. O custo é que regras e configurações passam a depender umas das outras nas duas direções. Para as duas recusas que isso produz, consulte O que Network Shield acrescenta a um firewall.

Funções em um firewall

Uma função em um firewall roda na fase de requisição, a única fase que um firewall tem: todas as suas regras são regras de requisição. Três objetos ficam entre uma função e uma requisição. A função declara o ambiente de execução firewall, uma instância de função no firewall carrega os argumentos dela, e o comportamento Run Function de uma regra nomeia essa instância pelo ID.

Quando os critérios da regra correspondem, o comportamento entrega a requisição ao Azion Runtime, que executa a função e retorna um resultado. Rules Engine para Firewall então retoma a partir do ponto em que o comportamento foi executado, com base nesse resultado. A função pode negar a requisição, descartá-la ou respondê-la ela mesma. Para os métodos que uma função de firewall chama sobre a requisição, consulte Functions no Firewall.

Uma função carrega argumentos padrão, e cada instância carrega os seus. Os argumentos da função são a base de toda instância, e os argumentos da instância os sobrescrevem. Os padrões são aplicados quando a função roda, não copiados para a instância: uma instância criada com um objeto vazio armazena {}. Nada valida os argumentos de uma instância, então uma chave escrita errada é armazenada e ignorada, enquanto a função roda com o seu padrão. Para mais informações, consulte Instâncias de função no Firewall.

Uma função pode sustentar várias instâncias em um firewall, cada uma com os seus argumentos e cada uma executada pela sua própria regra. É assim que uma função instalada atende duas fatias de tráfego com duas configurações. Uma instância pertence ao firewall em que foi criada, e uma função escrita para o ambiente de execução de aplicação não pode ser instanciada em um firewall. Para os limites do nome de uma instância e dos argumentos dela, consulte Limites de Firewall.

Propagação

Uma mudança salva não chega ao tráfego imediatamente. Ela se propaga pela infraestrutura distribuída da Azion, e o tempo que isso leva depende do que mudou. Nenhuma duração é garantida:

Entre a primeira resposta alterada e a última, as requisições alternam entre o resultado anterior e o alterado. Uma única requisição logo depois de uma mudança, portanto, prova pouco. Por exemplo, depois que você remove o seu próprio endereço de uma blocklist, uma requisição pode passar e a seguinte ainda pode ser recusada.

Um workload novo responde com o 404 provisório da Azion até que o vínculo com a aplicação se propague, e o firewall pode entrar no caminho muito depois da aplicação. Um domínio que responde, portanto, não significa que o firewall já está no caminho. Verifique uma mudança repetindo a requisição até que ela responda como esperado e as respostas concordem, nunca com uma única requisição.

Observabilidade

Uma decisão do firewall deixa pouco na resposta. Nenhum header nomeia o firewall, a regra ou a lista que decidiu. Toda resposta, interrompida ou não, carrega um header x-azion-request-id, e a página de erro padrão da Azion repete esse ID na linha Request ID. A linha Your IP mostra o endereço do cliente, que é o endereço que um critério Network compara com a sua lista:

O status distingue os resultados: 403 para uma negação, 429 para um rate limit, 400 para um bloqueio do WAF e nenhuma resposta para um descarte. Uma requisição descartada não carrega header, então o cliente dela não tem request ID para reportar.

Qual regra decidiu é respondido pelos logs, e apenas enquanto a configuração Debug Rules do firewall está ativada. A configuração fica em Main Settings, registra as regras que são executadas e vem desativada por padrão. Com ela ativada, Real-Time Events e Data Stream mostram as regras que uma requisição executou no campo $traceback. A GraphQL API do Real-Time Events as mostra na variável $stacktrace.

Manter a regra fora da resposta significa que um cliente não consegue saber qual regra o bloqueou, e a consulta passa para você. Um cliente pode reportar um status e um request ID, e a regra por trás deles vem dos logs. Para o procedimento, consulte Faça o debug de regras criadas com Rules Engine.

WAF

Uma requisição pode carregar um ataque na query string, em um header ou no corpo que ela envia. Um web application firewall lê essas partes antes da aplicação e pesa o que encontra contra padrões de ataque conhecidos. Quando as evidências se somam, ele recusa a requisição e, caso contrário, a requisição alcança a aplicação sem alteração.

Em um firewall, WAF age em um ponto do caminho da requisição: uma regra cujo comportamento Set WAF nomeia um rule set e um modo. O rule set guarda o que detectar, oito famílias de ameaças e a sensibilidade escolhida para cada uma, e a regra decide quando ele se aplica. Um rule set gerenciado configurado em outro lugar se transfere no mesmo formato: você escolhe categorias, que aqui são as famílias de ameaças, e um rigor para cada uma, que é a sensibilidade dela. As regras individuais ficam com a plataforma. WAF também precisa estar habilitado no firewall, e é o único produto que um firewall novo traz desativado: modules.waf.enabled mostra false até que você o ative. Um rule set aplicado em um firewall sem WAF nunca roda. Para saber onde fica esse interruptor, consulte Defina as configurações principais de um firewall.

Os campos de um rule set, as famílias de ameaças, os cinco níveis de sensibilidade e as regras internas estão em Rule sets do WAF. Os campos de uma exceção estão em Exceções do WAF.

Onde WAF age sobre uma requisição

Criar um rule set não inspeciona nada. Um rule set é um objeto de configuração que não carrega domínio, caminho nem método, então ele pontua exatamente as requisições que os critérios de uma regra entregam a ele. Uma regra carrega no máximo um comportamento Set WAF, então uma regra decide um rule set e um modo para as requisições a que corresponde.

Este diagrama acompanha uma requisição, da regra que corresponde a ela até a decisão do WAF:

1. Uma regra no firewall corresponde à requisição, e o comportamento Set WAF dela nomeia um rule set e um modo, logging ou blocking.
2. WAF pontua a requisição contra as famílias de ameaças configuradas nesse rule set.
3. Um score que alcança o limite da sua família torna a requisição uma correspondência.
4. Em Blocking, uma correspondência é recusada com 400. Em Logging, uma correspondência é registrada e servida.
5. Uma requisição que não alcança nenhum limite continua pelas regras do firewall até a aplicação.

Manter o rule set separado da regra é o que permite que um rule set rode de duas maneiras. O modo pertence ao comportamento, então o mesmo rule set roda em Logging em uma regra e em Blocking em outra, sobre os caminhos que você escolher. Isso custa um objeto e uma etapa: um rule set que nenhuma regra referencia não inspeciona nada, por mais cuidadosamente que as suas famílias estejam configuradas.

Para saber como WAF pontua uma requisição, o que cada modo faz e como exceções e tuning restringem um rule set, consulte Score e modos.

Network Shield

Parte do tráfego é indesejada por causa de onde vem, não do que pede. A fonte pode ser um endereço que abusou de um formulário de login, uma rede inteira ou um país em que o seu serviço não opera. Bloquear pela fonte compara o endereço do cliente de cada requisição com uma lista e recusa a requisição antes que a aplicação a veja. A lista pode mudar com a mesma frequência que as ameaças, enquanto a regra que a lê continua a mesma.

Em um firewall, Network Shield age por meio de um critério de uma regra. A lista é uma network list, e a comparação é o critério Network, ${network} na API. O que acontece com uma requisição que corresponde é o comportamento da regra, que Rules Engine para Firewall define e Network Shield não altera. Uma network list não decide nada sozinha, e criar uma não bloqueia nenhuma requisição. Uma lista só corresponde a tráfego depois que uma regra a referencia, em um firewall que o deployment de um workload nomeia.

O que Network Shield acrescenta a um firewall

Network Shield acrescenta uma coisa a um firewall: o critério Network. Enquanto Network Shield está desativado, a API recusa uma regra que usa ${network} com 25047 Missing Required Modules. Azion Console mostra a opção desabilitada, como Network - required Network Shield. Todo comportamento que uma regra correspondente executa pertence ao Firewall: Deny (403 Forbidden), Drop (Close Without Response) e Set Rate Limit são aplicados com Network Shield desativado. Uma regra pode encadear o critério Network com qualquer outro critério que o firewall oferece.

Um firewall novo começa com Network Shield ativado: o interruptor do Console vem ativado por padrão, e a API retorna modules.network_protection.enabled como true. O interruptor fica em Main Settings, na seção Modules, e a opção Network fica selecionável depois que você salva o firewall com ele ativado. Depois que uma regra usa o critério Network, Network Shield não pode ser desativado. A mudança é recusada com 24005, e o detalhe dela lista os IDs das regras.

As duas recusas importam quando uma regra passa de um firewall para outro. Uma regra Network recriada em um firewall em que Network Shield está desativado é recusada até que Network Shield seja ativado ali. No firewall de onde a regra veio, Network Shield só é desativado depois que toda regra Network dele for excluída ou alterada. Uma regra que usa o critério Network conta para as regras do firewall como qualquer outra regra. Para as regras que cada plano inclui, consulte Limites de Firewall.

O preço de corresponder pela fonte é que o critério Network lê apenas o endereço do cliente. Ele diz de onde uma requisição vem e nada sobre o que ela carrega. Uma regra que também precisa do caminho encadeia um segundo critério, como Request Uri, no mesmo bloco. Por exemplo, uma regra pode negar os países de uma lista, a menos que a requisição venha do Googlebot. Os critérios dela são Network matches a lista and Header User Agent does not match Googlebot, e o comportamento dela é Deny (403 Forbidden). Header User Agent precisa de WAF no firewall, e um cliente define o seu próprio User-Agent, então qualquer cliente pode alegar ser o Googlebot.

Para saber como uma lista corresponde ao endereço do cliente, quando os itens expiram e quais listas a Azion mantém, consulte Correspondência de listas.

Bot Manager

Um script e uma pessoa chegam a uma aplicação do mesmo jeito, por HTTP, e a requisição é tudo o que existe para diferenciá-los. O gerenciamento de bots pesa a evidência que uma requisição carrega: os headers que envia, o endereço de onde vem e a sessão que apresenta. Cada verificação que encontra algo soma pontos a um único score. Quando o score alcança um valor que você define, a requisição recebe uma ação e, com um score menor que esse valor, a aplicação recebe a requisição sem alteração.

Em um firewall, Bot Manager age como uma instância de função, não como um interruptor em Modules. A função Bot Manager instalada é instanciada no firewall com um objeto JSON de argumentos, e uma regra cujo comportamento é Run Function a executa. A instância guarda o score a partir do qual Bot Manager age e a ação que ele toma, e a regra decide quais requisições recebem um score.

Bot Manager Lite é a edição self-service, instalada pelo Azion Marketplace. As duas edições diferem no que usam para calcular o score, não no que fazem com um score.

Onde Bot Manager age sobre uma requisição

Uma função Bot Manager instalada não pontua nada sozinha. Cinco objetos colocam uma requisição sob inspeção, e cada um nomeia o seguinte:

• A função Bot Manager instalada.
• Um firewall com Functions habilitado.
• Uma instância de função nesse firewall, carregando os argumentos.
• Uma regra nesse firewall cujo comportamento Run Function nomeia a instância.
• Um workload vinculado ao firewall pelo seu deployment.

Este diagrama acompanha uma requisição, da regra que corresponde a ela até a decisão do Bot Manager:

1. Uma regra no firewall corresponde à requisição, e o comportamento Run Function dela executa uma instância do Bot Manager, com os argumentos que essa instância carrega.
2. Bot Manager lê os dados que a requisição carrega, incluindo os dados de dispositivo, de navegador e de rede, e deriva o fingerprint do cliente por trás dela.
3. Bot Manager pontua a requisição contra as suas regras e compara o score com o limite da instância.
4. Um score igual ou maior que o limite executa a ação configurada. Um score menor deixa a requisição seguir até a aplicação.

Manter a seleção em uma regra deixa a mira da inspeção com você: uma instância pontua as requisições a que a sua regra corresponde, não tudo o que o firewall vê. Isso custa um objeto e uma etapa. Uma instância que nenhuma regra nomeia fica inerte, quaisquer que sejam os seus argumentos, e uma regra cujos critérios nunca correspondem não pontua nada.

Para saber como Bot Manager calcula um score e age sobre ele, e como fingerprints, cookies de sessão e modos o moldam, consulte Score de bots.

Recursos relacionados