[lacnog] Problemas para accesar a YouTube ayer por ruteo
Roque Gagliano
roque en lacnic.net
Mie Feb 27 00:43:21 BRT 2008
buen dato, tenes alguna referencia?
r.
On Feb 27, 2008, at 11:38 AM, José Manuel Echenique H. wrote:
> Integrar Nagios con Asterisk éste a su vez conectado a la PSTN por
> medio de un fxo te permite enviar no un SMS sino una llamada a tu
> telefono cuyo mensaje de voz previamente configurado se asocia al
> evento generado.
>
> 2008/2/26 Roque Gagliano <roque en lacnic.net>:
> Hola,
>
> Solo queria comentarles sobre una herramienta desarrollada por RIPE
> que les avisa si alguno de sus bloques esta siendo anunciado por
> algun ASN que no deberia hacerlo (siempre que no sea vuestro
> servidor de correo!). Seria bueno que todo el mundo con un ASN se
> asociara.
>
> http://www.ris.ripe.net/myasn.html
>
> Otra cosa, relacionada con esto. Alguno de ustedes usan plaquetas
> para SMS para poder mandar SMS de alarmas cuendo no tienen acceso al
> mundo desde su correo electronico?
>
> Roque
>
>
>
> On Feb 26, 2008, at 6:52 PM, Nicolas Antoniello wrote:
>
>> Estimados,
>>
>> Es cierto que la versión actualmente más utilizada de BGP no es tan
>> segura como al parecer
>> lo requiere el día de hoy... pero en este caso en particular (esto
>> fue ampliamente
>> discutido en NANOG entre ayer y hoy), la solución más utilizada es
>> la de filtrar los
>> prefijos recibidos de los ISP o clientes (esto no es algo nuevo).
>>
>> Nosotros lo hacemos y la mayoría de nuestros carriers también. A
>> pesar de esto, es cierto
>> que en el mundo no todos lo hacen (de hecho, algunos de nuestros
>> carriers, grandes
>> carriers, no realizan filtrados de prefijos sino que filtran solo
>> por AS path), entonces,
>> es aquí donde surge el problema.
>>
>> Es cierto que en muchos casos, donde un carrier recibe cientos de
>> prefijos de un cliente,
>> se vuelve muy difícil mantener un filtrado que no sea "automatizado".
>>
>> Creo que el filtrado por prefijo es algo indispensable, al menos en
>> la versión actual de
>> BGP, no con la premisa de desconfiar de todos, sino por la premisa
>> de que siempre existe
>> la posibilidad de equivocarse... y cualquiera de los que nos
>> dedicamos a la administración
>> de redes, ya sea pequeñas o grandes, hemos tenido experiencias de
>> esas... en las que nos
>> equivocamos y decimos: "por suerte estaba esto que evito que pasara
>> aquello"...
>>
>> Hay que condenar al que se equivoca? No, hay que fomentar e
>> impulsar ciertas prácticas que
>> en caso de errores o accidentes, eviten la propagación del desastre.
>>
>> Si bien creo que todo lo que se ha dicho es cierto, tengo dos
>> reflexiones personales sobre
>> algunos puntos en particular:
>> * En este caso, si existe la posibilidad de en cierta manera
>> "asegurar" el continuo de
>> funcionamiento en un caso como el que se dio que es el viejo y
>> nunca bien ponderado
>> filtrado de prefijos recibidos.
>> * En cuanto a "hacer cosas mal por parte de administradores de
>> ASN", creo que esto es
>> relativo, ya que estos acontecimientos pueden suceder no solo por
>> "errores graves" por
>> parte de los administradores, sino por una suma de aspectos que por
>> alguna razón no se
>> tuvieron en cuenta antes, que individualmente pueden parecer
>> menores, pero que "alineados"
>> provocan un desastre.
>> Soy resistente a creer que CUALQUIER administrador de CUALQUIER red
>> por mas titulos que
>> tenga o red mas grande que administre, nunca cometa errores que
>> alguno puede catalogar de
>> "graves"... hagamos una reflexión personal a ver si NUNCA nos
>> mandamos una grande !! :)
>> Creo que eso no hace al "profesionalismo" o "calidad" del
>> administrador, pero si el
>> reflexionar luego de lo sucedido, para que no se repita con el
>> mismo patrón o secuencia de
>> eventos.
>>
>> Por cierto, la opción de filtrado, previene también un caso de
>> "mala intención".
>>
>> La pregunta entonces, es: que mecanismos hay hoy en día, para
>> verificar que los prefijos
>> que me pasan los clientes, son efectivamente de ellos y así armar
>> el filtro? Bueno, la
>> respuesta es que existen varias formas (con pros y contras)... pero
>> eso da para otra
>> discusión. :)
>>
>> Saludos,
>> Nicolas.
>>
>>
>>
>> Ricardo Patara wrote:
>>>> Hugo,
>>>>
>>>> Estoy de acuerdo contigo, pero creo que lo quiso destacar
>>>> Francisco es que el
>>>> sistema BGP por si tiene fragilidades de seguridad.
>>>>
>>>> Se verifica con eso como es fácil perjudicar un sitio (mismo que
>>>> esa no haya
>>>> sido la intención de los de PCCW).
>>>>
>>>> uno con intención puede hacer lo mismo para secuestrar el trafico
>>>> de un sitio,
>>>> pues el bgp actual no se garantiza que quien hace un anuncio
>>>> tiene derecho de
>>>> hacerlo.
>>>>
>>>> saludos
>>>> Ricardo
>>>>
>>>>>> Yo creo que este tipo de problemas se van a
>>>>>> seguir presentando siempre que el adminstrador de un ASN haga
>>>>>> las cosas mal.
>>>>>>
>>>>>> BGP tiene caracterisiticas que lo hacen
>>>>>> loop-free, pero no es inmune a errores graves en configuración.
>>>>>>
>>>>>> Saludos
>>>>>>
>>>>>> Hugo Zamora
>>>>>>
>>>>>>
>>>>>> At 12:57 p.m. 25/02/2008, Francisco Arias wrote:
>>>>>>
>>>>>>>> Por si no han visto la noticia del
>>>>>>>> problema que tuvo ayer el sitio de YouTube por un
>>>>>>>> filtrado de ruteo mal hecho, les paso un par de ligas.
>>>>>>>>
>>>>>>>> En español, la reseña de Arturo Servín:
>>>>>>>> http://arturo-servin.blogspot.com/2008/02/rutas-envenenadas-route-poisoning.html
>>>>>>>>
>>>>>>>> En inglés con la explicación detallada de lo que
>>>>>>>> sucedió:
>>>>>>>>
>> http://arstechnica.com/news.ars/post/20080225-insecure-routing-redirects-youtube-to-pakistan.html
>>>>>>>>
>>>>>>>> Lo interesante es que se trata del
>>>>>>>> primer caso de un ataque (aunque al parecer
>>>>>>>> involuntario) en el sistema de ruteo a un portal
>>>>>>>> de primer nivel mostrando la fragilidad del
>>>>>>>> sistema ante la falta de una opción para
>>>>>>>> asegurarlo. Si esta noticia llega a los titulares
>>>>>>>> de los medios masivos, quizá podríamos tener
>>>>>>>> pronto apoyo verdadero a los trabajos para asegurar el ruteo
>>>>>>>> en Internet.
>>>>>>>>
>>>>>>>> fjac
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> lacnog mailing list
>>>>>>>> lacnog en lacnic.net
>>>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>>>
>>>>>> _______________________________________________
>>>>>> lacnog mailing list
>>>>>> lacnog en lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> _______________________________________________
>>>> lacnog mailing list
>>>> lacnog en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>>
>>
>>
>> _______________________________________________
>> lacnog mailing list
>> lacnog en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>
>
> _______________________________________________
> lacnog mailing list
> lacnog en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
>
> _______________________________________________
> lacnog mailing list
> lacnog en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20080227/2acba1c2/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20080227/2acba1c2/attachment.sig>
Más información sobre la lista de distribución LACNOG