RE: [LACNIC/Politicas] Iniciativa de coordinación a nte ataques

[Ralvarez]

Hola a todos:

>Solo para dar como referencia, queria marcar que varios proveedores
> implementan comunidades BGP para mitigar el efecto de DDoS creando
> rutas a Null0.  Como Carlos dice, con estas tecnicas se deja las redes
> inoperativas, pero los proveedores estan permitiendo ser tan especifico
> como un /32. Esta solucion no es una lista de acceso sino que es una
> entrada adicional en la tabla de routing por lo que, en principio, no
> aumenta el consumo de CPU en forma considerable.

Siguiendo con el aporte de ideas, me parece muy bueno y practico lo que dice
Roque, nosotros en la empresa lo tenemos implementado con todos nuestros
proveedores, lo hemos utilizado varias veces y con muy bueno resultados y
prácticamente sin consecuencias para nuestros equipos.

En este link se explica como la Seabone lo lleva a la practica con sus
clientes.
http://etabeta.noc.seabone.net/communities.html

PDF explicativo de Global Crossing

http://www.intron.com.br/doc/gblx.BlackHole.pdf

Saludos cordiales,

Rodolfo


> -----Mensaje original-----
> De: politicas-bounces at lacnic.net [mailto:politicas-bounces at lacnic.net] En
> nombre de rgaglian at adinet.com.uy
> Enviado el: miércoles, 14 de diciembre de 2005 18:33
> Para: politicas at lacnic.net
> Asunto: RE: [LACNIC/Politicas] Iniciativa de coordinación a nte ataques
> 
> Carlos,
> 
> Si tomamos lo que se ve en nanog, muchas veces la solucion viene por
> el escandalo publico. Al dar al aire el nombre del operador, Dir IP,
> etc. Listas negras a nivel de routing son muy peligrosas, como hemos
> visto que ha pasado con los filtors para algunos /8 como el 76/8, etc.
> de todas formas, creo que tener un grupo/lista donde compartir
> informacion y experiencias sobre la operacion del dia a dia es muy
> importante.
> 
> Dado que esta es la lista de politicas de LACNIC, deberiamos pensar en
> algo positivo que se pueda hacer al respecto desde el punto de vista de
> las politicas.
> 
> Podemos pensar en politicas duras (que yo no comparto) como puede ser,
> el proveedor que ha recibido denuncias de DDoS no puede recibir nuevas
> asignaciones.
> 
> O aspectos mas constructivos. Por ejemplo, pienso en algunas medidas
> desde el punto de vista de las politicas:
> - Obligatoriedad del contacto por abusos (abuse-c) o crear un ddos-c,
> exclusivo para estos ataques.
> - Obligatoriedad de presentar en el momento de solicitar bloques
> adicionales un procedimiento interno donde se detalla como se manejan
> las denuncias de ataque de DDoS.
> 
> Solo para dar como referencia, queria marcar que varios proveedores
> implementan comunidades BGP para mitigar el efecto de DDoS creando
> rutas a Null0.  Como Carlos dice, con estas tecnicas se deja las redes
> inoperativas, pero los proveedores estan permitiendo ser tan especifico
> como un /32. Esta solucion no es una lista de acceso sino que es una
> entrada adicional en la tabla de routing por lo que, en principio, no
> aumenta el consumo de CPU en forma considerable.
> 
> Aqui hay algunos links (a veces se llama: REMOTE TRIGGERED BLACKHOLE):
> http://www.bgpexpert.com/antidos.php
> http://www.sprint.net/policy/bgp.html
> 
> Se que Global Crossing y Level3 tambien lo han implementado, no
> encuentro los links ahora.
> 
> Roque
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas