[FUGSPBR] [OFF] The IP Smart Spoofing

[Patrick Tracanelli]

Fernando Monteiro wrote:
>>Sim,
>>
>>E o ipfw statefull nao soluciona esta problema ???
>>
>>No caso o keep-state e check-state nao barram o spoof ?
>>
> 
o IP X, que era de um servidor
> e estava relacionado ao MAC address MAC-X agora deve apontar para o
> endereço MAC-Y de uma máquina de um cracker.
> 
> O keep state e a sequência de pacotes podem até mostrar alguma coisa
> errada acontecendo, mas as novas conexões poderão acontecer sem
> problemas.
> 

>  Outra
> possibilidade é criar um monitor de ARP que investigasse qq mudança,
> atuando como um IDS.
>


Ola :-)

Talvez eu esteja errado por estar entrando na discussao só agora. Mas 
dexaeu tentar entender. Nesse caso onde o IP é assimilado a um novo MAC 
trata-se do mesmo barramento, correto? Acredito que sim pois se nao for 
o mesmo barramento nao faz muito sentido o reconhecimento do endereço de 
hardware né?

Bom nesse caso eu acho que não se tem muita escolha. Não se é sucetível 
apenas a um "smart spoofing attack" mas tambem a um ataque de spoof 
ordinario apenas com o endereco de origem alterado no cabecalho TCP/IP.

Ja, no mesmo barramento o problema nao e' exclusividade de "spoof" em 
relacao ao MAC. Acredito que muitos (como eu) ja devem ter problemas com 
switches 3Com que fazem um "pseudo-roteamento" de pacotes entre redes 
distintas apenas baseado em MAC (quando deveria passar antes pelo 
gateway que no caso seria o firewall tbm).

Bom.. mas no caso de spoof fora da rede privada as politicas normais de 
firewall ja dao conta, para evitar ser vitima e evitar que partam 
ataques desse tipo pela rede privada. Por exemplo, nunca deixar que 
pacotes cujo endereco de origem e' igual às suas redes internas entrar 
pela interface externa (nao faria sentido, eh obviamente o comportamento 
de um spoof), nunca deixar que pacotes cujo endereco de destino nao seja 
nenhuma rede interna entrar pela interface externa, nuncca deixar 
pacotes cujo endereco de origem é diferente das suas redes privada sair 
pra rede publica, etc. Isso evita (ou ao menos ajuda a diminuir muito a 
probabilidade de) um ataque de DDoS tambem.

Quanto ao "mesmo barramento", que parece ser o lado mais problematico... 
uma solucao bastante obvia e' uma DMZ. A questao de monitoramento nao 
precisa de um IDS ja que o FreeBSD e' bem "verboso" por padrao quanto a 
alteracoes na sua tabela de MAC. Quem ja nao percebeu isso com mensagens 
do tipo:Oct  8 11:06:47 current /boot/kernel/kernel.trusted: arp: 
200.210.XXX.YYY moved from 00:02:2d:5e:8e:11 to 00:02:2d:30:b3:e7 on wi0

Esse comportamento e' digno de muita atencao :Pp

Como ja disseram aqui na lista antes (nao me lembro quem foi), esse e' 
apenas um antigo ataque com um novo nome. Nao mudam muito os problemas e 
por isso nao muda muito as solucoes.

Ou eu perdi algo relevante?


-- 
Atenciosamente,

Patrick Tracanelli

FreeBSD Brasil LTDA.
The FreeBSD pt_BR Documentation Project
http://www.freebsdbrasil.com.br
patrick em freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/