17 October 2019

Introdução aos Firewalls com Cisco ASA - Parte 1

Este artigo inicia uma série de estudos sobre os firewalls usando o Cisco ASA (Adaptive Security Appliance) como ferramenta de laboratório. A série não será composta por um conjunto de meros how-to como receitas de bolo; teremos uma introdução abrangente sobre os firewalls, passando pelo entendimento dos principais padrões de segurança envolvidos. Então, sem mais delongas, vamos começar!

O que é um Firewall?

Resumidamente, o firewall é a barreira entre uma rede que você confia e uma rede que você não confia. É por isso que os firewalls são muitas vezes representados por um ícone de muro com tijolos à mostra. No jargão técnico, a rede que você confia é chamada de trusted network, e a rede que você não confia é chamada de untrusted network. A rede local da sua empresa ou da sua casa é um exemplo de rede que você confia, portanto, trusted network. Já a Internet, por ser um ambiente de livre acesso, é uma rede que você não confia, ou seja, untrusted network.

A origem da palavra firewall (fire + wall, literalmente parede de fogo”) remete ao século XVII. Uma lei do Estado de Nova York, EUA, datada de 1791 (chapter 46), obriga que todas as moradias sejam construídas com paredes anti-incêndio que se estendem do chão a até pouco mais de 30 centímetros acima do telhado. Essas paredes anti-incêndio são chamadas de fire walls”. Se um incêndio tomar conta de um cômodo ou de toda a casa, as paredes anti-incêndio impedem que o fogo se propague, limitando a dimensão do desastre.

Por analogia, os engenheiros de rede criaram a palavra firewall para designar o sistema (seja hardware ou software) inserido entre uma zona confiável e uma zona não confiável com o objetivo de impedir que a zona não confiável cause impactos negativos dentro da zona confiável. Tecnicamente, essas zonas são chamadas de security zones.

O que são Security Zones?

A rede local da sua empresa é um território que você confia, compondo uma trusted network. Por exemplo, teoricamente, todo o tráfego que corre dentro de uma rede local é confiável, pois trata-se do tráfego útil dos usuários que fazem parte da rede. O território de uma rede local, no entanto, possui um limite, uma fronteira. Tudo o que está dentro desse limite forma uma security zone. A rede local da sua empresa forma uma security zone chamada private zone.

Private zone = trusted network = geralmente, a rede local da sua empresa.

Toda a Internet forma uma security zone chamada public zone. Você não pode confiar no tráfego que corre pela Internet porque é difícil estabelecer uma origem confiável. É justamente por isso que a Internet é uma untrusted network.

Public zone = untrusted network = geralmente, a Internet.

Os firewalls usam o conceito de security zones para a definição de políticas de controle de acesso. Não se assuste com o nome; vamos entender tudo isso através de um exemplo:

Figura 01

A figura acima ilustra um cenário simples com o uso de firewall. A rede local à esquerda, por ser uma trusted network, é uma private zone. Já a Internet à direita, untrusted network, é uma public zone. O firewall situado no meio do caminho entre as duas zonas gerencia o acesso que uma zona pode ter à outra zona.

A private zone (rede local) pode ter acesso livre a qualquer outra zona. Pense bem: a private zone gera um tráfego confiável, e não existe zona mais segura do que a private zone. Portanto, todo acesso originado dentro da private zone é liberado a qualquer destino.

Por outro lado, a public zone (Internet) não pode ter acesso livre à private zone. A public zone gera tráfegos que não são confiáveis, e por isso esses tráfegos não podem entrar livremente numa private zone.

Assim sendo, temos os seguintes fluxos controlados pelo firewall:

Figura 02

A rede local pode acessar a Internet livremente, mas a Internet não possui acesso à rede local.

Neste caso, o que vai acontecer quando a Internet responder ao tráfego gerado dentro da rede local? Quando um dispositivo na private zone acessa a public zone, em algum momento a public zone tem que responder ao dispositivo na private zone. Como isso é possível, se a Internet não tem acesso à rede local? Vamos ver.

Stateless vs. Stateful

Existem dois modelos básicos de sistemas de controle de acesso: stateless e stateful. Os sistemas stateless consideram os pacotes de forma independente, enquanto que os sistemas statefull lidam com toda a comunicação, do início ao fim.

As ACLs (Access Control Lists) tradicionais configuradas nos roteadores, por exemplo, compreendem um sistema de controle de acesso stateless. Quando um usuário acessa um website na Internet, o primeiro pacote da comunicação é gerado na rede local e destinado à rede pública. Se houver uma ACL configurada na interface do roteador que se conecta à rede local, esse pacote será analisado antes de continuar o seu percurso, ou seja, o roteador vai decidir se encaminha ou descarta o pacote com base nas regras definidas na ACL.

Quando o servidor web na Internet responder à solicitação do usuário dentro da rede local, se houver outra ACL configurada na interface do roteador que se conecta à Internet, esse pacote de resposta será analisado para que o roteador decida se ele será encaminhado ou descartado. Ou seja, neste caso, duas regras de permissão são necessárias: uma na ACL aplicada na interface da rede local e a outra na ACL da interface conectada à Internet. O cenário fica da seguinte forma:

Figura 03

Se em qualquer uma das ACLs não houver a permissão ilustrada na figura acima, a comunicação não será possível. Ou a solicitação não vai conseguir sair para a Internet, ou a resposta não vai conseguir entrar na rede local.

Os sistemas stateful simplificam o gerenciamento desse fluxo. Se na figura acima o roteador fosse substituído por um firewall, apenas uma regra seria necessária: a permissão para que o dispositivo da rede local tivesse acesso à Internet (no Cisco ASA, essa permissão vem configurada por padrão). A outra regra para permitir a entrada do tráfego de resposta na rede local não seria necessária porque o firewall, por ser um sistema stateful, saberia que tal tráfego é realmente a resposta a uma solição gerada dentro da rede local. Em suma, o firewall permite que pacotes vindos da Internet (untrusted network) entrem na rede local (trusted network) se e somente se esses pacotes fizerem parte de uma comunicação iniciada originalmente dentro da rede local, ou seja, se os pacotes forem a resposta a uma solicitação previamente feita por um dispositivo da rede local. Caso contrário, se o tráfego for originado na Internet, a comunicação será bloqueada. Qualquer tráfego originado em uma untrusted network com destino a uma trusted network deve ser explicitamente permitido pelo firewall em suas regras de acesso.

O cenário ficaria da seguinte forma:

Figura 04

Os firewalls, portanto, por serem sistemas stateful, são capazes de rastrear o estado de uma comunicação associando solitações e respostas, permitindo que as respostas vindas de uma untrusted network sejam encaminhadas para dentro de uma trusted network.

Além disso, a maioria dos sistemas stateful trabalha até a camada 7, podendo filtrar pacotes com base em parâmetros de aplicação. Por exemplo, se o acesso a um determinado website tiver que ser bloqueado, a URI pode ser especificada ao invés do endereço IP. É mais garantido especificar a URI porque o endereço IP de um website pode mudar com o tempo. Os sistemas stateless geralmente alcançam até a camada 4 apenas.

DMZ

Além das zonas já mencionadas, outra zona muito comum é a demilitarized zone (DMZ). Se você acompanha o noticiário, deve saber da existência da zona desmilitarizada da Coreia. Trata-se de um espaço na fronteira entre Coreia do Norte e Coreia do Sul onde muitas vezes ocorrem encontros diplomáticos entre governos ideologicamente opostos, como EUA e Coreia do Norte, por exemplo. A DMZ no firewall tem um propósito bem análogo à zona desmilitarizada da Coreia.

Digamos que você tenha um servidor dentro de sua rede local que precisa ser acessado tanto pelos usuários da rede interna como por usuários da Internet. Ou seja, esse servidor está localizado em uma trusted network recebendo solicitações originadas em uma untrusted network, gerando um risco de segurança considerável. Para evitar que isso aconteça, o servidor deve ser inserido em uma DMZ. Vamos a um exemplo:

Figura 05

A DMZ não é mais segura que a private zone nem menos segura que a public zone; ela é o meio-termo entre a rede local e a Internet. O controle de acesso entre a private zone e a public zone permanece o mesmo: a rede local pode se comunicar com qualquer destino, e a Internet, por padrão, pode se comunicar com a rede local somente se o tráfego for a resposta a uma solicitação previamente originada na rede local.

Nas conexões entre private zone e demilitarized zone, a rede local tem acesso livre à DMZ, mas a DMZ, por definição, só pode se comunicar com a rede local com tráfegos de resposta a solicitações previamente geradas na rede local. Já nas conexões entre demilitarized zone e public zone, a DMZ tem permissão para acessar livremente a Internet, mas a Internet, por definição, só tem permissão para acessar a DMZ com pacotes de resposta às solicitações. O cenário fica da seguinte forma:

Figura 06

Observe bem: temos um problema ilustrado na figura acima. Os usuários da public zone (Internet) devem ser capazes de iniciar conexões com o servidor situado na DMZ. Por definição, essas conexões são bloqueadas, já que a public zone é menos segura que a DMZ. Para permitir que os usuários da Internet acessem a DMZ, uma regra deve ser explicitamente configurada no firewall. Com isso, teremos o seguinte cenário:

Figura 07

Assim sendo, podemos listar as definições das políticas de controle de acesso:

  • Tráfego da private zone para a public zone - permitido.
  • Tráfego da private zone para a demilitarized zone - permitido.
  • Tráfego da demilitarized zone para a private zone - negado.
  • Tráfego da demilitarized zone para a public zone - permitido.
  • Tráfego da public zone para a private zone - negado.
  • Tráfego da public zone para a demilitarized zone - negado (deve ser permitido via ACL).

Conclusão

Encerramos aqui a primeira parte da nossa série sobre firewalls. Garanta que você tenha absorvido o conteúdo deste texto antes de prosseguir para as próximas partes da série.

Se você tiver qualquer crítica ou sugestão, me envie uma mensagem via carlos@wolkartt.com.

Fique à vontade para compartilhar este artigo. Peço apenas que você referencie o autor e este blog como fonte.

cisco asa security


Post Anterior
O que são Call Legs Toda chamada que passa por um voice gateway entra por um call leg e sai por outro call leg. Você pode traduzir “leg” como “perna”, mas o termo