[GTER] Co-operative DDoS Mitigation

[Douglas Fischer]

Nunca usei com Mikrotik.
Também não sei se o RPF ficaria no nível do FastPath ou teria que subir
para o Línux.
(Imagino que fique no FastPath)
Aí eu pergunto: Quando fez esse teste estava com FastPath habilitado?
  P.S.: RB750? Aí não dá né?

Mas falando de Cisco, RPF fica no hardware.
Se não me engano Juniper é a mesma coisa.

RPF custo de performance? TEM!
Ou seja, numa conta de padeiro, teria que comprar uma caixa com o
DOBRO(provavelmente menos) do poder do que estava planejando...
Com esse dinheiro você compra um PeakFlow? naaaaa...

OK, OK! São coisas diferentes...
Um você usa para se proteger, outro para não deixar tua rede ser mal usada.

Mas e se todos fizermos nossa parte?
Exatamente a mesma lógica do bloqueio da porta 25.





Em 23 de outubro de 2015 11:18, Fabiano Ribeiro <
fabiano.ribeiro at gerenciatec.com.br> escreveu:

>      É exatamente isso que penso Diego, que a responsabilidade do ddos tem
> que ser de cada operadora com seus blocos, não da operadora de trânsito.
> Mas infelizmente se quisermos uma internet "livre" de DDOS usando técnicas
> de Spoofing isso terá que ser feito pois duvido que todos os ASNs do mundo
> terão esse cuidado.
>       Douglas você já fez testes com Reverse Path ? em testes que fiz com o
> RouterOS, duas consultas a tabela de roteamento para cada forward topou a
> CPU da rb750 (nele uso pppoe descentralizado nas ilhas de cabo UTP de
> clientes residenciais) com 20 megas e 50 clientes, já a regra de firewall
> ficou tranquilo.
>
> Em 23 de outubro de 2015 00:32, Diego Canton de Brito <
> diegocanton at ensite.com.br> escreveu:
>
> >
> >
> > Desculpe, mas filtrar na caixa da borda, onde passa clientes BGP? Meio
> > loucura isso né?
> >
> > Acho que o ideal seria a filtragem diretamente nos Roteadores de
> > acesso/Concentradores, quanto mais perto da origem do problema melhor,
> > filtra direto onde os cliente se conectam, infelizmente clientes com ASN
> > devem fazer o mesmo em seus respectivos roteadores não sendo
> > responsabilidade do operador de transito, haja em vista o "potencial de
> > merda" que isso tem (no sentido de incorrer no risco maior de gerar
> > problemas do que resolver).
> >
> > ---
> >
> > Att.
> >
> > -------------------------
> >
> > DIEGO CANTON DE BRITO
> >
> > Em 2015-10-21 21:23, Fabiano Ribeiro escreveu:
> >
> > > Compartilho da opinião do Bruno, mas acredito que para uma grande
> > > operadora manter o controle de todos os prefixos que passam por sua
> rede
> > > pode se tornar bastante complexo. Se a operadora agrega vários clientes
> > em
> > > uma única caixa, como vejo alguma fazerem, manter regras mesmo que
> > > stateless dando match em gigabits de tráfego pode ser bastante oneroso
> > para
> > > a caixa, isso para não falar de Reverse Path que é o correto porém mais
> > > oneroso ainda.
> > >
> > > Em 20 de outubro de 2015 19:56, Bruno Cabral <bruno at openline.com.br>
> > > escreveu:
> > > Pelos ISPs que atendo, a maioria é desconhecimento mesmo. !3runo Cabral
> > -- Cursos e Consultoria BGP Ainda dentro do assunto DDoS, estava
> > conversando com um amigo esses dias sobre filtros de saída e pensando nas
> > razões porque muitos ASNs não possuem. Quem não possui ou que tenha
> > conhecimento poderia citar os quais os principais impedimentos e
> > dificuldades ? Mesmo sabendo que a maioria dos ataques venha lá de fora,
> já
> > daria pra ter uma base boa das dificuldades que existem hoje para se
> > implementar filtros de saída permitindo apenas suas próprios ranges como
> > endereço de origem nos pacotes. Obrigado Fernando -- 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação