[Iptables – artigo 1/10] Um passeio pelas chains da tabela filter (INPUT)

Talvez o maior e melhor de todos os recursos nativos do Kernel Linux seja o módulo Netfilter , desde o kernel 2.4 representado pelo Iptables, que é imprescindível no Skill de qualquer administrador Linux Pleno.

Então, a contar de hoje, serão 10 posts sobre Iptables, todas as quirtas-feiras, aqui no MundoTiBrasil

O de hoje vai ser um passeio pelas chains da tabela filter do Iptables.

A tabela filter

Sim, com letra minúscula mesmo, para respeitar a sintaxe do artista que fez isso!!

Como o próprio nome já diz, é a tabela que efetivamente faz o ‘pente fino’ no pacote, o filtro nele, é onde o netfilter é informado que política adotar ao ‘ver’ a passagem deste pacote. Então, para o netfilter ter o que fazer com o pacote ele precisa saber que tipo de pacote é, e é aí que entram as chains desta tabela.

INPUT

Trata os pacotes que dão entrada no servidor e que tem como destino o próprio servidor. Mas por que em negrito?! Porque todo mundo erra isso no início!

Na maioria das implementações de firewall Iptables, ele está entre redes distintas, exercendo papel de router de uma rede para outra e também atuando no filtro dos pacotes entre elas.

PORÉM, esta chain não trata pacotes que passam pelo firewall e têm como destino outra rede.

Vejamos um exemplo de aplicação disso:

Neste caso, o firewall pode ser implementado no próprio servidor rejeitando todo e qualquer pacote que venha da rede local na porta 21 e tenha como destino a interface 172.16.0.20 do servidor Web Apache:

#iptables -t filter -A INPUT -p tcp -s 172.16.0.0/16 -d 172.16.0.20 –dport 21 -j REJECT

ou

#iptables -A INPUT -p tcp -s 172.16.0.0/16 -d 172.16.0.20 –dport 21 -j REJECT

*obs: suprimi o ‘-t filter’ porque é a tabela padrão da chain INPUT.

Aproveitando, poderíamos também fazer log de todos os pacotes SSH que entrem no servidor e em seguida fazer DROP dos destes pacotes, a exceção de quando eles vierem da máquina do analista (172.16.0.10):

#iptables -I INPUT -p tcp –dport 22 -j LOG –log-level warn –log-prefix ‘[Entrada de pacotes SSH]’

#iptables -A INPUT -p tcp !-s 172.16.0.10 -d 172.16.0.20 –dport 22 -j DROP

IMPORTANTE: para configuração de logging exclusivo do iptables é necessaŕio atuar no arquivo /etc/rsyslog.conf para criar o mesmo, se não for feito isso, os eventos vão para o log de facilidade kern , que é o /var/log/kern.log .

Repare que acima eu criei a primeira regra com -I e a segunda com -A . No primeiro caso, é uma regra alta, que tem prioridade em cima das demais, no segundo, estou adicionando uma ‘regra baixa’, que pode ser lida depois. Fica assim: primeira faz log e depois bloqueia o pacote. Boa prática! :)

Ih, mas aí eu esqueci que tem um amigo administrador que precisa usar o FTP deste servidor para fazer upload dos arquivos, afinal, é um servidor Web. Não tem problema, é só liberar a porta 21 para ele:

#iptables -I INPUT -p tcp -s 172.16.0.11 -d 172.16.0.20 –dport 21 -j ACCEPT

Então, entenderam? A chain INPUT trata apenas de pacotes de rede que tenham SEMPRE como destino (opção -d) o próprio servidor onde está feita a regra.

Grande abraço e até o próximo post!!