Como gerenciar efetivamente XDP/EBPF para melhor proteção DDOS

[Antevisão da transmissão ao vivo] Os modelos grandes substituirão os programadores? "

O Extended Berkeley Packet Filter ( eBPF ) pode ser atualizado de forma rápida e contínua, tornando-o ideal para lidar com alterações frequentes na configuração de segurança.

Traduzido de Como gerenciar XDP/eBPF efetivamente para melhor proteção contra DDoS , autor Ivan Koveshnikov.

O mapa Extended Berkeley Packet Filter ( eBPF ) serve como uma interface de alto nível para atualizações atômicas dos segmentos de memória compartilhada usados como memória compartilhada e fornece uma interface de configuração poderosa para programas eBPF. O mecanismo de leitura-cópia-atualização minimiza a sobrecarga de desempenho no caminho ativo. Além disso, o mapeamento eBPF permite acesso exclusivo a segmentos de memória compartilhada. Eles podem lidar com tipos de mapas mistos (matrizes, tabelas hash, filtros Bloom, filas e buffers de anel), o que os torna ideais para configurações complexas, como segurança .

À medida que a complexidade da configuração aumenta, aumenta também a necessidade de conexões entre diferentes entradas de mapeamento. Se houver muitas conexões entre as entradas do mapa, a capacidade de fazer atualizações de configuração atômica começa a diminuir. Atualizar apenas uma entrada do mapa pode significar que outras entradas devem ser atualizadas ao mesmo tempo, o que pode causar inconsistências durante as atualizações.

Aplique o XDP para gerenciamento avançado de tráfego

Considere um programa simples eXpress Data Path (XDP) que classifica e filtra o tráfego com base em um conjunto de regras prioritárias de cinco tuplas. O programa processa o próximo pacote com base na prioridade da regra e em uma combinação do endereço IP de origem do pacote, endereço IP de destino, protocolo e portas de origem e destino.

Fluxograma de classificação que leva ao processamento.

Veja a seguir um exemplo de regra de configuração de rede:

Qualquer tráfego da sub-rede A é sempre permitido.
Restringir o acesso de clientes na sub-rede C ao servidor Web na sub-rede B.
Restrinja o acesso ao servidor Web na sub-rede B.
Todos os outros acessos são negados.

Essas regras exigem que regras e restrições de classificação de tráfego sejam armazenadas na configuração, o que pode ser alcançado usando mapeamentos eBPF.

Entenda a configuração do programa eBPF como uma estrutura em árvore

Você pode visualizar a configuração como uma árvore hierárquica, com uma "raiz de configuração" como base. Esta raiz (possivelmente virtual) organiza as diversas entidades de configuração para formar a configuração ativa. As entidades são diretamente conectadas à raiz para acesso global imediato ou aninhadas em outras entidades para organização estruturada.

O acesso a uma entidade específica começa na raiz e prossegue sequencialmente (“desreferenciando” cada nível) até que a entidade desejada seja alcançada. Por exemplo, para recuperar um sinalizador booleano de uma estrutura de "opções" em uma coleção, você navegaria até a coleção, encontraria a estrutura e, em seguida, recuperaria os sinalizadores.

A abordagem da Gcore para enfrentar os desafios de complexidade do eBPF

Essa estrutura em árvore oferece flexibilidade no gerenciamento de configuração, incluindo troca atômica de qualquer subárvore, garantindo transições suaves e sem interrupções. No entanto, o aumento da complexidade traz desafios. À medida que as configurações se tornam mais complexas, as entradas tornam-se mais interligadas. É comum que várias entradas pai apontem para uma única entrada filha, ou que uma entrada desempenhe uma função dupla, tanto como propriedade de uma entidade quanto como parte de uma coleção.

As linguagens de programação modernas desenvolveram mecanismos para gerenciar configurações complexas. Os desenvolvedores usam contadores de referência, referências mutáveis e imutáveis e coletores de lixo para garantir atualizações seguras. Contudo, gerenciar a segurança dessas configurações não garante atomicidade ao alternar entre versões de configuração.

O cenário em constante mudança do tráfego online significa que as equipes de operações de segurança devem fazer alterações frequentes nas políticas de segurança. Portanto, o Gcore fez atualizações rápidas e frequentes na proteção DDoS do Gcore e incorporou recursos importantes, como um mecanismo de expressão regular . Passamos do padrão de uma ou duas atualizações por dia para soluções auto-hospedadas para atualizações quase constantes exigidas pelos provedores de serviços. Este requisito, muitas vezes esquecido em aplicações Linux, levou à adoção da tecnologia eBPF, que permite atualizações rápidas e ininterruptas.

Ao explorar soluções eBPF, devemos explorar minuciosamente estratégias para garantir que nossa configuração eBPF seja tratada da melhor maneira possível. Especificamente, as limitações do mapeamento eBPF fizeram com que nossa equipe repensasse nossa estratégia de armazenamento de configuração.

Devido à validação de segurança do kernel, as entradas do mapa eBPF não podem armazenar ponteiros diretos para segmentos de memória arbitrários, o que requer uma chave de pesquisa para acessar a entrada do mapa, retardando o processo de pesquisa. Mas esta deficiência traz um benefício: permite dividir árvores de configuração complexas em segmentos menores e mais gerenciáveis, vinculados diretamente à raiz da configuração. qual é o resultado? Consistência, mesmo durante atualizações não atômicas.

Nossas descobertas e estratégias destacam a importância do planejamento e execução cuidadosos de programas eBPF para otimizar a eficiência. Então, vamos agora abordar as estratégias específicas de atualização de configuração para ambientes eBPF e sua aplicabilidade aos requisitos e limitações exclusivos do sistema.

Política de atualização de configuração de segurança

Descobrimos que três estratégias de atualização são particularmente eficazes para melhorar as atualizações do programa, garantindo ao mesmo tempo alto desempenho e flexibilidade.

Estratégia de atualização 1: transição gradual

Uma estratégia de atualização gradual significa atualizações incrementais de configuração em vários mapeamentos. Esta é uma opção útil ao processar dados em um mapa para fornecer uma chave de pesquisa para outro mapa. Neste caso, múltiplas entradas do mapa precisam ser atualizadas e a conversão atômica não é viável. Mas operações de atualização precisas e sequenciais permitem atualizações metódicas na configuração. Algumas operações em subárvores de configuração referenciadas tornam-se seguras se executadas na ordem correta.

Por exemplo, no contexto de classificação e processamento, a camada de classificação fornece chaves de pesquisa para combinar políticas de segurança, o que significa que as operações de atualização devem seguir uma ordem específica:

É seguro inserir uma nova política de segurança porque a nova política ainda não foi referenciada.
Também é seguro atualizar as políticas de segurança existentes porque atualizá-las individualmente geralmente não causa problemas. Embora as atualizações atômicas sejam desejáveis, elas não oferecem vantagens significativas.
É seguro atualizar o mapeamento da camada de classificação para fazer referência à nova política de segurança e remover referências à política desatualizada.
É seguro eliminar políticas de segurança não utilizadas da configuração quando elas não forem mais referenciadas.

Mesmo sem atualizações atômicas, as atualizações seguras podem ser realizadas sequenciando adequadamente o processo de atualização. Este método funciona melhor para mapeamentos independentes que não estão intimamente relacionados a outros mapeamentos.

Recomendamos realizar atualizações incrementais em vez de atualizar o mapa inteiro de uma só vez. Por exemplo, atualizações incrementais em mapas hash e matrizes são completamente seguras. No entanto, este não é o caso de atualizações incrementais para um mapa Longest Prefix Match (LPM), porque a pesquisa depende de elementos que já estão no mapa. O mesmo problema ocorre quando a criação de uma chave de pesquisa para outra tabela exige que você opere em elementos de vários mapas.

As camadas de classificação são frequentemente implementadas usando vários LPMs e tabelas hash, fornecendo um exemplo desta complexidade:

Fluxos de pesquisa da classificação para LPM e hashing, e da classificação para processamento e hashing, com descrição do problema de atualização de mapeamento.

Estratégia de atualização 2: substituição de mapeamento

Para mapeamentos que não podem ser atualizados de forma incremental sem inconsistência (como mapeamentos LPM), substituir todo o mapeamento é a melhor solução. Para substituir o mapeamento do programa eBPF, é necessário um mapeamento do mapeamento. Um aplicativo de espaço do usuário pode criar um novo mapa, preenchê-lo com as entradas necessárias e, em seguida, substituir atomicamente o mapa antigo.

O mapeamento mapeado resulta em dois nós com recursos de isolamento e substituição de recursos.

Particionar a configuração em mapas separados, cada um descrevendo as configurações de uma única entidade, proporciona o benefício adicional de isolamento de recursos e elimina a necessidade de recriar a configuração completa durante pequenas atualizações. A configuração de cada entidade múltipla pode ser armazenada em um mapa substituível.

Este método tem algumas desvantagens. O espaço do usuário precisa desafixar o mapeamento anterior para manter o caminho fixo anterior, porque o mapeamento de substituição não pode ser fixado no mesmo local do mapeamento anterior. Isto é especialmente importante para programas de longo prazo que atualizam frequentemente sua configuração e dependem da fixação de mapas para estabilidade.

Estratégia de Atualização 3: Substituição de Programa

O método de substituição de mapa pode falhar ao vincular vários mapas. Atualizar apenas o mapeamento pode resultar em um estado inconsistente ou inválido que não reflete nem a configuração antiga nem a nova configuração esperada.

Para resolver este problema, as atualizações atômicas deveriam acontecer em um nível superior. Embora o eBPF não possua um mecanismo para substituir atomicamente um conjunto de mapeamentos, os mapeamentos geralmente estão vinculados a um programa eBPF específico. Este problema pode ser resolvido dividindo os mapeamentos interconectados e o código correspondente em programas eBPF separados, vinculados por chamadas finais.

Pipeline de pacotes para fluxograma de mapeamento de programa, resultando em código substituível e pacotes de mapeamento para programas eBPF.

Conseguir isso requer carregar um novo programa eBPF, criar e preencher o mapeamento para ele, fixar ambos e, em seguida, atualizar o mapeamento do programa a partir do espaço do usuário. Este processo é mais trabalhoso que a simples substituição do mapeamento, mas permite que o mapeamento e o código associado sejam atualizados simultaneamente, facilitando assim os ajustes do código em tempo de execução. No entanto, a utilização desta abordagem nem sempre é particularmente eficiente, especialmente quando se utilizam múltiplos mapas e sub-rotinas para atualizar uma única entrada de mapa num programa complexo.

Manipulação de erros

Lidar com erros ao gerenciar o eBPF pode ser complicado. É importante atualizar a configuração para evitar inconsistências. Se ocorrer um erro durante uma atualização, ele poderá causar o caos, portanto, ter backups automatizados pode ajudar a reduzir a necessidade de correções manuais.

Você pode dividir os erros em duas categorias: erros recuperáveis e erros irrecuperáveis. Para erros recuperáveis, se algo der errado durante uma atualização, você pode simplesmente interrompê-la e nenhuma alteração será feita. Você pode corrigir qualquer bug sem risco.

Erros irrecuperáveis são um pouco mais complicados. Você precisa lidar com eles com cuidado, pois podem afetar entidades de configuração específicas, o que pode quebrar todo o sistema.

É melhor organizar as atualizações por entidade de configuração em vez de por tipo de atualização. Desta forma, se ocorrer um erro, ele afetará apenas uma entidade de configuração específica e não tudo de uma vez. Por exemplo, se as regras de classificação e as políticas de segurança forem definidas para diferentes segmentos de rede, seria mais eficiente atualizá-las em ciclos separados com base no segmento de rede, em vez de por tipo de atualização. Isso facilita o gerenciamento de backups automatizados e, se ocorrer um erro irrecuperável, você saberá exatamente qual será o impacto. Apenas parte da rede é configurada de forma inconsistente, enquanto o restante não é afetado ou pode ser rapidamente alterado para uma nova configuração.

Gerenciar o ciclo de vida do programa eBPF para atualizações

Acompanhar o ciclo de vida de um programa eBPF é fundamental para programas que exigem persistência, atualizações frequentes e retenção de estado em diferentes instâncias de código. Por exemplo, se o seu programa XDP requer atualizações frequentes de código enquanto mantém as sessões de cliente existentes, é fundamental gerenciar seu ciclo de vida de maneira eficaz.

Para desenvolvedores que desejam maximizar a flexibilidade e evitar restrições, o objetivo deve ser reter apenas informações importantes entre recarregamentos – dados que não podem ser recuperados do armazenamento não volátil. Dessa forma, você pode usar mapeamentos eBPF para ajustes dinâmicos de configuração.

Para tornar o processo de recarga de código ativo mais simples, você precisa ser capaz de distinguir entre mapas de estado e de configuração, reutilizar o mapa de estado durante a recarga e preencher novamente o mapa de configuração a partir do armazenamento não volátil. A transição do processamento do programa antigo para o novo e a notificação de todos os usuários do mapeamento eBPF sobre as alterações pode ser um pouco complicada.

Existem duas maneiras comuns de implementar transições:

Substituição de programa atômico : Este método envolve anexar um programa XDP diretamente a uma interface de rede e trocá-lo atomicamente durante uma atualização. Isto pode não ser o mais apropriado para programas eBPF grandes e complexos que interagem com um grande número de programas e mapas de espaço de usuário.
Uma abordagem semelhante à libxdp : o programa agendador se conecta à interface de rede e usa chamadas finais para fazer o processamento no próximo programa no mapa do programa onde o processamento real é feito. Além de gerenciar o uso e a fixação do mapa, ele coordena vários manipuladores, permitindo transições rápidas entre eles.

A placa de interface de rede (NIC) se conecta ao agendador, ao mapa do programa e ao mapa de estado, resultando na configuração real do programa.

O processo de recarga a quente detecta e corrige rapidamente problemas de configuração e reverte rapidamente para uma versão estável anterior, se necessário. Para cenários complexos, como testes A/B, o agendador pode usar tabelas de classificação para direcionar tráfego específico para novas versões do programa XDP.

para concluir

Através da programação eBPF/XDP, a Gcore ultrapassou os limites da segurança de rede e otimização de desempenho. Nossa jornada demonstra nosso compromisso em combater ameaças emergentes por meio de recursos avançados de eBPF/XDP. À medida que continuamos a melhorar nosso núcleo de processamento de pacotes, estamos comprometidos em fornecer soluções de ponta que ajudem a manter as redes de nossos clientes robustas e ágeis.

Este artigo foi publicado pela primeira vez em Yunyunzhongsheng ( https://yylives.cc/ ), todos são bem-vindos para visitar.