VPSs y mas.

Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta seguridad. Mostrar todas las entradas

martes, 2 de octubre de 2018

Aportando un grano de arena en la seguridad de la red, un caso de éxito

Introducción

Seguramente algunos de ustedes conocen el proyecto IPv6 DNS Open Resolvers [1] que lleva adelante LACNIC, un trabajo conjunto de WARP [2] y de I+D donde identificamos servidores abiertos DNS con direccionamiento IPv6.
Tradicionalmente no ofrecemos soporte de ningún tipo para la infraestructura de nuestros asociados, esto quiere decir que LACNIC “no toca” los equipos (servidores, dispositivos de red). Sin embargo siempre hemos extendido una mano de apoyo para colaborar en todo lo que podamos.

Contexto

Luego de haber identificado una dirección IPv6 donde se encuentra una servidor DNS recursivo abierto, envíamos un correo automatizado a la organización dueña de la dirección IP alertando la situación. En él explicamos las posibles consecuencias y recomendamos una serie de configuraciones para los servidores más usados. Dicho correo tiene un formato similar a:
===
DATE DD-MM-AAAA


Dear ORG-ID NAME. (OR-ID-LACNIC):

You appear to be running a DNS - open recursive resolver at IP address 280X:XXXX:X:XXXX:XXXX:XXXX:XXXX:XXXX.

It may have undesirable consequences on the Internet because it may participate in an attack against a selected target, causing a Denial of Service (DOS) attack. It generates large UDP responses to spoofed queries, with those responses becoming fragmented because of their size.

We strongly recommend to reconfiguring your resolver. Here are some ways that may help you:


- To only serve your customers and not respond to outside IP addresses (in BIND, this is done by defining a limited set of hosts in "allow-query";)

options {

 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of options


- To only serve domains that it is authoritative for (in BIND, this is done by defining a limited set of hosts in "allow-query" for the server overall but setting "allow-query" to "any" for each zone)

zone "example.com"{
 type master;
 file "example.com.db";
 allow-query {
  192.168.196.0/24;
  2001:db8::/32;
  localhost;
 } // end of allow-query
} // end of zone example.com


In unbound you can achieve the same behavior with the access-control statement in the unbound.conf file. Would be something like:

server:
 access-control: 2001:db8::/32 allow


If you are an ISP, please also look at your network configuration and make sure that you do not allow spoofed traffic (that pretends to be from external IP addresses) to leave the network. Hosts that allow spoofed traffic make possible this type of attack.

References:
More information on this type of attack and what each party can do to mitigate it can be found here: http://www.us-cert.gov/ncas/alerts/TA13-088A


Best regards,

LACNIC's WARP Team

=======

Caso de éxito

Queremos presentarles este caso de éxito que comenzó cuando una organización recibió el correo indicado anteriormente y se contactó con WARP buscando recibir apoyo para aplicar las recomendaciones de seguridad en sus equipos. Por ser un proyecto nuevo no nos había ocurrido esta situación anteriormente pero analizamos el caso decidimos proseguir por dos razones:
⋅⋅1. La persona que nos contactó se mostró realmente interesada
⋅⋅2. El OS y el servidor DNS se encontraba en el grupo de los cuales tenemos experiencia
Comenzamos por identificar dónde estaban los archivos de configuración del servidor y los ACLs que él mismo utilizaba. Luego le guiamos para implementar en la configuración existente, las recomendaciones de seguridad genéricas que enviamos en el correo inicial.
La buena noticia fue que el miembro de LACNIC, siempre se mostró muy dado a recibir nuestra ayuda y la comunicación fue muy fluida en todo momento. Al cabo de menos de dos semanas, con aproximadamente 8 correos intercambiados, el servidor que era una potencial amenaza se encontraba configurado de tal manera que solo permitía consultas DNS desde sus propios prefijos.
Pero esto no fue todo, la alerta que enviamos y por la cual fuimos contactados, refería solo a uno de los servidores administrados por esta organización. Para completar nuestra tarea, nuestro miembro identificó que otro servidor de su red se encontraba en las mismas condiciones que el anterior, por lo que también colaboramos en la aplicación de las correcciones necesarias.
El caso lo consideramos muy exitoso por ser servidores que tienen direcciones IPv6 estáticas las cuales eventualmente podrían ser descubiertas por algunos atacantes y traer consigo eventuales tareas maliciosas sobre la red.
Lo anterior no quiere decir que sea el único caso de éxito ocurrido, muy posiblemente otros operadores han tomado acciones sobre sus servidores sin conocimiento alguno de LACNIC. Prontamente estaremos trabajando en identificar estos casos y publicaremos algunos resultados.

Referencias

[1] (https://labs.lacnic.net/Identificando-servidores-DNS-IPv6-Open-Resolvers/)
[2] (https://warp.lacnic.net/)

Por:

Darío Gómez

Security Analyst at LACNIC WARP



y

Alejandro Acosta



viernes, 17 de agosto de 2018

Demostración: Antispoofing IPv6 en un router Cisco IOS

El siguiente video muestra como simular un ataque spoof en Internet y como prevenir el mismo en Cisco IOS


 

miércoles, 23 de mayo de 2018

Script in Python3 que chequea fecha de vencimiento de certificados SSL y envia correos

Intro:
  Abajo les dejo un script realizado en Python3 que chequea fecha de vencimiento de certificados SSL (https) y realiza el envio de correos.

Importante:
  Que corra en OS modernos (Ubuntu 16.04 o mayor por ejemplo).., la razón es el soporte de librerías actualizadas SSL

El Script:
$ more check_ssl_certificates.py 




#!/usr/bin/python3

#El objetivo de este script es revisar los hostnames en la lista hostnames

#revisar cuantos dias faltan para que expire el certificado SSL

#y se expira pronto (definido por la variable umbral) enviar un correo

#con dicha notificacion




import OpenSSL

import ssl, socket

import argparse

from OpenSSL import SSL

from datetime import datetime




# Please add every FQDN you wish to be checked

hostnames = ["www.sitio1.com","www.sitio2.com","www.sitio3.com"]

umbral = 10 #threshold - number of days left in order to send the notification

notify_to= "you@yourserver.com, youyou@yourserver.com" #list of email addresses to send email separated by ,




def cert_expiration_date(hostname):

# get SSL Cert info

try:

cert = ssl.get_server_certificate((hostname, 443))

x509 = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, cert)

x509info = x509.get_notAfter()




exp_day = x509info[6:8].decode('utf-8')

exp_month = x509info[4:6].decode('utf-8')

exp_year = x509info[:4].decode('utf-8')




exp_date = str(exp_day) + ' ' + str(exp_month) + ' ' + str(exp_year)

expire_date = datetime.strptime(exp_date, "%d %m %Y")







except Exception:

MSG='el host ' + str(hostname) + ' no pudo ser chequeado '

sendnotification(hostname, 0, MSG)

return #will enter here if could not connect to the website port 443




#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', exp_date)

#print('SSL Certificate for hostname', hostname, 'will be expired on (DD-MM-YYYY)', expire_date)



expire_in = expire_date - datetime.now()

expire_in = str(expire_in).split(' ')[0]




if int(expire_in) < umbral :

MSG='el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

sendnotification(hostname, str(expire_in), MSG)




#print ('Expira en: ', expire_in)




def sendnotification(hostname, expire_in, MSG):

from smtplib import SMTP_SSL as SMTP

import logging

import logging.handlers

import sys

from email.mime.text import MIMEText




#MSG = 'el cert ssl de ' + str(hostname) + ' expira en ' + str(expire_in) + ' dias'

#text = MSG

msg = MIMEText(MSG, 'plain')

msg['Subject'] = MSG

me = 'your@email.com'




recipients = notify_to

msg['To'] = notify_to

try:

conn = SMTP('yourmailserver.com')

conn.set_debuglevel(True)

conn.login('authusr', 'yourpassword')

try:

conn.sendmail(me,recipients.split(',') , msg.as_string())

finally:

conn.close()

except Exception as exc:

logger.error("ERROR!!!")

logger.critical(exc)

sys.exit("Mail failed: {}".format(exc))






if __name__ == "__main__":

for hostname in hostnames:

cert_expiration_date(hostname)


lunes, 22 de enero de 2018

Propuesta de una fuente confiable de enrutamiento para la región de LAC

Introducción

Recientemente fue publicado un artículo por Job Snijders llamado: “A New Source For Authoritative Routing Data”, su traducción viene a ser algo como: “Una nueva fuente de información de enrutamiento autoritativa”. (Snijders 2017)
El documento trata sobre un trabajo donde explica como varios expertos y en contribución con varias instituciones construyeron una manera de proveer a la comunidad información confiable sobre enrutamiento. Para ir entrando en detalles técnicos podemos verlo como algo entre un IRR (“Internet Routing Registry - Wikipedia” n.d.) y RPKI (“Resource Public Key Infrastructure - Wikipedia” n.d.)
En este documento se describe una propuesta de LACNIC a la comunidad, con el fin de proveer una fuente de información autoritativa confiable sobre enrutamiento que pueda utilizarse por parte de los operadores de Internet de la región.

Un poco de historia

En el post de Job Snijder se explica cómo se tomó como fuente de información confiable la base de datos de Whois de ARIN y especificamente un campo llamado Origin el cual especifica cual AS (Sistema Autónomo) es quien anunciará determinado prefijo.
Posteriormente lo que se hace con esa información es construir un archivo JSON (“JSON - Wikipedia, La Enciclopedia Libre” n.d.) el cual puede ser utilizado fácilmente por programadores y diferente software de forma muy similar a lo que hace un IRR actualmente.

¿Qué hicimos en Lacnic?

Luego de analizar el post anterior y nuestras opciones, concluimos que el campo OriginAS prácticamente no es utilizado en el WHOIS de LACNIC, por lo que no estaríamos en condiciones de extraer esa información a partir de esa fuente. Sin embargo, dado el gran porcentaje de ROAs creados en varios países de la región (“Statistics — RIPE Network Coordination Centre” n.d.), creemos conveniente utilizar RPKI como fuente de información.

¿Cómo se tomó la información de RPKI?

Para utilizar la informacion de RPKI de LACNIC trabajamos con el validador RPKI de RIPE (“Tools and Resources” n.d.), con la diferencia que removimos todos los TAL (Trust Anchor Locator) exceptuando el de LACNIC. De esta manera el validador unicamente estaría procesando los ROAs correspondientes a nuestra región. Finalmente lo que hicimos fue exportar los ROAs en formato JSON, una funcionalidad que ofrece el propio validador.

Proceso de la información de RPKI

Finalmente, utilizando un script en python3 y en base al JSON exportado del Validador de RIPE construimos un nuevo archivo de JSON, (“Tools and Resources” n.d., “Website” n.d.) con una similitud sintáctica de 95% al del proyecto previo (“Website” n.d.)(Job Snijders y compañía). En este sentido, la manera como se crea la fecha, las posiciones relativas en el archivo, los nombres de las llaves son identicos, de esta manera facilitamos la interoperatividad con scripts y software ya existente.
Adicionalmente, esta misma información se publica en format RPSL(“Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre” n.d.), un formato que es más habitual para los operadores. De esta forma, se puede elegir entre ambos formatos para procesar o utilizar la información autoritativa.

Avances actuales

En base a todo lo mencionado anteriormente actualmente:
  • Se publica diariamente un dump de todos los ROAs en formato JSON
  • Se publica en RPSL la información correspondiente al AS de Origen y el prefijo (tanto v4 como v6) Lo anterior viene acompañado de un un hash de comprobación bajo SHA384 URL http://stats.labs.lacnic.net/RPKI/RPKItoJSON/

Espacio para mejoras

Sabemos que existen muchas cosas para mejorar, por el momento debemos mencionar:
  1. Publicar los archivos en un server con soporte de https

Conclusiones

Dentro de Lacnic este proyecto aun se encuentra en una etapa Alfa, a lo sumo Beta. Dependeremos 100% de los comentarios recibidos de la comunidad si deseamos llevar esta idea a un ambiente con carácter de producción. Por ello no dude en comunicarse con nosotros, somos muy buenos recibiendo quejas, comentarios y felicitaciones.

Consideraciones adicionales

En los ROAs es posible especificar una longitud máxima y mínima de prefijos a publicar, sin embargo esto no tendría una forma similar de replicarlo en el archivo de salida. Una posibilidad en IPv4 sería generar los prefijos intermedios con el mismo sistema autónomo de origen, pero en IPv6 esto no sería posible por la cantidad de direcciones involucradas. Otra posibilidad es no utilizar las longitudes mínima y máxima en los ROAs, ya que esa es la situación análoga a los IRRs. El formato JSON de salida es fácilmente convertible a RPSL, con lo cual se pueden utilizar las mismas herramientas que se utilizan para procesar la información de un IRR. Un punto a analizar es si resulta necesario poder contar con otros objetos que no están incluidos en esta base de datos auto-generada.

Por:

  • Alejandro Acosta alejandro \at lacnic dot net
  • Guillermo Cicileo guillermo \at lacnic dot net

Referencias

  1. “Internet Routing Registry - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Internet_Routing_Registry.
  2. “JSON - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/JSON.
  3. “Resource Public Key Infrastructure - Wikipedia.” n.d. Accessed January 19, 2018. https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure.
  4. “Routing Policy Specification Language - Wikipedia, La Enciclopedia Libre.” n.d. Accessed January 19, 2018. https://es.wikipedia.org/wiki/Routing_Policy_Specification_Language.
  5. Snijders, Job. 2017. “A New Source For Authoritative Routing Data: ARIN WHOIS.” Medium. Medium. December 19, 2017. https://medium.com/@jobsnijders/a-new-source-for-authoritative-routing-data-arin-whois-5ea6e1f774ed.
  6. “Statistics — RIPE Network Coordination Centre.” n.d. Accessed January 19, 2018. https://lirportal.ripe.net/certification/content/static/statistics/world-roas.html.
  7. “Tools and Resources.” n.d. RIPE Network Coordination Centre. Accessed January 19, 2018. https://www.ripe.net/manage-ips-and-asns/resource-management/certification/tools-and-resources.
  8. “Website.” n.d. Accessed January 19, 2018a. http://stats.labs.lacnic.net/RPKI/RPKItoJSON/.

lunes, 1 de enero de 2018

Solucion de errores: SSH "Permission denied (publickey)". Luego de upgrade. Facil y rapido

En caso de que estes recibiendo el siguiente error al hacer un ssh:


"Permission denied (publickey)."

pero extrañamente venía funcionando todo quizás fue por un upgrade de openssh o del sistema operativo.
Lo primero que te recomiendo es realizar un ssh y con algo de debug (por ejemplo con el -v)

Quedarías así:


$ ssh -v -l alejandro miserver.com

Verás algo así:

$ ssh -v -l alejandro miserver.com
OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /Users/alejandroacosta/.ssh/config
debug1: /Users/alejandroacosta/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 49: Applying options for *
debug1: Connecting to miserver port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_rsa-cert type -1
debug1: identity file /Users/alejandroacosta/.ssh/id_dsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/alejandroacosta/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to miserver.com:22 as 'alejandro'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:0CjzVIchz9571bMTChmp6cMZ+9QVogt9mHSaK8JA5VQ
debug1: Host '[miserver.com]:22' is known and matches the ECDSA host key.
debug1: Found key in /Users/alejandroacosta/.ssh/known_hosts:20
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: Skipping ssh-dss key /Users/alejandroacosta/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_rsa
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_ecdsa
debug1: Trying private key: /Users/alejandroacosta/.ssh/id_ed25519
debug1: No more authentication methods to try.
alejandro@miserver.com: Permission denied (publickey).


La linea mas importante es:

"debug1: Skipping ssh-dss key /Users/alejandroacosta/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes"


Existen varias maneras de solucionarlo, muchas estan mencionadas en:

https://stackoverflow.com/questions/39715135/problems-deploying-code-with-capistrano-since-upgrading-to-macos-10-12-sierra

y

https://rolfje.wordpress.com/2016/11/12/macos-sierra-ssh-permission-denied/


Sin embargo si estas urgido, corriendo puedes solucionarlo inmediatamente haciendo esto:

Solución

echo "Host *" >> ~/.ssh/config
echo "PubkeyAcceptedKeyTypes=+ssh-dss" >> ~/.ssh/config


Mas información:

https://ro-che.info/articles/2015-12-21-permission-denied-publickey-ssh-update












jueves, 23 de marzo de 2017

BGP: Filtrar por tamaño de la red en BGP, he ahí el dilema

Introducción
 El equipo de I+D del área técnica y WARP redactaron en conjunto el presente artículo basado en algunos incidentes gestionados por el centro de respuestas de LACNIC.
 En el mundo de BGP existen decenas de maneras para filtrar prefijos. El objetivo del presente post mostrar una serie de recomendaciones para tener una red más estable, no perder conectividad con ciertos destino y reducir el número de quejas en nuestro NOC.


Situación identificada
  Muchos ISPs no pueden recibir la full routing table de BGP (para el dia de hoy consta de ~610.000 prefijos IPv4) en sus enrutadores.
  Lo anterior puede deberse a diversas razones:
  • El enrutador no posee suficiente RAM para aprender todos los prefijos (además recordar que es posible que el router tenga varias sesiones BGP)
  • Por ahorro de CPU
  • Porque el upstream provider a su vez no entrega toda la tabla de enrutamiento
  • Por simplicidad y sencillez


 Entendiendo la situación e independientemente de la razón que sea, el enrutador no aprende toda la tabla de enrutamiento.


Problema
  No aprender toda la tabla de enrutamiento puede traer algunos inconvenientes parciales pero que al final trae problemas de conectividad, quejas de los usuarios, inconvenientes de acceso a ciertos sitios, entre otros.


¿Por qué?
  Imaginemos la siguiente situación:
  1. Tengo un router (propiedad de EXAMPLE) en Internet que solo aprende la tabla parcial de enrutamiento
  2. El router propiedad de EXAMPLE quedó configurado solo para aprender redes “más grandes” que /21. Es decir, aprende redes /20, /19, /18, etc.  (evidentemente estamos hablando de IPv4)
  3. Debido a la configuración establecida en el punto “b”, el router no aprenderá prefijos de tamaño /21, /22, /23 ni /24
  4. Mientras tanto en otra parte del mundo, le acaban de secuestrar su red /21 a la empresa ACME (planteamos el caso como un secuestro pero podría ser una mala configuración)
  5. ACME decide realizar anuncios más específicos de su red original /21, es decir, anuncia 8 redes /24
  6. Por causa de los filtros configurados por EXAMPLE, nunca verá dichos anuncios /24 de ACME
  7. EXAMPLE seguirá aprendiendo la red /21 del secuestrador de la red. Lo que puede ocasionar que el tráfico hacia ACME puede ser potencialmente secuestrado (repito, se entiende que esta situación es potencial, no necesariamente el tráfico irá hacia el atacante)


Diagrama:
  El siguiente diagrama representa la hipótesis planteada en el punto anterior de manera gráfica para facilitar su comprensión.
Articulo BPG.png

Recomendación
 Realizaremos la siguiente recomendación en base a algunas experiencias vividas, teniendo en cuenta que solo aplican al caso de cuando no se pueda aprender/recibir la tabla completa de BGP:
  1. No filtrar permitiendo redes menos específicas. Es conveniente aprender redes más chicas, es decir: /24, /23, /22.
  2. Filtrar por AS_PATH de profundidad.
  3. Crear los ROAs respectivos a los prefijos (RPKI).


Algunos ejemplos (Cisco like)
1)  Solo queremos aprender redes entre /22 y /24 (hay otras maneras de hacer esto):

router bgp 65002
neighbor 10.0.0.1 remote-as 65001
neighbor 10.0.0.1 route-map FILTRO-IN in
!
ip prefix-list REDESCHICAS seq 5 permit 0.0.0.0/0 ge 22 le 24
!
route-map FILTRO-IN permit 10
match ip address prefix-list REDESCHICAS
!


2) Solo queremos aprender dos AS de profundidad (hay otras maneras de hacer esto):


router bgp 65001
neighbor 10.0.0.2 remote-as 65002
neighbor 10.0.0.2 route-map ASFILTER-IN in
!
ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
!
route-map ASFILTER-IN permit 10
match as-path 5
!


Mas información



Autores
- Dario Gomez
- Alejandro Acosta (@ITandNetworking)

sábado, 28 de noviembre de 2015

Carta de Lacnic Labs a Papa Noel

Querido Papá Noel, alias Santa Claus,

  Quiero comenzar esta carta dándote un gran saludo,  ojalá también pudiese darte un fuerte abrazo. Hace mucho que no te escribía, siento una felicidad interna indescriptible e inesperada.
  Quizás te extrañe un poco que vuelva a aparecer luego de tantos años, dicen que nunca es tarde, te aseguro que el cariño es el mismo, perdón, hoy en día es mayor, he aprendido a comprenderte y admirar tu trabajo, mis felicitaciones a tú persona!! :-)
  Antes de continuar no puedo omitir indicarte que todo el año me he portado muy bien, he hecho mis tareas cabalmente, ayudo al prójimo, he intento ser parte de la solución y no del problema. Claro, tú lo sabes todo pero quería decírtelo para prevenir, alguna se te debe escapar.
  Ahora bien, vamos al grano, se que tienes mucho trabajo y sobre todo en estas fechas, tu tiempo es valioso así que no voy a extenderme mucho.
  Te escribo no por mí, desde chico me enseñaron a pedir para los demás, en esta ocasión voy a pedir por alrededor de 600 millones de latinoamericanos, suena mucho pero créeme que solo hay que enfocarse en una pequeña cúpula de personas.., el resto viene solo.
  ¿Qué voy a pedir para toda esta gente?…, cosas más sencillas que lo que parecen, me han dicho que no sabes mucho de tecnología y por ello voy a explicarte muy breve cada regalito.., ahh, tampoco voy a pedir mucho, me han enseñado a máximo tres regalos y sin garantía de que se cumpla…., pienso que mis padres repetían lo que tu le decías a ellos.
  Quiero para esta navidad o durante el 2016:

- Un Internet más seguro… Santa, puedes creer que existen muchas tecnologías de seguridad y aún no las implementan!, muchas gratis y sencillas, bueno Santa, esta no puede faltar. Pls!
- Mejores interconexiones… con esto quiero decir más IXPs, más conexiones entre ISPs y diferentes entidades. Esto trae ahorre de costos, mejor rendimiento, mayor uptime de servicios, facilidad de troubleshooting y muchas cosas más. Es una práctica mundialmente aplaudida y comprobada y aún hay gente que no esta convencida. ¿Me ayudas?
- Y por último…, más IPv6 en la región!. ¿Puedes creer que el promedio aún es ligeramente mayor al 1% en LAC?.., estamos hablando de un protocolo que va a ayudar a los países a ser más productivos, a mejorar la calidad de vida de la gente, a disminuir la rata de falla en las aplicaciones y aún así mucha gente no da el paso a implementarlo. ¿Cuento contigo?


  En estos tiempos tan difíciles de gusanos, backdoors, rootkits, troyanos, secuestro de redes e información creo que mi solicitud no es una cosa loca, se que no es fácil pero entre todos podemos :-)   Ahh, no debemos olvidar el otro casi 50% de la población que aun no cuenta con Internet, afortunadamente este indicador se mueve a favor de mí deseo pero me encantaría que fuese más rápido, no por mí, sino por ellos.

  Antes de finalizar la carta no quiero despedirme sin enviarle saludos a la señora Santa y a los renos -en especial a Rodolfo!!-, quienes han hecho pasar horas de infinita alegría a millones de niños.  Espero todos tengan su tablet y su conexión a Internet con IPv6, sino me avisas y vemos si podemos conectarte en el Polo Norte…, creo que no lo cubre Lacnic pero te extendemos nuestro apoyo.

  Recibe un gran saludo, ojalá pases por mí casa  y en vez de dejarte unas galletas  y leche, te daré un modem Wifi 802.11ac y un SSD.

Un fuerte abrazo con mucho amor

Lacnic Labs

miércoles, 27 de mayo de 2015

Sinopsis FLIP6 Lima Peru 18-22 de Mayo 2015

Buenas dias a todos(as),


 Una vez más para mi es un honor realizar este resumen. En esta
oportunidad me corresponde sobre el Decimotercer Foro Latinoamericano de
IPv6 (FLIP6) llevado a cabo durante el evento de Lacnic 23 en Lima -
Perú entre los días 18 al 22 de Mayo del presente año.

 Todos los eventos son especiales, cada uno tiene su propia magia, sin
embargo esta oportunidad venía acompañado de un contexto adicional por
ser mi último año como moderador del foro.

 En Lima, FLIP6 tuvo una duración de 6 horas divididas en tres días
consecutivos. Para el evento hubo más de 450 personas en sitio y
aproximadamente 100 personas haciendo seguimiento vía Webcasting. Para
el momento que se escriben estas líneas parte de las presentaciones se
encuentran en youtube.com ([1]) y en el sitio guindadas en la web de
Lacnic ([2]).

 Hablando del evento per sé: contamos con los siguientes expositores más
un panel (la agenda puede ser conseguida también en [2]):


Expositores:

- John Correa

 John Correa estaba exponiendo por primera vez durante FLIP6, su tema
fue "Asegurando servicios IPv6 en Linux". El tópico indiscutiblemente es
considerado un tema muy importante en estos tiempo donde las
implementaciones de IPv6 se están llevando a cabo a un ritmo acelerado.
Desde FLIP6 además de incentivar el protocolo lo queremos promover de
manera segura.


- Panel: Fabricantes e IPv6

 El Panel fue una iniciativa de Lacnic que vino como resultado de las
encuestas realizadas en eventos previos donde los asistentes
manifestaban que sería buena idea contar con los propios fabricantes
hablando directamente de su soporte de IPv6 en sus productos.

 El Panel estuvo compuesto por los siguientes panelistas:

 - Tomás Lynch, Ericsson
 - Hugo Peña - Alcatel-Lucent
 - Wardner Maia, Mikrotik
 - Enrique Dávila, Cisco


 Al final esta presentación fue muy exitosa, en lo personal tuve muy
buen feedback y siempre escuchar del propio vendor hablar de su soporte
IPv6 es muy beneficioso.


- John Brzozowski - KeyNote

 Como es costumbre, dentro del FLIP6 contamos con la presencia de un
Keynote, en esta oportunidad le correspondió a un amigo de la casa: John
Brzozowski. Durante su presentación cubrió diferentes temas relevantes a
IPv6: Desde estadísticas, novedades en Comcast, importancia de IPv6
entre otros. Este tipo de exposiciones esperemos apoyen a la difusión
del protocolo a lo largo y ancho de nuestra región.


- Jordi Palet - 464XLAT

 Jordi, viejo amigo de la casa, expuso sobre una interesante tecnología
la cual ha tenido mucha  adopción y probablemente se masifique más su
implementación en un corto tiempo. Su presentación trató sobre el
mecanismo de transición 464XLAT. Esperamos haya sido educativo y le
sirva de puente a muchos para implementar IPv6 en sus redes


- Gregorio Manzano - Iniciativa comunitaria para despliegue del
protocolo IPv6 en Venezuela

 Esta presentación trató sobre como un grupo de lideres en Internet en
Venezuela llevaron a cabo la formación de un grupo para promover IPv6 en
su país. Gregorió abarcó desde sus inicios hasta la entrega de un
documento al gobierno de Venezuela. Felicitamos esta iniciativo y ojalá
existan más en la región.


- Kathleen Moriarty - IETF CodeMatch

 Por primera vez en FLIP6 tuvimos a Kathleen Moriarty quien trabaja muy
de cerca con ISOC y la IETF. Nos expuso sobre una excelente iniciativa
llamada CodeMatch donde se busca acercar a las universidades de la
región a la IETF. Kathleen explicó en que consiste y como convertirse en
parte de esta interesante iniciativa. Deseamos ver muchas universidades
de la región involucradas en este tipo de proyectos.


- Fernando Gont - Avances recientes en seguridad de IPv6 y Evaluaciones
de seguridad y resolución de problemas con el IPv6 Toolkit v2.0 de SI6

 Fernando, otro amigo de la casa, tuvo la oportunidad de realizar dos
exposiciones durante FLIP6, ambas muy relaciones a seguridad de red.
Expuso de una manera muy pedagógica basado en ejemplos de como utilizar
IPv6 Toolkit y adicionalmente indicó temas muy importantes de seguridad
en el mundo de IPv6. Una vez para nuestro foro no es solo fomentar IPv6
sino promoverlo dentro de un contexto de implementación segura y basado
en mejores prácticas. Esperamos que con este tipo de charlas educar al
asistentes y fortalecer las redes en la región.


- Enrique Davila - Operar en forma segura redes IPv6

 Enrique Dávila, exponía por primera vez en FLIP6, explicó de una manera
práctica diversas tareas que pueden llevar a cabo los administradores de
redes para operar de mejor manera una red IPv6. Indicó diversos consejos
y prevenciones que pueden tomarse en cuenta con el objetivo de aumentar
la seguridad de una red IPv6. Estamos seguro que esta junto a otras
exposiciones llevadas a cabo durante el FLIP6 permitirán al asistente en
incrementar la seguridad de sus redes.


- Gianpietro Lavado - Segment-Routing in IPv6

  Gianpietro expuso sobre un tema muy novedoso llamado Segment-Routing,
específicamente lo enfocó al área de IPv6. Indicó sus ventajas y
posibles implementaciones que existirán en el futuro cercano. Desde
FLIP6 nos encantan este tipo de temas porque nos permiten estar
enterados en lo que acontece en el marco de la IETF y a su vez
prepararnos mejor para lo que viene en el mundo de enrutamiento en un
futuro no muy lejano


- Mariela Rocha - Informe Portal IPv6

 Mariela Rocha (ex-moderadora de FLIP6*)* nos acompañó en esta
oportunidad para indicarnos avances que existen en el portal IPv6 de
Lacnic [3]. Nos explicó diferentes aspectos y noticias que se guindan en
el mismo, contenido nuevo que tiene y como participar en el mismo. Nos
recordó que el portal es de la comunidad y cada uno de nosotros puede
ser participe del mismo. Ójala esta exposición incentive al asistente a
engranarse con el portal IPv6.


Miscelaneos.

 En este oportunidad el moderador también hizo algunos anuncios:


- Se presentó la canción IPv6 [4]  (favor escucharla y recordar colocar
los subtítulos)

- Se presentó una animación llamada: "La triste historia de un ISP sin
IPv6" [5]

- El actual moderador anunció próximas elecciones para Junio 2015
indicando su intención de no postularse para las mismas. De igual manera
enfáticamente indicó que este cargo ha sido muy enriquecedor dentro de
su vida profesional.


Reciban todos un fuerte abrazo y como siempre quedando a sus ordenes.



Att.

Alejandro Acosta

Moderador
FLIP6 2015



[1] https://www.youtube.com/playlist?list=PLU6Q4ZhHN2Q6Iw4rb9paNKIwYGhEMLCZK

[2] http://www.lacnic.net/en/web/eventos/lacnic23-foro-flip6

[3] http://portalipv6.lacnic.net

[4] https://www.youtube.com/watch?v=99Qw9cfpyEg
Créditos a:
Antonio Esguerra: Head Engineer
Michae Schulze: Co-producer
Eidan Molina: Co-producer. Composer.
Music and Lyrics by Eidan Molina
Agrupacion de producción: Fifth Floor Studios
Idea: Alejandro Acosta

[5] https://www.youtube.com/watch?v=BswW2uVHoX0*
Créditos a:

Guion: Alejandro Acosta,
Producido en: Universidad de
Guadalajara Coordinacion General de Tecnologia de Informacion, Animacion
y Diseno: Marco Sierra,

Voz:**Dolores Hernandez - Red Radio Universidad de Guadalajara,
Grabacion: Mauricio Urbina - Red Radio

Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema
Musical: "Children" Matti Paalanen.