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. 

segunda-feira, 3 de outubro de 2011

Combatendo SPAMBOTS

Um dos mecanismos primários usados pelos “spammers” para coletar e-mails é a utilização do que chamamos de “spambots”, que ficam vasculhando sites em busca de e-mails publicados.

Para que possamos enganar esses sistemas impedindo que e-mails dos Órgãos do Estado caiam nessas listas e diminuir o recebimento de e-mails não desejados (spam) podemos substituir o arroba (@) por {NOSPAM}.

Um e-mail publicado como osvaldo@hotmail.com seria substituído por osvaldo{NOSPAM}hotmail.com. Para ajudar os usuários poderia ser colocado uma mensagem informando para substituir o {NOSPAM} pelo @.

Alguns “spambots” podem buscar pela palavra “mailto:” na tag em HTML em busca de e-mail, para isso basta usar código ASCII, veja o exemplo abaixo:


<a href="mailto:osvaldo@hotmail.com">osvaldo{NOSPAM}hotmail.com</a>

Com ASCII:

Neste caso o “mailto:” foi substituído pelo código ASCII “&#109;&#97;&#105;&#108;&#116;&#111;&#58;”

Essas duas técnicas impediriam que 80% dos e-mails publicados de serem adicionados em lista de spam. Lembrando que os “spambots” estão sempre sendo adaptados para burlar mecanismos de anti-apambots. Abaixo estarei apresentando dois exemplos que são considerados 100% eficientes contra spambots.

Primeiro: escondendo o e-mail em imagens
Crie uma imagem com o e-mail que deseja publicar.

Segundo: utilizando Javascript

<script type='text/javascript'>var a = new Array('com','ail.','ldo@','osva','hotm');document.write("<a href='mailto:"+a[3]+a[2]+a[4]+a[1]+a[0]+"'>"+a[3]+a[2]+a[4]+a[1]+a[0]+"</a>");</script>

Clientes com javascripts desabilitado no browser não verão o e-mail, para contornar este problema basta utilizar as duas técnicas, ficando assim:

<script type="text/javascript">var a = new Array('com','ail.','ldo@','osva','hotm');document.write("<a href='mailto:"+a[3]+a[2]+a[4]+a[1]+a[0]+"'>"+a[3]+a[2]+a[4]+a[1]+a[0]+"</a>");</script>
<noscript><img src="imagem-do-email.gif"></noscript>


fonte: http://www.projecthoneypot.org/how_to_avoid_spambots.php

sexta-feira, 16 de setembro de 2011

Burlando o filtro XSS do Chrome

Quando se trata de segurança, temos que ter em mente que sempre haverá um caminho alternativo para burlar a segurança, basta você descobrir este caminho.

Neste post vou mostrar como Nick Nikiforakis encontrou este caminho alternativo para burlar o sistema de filtro de XSS do Google Chrome.

Este filtro do Chrome impede qualquer tentativa de XSS acessado por você. Vamos fazer dois testes, utilizando o Chore e o Firefox.

A URL abaixo é vulnerável a XSS onde mostra o número 1 em uma janela da pop-up.

Abra a URL abaixo no firefox e depois no Chrome.

http://www.dsm.com/en_US/cworld/public/home/pages/searchResults.jsp?search-site=%22%3E%3Cscript%3Ealert%281%29;%3C/script%3E&noMimimumKeywords=false

Perceba que no Firefox o pop-up apareceu, mas no Chrome foi barrado pelo filtro.

A ideia inicial do Nick é não colocar a tag para fechar o JavaScript, com isso o código HTML passou a ser executado dentro do script, mas com erro, até porque o JavaScript não entende HTML. Em seguida ele comentou o código HTML (/* &b=*/) para que o script em java fosse executado, e funcionou.

bypassing XSS filter Chrome:

Agora vamos executar nossa URL nos dois browser usando esse pequeno "trick".

http://www.dsm.com/en_US/cworld/public/home/pages/searchResults.jsp?search-site="><script>alert(1);/*&noMimimumKeywords=*/</script>

Perceba que foi executado tanto no Firefox como no Chrome.

fonte: http://blog.securitee.org/?p=37

Disconnect Stalled SSH Session

Muito boa essa dica:

This doesn't really apply to Windows users as you can just close puTTy. But for everyone else, stalled SSH Sessions suck. You are either slamming enter to get it to realize it's been disconnected or just waiting for it to. Well, for those of us who are impatient just hit:
~.
Thats right, SHIFT + the key above TAB, release, and hit the period. You may have to hit ENTER first to clear the buffer or whatever it does, but do that and it will disconnect the SSH session right away.
Stupid trick, but I use it all the time (especially on shotty MiFi connections).

The ~ is the escape character, similar to Ctrl+A in screen. If you try ~?, you get the following dialogue:
$ ~?
Supported escape sequences:
~. - terminate connection (and any multiplexed sessions)
~B - send a BREAK to the remote system
~C - open a command line
~R - Request rekey (SSH protocol 2 only)
~^Z - suspend ssh
~# - list forwarded connections
~& - background ssh (when waiting for connections to terminate)
~? - this message
~~ - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)
Another very useful trick is to use ~C to open a command line, then use -L or -R to add additional SSH forwarding tunnels without breaking your existing SSH connection.


 fonte: http://www.room362.com/blog/2011/9/15/disconnect-stalled-ssh-session.html