Como Escolher uma Política de Firewall Eficaz para Proteger seus Servidores

Introdução

O uso de um firewall é tanto sobre tomar decisões de política inteligentes quanto sobre aprender a sintaxe. Firewalls como o iptables são projetados para impor políticas interpretando regras definidas pelo administrador. No entanto, como administrador, você precisa saber que tipos de regras fazem sentido para sua infraestrutura.

Enquanto outros guias se concentram nos comandos necessários para começar a funcionar, neste guia, discutiremos algumas das decisões que você terá que tomar ao implementar um firewall. Essas escolhas afetarão como seu firewall se comporta, o quão protegido seu servidor está e como ele responderá a várias condições que ocorrerem. Usaremos o iptables como exemplo específico, mas a maioria dos conceitos será amplamente aplicável.

Decidindo uma Política Padrão

Quando construir um firewall, uma das decisões mais importantes a tomar é a política padrão. Isso determina o que acontece quando o tráfego não corresponde a nenhuma outra regra. Por padrão, um firewall pode tanto ACEITAR qualquer tráfego não correspondido por regras anteriores, quanto REJEITAR esse tráfego.

Rejeição Padrão vs Aceitação Padrão

A default policy of ACCEPT means that any unmatched traffic is allowed to enter the server. This is generally not recommended, because it means that you would need to work backwards from there, blocking all unwanted traffic. Blocklist-type approaches are difficult to manage, because you’d need to anticipate and block every type of unwanted traffic. This can lead to maintenance headaches and is generally prone to mistakes, misconfigurations, and unanticipated holes in the established policy.

A alternativa é uma política padrão de REJEITAR. Isso significa que qualquer tráfego não correspondido por uma regra explícita não será permitido. Cada serviço deve ser explicitamente permitido, o que pode parecer uma quantidade significativa de configuração inicial. No entanto, isso significa que sua política tende para a segurança e que você sabe exatamente o que é permitido receber tráfego em seu servidor. Além disso, quase todas as políticas pré-configuradas seguirão essa abordagem, o que significa que você pode construir com base nas configurações padrão existentes.

Política de Rejeição Padrão vs Regra de Rejeição Final

A escolha de uma política de rejeição padrão leva a outra decisão sutil. Com o iptables e outros firewalls semelhantes, a política padrão pode ser definida usando a funcionalidade de política incorporada do firewall ou implementada adicionando uma regra de rejeição abrangente no final da lista de regras.

A distinção entre esses dois métodos se resume ao que acontece se as regras do firewall forem descartadas.

Se a função de política incorporada do seu firewall estiver configurada como DROP e as regras do firewall forem descartadas (redefinidas), ou se certas regras correspondentes forem removidas, seus serviços se tornarão instantaneamente inacessíveis remotamente. Isso é frequentemente uma boa ideia ao definir políticas para serviços não críticos, para que seu servidor não seja exposto a tráfego malicioso se as regras forem removidas.

A desvantagem dessa abordagem é que seus serviços ficarão completamente indisponíveis para seus clientes até que você reestabeleça regras permissivas. Você pode até se trancar fora do servidor se não tiver acesso remoto local ou baseado na web como alternativa.

A alternativa para definir uma política de descarte usando a funcionalidade de política incorporada é definir a política padrão do seu firewall como ACCEPT e, em seguida, implementar uma política de DROP com regras regulares. Você pode adicionar uma regra normal de firewall no final da sua cadeia que corresponda e negue todo o tráfego restante não correspondido.

Nesse caso, se as regras do seu firewall forem descartadas, seus serviços serão acessíveis, mas desprotegidos. Dependendo das opções de acesso local ou alternativo, isso pode ser um mal necessário para garantir que você possa entrar novamente no servidor se as regras forem descartadas. Se decidir usar essa opção, certifique-se de que a regra de captura sempre permaneça como a última regra no seu conjunto de regras.

Derrubar vs Rejeitar Tráfego

Há várias maneiras de impedir que um pacote alcance seu destino pretendido. A escolha entre elas afeta como o cliente percebe sua tentativa de conexão e quão rapidamente ele pode determinar que sua solicitação não será atendida.

A primeira maneira pela qual os pacotes podem ser negados é usando DROP. O Drop pode ser usado como política padrão ou como um destino para regras de correspondência. Quando um pacote é descartado, o iptables simplesmente o descarta. Não envia nenhuma resposta de volta ao cliente que está tentando se conectar e não dá nenhuma indicação de que já recebeu os pacotes em questão. Isso significa que os clientes (legítimos ou não) não receberão nenhuma confirmação do recebimento de seus pacotes.

Para tentativas de conexão TCP (como as feitas por um navegador da web), a conexão ficará parada até que o limite de tempo limite seja atingido. A falta de resposta para clientes UDP é ainda mais ambígua. Na verdade, não receber um pacote UDP de volta muitas vezes indica que o pacote foi aceito. Se o cliente UDP se preocupa com o recebimento de seus pacotes, ele terá que reenviá-los para tentar determinar se foram aceitos, perdidos durante o trânsito ou descartados. Isso pode aumentar o tempo que um ator malicioso terá que gastar para obter informações sobre o estado das portas do seu servidor, mas também pode causar problemas com o tráfego legítimo.

Uma alternativa para descartar o tráfego é rejeitar explicitamente os pacotes que você não permite. ICMP, ou Protocolo de Mensagem de Controle da Internet, é um meta-protocolo usado em toda a Internet para enviar mensagens de status, diagnóstico e erro entre hosts como um canal fora de banda que não depende de protocolos de comunicação convencionais como TCP ou UDP. Quando você usa o alvo REJECT em vez do alvo DROP, o tráfego é negado e um pacote ICMP é retornado para o remetente informando que seu tráfego foi recebido, mas não será aceito. Uma mensagem de status também pode ser incluída para fornecer um motivo.

Isso tem várias consequências. Supondo que o tráfego ICMP seja permitido alcançar o cliente, ele será imediatamente informado de que seu tráfego está bloqueado. Para clientes legítimos, isso significa que eles podem entrar em contato com o administrador ou verificar suas opções de conexão para garantir que estão se comunicando com a porta correta. Para usuários maliciosos, isso significa que eles podem concluir suas varreduras e mapear as portas abertas, fechadas e filtradas em um período mais curto de tempo.

Há muito a considerar ao decidir se deve descartar ou rejeitar o tráfego. Uma consideração importante é que a maioria do tráfego malicioso na verdade será perpetrada por scripts automatizados. Como esses scripts geralmente não são supervisionados, descartar o tráfego ilegítimo não desencorajará significativamente eles e terá efeitos negativos para os usuários legítimos. Mais informações sobre esse assunto podem ser encontradas no site de Peter Benie.

Tabela de Resposta de Rejeição vs. Descarte

A tabela abaixo mostra como um servidor protegido por um firewall reagirá a diferentes solicitações, dependendo da política aplicada à porta de destino.

A primeira coluna indica o tipo de pacote enviado pelo cliente. A segunda coluna contém os comandos nmap que podem ser usados para testar cada cenário. A terceira coluna indica a política de porta aplicada à porta. A quarta coluna é a resposta que o servidor enviará, e a quinta coluna é o que o cliente pode inferir sobre a porta com base na resposta recebida.

Políticas ICMP

Assim como ao decidir se deve descartar ou rejeitar tráfego negado, você tem a opção de aceitar ou rejeitar pacotes ICMP destinados ao seu servidor.

O ICMP é um protocolo usado para muitas coisas. Como mencionado, muitas vezes é enviado para fornecer informações de status sobre solicitações usando outros protocolos. Uma de suas funções mais populares é enviar e responder a pings de rede para verificar a conectividade com hosts remotos. Existem muitos outros usos para o ICMP que não são tão amplamente conhecidos, mas ainda são úteis.

Pacotes ICMP são organizados por “tipo” e depois ainda por “código”. Um tipo especifica o significado geral da mensagem. Por exemplo, o Tipo 3 significa que o destino era inalcançável. Um código é frequentemente usado para fornecer mais informações sobre um tipo. Por exemplo, ICMP Tipo 3 Código 3 significa que a porta de destino não estava disponível, enquanto ICMP Tipo 3 Código 0 significa que a rede de destino não pôde ser alcançada.

Tipos para Bloquear Dependendo da Configuração de Rede

Alguns tipos de ICMP são úteis em determinadas configurações de rede, mas devem ser bloqueados em outras.

Por exemplo, mensagens de redirecionamento ICMP (tipo 5) podem ser úteis para iluminar um design de rede ruim. Um redirecionamento ICMP é enviado quando uma rota melhor está diretamente disponível para o cliente. Portanto, se um roteador recebe um pacote que terá que ser roteado para outro host na mesma rede, ele envia uma mensagem de redirecionamento ICMP para dizer ao cliente para enviar os pacotes através do outro host no futuro.

Isso é útil se você confia na sua rede local e deseja identificar ineficiências em suas tabelas de roteamento durante a configuração inicial. Em uma rede não confiável, um usuário mal-intencionado poderia potencialmente enviar redirecionamentos ICMP para manipular as tabelas de roteamento em hosts.

Outros tipos de ICMP que são úteis em algumas redes e potencialmente prejudiciais em outras são os pacotes de anúncio de roteador ICMP (tipo 9) e solicitação de roteador (tipo 10). Os pacotes de anúncio e solicitação de roteador são usados como parte do IRDP (Protocolo de Descoberta de Roteador da Internet ICMP), um sistema que permite que hosts, ao inicializar ou ingressar em uma rede, descubram dinamicamente os roteadores disponíveis.

Na maioria dos casos, é melhor para um host ter rotas estáticas configuradas para os gateways que ele usará. Esses pacotes devem ser aceitos nas mesmas situações que os pacotes de redirecionamento ICMP. Na verdade, como o host não conhecerá a rota preferida para o tráfego de quaisquer rotas descobertas, mensagens de redirecionamento muitas vezes são necessárias logo após a descoberta. Se você não está executando um serviço que envia pacotes de solicitação de roteador ou modifica suas rotas com base em pacotes de anúncio (como rdisc), você pode bloquear esses pacotes com segurança.

Tipos que Geralmente São Seguros de Permitir

Os tipos de ICMP que geralmente são seguros de permitir estão listados abaixo, mas você pode desativá-los se quiser ser extra cauteloso.

• Tipo 8 — Solicitação de eco: Estas são solicitações de ping direcionadas ao seu servidor. Geralmente, é seguro permitir isso (negar esses pacotes não oculta seu servidor, já que existem muitas outras maneiras para os usuários descobrirem se seu host está ativo), mas você pode bloqueá-los ou limitar os endereços de origem aos quais você responde, se desejar.
• Tipo 13 — Solicitação de carimbo de data/hora: Esses pacotes podem ser usados pelos clientes para coletar informações de latência. Eles podem ser usados em algumas técnicas de identificação de sistema operacional, então você pode bloqueá-los ou limitar o intervalo de endereços aos quais você responde.

Os tipos abaixo geralmente podem ser permitidos sem regras explícitas, configurando seu firewall para permitir respostas a solicitações que ele tenha feito (usando o módulo conntrack para permitir tráfego ESTABLISHED e RELATED).

• Tipo 0 — Respostas de eco: Estas são respostas às solicitações de eco (pings).
• Tipo 3 — Destino Inalcançável: Pacotes legítimos de destino inalcançável são respostas a solicitações criadas pelo seu servidor indicando que o pacote não pôde ser entregue.
• Tipo 11 — Tempo excedido: Este é um erro de diagnóstico retornado se um pacote gerado pelo seu servidor morreu antes de alcançar o destino devido a exceder seu valor TTL.
• Tipo 12 — Problema de parâmetro: Isso significa que um pacote de saída do seu servidor estava malformado.
• Tipo 14 — Respostas de carimbo de data/hora: Estas são as respostas para consultas de carimbo de data/hora geradas pelo seu servidor.

Bloquear todo o tráfego ICMP de entrada ainda é recomendado por alguns especialistas em segurança, no entanto, muitas pessoas agora incentivam políticas inteligentes de aceitação ICMP. Estes dois tópicos do Stackexchange têm mais informações.

Limitação de Conexão e Limitação de Taxa

Para alguns serviços e padrões de tráfego, você pode querer permitir o acesso apenas enquanto o cliente não estiver abusando desse acesso. Duas maneiras de limitar o uso de recursos são a limitação de conexão e a limitação de taxa.

Limitação de Conexão

A limitação de conexão pode ser implementada usando extensões como connlimit para verificar quantas conexões ativas um cliente tem abertas. Isso pode ser usado para restringir o número de conexões permitidas de uma só vez. Se você decidir impor limites de conexão, terá algumas decisões a tomar:

• Você limita em uma base por endereço, por rede ou global?
• Você combina e restringe o tráfego para um serviço específico ou para o servidor como um todo?

Conexões podem ser limitadas caso a caso em um host específico, ou um limite pode ser estabelecido para um segmento de rede fornecendo um prefixo de rede (como um intervalo de endereços IP para toda uma organização). Você também pode definir um número máximo global de conexões para um serviço ou para a máquina inteira. Lembre-se de que é possível combinar essas opções para criar políticas mais complexas para controlar o número de suas conexões.

Limitação de Taxa

A limitação de taxa permite que você crie regras que governam a taxa ou frequência com que o tráfego será aceito pelo seu servidor. Existem várias extensões de firewall que podem ser usadas para limitação de taxa, incluindo limit, hashlimit e recent. A escolha da extensão dependerá, em grande parte, da forma como você deseja limitar o tráfego.

A extensão limit fará com que a regra em questão seja correspondida até atingir o limite, após o qual os pacotes adicionais são descartados. Um limite como 5/seg permitirá que 5 pacotes correspondam por segundo, após o qual a regra não será mais aplicada. Isso é útil para estabelecer um limite global de taxa para um serviço. Você também pode implementar um serviço adicional como Fail2ban para bloquear tentativas repetidas de conexão.As conexões podem ser limitadas caso a caso ou pode ser definido um limite para um segmento de rede fornecendo um prefixo de rede (como um intervalo de endereços IP para uma organização inteira). Você também pode definir um número máximo global de conexões para um serviço ou para a máquina inteira. Tenha em mente que é possível combinar esses métodos para criar políticas mais complexas para controlar o número de conexões. A limitação de taxa permite que você construa regras que governem a taxa ou frequência com que o tráfego será aceito pelo seu servidor. Existem várias extensões de firewall que podem ser usadas para limitação de taxa, incluindo `limit`, `hashlimit` e `recent`. A escolha da extensão a ser usada dependerá principalmente da forma como você deseja limitar o tráfego. A extensão `limit` fará com que a regra em questão seja correspondida até que o limite seja atingido, após o qual os pacotes adicionais serão descartados. Um limite como `5/sec` permitirá que 5 pacotes correspondam por segundo, após o qual a regra não corresponderá mais. Isso é útil para definir um limite global de taxa para um serviço. Você também pode implantar um serviço adicional como o Fail2ban para bloquear tentativas de conexão repetidas.

A extensão hashlimit é mais flexível, permitindo que você especifique alguns dos valores que o iptables irá hash para avaliar uma correspondência. Por exemplo, ele pode examinar o endereço de origem, porta de origem, endereço de destino, porta de destino ou uma combinação desses quatro valores para avaliar cada entrada. Pode limitar por pacotes ou por bytes recebidos. Isso oferece limitação flexível por cliente ou por serviço.

A extensão recent adiciona dinamicamente endereços IP de clientes a uma lista ou verifica contra uma lista existente quando a regra corresponde. Isso permite distribuir sua lógica de limitação em várias regras para padrões complexos. Tem a capacidade de especificar uma contagem de acertos e um intervalo de tempo como os outros limitadores, mas também pode redefinir o intervalo de tempo se houver tráfego adicional, forçando um cliente a interromper todo o tráfego se estiver sendo limitado.

Gerenciamento Monolítico vs Baseado em Cadeias

Toda a política de firewall do iptables e nftables essencialmente se baseia na extensão das cadeias incorporadas. Para começar, isso geralmente significa alterar a política padrão para as cadeias existentes e adicionar regras. Para firewalls mais complexos, muitas vezes é uma boa ideia estender o framework de gerenciamento criando cadeias adicionais.

As cadeias criadas pelo usuário são chamadas secundariamente e estão intrinsicamente ligadas à sua “cadeia de chamada”, da qual se originam. As cadeias criadas pelo usuário não têm uma política padrão, então se um pacote passar por uma cadeia criada pelo usuário, ele retornará à cadeia de chamada e continuará a avaliação. Levando isso em consideração, as cadeias criadas pelo usuário são principalmente úteis para fins organizacionais, para tornar as condições de correspondência de regras mais manuteníveis e para melhorar a legibilidade dividindo as condições de correspondência.

Se você se pegar repetindo determinados critérios de correspondência para um número significativo de regras, pode valer a pena criar uma regra de salto com os critérios de correspondência compartilhados para uma nova cadeia. Dentro da nova cadeia, você pode adicionar esse conjunto de regras com os critérios de correspondência redundantes omitidos.

A decisão de agrupar todas as suas regras em uma das cadeias integradas ou de criar e utilizar cadeias adicionais dependerá da complexidade do seu conjunto de regras.

Conclusão

Agora você deve ter uma compreensão melhor das decisões que terá que tomar ao projetar políticas de firewall para seus servidores. Geralmente, o investimento de tempo envolvido com firewalls tende a ser muito maior durante a configuração inicial. Embora possa levar algum tempo e experimentação para elaborar uma política que atenda melhor às suas necessidades, fazê-lo lhe dará mais controle sobre a segurança do seu servidor.

Se você deseja saber mais sobre firewalls e iptables especificamente, confira os seguintes artigos:

• Como funciona o Firewall Iptables
• A Deep Dive into Iptables and Netfilter Architecture

Os seguintes guias podem ajudá-lo a implementar suas políticas. Escolha o guia que corresponde ao seu firewall para começar:

• Como configurar um firewall usando Nftables no Ubuntu 22.04
• Como configurar um firewall com UFW no Ubuntu 22.04
• Como configurar um firewall usando FirewallD no Rocky Linux 9