As melhores práticas em WAF: O que considerar e como escolher

Muitas organizações implementam um firewall de aplicação web (WAF) para atender a requisitos de conformidade, mas para a maioria, o principal motivo para implementar um WAF é proteger servidores e aplicações web contra exploração por meio de vulnerabilidades de aplicação. Deve-se levar em consideração que a maioria das aplicações possui vulnerabilidades. Em um estudo recente, a equipe Trustwave identificou pelo menos uma vulnerabilidade em 100% das aplicações que investigaram. E a maioria tinha mais de uma.

Você pode se perguntar “por que não corrigir as vulnerabilidades e dispensar o WAF?” Embora haja uma tendência de incorporar o desenvolvimento seguro no início do processo de desenvolvimento de aplicações, o nível de expertise em segurança dentro das equipes de desenvolvimento varia amplamente. Práticas de desenvolvimento também podem introduzir vulnerabilidades. Além disso, é fundamental levar em consideração que aplicações legadas são alvos fáceis de atacantes, e muitas vezes os times de desenvolvimento evitam realizar alterações pela falta de confiança em corrigir algo em nível de segurança e prejudicar o funcionamento da aplicação.

Vulnerabilidades podem passar despercebidas em novas aplicações, à medida que os desenvolvedores são pressionados a entregar aplicações mais rapidamente do que nunca. O uso de componentes de código aberto e/ou código de terceiros pode levar a bugs e falhas desconhecidos se tornando parte das aplicações. No futuro previsível, organizações que desenvolvem aplicações devem esperar que essas aplicações tenham vulnerabilidades.

Por esse motivo, um WAF é uma ferramenta necessária para proteger servidores e aplicações web contra ataques. Como qualquer ferramenta de segurança, um WAF precisa ser implementado e gerenciado de forma eficaz para fornecer valor sustentável.

Melhores práticas de implementação do WAF

Quanto mais tempo você dedicar ao planejamento da implementação do seu WAF, mais eficaz será sua implementação ao longo do tempo. Trabalhe nessas melhores práticas antes e durante a implementação.

Documente sua tolerância a riscos de segurança web:

A tolerância ao risco da sua organização deve impactar como você configura suas políticas de WAF. Por exemplo, se sua organização é uma grande operação de comércio eletrônico, você pode ter uma tolerância alta para riscos. Você não quer que nenhum tráfego legítimo seja bloqueado, pois a receita que você obtém do seu negócio de comércio eletrônico supera o risco de ser atacado com sucesso. Por outro lado, se você suporta uma instituição financeira, sua tolerância ao risco pode ser muito baixa. Você está disposto a permitir que alguma atividade de usuário legítimo seja bloqueada como uma troca para evitar um ataque e a má publicidade que poderia vir com ele.

Documente aplicações e proprietários:

Diferentes aplicações servem a propósitos diferentes, então a tolerância ao risco geral da sua organização pode não se aplicar a cada aplicação. Fale com cada proprietário sobre que proteção sua aplicação requer. Ter o conhecimento sobre as aplicações e seu propósito ajudará você, como profissional de segurança, a apoiar seu negócio, em vez de impedi-lo. Também ajudará você a identificar rapidamente os proprietários se algo der errado.

Sua organização pode querer aplicar uma única política de segurança para todas as aplicações, ou você pode estar aberto a definir políticas diferentes para diferentes aplicações, conforme fizer sentido. 

Entender as aplicações também pode ajudar a definir políticas de WAF.

• Implemente políticas de WAF que façam sentido para suas aplicações. Seu fornecedor de WAF provavelmente fornecerá um conjunto abrangente de políticas para uma variedade de aplicações e tecnologias. Dedique tempo para ajustar essas políticas. Por exemplo, se seu site é desenvolvido em um CMS conhecido, aplique as melhores práticas conhecidas. Isso economizará tempo na revisão de eventos, reduzirá a complexidade e os falsos positivos. Também economizará recursos de computação ao reduzir a carga no seu WAF e melhorará a responsividade do ponto de vista da latência.

• Se você conhece os serviços que estarão por trás do WAF, estenda as políticas do WAF para incluir todos eles (ou faça com que algum tráfego do serviço ignore o WAF). Frequentemente vemos implementações de WAF que procuram tráfego HTTP, mas ignoram o tráfego de aplicativos proveniente de aplicativos iOS ou Android.

• Você pode configurar a maioria dos WAFs para bloquear ou ignorar o tráfego usando métodos de conexão não utilizados por suas aplicações. Digamos que suas aplicações usem GET, POST e HEAD, mas não OPTIONS, PROPFIND ou PUT. Bloqueie aqueles que não são usados para evitar tráfego indesejado. Isso também protegerá sua aplicação para que métodos usados no desenvolvimento não sejam enviados para produção por engano.

Identifique o que você deve restringir e o que deve permitir

A implementação é um bom momento para identificar coisas básicas que você deseja restringir e permitir através do seu WAF. Restrições geográficas são um começo fácil. Se sua empresa opera em geografias específicas, restrinja o acesso aos portais de RH apenas aos países onde você tem funcionários. Isso reduzirá a carga no seu WAF e servidores web. Atacantes ao redor do mundo estão constantemente escaneando vulnerabilidades em sites para explorar. Restringir geografias onde você não opera pode reduzir a carga nos seus servidores web.

Da mesma forma, mas do ponto de vista de whitelist, configure seu WAF para permitir tráfego confiável. Um exemplo é permitir que seu scanner de vulnerabilidades interaja completamente com as aplicações web de back-end e não seja bloqueado pelo WAF. Fazendo isso, você poderá identificar vulnerabilidades em aplicações web que estão atualmente mitigadas pelo WAF. Do ponto de vista da varredura de aplicações, você obterá maior visibilidade e identificará vulnerabilidades que podem ser bons candidatos para os desenvolvedores abordarem em futuras versões.

Escolha uma solução de WAF aderente ao seu cenário

Os WAFs têm diferentes modos de operação. Existem modos em linha, como proxy reverso e ponte transparente, onde o WAF fica entre as solicitações web e os servidores web. Um WAF em linha pode ter muito controle sobre as solicitações web, como bloquear e/ou mascarar o tráfego que não atende às políticas (tanto de entrada quanto de saída). Há também o modo fora de linha (às vezes chamado de modo fora de banda), onde o WAF investiga uma cópia do tráfego web. Nesse modo, a capacidade do WAF de bloquear o tráfego é limitada. Ele só pode enviar pacotes TCP-reset para interromper o tráfego, o que significa que algum tráfego malicioso pode chegar ao seu servidor web antes que o TCP-reset aconteça.

Como prática recomendada, escolha um modo em linha. Do ponto de vista de segurança, o risco com um WAF fora de linha de que o tráfego malicioso alcance seu servidor web e uma resposta bem-sucedida aos atacantes é muito grande. É melhor implantar um WAF em modo em linha de uma forma que atenda aos seus requisitos de segurança e aplicação do que assumir esse risco. Também há um problema em poder registrar o tráfego. Um WAF fora de linha não será capaz de descriptografar o tráfego Diffie-Hellman, que é o método de criptografia mais comum em uso hoje. Então, além do risco de segurança aumentado, você ficará cego para grande parte do seu tráfego web.

Crie uma conta para seus desenvolvedores

Os desenvolvedores de aplicações podem se beneficiar das informações provenientes do WAF, então faz sentido configurar uma conta (ou contas) para eles. Embora um WAF seja, em primeiro lugar, um controle de segurança, a maioria dos WAFs fornece informações valiosas sobre o desempenho da aplicação. Essas informações incluem coisas como alertas de alteração da aplicação, métricas de desempenho, identificação de dados sensíveis e links quebrados.

Alguns mensagens de erro do WAF também serão de interesse para os desenvolvedores. O tráfego que parece malicioso é frequentemente criado por usuários não maliciosos que interagem com aplicações de formas que o desenvolvedor não antecipou. Mensagens de erro do WAF que contenham detalhes como configurações padrão do WAF ou listagens de diretórios de pastas e arquivos podem indicar problemas na aplicação que precisam ser resolvidos.

Na GoCache, oferecemos nossa solução de WAF que pode te ajudar a proteger seus sites e aplicações contra ataques que podem comprometer a integridade de dados sensíveis e privados. Nossos recursos são personalizados, permitindo que você adapte o nosso WAF para as regras de negócio de sua aplicação. E claro, se você precisar de ajuda e quiser que nosso time crie e monitore políticas de WAF para suas aplicações, recomendamos nossos serviços do GoCache Managed Security, onde nossa equipe realiza a monitoração contínua de seus serviços. 

Antes de bloquear, comece com o “simular”.

A maioria dos WAFs oferecem opções para monitorar e/ou bloquear o tráfego de aplicações web, bem como, também possuem opções para gerar logs, sem necessariamente tomar ações. Escolha as opções de monitoramento e bloqueio que melhor suportam sua tolerância ao risco. Por exemplo, a instituição financeira que citamos no início do artigo poderia:

• Configurar seu WAF para bloquear o tráfego para todas as aplicações web.
• Configurar regras personalizadas, como o tempo que um visitante tem acesso ao seu site após completar um desafio-resposta como um teste CAPTCHA.
• Apresentar páginas de erro instrutivas, para que se um usuário legítimo for bloqueado, ele verá informações sobre outras formas de se envolver com o negócio.
• Configurar o WAF para gerar logs de eventos, e após coletar uma boa amostragem, decidir quais tipos de ação são mais compatíveis em cada situação.
• Integrar sua aplicação com SIEM para analisar melhor os falsos positivos, e depois de ter tratado tudo, utilizar opções de desafiar, que é um modo mais leve, e depois, sem ocorrências de reclamações, alterar as regras para bloqueio.