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.

[ Hits: 37.106 ]

Por: Ricardo Lino Olonca em 24/05/2013


Nat / Outras informações



NAT (Network Address Translator) é o processo que altera um ou mais campos do cabeçalho IP.

O exemplo mais simples e utilizado é o mascaramento, que faz com que todas as estações de trabalho da rede interna saiam para a internet através de um único endereço IP válido.

Outro exemplo, é fazer com que uma requisição vinda da internet possa ser direcionada para uma máquina na rede interna, fazendo com que vários serviços (e-mail, HTTP, FTP) rodando em máquinas diferentes possam ser acessados tendo-se um único endereço válido.

Vamos analisar melhor no desenho abaixo:
Como expliquei em artigos anteriores, para que máquinas com IP privado (ex.: 172.20.x.x) acessem a Internet, é necessário fazer com que todas as estações saiam para a Internet com um IP válido.

No iptables, isso é feito com o seguinte comando:

# iptables -t nat -A POSTROUTING -j MASQUERADE

Isso faz com que todo tráfego que passar pelo firewall, irá sair com o IP da interface de saída. Se você quiser que somente os dados que saem para a Internet sejam mascarados, basta adicionar a interface de saída (vamos suporte que seja a eth1).

# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Enquanto a tabela de firewall possui três chains, a de NAT possui duas: PREROUTING e POSTROUTING. Como podemos ver na imagem acima, PREROUTING é usada ANTES do pacote entrar no firewall e POSTROUTING é usado DEPOIS de sair do firewall.

O NAT também é muito usado onde o gateway da rede também é o proxy. É comum usar, nessas situações, o proxy transparente, que nada mais é do que enviar os dados que estão saindo para a porta 80 e 443 e redirecioná-los para a porta do proxy.

Para fazer isso, é necessário tratar o pacote ANTES dele entrar no firewall, portanto, usamos a chain PREROUTING:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-ports 3128

Isso fará com que todo acesso de HTTP seja direcionado para a porta 3128, onde roda o proxy. Podemos também direcionar o tráfego para outro servidor.

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 172.20.120.4:3128

Uma outra possibilidade interessante do NAT é permitir que um único IP seja usado para disponibilizar diferentes serviços em diferentes servidores.

Vamos supor que você tenha um servidor Web com IP 172.16.10.80 e um outro servidor de e-mail com IP 172.16.10.25. Podemos direcionar o tráfego que chega pela internet para esses servidores.

# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to-destination 172.16.10.80:80
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 25 -j DNAT --to-destination 172.16.10.25:25


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.

Salvando e restaurando as regras

Eu costumo colocar as regras de firewall em um script que é executado no boot. Mas, há situações em que você pode salvar o estado atual do firewall para poder fazer várias alterações de teste.

Assim que os testes forem feitos, é possível restaurar o estado anterior. Isso é feito com o comando iptables-save:

# iptables-save > regras.lst

Para restaurar as regras anteriores, basta executar:

# iptables-restore < regras.lst

Módulos

Eu ia falar dos módulos que aumentam as opções do iptables, mas há um artigo muito bom escrito pelo Edson aqui mesmo no VOL:

Mais informações

Nos links abaixo, há mais informações sobre firewall e iptables.AX:
Página anterior    

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

Entendendo TCP/IP (Parte 5) - Portas TCP/UDP

Deduplicação com LessFS

Entendendo TCP/IP (parte 4) - DHCP

Entendendo o TCP/IP

MooseFS - Sistema de arquivos distribuído

Leitura recomendada

Incrementando seu Firewall com o Layer 7 Filter

IPFire - Um Firewall Open Source

Servidor Firewall-Proxy utilizando CentOS, IPtables, Squid, DHCP, DNS e outros

Script de Firewall com redirecionamento de portas em Linux Debian

Endian Firewall - Solução completa para um servidor de internet

  
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!!

[11] Comentário enviado por ricardoolonca em 11/07/2013 - 16:55h

Tem esse guia de bolso aqui.

http://www.novatemporeal.com.br/linux-iptables-guia-de-bolso-8576081024?keyword=iptables&model=1&aut...

Nunca li ele, mas tenho outros livros da série e costumam ser interessantes.

[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




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts