18 de noviembre de 2005

El túnel del SSH

Esta última semana fue un poco cansada...gracias a cierta aerolínea he tenido que dormir en cuatro capitales de Centroamérica en cinco días..pero bueno, como siempre he creído, siempre aparecen oportunidades de aprender cosas nuevas.

Por tanto viaje, he estado teniendo que usar accesos públicos de Internet a través de redes inalámbricas (Wi-Fi hotspots) en hoteles, aeropuertos, etc. Para facilidad del acceso de la gente que se conecta a esto, los access points están configurados sin ningún tipo de seguridad (aunque sea WEP). Esto es bastante conveniente para uno, pero también es bastante fácil para cualquier script kiddie que ande por allí, que ponga su equipo a escuchar y copiar el tráfico de todos los usuarios...y para hacerlo más interesante, ronda por la Red una herramienta para reconocer passwords dentro del tráfico normal de red (esto lo oí en el podcast de Security Now, por cierto).

Sobre esto, hace poco salió en digg una "nota" que ponía una página que capturaba todos los passwords transmitidos en cleartext durante una conferencia: pusieron un script que hacía sniffing del tráfico inalámbrico y capturaba claves. Aparte de las implicaciones legales, etc. de esto, pues me puse a investigar cómo proteger el tráfico, sin llegar a una solución más complicada, tipo VPN.

Parte de lo que encontré, fue usar SSH tunnels. El concepto es interesante: a través de un cliente de SSH cualquiera, se puede redirigir el tráfico de un puerto local, hacia otro puerto en un servidor remoto, dentro de la conexión encriptada que ya mantiene el cliente SSH.

Con esto, se hace tráfico muy seguro, ya que el protocolo SSH (en la versión 2, verdad?) usa criptografía fuerte.

Lo que hice entonces fue configurar en PuTTY que hiciera el túnel (Connection->SSH->Tunnels), agregando un puerto local (en mi caso, localhost:3128 que corresponde al HTTP proxy Squid usualmente), hacia el puerto 3128 de un servidor remoto.ejemplo.com que corre el proxy Squid, y apuntando el HTTP proxy de mi navegador hacia localhost:3128.

Para evitar que todo el mundo use ese proxy, se configura para que sólamente acepte tráfico de localhost (en este caso, es el localhost del servidor remoto, no de mi PC). Entonces, el PuTTY se encarga de reenviar el tráfico recibido en localhost:3128, y redirigirlo al remoto.ejemplo.com:3128, donde el sshd de remoto lo interpreta como tráfico local, y lo traslada directamente al Squid local que está escuchando en el puerto localhost:3128.

De esa manera, mi tráfico inalámbrico está totalmente encriptado hasta llegar al proxy server! Con eso, ya podría entrar a una LAN segura si el proxy permitiera tráfico hacia ella. La autenticación queda a cargo de SSH, usando passwords.

Hay muchas aplicaciones para estos túneles, y hay bastante información adicional en Gugle, buscando la frase "ssh tunnel". Esta técnica está altamente recomendada para asegurar tráfico en el Internet. Como leí hace poco en un libro: la seguridad se diseñaba anteriormente para evitar que los malos entraran; ahora los malos están adentro, usando los sistemas de seguridad...ya no sólo es protección, necesitamos autenticación, autorización y administración (el famoso AAA en inglés dice "Accounting" para la última A, pero...dejémoslo en administración ;-).

10 de noviembre de 2005

Ponencia para la Jornada Científica de Ingenierías, Licenciaturas y Ciencias Básicas de Unitec

El 01 de diciembre habrá en UNITEC un evento de Investigación Científica en diversas áreas. Este evento está abierto a todas las personas

En lo personal, envié una ponencia dentro del área de Computación Aplicada, que he titulado "Análisis de ataques a un sistema de correo electrónico por medio de mensajes que incluyen contenido alterado de forma maliciosa". Esta investigación será específicamente sobre lo que conocemos mejor como phishing, y el abstract es el siguiente:

"La investigación se realiza con el propósito de evaluar la vulnerabilidad de los sistemas de comunicación por correo electrónico de Internet, para determinar la facilidad de explotación de un ataque por medio de mensajes que incluyen contenido creado con fines maliciosos, con el objeto de diseñar y preparar medidas de mitigación de riesgos y educación de los usuarios.

Se describe el análisis realizado sobre la capacidad de crear mensajes de correo electrónico de Internet, que incluyen código HTML diseñado maliciosamente para hacer creer al receptor que proviene de una entidad o persona de confianza, y hacerle creer que está interactuando con ella, sin que sea detectado por el sistema de correo electrónico o paquetería de filtrado y seguridad, como antivirus y antispam.

Se considera como un ataque de ingeniería social (“social engineering”) hacia los usuarios de los sistemas de correo electrónico, que aprovecha de debilidades en los paquetes de correo electrónico (“Mail User Agents – MUAs”) y sistemas de filtrado de correo y virus disponibles comercialmente. El término utilizado comúnmente para este tipo de ataques se denomina phishing.

La prueba de concepto se realiza sobre software disponible comercialmente y de uso generalizado entre las personas que se comunican a través de correo electrónico de Internet."

Estoy haciendo un paper, y habrá presentación en el día de la Jornada. A ver que tal sale.


8 de noviembre de 2005

¿Existe un uso para esos MP3 players de 128MB?

Creo que ya lo encontré...¡oír Podcasts en el carro! La nueva onda de masificación de los medios de comunicación por podcasting es una excelente aplicación para esos pequeños MP3 players, ya que por lo general los shows son grabados a un bitrate bajo

Estoy usando smartfeed para PocketPC, y tengo los siguientes podcasts cargados:

- Diggnation
- the WEEK in TECH (tWiT)
- Security Now
- Scifi Dig

Estos se encuentran en el directorio de podcasts de iPodderX.