El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
www.avast.com
Gracias Fátima y Alejandro. Para quienes estén interesados para ver ciberataques, les envió este link. Pueden tardar varios minutos en recorrerlo, pero está muy interesante y nos da una idea muy concreta de cantidad de ataques, no solo ICANN los sufre. CYBERTHREAT REAL-TIME MAP:
https://cybermap.kaspersky.com/
Además las herramientas para generar estos ataques son muy accesibles, y las herramientas para prevenir o minimizar estos ataques, suelen no serlo, además es necesario toda una ingeniería de seguridad, una administración de seguridad, no herramientas dispersas. Y un costo importante, que nadie quiere tomarlo como inversión, y si lo toman como un gasto.
En particular, sería muy interesante que todos nos aboquemos a la propuesta de Alejandro, podríamos generar un mapa de nuestra Región. Desde allí sería muy importante lo que podamos hacer, quizás lograr modificaciones de políticas que protejan al usuario final.
Saludos cordiales
Alberto Soto
De: Alejandro Pisanty [mailto:apisanty@gmail.com]
Enviado el: lunes, 14 de diciembre de 2015 4:32 a. m.
Para: Fatima Cambronero <fatimacambronero@gmail.com>
CC: Alberto Soto <asoto@ibero-americano.org>; LACRALO <lac-discuss-es@atlarge-lists.icann.org>
Asunto: Re: [lac-discuss-es] Ataque de Denegación de Servicios a root servers de ICANN
Colegas,
el tema del intento de negación de servicio a los servidores del DNS debería ser de interés para los usuarios generales y sobre todo sus representantes, como se entiende que lo aprecian también Alberto y Fátima por sus mensajes.
La respuesta más detallada de ICANN llama a todos los operadores de redes a usar BCP 38, un documento de la IETF que provee consideraciones y formas de filtrar ciertos tipos de tráfico de ingreso a las redes con direcciones IP falsificadas ("spoofed"). La aplicación de esta práctica no es suficientemente extensa. Existen algunas herramientas para probar si las redes a las que estamos conectados la aplican pero no son confiables cuando estamos detrás de una NAT o DHCP como suele ocurrir en las conexiones domésticas; se necesita conexión desde una dirección IP fija.
Muchos de Uds. operan servidores propios o rentados con esta característica. ¿Pueden identificarse para que exploremos cómo apoyar a los usuarios en general midiendo primero el cumplimiento de esta práctica y luego recomendando lo que proceda a los operadores desde nuestras respectivas organizaciones o incluso desde LACRALO en su conjunto?
Alejandro Pisanty
On Sun, Dec 13, 2015 at 12:44 PM, Fatima Cambronero <fatimacambronero@gmail.com> wrote: