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
[EMAIL PROTECTED]
"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/
