Tempo de atividade e segurança de firewall com iptables

Configure e mantenha um firewall Linux com este aplicativo eficaz

Iptables é o aplicativo de firewall Linux® padrão. É fácil de configurar e manter e, ao mesmo tempo, é eficiente o suficiente para oferecer o controle esperado de um dispositivo de topo de linha. Saiba como começar a trabalhar com iptables, recuperar-se de problemas comuns e simular um cenário de uso de escritório pequeno.

Alfredo Deza, Software Engineer

Photo of Alfredo DezaAlfredo Deza é engenheiro de software, ex-atleta profissional e olímpico com forte formação em administração de sistema. Ele é apaixonado por software livre e é orador regular em grupos de tecnologia local e conferências internacionais, como a PyCon. Em seu tempo livre, ele tenta melhorar suas habilidades com a fotografia e gosta de contribuir para projetos de software livre.



28/Dez/2011

Introdução

Iptables é um aplicativo que permite a administração de tabelas no firewall do kernel Linux. Não é necessário ter conhecimento prévio sobre o kernel, nem sobre as tabelas dentro dele, para modificar o firewall e executar tarefas comuns de administração de sistema.

Em algumas distribuições Linux, o iptables vem ativado por padrão. É comum para usuários sem experiência recomendar a desativação do iptables para evitar problemas de rede. Este artigo ajudará você a começar a trabalhar rapidamente e a manipular o iptables de acordo com suas necessidades.

Às vezes, o iptables é usado para se referir ao componente no nível do kernel Linux. Neste artigo, qualquer coisa relacionada ao iptables refere-se especificamente ao aplicativo que controla os protocolos em uma distribuição Linux como ipv4, ipv6 e as tabelas ARP.

De forma semelhante a outros aplicativos Linux, é possível configurar o iptables na interface de linha de comandos ou em um arquivo de texto simples, permitindo a edição com qualquer editor de texto. Apesar de ser fácil de modificar, pode parecer um pouco desajeitado em comparação com os dispositivos de firewall usuais em que a maior parte da interação com as definições e configurações é feita em uma interface gráfica. Há aplicativos que usam iptables para gerenciar um firewall por meio de interfaces gráficas, mas este artigo abordará a interação com o iptables em seu ambiente nativo: o terminal Linux.

Uma certa familiaridade com o uso do terminal Linux (também chamado de console ou emulador de terminal) ajudará os desenvolvedores a tirar proveito dos exemplos e configurações apresentados a seguir. A interface de linha de comandos é a principal forma de interagir com o iptables, e um terminal Linux é o aplicativo que permite acesso a essa interface.

As regras que são aplicadas são em sua maioria muito legíveis e facilmente portadas para outros servidores. Esse recurso economiza um tempo significativo ao lidar com hardware que não responde.

Requisitos de aplicativos

Apesar de o iptables ser o principal assunto deste artigo, e provavelmente já estar instalado em seu ambiente, também usaremos nmap, que é outro eficiente aplicativo.

Verifique se o nmap está instalado antes de continuar. É possível instalar esse efetivo scanner de rede em uma distribuição Linux Debian/Ubuntu.

Listagem 1. Instalando o nmap no Debian/Ubuntu
sudo apt-get install nmap

Introdução

Quase todas as distribuições Linux vêm com o iptables instalado e pronto para o uso. Certifique-se de quem você tenha o comando iptables disponível em seu shell preferencial. Este artigo usa convenções do Debian/Ubuntu para configurar o iptables.

Como iremos fazer modificações no nível do kernel, certifique-se de que você tenha privilégios de administrador.

Listagem 2 mostra as regras que estão sendo aplicadas atualmente no servidor. A Listagem 2 será repetida durante o artigo para verificar quais regras estão atualmente em uso e para verificar mudanças bem-sucedidas.

Listagem 2. Regras atualmente aplicadas
root@desktop:~# 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

Na Listagem 2, instruímos o iptables a relacionar todas as regras aplicadas atualmente ao firewall. Isso é realizado pelo sinalizador -L .

A saída também menciona Chain. Conceba as cadeias do iptable como seções no firewall que permitem um certo tipo de tráfego. Por exemplo, para bloquear todo o tráfego da rede privada para a Internet, a regra deveria ser configurada na seção OUTPUT. Da mesma maneira, qualquer regra que afete o tráfego de entrada seria relacionada na cadeia INPUT.

Cada uma das três cadeias é aplicada a um tipo de atividade no firewall. Neste momento, não há nada configurado ainda. Isso significa que não há restrições e que é permitido que todo o tráfego de rede entre e saia.

  • Chain INPUT
  • Chain FORWARD e
  • Chain OUTPUT

Antes de continuar, é necessário verificar quais portas estão abertas no servidor, para comparação depois dele ser bloqueado. Como mencionado antes, o nmap é uma eficiente ferramenta de linha de comando que fornece informações de segurança de rede. Listagem 3 mostra a saída do nmap em um servidor remoto na rede.

Listagem 3. Varredura de rede com o nmap
~ $ nmap 10.0.0.120

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-21 20:44 EST
Nmap scan report for 10.0.0.120
Host is up (0.012s latency).
Not shown: 991 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
631/tcp  open  ipp
3306/tcp open  mysql
4001/tcp open  unknown
5900/tcp open  vnc
8080/tcp open  http-proxy

Nmap done: 1 IP address (1 host up) scanned in 6.57 seconds

São muitas portas abertas! Em poucas etapas, você aprenderá como os dados acima mudam quando o iptables é configurado.

Virtual nem sempre é melhor

À medida que você aprende sobre o iptables, pode ser melhor seguir os exemplos neste artigo em um computador com Linux instalado em vez de em uma máquina virtual (VM). As políticas de rede entre um host de VM e um convidado de VM podem tornar a depuração difícil, e alguns exemplos não funcionarão. Comece com um ambiente físico e depois passe para os ambientes virtuais mais avançados.

As regras de firewall podem ser aplicadas e anexadas, ou editadas manualmente em um arquivo de texto simples, e originadas. Prefiro usar um arquivo de texto para aplicar as mudanças. Na maioria das vezes, os erros de sintaxe são mais fáceis de perceber quando estão escritos em um arquivo de texto. Surge outro problema ao editar as regras anexando-as diretamente, isto é, essas regras não serão salvas quando um servidor for reiniciado. Antes de editar o arquivo, vamos mandar o iptables exportar as regras atuais para que o arquivo se torne nosso modelo inicial. Consulte a Listagem 4.

Listagem 4. Salvando regras em um arquivo
root@desktop:~# iptables-save > /etc/iptables.rules
root@desktop:~# cat /etc/iptables.rules 
# Generated by iptables-save v1.4.4 on Sun Nov 21 14:48:48 2010
*filter
:INPUT ACCEPT [732:83443]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [656:51642]
COMMIT
# Completed on Sun Nov 21 14:48:48 2010

Usei o comando iptables-save e redirecionei a saída para um arquivo de texto no diretório "/etc". Concatenei o arquivo para que você possa ver a aparência do arquivo na minha máquina.

Um dos primeiros requisitos é permitir que conexões estabelecidas recebam tráfego. Isso é necessário quando você desejar que alguma coisa por trás do firewall (em uma rede privada) seja capaz de enviar e receber dados de rede sem restrições. Na Listagem 5 emitiremos uma regra direta para o iptables e, depois disso, verificaremos o estado do firewall.

Listagem 5. Regra de sessões estabelecida
root@desktop:~# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            ctstate RELATED,ESTABLISHED 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Para termos uma ideia melhor do que foi emitido, vamos decompor o comando e explicar cada um:

-A INPUT: Anexe esta regra à cadeia INPUT .

-m conntrack: Corresponda o seguinte rastreamento de conexão para a conexão/pacote atual.

-ctstate ESTABLISHED, RELATED: Estados de conexão aos quais a regra de se aplicar. Nesse caso, uma conexão ESTABLISHED significa uma conexão que viu pacotes em ambas as direções, e um tipo RELATED significa que o pacote está iniciando uma nova conexão mas está associado a uma conexão existente.

-j ACCEPT: diz ao firewall para aceitar as conexões descritas anteriormente. Outra configuração válida para o sinalizador -j seria DROP

Também está se conectando pelo protocolo SSH a esse servidor, então antes de bloquear o firewall, uma regra na Listagem 6 irá permitir todo o tráfego SSH de entrada. Eu especifico o tipo de protocolo de rede (tcp) e a porta que está convenientemente associada ao serviço SSH. É possível especificar o número da porta de forma direta se necessário.

Listagem 6. Aceitando conexões SSH de entrada
root@desktop:~# iptables -A INPUT -p tcp --dport ssh -j ACCEPT
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            ctstate RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Finalmente, vamos configurar o firewall para bloquear todo o resto. Tome muito cuidado ao emitir o comando a seguir. Se for colocado antes de todas as outras regras, ele irá bloquear todo o tráfego para o servidor. O iptables lê as regras de modo processual (de cima para baixo) e, depois que uma regra é correspondida, nada mais é avaliado.

Listagem 7. Bloqueando todo o tráfego de entrada
root@desktop:~#  iptables -A INPUT -j DROP
root@desktop:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            ctstate RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

A Listagem 7 mostra que as regras estão na ordem certa, mas para podermos fazer mudanças específicas, vamos salvar as regras em um arquivo e o concatenar para verificar o conteúdo como na Listagem 8 .

Listagem 8. Verificando a configuração do firewall
root@desktop:~# iptables-save > /etc/iptables.rules 
root@desktop:~# cat /etc/iptables.rules 
# Generated by iptables-save v1.4.4 on Sun Nov 21 15:10:42 2010
*filter
:INPUT ACCEPT [1234:120406]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1522:124750]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -j DROP 
COMMIT
# Completed on Sun Nov 21 15:10:42 2010

O comando iptables-=save passou nossas mudanças para um arquivo de texto simples. Ele tem a aparência um pouco diferente de uma simples listagem de regras na linha de comando, mas é exatamente a mesma coisa. Assim como antes, temos três seções: INPUT, FORWARD e OUTPUT. As regras que especificamos inicialmente referem-se a conexões OUTPUT; assim, esta é a seção em que as regras que incluímos são colocadas.

Neste momento, o servidor está bloqueado e a configuração foi salva em um arquivo. Mas o que ocorre quando executamos uma varredura de rede? Vamos executar o nmap novamente junto a esse servidor e verificar os resultados conforme mostrado na Listagem 9.

Listagem 9. Varredura de rede com servidor bloqueado
~ $ nmap 10.0.0.120    

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-21 20:56 EST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.04 seconds

~ $ nmap -Pn 10.0.0.120

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-21 20:56 EST
Nmap scan report for 10.0.0.120
Host is up (0.017s latency).
Not shown: 999 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh

Nmap done: 1 IP address (1 host up) scanned in 12.19 seconds

Observe que foi tentada uma varredura junto ao IP em que o servidor está localizado, mas o nmap não relacionou as portas abertas. Isso ocorre porque o firewall está configurado de tal maneira que ele bloqueia tudo exceto a porta SSH que temos aberta. Como o nmap usa um protocolo de rede específico para verificar se o host ainda está ativo, ele retornou vazio. A segunda tentativa foi bem-sucedida e está nos dizendo que apenas SSH está aberta e nada mais. Com apenas três regras, conseguimos obter um bloqueio efetivo do nosso servidor.

Salvando e restaurando regras

Na seção anterior, nós salvamos as regras em um arquivo de texto. Porém, isso não diz efetivamente ao servidor que ele precisa carregar as regras. Além disso, quando o servidor é reiniciado, ele perde todas as configurações realizadas.

Se você estiver incluindo as regras na linha de comando, já deve estar familiarizado com o salvamento dessas mudanças em um arquivo de texto. Consulte a Listagem 10 para salvar as regras de firewall.

Listagem 10. Salvando as regras de firewall
iptables-save > /etc/iptables.rules

Dependendo do sistema operacional em uso, há várias maneiras de fazer com que essas regras sejam carregadas durante a inicialização. Uma abordagem fácil consiste em ir até a única interface voltada ao público e pedir que ela carregue essas regras antes de trazer a interface on-line. Consulte a Listagem 11.

Listagem 11. Regras de carregamento de interface de rede pública
<![CDATA[
auto eth0
iface eth0 inet static
  address 99.99.99.0
  netmask 255.255.255.0
  pre-up iptables-restore < /etc/iptables.rules
]]>

Aqui temos a interface eth0 e estamos declarando uma regra para carregar as regras antes de ativar a interface. Como deve ter imaginado, você pode usar esses comandos para atualizar as regras de firewall manualmente a partir do arquivo ou no arquivo.


Recuperação de desastres

Há pouco tempo, eu estava em uma situação em que era responsável por um dispositivo de firewall. Apesar de estar assegurando que fossem feitos backups periódicos das regras e configurações, não percebi que esses backups estavam em um formato proprietário que só era legível pelo modelo do dispositivo que eu tinha. Isso não representa um problema, naturalmente, desde que você tenha dois dispositivos da mesma marca, modelo e versão de firmware; mas, como é comum em pequenas empresas, o orçamento não permitia mais nada.

Um dia, o dispositivo decidiu não funcionar mais, e eu tive que implementar rapidamente algo que pudesse ser confiável (ou melhor). Aprendi da maneira mais difícil que possuir configurações legíveis por seres humanos e a capacidade de voltar à atividade rapidamente são ativos muito importantes.

Com alguma sorte, encontrei um servidor antigo em boa condição com algumas interfaces de rede, e fui capaz de substituir o dispositivo inoperante.

Até o momento, examinamos cenários de obtenção de uma cópia das regras que poderiam ser aplicados a qualquer servidor em caso de falha. Agora vamos ativar o firewall para ser o principal gateway de uma rede residencial ou de negócios.


Iptables como gateway principal

Até aqui, tudo o que abordamos é ótimo se você estiver executando o iptables em um computador pessoal, mas não faz muito sentido se o escritório inteiro precisa compartilhar uma conexão à Internet. Com algumas definições de configuração, podemos configurar isso adequadamente.

Um servidor gateway precisa de pelo menos duas interfaces de rede para poder servir como um gateway adequado. Uma interface "falaria" com a conexão voltada ao público e a outra com o público interno e protegido.

Vamos presumir que o servidor possui duas interfaces de rede físicas:eth0 (pública) e eth1 (privada). Preciso juntá-las por NAT para que o tráfego de rede flua sem interrupções de uma interface para a outra. A sub-rede de rede privada é 192.168.0.0/255.255.0.0; portanto, vamos ver como seria uma regra NAT com encaminhamento. Listagem 12..

Listagem 12. NAT and forwarding rules
iptables -A FORWARD -s 192.168.0.0/255.255.0.0 -i eth0 -o eth1 -m\
conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A POSTROUTING -t nat -j MASQUERADE

A Listagem 13 mostra como modificar algumas configurações em proc para ativar o encaminhamento no servidor.

Listagem 13. Ativando o encaminhamento no servidor
sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

Observe que as mudanças em proc são voláteis, portanto quaisquer mudanças feitas são perdidas após uma reinicialização. Há várias maneiras de nos certificarmos de que as notificações permanecerão após uma reinicialização. Nas distribuições Debian/Ubuntu, inclua as linhas a serem executadas em /etc/rc.local.

Finalmente, como mostrado na Listagem 14, há mais uma mudança de configuração que modifica os parâmetros do kernel no tempo de execução sysctl. Essas configurações geralmente já estão no sysctl.conf, mas suas linhas estão comentadas. Retire as marcas de comentário (ou as adicione se elas não forem incluídas na sua distribuição).

Listagem 14. Sysctl/kernel forwarding
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.all.forwarding=1

Limite de DNS

A execução de um servidor Linux como gateway causará certos problemas com o DNS. O kernel é projetado para manter uma tabela de mapeamentos DNS, mas ele vem com um nível máximo de entradas que não é adequado para tráfego pesado. Quando esse nível for atingido, nenhuma consulta DNS pode voltar ao host que a fez. Apesar de esse limite ser raramente atingido com poucos clientes, mais de trinta clientes passando por esse firewall causará problemas.

O ambiente pode precisar de alguns ajustes, mas os valores mostrados na Listagem 15 devem fornecer espaço antes que esses problemas com o DNS sejam vistos.

Listagem 15. Aumentando o limite de DNS
echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

Fique atento a mensagens semelhantes àquela naListagem 16, que fornecerão um aviso se for necessário aumentar os números recém-fornecidos.

Listagem 16. Avisos de estouro de DNS de log do sistema
Nov  22 11:36:16 firewall kernel: [92374.325689] Neighbour table overflow.
Nov  22 11:36:20 firewall kernel: [92379.089870] printk: 37 messages suppressed.
Nov  22 11:36:20 firewall kernel: [92379.089876] Neighbour table overflow.
Nov  22 11:36:26 firewall kernel: [92384.333161] printk: 51 messages suppressed.
Nov  22 11:36:26 firewall kernel: [92384.333166] Neighbour table overflow.
Nov  22 11:36:30 firewall kernel: [92389.084373] printk: 200 messages suppressed.

Conclusão

Seguimos algumas etapas simples para fazer com que o iptables fosse executado adequadamente e para bloquear um servidor Linux com segurança. As regras aplicadas devem fornecer uma boa ideia do que está acontecendo em um servidor que usa iptables como firewall. Incentivo você a testar o iptables, principalmente se depender de um dispositivo e desejar mais controle e configurações legíveis por seres humanos e facilmente replicáveis.

Apesar das regras que usamos aqui serem simples, a flexibilidade e complexidade do iptables está muito além do escopo deste artigo. Há muitas regras complexas que você pode combinar para criar um ambiente de firewall seguro e controlável.

Um exemplo de um recurso avançado interessante no iptables é o balanceamento de carga. Na maioria das vezes, ao explorar serviços da web de alta disponibilidade, você está procurando soluções de balanceamento de carga. Com o iptables, isso pode ser definido e configurado com os sinalizadores random ou nth .

Você também pode fazer regras baseadas em tempo. Em ambientes de pequenos escritórios, pode ser útil restringir certos serviços de segunda a sexta, mas permitir que o firewall se comporte de forma diferente entre sábado e domingo. Os sinalizadores que podem funcionar em tal caso são: --timestart, --timestop e days.

Um problema que tive foi não possuir dois firewalls ao mesmo tempo com algum tipo de failover. A criação de tal coisa não é uma tarefa simples, mas pode ser abordada de várias maneiras. A solução mais fácil seria fazer com que o roteador assumisse o trabalho e fizesse o balanceamento de carga de dois servidores de firewall idênticos. Recomendo investigar essa opção se o ambiente de rede for um ativo crítico como um escritório ou pequena empresa.

O Iptables me salvou uma vez, e espero que faça o mesmo por você!

Recursos

Aprender

Obter produtos e tecnologias

  • Avalie produtos de software IBM: a partir de downloads de teste para produtos hospedados na nuvem, é possível inovar no seu próximo projeto de desenvolvimento de software livre usando software especialmente para desenvolvedores.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Linux
ArticleID=783112
ArticleTitle=Tempo de atividade e segurança de firewall com iptables
publish-date=12282011