F5 Distributed Cloud: uma requisição, de ponta a ponta

Dezesseis artigos sobre o F5 Distributed Cloud, na ordem em que uma requisição passa por eles: como um site entra na malha, onde a requisição chega, que rota ela segue, para onde é encaminhada, como é criptografada, se é permitida, quanto dela é tolerado, o que ela pode chamar, o rastro que deixa e o erro que passa despercebido na configuração que a tratou.

Por que esta ordem

A documentação da plataforma é organizada por objeto: load balancers, origin pools (os pools de servidores de origem), service policies, , proteção de API. Para uma referência, é o jeito certo de organizar; para aprender a plataforma, é o jeito errado, porque quem trabalha com ela não encontra os objetos um de cada vez. Encontra uma requisição, e a requisição passa pelos objetos numa sequência fixa.

Por isso, esta página acompanha uma requisição desde o momento em que um site entra na malha (a fabric) até o momento em que um evento de segurança é gravado sobre ela. Cada passo é um artigo. Lida do começo ao fim, a sequência apresenta a plataforma inteira; usada como consulta, cada passo diz aonde ir quando aquela etapa dá problema.

1. Como um site entra na malha

Registro do CE e tráfego de saída - antes que um site possa atender qualquer requisição, o Customer Edge precisa se registrar: uma chamada de registro com token (o call-home), dois Regional Edges escolhidos pela localização geográfica, a emissão dos certificados e túneis que usam de preferência, com fallback para SSL. A maioria dos problemas de conectividade da plataforma nasce neste passo, e eles aparecem como se tudo o que vem depois estivesse quebrado.

2. Onde a requisição chega

Match de domínio e lógica do listener - a advertise policy restringe a requisição a um endereço e uma porta; dentro disso, a plataforma escolhe o match de domínio mais específico, e o nome exato ganha do wildcard. O hostname vem do ou do header Host, conforme o protocolo, e é esse detalhe que explica muitos chamados do tipo "o balanceador errado respondeu".

3. Que rota ela segue

Avaliação de rotas no HTTP load balancer - as rotas formam uma lista ordenada, avaliada por first-match (vale a primeira que casar). Quatro tipos de rota, três tipos de match de path e as regras de ordem que explicam por que uma requisição foi parar numa rota abaixo da que você esperava.

4. Para onde ela é encaminhada

Anatomia do origin pool - o que um pool contém, as cinco formas de identificar um origin e por que o mesmo origin pode aparecer saudável visto de um site e não de outro.

Algoritmos de load balancing e persistência - é aqui que quem vem do BIG-IP precisa desaprender uma coisa: lá, método e persistência são dois ajustes separados; aqui são um só, e os algoritmos de consistent hashing (hash consistente) são a persistência.

5. Como ela é criptografada

Níveis de segurança do TLS - os três níveis predefinidos, mais o Custom; por que o Default é o nível High e que versão mínima de protocolo isso implica; por que as listas de ciphers são cumulativas; e por que um scanner às vezes aponta versões de protocolo que a configuração, aparentemente, não permite.

6. Se ela é permitida

A service policy é o controle de acesso da plataforma, e é a parte que mais vale a pena ler na sequência, porque cada artigo é pré-requisito do seguinte.

Predicados e lógica - dentro de uma regra, todos os predicados são combinados com AND, e um predicado não configurado é implicitamente verdadeiro; dentro de um matcher, vários valores são combinados com OR. Se você errar isso, as regras casam com tudo ou com nada.

Ações e negação por padrão - ALLOW, DENY ou NEXT_POLICY, os modificadores que uma regra pode aplicar quando casa e o que acontece com uma requisição que não casa com regra nenhuma.

Algoritmos de combinação de regras - quando uma política tem várias regras, é o algoritmo que decide em que ordem elas são avaliadas. O first-match percorre as regras de cima para baixo e para na primeira que casar; os outros algoritmos não param, e é nessa diferença que está todo o comportamento.

Maiúsculas, minúsculas e transformers nos matchers - nomes de header são case-insensitive (não diferenciam maiúsculas de minúsculas); valores de header, chaves de query e nomes de cookie diferenciam; e o match exato compara byte a byte, a menos que um transformer diga o contrário. É o artigo para ler quando uma regra que obviamente deveria casar não casa.

Service policy versus iRules - para quem traz os hábitos do BIG-IP: uma iRule é código procedural que roda em eventos; uma service policy é uma lista declarativa. O que tem equivalente, o que não tem e como pensar nos casos que não têm.

7. Quanto dela é tolerado

Rate limiting explicado - por que dois limites escritos de formas diferentes são o mesmo limite, como o leaky bucket (o algoritmo do balde furado) e o multiplicador de burst se comportam de verdade e a armadilha: uma mitigação configurada como Disabled não é o mesmo que desligada.

8. O que ela pode chamar

OpenAPI e inventário de APIs - a proteção de API é um modelo de segurança positivo, montado a partir de uma especificação OpenAPI: os paths e os métodos da spec viram o inventário, e o inventário orienta a validação. Este artigo existe para o caso de uma requisição a um endpoint que a spec não descreve.

9. O rastro que ela deixa

Anatomia dos eventos de segurança - o WAF (web application firewall), a defesa contra bots, as service policies e a proteção de API gravam todos no mesmo fluxo de eventos. Um campo diz qual dessas fontes gerou o evento, e a diferença entre a ação tomada e a ação recomendada mostra, depois do ocorrido, se a proteção estava em modo de bloqueio ou de monitoramento.

10. O erro que passa despercebido

Riscos de configuração - a plataforma aceita configurações válidas e operacionalmente erradas: um origin pool que não verifica o certificado, texto claro onde não deveria haver, e o resto da lista que um linter consegue apontar olhando um único objeto. Leia por último, porque cada risco desse artigo é um dos passos acima feito de um jeito um pouco errado.

Os dois hábitos que esta sequência ensina

O raciocínio parte da requisição. Quando algo dá errado, ache o passo. Backend errado é o passo três ou quatro. Uma regra que deveria casar e não casa é o passo seis e, quase sempre, caso para o artigo sobre matchers. Um scanner reclamando de versões de protocolo é o passo cinco. Seguir a sequência resolve mais rápido do que fuçar o console.

E o console aceita coisas que não deveria. O passo dez é uma lista de configurações que a plataforma salva e executa sem reclamar, e cada uma delas é uma decisão que um revisor deveria pegar. O catálogo de falhas deste site está cheio de sistemas que fizeram exatamente o que foram configurados para fazer; uma plataforma que valida a sintaxe, e não a intenção, está pedindo ao operador que faça a segunda conferência.

Esta série, em ordem

Este artigo abre a série F5 Distributed Cloud, uma requisição de ponta a ponta. A série acompanha uma requisição desde o site até o evento de segurança que ela deixa registrado; as partes são os artigos de cada passo, na mesma ordem, com o modelo de match da service policy (como uma política decide se vale para a requisição) colocado antes dos predicados, das ações e dos algoritmos que ele rege.

O que realmente acontece quando um CE se registra: token, dois REs por GeoIP, IPsec-com-fallback-SSL e o allowlist que faz funcionar. O call-home com token, dois Regional Edges escolhidos por GeoIP, IPsec com fallback para SSL e o allowlist do firewall que deixa um Customer Edge entrar na malha.
Como o XC decide qual load balancer vence um hostname: listener logic, wildcards e o apex. Qual load balancer fica com um hostname: a advertise policy, o nome exato antes do wildcard, o catch-all padrão e o apex, que o wildcard não cobre.
Como o HTTP load balancer do XC escolhe uma rota: first-match, tipos de path e o WAF por rota. As rotas como uma lista ordenada de first-match: os quatro tipos de rota, os paths por prefixo, exatos e por regex, e o WAF que uma rota pode associar ou desativar.
A anatomia de um origin pool do XC: tipos de origin, seleção de endpoint e TLS para o origin. O que um origin pool contém, as formas de identificar um origin, por que um mesmo origin aparece uma vez para cada Regional Edge e o TLS até o origin.
Algoritmos de load balancing e persistência no XC, para quem vem do BIG-IP. No BIG-IP, método e persistência são dois ajustes; no XC são um só, e os algoritmos de hash são a própria persistência.
Níveis de segurança TLS do F5XC decodificados: o que High/Medium/Low negociam, e por que seu scanner sinaliza um load balancer. High, Medium, Low e Custom: o que cada um negocia, por que o padrão é High e por que um scanner aponta os níveis mais baixos.
Como uma service policy do F5 XC casa com uma requisição. O modelo em que todo o resto se apoia: os predicados no nível da política definem o escopo dela, e depois a requisição precisa casar com uma das suas regras.
Predicados e lógica booleana nas regras de service policy do XC. AND entre os predicados de uma regra, OR entre os valores de um matcher e o predicado não configurado, que é sempre verdadeiro.
Ações e negação por padrão em service policies do XC. ALLOW, DENY e NEXT_POLICY, os modificadores que uma regra pode aplicar e a negação por padrão (default deny), que pega todo o resto.
Algoritmos de combinação de regras do XC: FIRST_MATCH, ALLOW_OVERRIDES, DENY_OVERRIDES. FIRST_MATCH, ALLOW_OVERRIDES e DENY_OVERRIDES: qual regra vence quando várias poderiam casar.
Maiúsculas, minúsculas e transformers nos matchers do XC. Nomes de header ignoram maiúsculas e minúsculas, valores não: o motivo mais comum para uma regra que parece certa nunca casar.
Service policy do XC vs iRules do BIG-IP: um modelo mental. Scripts orientados a eventos versus uma lista declarativa de regras: como ler as políticas do XC com a cabeça de quem escreve iRules.
Como o rate limiting do F5XC realmente conta: leaky bucket, burst, bloqueio e overshoot. Leaky bucket, burst, bloqueio (lockout) e overshoot: como o rate limiting do XC conta de verdade, e por que Disabled não quer dizer desligado.
A spec OpenAPI como o inventário de API do XC: paths, auth e a sombra. A especificação OpenAPI como inventário de APIs: validação, discovery, autenticação e as shadow APIs que ninguém documentou.
Como ler um evento de segurança do XC: tipo, ação e a razão pela qual disparou. Um único fluxo para WAF, defesa contra bots, service policy e proteção de API: o tipo do evento, a ação e onde fica o motivo.
Perigos comuns de configuração do XC que um linter pode pegar. Configurações válidas, mas operacionalmente erradas, as que um linter consegue apontar olhando um único objeto, e os limites de analisar um objeto isolado.