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

Por: Ricardo Lino Olonca em 24/05/2013


Liberações e bloqueios



Liberando acessos

Vamos agora liberar o ping para a tua máquina. Para isso, vamos adicionar uma regra na change INPUT (-A INPUT), permitindo (-j ACCEPT) o protocolo ICMP (-p icmp).

E para efeito de desempenho, vamos listar as regras de firewall (-L) sem a resolução de nomes dns (-n).

# iptables -A INPUT -p icmp -j ACCEPT
# iptables -nL

 Chain INPUT (policy DROP)
 target     prot opt source      destination
 ACCEPT     icmp --  anywhere    anywhere

 Chain FORWARD (policy ACCEPT)
 target     prot opt source      destination

 Chain OUTPUT (policy ACCEPT)
 target     prot opt source      destination

Testando o ping:

ping -c 1 172.20.1.145

 PING 172.20.1.145 (172.20.1.145) 56(84) bytes of data.
 64 bytes from 172.20.1.145: icmp_req=1 ttl=64 time=0.028 ms

 --- 172.20.16.60 ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 0.028/0.028/0.028/0.000 ms

Vemos que agora, o equipamento responde ao ping.

Você pode adicionar regras usando o "-I" ao invés de "-A". A diferença é que o "-I" adiciona a regra no top da tabela, enquanto que o "-A", adiciona no final.

* Lembre-se: as regras mais acima têm precedência em relação às que estão embaixo.

Especificando IP de origem e destino

Há situações que você precisa liberar um acesso apenas a alguns hosts. Por exemplo, você pode liberar acesso remoto em seu servidor apenas para as estações dos administradores do sistema.

Para isso, use o parâmetro "-s" (origem) e "-d" (destino):

# iptables -A INPUT -s 172.20.16.60 -j ACCEPT

Isso permite que o host 172.20.16.60 se conecte em qualquer porta.

# iptables -A OUTPUT -d 8.8.8.8 j DROP

Isso bloqueia o acesso a qualquer porta do IP 8.8.8.8.

Especificando o tipo de protocolo

Para começar a ser mais específico, podemos especificar qual o tipo que porta você quer bloquear. Por exemplo, para bloquear todos os pacotes TCP, permitindo somente o UDP, devemos usar o parâmetro "-p":

# iptables -A INPUT -s 172.20.16.60 -p udp -j ACCEPT

Podemos ser ainda mais específicos, liberando o acesso somente à porta 53 UDP (DNS) usando o parâmetro "--dport":

# iptables -A INPUT -s 172.20.16.60 -p udp --dport 53 -j ACCEPT
# iptables -A INPUT -s 172.20.16.60 -j DROP.


Podemos perceber na primeira regra, que o host 172.20.16.60 tem liberado a resolução de nomes (UDP 53). Na segunda regra, está sendo bloqueado qualquer outro tipo de acesso deste host.

Trabalhando com a chain FORWARD

Agora que você já sabe o básico do iptables, vamos partir para a configuração de um firewall de rede.

Vamos supor que você tenha um equipamento com duas placas de rede, a eth0 ligada na tua rede local, e eth1 na internet. Primeiramente, temos que habilitar o roteamento:

# sysctl net.ipv4.ip_forward=1

Como eu mostrei nos outros artigos da série, é necessário que as estações da rede saiam para a internet com o IP externo do firewall.

Para fazer isso, digite o comando abaixo:

# iptables -t nat -A POSTROUTING -j MASQUERADE

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:
Note que o IP mostrado é o do firewall, e não o teu.

Agora, para liberar o acesso da rede interna à navegação (HTTP e HTTPS), digite:

# iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
# iptables -A FORWARD -p tcp --dport 443 -j ACCEPT


Especificando as interfaces nas regras de firewall

Para evitar um ataque do tipo IP spoofing, você pode especificar as interfaces de rede nas regras do iptables. Vamos supor que a eth0 seja a interface da rede interna e eth1, a interface da internet:

# iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 80 -j ACCEPT

Em outras palavras, a regra acima permite (ACCEPT) o acesso da HTTP (-p tcp --dport 80) que esteja entrando pela rede interna (-i eth0) e saindo pela interface de internet (-o eth0).

# 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).

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

MooseFS - Sistema de arquivos distribuído

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

Problemas encontrados na adoção do IPv6

Deduplicação com LessFS

Entendendo TCP/IP (Parte 3) - Resolução de nomes

Leitura recomendada

Incremente o iptables com patch-o-matic

Construindo um Firewall / Proxy com o Fedora Core 4

Integrando Layer7 + IPP2P ao Iptables

L7-filter (funcionando) no Slackware 10.2

PFSense Firewall com Squid e SquidGuard

  
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