Pular para o conteúdo

Entendendo TCP/IP (Parte 6) - Firewall

Neste artigo, o sexto da série, vou explicar o funcionamento de um firewall e mostrar como o iptables funciona.
Ricardo Lino Olonca ricardoolonca

Por Ricardo Lino Olonca em 24/05/2013

Hits: 38.826 Categoria: Linux Subcategoria: Firewall
  • Indicar
  • Impressora
  • Denunciar

Introdução

Vejo aqui no VOL e em outros fóruns, pessoas tirando dúvidas sobre o IPtables e notei que a maioria das dúvidas, se deve ao fato da pessoa não entender da tecnologia em questão, ou seja, não sabe como funciona um firewall, e nem o próprio TCP/IP.

Por isso, decidi escrever uma série de artigos sobre rede e agora chegou a vez do firewall. Se você não sabe o que são portas TCP e UDP, sugiro ler os meus artigos anteriores:

Funcionamento de um firewall

Basicamente, um firewall é um software que trabalha bloqueando ou liberando as conexões de rede, de acordo com regras pré-estabelecidas baseadas no endereço de origem, no endereço de destino e na porta de destino (serviço) da conexão.

Acontece que, a maioria dos software de firewall de hoje, senão todos, possuem outras características além do firewall em si. Mas, para entendermos melhor os conceitos, vamos nos ater ao básico neste momento.

O firewall sempre lê as regras de cima para baixo, executando a ação descrita na primeira regra onde o pacote se encaixar. Por exemplo, a regra 2 abaixo, nunca será executada:

Neste caso, o correto é colocar a regra 2 antes da 1.

Stateless x Statefull

Quando uma conexão é permitida no firewall, é evidente que a volta também será. Por exemplo, para permitirmos que o firewall navegue na internet, devemos criar a seguinte regra (reparem agora na porta de origem):

Essa segunda regra é necessária para liberar também a volta do pacote, que agora tem como porta de origem, a porta 80 (HTTP). Fica evidente que para cada regra de firewall, uma segunda regra deverá ser feita para permitir a volta do pacote.

Para evitar isso, os firewalls atuais trabalham com o conceito de Statefull. Isso permite que uma regra temporária seja automaticamente criada quando um dado passa pelo firewall permitindo a volta do pacote.

O IPtables pode trabalhar tanto com Stateless, como com Statefull. Veremos isso mais pra frente.

Páginas do artigo

   1. Introdução
   2. Instalando o iptables
   3. Liberações e bloqueios
   4. Nat / Outras informações

Outros artigos deste autor

Deduplicação com LessFS

O fim está próximo

Entendendo TCP/IP (parte 4) - DHCP

Entendendo TCP/IP (parte 2) - Endereços IP

Problemas encontrados na adoção do IPv6

Leitura recomendada

OpenVPN - Instalação e configuração

Implementando prioridade nos serviços com TOS no Iptables

IPFire - Um Firewall Open Source

Firewall profissional

Criando um firewall simples e compartilhando a conexão usando o IPtables

Comentários

#1 Comentário enviado por Buckminster em 24/05/2013 - 06:21h
"Há situações onde o gateway possui vários IPs e eu preciso que determinado acesso seja feito por um IP diferente do padrão. Por exemplo, se meu servidor possui dois endereços 200.200.100.50 (padrão) e 200.200.100.60 e eu preciso fazer com que POP3 sempre saia pelo 60.

Neste caso, eu vou usar a chain POSTROUTING, pois estou trabalhando na SAÍDA:

# iptables -t nat -A POSTROUTING -i eth1 -p tcp --dport 110 -j SNAT --to-source 200.200.100.60

Lembrando que essa regra deve vir antes da regra de MASQUERADE, pois o iptables é top-down, ou seja, as regras mais acima são executadas primeiro."

-- Acredito que neste caso não se pode utilizar o MASQUERADE.
O MASQUERADE somente se usa no IPtables quando o IP da placa de rede de entrada da Internet/dados está dinâmico (ou automático).
Todas as regras para os vários IPs do gateway, nesse caso, devem ser com SNAT.

"# iptables -A FORWARD -i eth0 -o eth1 -s 172.20.16.60 -d 8.8.8.8 -p udp --dport 53 -j ACCEPT

Acima, a regra permite (-j ACCEPT) que pacotes de DNS (-p udp --dport 53) vindos de 172.20.16.60 (-s 172.20.16.60) com destino ao DNS do Google (- d 8.8.8.8) entrando pela interface da LAN (-i eth0) e saindo pela interface de internet (-o eth1) atravessem o firewall (-A FORWARD)."

-- Note que especificar qualquer nome a ser resolvido com uma consulta remota, como a um DNS, é uma ideia muito ruim.


"Não se preocupe em entender esse comando agora, pois vou explicá-lo mais pra frente neste artigo. A princípio, tenha em mente que esse comando vai fazer com que todos as estações da rede saiam com o IP do firewall.

Para comprovar isso, acesse: http://meuip.datahouse.com.br/

Note que o IP mostrado é o do firewall, e não o teu."

-- O IP mostrado não é o do firewall, é o do modem/roteador.

Mas está bom o artigo.
#2 Comentário enviado por ricardoolonca em 24/05/2013 - 13:06h

[1] Comentário enviado por Buckminster em 24/05/2013 - 06:21h:

-- Acredito que neste caso não se pode utilizar o MASQUERADE.
Você pode usar MASQUERADE e SNAT, mesmo com ip fixo, desde que SNAT seja colocado antes de MASQUERADE.

-- Note que especificar qualquer nome a ser resolvido com uma consulta remota, como a um DNS, é uma ideia muito ruim.
Correto. Mas a regra foi colocada apenas para exemplificar o funcionamentos do firewall e da chain FORWARD. Nesse caso, um dns interno seria recomendado.

-- O IP mostrado não é o do firewall, é o do modem/roteador.
Depende do caso, Na minha rede o roteador não faz nat, Quem recebe o ip válido é o firewall mesmo. O importante é saber que o "pacote" de rede sai do firewall com o ip do firewall, e não com o ip do host que originou o pacote.



#3 Comentário enviado por Buckminster em 24/05/2013 - 13:44h
"masquerade :: Este alvo só é válido na tabela nat na chain postrouting. Ele só deve ser utilizado com IP atribuído dinamicamente (dialup): se você tem um endereço IP estático, você deve usar o alvo snat."

Isso é o que está no Manual do IPtables, pois é considerado uma falha utilizar masquerade com IP fixo.

Na tua rede é o IPtables que faz o papel de roteador?

Quantas máquinas tem na tua rede interna?

Você fez somente o compartilhamento no IPtables ou fez alguma outra configuração a mais para ele fazer o papel do roteador?
#4 Comentário enviado por ricardoolonca em 24/05/2013 - 15:35h
Se você tem um firewall com várias vlans, usar MASQUERADE pode facilitar as coisas. E também pode dificultar. Tudo depende da topologia da rede, das regras do firewall, dos roteamentos, etc.

Aqui o Iptables faz o papel de roteador. Aliás, como disse no início do artigo, hoje é difícil ter um firewall que seja somente firewall. Os próprios D-LInk e TP-Link caseiros são roteadores que possuem firewall. E todo firewall de rede também faz a função de roteador.

Hoje administro uma rede com cerca de 1200 equipamentos. O firewall possui 6 vlans, e possui cluster com dois equipamentos. Temos 3 links de 100 mbps. Os links são de dados, e não de Internet. Esses links ligam a empresa a um backbone de outra empresa parceira que possui links de Internet de 1gbps. Mas também trabalhei em uma empresa com 35.000 equipamentos. Nesta, o firewall (Checkpoint) estava atrás de um roteador (Cisco). Porém, o firewall também tinha um endereço válido, e o Cisco não fazia nat.

O firewall aqui também possui proxy Squid, Ips, regras de controle de banda e algumas ferramentas de análise de rede. Também possui algumas regras de nat, direcionamentos, etc.
#5 Comentário enviado por Buckminster em 24/05/2013 - 16:31h
Perguntei se você tinha feito alguma outra configuração no IPtables porque fazer o NAT no IPtables não o transforma num roteador no sentido estrito de roteamento com tabelas. Ele simplesmente faz a tradução de endereços de rede (NAT).

No momento que você desabilita o NAT no roteador (um Cisco, por exemplo) ele continuará fazendo as rotas ou procurará o roteador mais perto para fazer isso por ele (depende do aparelho).

E só por uma questão de definição: o IPtables não é um firewall, é um filtro de pacotes.
Um firewall é um sistema de servidores, vários servidores atuando em conjunto.

Mas enfim, é somente uma questão técnica, se tudo aí está funcionando a contento, isso é que é o importante.
#6 Comentário enviado por ricardoolonca em 26/05/2013 - 19:44h
Mas eu não falei que habilitar o Nat transforma o equipamento em um roteador. Habilitar a função de roteamento envolve a implantação de um protocolo de rotamento, como o Rip. Explico isso em meu segundo artigo. O Nat apenas faz a tradução do endereço ip.

O Iptables não é um firewall? Como não? Uma das definições de firewall diz que firewall é um filtro de pacote. O Iptables é, sim, um firewall, mas não é só isso. Ele também possui outras funções. Acho que você está confundindo firewall com cluster. Vários servidores trabalhando junto (para aumentar o desempenho ou para aumentar a disponibilidade) chama-se cluster. Veja o texto da wikipedia em http://pt.wikipedia.org/wiki/Cluster.
#7 Comentário enviado por Buckminster em 27/05/2013 - 13:42h

Cara, um sistema de firewall envolve um IPS (sugiro o HLBR), um IDS, um Honey Pot, o Squid, talvez uma DMZ, quem sabe um proxy DNS, e, claro, o iptables instalado em cada servidor integrante do firewall (menos no HLBR), além de outros. Foi isso que eu quis dizer.

Nada a ver com cluster. Mas por falar em cluster, estou montando um aqui em casa.

E não me leve a mal, mas a Wikipédia não é fonte de pesquisa válida, pois não tem um único autor, além disso tem muita informação errada.

É só ver pela própria definição de cluster:

"Um cluster, ou aglomerado de computadores, é formado por um conjunto de computadores, que utiliza um tipo especial de sistema operacional classificado como sistema distribuído."

Um cluster NÃO utiliza um tipo especial de sistema operacional, além disso, um sistema distribuído NÃO é um sistema operacional.
A própria Internet pode ser considerada um sistema distribuído funcionando através dos navegadores.

Um cluster, como o Beowulf, por exemplo, é uma API (uma biblioteca), ou melhor, são duas (você escolhe dependendo do tipo de cluster que você quer) instalada no Linux (ou no Unix) ou outro sistema; e pode ser considerado um sistema distribuído, mas nada a ver com sistema operacional. Um cluster funciona em cima de um sistema operacional.
A não ser que você construa seu próprio sistema operacional habilitado para cluster, mas mesmo assim, tecnicamente, o cluster não seria o sistema operacional.
#8 Comentário enviado por ricardoolonca em 27/05/2013 - 22:13h
É, há um problema de definição aqui. Firewall é firewall. Ips é ips. Um sistema de firewall não precisa ter ips. Não precisa ter honeypot. Não precisa tem proxy. Como disse no artigo, o conceito de firewall envolve bloqueios e liberações baseados em ip e porta. Só. Nada mais. Mas há, sim, softwares, como Checkpoint, que são vendidos como firewall, mas contém outras ferramentas, como proxy, nat, vpn e ips.
#9 Comentário enviado por sergin1rn em 05/06/2013 - 10:08h

[8] Comentário enviado por ricardoolonca em 27/05/2013 - 22:13h:

É, há um problema de definição aqui. Firewall é firewall. Ips é ips. Um sistema de firewall não precisa ter ips. Não precisa ter honeypot. Não precisa tem proxy. Como disse no artigo, o conceito de firewall envolve bloqueios e liberações baseados em ip e porta. Só. Nada mais. Mas há, sim, softwares, como Checkpoint, que são vendidos como firewall, mas contém outras ferramentas, como proxy, nat, vpn e ips.


Ricardo,

Estes equipamentos checkpoint, fortigate, cisco ASA, sonicwall são chamados de UTMs, por isso tem todas estas funções de proxies, vpn, ips, etc. Eles também tem a função de firewall.

Buckminster

Não necessáriamente um firewall tem que ter tudo isso que você falou, mas quem quer ter uma rede protegida é aconselhável tudo isso sim...
#10 Comentário enviado por slackhigh em 11/07/2013 - 06:26h
Fala Ricardo, blz? parabéns pelo artigo

Você tem algum livro para recomendar para quem esta iniciando nesta questão do iptables?

vlw!!
#12 Comentário enviado por atacama2020 em 29/05/2014 - 10:57h
Tem alguma solução UTM free que oferece os mesmos serviços que um UTM como o chekpoint, fortigate, sonicwall, aker, whatsguard?

Contribuir com comentário

Entre na sua conta para comentar.