[GTER] Ataques entrando pelo PTT-SPO com origem ASN 6939 ( HE )
Douglas Fischer
fischerdouglas at gmail.com
Fri Jul 8 09:27:21 -03 2016
Me lembro dessa proposta Rinaldo!
E é funcional para um boooom tempo...
O problema é que esses IDs tem que ser flat em todos os PTTs do .BR.
-Ou Seja, o "NetFlix" teria que ser "ID=2" no PTT-Oiapoque e também no
PTT-Chuí.
Isso porque muitos participantes têm presença em múltiplos PTTs.
Hoje tem ASN de tudo que é lado do mundo conectado nos PTTs do Brasil.
E se for extrapolar, dar um ID para cada um, é quase querer renumerar os
ASNs do mundo.
Imagina a encheção de saco que seria ter mais um recurso de numeração para
lidar?
Em 7 de julho de 2016 18:36, Rinaldo Vaz <rinaldopvaz at gmail.com> escreveu:
> 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
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list