A Evolução dos Firewalls

Os firewalls evoluiram muito nos últimos anos e meu contato direto com o Palo Alto Networks me mostrou como esse mercado mudou.

---

Meu colega Rodrigo escreveu em seu artigo (aqui) sobre tipos diferentes de firewall para topologias diferentes e eu comecei a pensar em como mudaram os requisitos de um firewall de rede corporativa. Quando eu administrava firewalls (há uns 10 anos pelo menos) a gente fazia o que dava com o que tinha. Depois de tantos anos voltei a mexer com um firewall novo que temos aqui no laboratório (da Palo Alto Networks) e fiquei muito impressionado com como esse mercado evoluiu.

Eu vejo dois desafios interessantíssimos que o mercado de firewalls parecia ignorar. E quando eu digo ignorar, eu nao quero dizer que não sabiam que o problema existia. É que parecia tão difícil de resolver que deixaram de lado. O comprador do firewall também não falava disso, porque se levantasse a lebre ele estaria chamando atenção para um problema que não havia solução. Então, em um acordo tácito, todos nós simplesmente não desenvolvíamos o assunto. O Palo Alto Networks foi o primeiro firewall que eu vi que faz diferente; que foi criado pensando em soluções para esses dois desafios. Ele tem uma longa lista de funcionalidades, como todo fabricante tem, e meu objetivo aqui nao é de falar de funcionalidade. O que me impressionou foi é que o produto foi projetado com esses dois conceitos em mente, e suas funcionalidades em grande parte derivam do conceito diferente que esse firewall traz ao mercado.

Primeiro Desafio Interessante

Desde que usuários passaram a usar endereço IP dinâmico (DHCP) que se tornou muito difícil de se criar regras específicas para cada usuário. Firewalls nasceram do conceito de que tudo era identificável por Protocolo, Endereço IP de origem, porta de Origem, Endereço IP de destino e Porta de destino. Essas cinco informações compõem quase todas as regras de firewall implementadas no mundo hoje. O endereço IP deixou de representar um usuário específico.

Por falta de uma solução elegante, esse problema foi largamente ignorado. Regras deixaram de ser criadas “por usuário” e passaram a ser generalistas, como “os usuários Internos” e “Estações do Helpdesk”. Nada mais foi do que adequar a nossa necessidade às ferramentas disponíveis. Houveram tentativas de se implementar ferramentas que reconhecessem o usuário, como proxies, mas quem já teve que cuidar de um sistema de proxies entende o que eu quis dizer por solução “elegante”. Funciona, mas dá trabalho e dá dor de cabeça.

É aí que se nota a primeira grande diferença do PA para os outros firewalls que já vi. As regras do Palo Alto podem ser criadas por usuário ou por grupo (do AD/LDAP). Ele é capaz de monitorar o tráfego e ver o username que foi enviado da estação, identificando quem foi que fez login naquela máquina. Se forem múltiplos usuários de um mesmo endereço (como no caso de um terminal server/Citrix), um agente precisa ser instalado. Para estações comuns, não precisa de nada. É pelo tráfego criado pelo próprio usuário que ele detecta quem é quem.

Segundo Desafio Interessante

O segundo desafio que eu vejo é a definição de regras por aplicação. Tradicionalmente as aplicações eram reconhecidas por protocolos e portas. Por exemplo, TCP/80 era WWW e TCP/110 era POP e-mail. Até aí tudo certo. TCP/IP foi escrito na década de 70 e até hoje funciona mais ou menos do mesmo jeito. Portas continuam sendo usadas e as aplicações continuam precisando usar uma porta para funcionar.

O problema foi que a Web mudou tudo. Hoje em dia, tudo é baseado em HTML. Por exemplo – Webmail. Na definição acadêmica é uma aplicação WEB, é acessada com navegador e é executada na porta TCP/80. Mas na prática, a aplicação é de e-mail. Não é de navegação. Idem para SAP, Office365, e infinitas outras aplicações que trabalham com interface Web. Firewalls tradicionais identificam essas aplicações coletivamente como “Navegação na Internet”.

Um administrador de firewall tradicional que deseja bloquear todo tipo de acesso a e-mail externo tem um desafio grande nas mãos. Filtrar apenas as portas das aplicações de E-mail tradicionais não resolve a questão de Webmail e não se pode simplesmente filtrar TCP/80, já que fazer isso impediria todo o acesso à Internet. E ficar documentando todos os endereços IP de todos os serviços de e-mail públicos é impraticável.

A segunda grande diferença do firewall Palo Alto aparece aí. As regras podem ser criadas por aplicações sem se preocupar em endereço e porta TCP/IP. Ele reconhece aplicações e reconhece, que eu achei mais legal ainda, comportamento dentro das aplicações. Isso significa que regras podem ser criadas do tipo “Permito acesso ao Hotmail mas nao permito que anexos sejam baixados”. Permito acesso ao Gmail mas não permito o uso do Gtalk dentro do Gmail. Na minha cabeça esse é o tipo de regra que qualquer administrador de rede sempre quis criar e gerenciar.

E para ficar mais bonito ainda, as regras criadas podem endereçar os dois problemas ao mesmo tempo. Aí as regras começam a ficar assim:

– Permitir Webmail para todos os usuários, mas apenas ATC\andrepadua pode colocar anexo nas mensagens.

– Negar Facebook para todos mas permita para membros do grupo AD do Marketing

– Permitir twitter para todos mas apenas participantes da campanha XYZ podem twittar.

– Permita e priorize tráfego para SalesForce.com

– Permita skype para todos e priorize tráfego para voz.

– e etc…

Eu entendo que para uma rede corporativa os exemplos acima são praticamente os únicos tipos de regras que fazem sentido. IP e porta é muito legal para declarar VPN e fazer regras para empresas parceiras e etc., mas no geral, para controlar acesso dos usuários, IP e porta não vale mais nada.

E vocês? O que acham? Regras com endereços IP e Portas ainda te atendem plenamente? Qual outra maneira de controlar acesso vocês usam nas suas empresas, e que tipo de sucesso vocês têm tido?