[GTER] Communities no IX.br

[Rafael Ganascim]

Em 28 de outubro de 2016 13:35, Rubens Kuhl <rubensk at gmail.com> escreveu:

> 2016-10-27 20:24 GMT-02:00 Rafael Ganascim <rganascim at gmail.com>:
>
> > Em 27 de outubro de 2016 19:23, Rubens Kuhl <rubensk at gmail.com>
> escreveu:
> >
> > > 2016-10-27 19:08 GMT-02:00 Antonio M. Moreiras <moreiras at nic.br>:
> > >
> > > > Em 27/10/16 17:30, Rubens Kuhl escreveu:
> >
> >
> > No ARP não respondido de fato as requisições seguem um caminho não ideal
> > dentro dos roteadores (mesmo os grandes). Acho que não responder ARP
> > impacta a todos de forma bem negativa.
> >
> >
> >
> Não é verdade para um bom número de arquiteturas de roteadores de alta
> performance. Uma que eu sei que sofreria um pouco é exatamente uma que já
> teve seu tempo e não deveria estar mais em uso, 6500/7600... já mesmo
> algumas outras arquiteturas da Cisco não teriam problema, e outras ainda da
> Cisco eu não sei. Mas vale sim olhar como reagem
>
>
Vale sim olhar como reagem. Você está certo, e concordamos neste ponto. Já
sabemos que para o tal bom número de arquiteturas de alta performance,
lidam bem.

Agora é levantar como os demais roteadores comumente utilizados pelos
participantes se portam. (inclusive os meus e meus clientes).



>
> > > Detalhe que isso tem uma solução simples é que quem tiver qualquer
> > > restrição com isso transformar a rota para o IP de drop numa discard
> > route
> > > (RouterOS), colocar um rota mais específica para esse IP apontando para
> > > nul0 (IOS), ou diversos outros jeitos. O que eu gosto nesse modelo é
> que
> > > ele já funciona de primeira sem configuração em 1 mil participantes...
> e
> > > quem não gostar da implementação default, pode substituir pela que mais
> > lhe
> > > agrade de acordo com sua arquitetura de equipamento.
> > >
> > >
> > Isto envolve reconfiguração por parte dos participantes do IX, e um
> grande
> > esforço para achar o next-hop adequado e comum.
> >
>
> O next-hop já é preferido... a ação de descarte é que é dependente da
> arquitetura.
>
>
>
Se o next-hop referido for um IP dentro da faixa de rede v4 do IX, para
haver bloqueio direto no cliente ele precisa de configurações adicionais.
Caso ele escolha não configurar isto, o drop nunca ocorrerá e o ataque
continuará fluindo. Ou seja, continuarei a ser atacado.



> >
> >
> >
> > > Outro detalhe é que muitos participantes do IX pagam transporte até
> ele,
> > > então o descarte no IX não resolve o fato de que o canal dele pode
> lotar
> > no
> > > sentido de uplink e ele ser degradado por um ataque volumétrico.
> > >
> > >
> > >
> > O blackhole irá proteger quem está sendo atacado e quer se proteger dos
> > miseráveis anti-BCPs que tb participam do IX. Pq os dados não vão chegar
> > até ele.
> >
>
> Como os ataques baseados em dispositivos IoT vulneráveis mostraram, não é
> sempre que DDoS de alto impacto vem de redes não seguidoras de BCPs.
>
>
Foi apenas um exemplo. Já fomos atacados, e IPs spoofados vindos do IX
infelizmente geraram um transtorno enorme.
Agora se o ataque estiver vindo de IPs verdadeiros, basta ligarmos no inoc
do ASN em questão, não é? (isso se nossos telefones IP ainda conseguirem
falar com alguém rsrs)

Lembre-se, a meu ponto é referente a proteção dos participantes atacados
(de quem está sendo atacado, e não quem está atacando).



>
> > Agora se algum dos participantes estiver sendo usado para ataque, é
> melhor
> > mesmo que o link dele fique topado até o IX e ele vá tentar descobrir a
> > anormalidade.
> >
>
> "IX Death Penalty" ? Vixe.
>
>

Uai, um participante hoje atacando um alvo via IX já não traz o mesmo
efeito? Link topado.
A única diferença é que esta discussão tenta evitar que a penalidade seja
para ambos (quem é atacado e quem está atacando), e deixa o efeito somente
no atacante. Deixar os dois penalizados é de fato a política que devemos
correr dela.




>
> > De verdade não sei o peso computacional para o bloqueio no L2, mas ele,
> na
> > visão limitada que tenho de participante, parece tornar as coisas mais
> > simples.
> >
>
> Isso acontece muitas vezes em ambientes que são coletivos: achar que o
> outro fazer é mais simples. A raiz disso é bem explicada no "Tragédia dos
> Comuns":
> https://pt.wikipedia.org/wiki/Trag%C3%A9dia_dos_comuns
>
>
>
Estou apenas expressando minha opinião puramente técnica sobre o assunto.
As questões não técnicas, como sempre, procuro não me meter. Tem gente
nesta lista muito mais capacitada.



>
> > A rota de blackhole vem do BGP, e o next-hop é algo válido no lado do
> > participante (e drop no lado do IX).
>
>
> O fato de você dizer "drop no lado do IX" ao invés "de drop eventual no
> lado do IX caso o participante falhe em descartar o tráfego localmente" é
> bem sintomático do que iria acontecer na prática.
>
>
É uma verdade o que você disse. A política e as recomendações não devem
omitir o fato que para o IP de next-hop blackhole o participante deva
dropar localmente.

Mas, mesmo que o participante usado no ataque falhe neste ponto, ainda há
uma proteção para o flamigerado atacado (lembre-se, quem marcou o /32 com o
blackhole está sendo atacado).

Como citou o Henrique, existem bons exemplos por aí. E bloquear onde for
possível (L2, L3, na cafeteira IoT) e mais próximo a fonte é, como dizem,
"o que há de mais moderno". Para meus amigos goianos, é "só o ouro".

</visoes_tecnicas_sobre_o_assunto>