Autor: Dmitri

Após vários anos de trabalho árduo, temos o orgulho de anunciar o lançamento público do novo ecossistema de software Deflect. Em nossa organização no GitHub https://github.com/deflect-ca você encontrará todos os repositórios oficiais de código aberto relacionados ao Deflect, que permitem que você implemente uma infraestrutura completa de proteção de sites ou seus componentes individuais. O Deflect oferece uma rede de armazenamento em cache e entrega de conteúdo de alto desempenho, ferramentas de mitigação de ataques cibernéticos com tecnologia da Banjax e do centro de aprendizado de máquina Baskerville, painéis de controle para usuários, APIs e muito mais. Você está lendo esta postagem em uma infraestrutura do Deflect reconstruída e refatorada, e estamos muito orgulhosos disso!

A seguir, apresentamos a história de como o novo Deflect surgiu e os motivos que levaram às diversas escolhas de software.

Desviar-próximo

Criado em 2011, o Deflect foi uma solução relativamente simples para o problema do tipo “muitos contra um” dos ataques de negação de serviço distribuída (DDoS) direcionados aos servidores web da sociedade civil. Ao executar o software de cache e mitigação do Deflect em servidores de borda em constante rotação, estrategicamente localizados em alguns dos maiores data centers do mundo, oferecemos um cenário de “muitos contra muitos”, utilizando a natureza abrangente da Internet de maneira semelhante àqueles que organizavam ataques contra nossos clientes – nivelando o campo de jogo e trazendo um pouco mais de “igualdade” para os direitos de nossos clientes à liberdade de expressão e de associação com nosso público. Os servidores de borda da Deflect memorizavam solicitações anteriores de dados de sites (por meio de técnicas de cache de proxy reverso) e aliviavam a carga dos servidores web de nossos clientes. Para bloquear a enxurrada de ataques conduzidos por bots, desenvolvemos um software de mitigação de ataques baseado em regras – o Banjax –, que identifica comportamentos algorítmicos que consideramos maliciosos e bloqueia os endereços IP que os exibem. 

À medida que expandíamos nossa infraestrutura e centenas de meios de comunicação independentes, grupos de direitos humanos e outras organizações sem fins lucrativos aderiam ao serviço, a rede Deflect passava a receber milhões de solicitações diárias de todo o mundo. Esse crescimento foi acompanhado por uma maior frequência e sofisticação dos ataques. A infraestrutura do Deflect foi continuamente e meticulosamente corrigida, aprimorada e atualizada várias vezes. Como costuma acontecer, o código-fonte que sustenta o serviço tornou-se pesado e repleto de configurações e correções complicadas. Além disso, fomos nos afastando cada vez mais da ambição do nosso projeto secundário: ver outros grupos de tecnologia operando suas próprias instâncias do Deflect usando nossa base de código. A pilha de software exigia muita configuração manual e “conhecimento especializado”. A partir de 2019, começamos a arquitetar e desenvolver uma nova versão do Deflect, utilizando um método totalmente novo de provisionamento, gerenciamento e configuração de componentes de rede, mantendo nossa agilidade e incorporando a reprodutibilidade como filosofia principal de design.

Do ATS para o Nginx

A principal ferramenta para hospedar os sites dos clientes da Deflect é o software de cache instalado em cada ponto de borda da rede. Ele realiza todo o trabalho pesado em nossa arquitetura – atendendo a solicitações da Internet em nome dos sites de nossos clientes, funcionando como um proxy reverso. Inicialmente, optamos pelo Apache Traffic Server (ATS), desenvolvido pelo Yahoo e lançado como código aberto no início dos anos 2000. A escolha foi feita principalmente por causa de seus níveis de desempenho em testes de carga. O software em si ainda não era amplamente difundido e era um pouco mais difícil de configurar e manter, com a configuração de ações específicas frequentemente distribuída por vários arquivos. Isso exigia que cada operador de rede da Deflect se aprofundasse na documentação e no código-fonte para entender o que aconteceria a cada alteração.

Outra solução de cache e proxy — o Nginx — revelou-se uma opção mais atraente para nosso novo projeto de rede, com formatos de configuração flexíveis e uma base de usuários técnicos muito maior.

Do Ansible e do Bash ao Python e ao Docker

Os clientes do Deflect personalizam suas configurações de cache e mitigação de ataques por meio do Deflect Dashboard, que envia instantâneos dessas configurações para o controlador de rede. Anteriormente, o mecanismo de configuração era uma combinação de Ansible e Bash, e sua lógica e complexidade haviam crescido além do que era viável gerenciar nessas linguagens. Agora, reconstruímos o módulo de configuração em Python, garantindo melhor escalabilidade no futuro e compatibilidade com comunicações via API.

Reestruturamos o módulo de orquestração do Deflect — para instalar pacotes, iniciar e parar processos e enviar novas configurações para os pontos de extremidade da rede — utilizando o Docker.

Os benefícios da conteinerização são bem conhecidos, mas, resumidamente, as vantagens para nós foram: dissociar as aplicações do sistema operacional host (a atualização entre versões do Debian sempre foi um ponto crítico), tornar nossos diversos ambientes de desenvolvimento e teste mais reproduzíveis e permitir que criássemos e destruíssemos facilmente várias cópias de um contêiner no mesmo servidor. Depois que nossas aplicações foram containerizadas, precisávamos de uma maneira de iniciar e parar esses contêineres, e decidimos escrever o código de forma imperativa em nossa linguagem de uso geral preferida, o Python. Existe uma biblioteca, a docker-py, que se conecta ao daemon do Docker em hosts remotos via SSH e fornece uma API para construir imagens, criar volumes, iniciar/parar contêineres e tudo o mais de que precisávamos. O resultado não é tão simples quanto o Docker Compose ou o Swarm, mas também não é tão complicado quanto o Kubernetes, e está escrito em uma linguagem que todos em nossa equipe de desenvolvimento já conhecem.

De Banjax para Banjax-go

Nosso principal método de mitigação — o Banjax — era, anteriormente, um plug-in do ATS e, como tal, estava fortemente acoplado aos detalhes internos da máquina de estados de processamento de solicitações e do ciclo de eventos do ATS. Escrito em C++, ele estava fortemente acoplado aos mecanismos internos do ATS e, muitas vezes, tinha sua funcionalidade limitada pelo próprio servidor de cache. Responder a uma pergunta simples como “uma solicitação conta para o limite de taxa mesmo que o resultado já tenha sido armazenado em cache, ou apenas se a solicitação for encaminhada até a origem?” exigia uma leitura minuciosa do código-fonte do Banjax e do ATS. Para portar nossa lógica de mitigação de ataques para outro servidor, como o Nginx, seria necessário um entendimento igualmente detalhado de seus mecanismos internos. Além disso, queríamos compartilhar as ferramentas do Banjax com outras pessoas — mas não conseguíamos dissociá-las do ATS —, pois nenhum de nossos parceiros ou colegas utilizava esse software de cache.

Exploramos uma arquitetura alternativa: na qual a lógica de mitigação de ataques reside em um processo separado (desenvolvido em qualquer linguagem e desacoplado do funcionamento interno de qualquer servidor específico) e se comunica com o servidor por meio de algum canal de comunicação entre processos. Exploramos o uso de um plug-in do Nginx especializado para essa finalidade (e desenvolvemos um plug-in ATS de prova de conceito em Lua que fazia a mesma coisa) mas descobrimos que uma combinação entre a diretiva `proxy_pass`, amplamente utilizada, e o cabeçalho `X-Accel-Redirect` era mais flexível (as respostas de autenticação podem redirecionar o cliente para locais arbitrários) e provavelmente mais portável entre servidores. Quanto à escolha da linguagem para o serviço de autenticação, Python e a estrutura Flask teriam sido uma boa opção, já que os utilizamos em outras partes de nossa pilha, mas alguns testes de desempenho mostraram que Go e Gin eram muito mais rápidos (nossa meta era uma sobrecarga no pior caso de cerca de 1 ms além das solicitações, com um tempo de resposta no 50º percentil de 50 ms, e o Go/Gin atinge isso).

A interface entre o Nginx e o Banjax-go é uma boa demonstração do poder de expressão do arquivo de configuração do Nginx. Este primeiro bloco de código indica que se deve corresponder a todas as solicitações recebidas (`/`) e encaminhá-las para `http://banjax-go/auth-request`.

location / {
    proxy_pass http://banjax-go/auth_request
}

O Banjax-go então verifica o IP do cliente e o nome do site em suas listas de IPs a serem bloqueados ou submetidos a verificação. Ele responde ao Nginx com um cabeçalho semelhante a `X-Accel-Redirect: @access_granted` ou `X-Accel-Redirect: @access_denied`. Esses são nomes de outros blocos de localização na configuração do Nginx, e o Nginx realiza um redirecionamento interno para um deles.

location @access_granted {
    proxy_pass https://origin-server
}
location @access_denied {
    return 403 "acesso negado";
}

Isso já é muito mais fácil de entender do que um plugin que se integra à lógica interna de processamento de solicitações do Nginx ou do ATS (ler e gravar um arquivo de configuração é mais fácil do que ler e gravar código). Além disso, ele se integra muito bem aos outros conceitos que podem ser expressos com a configuração por escopo do Nginx: você pode controlar o registro em log, o cache, o tratamento de erros e muito mais em cada bloco `location`, e fica claro se isso se aplica à solicitação ao banjax-go, à solicitação ao servidor de origem ou à mensagem estática 403 de acesso negado.

Aqui está um diagrama que mostra o fluxo de proxy_pass + X-Accel-Redirect descrito acima (siga os números vermelhos 1, 2 e 3), juntamente com as outras interfaces que o Banjax-go possui: o monitoramento de logs e a conexão com o Kafka. O monitoramento de logs aplica as mesmas regras de expressão regular e limite de taxa que o plug-in ATS aplicava, mas de forma assíncrona (fora da solicitação e da resposta do cliente), em vez de síncrona. O canal do Kafka serve para receber decisões do Baskerville (“desafiar este IP”) e para informar
 se um IP desafiado foi aprovado ou reprovado no desafio.

Cliente da Baskerville

O centro de coordenação de previsão de anomalias liderado por máquinas — Baskerville — é uma infraestrutura inovadora que vem operando em produção no Deflect há mais de um ano. Trata-se de uma configuração complexa que depende de servidores de borda que enviam logs para o centro de coordenação, onde o pré-processamento para extração de características (identificação de comportamentos anômalos em logs da web) gera vetores que são, em seguida, processados pelo modelo de aprendizado. Uma previsão de anomalia é gerada e comunicada de volta à borda da rede. O centro de coordenação é executado em um cluster do Kubernetes e requer uma grande quantidade de recursos para o processamento.

Recentemente, dividimos a base de software em dois componentes: a câmara de compensação e o software cliente (que opera em qualquer servidor web Linux+nginx). A ideia era permitir que clientes de terceiros, que não utilizam o Deflect, se beneficiem das previsões da câmara de compensação e da ferramenta de mitigação Banjax. Nesse novo modelo, o cliente Baskerville é instalado independentemente do Deflect e realiza:

• Processa os logs do servidor web nginx e calcula características estatísticas.
• Envia recursos para uma instância da câmara de compensação do Baskerville.
• Recebe previsões de uma câmara de compensação para cada endereço IP.
• O Issues emite comandos para cada IP malicioso em um tópico separado do Kafka.
• Monitora ataques nos painéis do Grafana.

Próximos componentes de código aberto do Deflect

• Deflect — todos os componentes necessários para configurar seu controlador de rede e servidores de borda — que, essencialmente, atuam como um proxy reverso para você ou para os servidores web de origem dos seus clientes.
• Deflect-API — uma interface para os componentes do Deflect
• Edgemanage — uma ferramenta para gerenciar a disponibilidade HTTP de um cluster de servidores web por meio do DNS. Se for constatado que uma máquina está apresentando baixo desempenho, ela é substituída por um novo host para garantir a máxima disponibilidade da rede.
• Banjax — limitação básica da taxa de solicitações recebidas de acordo com um conjunto configurável de padrões de expressões regulares.
• Baskerville — um mecanismo de análise que utiliza aprendizado de máquina para distinguir entre comportamentos normais e anormais no tráfego da web. Utilizado em conjunto com o Banjax para bloquear e banir endereços IP que ultrapassem um limite definido pela operadora.
• Cliente Baskerville — software de ponta para o pré-processamento de características comportamentais a partir de registros da web e para a comunicação com o centro de dados Baskerville para previsões de anomalias.
• Painel do Baskerville — Um painel destinado aos usuários que utilizam o software Baskerville Client, oferecendo opções de configuração, definição de rótulos e envio de feedback à câmara de compensação

Boa programação a todos!