terça-feira, 22 de novembro de 2011

Entendendo IPTABLES: PREROUTING e POSTROUTING


Quando o assunto é firewall logo se pensa em usar um Linux com iptables. O que não falta são tutoriais pela Internet que ensinam como instalar e configurar um firewall no Linux usando o iptables. Infelizmente muita gente se confunde quando o assunto é a chain PREROUTING e POSTROUTING da tabelna NAT do Netfilter.

A proposta deste post é justamente explicar o que acontece com o pacote quando passa por uma dessas chains.


PREROUTING

Logo que o pacote chega ele é modificado, isso acontece antes do roteamento do pacote. É usado em regras de DNAT e Redirecionamento de porta.

Vamos analisar o cenário abaixo, onde estamos fazendo um DNAT, ou seja, toda requisição feita para o IP 200.164.30.20 na porta 80 será repassado para o IP da rede interna 192.168.2.100.



A requisição vem da Internet com destino 200.164.30.20:80.

No nosso firewall a porta 80 esta desabilitada, neste caso o pacote seria “dropado”, mas como temos essa regra de IPTABLES:

iptables -t nat -A PREROUTING -d 200.164.30.20 -p tcp --dport 80 -j DNAT --to 192.168.2.100

Neste caso todo pacote com destino 200.164.30.20:80 será repassado para 192.168.2.100:80, porém isso acontece antes de qualquer roteamento. Veja a figura abaixo que mostra o que acontece logo que o pacote chega no firewall:


Como o nosso firewall conhece a rede 192.168.2.0/24 o pacote será repassado para o IP 192.168.2.100 na porta 80. Note que o roteamento foi o último procedimento realizado. Neste caso não seria lógico realizar o roteamento primeiro já que o DST possui o mesmo IP do firewall (200.164.30.20).


POSTROUTING

Os pacotes precisam ser modificados após o roteamento. É usado em regras de SNAT e IP MASQUERADING.

Neste post vou usar o MASQUERADING para explicar como funciona o POSTROUTING.

Segue abaixo a descrição tirada do FOCALINUX do que seria o MASQUERADING:

“O IP Masquerading é um tipo especial de SNAT usado para conectar a sua rede interna a internet quando você recebe um IP dinâmico de seu provedor”.

Veja o cenário abaixo:



 
A máquina 192.168.2.100 pretende acessar a INTERNET, mas para isso é preciso ter uma regra de MASQUERADING no Firewall, onde o mesmo mascara todo acesso da máquina de origem para que saia para a Internet com o IP do próprio Firewall. A regra do iptables seria assim:


iptables -t nat -A POSTROUTING -s 192.168.2.100 -o eth0 -j MASQUERADE
A requisição vem de uma máquina interna da rede (192.168.2.100) com destino (dst) www.google.com.

Veja a figura abaixo que mostra o que acontece logo que o pacote chega no firewall:


Quando o pacote chegar no Firewall vai ser repassado para o Gateway padrão do Firewall que esta configurado na placa de rede com saída para a Internet. No segundo momento, logo depois do roteamento, o pacote bate na chain POSTROUTING da nossa regra de iptables e o mesmo é modificado para que possa navegar na Internet com um IP válido, no nosso caso o IP do Firewall (200.164.30.20).

É fundamental entender o fluxo do pacote quando o mesmo passa pelo Netfilter, Postrouting e Prerouting são chains que poucos entendem. Espero que com este post as dúvidas possam ter sido esclarecidas sobre o assunto.
 





quinta-feira, 10 de novembro de 2011

Detectando Máquinas que fazem parte da rede Rustock

Recentemente fomos notificados que possíveis máquinas da nossa rede estaria fazendo parte da rede de botnets Rustock (1). Pesquisei pelo Google e encontrei a lista de IP's dos servidores da rede Rustock.

A lista você encontra no link abaixo:

Rustock CnC Servers: http://blog.fireeye.com/research/rustock-cnc-servers.html

Usando o tcpdump pude filtrar todo tráfego com destino aos IP's e salvar o resultado em um arquivo para que posteriormente possa ser analisado, veja o script como ficou:

#!/bin/bash 
tcpdump -nn -i any host 173.192.135.102 or host 173.192.135.98 \
or host 173.192.135.99 or host 173.208.128.50 or host 173.208.128.74 \
or host 173.208.128.82 or host 173.208.131.178 or host 173.208.131.98 \
or host 173.208.141.154 or host 173.208.143.114 or host 173.208.143.122 \
or host 173.208.143.194 or host 173.208.143.90 or host 173.208.150.90 \
or host 173.208.154.90 or host 173.208.162.2 or host 173.208.163.178 \
or host 173.208.163.242 or host 173.212.214.194 or host 173.212.241.42 or host 173.212.241.50 or host 173.212.243.114 \
or host 173.83.26.26 or host 173.83.26.34 or host 174.139.250.66 or host 174.36.237.84 or host 204.12.192.250 \
or host 204.12.217.218 or host 204.12.217.250 or host 204.12.217.42 or host 204.12.217.98 or host 204.12.220.122 \
or host 204.12.237.202 or host 204.12.243.210 or host 204.12.243.34 or host 204.12.243.42 or host 204.12.243.58 \
or host 204.12.248.66 or host 204.45.118.202 or host 204.45.118.250 or host 204.45.119.10 or host 204.45.119.18 \
or host 204.45.119.2 or host 204.45.119.26 or host 204.45.119.34 or host 204.45.119.42 or host 204.45.119.50 \
or host 204.45.119.74 or host 204.45.119.82 or host 204.45.119.90 or host 204.45.121.130 or host 204.45.121.18 \
or host 204.45.121.34 or host 204.45.121.42 or host 204.45.121.50 or host 204.45.121.58 or host 206.217.206.8 \
or host 208.101.27.108 or host 208.101.27.44 or host 208.101.27.72 or host 208.110.71.58 or host 208.110.80.50 \
or host 208.110.82.186 or host 208.43.102.220 or host 208.43.157.96 or host 208.43.17.44 or host 208.43.18.12 \
or host 208.43.31.8 or host 208.43.40.148 or host 64.120.144.69 or host 64.120.149.117 or host 64.120.153.117 \
or host 64.191.18.149 or host 64.191.38.165 or host 64.191.53.37 or host 64.191.59.245 or host 64.22.109.222 \
or host 66.197.161.181 or host 66.197.251.69 or host 66.79.162.138 or host 66.79.162.86 or host 66.79.163.102 \
or host 66.96.214.53 or host 66.96.224.213 or host 67.228.206.92 or host 69.197.144.138 or host 69.197.158.242 \
or host 69.197.158.250 or host 69.197.161.34 or host 69.50.197.191 or host 72.26.196.194 or host 74.86.210.133 \
or host 74.86.210.134 or host 76.164.194.226 or host 85.17.200.13 or host 95.211.128.25 or host 96.0.203.106 \
or host 96.0.203.114 or host 96.0.203.122 or host 96.0.203.82 or host 96.0.203.90 or host 96.0.203.98 or host 96.31.81.44 \
or host 96.45.189.178 or host 96.9.169.53 or host 96.9.180.21 or host 96.9.182.101 or host 96.9.182.197 or host 96.9.183.149 \
or host 98.126.114.50 or host 98.126.42.26 or host 98.126.76.186 or host 98.126.77.2 or host 98.141.220.194 \
or host 98.141.220.226 -w /var/log/rustock.log &

O resultado será salvo no arquivo /var/log/rustock.log. Para ler este arquivo temos que usar o tcpdump e redirecionar a saída para um arquivo:

#tcpdump -r /var/log/rustock.log > /tmp/rustock.txt

Agora já podemos manipular as informações. Dando um cat no arquivo veja o que temos:

13:40:32.613458 IP 10.123.122.254.1436 > ..www: Flags [S], seq 3547421019, win 65535, options [mss 1460,nop,nop,sackOK], length 0

Precisamos filtrar o arquivo para termos só o que nos interessa, o IP. Para isso execute o comando abaixo:

#cat /tmp/rustock.txt | cut -f3 -d" " | cut -f1-4 -d.

Agora temos a lista dos IP's que estão tentando se conectar em um dos servidores do Rustock. Agora vamos usar o comando sort para que não apareça os IP's repetidos:

#cat /tmp/rustock.txt | cut -f3 -d" " | cut -f1-4 -d. | sort -u

Agora temos a lista dos IP's que deverão ser investigados.



Referencia:

(1) http://pt.scribd.com/doc/59395728/Battling-the-Rustock-Threat

terça-feira, 8 de novembro de 2011

Bypass Squid com IPTABLES

Digamos que você tem uma regra redirecionando toda conexão com destino a porta 80 para a porta 3128 (squid):

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
 
Adicione uma regra de RETURN em cima da regra de REDIRECT para fazer com que todo pacote 
TCP com destino a porta 80 e host www.bypass.com.br pare de passar pela tabela NAT e chain PREROUTING.
 
As regras ficariam assim:
 
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -d www.bypass.com.br -j RETURN
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 
 
Com essa regra toda requisição feita para o domínio  www.bypass.com.br não passara
pelo squid.