[GTER] Ataques entrando pelo PTT-SPO com origem ASN 6939 ( HE )

[Bruno Cabral]

Que tal a comunidade enviar aos RS prefixos/32 com community 26162:666 que seriam replicados normalmente. Quem tiver poder de fazer bloqueio de borda desses alvos, faz, quem não puder já ignoraria mesmo...
Sobre quem poderia validar esses anúncios, se hoje alguém anunciasse um /32 de outro participante já seria sequestro de bloco, não?
Os RS (que eu saiba) não amarram os blocos dos participantes, apenas quantidades de anúncios. Usar um IRR forçosamente no ingresso ao PTT seria uma opção, ou mesmo a RFC1786 já disponível na interface do registro.br. Com apoio da administração do IX, os RS poderiam ser configurados para só aceitar e enviar rotas marcadas para quem tivesse aderido ao modelo de proteção.
[]sBruno Cabral
--Cursos e Consultoria BGP e OSPF

> O problema é eleger um único sistema onde todos vão se inscrever. Só
> forçando um mesmo.
> 
> 
> Pense comigo em um cenário hipotético. Não sou dono da melhor idéia (longe
> disto), estou apenas discutindo possíveis soluções para o problema em
> comum.
> 
> 
> Como poderia ser feito o bloqueio do meu(s) ip(s) atacado(s) pelo nic.br em
> todo o PTT de forma transparente (sem qualquer configuração de outros
> players)?
> 
> 1) envio a rota para o BH do nic.br
> 
> Previamente me inscrevi no BH do nic.br (e autorizei e foram validados que
> os prefixos são meus).
> 
> 
> 2) O nic.br aceita meu prefixo de BH, muda o next-hop para um IP da mesma
> rede do PTT (ex 187.16.216.xxx) e envia para os participantes a rota de
> blackhole (no RS normal)
> 
> O IP 187.16.216.xxx pertence ao nic.br, e tem o mac-address
> 66-66-66-66-66-66 e responde a requisições ARP.
> 
> Basta então nos switches L2/roteadores do NIC.br que ligam os participantes
> um filtro L2  na entrada:
> deny from any to mac 66-66-66-66-66-66
> permit from any to any
> 
> *claro que existe o filtro de origem do PTT
> 
> O drop então seria no primeiro ponto de entrada do PTT.
> 
> 
> Quem não quer participar do blackhole do PTT, não participa (não popula as
> tabelas). Porém, quem quer se proteger, protege-se.
> 
> Claro que existem ainda outros aspectos, como por exemplo, o aceite das
> rotas /32, a administração de tal serviço, o uso por grande parte dos
> participantes, etc.
> 
> 
> Mas duvido que quem sofreu um ataque recentemente não pensa em se proteger
> neste ponto.