[atualizado] Usando o Iptables como Firewall no Nível de Aplicação e como IDS
A pouco tempo atrás a empresa em que trabalhava me enviou a um cliente para implantar um sistema de controle de acesso a internet utilizando um firewall com Iptables e sem um Proxy. Não sei porque eles me mandaram fazer isto, talvez por redução de custo por parte do cliente.
O fato é que, embora possamos fazer o iptables trabalhar como se fosse um proxy, isto não é nada recomendado e no final das contas foi mais complicado para mim executar esta tarefa do que se eu tivesse instalado um Squid como proxy. Mas isso me possibilitou avançar no estudo de alguns módulos do iptables pouco conhecidos e utilizados.
Normalmente utilizamos um proxy como firewall em nivel de aplicação, para efetuarmos filtragem baseado no conteudo do pacote. Assim podemos bloquear determinadas paginas e anexos, baseado em nomes de URLs e extensões de arquivos.
Embora, não seja o mais recomendado podemos fazer com que o iptables trabalhe “simulando” no nível de aplicação.
Podemos dividir os tipos de firewall basicamente em dois tipos (retirado do foca-linux):
1 - Firewall de Aplicação: Este tipo de firewall analisam o conteúdo do pacote para tomar suas decisões de filtragem. Servidores proxy, como o Squid, são um exemplo deste tipo de firewall.
2) Firewall de Pacotes: Este tipo de firewall toma as decisòes baseadas nos parametros dos pacotes como porta/endereço de origem/destino, estado da conexão e, e outros parametros do pacote. Exemplos são o próprio iptables, ipfw, ipfilter e o Pix.
O iptables trouxe o conceito de arquitetura modular, agora user-code módulos são possíveis. Os modulos são programados no nível do kernel mas podem ser carregados no espaço no usuario com o uso do comando modprobe.
Dois móulos são interessantes pois fazem uma inspeção em todo o payload do pacote e elevam a funcionalidade do iptables para além de uma simples inspeção do modelo TCP/IP: Modulo String e Módulo Pkttype.
1) Modulo String:
Disponivel no Iptables desde a versão 1.2.3 (antes era experimental). O uso deste módulo permite elevar o iptables para filtragem no layer 7 (aplicação) e torna a filtragem muito mais rápida (3 a 10 vezes) em relação a um proxy como squid.
## Bloqueando acesso a pacotes que contem “playboy” e gerando log
iptables -A FORWARD -m string –string “playboy” -j LOG — log-prefix ” Acesso a Playboy”
iptables -A FORWARD -m string –string “playboy” -j DROP## Limitando acesso a qualquer dados que contenham no payload “orkut” a 1/m
iptables -A FORWARD -m string –string “orkut” -m limit –limit 1/m -j ACCEPT## Bloqueando o acesso a mp3 e logando
iptables -A FORWARD -m string –string “.mp3″ -j LOG –log-prefix “Download: mp3″
iptables -A FORWARD -m string –string “.mp3″ -j DROP
Também é possivel fazer, com algumas ressalvas, um pequeno IDS em substituição ao SNORT com o uso deste modulo. Aqui você encontra scrips para fazer esta conversão:
Regras no Snort:
1. alert udp $EXTERNAL_NET any -> $HOME_NET 518 (msg:"EXPLOIT ntalkd x86 linux overflow"; content:"|0103 0000 000 0 0001 0002 02e8|"; reference:bugtraq,210; classtype:attempted-admin; sid:313; rev:2;) 2. alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"EXPLOIT named tsig infoleak"; content: "|AB CD 09 80 00 00 00 01 00 00 00 00 00 00 01 00 01 20 20 20 20 02 61|"; reference:cve,CAN-2000-0010; reference:bugtraq,2302; reference:arachnids,482; classtype:attempted-admin; sid:303; rev:3;) 3. alert udp $EXTERNAL_NET any -> $HOME_NET 635 (msg:"EXPLOIT x86 linux mountd overflow"; content:"|5eb0 0289 06fe c889 4604 b006 8946|"; reference:cve,CVE-1999-0002; classtype:attempted-admin; sid:315; rev:1;)Convertidos para o Iptables:
1. iptables -A SnortRules -p udp -s $EXTERNAL_NET -d $HOME_NET --dport 518 -m string --string " è" -j LOG --log-prefix "SID313 " # "EXPLOIT ntalkd x86 linux overflow" bugtraq,210 classtype: attempted-admin sid:3132. iptables -A SnortRules -p tcp -s $EXTERNAL_NET -d $HOME_NET --dport 53 -m string --string "«Í .a" -j LOG --log-prefix " SID303 " # "EXPLOIT named tsig infoleak" cve,CAN-2000-0010 bugtraq,2302 arachnids,482 classtype:attempted-admin sid:3033. iptables -A SnortRules -p udp -s $EXTERNAL_NET -d $HOME_NET --dport 635 -m string --string "^° ‰ þȉF ° ‰F" -j LOG --log-prefix " cve-CVE-1999-0002 " # "EXPLOIT x86 linux mountd overflow" classtype:attempted-admin sid:315
2) Modulo lenght:
Este módulo permite limitar o tamanho dos pacotes que passam pelo firewall. Assim como os outros módulos podem ser usados em conjunto com os módulos mais conhecidos. Pode ser usado para limitar downloads, por exemplo.
## Bloqueia qualquer pacote UDP maior que 10kb
iptables -A FORWARD -p udp -m length –lentgh 10000 -j DROP## Bloqueia qualquer pacote icmp vindo da eth0 entre 1 e 15kb
iptables -A FORWARD -p icmp -i eth0 -m lenght –length 1000:15000
Outro módulo que trabalha no nível de aplicação:
Modulo Owner: Permite um controle em cima do usuario que inicia a conexão, tomando como paramentros o UID, GID e PID.
Abaixo está o gráfico dos caminhos percorridos pelos pacotes nas tabelas e chains. Somente após entender bem este processo você poderá dizer que conhece iptables!!
Outros Links Relacionados:
- Manpage do iptables
- Artigo sobre o Modulo String
- A Comparison of iptables Automation Tools
[atulização] Achei um ótimo texto no VivaoLinux de como instalar o Módulo Layer7 no Debian Etch e a partir dele poder fazer filtros no iptables por aplicação. É melhor do que fazer via string e muito mais eficiente, mas tem o inconveniente de usar um módulo experimental e recompilar o kernel …
Abraços

Textos do Blog Blogmind sao licenciados sobre a Creative Commons Atribuição-Uso Não-Comercial-Compartilhamento pela mesma Licença 2.5 Brasil License.
Parte do Trabalho de Leandro Godoy - www.opencode.com.br.








Nov 3rd 2006
Parabéns. Muito bom artigo
Dez 4th 2006
O que transforma realmente o iptables num firewall layer 7 é o módulo layer 7, que permite fazer bloqueios baseado no protocolo. Inspecionar strings de pacotes ainda continua sendo em layer 3. Procure estudar o modelo OSI antes de falar besteira. É muito melhor usar um proxy, porque se a string estiver dividida em vários pacotes, o iptables simplesmente não bloqueia.
Dez 4th 2006
Sobre o artigo, muito interessante, até mesmo porque independente de teoria com relação a qual das camadas o firewall atua, o fato é que para um artigo rápido, ficou EXCELENTE! Com exemplos práticos.Pessoas como este cidadão, que só cirticam, simplesmente poderiam não existir, ou pelo menos comentários de pessoas que não possuem o mínimo de educação, não dignam seu tempo a fazer nada que não seja em benefício próprio. O sujeito poderia CONTRIBUIR, com crítica CONSTRUTIVA, mas opta por dizer coisas do tipo ‘vai estudar a camada 3 do modelo OSI’ ou ’slackware é melhor’ ou ainda ‘qmail é muito superior ao postfix’, etc.Ser linuxista é contribuir, colaborar, não ser tonto! Abc. aos amigos da verdadeira comunidade!Rogério Reis
Dez 4th 2006
Obrigado pelos comentários …
Pô Fausto desculpe se falei besteira ai cara … mas é até onde meu conhecimento vai, pelo menos eu estou compartilhando o pouco que eu sei.
Cara, bem que tu podia escrever uns artigos e dividir com a gente o teu vasto saber … a comunidade ia agradecer.
Rogerio,
Valeu pelo entendimento … tu entendeu bem o espirito da coisa.
Abraços
Ago 21st 2007
Salve Fausto
Existe aí uma interpretação errada de conceito, quando tratamos os primeiros 20 bytes do pacote estamos tratando o que diz respeito a camda 3! Quando tratamos os 20 bytes sequintes estamos tratando o cabeçalho do protocolo que pode ser um protocolo de de transporte (TCP ou UDP) o que seria camada 4.
Mas quando o tratamento pega também os 1460 bytes restantes do pacote, ou seja o payload (parte de dados uteis) estamos tratando a informação destinada a aplicação! Por
Ago 21st 2007
“Considere este post, tive problemas de delay :-(”
Salve Fausto
Desculpe mas preciso descorda de você e contestá-lo!
Veja, quando tratamos os primeiros 20 bytes do pacote estamos tratando o que corresponde ao cabeçalho de endereçamento ou seja o cabeçalho IP, neste momento o tratamento é like Packet Filter!
Todavia quando tratamos também os 20 bytes seguintes, ou seja, estamos pensando nos primeiros 40 bytes do pacote, estamos tratando o cabeçalho do protocolo que pode ser o protocolo de transporte (TCP e UDP), caso o firewall seja capaz de tratar bem os campos do protocolo de transporte (principalmente o do TCP) e ele já pode ser considerado um Firewall State. É claro que existem Firewall State que são melhores que outros! Mas todos de uma certa forma seriam State neste caso!
No caso do Strings, estamos falando de um tratamento na camada 7 sim, por que a informação tratada neste caso está nos 1460 bytes restante do pacote também conhecido como Payload ou MSS, tomando como referência o MTU de 1500 bytes! Assim sendo não seria errado dizer que usando Strings estamos atuando na camada 7, claro que o Modulo Layer 7 amplia a capacidade do Iptables de atuar na camada 7.
Leandro, parabéns pela iniciativa, tenha certeza que só existe um jeito de errar, é tentando acertar, embora acredito que tenha deixado claro que não houve um erro na sua argumentação apenas um conflito de conceitos!
:-)!