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.108 ]

Por: Ricardo Lino Olonca em 24/05/2013


Instalando o iptables



O iptables é uma ferramenta que administra o módulo netfilter do sistema operacional e está presente desde a versão 2.4 do kernel.

Para usá-lo, é necessário possuir direitos administrativos no equipamento. No caso improvável de você não ter o iptables, basta instalá-lo através do gerenciador de aplicativos da tua distribuição.

No Debian, use:

# apt-get install iptables

Antes de entrarmos nas regras de firewall, é preciso entender como o iptables trabalha. O iptables possui 3 cadeias (chain), que são caminhos diferentes por onde os pacotes de rede passam.

Todo dado que se origina no firewall e o que está saindo dele, usa a chain OUTPUT. Pacotes destinados ao firewall, usam a chain INPUT.

Há ainda uma outra chain, FORWARD, destinada a tratar pacotes de dados que estão passando pelo firewall, mas não se originam nele e nem tem ele como destino; esse é o caso se você está configurando o firewall no gateway da rede.

Quando alguém em sua rede acessa a internet, por exemplo, esse dado passa pelo firewall, mas nem a origem e nem o destino são o firewall. A figura abaixo exemplifica isso:

As ações podem ser ACCEPT, REJECT e DROP. A diferença entre REJECT e DROP, é que REJECT envia uma resposta ao remetente. Enquanto que DROP, simplesmente descarta o pacote como se ele nunca tivesse existido.

Para listar as regras atuais, digite:

# iptables -L

 Chain INPUT (policy ACCEPT)
 target     prot opt source        destination

 Chain FORWARD (policy ACCEPT)
 target     prot opt source        destination

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source        destination


Para começar a brincadeira, vamos primeiramente ativar o Statefull, conforme expliquei acima:

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT


Fazendo isso, você evita a criação de duas regras para cada liberação.

Vamos ver as mudanças:

# iptables -L

 Chain INPUT (policy ACCEPT)
 target     prot opt source     destination
 ACCEPT     all  --  anywhere   anywhere     state RELATED,ESTABLISHED

 Chain FORWARD (policy ACCEPT)
 target     prot opt source     destination
 ACCEPT     all  --  anywhere   anywhere     state RELATED,ESTABLISHED

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source     destination
 ACCEPT     all  --  anywhere   anywhere     state RELATED,ESTABLISHED


Agora, vamos definir a regra padrão. Em um caso mais simples possível, considere que estamos criando as regras de firewall em um desktop normal (portanto, não teremos FORWARD).

Vamos configurar INPUT como DROP e OUTPUT, como ACCEPT. Em outras palavras, esse desktop poderá sair para qualquer lugar, mas ninguém poderá se conectar nele.

# iptables -P INPUT DROP
# iptables -P OUTPUT ACCEPT
# iptables -L

 Chain INPUT (policy DROP)
 target     prot opt source       destination

 Chain FORWARD (policy ACCEPT)
 target     prot opt source       destination

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source       destination


Agora podemos notar que a regra padrão de INPUT é DROP.

Vamos tentar pingar o desktop através de outro equipamento:

ping -c 1 172.20.1.145

 PING 172.20.1.145 (172.20.1.145) 56(84) bytes of data.

 --- 172.20.1.145 ping statistics ---
 1 packets transmitted, 0 received, 100% packet loss, time 0ms

arp -na | grep 172.20.1.145

 ? (172.20.1.145) em 00:25:90:2b:35:de [ether] em br0

Apesar de não termos resposta, podemos perceber pelo arp que o equipamento está na rede, pois a resolução ARP, como expliquei nos artigos anteriores, é feita antes que o firewall entre em ação.

Página anterior     Próxima página

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

Problemas encontrados na adoção do IPv6

O fim está próximo

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

MooseFS - Sistema de arquivos distribuído

Entendendo o TCP/IP

Leitura recomendada

Instalar e configurar o Nftables com exemplos básicos de configurações

Desvendando as regras de Firewall Linux Iptables

Análise da distribuição Mandrake Security

Construindo um Firewall / Proxy com o Fedora Core 4

Firewalls redundantes utilizando VRRP

  
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