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

Thu Jul 7 18:36:42 -03 2016

Na prática não conseguiríamos definir um modelo simples por causa dos ASNs
de 32 bits. Acredito que o camino seria um link atualizado com um ID de
cada participante:

ASN do Google: ID 1
ASN do Netflix: ID 2
...
ASN do Joãozinho: ID n

O padrão da community sendo "65535:ID"

Então se não quero que determinado prefixo não chegue ao Google nem ao
Netflix marco assim:

set community 65535:1 65353:2

Dessa forma Google e Netflix não receberiam o prefixo ao mesmo tempo
que todos os outros receberiam normalmente.

Além de desviar eventuais ataques vindos de um participante esse
modelo possibilitaria um melhor controle sobre tráfego de CDN incluindo
ações de "set prepend/MED" além do no-export.

Como o Douglas disse mais em cima já fazem alguns anos que venho expondo
essa solução por já esperar que o crescimento do IX traria esse tipo de
consequências. Se o IX tiver interesse posso publicar um modelo
da configuração sugerida.

Dou minha garantia de que esse modelo vai funcionar satisfatoriamente e que
o pior que pode acontecer se eu for desqualificado o suficiente para
colocar todas as comunities de maneira errada seria meu AS parar de ser
visto no ATM, assim como já ocorre se eu desabilitar minha sessão BGP com
os Route Servers.

Em quinta-feira, 7 de julho de 2016, Márcio Elias Hahn do Nascimento <
marcio at sulonline.net> escreveu:

>
>
> Community para blackhole é muito interessante, mais voltando mais ao
> TE que o Rubens citou lá no começo...
>
> Seria tão bom se uma community
> como MEU-AS:AS-X fizesse com que os route-servers
> anunciassem minhas
> rotas para todos exceto o AS-X...
>
> Imaginem, hoje não quero receber
> Netflix pelo PTT, ou então Facebook, mais quero o resto. Com isso esse
> controle seria possível!
>
> Complexo, pode ser, mais as possibilidades
> proporcionadas aos AS's conectados ao ATM seriam muito interessantes.
>
> ---
>
> Att
>
> Márcio Elias Hahn do Nascimento
> (48) 8469-1819 / 3524-0700 -
> marcio at sulonline.net <javascript:;>
> INOC-BR: 52977*100
> GERÊNCIA DE RECURSOS DE TIC -
> Sul Internet [2]
>
>  [2]
>
> Em 07/07/2016 17:37, Gabriel Mineiro escreveu:
>
>
> > Se o IX aceitasse prefixos /32 dos participantes, todos poderiam
> criar uma politica de blackhole baseada nesses anuncios.
> >
> > Seria uma
> forma de escapar temporariamente de usar community, ao menos para
> blackhole.
> >
> > Gabriel Mineiro
> >
> > -----Mensagem original-----
> > De:
> gter [mailto:gter-bounces at eng.registro.br <javascript:;>] Em nome de
> Wilson R Lopes
> >
> Enviada em: quinta-feira, 7 de julho de 2016 15:43
> > Para: Grupo de
> Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br
> <javascript:;>>
> >
> Assunto: Re: [GTER] Ataques entrando pelo PTT-SPO com origem ASN 6939 (
> HE )
> >
> > Não seria uma boa oportunidade para alguma empresa, ou o
> próprio PTT, montar um cleaning center dentro da infra do PTT e vender
> isso como serviço aos participantes ?
> >
> > A questão de community para
> blackhole não seria uma implementação do PTT, mas sim um "combinado"
> entre os participantes de configurarem uma community padrão nos seus
> routers, que quando recebido um anúncio de um determinado ip ou prefixo
> com esta community marcada, deve descartar o tráfego com destino ao ip
> ou prefixo marcado.
> > A função do route server do PTT seria apenas de
> repassar estes anúncios com a community marcada para todos do ATM.
> >
> >
> Abs,
> > Wilson.
> >
> > Em 7 de julho de 2016 10:31, Douglas Fischer
> <fischerdouglas at gmail.com <javascript:;>>
> > escreveu:
> >
> >> E voltamos às benditas
> communities! i++ para as communities; Assim como o Kurt mencionou. Tem
> mais de 4 anos que escuto os amigos falando sobre isso! Lembro até de
> uma apresentação do Rinaldo sobre isso(também tem uns 3 anos ou mais). O
> Rubens está certíssimo sobre o IX ser L2, e não pode-se entrar nos
> pacotes alheios. Mas no caso das Communities, isso não estaria
> analisando os pacotes. Apenas entregando uma rota com uma observação
> "mande pro inferno" para os demais participantes Não consigo ver
> empecilhos técnicos(apesar de ser algo muito complexo) para
> implementação de communities que permitam um controle mais granular dos
> anúncios: - Para quem deve ser repassada a rota. - Para que não deve ser
> repassada a rota. - Com qual community deve ser repassada a rota. A
> parte mais complexa disso é que todos os participantes terão que
> configurar o BlackHole nos seus bordas. Mas presume-se que tenham
> capacidade para isso, certo? Além do mais, conseguindo romper essa
> barreira(que claramente é complexa), todos esses controles de bloqueio
> de anúncios entre participante que hoje é feito manualmente através de
> portal e configuração específica passam a ser responsabilidade do ASN,
> desonerando material humano na gerência dos IX. P.S.: O principal contra
> disso é a possibilidade de um tanso fazer caquinha. Mas em teoria isso
> está coberto na definição de "sistema AUTÔNOMO", certo? Em 7 de julho de
> 2016 07:15, Rubens Kuhl <rubensk at gmail.com <javascript:;>> escreveu:
> >>
> >>>
> 2016-07-06 23:30 GMT-03:00 Kurt Kraut <listas at kurtkraut.net <javascript:;>
> >:
> >>>
> >>>>
> Aloha amigos, Sei que estão tentando ajudar o colega que está tomando
> DDoS na
> >> cachola,
> >>
> >>>> mas esse é um caso em que o bom é o
> inimigo do ótimo. Convido todos a clamarem por black hole nos IX.br
> >>>
> Black hole do ponto de vista de um IX, que é L2, se pudesse ser
> implementado só poderia ser do tipo "Drop MAC origem tal"... mais do que
> isso e o IX está fuçando nos seus pacotes. ;-) Me parece que algo como
> community de controle de propagação no ATM seria mais o caso, tipo "Não
> me anuncie para a HE, please"... e isso tem utilidades diversas em TE,
> não apenas em resposta a DoS. Rubens -- gter list
> https://eng.registro.br/mailman/listinfo/gter [1]
> >> -- Douglas Fernando
> Fischer Engº de Controle e Automação -- gter list
> https://eng.registro.br/mailman/listinfo/gter [1]
> >
> > --
> > gter list
> https://eng.registro.br/mailman/listinfo/gter [1]
> >
> > --
> > gter list
> https://eng.registro.br/mailman/listinfo/gter [1]
>
>
> Links:
> ------
> [1]
> https://eng.registro.br/mailman/listinfo/gter
> [2]
> http://www.sulinternet.net
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

-- 
---
Att
Rinaldo Vaz
83 99836-0616