firewall

Este é um tema interessante, que merece uma abordagem mais abrangente. Atualmente, existe um apelo muito forte para a aquisição de appliances baseados em soluções mistas, como os famosos UTMs (Unified Threat Management) ou Next-Generation firewalls.

São excelentes soluções, mas não se afobe… Nem tudo é o que parece! 😉

Resumidamente, um firewall UTM consiste no agrupamento das principais soluções de segurança em um único equipamento, sendo responsável pela filtragem de pacotes, NAT, VPN, serviços Proxy para controle de acesso, antivírus, sistema de detecção de Intrusão e etc – depende do fabricante. O objetivo consiste em simplificar o layout físico da rede (diminuindo o número de equipamentos e pontos de falha) e oferecer uma configuração centralizada e “homogênea”. É de fato uma grande vantagem, mas a eficiência do sistema de segurança e rede, como um todo, não deve ser encarada de uma forma tão simplista.

Já o Next-Generation costuma ser visto como uma evolução do UTM, oferecendo os mesmos recursos ou serviços, com maior diferencial na análise de aplicação (DPI – Deep Packet Inspection). No entanto, isto pode ser relativo e dependerá das características exibidas no datasheet ou white-paper de cada equipamento – nem sempre retrata a realidade.

Como é possível encontrar vasta documentação sobre o assunto, não pretendo entrar em maiores detalhes sobre as diferenças conceituais. Mas, farei uma análise sobre a exploração prática dos recursos disponíveis.

Praticamente todos os recursos descritos podem ser implementados em um firewall Linux e de diferentes maneiras. Mas, infelizmente, existem duas desvantagens: “falta de ferramentas eficientes para administração centralizada (para sincronizar vários firewalls) e relatórios (dependerá do seu objetivo)“. Existem vantagens e desvantagens nos “dois mundos”!

Existe um mito de que esta nova geração de firewall muda a lógica de configuração das regras de acesso, trocando o filtro de pacotes convencional por filtro de aplicações. Já ouvi um administrador dizer que controlava, no Sonicwall, todas as permissões via “App Control“. Se você acha que está seguro fazendo isto… não está e, dependendo do tamanho e complexidade da rede, terá fortes dores de cabeça.

O primeiro problema é que, assim como em um IPS, a presença de falso-positivo não é tão rara (em soluções comerciais também). Já presenciei um telefone IP ser classificado como Ultrasurf, por exemplo. Como a incidência de erro foi alta (em diferentes aplicações), optamos por fazer uma seleção mais criteriosa das aplicações, pois estava tornando o nosso trabalho de administração inviável. Ao contrário do que costuma ser dito, este tipo de inspeção pode ser feita por um IPS sim, como é o caso do Snort integrado ao OpenAppId.

Ops… quer dizer que isto existe no mundo Open? SIM! 😉

Outro aspecto que deve ser levado em consideração é a demanda de CPU. O simples fato de habilitar a filtragem de pacotes já onera a capacidade de roteamento, impactando sobre a performance da rede. Logo, a ativação de um controle DPI aumenta ainda mais a carga de processamento. E, quanto maior for a demanda de rede, pior será a performance – varia de acordo com o número de pacotes/segundo ou número de conexões simultâneas.

Este tipo de avaliação é importantíssima em redes de grande porte. O throughput de um firewall que lida com 100 conexões não será o mesmo se precisar lidar com 100.000. Ahh, mas no datasheet indica que o firewall suporta alguns “milhões de conexões“! Tudo bem, mas o resultado dependerá das condições da avaliação. Simule, ao mesmo tempo, um ataque de synflood usando o hping3 e veja se chega perto disto! (risos). Esteja ciente que este texto é apenas para efeito didático, a utilização desta ferramenta sem autorização é ilegal.

A indicação de filtros de aplicação como critério de acesso (liberando ou bloqueando) tem sido feita de forma equivocada.

Imagine que seu interesse seja permitir o acesso HTTP e bloquear Telnet para todas as estações da rede. De que forma você faria o filtro?

  1. filtro de pacotes
    iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 23 -j DROP
  2. filtro de aplicações
    iptables -A FORWARD -s 10.0.0.0/8 -m ndpi --http -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/8 -m ndpi --telnet -j DROP

A lógica apresentada é a mesma para qualquer appliance.

O custo de processamento do primeiro exemplo será muito menor. Infelizmente, não evitará que tuneis sejam estabelecidos através da porta tcp/80. Este é o grande diferencial da nova geração de firewalls.

Então, podemos concluir que o ideal é aplicar as regras do exemplo seguinte? NÃO.

Quando você define um filtro de aplicação tão abrangente, o custo de CPU será “excessivo”, desnecessário e aumentará a incidência de falso-positivo, pois o sistema fará a inspeção de todos os pacotes que atravessam o firewall. Existe também uma “crença” de que a filtragem de “aplicação” dispensa a de “pacotes”. Não é verdade. Na pratica, ao ignorar a filtragem de pacotes, o administrador acaba “esquecendo” das aplicações não tratadas.

Normalmente, em um ambiente corporativo, a configuração padrão é restritiva (default DROP). Então, o ideal é identificar a aplicação apenas para a porta liberada:

iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 80 -m ndpi --http -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/8 -p tcp --dport 23 -j DROP

A grande vantagem é que o firewall fará inspeção para o protocolo HTTP apenas na porta 80. E no caso do bloqueio do telnet, a identificação do protocolo não é pertinente.