Alpha's Manifesto

A black and white figure's thought-hive

“Hackearon mi server”

¿Y ahora qué hago?

Uno de los posts que causaron revuelo en las preguntas de Server Fault fue My server’s been hacked EMERGENCY (Hackearon mi server, EMERGENCIA), un post cuya respuesta fue totalmente inesperada para muchos y muy útil y planeada para situaciones tan sorpresa.

Me pareció tan útil que además de sólo linkear la pregunta y su respuesta, quise traducir la elongada explicación que Robert Moir, bajo el usuario de DJ Pon3 nos ha brindado. Esta traducción se basa en su respuesta pública, sin permiso explícito.

Él nos explica cuáles son las medidas a tomar en un caso drástico como este, y muchas formas de reducir el riesgo de esto ocurriendo en el futuro. La explicación es larga pero muy clara y muy explícita sobre cada aspecto involucrado en la seguridad de un sistema.

A continuación, su respuesta:


Es difícil dar un consejo específico desde lo que has posteado aquí, pero tengo algunos consejos genéricos basados en un post que escribí mucho tiempo atrás cuando todavía podía molestarme en bloggear.

Primero que nada, no hay “arreglos rápidos” más que recuperar tu sistema de una copia de seguridad tomada anteriormente a la intrusión, y esto tiene al menos dos problemas.

  1. Es difícil identificar cuándo ocurrió la intrusión
  2. No ayuda a cerrar el “agujero” que les permitió la entrada la última vez, ni lidiar con las consecuencias de cualquier “robo de datos” que pueda haber tomado lugar también.

Esta pregunta sigue siendo hecha repetidamente por las víctimas de los hackers que entran en su servidor web. Las respuestas cambian raramente, pero la gente sigue haciendo la misma pregunta. No estoy seguro de por qué. Quizá a la gente no le gustan las respuestas que han visto buscando por ayuda, o no pueden encontrar a alguien que confíen que les de consejo. O quizá la gente lee una respuesta a esta pregunta y se concentra demasiado en el 5% de por qué su caso es especial y diferente a las respuestas que pueden encontrar online y se pierden el 95% de las preguntas y respuestas en donde su caso es suficientemente cercano a ser el mismo al que leyeron online.

Eso me trae a la primera pepita de información. Realmente aprecio que eres un copo de nieve único muy especial. Aprecio que tu sitio también lo sea, ya que es un reflejo de tí y tu negocio, o en última instancia, tu trabajo duro en nombre de un empleador. Pero para alguien desde afuera mirando hacia adentro, ya sea una persona de seguridad de computadoras mirando al problema para tratar de ayudarte o incluso para el mismo atacante, es muy probable que tu problema sea al menos 95% idéntico a cualquier otro caso que ellos hayan visto.

No te tomes el ataque de forma personal, y no tomes las recomendaciones que siguen aquí y que te da otra gente de forma personal. Si estás leyendo esto inmediatamente luego de convertirte en la víctima de un hack en un website, entonces realmente lo siento mucho, y espero que puedas encontrar algo útil aquí, pero este no es el momento para dejar que tu ego se interponga en el camino de lo que tienes que hacer.

Encontraste que tu(s) server(s) fueron hackeados. ¿Ahora qué?

No entres en pánico. Absolutamente no actúes apurado, y absolutamente no intentes actuar como si las cosas nunca hubieran ocurrido y no tuvieras que hacer nada.

Primero: comprender que el desastre ya ocurrió. Este no es el momento para la negación; es el momento para aceptar lo que pasó, para ser realista al respecto, y para tomar pasos para controlar las consecuencias del impacto.

Algunos de estos pasos van a doler, y (a menos que tu website tenga una copia de mis datos), realmente no me importa si ignoras todos o algunos de estos pasos, pero hacerlos hará las cosas mejores al final. La medicina puede saber horrible pero a veces hay que quitarle importancia a eso si queremos que la cura funcione.

Detén el problema de volverse peor de lo que ya es:

  1. La primera cosa que deberías hacer es desconectar los sistemas afectados de la internet. Cualquier otro problema que tengas, dejar el sistema conectado a la web sólo permitirá que el ataque continúe. Me refiero a esto de forma bastante literal; consigue a alguien que visite al server físicamente y desconecte los cables de red si eso es lo que hace falta, pero desconectar a la víctima de sus atracadores antes de que hagas cualquier otra cosa.
  2. Cambia todos los passwords de todas las cuentas en todas las computadoras que están en la misma red que los sistemas comprometidos. No, en serio. Todas las cuentas. Todas las computadoras. Sí, tienes razón, esto podría ser demasiado; pero por el otro lado, puede que no. De todas formas no lo sabes, ¿verdad?
  3. Verifica tus otros sistemas. Pon atención especial a aquellos que tengan servicios que están expuestos a la internet, y a aquellos que tienen datos funancieros o cualquier otro dato comercialmente sensible.
  4. Si el sistema mantiene los datos personales de alguien, haz una divulgación completa y sincera a cualquiera potencialmente afectado de una vez. Sé que esta es difícil. Sé que va a doler. Sé que muchos negocios quieren barrer este tipo de problemas debajo de la alfombra pero me temo que sólo tendrás que lidiar con él.

¿Todavía dudas si tomar este último paso? Lo entiendo, de verdad. Pero míralo de esta manera:

En algunos lugares podrías tener un requerimiento legal de informar a las autoridades y/o las víctimas de este tipo de brecha de privacidad. Por mucho que tus clientes se molesten teniéndote contándoles sobre un problema, estarían mucho más enojados si no les contaras, y sólo se enterarían por cuenta propia cuando alguien les cobre U$S 8.000 dólares en bienes usando los datos de tajeta de crédito que obtuvieron de tu sitio.

¿Recuerdas lo que dije antes? Lo malo ya ocurrió. La única pregunta ahora es qué tan bien vas a lidiar con ello.

Comprende el problema completamente:

  1. NO pongas a los sistemas afectados de vuelta online hasta que esta etapa esté completa, a menos que quieras que quieras ser la persona cuyo post fue la punta del iceberg que me hizo decidir escribir este artículo. No voy a linkear a ese post para que la gente pueda tener una risa barata, pero la tragedia real es cuando la gente falla en aprender de sus errores.
  2. Examina los sistemas ‘atacados’ para comprender cómo los ataques tuvieron éxito en comprometer tu seguridad. Haz cada esfuerzo posible por averiguar de dónde “vinieron” los ataques, para que puedas comprender los problemas que tienes y que necesitas solucionar para que tu sistema esté seguro en el futuro.
  3. Examina los sistemas ‘atacados’ nuevamente, esta vez para comprender a dónde fueron los ataques, para que entiendas qué sistemas fueron comprometidos en el ataque. Asegúrate de seguir cualquier pista que sugiera que otros sistemas comprometidos podrían convertirse en una plataforma para atacar más a tus sistemas.
  4. Asegúrate de que los “gateways” usados en cada uno y todos los ataques estén completamente comprendidos, para que puedas comenzar a cerrarlos apropiadamente (por ejemplo, si tus sistemas fueron comprometidos por un ataque de SQL injection, entonces no sólo tienes que cerrar la línea de código particular que usaron para entrar, también querrías auditar todo tu código para ver si el mismo tipo de error ocurrió en algún otro punto).
  5. Comprende que los ataques a veces tienen éxito por más de una falla. A veces, los ataques son exitosos no gracias a encontrar un gran bug en un sistema sino poniendo juntos varios problemas (muchas veces menores y triviales de por sí) para comprometer a un sistema. Por ejemplo, usar SQL injection para enviar comandos a un servidor de bases de datos, descubrir que el website/aplicación corre bajo el contexto de un usuario administrador y usar los derechos de esa cuenta como punto de partida para comprometer otras partes de un sistema. O como a los hackers les gusta decir: “otro día en la oficina aprovechándonos de los errores comunes que la gente hace”.

¿Por qué no simplemente “reparar” el exploit o rootkit que detectaste y poner los sistemas online de vuelta?

En situaciones como esta el problema es que ya no tienes control de ese sistema. Ya no es tu computadora.

La única forma de estar seguro de que tienes control del sistema es reconstruir el sistema. Si bien hay mucho valor en encontrar y arreglar el exploit usado para entrar en el sistema, no puedes estar seguro sobre qué más ha ocurrido en el sistema una vez que los intrusos tomaron control (de hecho, se sabe de hackers que reclutan sistemas a una botnet para solucionar los exploits que ellos mismos usaron, para salvaguardar “su” computadora de otros hackers, y también instalar sus rootkits).

Haz un plan de recuperación y para poner a tu sistema online de vuelta y no te desvíes de él:

Nadie quiere estar offline más de lo que tienen que estarlo. Eso está claro. Si este website es un mecanismo de generación de ganancias, entonces la presión para traerlo de vuelta online rápidamente va a ser intensa. Incluso si solo la cosa en juego es la reputación tuya / de tu compañía, esto va a generar todavía más presión para poner las cosas funcionando de vuelta rápidamente.

Sin embargo, no cedas a la tentación de volver online demasiado rápido. En lugar de eso, muévete tan rápido como puedas para comprender qué causó el problema y para solucionarlo antes de volver online, de de lo contrario muy sgeuramente caerás víctima de una intrusión nuevamente, y recuerda, “ser hackeado una vez puede ser clasificado como mala fortuna; ser hackeado de vuelta inmediatamente luego se ve como descuido” (con mis disculpas a Oscar Wilde).

  1. Estoy asumiendo que has comprendido todos los problemas que llevaron a la intrusión exitosa en primer lugar antes de que siquiera comiences esta sección. No quiero sobre-enfatizar el caso pero si no has hecho eso primero, realmente deberías hacerlo. Lo siento.
  2. Nunca juegues en modo extorsión / protección de dinero. Este es el signo de la presa fácil y no quisieras que se use esa frase nunca para describirte.
  3. No te sientas tentado a poner el mismo server / los mismos servers de vuelta online sin una completa re-instalación. Debería ser más fácil construir una nueva computadora o “enviar una bomba atómica al server desde órbita y hacer una instalación limpia” en el hardware viejo que debería ser auditar cada esquina del viejo sistema para segurarse que está limpio antes de ponerlo de vuelta online. Si no estás de acuerdo con esto entonces probablemente no sepas lo que significa realmente asegurarse que un sistema esté realmente limpio, o tus procedimientos de instalación de websites son un desastre. Es de suponer que tienes backups y pruebas de instalación de tus sitios que puedes simplemente usar para construir el sitio en vivo, y si no entonces ser hackeado no es tu problema más grave.
  4. Sé muy cuidadoso sobre usar datos como estaban “en vivo” en el sistema al momento del hackeo. No diré “nunca nunca lo hagas” porque simplemente me ignorarás, pero francamente creo que deberías considerar las consecuencias de mantener datos por ahí cuando sabes que no puedes garantizar su integridad. Idealmente, deberías traerlos de un backup hecho anteriormente al momento de la intrusión. Si no puedes o no lo vas a hacer, deberías ser muy cuidadoso con esos datos porque están contaminados. Deberías especialmente ser consciente de las consecuencias a otros si estos datos pertenencen a clientes o visitantes del sitio más que directamente a tí.
  5. Monitorea los sistemas cuidadosamente. Deberías mantener esto como un proceso continuo en el futuro (más sobre esto abajo) pero deberías tomar cuidados extra para ser vigilante durante el periodo inmediatamente siguiente a tu sitio volviendo a estar online. Los intrusos muy seguramente volverán, y puedes verlos tratando de volver a entrar y deberías poder verificar rápidamente si realmente cerraste todos los agujeros que usaron más cualquier otro que hayan hecho ellos por cuenta propia, y puedes obtener información útil que puedes pasar a tus autoridades legales.

Reducir el riesgo en el futuro

La primer cosa que debes comprender es que la seguridad es un proceso que debes aplicar por todo el ciclo de vida de diseño, instalación y mantenimiento en un sistema que tiene acceso a internet, no algo que puedes pegar como un par de capas sobre tu código luego como pintura barata. Para estar seguro apropiadamente, un servicio y una aplicación deben estar diseñados desde el comienzo con esto en mente como uno de los objetivos principales del proyecto. Me doy cuenta que es aburrido y que ya has escuchado todo esto antes, y que “no te das cuenta de la presión, hombre” de tener tu servicio web 2.0 beta (beta) en estado beta en la web, pero el hecho es que esto se sigue repitiendo porque fue verdad la primera vez que fue dicho y todavía no se ha convertido en mentira.

No puedes eliminar el riesgo. No deberías siquiera tratar de hacerlo. Lo que deberías hacer, sin embargo, es comprender cuáles riesgos de seguridad son importantes para tí, y comprender cómo manejar y reducir tanto el impacto del riesgo y la probabilidad de que el riesgo ocurra.

¿Qué pasos puedes tomar para reducir la probabilidad de que un ataque sea exitoso?

Por ejemplo:

  1. ¿Cuál fue la falla que le permitió a la gente entrar a tu sitio, un bug en un código de teceros conocidos para el cual había un patch disponible? Si es así, ¿deberías re-pensar tu aproximación a cómo patchear aplicaciones en tus servidores que ven la internet?
  2. ¿Fue la falla que le permitió a la gente entrar a tu sitio un bug desconocido en un código de teceros, para el cual no había un patch disponible? Yo ciertamente no abogo por cambiar de proveedor cuando algo como esto te muerde porque todos tienen sus problemas y te quedarás sin plataformas en un año si tomas esta aproximación. Sin embargo, si un sistema constantemente te decepciona, entonces deberías migrar a algo más robusto o como mínimo, re-arquitecturar tu sistema de forma que los componentes vulnerables estén envueltos en algodón y lo más lejos posible de ojos hostiles.
  3. ¿Fue la falla un bug en código desarrollado por tí (o un empleado trabajando para tí)? Si es así, ¿deberías re-pensar tu aproximación a cómo aprobar código para instalarlo a tu sitio en vivo? ¿Podría el bug haber sido detectado con un testeo de sistema mejorado, o con cambios en tu estándar de codificación? (Por ejemplo, si bien la tecnología no es una panacea, puedes reducir la probabilidad de un ataque de SQL Injectoin utilizando técnicas de codificación bien documentadas.)
  4. ¿Fue a falla debida a un problema en cómo el servidor o la aplicación fueron instalados? Si es así, ¿estás usando procesos automatizados para construir e instalar servidores cuando es posible? Estos son una gran ayuda en mantener una “base” consistente en todos tus servidores, minimizando la cantidad de trabajo particular que debe ser hecho en cada uno y así minimizando la oportunidad de un error de ser cometido. Lo mismo ocurre con las instalaciones – si requieres algo “especial” de ser hecho para instalar la última versión de tu aplicación web entonces intenta automatizarlo y asegúrate que siempre se haga de una forma consistente.
  5. ¿Podría la intrusión haber sido detectada más tempranamente con mejor monitoreo de tus sistemas? Por supuesto, un sistema de monitoreo de 24 horas, o un sistema “on call” para tu personal podría no ser lo más efectivo en cuanto a costos, pero hay companías que pueden monitorear tus servicios web para tí y alertarte en el evento de un problema. Podrías decidir que no puedes pagar o no lo necesitas y estás bien… pero tómalo en consideración.
  6. Utiliza herramientas como tripwire y nessus cuando sea apropiado – pero no las uses ciegamente porque yo lo digo. Tómate el tiempo de aprender cómo usar un buen par de herramientas de seguridad que sean apropiadas para tu entorno, mantiene estas herramientas actualizadas y utilízalas en períodos regulares.
  7. Considera contratar expertos en seguridad para ‘auditar’ tu sitio en períodos regulares. Nuevamente, puedes decidir que no puedes pagarlo o que no lo necesitas y eso está bien… pero tómalo en consideración.

¿Qué pasos puedes tomar para reducir las consecuencias de un ataque exitoso?

Si decides que el “riesgo” de que el piso bajo de tu casa se inunde es alto, pero no lo suficientemente alto como para mudarte por las dudas, deberías al menos mover las reliquias familiares irremplazables al piso superior. ¿Verdad?

  1. ¿Puedes reducir la cantidad de servicios expuestos directamente a la internet? ¿Puedes mantener algún tipo de brecha entre tus servicios internos y tus servicios externos a la Internet? Esto se asegura que incluso si tus sistemas externos están comprometidos, las posibilidades de usar esto como plataforma para atacar tus sistemas internos están limitadas.
  2. ¿Estás almacenando información que no necesitas almacenar? ¿Estás almacenando información “online” cuando podría estar archivada en otro lugar? Hay dos puntos en esta parte; el obvio es que la gente no se puede robar información que no tienes, y el segundo es que mientras menos tengas, menos que tienes que mantener y codificar, y entonces hay menos chances de bugs apareciendo en tu código o tu diseño de sistemas.
  3. ¿Estás usando los principios de “acceso mínimo” para tus aplicaciones web? Si los usuarios sólo necesitan leer de una base de datos, asegúrate que la cuenta que la aplicación web utiliza para hacer esto sólo tenga permiso de lectura, no le permitas escribir y ciertamente no nivel de acceso a todo el sistema.
  4. Si no estás muy experimentado a algo y no es central a tu negocio, considera tercerizarlo. En otras palabras, si mantienes un pequeño website que habla de escribir código para aplicaciones desktop y decides comenzar a vender aplicaciones desktop pequeñas desde tu sitio, considera “tercerizar” tu sistema de órdenes de tarjeta de crédito a alguien como Paypal.
  5. Si es posible de alguna forma, haz la práctica de recuperación de sistemas comprometidos parte de tu plan de recuperación de desastres. Esto es discutiblemente otro “escenario de desastre” que podrías encontrar, simplemente uno con sus propios problemas y complicaciones que son distintos de los usuales ‘la sala de servidores se incendió’ / ‘fue invadida por un servidor gigante comiendo furbies’.

…y finalmente

Probablemente no dejé cabo suelo entre las cosas que otros consideran importantes, pero los pasos de arriba deberían al menos ayudarte a comenzar a ordenar las cosas si tienes la mala suerte de convertirte una víctima de los hackers.

Sobre todo: no entres en pánico. Piensa antes de actuar. Actúa firmemente una vez que hayas tomado una decisión, y deja un comentario debajo si tienes algo que agregar a mi listado de pasos.


Soy un zorrinito hackeado (gracias Julián!)

PrivateSky

Accesible para uno, secreto para todos

PrivateSky no es ni el primer ni el último intento de un servicio de seguridad en la nube. Lo que los distingue es que, según dicen, ni ellos mismos tienen acceso a los datos que nosotros guardamos, y que ni al momento de que el gobierno les requiera los datos, ellos los darían. (O eso dice su CEO.)

Alguien en IT Security preguntó: ¿Cómo puede PrivateSky no tener acceso a nuestros datos?, y la respuesta más extensa la brinda, con lujo de detalles y tecnicismos, Brian Spector, el CEO de CertiVox. Debo admitir que no estuve al nivel de entenderla completamente, pero me queda claro cuál fue la estrategia general, y sé que en este tipo de cosas no se le puede mentir a la comunidad, al menos no en ese foro en particular.

En general, lo que ellos intentan es hacer un sistema de encriptación basado en identidad, en donde algo del lado del cliente siempre permita decriptar, algo que ellos en ningún momento reciben como clave completa, y en donde la forma de alterar esto generaría la destrucción de las demás partes de la clave. Esto significa, que sólo el usuario en acuerdo con el sistema puede cambiar la clave a otro valor, y que cualquier intento de hacerlo fuera de esa identidad básicamente perdería las claves que se pueden usar para decriptar los datos.

Por ahí preguntaron también cómo harían para evitar pedidos legales de información. Ellos se basado en un vacío legal que les permitiría entregar los datos encriptados, y defenderse diciendo que no tienen forma de decriptarlos, dejando la información segura de forma total. (Esto es, claro, excepto que la entidad gubernamental tenga los métodos apropiados para quebrar la encriptación, cosa por la que se apuesta que no ocurra.)

A pesar de lo transparente que se busca ser en esto, Brian Spector ha sido bastante cerrado en cuanto a la información de seguridad que dejó ver del sitio web.

Aún así, parece una aproximación muy novedosa.

Soy un zorrinito privado.

Manifiesto: Cerrando el 2011

Se me ocurrió hacer esta especie de recuento en la que resumo el año personal, a modo de balance. Por supuesto, muchas cosas van a quedar afuera de este resumen, tanto por privacidad personal como por respeto a otros. Si creés que deberías estar acá y no estuviste, sacá un número porque van a ser muchos, y no por desmerecerlos.

En cuanto a mi vida, como varios saben, la comencé en Estados Unidos este año (menos una semana de Enero pero… quién cuenta los días?). El estilo de vida es distinto, el estilo de la gente es distinto, las ciudades son distintas, las comodidades son distintas, la forma de vivir y aproximarse a las cosas es distintas. Muchos podrán abogar por beneficios y otros podrán resaltar desventajas (y de hecho, todo eso ya fue hecho), pero la verdad es que me siento más cómodo. El tipo de vida nuevo me ha traído una comodidad especial, no en lo material sino en la forma de vivir. No creo encontrar las palabras exactas – al menos no ahora – para lo que quiero decir, pero espero que se entienda. Mi vida personal ha mejorado mucho y hemos disfrutado mucho de ella en detalles y en cosas importantes.

Me hice más adepto a las películas, creo que este año cuento unas dieciséis reseñas en mi blog pero sé que ví varias más. No parece realmente mucho pero tengo años con cuenta nula. Volví a la lectura (técnica todavía, tendré que en poco volver a la ficción – ¿podría ese ser un propósito para el año que viene?). Comencé a tener en cuenta técnicas de mejor productividad personal, y mi objetivo era que mis 8 horas de trabajo me alcanzaran para mi trabajo y para auto-mejora en el trabajo. Estoy muy muy cerquita de lograrlo y parece que pronto me van a dar una ayuda enorme, pero vamos a hablar de trabajo luego. Pronto volveré a la música (yay?), y de a poco quizá vuelva a la escritura (yay?). Este año sólo he publicado las reseñas de películas, algunos juegos y cinco sueños.

¡Volví a jugar! Hacía años que no jugaba, este año disfruté de Portal 2 (como no podía esperarse menos), varios juegos experimentales ([1], [2], [3]). Esperando poder probar luego Deus Ex (Human Revolution) jugué a Deus Ex (el primerito) y Deus Ex: Invisible War. Jugué al Halo (al primero), posiblemente luego continúe con la saga. No hice review de ellos porque realmente no sé qué comentar que sea nuevo. Amplié mi ámbito de juego a las consolas. Tras haber probado Soul Calibur y algunos otros de XBox, me quedé atrapado con Zelda Skyward Sword (ay, qué adicción).

Ahora sobre trabajo… mi cambio ha generado un gran cambio en lo que mis responsabilidades eran, y si bien me tomó un tiempo entenderlo, creo que he logrado cierto buen desarrollo. No es un mérito propiamente mío, me ha tocado un equipo de trabajo impecable y que realmente es responsable y de confiar. (Si alguno de ustedes lee esto, felicítense de mi parte.) Me desempeñé un poco más en management que en desarrollo en sí, pero no me atrevería a llamarme manager, me faltan años para tener la experiencia necesaria. Me he basado en la comunicación y hemos resuelto problemas bastante graves con entendernos todos un poco más. Y esta es la anécdota más interesante que tengo: hemos hecho un éxito de un proyecto que no debió serlo. Creanmé, ese proyecto estaba en su apocalípsis y las bombas seguían llegando. Lo logramos like a boss.

De a poco me abrí un poco más y comencé ciertos proyectos de investigación, algo que siempre me había llamado. Comenzamos a darle más seriedad y estoy llevando a cabo varios proyectos para hacerlo real. Esto es algo que debe seguir pasando, pero me emociona mucho.

Como para darle más interés, me he codeado con mucha gente por acá que me ha dado una nueva visión de lo que es mi trabajo (eventos, colegas, conocidos). Realmente se trata de innovación, realmente se trata de empujar la industria para adelante. No voy a creerme que yo voy a ser quién haga revoluciones industriales, pero ya me hicieron creer que mi aporte puede ser una semilla de eso. ¡Me llevaron a ser opinólogo! Resulta que ahora respondo preguntas de productividad, programación, bases de datos, experiencia de usuario, y algunos más por ahí. Me gusta más mantenerme al tanto, me gusta más saber lo último. Me satisface poder dar rienda suelta a mi curiosidad.

¡He empezado a cuidar mi apariencia! ¿Quién lo creería? He encontrado un balance entre sentirme cómodo y verme bien (aunque dudo eso último), hasta he recibido halagos de diversa gente por mi forma de vestir y verme. Debo reconocer que he recibido mucha ayuda con esto, no es mérito mío tampoco, pero creo que ha sido un gran avance.

¡He vuelto a clases! La experiencia no fue tan placentera como la esperaba. Tomé cursos online en Stanford, y pensé que tres cursos serían soportables. Lo fueron, pero requirieron mucho esfuerzo de mi parte y lo que menos quisiera es frustarme con ellos. Quiero disfrutarlos. El año que viene haré un par más, vamos a ver. También he vuelto a la tesis de mi vieja carrera (debo agradecer a A. M. por esa oportunidad, me ayudó mucho y fue quién me ofreció la oportunidad y el contexto que yo necesitaba para embarcarme en eso). Quién sabe, quizá en un par de años sí tenga mi título de ingeniero después de todo.

¡Agrandamos la familia! Ahora en casa Lino y Sable ambos haciendo de las suyas. Cada tanto se merecen algún tweet porque no me dejan de sorprender. No sería lo mismo sin ellos.

Por último (y sólo por ser lo más importante), tengo que dar un reconocimiento extra a Tassy, realmente ha hecho mucho por mí, desde detalles a cosas increíblemente importantes. Innumerables. Increíbles. Este año ha sido precioso compartirlo y toda esta aventura no sería lo mismo si no hubieras sido parte de él. ¡Por muchos más y más aventuras!

El balance es positivo. ¡Salud! ¡Por un nuevo año bueno para muchos! ¡Happy new 2012!

Link del día: Privacidad en las redes sociales

Las redes sociales siempre fueron una preocupación en cuanto a la privacidad de los datos y la forma en la que fácilmente otras personas nos pueden engañar. De hecho, mientras mejor cumplan su trabajo, más peligrosas van a ser en este sentido.

Es por eso que la gente de DragonJar hizo un buen post, casi-recopilatorio, sobre este tema. Se titula: Cómo conservar la privacidad en las redes sociales. En él nos explican una serie de conceptos básicos a modo de caricatura (orientado a chicos que ya son familiares con estas tecnologías) y de ahí una serie de posts que ellos mismos poseen sobre la seguridad en internet, y guías específicas para proteger los datos en cada una de las redes sociales que hoy son más populares (Facebook, Flickr, Hi5, Last.FM, LinkedIn, MySpace, Orkut, Tuenti, Twitter, Windows Live Spaces, Xing y Youtube).

Soy un zorrinito privado.

Link del día: Anonimato en internet gratuito

Estaba leyendo algunas cosas cuando caí en el artículo de HackTimes sobre Anonimato en internet gratis durante un año, y tras leer de qué se trataba, realmente me pareció muy interesante. Lo explicaré en pocas palabras.

Básicamente, podemos contratar un VPS (Virtual Private Server) de Amazon y si nos mantenemos dentro de los límites de transferencia (que parecerían ser unos 15 GB/mes) este primer año lo tendríamos gratuito. Podemos configurar este VPS como un servidor proxy que utilizaremos a través de una conexión  SSH (encriptada), lo cual significaría que toda nuestra navegación en internet sería detectada desde los servicios de Amazon (recordemos, Cloud Computing). Eso significa también que nuestro ISP no tendría acceso a la información que estamos enviando/recibiendo.

Pero mejor aún, y esto aplica para los que, como yo, últimamente han tenido problemas de conexión debido a problemas de proxies internos del ISP: estos problemas desaparecerían, porque todos estos pedidos ya no serían procesados por nuestro ISP, sino por Amazon.

Quizá yo haga el intento, no parece demasiado difícil. ¿Ustedes se animan?

Soy un zorrinito encriptado.

Link del día: Evercookie

Hace un tiempo me crucé con un artículo que hablaba sobre HTML5 y la privacidad en internet. Si bien me pareció que era un poco exagerado, parece que muchas fuentes, incluyendo algunas bastante confiables como el NYTimes.

Pero en realidad no estamos hablando de un problema de HTML5, sino de la seguridad que los navegadores implementen para dar soporte a este nuevo estándar.

Todo en el fondo se trata de la utilización de más técnicas para el almacenamiento de información local en una computadora, que de una forma u otra puede ser utilizada (y de hecho, lo es hoy en día) para identificar gustos y tendencias de navegación en ciertas partes de internet, de forma que, por ejemplo, Google pueda anunciar cosas de nuestro interés, incluso aunque estemos viendo una noticia sobre algo que no está relacionado.

Una aplicación proof of concept de cómo se puede almacenar información casi-persistente (cuando se supone que no debería de serla) es EverCookie. Evercookie es una suerte de cookie que a través de distintos mecanismos de almacenamiento se permite persistir de forma prácticamente persistente, incluso luego de la limpieza de caché, cookies y otro tipo de limpiezas estándares que muchos de nosotros haríamos pensando que ya debería de haber desaparecido.

¿Ustedes creen que esto realmente tenga implicaciones en la seguridad? ¿Creen que HTML5 se convertirá más en un problema que en una solución?

Soy un zorrinito persistente.

Link of the Day: Liberate your data!

I know that Google has products for everything, and they’re still creating new things, making more and more enemies in different business. Besides that, we have the user’s data concern: what about privacy? What about having other options? What happens to our Google data?

Well, Google has made a step forward into that, creating DataLiberation.org, or, known by it’s full name, The Data Liberation Front (politics, anyone?). The mission for this project is that all users should be able to control the data they store in any of Google’s products. And to approach that mission, you may check for instructions on how to import or export data from any of Google products, and how to make it compatible with different options.

For example, you may as well want to download your Google Docs to use Microsoft Word. Or maybe you want your AdWords data in HTML. Or maybe you want to download back your videos from Youtube.

There are plenty of options, and ideally, each of Google’s products should have a way to back up your data and use it in another service or any way you like. It is supposed that it’s your data. (However, licenses may state else.)

I’m a compatible little skunk.

Link of the Day: Security papers, tools and exploits

It’s been a while now I’m following the RSS feed of a site called Exploit-DB. In fact, this site was created by Offensive Security, the same guys that are the creators of Backtrack, the widely-known Linux distribution for penetration testing and security auditing.

What I like most of the site are the papers. Most of them are truly enlightening and even inspiring. The last ones I’ve read are Inyección SQL en MSSQL – HackTimes, [Spanish] PFD – Partial Function Disclosure and The (in)security of Omegle – What Omegle users should know. All of the papers are easy to understand and well documented, even with pictures and examples of what they talk about.

Not so far from here, I found the site called HackTimes, with lots of articles to read about security measures, hacking techniques, ideas and more. I’ve just read an article about Fuzzy Hashing and it seems totally interesting.

I’m a secure little skunk.

Link del día: One password to rule them all…

LastPass es un sistema centralizador de passwords que se integra con una gran variedad de navegadores para que autocomplete nuestros datos en los sitios que visitemos. De esta forma, podemos tener una buena cantidad de passwords de alta complejidad sin necesidad de tener que recordarlos de memoria, pudiendo sólo utilizar un password que usaremos en LastPass.

Por supuesto, sabemos que de esta forma, nuestro punto débil puede ser el password de LastPass, pero por supuesto existen medidas de seguridad adicionales para asegurar que no cualquiera acceda como nosotros a la información que este sistema almacena, donde podemos centralizar todo.

Entre las características que posee, existen:

  • la de ingresar a un sitio, loggeándonos con un solo click
  • la de sincronizar información entre varias computadoras y/o navegadores
  • de compartir logins/passwords con amigos (ya no hace falta eso de enviar passwords de forma plana y sin protección)
  • importación desde otros programas o sistemas
  • exportar los datos
  • hacer backups, restores
  • generar passwords complejos
  • usar la versión online
  • usar desde un USB
  • uso de teclados virtuales (para evitar keyloggers)
  • passwords para usar una sola vez (temporales)
  • crear distintas identidades con distintos permisos
  • usar iPhones, Blackberry, Windows Mobile, Android, Symbian (versión paga)
  • usar un USB como claves “multi-factor” (versión paga)
  • usar YubiKeys (versión paga)
  • soporte (versión paga)
  • sin publicidades (versión paga)

Incluso hay muchos features más ya incluidos que podemos ver desde la sección de FAQs, pero si es que alguno se anima a probarlo y poner su información ahí, no dudo que va a tener una buena experiencia.

Soy un zorrinito centralizado.