BlogPandora: el blog de pablot

Febrero, 20 2009

Detector de tráfico no deseado para OpenWRT (para WRT54g) Parte II

Archivado en: Geek, General, Linux, Tech, hardware, seguridad, wifi — Etiquetas:, , , — pablot @ 10:58 pm

¿Se acuerdan del detector de tráfico no deseado para OpenWRT?. Bueno, el tema es que como dije en mi post anterior, al actualizar a OpenWRT Kamikaze, la utilidad gpio dejó de funcionar, por lo que el feedback visual que proporcionaba este hack si alguien accedía a nuestra red, desapareció.

La solución es más simple de lo que parece, ya que aparentemente a partir de la versión RC6 de White Russian (creo) los leds están presentes en /proc/diag/led como se ve a continuación:

root@OpenWrt:/proc/diag/led# ls -l
-r--------    1 root     root            0 Jan  1 01:29 dmz
-r--------    1 root     root            0 Jan  1 01:29 power
-r--------    1 root     root            0 Jan  1 01:29 ses_orange
-r--------    1 root     root            0 Jan  1 01:29 ses_white
-r--------    1 root     root            0 Jan  1 01:29 wlan
root@
OpenWrt:/proc/diag/led#

Esto permite que si queremos por ejemplo encender el led naranja detrás del logo de Cisco, sólo tengamos que hacer:

root@OpenWrt:/proc/diag/led# echo "1" > /proc/diag/led/ses_orange

Sin necesidad de recurrir a la herramienta gpio que era necesaria antes. De esta misma manera se puede controlar cualquiera de los otros leds, con solo mandar un 1 para encenderlos y un 0 para apagarlos.

Todo esto nos sirve para simplificar el script que usábamos en la versión anterior (White Russian) y que sólo tengamos que hacer lo siguiente:

Agregar el archivo /usr/bin/wl-traf.sh (y darle permiso de ejecución) con el siguiente contenido:

#!/bin/sh
#
I=wl0
while sleep 1; do
if [ "`wl assoclist`" != "" ]; then
XFER=`ifconfig $I|grep bytes`

if [ "$XFER" != "$PXFER" ]; then
# Si hay transferencia prendo el led ambar
echo "1" > /proc/diag/led/ses_orange
echo "0" > /proc/diag/led/ses_white
PXFER=$XFER
else
# Si no hay transferencia prendo el led blanco
echo "0" > /proc/diag/led/ses_orange
echo "1" > /proc/diag/led/ses_white
fi
else
echo "0" > /proc/diag/led/ses_orange
echo "0" > /proc/diag/led/ses_white
fi
done

Y por último agregar la siguiente línea al archivo /etc/init.d/custom-user-startup

/usr/bin/wl-traf.sh &

No se olviden del “&”, de esta manera será ejecutado cada vez que se inicie el router. Y por supuesto tampoco olviden que como en el caso anterior, va a ser necesario instalar el paquerte wl para que funcione.

Upgrade de OpenWRT White Russian 0.9 a Kamikaze 8.09

Archivado en: Geek, General, Linux, Tech, hardware, seguridad — Etiquetas:, , , , — pablot @ 2:06 pm

wrt54g-smallFinalmente me decidí y actualicé el firmware de mi router Linksys wrt54g. Pasé del vetusto OpenWRT White Russian 0.9 al flamante OpenWRT Kamikaze 8.09.

Como novedad, al menos para mi, debo decir que ya no es necesaria la interfase Webif para administrarlo desde un browser, ya que ahora trae una interfase llamada LuCI integrada al firmware, aunque por supuesto también se le puede instalar Webif.

Cabe aclarar que si bien OpenWRT ya utiliza versiones 2.6 del kernel de Linux, para el caso de routers basados en Broadcom (como los Linksys), como se necesitan drivers propietarios aún se sigue con el kernel 2.4.

Otro cambio importante es que se abandonó el sistema de guardar las variables en la NVRAM y ahora se guardan en archivos de configuraciòn en /etc/config. Esto es principalmente debido a que como OpenWRT se ha extendido a plataformas que no poseen NVRAM, se ha debido tomar esta decisión para poder soportarlas. Este cambio hace que al pasar de White Russian a Kamikaze haya que volver a reconfigurar el router desde cero, ya que se pierden las configuraciones que tengamos.

Respecto al upgrade en si, no representa ningún problema ya que se hace desde la opción de upgrade del firmware desde Webif y funciona perfectamente, pero al reiniciarse el router queda con la configuración inicial y se debe volver a reconfigurar para poder utilizarlo.

La reconfiguración en si no fue gran problema y todo salió funcionando al igual que funcionaba anteriormente con la excepción de mi hack para detectar tráfico no deseado, ya que como esto se hacía por medio de los pins GPIO de la motherboard y jugar con esto estaba expresamente desaconsejado, pues bien, ha dejado de funcionar.

Excepto este problema menor, debo decir que todo funciona muy bien y aún debo dedicarme un poco más a explorarlo y ver que nuevas facilidades brinda.

Para Instalar X-Wrt o Webif solo hay que agregar al archivo `/etc/opkg.conf` la siguiente línea (cuidado que esto es en el caso de un router basado en Broadcom y con kernel 2.4, fíjense cual les corresponde si es otro modelo):

src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/8.09/brcm-2.4/packages

De esta manera el archivo `/etc/opkg.conf` queda así:

src/gz snapshots http://downloads.openwrt.org/kamikaze/8.09/brcm-2.4/packages
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /jffs
src X-Wrt http://downloads.x-wrt.org/xwrt/kamikaze/8.09/brcm-2.4/packages

Luego hay que desinstalar LuCI de la siguiente manera:

root@OpenWRT:~# opkg remove -recursive luci-*

Y por último para instalar X-Wrt hay que tipear:

root@OpenWRT:~# opkg update

root@OpenWRT:~# opkg install webif

¡Y listo!

Enero, 7 2009

Twitteando por la calle con Wifi

Archivado en: Geek, N95, Tech, Telefonía, seguridad — Etiquetas:, — pablot @ 9:56 pm

Siguiendo con la temática del post anterior, es increíble la cantidad de redes wifi que hay por todos lados.

Es posible ir twitteando por la calle, ya que con solo hacer 5 o 6 intentos seguramente encontraremos alguna red abierta que nos permitirá enviar nuestro mensaje a twitter sin siquiera tener que detenernos.

Algunas son redes públicas en serio, de bares, o lo que sea y otras son solo de desafortunadas personas que no han sabido o podido cerrar sus redes para que nadie las utilice.

Enero, 4 2009

Wifi: La telaraña invisible.

Archivado en: Geek, N95, Nokia, Tech, Telefonía, seguridad, wifi — Etiquetas:, , , — pablot @ 6:40 pm

Es increible todo lo que existe aunque uno no lo vea. Tal es el caso wifide la cantidad de redes wifi que hay por ahí.

Ayer di una vuelta haciendo Wardriving (o más precisamente Warwalking porque iba caminando) con GPSd y Barbelo corriendo en mi N95.

Encontré 30 redes wifi (la mayoría cerradas, lo cual es bueno) todas ellas en un recorrido de 3 o 4 cuadras.

Para quien le interese, solo tienen que tomar el log que deja Barbelo y convertirlo con kisgearth a un archivo kml que pueda ser cargado por Google Earth para ver todos los puntos de acceso y su localización en Google Earth.

Octubre, 8 2008

el podcast de pablot – Episodio 28 – ¿Se rompió Internet?

Archivado en: Tech, actualidad, episodios, podcast, seguridad — Etiquetas:, — pablot @ 1:00 am

Luego de renegar bastante para encontrar tiempo, les hago entrega de un nuevo episodio del podcast, esta vez vamos a ver que es lo que esta pasando con Internet que se están encontrando serios problemas de seguridad cada vez más seguido ¡y más serios!. ¿Se rompió Internet?

podcasticonDescargar: el podcast de pablot – Episodio 28 – ¿Se rompió Internet?

Links adicionales: Más datos en Hispasec

Septiembre, 3 2008

el podcast de pablot – Episodio 24 – Wifi ¿abierta o cerrada?

Archivado en: Tech, episodios, podcast, seguridad — Etiquetas:, — pablot @ 1:00 am

En este episodio vamos a volver sobre el tema de las redes wifi. La idea no es volver a tratar el tema, sino tratar de analizar si es conveniente tomar medidas de seguridad para cerrar nuestra red o por el contrario dejarla abierta para quien quiera usarla,

podcasticonDescargar: el podcast de pablot – Episodio 24 – Wifi ¿abierta o cerrada?

Links adicionales: Bruce Schneier – My Open Wireless Network

Agosto, 27 2008

el podcast de pablot – Episodio 23 – El problema del DNS (parte 2)

Archivado en: Tech, actualidad, episodios, podcast, seguridad — Etiquetas:, , , , , — pablot @ 1:00 am

Vamos a retomar el tema del último podcast y ahondaremos un poco más en el problema, pero a su vez vamos a tratar de explicar brevemente que es lo que esta vulnerabilidad permite hacer a un atacante. Pero esta vez lo haremos en forma mucho más simple y sencilla, sin entrar en los aspectos técnicos del problema, para permitir que quienes no sean técnicos puedan comprenderlo sin quedar a mitad de camino.

podcasticonDescargar: el podcast de pablot – Episodio 23 – El problema del DNS (parte 2)

Links adicionales: DNS, DNS Cache poisoning, Dan Kaminsky, OpenDNS, Blog de Dan Kaminsky donde se puede chequear el DNS, Otro sitio para chequear el DNS, Excelente explicación sobre la vulnerabilidad del DNS

Agosto, 14 2008

Autobombo: TrueCrypt en Tuxinfo

Archivado en: Tech, seguridad — Etiquetas:, , — pablot @ 3:39 pm

Si no me hago un poco de autobombo yo mismo quien me lo va a hacer, ¿no?. Es por eso que los invito a leer mi nuevo artículo en TuxInfo sobre TrueCrypt llamado Derecho a la Privacidad – TrueCrypt.

Si no conocen lo que es TrueCrypt, esta es una excelente oportunidad para conocerlo, pero en pocas palabras les cuento que permite encriptar dispositivos de almacenamiento (particiones o dispositivos completos) brindando excelentes opciones a la hora de mantener nuestros datos a salvo. Y lo mejor de todo es que es open source.

Para más detalles sobre TrueCrypt les dejo los links a un post sobre TrueCrypt en mi blog y al podcast que trata sobre el mismo tema.

Espero que me comenten que opinan del tema, y que lean también el resto de los artículos que estan muy buenos.

Aclaración: Para quienes no conozcan el término autobombo, hacer autobombo es algo así como hacer publicidad de uno mismo. ;-)

Agosto, 13 2008

el podcast de pablot – Episodio 22 – HOUSTON: Tenemos un problema con el DNS

Archivado en: Tech, actualidad, episodios, podcast, seguridad — Etiquetas:, , , , , — pablot @ 1:00 am

A estas alturas nadie que se mueva en un ambiente técnico esta ajeno al gran problema que se ha presentado con el servicio de DNS, por lo que en este episodio del podcast, vamos a tratar de explicar de que se trata este problema

Es sin duda uno de los episodios más técnicos que hemos tenido hasta ahora, por lo que también es probable que sea el que más errores tenga. Más allá de los errores técnicos que pueda haber cometido en la explicación (hay una suerte de fe de erratas sobre el final), la idea no es que sea una clase magistral y detallada del problema, sino una explicación los más entendible posible sobre el tema.

Vamos a ver que es el servicio de DNS, que protocolo IP usa y porque, y en que consiste el ataque del que todos hablan.

No debemos perder de vista el real problema, ya que más allá del problema técnico en si con el DNS, lo más serio es que una vez suplantado o envenenado un servidor de DNS, todos los servicios de Internet que lo utilicen (web, email, ftp, etc.), pueden ser redireccionados a servidores falsos.

podcasticonDescargar: el podcast de pablot – Episodio 22 – HOUSTON: Tenemos un problema con el DNS

Links adicionales: DNS, DNS Cache poisoning, Dan Kaminsky, OpenDNS, Blog de Dan Kaminsky donde se puede chequear el DNS, Otro sitio para chequear el DNS, Excelente explicación sobre la vulnerabilidad del DNS

Servidores de DNS de OpenDNS:

  • 208.67.222.222

  • 208.67.220.220

Agosto, 10 2008

DNS en terapia intensiva

Archivado en: Tech, actualidad, podcast, seguridad — Etiquetas:, , , , , — pablot @ 8:25 pm

A estas alturas no va a ser novedad para nadie que este más o menos en tema, el serio problema que se ha detectado en el servicio de DNS.

Haciendo un breve resumen, el tema es que existe una vulnerabilidad que ya se conocía desde hace mucho tiempo, pero que desde hace unos meses un investigador y experto en seguridad, Dan Kaminsky, detectó que el problema es más serio de lo que parecía.

En pocas palabras, el problema esta dado porque se pueden hacer ataques de envenenamiento de cache de DNS (DNS cache poisoning) de forma mucho más rápida (por lo tanto más efectiva) de lo que se pensaba. Es por esto que Dan junto a varias empresas ha estado trabajando en un parche para minimizar el problema, ya que no se puede resolver directamente porque esta derivado de un problema de diseño del sistema de DNS y no de un simple bug que pueda ser corregido.

El descubrimiento de Dan ha demostrado que se puede tomar el control de un servidor de DNS en un tiempo que va de unos 30 segundos a 2 minutos. Para decirlo en términos simples el parche que ha desarrollado Dan junto a varias empresas, consiste en evitar que el ataque pueda ser realizado rápidamente para evitar que sea tan efectivo; evitando que el ataque pueda ser perpetrado en solo dos minutos. Pero el problema es serio y de ninguna manera el parche logra eliminar el riesgo.

Otro investigador, Evgeniy Polyakov, ha demostrado que esta lentificación que lograba el parche no lo ha lentificado tanto como creían, ya que fue posible tomar el control de un servidor de DNS en unas 10 horas (pero contando con cierta ventaja, como una red de Gb y una máquina con un troyano).

Ahora bien, debido a esto se han comenzado a ver titulares que dicen que el parche no sirve. Esto no es cierto, el parche si sirve, ya que aunque el ataque tarda 10 horas en ser efectivo, es mucho mejor eso a tan solo dos minutos.

El trabajo de Evgenly es muy bueno, pero de ninguna manera invalida la efectividad del parche desarrollado por Dan y su equipo, tan solo demuestra que no tiene toda la efectividad que se pensaba, pero no me parece que se pueda afirmar que el parche no resuelve el problema, ya que eso lo dijo el mismo Dan.

Si quieren saber más sobre el problema en cuestión, esperen a la próxima edición del podcast, ya que nos vamos a meter de lleno en el problema para tratar de explicarlo de la forma más sencilla posible. Espero que se entienda, ya que seguramente va ser el episodio más técnico que hayamos tenido hasta el momento.

Entradas más antiguas »

Blog de WordPress.com.