Quando as pessoas falam sobre firewalls de aplicações, tendem a agrupar várias coisas diferentes sob um mesmo conceito. Mas nem todos os firewalls são iguais, e é importante compreender as diferenças entre eles, especialmente se estiver a tentar descobrir qual a proteção de que a sua aplicação realmente precisa.
Então, vamos analisar isso. Existem três camadas principais de segurança de aplicações que deve conhecer: WAFs, in-app e in-kernel. RASP e alguns ADR são in-app, enquanto ADR de nível inferior baseados em eBPF são in-kernel. Todos eles têm o mesmo objetivo geral de impedir que coisas ruins aconteçam à sua aplicação, mas a forma como o fazem é muito diferente. Resumindo, o WAF vê a solicitação, o in-app vê o código e o in-kernel vê o sistema operativo.
Qual deles precisa? Bem, se deseja a postura de segurança mais forte possível, provavelmente mais de um. Neste artigo, explicaremos o que são WAFs, RASP, ADR e eBPF, em que cada um deles é mais eficaz e ajudaremos a decidir qual deles precisa.
WAF VS RASP VS ASP: Como funcionam as três camadas de segurança de aplicações?
As ferramentas de segurança de aplicações operam em três níveis diferentes, e cada uma delas detecta coisas que as outras não conseguem.
WAF: segurança de ponta
Os WAFs ficam totalmente fora da sua aplicação, inspecionando o tráfego HTTP recebido antes que ele chegue à sua aplicação. Não há contexto da aplicação, mas é ótimo para ameaças de alto volume.
Segurança de tempo de execução no aplicativo: dentro do aplicativo
Os instrumentos de segurança no aplicativo conectam-se diretamente ao seu aplicativo. Eles conectam-se à execução do seu código, rastreiam como as entradas do utilizador fluem pelo seu aplicativo e podem bloquear ataques no ponto exato em que eles se tornam perigosos, antes que uma carga maliciosa atinja o driver do seu banco de dados ou gere um shell. Por ter um contexto completo do aplicativo, ele é preciso. As ferramentas RASP, uma subcategoria do ADR, se enquadram nessa categoria.
Segurança de tempo de execução no kernel: abaixo da aplicação
As ferramentas de segurança em tempo de execução no kernel ficam totalmente abaixo da sua aplicação, no nível do sistema operativo. Em vez de se conectar ao código da aplicação, elas monitorizam todas as chamadas de sistema feitas por todos os processos no host. Elas não têm ideia do que a lógica da sua aplicação está a fazer, mas veem tudo no nível do sistema operativo, incluindo o que acontece depois que um invasor já conseguiu entrar. As ferramentas ADR baseadas em eBPF se enquadram nessa categoria.
Primeiro, analisaremos o WAF, depois o in-app e o in-kernel através das lentes do RASP e do ADR.
O que é WAF?
Um WAF (Web firewall de aplicação) fica fora da sua aplicação, na periferia. Antes mesmo de uma solicitação chegar à sua aplicação, o WAF a intercepta e verifica se ela corresponde a uma lista de padrões de ataque conhecidos, como strings de injeção SQL, cabeçalhos maliciosos ou URLs suspeitos. Se algo corresponder a um padrão, será bloqueado.
Onde os WAFs são realmente insubstituíveis é em ataques volumétricos, como tráfego DDoS, inundações de bots e scrapers. Os WAFs são construídos para lidar com grandes volumes e força bruta. Cloudflare, por exemplo, é extremamente boa em absorver ataques em grande escala antes que eles interajam com a sua infraestrutura. Eles também são fáceis de implementar. Na maioria das vezes, basta uma alteração no DNS ou no proxy, sem necessidade de escrever código ou instalar nada dentro da sua aplicação. Os WAFs também são muito configuráveis com regras personalizadas, listas de permissões e ajuste de regras, e você também pode decidir se deseja bloquear algo suspeito ou apenas detectá-lo.
O problema é que um WAF não tem ideia do que acontece depois que uma solicitação passa pela porta. Ele pode detectar uma carga suspeita, mas não pode dizer se essa carga realmente fará algo perigoso, pois não tem ideia do que o seu aplicativo realmente fará com uma solicitação. Ele vê o tráfego chegando, compara os padrões com o que foi configurado para bloquear e decide se deve bloqueá-lo ou não.
Como resultado, os falsos positivos são um problema real e podem facilmente bloquear pedidos em excesso. Um utilizador pode pesquisar algo que por acaso se pareça com SQL e ser bloqueado, enquanto um invasor inteligente codifica a sua carga de forma diferente e consegue passar. E se um WAF quiser impedir um utilizador malicioso, ele bloqueia o seu IP. Então, um invasor pode simplesmente usar uma VPN para contornar isso. Mas se você tentar bloquear todo o tráfego da VPN, também bloqueará utilizadores reais.
Como resultado, o ajuste do WAF é um processo contínuo em que se reforçam as regras, se fica atento a falsos positivos e se flexibiliza quando necessário. Essa é uma das razões pelas quais os WAFs podem exigir muita manutenção em comparação com o RASP, que precisa de muito menos ajustes contínuos, pois tem o contexto da aplicação para tomar melhores decisões sem intervenção manual.
Exemplos: Cloudflare, AWS WAF, Imperva
Código aberto: ModSecurity (via OWASP)
O que é RASP?
RASP (Runtime Application Self-Protection) e ADR no aplicativo são recursos de segurança em tempo de execução que residem dentro do seu aplicativo e o monitoram internamente enquanto ele é executado, em vez de ficarem fora do aplicativo inspecionando o tráfego de entrada, como um WAP.
Para entender por que isso é importante, você precisa saber sobre sumidouros. Um sumidouro é uma função — no seu código, numa biblioteca ou num módulo integrado — onde a entrada do utilizador deixa de ser um dado e é executada como algo significativo. Podemos considerar uma injeção SQL como exemplo. Um invasor coloca um código malicioso num campo de formulário, que flui pelo seu aplicativo, atinge o driver do seu banco de dados (algum db.query()), e nesse ponto, deixa de ser texto e torna-se um comando. Essa função de consulta é o coletor. O que as ferramentas de segurança internas do aplicativo, como o RASP, fazem é conectar-se a esses coletores e observar como a entrada se move pelo aplicativo, rastreando-a até a função perigosa.
Como essas ferramentas internas estão a ser executadas dentro da sua aplicação, elas sabem qual é a entrada, de onde ela veio e para onde está a ir. Em vez de adivinhar se ' OU 1=1-- é um ataque ou uma sequência de pesquisa legítima, uma ferramenta integrada na aplicação sabe que esta sequência específica veio de req.body.user, foi concatenado sem ser sanitizado e está prestes a atingir um pg.query() Chamada. Bloqueie-a!
As taxas de falsos positivos são muito mais baixas do que as do WAF e do ADR baseado em eBPF, porque não se trata apenas de uma correspondência cega de padrões. Ele pode bloquear uma ID de utilizador em vez de apenas um IP, de modo que um invasor não pode simplesmente usar uma VPN. E como ele rastreia o fluxo de dados em vez de comparar assinaturas conhecidas, ele pode detectar novas cargas de ataque que ninguém viu antes. Cobertura zero-day sólida para ataques do tipo injeção!
O RASP e os ADRs no aplicativo também cobrem dependências de terceiros. Você pode sanitizar o seu próprio código perfeitamente, mas se uma biblioteca que você está a usar tiver uma vulnerabilidade, isso está fora do seu controlo (se o seu scanner SCA também SCA a detectou). O RASP opera no nível do sink, independentemente da origem do código.
A principal limitação da segurança no aplicativo é que, se um invasor contornar totalmente o tempo de execução, por meio de um complemento nativo ou uma chamada direta ao sistema, os ganchos nunca serão acionados. E, uma vez que um shell é gerado, o RASP vê a chamada inicial, mas não o que acontece dentro desse shell depois disso. É aí que entra a terceira camada.
Exemplos: Aikido ( versãoopen source e paga)
O que é ADR?
ADR (Detecção e Resposta a Aplicações) é a categoria moderna mais ampla na qual o RASP se enquadra. Todo RASP é ADR, mas nem todo ADR é RASP. O termo ADR abrange qualquer ferramenta que monitora e responde a ataques em tempo de execução, seja de dentro da sua aplicação ou totalmente abaixo dela.
Na prática, as ferramentas ADR são divididas em dois tipos. O ADR no aplicativo (o que o RASP sempre foi) fica diretamente no seu aplicativo e tem contexto completo no nível do código. Tudo o que foi abordado na seção RASP acima sobre segurança no aplicativo se aplica aqui. O ADR também implica um escopo mais amplo do que o RASP, enquanto o RASP é principalmente uma ferramenta de bloqueio, o ADR também abrange recursos de detecção, visibilidade e resposta a incidentes. Nem todas as ferramentas ADR fazem tudo isso, mas é a direção que a categoria está tomando.
O outro tipo de ADR, o ADR no kernel ou ADR baseado em eBPF, adota uma abordagem diferente para proteger as aplicações. Em vez de se conectar à sua aplicação, ele fica no nível do kernel do Linux e observa todas as chamadas de sistema feitas por todos os processos no host. Ele não sabe nada sobre a lógica da sua aplicação, mas vê tudo no nível do sistema operativo.
Depois que um invasor gera um shell, o ADR no kernel fornece o próximo nível de visibilidade pós-exploração que o ADR no aplicativo não consegue ver. O ADR no kernel vê todos os comandos executados dentro desse shell, como leituras de ficheiros, chamadas de rede e movimentação lateral. Se um invasor ignorar completamente o tempo de execução, o ADR ainda vê o execve independentemente de como foi desencadeado. Na prática, o cenário mais comum para aplicações Node.js é um complemento nativo malicioso que se infiltra através de um ataque à cadeia de abastecimento (uma dependência comprometida que inclui código nativo que o seu ambiente de execução não inspeciona).
O eBPF (Extended Berkeley Packet Filter) é a tecnologia de kernel subjacente que alimenta as ferramentas ADR no kernel. O eBPF permite anexar um programa de monitorização seguro ao kernel Linux que pode observar eventos específicos que ocorrem no nível do sistema operativo, sem tocar no próprio kernel. Normalmente, se quiser adicionar monitoramento ou lógica personalizada no nível do kernel, teria que modificar o código-fonte do kernel diretamente (arriscado e complexo) ou escrever um módulo do kernel (também arriscado, pois um bug pode travar todo o sistema). O eBPF contorna isso, permitindo que você insira pequenos programas no kernel que são executados em um ambiente sandbox. Esses programas observam chamadas de sistema específicas e reportam à ferramenta ADR, que então decide se permite ou bloqueia a ação.
A desvantagem do ADR no kernel, tal como o WAF, é que não tem contexto de aplicação. Ele vê chamadas de sistema brutas, como "o processo 4821 executou um programa", mas não tem ideia de qual solicitação HTTP ou utilizador o acionou. Sem esse contexto, a segurança no kernel precisa funcionar com base em políticas, que são regras como "este processo nunca deve gerar um shell" ou "este container nunca container gravar neste diretório". Isso funciona para detectar violações claras, mas torna-o bastante binário, sem nuances.
Para ataques do tipo injeção, como injeção SQL, o ADR no kernel é praticamente cego. Quando o ataque atinge a camada de chamada de sistema, a carga útil SQL é apenas bytes brutos dentro de um buffer de rede. As explorações em tempo de execução são outro ponto cego. Alguns ataques são disparados inteiramente dentro do tempo de execução da linguagem, portanto, nunca criam uma operação incomum no nível do sistema operacional até que seja tarde demais.
Ao contrário das ferramentas RASP tradicionais, este tipo de ADR não requer alterações no código da sua aplicação para ser configurado. No entanto, tem mais configurações e requisitos do que o WAF ou o RASP, porque as ferramentas ADR geralmente precisam de um kernel Linux relativamente moderno e privilégios de sistema elevados.
Exemplos: Tetragon, Falco, KubeArmor (código aberto)
Oligo ADR (comercial)
WAF, RASP, ADR, eBPF: qual deles eu preciso?
Até agora, já abordámos muitos termos — WAF, RASP, ADR, eBPF, in-app, in-kernel. A resposta curta é que se deseja proteção em mais de uma camada. A resposta mais longa depende de quais camadas. Quando se trata de RASP vs ADR, o RASP é uma subcategoria do ADR, então a questão passa a ser: deseja segurança in-app, segurança in-kernel ou ambas?
As diferentes camadas são complementares, não concorrentes, porque cada uma capta coisas que as outras não conseguem. É por isso que a resposta para "WAF ou RASP?" geralmente é "ambos", e adicionar ADR no kernel proporciona cobertura pós-exploração e no nível do kernel, completando o quadro.
As três camadas colocam questões fundamentalmente diferentes:
- WAF: «Esta solicitação HTTP corresponde a um padrão de ataque conhecido?»
- Segurança no aplicativo (RASP e ADR): "Esta entrada do utilizador está prestes a acionar uma função perigosa no meu aplicativo?"
- Segurança no kernel (ADR): «Este processo acabou de fazer algo que não deveria ter feito no nível do sistema operativo?»
TL;DR: Adquira primeiro um WAF e uma ferramenta de segurança integrada à aplicação. Adquira posteriormente um ADR com tecnologia eBPF se precisar de processamento específico ao nível do kernel.
A segurança no aplicativo, como o RASP, é a única camada que tem algum contexto sobre como os dados estão a interagir com o aplicativo específico, portanto, é a única camada que pode fazer um bloqueio realmente preciso. Portanto, naturalmente, ela tem o menor número de falsos positivos em comparação com as outras duas. Embora proteção em tempo de execução no aplicativo proteção em tempo de execução lidar com a maioria dos ataques no nível do aplicativo ou de injeção, o WAF é necessário para ataques de alto volume, como DDoS. Como os WAFs ficam fora do aplicativo, eles podem lidar com milhares de solicitações de bots antes de atingir o seu aplicativo e tocar nesses recursos, e isso não requer muito contexto para funcionar. Juntas, a segurança no aplicativo, como Aikido , combinada com um WAF, cobrirá a grande maioria dos problemas que você encontrará.
Se está na fase em que precisa de visibilidade total pós-exploração, está preocupado com movimentos laterais ou precisa de aplicação de políticas ao nível do kernel em vários processos, é nesse momento que deve pensar em adicionar ADR no kernel. É a ferramenta certa para uma configuração de segurança mais madura, embora não seja necessariamente a primeira coisa a se procurar. Algumas ferramentas ADR no aplicativo cobrem mais do que outras. Aikido , por exemplo, monitora as atividades de saída (consultas SQL, comandos shell, leituras de ficheiros e chamadas HTTP de saída) que o seu aplicativo realiza. E, em comparação com uma configuração ADR no kernel mais complicada, as equipas podem configurar o Zen com um único npm install e uma linha de código.
A única coisa que o ADR no kernel cobre além do Zen é o que acontece depois que um shell já foi gerado e o invasor está a operar no nível do sistema operativo. Portanto, o Zen não substituirá o eBPF se você precisar de visibilidade total pós-exploração e aplicação de políticas no nível do kernel em todos os processos, mas, para a maioria das equipas, ele cobre a superfície de ataque mais importante (ataques de injeção, zero-days e lógica de autorização). No entanto, se você tiver um RASP diferente que não cubra a atividade de saída e as injeções SQL, talvez precise do eBPF mais cedo.
Zen do Aikido: O ADR moderno no aplicativo
Embora tenham objetivos semelhantes, nem todas as ferramentas de segurança integradas em aplicações são iguais. Novos ADRs , como o Zen, firewall incorporado no aplicativo de código aberto firewall incorporado no aplicativo Aikido, estão no território da segurança integrada em aplicações, mas cobrem áreas que uma ferramenta RASP padrão não cobre.
O Zen fornece todo o contexto de aplicativos dos RASPs tradicionais, como rastreamento de contaminação, bloqueio no nível do sink, reconhecimento de ID do utilizador, baixo índice de falsos positivos, mas, como um ADR moderno, o Zen também monitora a atividade de saída da mesma forma que o ADR no kernel. Isso inclui todas as consultas SQL, comandos shell, leituras de ficheiros e chamadas HTTP de saída que a sua aplicação faz. O seu algoritmo de vulnerabilidade é determinístico desde a primeira solicitação, portanto, não há problema de inicialização a frio nem manutenção contínua de regras, como acontece com outros RASPs.
O Zen também vai além dos ataques de classe de injeção. Ele analisa todas as consultas SQL em tempo de execução usando um analisador SQL completo (construído em Rust) e aplica automaticamente o escopo do locatário. Se uma consulta não tiver um filtro de locatário ou usar o ID de locatário errado, o Zen gera um erro antes de enviá-la. IDORs (referências diretas a objetos inseguras) são a causa mais comum de vazamentos de dados entre locatários em SaaS multilocatário e são notoriamente difíceis de detectar em revisões de código. O Zen torna impossível a sua implantação acidental.
Leitura adicional: Prevenção de ataques zero-day para Node.js com Aikido
Perguntas Frequentes
O que é um WAF?
Um WAF ( firewall de aplicação web) fica fora da sua aplicação e inspeciona o tráfego HTTP recebido em busca de padrões de ataque conhecidos. Ele é particularmente bom no tratamento de ameaças volumétricas, como ataques DDoS e tráfego de bots, mas não tem visibilidade sobre o que a sua aplicação realmente faz com uma solicitação.
O que é segurança RASP?
O RASP (Runtime Application Self-Protection) é uma ferramenta de segurança que é executada dentro da sua aplicação. Ele monitoriza como as entradas do utilizador fluem através do seu código e bloqueia ataques no ponto em que se tornam perigosos: o sumidouro. Como possui contexto completo da aplicação, é muito mais preciso do que um WAF para ataques do tipo injeção.
Qual é a diferença entre WAF e RASP?
Um WAF fica fora da sua aplicação e bloqueia o tráfego com base em padrões. Um RASP fica dentro da sua aplicação e bloqueia ataques com base no que o seu código está realmente prestes a fazer com a entrada do utilizador. Os WAFs são mais fáceis de implementar e ótimos para ameaças volumétricas. Os RASPs têm taxas de falsos positivos mais baixas e melhor cobertura para ataques de injeção e zero-days.
Preciso de um WAF e de um RASP?
Sim, eles são complementares, não concorrentes. Um WAF lida com proteção de nível de borda e tráfego volumétrico. Um RASP lida com ataques de classe de injeção e zero-days que os WAFs normalmente não detectam. A maioria das configurações de segurança maduras usa ambos.
O que é ADR vs RASP?
Em geral, ADR abrange ferramentas que fornecem segurança no aplicativo ou no kernel. RASP refere-se a ferramentas no aplicativo e são um subconjunto de ADR. RASP e ADR no aplicativo são tecnicamente a mesma abordagem, apenas rótulos diferentes ao longo do tempo. O rótulo ADR é mais recente e mais abrangente. Às vezes, ADR é usado como abreviação ou de forma intercambiável com eBPF, ferramentas ADR baseadas no kernel. Os termos para RASP e ADR variam ligeiramente dependendo de quem você perguntar. Tenha isso em mente ao pesquisar mais sobre o assunto.
O que é ADR/eBPF na segurança de aplicações?
O ADR (Application Detection and Response, ou Detecção e Resposta a Aplicações) abrange a segurança tanto na aplicação como no kernel. Ferramentas ARD no kernel, como Tetragon ou Falco, operam no nível do kernel Linux, monitorando todas as chamadas de sistema em todos os processos no host. Elas são fortes em visibilidade pós-exploração e detecção de desvios no nível do kernel, mas não têm contexto de aplicativo, tornando-as complementares ao RASP, em vez de um substituto para ele. O eBPF (Extended Berkeley Packet Filter) é a tecnologia de kernel subjacente que alimenta as ferramentas ADR no kernel.
Se você higienizar todas as entradas corretamente, ainda preciso do RASP?
Sim. É difícil fazer a higienização de forma perfeita o tempo todo. Especialmente se não houver SAST ferramentas de qualidade de código durante o desenvolvimento, bugs de segurança podem entrar na base de código. Pense nisso menos como um substituto para boas práticas de codificação segura e mais como um suporte de tempo de execução para quando essas práticas não são perfeitas (o que, na prática, é claro, nunca são). O RASP também impede problemas provenientes de dependências de terceiros.
