Aunque digan que la medicina es una profesión vocacional, las ingenierías no se quedan atrás. No creo que nadie aguante 5 cursos (es decir, 7-8 años) de caminos, teleco o aeronáutica sólo porque "luego tienes muchas salidas". Fontanero también tiene muchas salidas, y con todo mi respeto a los fontaneros, es bastante más fácil. Y aunque la informática sea quizá el patito feo de las ingenierías, no se queda atrás. De hecho, a veces en la carrera te putean incluso un poco más, para recuperar el terreno perdido, debe de ser. El problema es que existe una cultura popular en la que si sabes escribir una carta en Word, sabes informática, si sabes navegar por Internet eres un experto y si ya sabes instalar Pequesuave Ventanas XP es que ya te falta nada para ser Guillermo Puertas.
Pero en mi caso es por puro frikismo y pasión por los chips, los bytes y todoas esas cosas. Me parecía fascinante como simplemente escribiendo una serie de comandos se podía hacer que un montón de chatarra "cobrara vida" e hiciera exactamente lo que se le decía (pantallazos azules aparte). Por aquel entonces ni siquiera tenía ordenador y me dedicaba a ojear viejos libros sobre Basic que dios sabe de dónde salieron. Más tarde cuando ya compramos el primer PC, un PIII 450Mhz el problema eran los recursos. No conocía nada de linux y en Pequesuave Ventanas para programar necesitabas "suites" de Borland o cosas similares, inalcanzables. Tras un primer intento (ridíiiiiculo) con Visual Basic (5, si no recuerdo mal) conseguí el DIV2, con el que hice mi primer matamarcianos, siguiendo un tutorial de una revista. En aquellos tiempos oscuros sin Internet la información era un tesoro y un chaval de 14 años no podía permitirse el lujo de comprar un libro de programación. En la biblioteca del pueblo sólo había un viejo libro de Pascal, que me daba la sensación de ser un lenguaje viejo e inútil. Para entonces ya había empezado a oir cosas sobre Linux y que estaba hecho en un lenguaje llamado C, al igual que muchos videojuegos, así que ese era el lenguaje a aprender. Tras mucho esfuerzo conseguí unos programas ejemplo tipo "hola mundo" en C, ¡bajados de Internet! en un ordenador del instituto y poco más tarde todo un señor libro de programación en C. Poco a poco empecé a "dominar" el tema, aunque algunas cosas me seguían pareciendo cosa de magia, y casi sigue siendo así hasta ahora (casi, ¿eh?), como pueden ser la programación Win32, DirectX, OpenGL, programación multimedia... Cuando llegué al instituto la asignatura de informática era (de nuevo, casi) mejor que el recreo. La parte de Pequesuave Oficina era para lerdos y la parte hiper-dificil de programación en C consistía en hacer un hola mundo y un programa que haga ordenaciones números enteros. Nada de quicksort: empezando por un ¿voy bien así? y alcanzando la máxima complejidad con un modo de burbuja de orden estrictamente n cuadrado y su digi-evolución, el método de burbuja mejorado, donde el bucle interno de inicia más allá de los elementos ya ordenados, que es el que viene en la wikipedia.
Y finalmente teminé le bachillerato y conseguí sustituir literatura e historia por física y programación. Tras un principio traumático con Haskell y su paradigma "no-uso-variables-pero-tengo-funciones-auxiliares-para-
guardar-información-que-necesitare-mas-tarde-y-que-
en-realidad-es-una-implemetación-tremendamente-
ineficiente-y-liosa-de-variables" pasamos a ADA, que no era tan distinto de C, aunque le añadía la funcionalidad de tipado: "no puedes sumar cantidad y 5, porque cantidad es del tipo_dinero y 5 es del tipo_integer". Pero eso era pasable, bastaba con tener un poco de cuidado y todo era coser y cantar. Hasta que en tercero llegó la programación orientada a objetos. De repente, desapareció cualquier rastro de otro tipo de programación y los profesores daban las clases rezando "padre nuestro que estás en un patrón factoría" en lugar de padre nuestro y en vez de "nos creó a su imagen y semejanza" era "heredamos de él atributos y métodos por ser una clase hija".
Y yo me preguntaba... ¿de verdad que todo lo que he aprendido hasta ahora no me vale para nada? ¿Será que los objetos es lo único que vale y que se usa y todo lo demás son tecnologías obsoletas? Yo desde luego me apaño perfectamente haciendo todas las prácticas en C sin haber aprendido a fondo ni C++ ni Java en lo que llevo de carrera. Y el núcleo de linux o GTK están hechos en C, pero quizá en C++ serían más bonitos, más fáciles y te harían café y tostadas por las mañanas... Por suerte en barrapunto me he encontrado con algunos comentarios sobre una entrevista al creador de C++ y con una simpática respuesta de Linus Torvalds que me han aclarado que la programación orientada a objetos es simplemente una forma más que tiene sus puntos fuertes y sus aplicaciones, no la panacea como nos quieren hacer ver.
Y por cierto, como dicen tambien en barrapunto, habría que ver la reacción de Linus si alguien le propone migrar el kernel de C a C++. Matarle quizá no le mate, pero seguro que contrata a esta gente para que vaya por las noches bajo su ventana ;)
Thursday, December 27, 2007
Tuesday, December 25, 2007
Blogger con OpenID
Antes de nada... ¡Feliz Navidad! Por ser unas fechas tan especiales, hoy no habrá tochopost.
Par hoy solo una pequeña nota, que ya había leído antes, pero me ha parecido interesante recordar: blogger ya permite identificarse con OpenID. Parece que este es el empujoncito final para hacer que OpenID alcance una "masa crítica" y se convierta por fin en un estándar. Para mas información, consultar el link ;)
¡Cuidado con los turrones, que luego vienen los propósitos de año nuevo y el gimnasio está muy caro!
Par hoy solo una pequeña nota, que ya había leído antes, pero me ha parecido interesante recordar: blogger ya permite identificarse con OpenID. Parece que este es el empujoncito final para hacer que OpenID alcance una "masa crítica" y se convierta por fin en un estándar. Para mas información, consultar el link ;)
¡Cuidado con los turrones, que luego vienen los propósitos de año nuevo y el gimnasio está muy caro!
Wednesday, December 19, 2007
Todo sobre mi Fonera
Tras una larga batalla parece ser que a la fonera no le gusta ninguno de los firmware nuevos, asi que le he flasheado uno un poco mas antiguo, el OpenWrt Kamikaze 7.07. Pero hasta aqui, he recorrido un largo camino, por una vez y sin que sirva de precedente, contaré la historia desde el principio de los tiempos.
Para quien no conozca la fonera, basicamente en un pequeño router inalambrico con un firmware basado en linux que durante un tiempo se pudo conseguir gratis con unas invitaciones y que ahora la gente se dedica a hackear.
Lo vende la empresa fon con el objetivo de que compartas tu adsl a cambio de usar el adsl de los demás usuarios. Y si alguien que no es usuario de fon quiere usar tu adsl, pues le paga un dinero a fon, y fon le deja usar tu adsl. Como aquel refrán de "cada uno en su casa y Dios en la de todos", fon pretende que cada uno comparta su adsl y ellos sacan dinero alquilándolo como si fuera suyo.
Pues bien, hace unos meses, creo que por navidades, fon decicio regalar un numero de foneras a los usuarios que llevaran mas tiempo registrados y sin fonera. Ahí conseguí la primera. Más tarde, sacó una promocion donde invitando a un amigo a fon, le regalaban una fonera. Ahí conseguí otras 3, y porque me daba palo seguir pidiendo. Y como soy bueno, dejé una de ellas enchufada para compartir mi adsl, que tampoco me cuesta nada.
Una vez con la(s) fonera(s) en mis manos, tocó empezar a trastear. Lo primero fue habilitar el ssh. Dado que tenía una versión antiguilla del firmware, lo pude hacer gracias a un fallo en una página de configuración. Clásico ejemplo de formulario mal validado, el programador se esperaba un valor y el usuario proporciona un comando del sistema operativo. El código no valida la entrada del usuario, y al intentar leer el valor, ejecuta el comando. Para más info sobre la técnica, que mejor sitio que la wikipedia. El formulario vulnerable en cuestión es uno de la página connection.sh, que sirve para (¡sorpresa!) configurar las conexiones de la fonera. El método paso por paso está muy bien explicadito en esta página. Merece la pena leer los demás artículos de la web, que aunque se dejó de actualizar hace mucho, son bastante instructivos.
Una vez tenemos acceso por ssh podemos hacer dos cosas: flashear la fonera con otro "sistema operativo" o bien dejarla como está.
Si la dejamos como está, lo primero que hay que hacer es habilitar el ssh al arranque y asegurarse que la fonera no se autoactualice. Por un lado, porque podríamos perder el ssh e incluso el "bug" para habilitarlo de nuevo y por otro lado, para que la gente de fon no pueda trastear en nuestra red.
El asunto del ssh es fácil, basta con hacer un: "ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear".
La auto-acualización tampoco es difícil. Por defecto, la fonera cada X tiempo (1 hora creo recordar) se baja un script de fon.com y lo ejecuta, con privilegios de root, normalmente para efectuar los cambios que hagamos a traves de la pagina web de fon a nuestra fonera o actualizar el firmware. Digamos que nos fiamos de fon y confiamos que no nos quieren espiar ni robar (...), pero si alguna vez el servidor de fon se ve comprometido, el atacante tendria total libertad de hacerse con el control de cientos de miles de redes domesticas en todo el mundo, simplemente cambiando el script inofensivo que manda fon por el suyo propio, seguro que mucho mas interesante. Para evitar que esto ocurra, hay que modificar el script que se ejecuta periódicamente (/bin/thinclient) y comentar la línea que ejecuta el script bajado: ". /tmp/.thinclient.sh". Esta es la configuración que tengo en la fonera que sigue conectada como fonera propiamente dicha.
La otra opción, mucho más interesante, es flashear la fonera con otro firmware. Para ello hace falta poder escribir en la memoria persistente del aparato, pero no se puede hacer directamente. Cuando la fonera se enciende, no arranca directamente el kernel de linux, sino un gestor de arranque llamado RedBoot. Normalmente este gestor se para unos segundos antes de arrancar, esperando que se pulse una tecla para interrumpir el proceso. Por supuesto, la fonera no tiene teclado así que o bien se hace por una consola serie, o bien por telnet. La consola serie es accesible por hardware si se hace un circuito adaptador con un chip MAX232 y la consola telnet (mucho más cómoda) es accesible ya que el RedBoot arranca un server telnet mientras espera la pulsación. Pero claro, la gente de fon configuró el RedBoot para que al arrancar se pusiera la IP 0.0.0.0 y de este modo el server no está disponible. Y configuraron el kernel para evitar que se cambie la configuración del RedBoot. De este modo, para flashear la fonera primero tenemos que cambiar el kernel por otro equivalente pero que deje cambiar la configuración del RedBoot:
Una vez conectados, nos sale el aviso de pulsar ctrl+c para interrumpir el arranque. El cliente telnet estándar no parece ser capaz de hacer esto, así que han surgido por Internet varias alternativas. Una es enviarle el símbolo con netcat, otra usar un script en perl, pero quizá la más cómoda sea usar Putty, bien desde Pequesuave Ventanas o desde linux con Wine. Basta con conectarse y cerrar la ventana, una vez interrumpido el arranque nos podemos conectar con cualquier cliente telnet. A partir de este momento ya somos libres de meter cualquier distribución que nos apetezca, aunque solo hay dos que parecen estar mas o menos maduras, OpenWrt y DD-WRT.
Para instalar la distribución tenemos que bajarnos las imagenes del kernel y el sistema de archivos y ponerlos en un server TFTP en la subred. Desde el RedBoot ejecutamos:
Pero todo tiene su parte mala, y es que esto no siempre funciona:
Para quien no conozca la fonera, basicamente en un pequeño router inalambrico con un firmware basado en linux que durante un tiempo se pudo conseguir gratis con unas invitaciones y que ahora la gente se dedica a hackear.
Lo vende la empresa fon con el objetivo de que compartas tu adsl a cambio de usar el adsl de los demás usuarios. Y si alguien que no es usuario de fon quiere usar tu adsl, pues le paga un dinero a fon, y fon le deja usar tu adsl. Como aquel refrán de "cada uno en su casa y Dios en la de todos", fon pretende que cada uno comparta su adsl y ellos sacan dinero alquilándolo como si fuera suyo.
Pues bien, hace unos meses, creo que por navidades, fon decicio regalar un numero de foneras a los usuarios que llevaran mas tiempo registrados y sin fonera. Ahí conseguí la primera. Más tarde, sacó una promocion donde invitando a un amigo a fon, le regalaban una fonera. Ahí conseguí otras 3, y porque me daba palo seguir pidiendo. Y como soy bueno, dejé una de ellas enchufada para compartir mi adsl, que tampoco me cuesta nada.
Una vez con la(s) fonera(s) en mis manos, tocó empezar a trastear. Lo primero fue habilitar el ssh. Dado que tenía una versión antiguilla del firmware, lo pude hacer gracias a un fallo en una página de configuración. Clásico ejemplo de formulario mal validado, el programador se esperaba un valor y el usuario proporciona un comando del sistema operativo. El código no valida la entrada del usuario, y al intentar leer el valor, ejecuta el comando. Para más info sobre la técnica, que mejor sitio que la wikipedia. El formulario vulnerable en cuestión es uno de la página connection.sh, que sirve para (¡sorpresa!) configurar las conexiones de la fonera. El método paso por paso está muy bien explicadito en esta página. Merece la pena leer los demás artículos de la web, que aunque se dejó de actualizar hace mucho, son bastante instructivos.
Una vez tenemos acceso por ssh podemos hacer dos cosas: flashear la fonera con otro "sistema operativo" o bien dejarla como está.
Si la dejamos como está, lo primero que hay que hacer es habilitar el ssh al arranque y asegurarse que la fonera no se autoactualice. Por un lado, porque podríamos perder el ssh e incluso el "bug" para habilitarlo de nuevo y por otro lado, para que la gente de fon no pueda trastear en nuestra red.
El asunto del ssh es fácil, basta con hacer un: "ln -s /etc/init.d/dropbear /etc/init.d/S50dropbear".
La auto-acualización tampoco es difícil. Por defecto, la fonera cada X tiempo (1 hora creo recordar) se baja un script de fon.com y lo ejecuta, con privilegios de root, normalmente para efectuar los cambios que hagamos a traves de la pagina web de fon a nuestra fonera o actualizar el firmware. Digamos que nos fiamos de fon y confiamos que no nos quieren espiar ni robar (...), pero si alguna vez el servidor de fon se ve comprometido, el atacante tendria total libertad de hacerse con el control de cientos de miles de redes domesticas en todo el mundo, simplemente cambiando el script inofensivo que manda fon por el suyo propio, seguro que mucho mas interesante. Para evitar que esto ocurra, hay que modificar el script que se ejecuta periódicamente (/bin/thinclient) y comentar la línea que ejecuta el script bajado: ". /tmp/.thinclient.sh". Esta es la configuración que tengo en la fonera que sigue conectada como fonera propiamente dicha.
La otra opción, mucho más interesante, es flashear la fonera con otro firmware. Para ello hace falta poder escribir en la memoria persistente del aparato, pero no se puede hacer directamente. Cuando la fonera se enciende, no arranca directamente el kernel de linux, sino un gestor de arranque llamado RedBoot. Normalmente este gestor se para unos segundos antes de arrancar, esperando que se pulse una tecla para interrumpir el proceso. Por supuesto, la fonera no tiene teclado así que o bien se hace por una consola serie, o bien por telnet. La consola serie es accesible por hardware si se hace un circuito adaptador con un chip MAX232 y la consola telnet (mucho más cómoda) es accesible ya que el RedBoot arranca un server telnet mientras espera la pulsación. Pero claro, la gente de fon configuró el RedBoot para que al arrancar se pusiera la IP 0.0.0.0 y de este modo el server no está disponible. Y configuraron el kernel para evitar que se cambie la configuración del RedBoot. De este modo, para flashear la fonera primero tenemos que cambiar el kernel por otro equivalente pero que deje cambiar la configuración del RedBoot:
Al reiniciar, ya podemos cambiar la configuración de RedBoot, con los siguientes comandos:# Ir a la ram
cd /tmp
# Bajarse el kernel modificado (cualquiera de los dos sitios vale)
wget http://fonera.info/camicia/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
wget http://ipkg.k1k2.de/hack/openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma
# Copiar el kernel de la ram a la flash, mtd es el equivalente a dd para dispositivos flash
mtd -e vmlinux.bin.l7 write openwrt-ar531x-2.4-vmlinux-CAMICIA.lzma vmlinux.bin.l7
# Reiniciar con el kernel modificiado
reboot
La fonera se reinicia y durante los primeros 10 - 15 segundos nos podemos conectar por telnet al RedBoot. Si tras el ultimo flasheo la fonera no termina de arrancar, no pasa nada, es posible que ocurra, en este caso se va a quedar parada en el RedBoot sin arrancar linux. Al arrancar el RedBoot se asigna la IP 192.168.1.254/24 sin puerta de enlace, por lo que habrá que hacer telnet (al puerto 9000) desde la misma subred o a través de una máquina que haga NAT en esa subred.# Ir a la ram
cd /tmp
# Bajarse el archivo de configuracion binario de RedBoot (ambos sitios son validos)
wget http://fonera.info/camicia/out.hex
wget http://ipkg.k1k2.de/hack/out.hex
# Volcar el contenido del archivo a la flash, (aqui podemos romper algo y que no arranque)
mtd -e "RedBoot config" write out.hex "RedBoot config"
# Reiniciar con el server telnet de RedBoot activo al arranque
reboot
Una vez conectados, nos sale el aviso de pulsar ctrl+c para interrumpir el arranque. El cliente telnet estándar no parece ser capaz de hacer esto, así que han surgido por Internet varias alternativas. Una es enviarle el símbolo con netcat, otra usar un script en perl, pero quizá la más cómoda sea usar Putty, bien desde Pequesuave Ventanas o desde linux con Wine. Basta con conectarse y cerrar la ventana, una vez interrumpido el arranque nos podemos conectar con cualquier cliente telnet. A partir de este momento ya somos libres de meter cualquier distribución que nos apetezca, aunque solo hay dos que parecen estar mas o menos maduras, OpenWrt y DD-WRT.
Para instalar la distribución tenemos que bajarnos las imagenes del kernel y el sistema de archivos y ponerlos en un server TFTP en la subred. Desde el RedBoot ejecutamos:
Y con esto ya tendríamos la fonera como un router cualquiera ejecutando un firmware "neutro". Ahora ya sólo quedaría elegir un firmware, pero eso ya depende de los gustos de cada uno, en mi caso tiro más por consola, así que OpenWrt. Para tener las versiones mas nuevas se puede mirar en varios sitios:# Asignamos IP a la fonera y le decimos el server por defecto
ip_addr -h IP_SERVER_TFTP -l 192.168.1.254/24
# Inicializamos (formateamos) la flash
fis init
# Cargamos el kernel en ram a partir de la dirección 0x80041000
load -r -b 0x80041000 NOMBRE_ARCHIVO_KERNEL
# Volcamos el kernel a la flash indicando los puntos de entrada y de ubicacion en memoria
fis create -r 0x80041000 -e 0x80041000 vmlinux.bin.l7
# Calculamos el espacio libre, el comando nos dira principio y fin del bloque.
# Hacemos (fin - principio) y da el tamaño, que suele ser 0x006F0000.
fis free
# Cargamos el rootfs en ram a partir de la dirección 0x80041000
load -r -b 0x80041000 NOMBRE_ARCHIVO_ROOTFS
# Volcamos el contenido del archivo a la flash. Tarda mucho sin responder, hasta 10 minutos
fis create -l 0x006F0000 rootfs
# Reiniciamos con el nuevo firmware
reset
- Sincronizar con el SVN y compilarselo uno todo (si se tiene mucha paciencia y tiempo libre)
- Revisiones r9xxx del foro de fonera.info, ahora mismo la r9703.
- Compilaciones de k1k2.de, en el momento de escribir este post la última es la r96xx del día 3 de diciembre, y su puede bajar de http://ipkg.k1k2.de/fonera_2.6.23.1/
Pero todo tiene su parte mala, y es que esto no siempre funciona:
- Las versiones mas nuevas no soportan WPA en modo AP, hay un fallo en el modulo de madwifi y no se puede asignar una clave a la interfaz. Pasa lo mismo tanto para la versión de k1k2.de como de fonera.info,
- La ultima version estable, la 7.09, no lo es. Con la wifi sin proteger perece ser que no tiene problemas, pero con hostapd activo (1 wifi con WPA+TKIP y sin clientes) no dura más de 36 horas sin colgarse. Desaparecen todas las wifis y la fonera deja de responder a los pings por ethernet. Probado con las versiones 0.57 y 0.58 de hostapd.
Sunday, December 16, 2007
Troubeshooting wireless
Con la llegada de WPA a mi red las cosas se han complicado bastante. Lo ultimo ha sido reunir las 4 foneras. Lo cierto es que una de ellas esta fuera de combate: contraseña cambiada y olvidada, ssh habilitado, ejecución de actualizaciones de fon quitada y redboot capado. O accedo al redboot por puerto serie, o la fonera pasa a mejor vida. He intentado cualquier combinacion de arranques + pulsaciones de reset, pero no ha funcionado nada, asi q toca soldar... un día de estos me pondré a ello. Mientras tanto, sigo con las otras 3 foneras, una de ellas conectada habitualmente en un sitio remoto, pero temporalmente en casa para su configuración. Y con las nuevas configuraciones, vienen los experimentos y se acaban rompiendo las cosas. Si bien hay un dicho "si funciona, no lo toques" es habitual entre alguna gente (entre los que me incluyo) cambiarlo por "si funciona, abrelo y arreglalo".
El problema empezo con la fonera que sirve de AP WPA para las videoconsolas. Parecía que era un problema de estabilidad: con el hostapd arrancado, no duraba mas de 1 dia sin colgarse. Pues bien, tras reflashearla por si acaso, decido cambiar la instalacion, ya que no habia ninguna otra version de hostapd mas nueva que la 0.57.1 en el repositorio de openwrt. En la pagina ipkg.k1k2.de parece que tienen el hostapd 0.58.1, aparte del kernel 2.6.23 para chipset Atheros. Tras consultar a "uname -a" veo q el que tenía era 2.6.19, asi que decido cambiar. Resultado: sin WPA. Ya no se cuelga, pero principalmente es porque no funciona. Todo se configura perfecto pero a la hora conectarse, el AP rechaza a los clientes. Tras una primera parte de la asociación correcta:
Aparece esto otro:
Y ya que estaba tocando cosas, me puse a tocar más. El portatil-server-AP tenía el cifrado WEP puesto a restricted (shared key). Aunque en un escenario ideal, con WEP siendo seguro, esto sería una mala idea; hoy en día, nadie en su sano juicio atacaría por ahí.
En pocas palabras: en modo abierto el AP deja asociarse a cuaquiera. En modo restringido, el AP manda unos datos que el ciente tiene que encriptar con la calve WEP y devolverlos al AP para comprobar si tiene la clave. Dado que todo viaja por el aire, un atacante podría capturar el mensaje en claro y cifrado y por fuerza bruta sacar la calve WEP, sin más datos. Esto es un trabajo de meses diría yo, y hoy en día teniendo ataques de minutos, es una pérdida de tiempo siquiera pensarlo.
Lo bueno del modo restricted es que es un obstáculo muy grande para romper una wifi con WEP. Por supuesto, no digo que no se pueda, de hecho con el propio aircrack-ng es posible sin más que leer la página del manual. El quid de la cuestión radica en que los miles de tutoriales online siempre explican el proceso de sacar claves WEP de redes abiertas, esto es, que cualquiera se puede asociar y "autenticar". Aunque en el manual de aircrack explique como atacar redes en restricted, no hay "tutoriales para HOYGANs" que lo expliquen, dado lo escaso de su aplicación. Basta que en el paso 14.c.II del mega-hiper-tutorial-para-dummies algo salga mal, para que un atacante de estos se vaya a una esquina a llorar y deje tu red en paz.
Lo que pasa detrás del escenario es que en una red abierta, la seguridad reside en que los clientes con la clave correcta mandarán tramas cifradas y el AP las entenderá y procesará. Los clientes que no tengan la clave, se podrán asociar y enviar tramas al AP, pero este las intentará descifrar con su clave WEP y al no poder, las dará por corruptas y las tirará. Esto se explota haciendo un ataque "fakeauth" para asociarse al AP y un "replay" para reenviar tramas ARP que circulen por la red y ya han sido encriptadas por el autor original. El atancante no las entenderá, pero el AP sí, y mandará las contestaciones generando así el tráfico necesario. Con una red restricted, el paso previo de "fakeauth" fallará al no poder asociarse el atacante al AP, y todas las tramas, incluídas las repeticiones de las ARP capturadas, serán rechazadas. Si no habeis entendido esto ultimo, la version corta es: el modo restricted te protege de noobs con manuales "bajaos de la güeb", pero no de gente que sabe lo que hace (sigue siendo WEP al fin y al cabo).
Bien, dado que anteriormente mi red estaba protegida sólo contra atacantes-dummies, usaba el modo restricted. Pero con la nueva configuración con VPN, no era necesario el modo restricted y decidi quitarlo, ya que los clientes por defecto intentas asociarse con modo open y para poner el restricted hay que rebuscar entre las opciones o hacerlo via consola. Pues cambie la linea wireless_key en el archivo interfaces de debian de "clave_WEP" a "clave_WEP" key open (no permita definirlo en dos lineas wireless_key, se queja de valores duplicados). Resultado: la ipw3945 del portatil no se conecta. Ya me da problemas con el dhcp y ahora esto. Puedo usar cualquier wifi abierta, WEP open/restricted o WPA a mi alcance excepto esa en concreto. Y al reves, cualquier otra tarjeta que he probado se asociaba perfectamente con el AP en modo open, excepto la intel.
Tras mucho tiempo investigando, me di cuenta de que el AP se anunciaba como "sin cifrado" y es lo que salia al escanear. Ninguna otra tarjeta/dispositivocon wifi se veía afectado por esto, pero la intel3945 sí. Los demás simplemetne se asociaban como si no tuviera clave y luego al poner la calve y se podía usar el AP.
El problema radicaba, curiosamente en la configuracion del prism54 del portatil-AP. Al poner la clave de la wifi y luego el modo open, la prism54 anunciaba el parámetro encryption como off, aunque para que los clientes se comunicaran con el AP sí que hacia falta la clave. Bastaba volver a poner la clave o cambiar el modo a restricted, para que se anunciara bien el cifrado. La solución fue tan simple como cambiar el orden y dejar la linea tal que: wireless_key open key "clave_WEP". Y todo volvio a funcionar perfecto como con el modo restricted. Y que rompan la clave si quieren, para lo que les va a servir... :D
En fin, basta de rollos por hoy. En caso de duda consulte con su farmaceutico o deje un cometario. Espero que hayais aprendido alguna cosa nueva, como hago yo al pelearme con las wifis y... ¡hasta la proxima!
*****
update 5:00am:
Ya he descubierto el fallo que no permite autenticarse por WPA en la fonera. Tal como sospechaba, es culpa del kernel puesto que bajar el hostapd de 0.58 a 0.57 no ha resuelto el problema. Esto es la salida de una asociación WPA (en concreto, de la psp), pero por parte del server:
Pues nada, ¡a flashear de nuevo!
El problema empezo con la fonera que sirve de AP WPA para las videoconsolas. Parecía que era un problema de estabilidad: con el hostapd arrancado, no duraba mas de 1 dia sin colgarse. Pues bien, tras reflashearla por si acaso, decido cambiar la instalacion, ya que no habia ninguna otra version de hostapd mas nueva que la 0.57.1 en el repositorio de openwrt. En la pagina ipkg.k1k2.de parece que tienen el hostapd 0.58.1, aparte del kernel 2.6.23 para chipset Atheros. Tras consultar a "uname -a" veo q el que tenía era 2.6.19, asi que decido cambiar. Resultado: sin WPA. Ya no se cuelga, pero principalmente es porque no funciona. Todo se configura perfecto pero a la hora conectarse, el AP rechaza a los clientes. Tras una primera parte de la asociación correcta:
State: SCANNING -> ASSOCIATINGEn lugar de aparecer el handshake:
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_associate
Setting authentication timeout: 10 sec 0 usec
EAPOL: External notification - EAP success=0
EAPOL: External notification - EAP fail=0
EAPOL: External notification - portControl=Auto
RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])
Wireless event: cmd=0x8b06 len=8
RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])
Wireless event: cmd=0x8b04 len=12
RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])
Wireless event: cmd=0x8b1a len=15
RX EAPOL from 00:18:84:1f:d1:4a
Setting authentication timeout: 10 sec 0 usec
IEEE 802.1X RX: version=2 type=3 length=95
EAPOL-Key type=254
key_info 0x89 (ver=1 keyidx=0 rsvd=0 Pairwise Ack)
key_length=32 key_data_length=0
replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 01
key_nonce - hexdump(len=32): XX XX XX 6a dd cf cf 87 a3 0f 2b e6 de cd 8e XX ad 18 ff b8 aa 21 6a ca 76 7e f2 d2 03 XX XX XX
key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00
key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00
key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
State: ASSOCIATING -> 4WAY_HANDSHAKE
WPA: RX message 1 of 4-Way Handshake from...
Aparece esto otro:
Wireless event: cmd=0x8b1a len=16Ojala tuviera tiempo para ver qué es lo que falla, pero en estas fechas prenavideñas llenas de entregas de practicas, no hay tiempo para mucho. Lo mas fácil, sencillo y rápido será probar otro firmaware donde el hostapd funcione, pero no mate a la fonera.
RTM_NEWLINK: operstate=0 ifi_flags=0x3 ([UP])
Wireless event: cmd=0x8b15 len=20
Wireless event: new AP: 00:00:00:00:00:00
Added BSSID 06:18:84:XX:XX:XX into blacklist
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
State: ASSOCIATING -> DISCONNECTED
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
EAPOL: External notification - EAP success=0
Authentication with 00:00:00:00:00:00 timed out.
Added BSSID 00:00:00:00:00:00 into blacklist
State: DISCONNECTED -> DISCONNECTED
wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
No keys have been configured - skip key clearing
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
Setting scan request: 0 sec 0 usec
State: DISCONNECTED -> SCANNING
Y ya que estaba tocando cosas, me puse a tocar más. El portatil-server-AP tenía el cifrado WEP puesto a restricted (shared key). Aunque en un escenario ideal, con WEP siendo seguro, esto sería una mala idea; hoy en día, nadie en su sano juicio atacaría por ahí.
En pocas palabras: en modo abierto el AP deja asociarse a cuaquiera. En modo restringido, el AP manda unos datos que el ciente tiene que encriptar con la calve WEP y devolverlos al AP para comprobar si tiene la clave. Dado que todo viaja por el aire, un atacante podría capturar el mensaje en claro y cifrado y por fuerza bruta sacar la calve WEP, sin más datos. Esto es un trabajo de meses diría yo, y hoy en día teniendo ataques de minutos, es una pérdida de tiempo siquiera pensarlo.
Lo bueno del modo restricted es que es un obstáculo muy grande para romper una wifi con WEP. Por supuesto, no digo que no se pueda, de hecho con el propio aircrack-ng es posible sin más que leer la página del manual. El quid de la cuestión radica en que los miles de tutoriales online siempre explican el proceso de sacar claves WEP de redes abiertas, esto es, que cualquiera se puede asociar y "autenticar". Aunque en el manual de aircrack explique como atacar redes en restricted, no hay "tutoriales para HOYGANs" que lo expliquen, dado lo escaso de su aplicación. Basta que en el paso 14.c.II del mega-hiper-tutorial-para-dummies algo salga mal, para que un atacante de estos se vaya a una esquina a llorar y deje tu red en paz.
Lo que pasa detrás del escenario es que en una red abierta, la seguridad reside en que los clientes con la clave correcta mandarán tramas cifradas y el AP las entenderá y procesará. Los clientes que no tengan la clave, se podrán asociar y enviar tramas al AP, pero este las intentará descifrar con su clave WEP y al no poder, las dará por corruptas y las tirará. Esto se explota haciendo un ataque "fakeauth" para asociarse al AP y un "replay" para reenviar tramas ARP que circulen por la red y ya han sido encriptadas por el autor original. El atancante no las entenderá, pero el AP sí, y mandará las contestaciones generando así el tráfico necesario. Con una red restricted, el paso previo de "fakeauth" fallará al no poder asociarse el atacante al AP, y todas las tramas, incluídas las repeticiones de las ARP capturadas, serán rechazadas. Si no habeis entendido esto ultimo, la version corta es: el modo restricted te protege de noobs con manuales "bajaos de la güeb", pero no de gente que sabe lo que hace (sigue siendo WEP al fin y al cabo).
Bien, dado que anteriormente mi red estaba protegida sólo contra atacantes-dummies, usaba el modo restricted. Pero con la nueva configuración con VPN, no era necesario el modo restricted y decidi quitarlo, ya que los clientes por defecto intentas asociarse con modo open y para poner el restricted hay que rebuscar entre las opciones o hacerlo via consola. Pues cambie la linea wireless_key en el archivo interfaces de debian de "clave_WEP" a "clave_WEP" key open (no permita definirlo en dos lineas wireless_key, se queja de valores duplicados). Resultado: la ipw3945 del portatil no se conecta. Ya me da problemas con el dhcp y ahora esto. Puedo usar cualquier wifi abierta, WEP open/restricted o WPA a mi alcance excepto esa en concreto. Y al reves, cualquier otra tarjeta que he probado se asociaba perfectamente con el AP en modo open, excepto la intel.
Tras mucho tiempo investigando, me di cuenta de que el AP se anunciaba como "sin cifrado" y es lo que salia al escanear. Ninguna otra tarjeta/dispositivocon wifi se veía afectado por esto, pero la intel3945 sí. Los demás simplemetne se asociaban como si no tuviera clave y luego al poner la calve y se podía usar el AP.
El problema radicaba, curiosamente en la configuracion del prism54 del portatil-AP. Al poner la clave de la wifi y luego el modo open, la prism54 anunciaba el parámetro encryption como off, aunque para que los clientes se comunicaran con el AP sí que hacia falta la clave. Bastaba volver a poner la clave o cambiar el modo a restricted, para que se anunciara bien el cifrado. La solución fue tan simple como cambiar el orden y dejar la linea tal que: wireless_key open key "clave_WEP". Y todo volvio a funcionar perfecto como con el modo restricted. Y que rompan la clave si quieren, para lo que les va a servir... :D
En fin, basta de rollos por hoy. En caso de duda consulte con su farmaceutico o deje un cometario. Espero que hayais aprendido alguna cosa nueva, como hago yo al pelearme con las wifis y... ¡hasta la proxima!
*****
update 5:00am:
Ya he descubierto el fallo que no permite autenticarse por WPA en la fonera. Tal como sospechaba, es culpa del kernel puesto que bajar el hostapd de 0.58 a 0.57 no ha resuelto el problema. Esto es la salida de una asociación WPA (en concreto, de la psp), pero por parte del server:
root@hostnameXXX:/lib/modules/2.6.23.1# hostapd -dd /var/run/hostapd-ath1.conf
Configuration file: /var/run/hostapd-ath1.conf
madwifi_set_privacy: enabled=0
BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
SIOCGIWRANGE: WE(compiled)=22 WE(source)=18 enc_capa=0xf
ath1: IEEE 802.11 Fetching hardware channel/rate support not supported.
Flushing old station entries
Deauthenticate all stations
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=0
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=1
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=2
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=3
Using interface ath1 with hwaddr 06:18:84:XX:XX:XX and ssid 'XXXXXXX'
SSID - hexdump_ascii(len=8):
XX XX XX XX XX XX XX XX XXXXXX
PSK (ASCII passphrase) - hexdump_ascii(len=21):
XXXXXXXXX... ...XXX XXX... ...XXX
PSK (from passphrase) - hexdump(len=32): XX XX XX ... ... XX XX XX
madwifi_set_ieee8021x: enabled=1
madwifi_configure_wpa: group key cipher=1
madwifi_configure_wpa: pairwise key ciphers=0x2
madwifi_configure_wpa: key management algorithms=0x2
madwifi_configure_wpa: rsn capabilities=0x0
madwifi_configure_wpa: enable WPA=0x1
madwifi_set_privacy: enabled=0
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GMK - hexdump(len=32): [REMOVED]
GTK - hexdump(len=32): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
madwifi_set_key: alg=TKIP addr=00:00:00:00:00:00 key_idx=1
madwifi_set_privacy: enabled=1
madwifi_set_iface_flags: dev_up=1
ath1: Setup of interface done.
Wireless event: cmd=0x8b1a len=17
Wireless event: cmd=0x8c03 len=20
ath1: STA 00:1c:26:XX:XX:XX IEEE 802.11: associated
New STA
ath1: STA 00:1c:26:XX:XX:XX WPA: event 1 notification
madwifi_del_key: addr=00:1c:26:XX:XX:XX key_idx=0
ath1: STA 00:1c:26:XX:XX:XX WPA: start authentication
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state INITIALIZE
madwifi_del_key: addr=00:1c:26:XX:XX:XX key_idx=0
madwifi_set_sta_authorized: addr=00:1c:26:XX:XX:XX authorized=0
ath1: STA 00:1c:26:XX:XX:XX IEEE 802.1X: unauthorizing port
WPA: 00:1c:26:XX:XX:XX WPA_PTK_GROUP entering state IDLE
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state AUTHENTICATION
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state AUTHENTICATION2
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state INITPSK
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state PTKSTART
ath1: STA 00:1c:26:XX:XX:XX WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=0 ack=1 install=0 pairwise=8 kde_len=0 keyidx=0 encr=0)
TX EAPOL - hexdump(len=113): XX XX XX ... ... XX XX XX
IEEE 802.1X: 32 bytes from 00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=1 length=0
ignoring 28 extra octets after IEEE 802.1X packet
IEEE 802.1X: 123 bytes from 00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=3 length=119
ath1: STA 00:1c:26:XX:XX:XX WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state PTKCALCNEGOTIATING
PMK - hexdump(len=32): [REMOVED]
PTK - hexdump(len=64): [REMOVED]
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state PTKCALCNEGOTIATING2
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state PTKINITNEGOTIATING
madwifi_get_seqnum: addr=00:00:00:00:00:00 idx=1
ath1: STA 00:1c:26:XX:XX:XX WPA: sending 3/4 msg of 4-Way Handshake
WPA: Send EAPOL(secure=0 mic=1 ack=1 install=1 pairwise=8 kde_len=24 keyidx=0 encr=0)
TX EAPOL - hexdump(len=137): XX XX XX ... ... XX XX XX
IEEE 802.1X: 99 bytes from 00:1c:26:XX:XX:XX
IEEE 802.1X: version=1 type=3 length=95
ath1: STA 00:1c:26:XX:XX:XX WPA: received EAPOL-Key frame (4/4 Pairwise)
WPA: 00:1c:26:XX:XX:XX WPA_PTK entering state PTKINITDONE
madwifi_set_key: alg=TKIP 00:1c:26:XX:XX:XX key_idx=0
ioctl[IEEE80211_IOCTL_SETKEY]: Invalid argument
madwifi_set_key: Failed to set key (addr 00:1c:26:0e:5f:f6 key_idx 0 alg 'TKIP' key_len 32 txkey 1)
hostapd_wpa_auth_disconnect: WPA authenticator requests disconnect: STA 00:1c:26:XX:XX:XX reason 2
madwifi_sta_deauth: 00:1c:26:XX:XX:XX reason_code=2
ath1: STA 00:1c:26:XX:XX:XX IEEE 802.11: deauthenticated due to local deauth request
Wireless event: cmd=0x8c02 len=99
Custom wireless event: 'STA-TRAFFIC-STAT
00:1c:26:XX:XX:XX
rx_packets=3
rx_bytes=296
tx_packets=2
tx_bytes=238
'
Wireless event: cmd=0x8c04 len=20
ath1: STA 00:1c:26:XX:XX:XX IEEE 802.11: disassociated
Pues nada, ¡a flashear de nuevo!
Saturday, December 8, 2007
Troubleshooting: disparando...
Bueno, aqui estoy otra vez. Ha pasado un mes desde la ultima entrada, pero entre viajes de estudios y entregas de practicas no ha habido mucho tiempo para bloguear. El viaje ha sido bastante interesante y educativo, una introducción a algoritmos de compresion de datos. Un tema para el cual vale la pena escribir una entrada un diade estos.
Pero a lo que iba, que mejor para volver al escribir que unos pocos problemillas de esos que tanto molestan.
Para empezar, el open office. Un programa fascintante, sobre todo cuando se instala en gentoo y no se usa el paquete binario: Nunca imagine que algo podría tardar tantas horas en compilarse en un Core Duo con 2GB de RAM. Pero ese no es el problema. El problema es mucho mas curioso y divertido. Arranco el oowriter, y no puedo poner tildes. Tecla de tilde, tecla de letra y... ¡nada! Ni siquiera sale la letra sin tilde. Y luego el mas dificil todavia: desde un konsole de root, se arranca el oowriter y ¡todo funciona! La ventana sale con el feo aspecto de GTK, pero se puede escribir correctamente. Tras trastear con las variables de entorno, consegui reproducir el comportamiento con un usuario normal haciendo unset de la variable KDE_FULL_SESSION antes de arrancar oowriter. Pero el problema era otro, y era que las locales estaban sin configurar. Por supuesto, la página de donde saque la info, no podia ser de otro sitio que de la documentacion de gentoo. Creado el archivo 02locales en /etc/env.d/ y todo listo y funcionando.
El segundo (y ultimo por hoy) problema por desgracia no ha conseguido solucionarlo, pero si al menos evitarlo. Se trata de un bonito fallo al reproducir video:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 141 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 90
Current serial number in output stream: 91
Esto parece ser un fallo en el driver de video de intel que hace incompatible el uso de xcomposite y XVideo. He probado todas las soluciones habidas que he visto: añadir parametros Cachelines /LinearAlloc a xorg.conf, etc y ninguna parece funcionar (por el momento al menos). La manera de evitar este problema es bien no usar xcomposite y decir adios a compiz o bien configurar el reproductor para no usar xvideo y usar xshm para reproducir. En cualquier caso, el resultado funciona pero deja mal sabor de boca. Como se suele decir, mas se perdio en cuba, y ellos no tenian la competencia de Pequesuave. Y total, con la velocidad a la que se desarrolla compiz, seguro que en nada esta arreglado el tema.
Por hoy lo dejo que es tarde, hasta la proxima!
Pero a lo que iba, que mejor para volver al escribir que unos pocos problemillas de esos que tanto molestan.
Para empezar, el open office. Un programa fascintante, sobre todo cuando se instala en gentoo y no se usa el paquete binario: Nunca imagine que algo podría tardar tantas horas en compilarse en un Core Duo con 2GB de RAM. Pero ese no es el problema. El problema es mucho mas curioso y divertido. Arranco el oowriter, y no puedo poner tildes. Tecla de tilde, tecla de letra y... ¡nada! Ni siquiera sale la letra sin tilde. Y luego el mas dificil todavia: desde un konsole de root, se arranca el oowriter y ¡todo funciona! La ventana sale con el feo aspecto de GTK, pero se puede escribir correctamente. Tras trastear con las variables de entorno, consegui reproducir el comportamiento con un usuario normal haciendo unset de la variable KDE_FULL_SESSION antes de arrancar oowriter. Pero el problema era otro, y era que las locales estaban sin configurar. Por supuesto, la página de donde saque la info, no podia ser de otro sitio que de la documentacion de gentoo. Creado el archivo 02locales en /etc/env.d/ y todo listo y funcionando.
El segundo (y ultimo por hoy) problema por desgracia no ha conseguido solucionarlo, pero si al menos evitarlo. Se trata de un bonito fallo al reproducir video:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 141 (XVideo)
Minor opcode of failed request: 19 ()
Serial number of failed request: 90
Current serial number in output stream: 91
Esto parece ser un fallo en el driver de video de intel que hace incompatible el uso de xcomposite y XVideo. He probado todas las soluciones habidas que he visto: añadir parametros Cachelines /LinearAlloc a xorg.conf, etc y ninguna parece funcionar (por el momento al menos). La manera de evitar este problema es bien no usar xcomposite y decir adios a compiz o bien configurar el reproductor para no usar xvideo y usar xshm para reproducir. En cualquier caso, el resultado funciona pero deja mal sabor de boca. Como se suele decir, mas se perdio en cuba, y ellos no tenian la competencia de Pequesuave. Y total, con la velocidad a la que se desarrolla compiz, seguro que en nada esta arreglado el tema.
Por hoy lo dejo que es tarde, hasta la proxima!
Tuesday, November 6, 2007
(In)seguridad wireless III
¡Al fin! Tras mucho esfuerzo y sufrimiento al fin los vecinos no van a poder conectarse a mi wifi. Bueno, esto no es del todo cierto: si que van a poder conectarse, pero no van a poder usarla.
Ultimamente han llegado a mi casa multitud de chismes con capacidad wifi. A la semana de tener la PSP se le unió la Wii y hace una semana la flamante PS3. Y todos ellos con soporte WPA, así que ya tocaba hacer algo. Tras decidirme a cambiar al fin el cifrado WEP por WPA me puse manos a la obra. Hasta ahora tenía un portátil NEC PIVM 1.8GHz con 256Mb RAM haciendo de router/server con debian stable, usando cifrado WEP y un script iptables bastante molesto para posibles intrusos. Para los PC's que no tuvieran soporte de WPA (el PC de "la familia" con una tarjeta belkin 11b, p.ej.) tenía una fonera que podía poner en modo WEP con forwarding deshabilitado y OpenVPN al server, de modo que hiciera falta conectarse a la VPN para salir al exterior. No me hacía gracia usar la fonera con su firmware original para mover tráfico, pero no había otra opción de coste 0.
La tarjeta PCMCIA de 25 euros que me compre en su día llevaba ya un tiempo funcionando en modo Master + WEP gracias a los drivers prism54 y el hostapd anunciaba (y aún anuncia) que también daba soporte a este chispet para modo Master + WPA. Bien, apt-get install hostapd, leer docuemtancion, editar configuración, probar y... ¡buen intento, sigue probando!
No se encuentra dispositivo. Tras cambiar el archivo .conf durante 5 minutos lo doy por imposible y busco en internet. Al igual que en un mensaje en algún foro, lo ejecuto con strace y efectivamente, hostapd levanta la interfaz eth2 (bien) y luego intenta controlar la eth2ap (¡mal!). Por ahi sugerían recompilar el hostapd con un hack del driver prism54: quitar a pelo ese "ap" del string del nombre de la interfaz. Bueno, se puede intentar. Como los experimentos, mejor con gaseosa, quito la tarjeta del router/server debian stable y la pongo en el portatil gentoo. Copio el ebuild a un overlay local, lo edito para bajar el código del disco duro, modifico el propio código (%sap ->%s), digest del ebuild y pa'lante. Y... nada. Arranca el rpograma, saca todos sus mensajitos, pero ni pone la tarjeta en modo Master, ni WPA, ni nada de nada. Indagando más por la red, resulta que el soporte de prism54 para hostapd es por así decirlo "histórico" ya que la realidad es que "un día funcionó con una versión del driver" segun cuenta el propio creador del hostapd en este email. La cosa para prism54 dejó de funcionar allá por 2005, en el mail de 2006 dijo de avisar en la web que ya no funcionaba y a noviembre de 2007 sigue apareciendo que lo soporta para que algún pardillo pierda la tarde intentándolo. Dado que no me apetecía bucear en las versiones del 2004 del prism54 para recompilar un modulo para el kernel de 2007 y el posible fin del mundo que podría ocasionar dicha combinación, deseché esa vía.
Dado el estado de las cosas, me he decidido por otra configuración. Para los PC's, prism54 en Master + WEP (menos da una piedra) con OpenVPN y política DROP para FORWARD con origen wifi. A traves el tun0, salida a internet, así cualquiera se puede meter en la wifi pero ni podrá usarla ni escuchar nada puesto que todo irá en tuneles cifrados. Y para las consolas, fonera + WPA, así de paso se separa el tráfico de unos y otros para (en el futuro) implementar QoS con tc.
La instaltación de la OpenVPN la he hecho siguiendo el HOWTO oficial, usando certificados. Tanto para windows con OpenVPN GUI como para linux con NetworkManager el sistema funcona bastante bien.
Al hacer un 'ping server-f -s 15000' con la wifi da unas tasas de 1,1Mb/s tanto de subida como de bajada. Al hacerlo con la VPN, el trafico observado en la interfaz wifi es de apenas 350kb/s. Extrañado, cree en el server un archivo de 100MB con 'dd if=/dev/zero of=/var/www/zero' y lo bajé a traves de la VPN. Resultado: 350kb/s en la wifi, 3Mb/s de velocidad efectiva. Razón: comp-lzo haciendo su trabajo. En efecto, al intentar bajar un 'openssl rand 100000000 > /var/www/rand' las tasas en wifi eran de 2,4Mb/s y en el tunel 2,02Mb/s (todo esto con la wifi a 54Mbps teóricos). Eso sí, durante la descarga de datos, el proceso de VPN llega a consumir un 15% de CPU, asi que habrá que pensar en cambiar el cifrado blowfish por defecto por alguno más ligero...
Algún día postaré todos los ficheros de configuración y scripts de iptables, pero a día de hoy creo que ya he hecho bastante.
Eso sí, aunque ya tenga una wifi segura, no pienso ponerle antivirus al PequeSuave Ventanas XP, ¿que sería de esta vida sin riesgo?
Ultimamente han llegado a mi casa multitud de chismes con capacidad wifi. A la semana de tener la PSP se le unió la Wii y hace una semana la flamante PS3. Y todos ellos con soporte WPA, así que ya tocaba hacer algo. Tras decidirme a cambiar al fin el cifrado WEP por WPA me puse manos a la obra. Hasta ahora tenía un portátil NEC PIVM 1.8GHz con 256Mb RAM haciendo de router/server con debian stable, usando cifrado WEP y un script iptables bastante molesto para posibles intrusos. Para los PC's que no tuvieran soporte de WPA (el PC de "la familia" con una tarjeta belkin 11b, p.ej.) tenía una fonera que podía poner en modo WEP con forwarding deshabilitado y OpenVPN al server, de modo que hiciera falta conectarse a la VPN para salir al exterior. No me hacía gracia usar la fonera con su firmware original para mover tráfico, pero no había otra opción de coste 0.
La tarjeta PCMCIA de 25 euros que me compre en su día llevaba ya un tiempo funcionando en modo Master + WEP gracias a los drivers prism54 y el hostapd anunciaba (y aún anuncia) que también daba soporte a este chispet para modo Master + WPA. Bien, apt-get install hostapd, leer docuemtancion, editar configuración, probar y... ¡buen intento, sigue probando!
hostapd -dd hostapd.conf
Configuration file: hostapd.conf
Opening raw packet socket for ifindex 5
ioctl(SIOCGIFINDEX): No such device
prism54 driver initialization failed.
No se encuentra dispositivo. Tras cambiar el archivo .conf durante 5 minutos lo doy por imposible y busco en internet. Al igual que en un mensaje en algún foro, lo ejecuto con strace y efectivamente, hostapd levanta la interfaz eth2 (bien) y luego intenta controlar la eth2ap (¡mal!). Por ahi sugerían recompilar el hostapd con un hack del driver prism54: quitar a pelo ese "ap" del string del nombre de la interfaz. Bueno, se puede intentar. Como los experimentos, mejor con gaseosa, quito la tarjeta del router/server debian stable y la pongo en el portatil gentoo. Copio el ebuild a un overlay local, lo edito para bajar el código del disco duro, modifico el propio código (%sap ->%s), digest del ebuild y pa'lante. Y... nada. Arranca el rpograma, saca todos sus mensajitos, pero ni pone la tarjeta en modo Master, ni WPA, ni nada de nada. Indagando más por la red, resulta que el soporte de prism54 para hostapd es por así decirlo "histórico" ya que la realidad es que "un día funcionó con una versión del driver" segun cuenta el propio creador del hostapd en este email. La cosa para prism54 dejó de funcionar allá por 2005, en el mail de 2006 dijo de avisar en la web que ya no funcionaba y a noviembre de 2007 sigue apareciendo que lo soporta para que algún pardillo pierda la tarde intentándolo. Dado que no me apetecía bucear en las versiones del 2004 del prism54 para recompilar un modulo para el kernel de 2007 y el posible fin del mundo que podría ocasionar dicha combinación, deseché esa vía.
Dado el estado de las cosas, me he decidido por otra configuración. Para los PC's, prism54 en Master + WEP (menos da una piedra) con OpenVPN y política DROP para FORWARD con origen wifi. A traves el tun0, salida a internet, así cualquiera se puede meter en la wifi pero ni podrá usarla ni escuchar nada puesto que todo irá en tuneles cifrados. Y para las consolas, fonera + WPA, así de paso se separa el tráfico de unos y otros para (en el futuro) implementar QoS con tc.
La instaltación de la OpenVPN la he hecho siguiendo el HOWTO oficial, usando certificados. Tanto para windows con OpenVPN GUI como para linux con NetworkManager el sistema funcona bastante bien.
Al hacer un 'ping server-f -s 15000' con la wifi da unas tasas de 1,1Mb/s tanto de subida como de bajada. Al hacerlo con la VPN, el trafico observado en la interfaz wifi es de apenas 350kb/s. Extrañado, cree en el server un archivo de 100MB con 'dd if=/dev/zero of=/var/www/zero' y lo bajé a traves de la VPN. Resultado: 350kb/s en la wifi, 3Mb/s de velocidad efectiva. Razón: comp-lzo haciendo su trabajo. En efecto, al intentar bajar un 'openssl rand 100000000 > /var/www/rand' las tasas en wifi eran de 2,4Mb/s y en el tunel 2,02Mb/s (todo esto con la wifi a 54Mbps teóricos). Eso sí, durante la descarga de datos, el proceso de VPN llega a consumir un 15% de CPU, asi que habrá que pensar en cambiar el cifrado blowfish por defecto por alguno más ligero...
Algún día postaré todos los ficheros de configuración y scripts de iptables, pero a día de hoy creo que ya he hecho bastante.
Eso sí, aunque ya tenga una wifi segura, no pienso ponerle antivirus al PequeSuave Ventanas XP, ¿que sería de esta vida sin riesgo?
Thursday, October 25, 2007
"FN Keys" en Linux
Un problema que he tenido con todas las distribuciones que he probado últimamente ha sido el tema de las teclas especiales del portátil, esas que sirven para ajustar el volumen, hibernar, etc. En algunas distros funcionaban algunas cosas, en otras salía el OSD pero no funcionaban y en la mayoría no funcionaban en absoluto. En las distribuciones de prueba ni me he molestado en investigar sobre el asunto pero en mi gentoo tenía que hacer que funcionasen estas teclas ya que su comodidad es incomparable a hacer las cosas con el raton desde algun menú, como el de KMix.
Los pasos para tener las teclas fn funcionando en un Sony Vaio SZ son:
1. Instalar soporte de teclas especiales sony en el kernel. Antes el módulo se llamaba sony_acpi, pero ahora es sony-laptop. Con esto conseguimos que el kernel genere eventos acpi cada vez que pulsamos la tecla fn + f1-f12
2. Procesar los eventos acpi. Para esto basta una sección adicional en el script /etc/acpi/default.sh. Por supuesto, se puede llamar a un script aparte poniendo el clasificador correspondiente en /etc/acpi/events/ y creando el script en la carpeta anterior, o en una subcarpeta, a gusto del usuario. En mi caso, la seccion relevante del default.sh es:
Brillo:
Por supuesto, existen otros métodos como mapear los eventos acpi a pulsaciones de teclas en X, o a través de módulos de KDE, pero esas soluciones o son más complejas y menos potentes o se acercan más al Plug & Pray y si no funcionan a la primera, no hay manera de arreglarlas.
PD: el codigo para la su publicación ha sido porcesado usando esta página. Increíble lo que he tardado en encontrar una página de ese tipo, la relación señal/ruido en Internet cada vez es peor.
Los pasos para tener las teclas fn funcionando en un Sony Vaio SZ son:
1. Instalar soporte de teclas especiales sony en el kernel. Antes el módulo se llamaba sony_acpi, pero ahora es sony-laptop. Con esto conseguimos que el kernel genere eventos acpi cada vez que pulsamos la tecla fn + f1-f12
2. Procesar los eventos acpi. Para esto basta una sección adicional en el script /etc/acpi/default.sh. Por supuesto, se puede llamar a un script aparte poniendo el clasificador correspondiente en /etc/acpi/events/ y creando el script en la carpeta anterior, o en una subcarpeta, a gusto del usuario. En mi caso, la seccion relevante del default.sh es:
3. Crear los scripts que den la funcionalidad. En caso del volumen se puede usar el comando amixer. Para el brillo basta leer/escribir en /sys/class/backlight/sony/brightness. Por supuesto se pueden asignar las funciones que se quieran a las teclas, como ejecutar scripts de mantenimiento, arrancar navegadores... Como ejemplo dejo dos scripts de control de brillo y volumen, que es lo mas usado.
Brillo:
Volumen:
Siendo vol_get:
Y vol_set:
Los scripts son de andar por casa y chapuceros, de hecho creo que son los primeros que he escrito, así que no tengo mucha idea de normas de estilo, ni siquiera de normas en general ;) Pero espero que sirvan para ilustrar el proceso a seguir para ajustar el comportamiento al gusto de cada uno. Y por supuesto la regexp de sed ha sido copiada de una web y modificada para que funcione con la salida del amixer (salida filtrada chapuceramente con grep xD).
Por supuesto, existen otros métodos como mapear los eventos acpi a pulsaciones de teclas en X, o a través de módulos de KDE, pero esas soluciones o son más complejas y menos potentes o se acercan más al Plug & Pray y si no funcionan a la primera, no hay manera de arreglarlas.
PD: el codigo para la su publicación ha sido porcesado usando esta página. Increíble lo que he tardado en encontrar una página de ese tipo, la relación señal/ruido en Internet cada vez es peor.
Thursday, October 18, 2007
Troubleshooting: disparando a los problemas
Entre las distribuciones Linux podemos encontrar dos tipos: las que son para geeks y ponen todo bajo tu control y las que son para gente despreocupada que solo quiere que las cosas funcionen. Bueno, y luego tenemos otras como Ubuntu que se procalama defensona de los inocentes y luego se leen perlas como las de este blog. La frase que me maravilla en concreto es:
El caso es que tras instalar gentoo en el portátil e instalar los programillas necesarios para navegar por internet, ver videos y escuchar múscia, ofimática, juegos, torrents, etc., pues había una serie de pequeños fallos e imperfecciones que molestaban por ahí. Y como instalé gentoo para aprender mas que para usar Linux pues me puse manos a la obra y al final las cosas se fueron solucionando. Por si alguien tiene los mismos problemas, aquí dejo un par de soluciones:
* Reproducción de mp3 acelerada
La mayoría de mp3 se escuchan bien con amaroK + xine, pero los del podcast de "Security Now!" se escuchaban acelerados, como si cada segundo de podcast de reprodujera en unas décimas con el característico sonido agudo y luego quedaba un hueco de silencio lo que quedaba de segundo. Y asi durante todo el podcast. Por supuesto, tanto en el iTunes en XP, en el iPod e incluso en el VLC en gentoo soaba perfecto, así que era culpa de amaroK. Y dado que el amaroK solo es una "interfaz" al motor de sonido, teía que ser culpa de xine. En internet no había mucha info, así que me puse a activar los USE flags desactivados y recompilar el xine-lib, a ver si se solucionaba. Y efectivamente, funcionó, tras activar el flag "mad" y recompilar, el amaroK empezó a reproducir los podcasts de manera normal.
* Aplicaciones GTK "feas"
Esta es más fácil. Usando KDE algunas aplicaciones simplemente parecen feas. Esto es porque usan la librería GTK en lugar de QT, la nativa de KDE. Instalando (emergiendo) el paquete "gtk-engines-qt" todo solucionado. Aparece un menu en el centro de control, bajo "Aspecto y Temas" y desde ahí se puede configurar el aspecto que se quiera.
* Escritorios múltiples con Compiz-Fusion
El problema es que KDE trae por defecto 4 "escritorios virtuales". Cuando se instala compiz, el famoso cubo genera 4 "viewports", es decir, las 4 caras del cubo. El problema es que uno no se entiende con el otro y en el paginador de escritorios aparecen 4x4=16 esritorios! Por supuesto, solo 4 son reales y si se hace click en el escritorio 5, se muestra el 1. Esto tiene fácil solucion y es ajustar los escritorios virtuales a 1 y de esta manera solo apareceran los 4 "viewports" en el paginador. Hasta ahí todo bien, pero resulta que en cuanto se cierra la sesión y se inicia de nuevo, vuelven a aparecer los 16 escritorios porque por alguna razón, KDE no recuerda el cambio de 4 escritorios virtuales a 1 (o de 4 a 17, simplemente lo vuelve a poner a 4). La solución a esto la encontré por casualidad trasteando con el compiz, y resulta que lo que hay que hacer es abrir una consola, matar a compiz, ejecutar kwin (el gestor predeterminado), ajustar los escritorios virtuales a 1 y reiniciar la sesión. Supongo que también funcionaría si se ajusta antes de instalar compiz, lo que sería más elegante.
* KNetworkManager no se inicia automáticamente
En lugar de los net.ethX clásicos de gentoo me dio por instalar el NetworkManager. Y el invento funciona medianamente bien pero resulta que la interfaz de KDE, el KNM, ignora la opción de "Iniciar KNetworkManager automáticamente al ingresar en el sistema". La solución la leí en un foro de fedora, creo recordar y consiste en copiar el archivo ".desktop" del KNM a la carpeta /usr/share/autostart. El archivo en sí se puede sacar del menú del sistema, arrastrandolo y creando una copia.
Bueno, por hoy es suficiente, otro día más.
Sabía que no iba a ser un camino de rosas. El caso es que después de dos horas mirando millones de foros y tutoriales, ¡lo conseguí!Pues vaya, eso si que es facilidad de uso. Yo en gentoo tardé aproximadamente media hora y de ello 15 minutos fueron torpezas que hice por no seguir lo que decía en el HOWTO. Y precisamente gentoo es una de las distribuciones del primer tipo, de "hágalo usted mismo", pero con una cantidad enorme de manuales, HOWTOs, foros y demás documentación. El IKEA de las distribuciones, pero sin tener nombre sueco. No es mi intención machacar a Ubuntu, pero sí que le tengo un poco de manía, y hay cosas como estas que no me hacen cambiar de opinión precisamente.
El caso es que tras instalar gentoo en el portátil e instalar los programillas necesarios para navegar por internet, ver videos y escuchar múscia, ofimática, juegos, torrents, etc., pues había una serie de pequeños fallos e imperfecciones que molestaban por ahí. Y como instalé gentoo para aprender mas que para usar Linux pues me puse manos a la obra y al final las cosas se fueron solucionando. Por si alguien tiene los mismos problemas, aquí dejo un par de soluciones:
* Reproducción de mp3 acelerada
La mayoría de mp3 se escuchan bien con amaroK + xine, pero los del podcast de "Security Now!" se escuchaban acelerados, como si cada segundo de podcast de reprodujera en unas décimas con el característico sonido agudo y luego quedaba un hueco de silencio lo que quedaba de segundo. Y asi durante todo el podcast. Por supuesto, tanto en el iTunes en XP, en el iPod e incluso en el VLC en gentoo soaba perfecto, así que era culpa de amaroK. Y dado que el amaroK solo es una "interfaz" al motor de sonido, teía que ser culpa de xine. En internet no había mucha info, así que me puse a activar los USE flags desactivados y recompilar el xine-lib, a ver si se solucionaba. Y efectivamente, funcionó, tras activar el flag "mad" y recompilar, el amaroK empezó a reproducir los podcasts de manera normal.
* Aplicaciones GTK "feas"
Esta es más fácil. Usando KDE algunas aplicaciones simplemente parecen feas. Esto es porque usan la librería GTK en lugar de QT, la nativa de KDE. Instalando (emergiendo) el paquete "gtk-engines-qt" todo solucionado. Aparece un menu en el centro de control, bajo "Aspecto y Temas" y desde ahí se puede configurar el aspecto que se quiera.
* Escritorios múltiples con Compiz-Fusion
El problema es que KDE trae por defecto 4 "escritorios virtuales". Cuando se instala compiz, el famoso cubo genera 4 "viewports", es decir, las 4 caras del cubo. El problema es que uno no se entiende con el otro y en el paginador de escritorios aparecen 4x4=16 esritorios! Por supuesto, solo 4 son reales y si se hace click en el escritorio 5, se muestra el 1. Esto tiene fácil solucion y es ajustar los escritorios virtuales a 1 y de esta manera solo apareceran los 4 "viewports" en el paginador. Hasta ahí todo bien, pero resulta que en cuanto se cierra la sesión y se inicia de nuevo, vuelven a aparecer los 16 escritorios porque por alguna razón, KDE no recuerda el cambio de 4 escritorios virtuales a 1 (o de 4 a 17, simplemente lo vuelve a poner a 4). La solución a esto la encontré por casualidad trasteando con el compiz, y resulta que lo que hay que hacer es abrir una consola, matar a compiz, ejecutar kwin (el gestor predeterminado), ajustar los escritorios virtuales a 1 y reiniciar la sesión. Supongo que también funcionaría si se ajusta antes de instalar compiz, lo que sería más elegante.
* KNetworkManager no se inicia automáticamente
En lugar de los net.ethX clásicos de gentoo me dio por instalar el NetworkManager. Y el invento funciona medianamente bien pero resulta que la interfaz de KDE, el KNM, ignora la opción de "Iniciar KNetworkManager automáticamente al ingresar en el sistema". La solución la leí en un foro de fedora, creo recordar y consiste en copiar el archivo ".desktop" del KNM a la carpeta /usr/share/autostart. El archivo en sí se puede sacar del menú del sistema, arrastrandolo y creando una copia.
Bueno, por hoy es suficiente, otro día más.
Tuesday, October 16, 2007
openSUSE 10.3 + Compiz-Fusion
Con tanto trajín de distribuciones, cada una instalando su propio gestor de arranque, al final se le queda a uno el MBR hecho un desastre. Y mas cuando alguna distribucion lo que hace es copiar el menú existente y encadenarlo al que instala ella misma. Es decir, uno arrranca el PC tras instalar por ejemplo, SuSE, y aparece un menu de arranque. En ese menu se puede seleccionar entre arrancar SuSE, Pequesuave Ventanas o las instalaciones anteriores de Linux. Pues cuando se selecciona la instalacion anterior, en lugar de arrancar el sistema, nos lleva al menu original de esa instalación.
El caso es que arranqué SuSE para arreglar el desastre y de paso instalar ese gestor de arranque tan bonito que trae (gfxboot se llama el invento, y es un parche al grub desarrollado precisamente por la gente de SuSE).
Ya que estaba, y recordando la instalación del qemu, decidí probar suerte con el compiz-fusion. Compiz viene instalado por defecto y sólo hace falta activarlo con un par de clicks, pero no hay nada como un estar a la última. Y nueva sorpresa: sólo hace falta instalar el "opensuse-xgl-settings" desde el YaST y luego dentro del configurador, darle al botón "Instalar", luego a "Configurar" y luego a "Activar". Reinicio y todo listo. Sin un solo comando, ni consola, ni nada. Esto sí que es un sistema "user-friendly".
Ojo, no digo que yo no me lo pase bien toqueteando todo lo que puedo con el consola con gentoo, lo que pasa es que no se puede predicar a los cuatro vientos lo facil que es un sistema y luego para cualquier cosa que no sea navegar por internet, tener que estar haciendo sudo apt-get install, editando xorg.conf's, creando scripts y demás historias...
Para terminar, un par de screenshots.
Escritorio por defecto:
Compiz-Fusion:
En fin, no se de donde han salido todos los fans de Ubuntu, pero para instalar Compiz-Fusion hay que hacer casi el mismo trabajo que para gentoo... ¿eso es ser facil / para principiantes? A ver si un día de estos saco tiempo y hago una pequeña comparativa entre todas las distros que he tocado la últma semana.
El caso es que arranqué SuSE para arreglar el desastre y de paso instalar ese gestor de arranque tan bonito que trae (gfxboot se llama el invento, y es un parche al grub desarrollado precisamente por la gente de SuSE).
Ya que estaba, y recordando la instalación del qemu, decidí probar suerte con el compiz-fusion. Compiz viene instalado por defecto y sólo hace falta activarlo con un par de clicks, pero no hay nada como un estar a la última. Y nueva sorpresa: sólo hace falta instalar el "opensuse-xgl-settings" desde el YaST y luego dentro del configurador, darle al botón "Instalar", luego a "Configurar" y luego a "Activar". Reinicio y todo listo. Sin un solo comando, ni consola, ni nada. Esto sí que es un sistema "user-friendly".
Ojo, no digo que yo no me lo pase bien toqueteando todo lo que puedo con el consola con gentoo, lo que pasa es que no se puede predicar a los cuatro vientos lo facil que es un sistema y luego para cualquier cosa que no sea navegar por internet, tener que estar haciendo sudo apt-get install, editando xorg.conf's, creando scripts y demás historias...
Para terminar, un par de screenshots.
Escritorio por defecto:
Compiz-Fusion:
En fin, no se de donde han salido todos los fans de Ubuntu, pero para instalar Compiz-Fusion hay que hacer casi el mismo trabajo que para gentoo... ¿eso es ser facil / para principiantes? A ver si un día de estos saco tiempo y hago una pequeña comparativa entre todas las distros que he tocado la últma semana.
Linux para... ¿seres humanos?
Tras usar Windows durante un tiempo, uno se hace a la idea de que cada X tiempo toca formatear. Eso, y que de manera casi inevitable hay que instalarse un antivirus, antispyware, bla, bla, bla... Bueno, yo soy un temerario y a parte de usar WEP en la wifi de mi casa jamás en 9 años que llevo usando un PC he tocado un antivirus. Eso de tener un programa mirando todo lo que haces, lo que te bajas, lo que envías por msn a amigos incautos y tocando las narices en general, no me hace mucha gracia. Para programas inútiles que consuman recursos prefiero el compiz, que al menos da una alegría a la vista, jeje. Y por cierto, en estos 9 años: 0 infecciones por virus para el menda. Del blaster me libré por conectarme por router y de lo demás, por tener dos dedos de frente al navegar por internet. En realidad no hay antivirus que proteja al usuario de su propia estupidez así que toda el concepto de "antivirus" carece un poco de sentido....
Volviendo al tema de los formateos periódicos, cuando se vuelven necesarios cada 3 meses hasta el más inexperto se cansa y pide ayuda a su amigo informático. Que por cierto, esto de "el amigo informático" ya lo trataré en otros posts, porque tiene tela el asunto y ya me he desviado bastante. El caso es que uno analiza las necesidades del usuario y le dice que para navegar, msn y ofimática cualquier distibución de Linux es más que suficiente. Pero claro, tiene que ser un Linux "fácil" y aquí empiezan los problemas.
El primero que viene a la mente es el tan de moda Ubuntu, pero a parte de parecerme bastatne feo (cosa solucionable), para hacer cualquier cosa hay que andar abriendo consolas y haciendo sudos. Si eso es un sistema para novatos que baje dios y lo vea.
Luego uno piensa en los "clásicos". Aún recuerdo mi primer linux, aquel Mandrake 7.2 que venía con un revista e instalé en el PIII450, 256Mb, 10Gb y Voodoo3 de la familia. Ya arranqué un PCLinuxOS (los desarrolladores son ex-Mandrake) hace unas semanas y me pareció una gran distro, así que la opción lógica fue la nueva Mandriva 2008.0 Free, en teoría la versión oficial de la saga. La verdad es que me decepcionó un poco al no traer driviers para la ipw3945 pero el centro de control no estaba nada mal. Aún asi la falta de drivers "out-of-the-box" me pareció un fallo muy grave para una distribución que pretende ser fácil.
Hace unos meses había grabado un DVD con la openSUSE 10.2 y no me convenció demasiado, al igual que la 9.algo un tiempo atrás, pero ya que había salido hace poco la 10.3 decidí probarla. Y solo me queda decir: ¡wow! Vaya mejora en apenas unos meses. Mientras la 10.2 no reconocía ni la pantalla 1280x800 del portatil, la 10.3 directamente arrancó con un precioso splashboot a pantalla completa. Impresionante. Y el escritorio no es para menos. Estuve unas horas trasteando con el YaST y la verdad es que parece que no hace falta tocar la consola ni un solo momento para configurar todo como se quiere. Incluso instalé el qemu a golpe de ratón sin ningún problema. Me ha dejado tan buen sabor de boca que en cuanto termine de "tunear" el gentoo del portátil (con, por ejemplo, el gfxboot de SuSE) sustituiré el Debian 4.0 del PC de escritorio por un flamante openSUSE 10.3. Y eso, tras... ¿5? años usando Debian, son palabras mayores.
Eso sí, del servidor/router el único que puede sustituir a mi querido Debian es ese OpenBSD que ando probando y no tiene tan mala pinta como creía. Pero los experimentos, con gaseosa; así que de momento, y por muchos meses, seguirá habiendo un Debian en mi casa :)
PD: al principio he hablado de "Windows". Tras las últimas clases de "Traducción de textos informáticos" en la facultad no se si esto es correcto. Después algunas barbaridades de días pasados, esta mañana me enteré de que "phishing" es totalmente incorrecto y hay que sustituirlo directamente por la palabra "estafa". Vamos, que si te timan al comprar una casa, te han hecho phishing, así de repente. Y todo esto en un artículo que trataba de explicar qué es el phishing.... ¡perdon! qué es "la estafa". Así que creo que en honor a mi sabia profesora de inglés debería empezar a hablar de Pequesuave Ventanas XP, no vaya a ser que me suspenda a final de cuatrimestre...
Volviendo al tema de los formateos periódicos, cuando se vuelven necesarios cada 3 meses hasta el más inexperto se cansa y pide ayuda a su amigo informático. Que por cierto, esto de "el amigo informático" ya lo trataré en otros posts, porque tiene tela el asunto y ya me he desviado bastante. El caso es que uno analiza las necesidades del usuario y le dice que para navegar, msn y ofimática cualquier distibución de Linux es más que suficiente. Pero claro, tiene que ser un Linux "fácil" y aquí empiezan los problemas.
El primero que viene a la mente es el tan de moda Ubuntu, pero a parte de parecerme bastatne feo (cosa solucionable), para hacer cualquier cosa hay que andar abriendo consolas y haciendo sudos. Si eso es un sistema para novatos que baje dios y lo vea.
Luego uno piensa en los "clásicos". Aún recuerdo mi primer linux, aquel Mandrake 7.2 que venía con un revista e instalé en el PIII450, 256Mb, 10Gb y Voodoo3 de la familia. Ya arranqué un PCLinuxOS (los desarrolladores son ex-Mandrake) hace unas semanas y me pareció una gran distro, así que la opción lógica fue la nueva Mandriva 2008.0 Free, en teoría la versión oficial de la saga. La verdad es que me decepcionó un poco al no traer driviers para la ipw3945 pero el centro de control no estaba nada mal. Aún asi la falta de drivers "out-of-the-box" me pareció un fallo muy grave para una distribución que pretende ser fácil.
Hace unos meses había grabado un DVD con la openSUSE 10.2 y no me convenció demasiado, al igual que la 9.algo un tiempo atrás, pero ya que había salido hace poco la 10.3 decidí probarla. Y solo me queda decir: ¡wow! Vaya mejora en apenas unos meses. Mientras la 10.2 no reconocía ni la pantalla 1280x800 del portatil, la 10.3 directamente arrancó con un precioso splashboot a pantalla completa. Impresionante. Y el escritorio no es para menos. Estuve unas horas trasteando con el YaST y la verdad es que parece que no hace falta tocar la consola ni un solo momento para configurar todo como se quiere. Incluso instalé el qemu a golpe de ratón sin ningún problema. Me ha dejado tan buen sabor de boca que en cuanto termine de "tunear" el gentoo del portátil (con, por ejemplo, el gfxboot de SuSE) sustituiré el Debian 4.0 del PC de escritorio por un flamante openSUSE 10.3. Y eso, tras... ¿5? años usando Debian, son palabras mayores.
Eso sí, del servidor/router el único que puede sustituir a mi querido Debian es ese OpenBSD que ando probando y no tiene tan mala pinta como creía. Pero los experimentos, con gaseosa; así que de momento, y por muchos meses, seguirá habiendo un Debian en mi casa :)
PD: al principio he hablado de "Windows". Tras las últimas clases de "Traducción de textos informáticos" en la facultad no se si esto es correcto. Después algunas barbaridades de días pasados, esta mañana me enteré de que "phishing" es totalmente incorrecto y hay que sustituirlo directamente por la palabra "estafa". Vamos, que si te timan al comprar una casa, te han hecho phishing, así de repente. Y todo esto en un artículo que trataba de explicar qué es el phishing.... ¡perdon! qué es "la estafa". Así que creo que en honor a mi sabia profesora de inglés debería empezar a hablar de Pequesuave Ventanas XP, no vaya a ser que me suspenda a final de cuatrimestre...
Wednesday, October 10, 2007
(In)seguridad wireless II
Con un par de meses de retraso me entero que un grupo de alemanes han terminado de romper el WEP. Si bien ya era conocido que con unos cientos de miles de tramas y menos de una hora de proceso se podía sacar una clave de 128bits, el nuevo método deja esos logros a la altura del betún.
A grandes rasgos, se aprovecha de las tramas ARP para obtener cadenas de 16 bytes de datos pseudoaleatorios del RC4. Esto es gracias a que los 8 bytes de LLC y los 8 de la cabecera ARP son totalmente constantes y conocidos, tanto para la petición como para la respuesta. Así que simplemente se hace un XOR con los contenidos cifrados de la trama ARP y se obtiene el flujo RC4 original. Las propias tramas ARP se distinguen por su longitud. Repitiéndolo (muchas) veces se obtiene la cantidad necesaria de tramas cifradas con distintos IV's para efectuar un ataque estadístico y así recuperar la clave WEP de la wifi.
Ahora los números. Si antes hacían falta cerca de medio millón de tramas (mas bien de IV's) para
poder empezar el análisis con esperanza. Ahora con 40mil (tramas) nos da una esperanza del 50% de encontrar la clave. Para orientarnos, con un AP 11g eso son unos 50 segundos de inyección. Y si antes hacía falta media hora larga para encontrar la clave a partir de los IV's capturados, con el método estadístico basado en ARP se tarda.... ¡3 segundos! Resultado: crackeo (perdón, "recuperación") de claves en menos de un minuto con posibilidades de éxito y en 2 minutos con seguridad de éxito. Para más detalles técnicos, consultar el paper de los autores.
Para llevarlo a la práctica, basta con:
- Tener un punto de acceso con WEP. No, no podeis hacerlo con el del vecino, ¡eso está prohibido!
- Una tarjeta que soporte inyección
- Una versión medianamente reciente del aircrack.
- Capturar paquetes enteros en lugar de sólo IV's
- Ejecutar el aircrack-ng con la opción "-z" para que haga el análisis PTW
Mañana lo probaré con alguna clave aleatoria en un AP dedicado, a ver que tiempo consigo :D
Parece mentira que aún tras leer todas estas maravillas siga usando WEP en casa. Todo por no dedicar 3 minutos a configurar wpa_supplicant. Eso sí, tengo el (leve) atenuante de filtrado mac, iptables tocapelotas y sin servidor DHCP. No sirve de gran cosa pero al menos entorpece a posibles vecinos cotillas. Si alguien es capaz de romper la clave, spoofear su MAC y adivinar cual es el rango de IP's válido así como la IP de gateway, como premio puede usar mi ancho de banda, o lo que quede de él. Eso o tener un usuario de FON, pero eso es otra historia...
A grandes rasgos, se aprovecha de las tramas ARP para obtener cadenas de 16 bytes de datos pseudoaleatorios del RC4. Esto es gracias a que los 8 bytes de LLC y los 8 de la cabecera ARP son totalmente constantes y conocidos, tanto para la petición como para la respuesta. Así que simplemente se hace un XOR con los contenidos cifrados de la trama ARP y se obtiene el flujo RC4 original. Las propias tramas ARP se distinguen por su longitud. Repitiéndolo (muchas) veces se obtiene la cantidad necesaria de tramas cifradas con distintos IV's para efectuar un ataque estadístico y así recuperar la clave WEP de la wifi.
Ahora los números. Si antes hacían falta cerca de medio millón de tramas (mas bien de IV's) para
poder empezar el análisis con esperanza. Ahora con 40mil (tramas) nos da una esperanza del 50% de encontrar la clave. Para orientarnos, con un AP 11g eso son unos 50 segundos de inyección. Y si antes hacía falta media hora larga para encontrar la clave a partir de los IV's capturados, con el método estadístico basado en ARP se tarda.... ¡3 segundos! Resultado: crackeo (perdón, "recuperación") de claves en menos de un minuto con posibilidades de éxito y en 2 minutos con seguridad de éxito. Para más detalles técnicos, consultar el paper de los autores.
Para llevarlo a la práctica, basta con:
- Tener un punto de acceso con WEP. No, no podeis hacerlo con el del vecino, ¡eso está prohibido!
- Una tarjeta que soporte inyección
- Una versión medianamente reciente del aircrack.
- Capturar paquetes enteros en lugar de sólo IV's
- Ejecutar el aircrack-ng con la opción "-z" para que haga el análisis PTW
Mañana lo probaré con alguna clave aleatoria en un AP dedicado, a ver que tiempo consigo :D
Parece mentira que aún tras leer todas estas maravillas siga usando WEP en casa. Todo por no dedicar 3 minutos a configurar wpa_supplicant. Eso sí, tengo el (leve) atenuante de filtrado mac, iptables tocapelotas y sin servidor DHCP. No sirve de gran cosa pero al menos entorpece a posibles vecinos cotillas. Si alguien es capaz de romper la clave, spoofear su MAC y adivinar cual es el rango de IP's válido así como la IP de gateway, como premio puede usar mi ancho de banda, o lo que quede de él. Eso o tener un usuario de FON, pero eso es otra historia...
Wednesday, October 3, 2007
(In)seguridad wireless
El día 28 de septiembre dejé de trabajar como becario de IT en una empresa de ingeniería y como regalo de despedida recibí un PSP "Slim & Lite". Una monada el bicho por cierto. Como no sabían mis gustos en cuanto a juegos en lugar de un UMD recibí un montón de complementos: cables, protectores para la pantalla, etc.
El caso es que volvía a casa en bus y tras trastear un buen rato con las configuraciones de todo el menú me dio por mirar la wifi. La consola tiene soporte para 802.11b (la wifi de 11Mbps, vamos). Siendo como es, un aparato de unos 20cm en su dimensión más amplia no creo que tenga una antena demasiado potente. Aún así, en los 5km que estuve trasteando en el bus antes de llegar a casa encontró nada menos que 67 redes distintas. Y eso que gran parte de esos 5km era una carretera con chalets a los lados...
Y el dato curioso, o quizá preocupante. De esas 67 redes, 10 estaban totalmente sin proteger, algunas incluso con ssid's de "default" o "Wireless". Vamos, si no han cambiado ni la ssid del punto de acceso la probabilidad de entrar al router con admin/admin son más bien altas. Y las consecuencias de eso dependen únicamente de la mala leche del "invitado".
Pero hay más. De las 57 restantes, 50 tenían cifrado WEP. Sí sí, WEP, ese que se rompe en unos minutos con cualquier herramienta de "auditoría de redes". Sólo 7 de las 67 redes tenían cifrado WPA, poco más del 10%. ¿Tan difícil es? ¿No viene en los propios menús de los routers inalámbricos "Cuidado: WEP malo", "Use WPA por su seguridad" y similares? No es que el vecino de al lado tenga que saber de IV's ni inyección de tramas, pero lo mismo le interesa saber que cualquier fulano que pase por la calle tiene acceso a sus carpetas compartidas en Windows, ¿no?
No es que un viajecillo en autobús con una PSP en la mano sea un estudio serio, pero es como para plantearse si a día de hoy realmente vale la pena pagar los 30 y pico euros al mes en ADSL si invirtiéndolos en una buena antena wifi se puede localizar por la ventana decenas de vecinos deseosos de compartir sus conexiones con el mundo...
Un saludo y hasta la próxima!
PD: para que todo esto sea más gracioso, yo mismo uso WEP en casa. Pero shhhhhh......
El caso es que volvía a casa en bus y tras trastear un buen rato con las configuraciones de todo el menú me dio por mirar la wifi. La consola tiene soporte para 802.11b (la wifi de 11Mbps, vamos). Siendo como es, un aparato de unos 20cm en su dimensión más amplia no creo que tenga una antena demasiado potente. Aún así, en los 5km que estuve trasteando en el bus antes de llegar a casa encontró nada menos que 67 redes distintas. Y eso que gran parte de esos 5km era una carretera con chalets a los lados...
Y el dato curioso, o quizá preocupante. De esas 67 redes, 10 estaban totalmente sin proteger, algunas incluso con ssid's de "default" o "Wireless". Vamos, si no han cambiado ni la ssid del punto de acceso la probabilidad de entrar al router con admin/admin son más bien altas. Y las consecuencias de eso dependen únicamente de la mala leche del "invitado".
Pero hay más. De las 57 restantes, 50 tenían cifrado WEP. Sí sí, WEP, ese que se rompe en unos minutos con cualquier herramienta de "auditoría de redes". Sólo 7 de las 67 redes tenían cifrado WPA, poco más del 10%. ¿Tan difícil es? ¿No viene en los propios menús de los routers inalámbricos "Cuidado: WEP malo", "Use WPA por su seguridad" y similares? No es que el vecino de al lado tenga que saber de IV's ni inyección de tramas, pero lo mismo le interesa saber que cualquier fulano que pase por la calle tiene acceso a sus carpetas compartidas en Windows, ¿no?
No es que un viajecillo en autobús con una PSP en la mano sea un estudio serio, pero es como para plantearse si a día de hoy realmente vale la pena pagar los 30 y pico euros al mes en ADSL si invirtiéndolos en una buena antena wifi se puede localizar por la ventana decenas de vecinos deseosos de compartir sus conexiones con el mundo...
Un saludo y hasta la próxima!
PD: para que todo esto sea más gracioso, yo mismo uso WEP en casa. Pero shhhhhh......
Thursday, September 13, 2007
Lío de navegadores
Son algo curioso, los exámenes. Cuando estás estudiando, ves mil cosas en Internet que te interesan, se te ocurren otras mil que hacer en cuanto acabes y literalmente te faltan manos y ojos para todo lo que te gustaría hacer a la vez. Y sorprendentemente, en cuanto acaban, junto con todo lo que has estudiado, se te olvida también todo lo que querías hacer. Para los exámenes de febrero me haré una lista.
Bien, ahora al tema... más o menos. Ya que aún no me he presentado (¿lo haré algún día?) he de decir que hasta hace nada mi ordenador principal era un Sony Vaio SZ1XP con el XP original, con toda la mierda de fabrica desinstalada y para navegar usaba el Seamonkey.
Volviendo al tema de las cosas por hacer, yo he empezado por limpiar. Tenía el escritorio de mi XP hasta arriba de howtos, vídeos, apuntes, exámenes de años anteriores, links, ejemplos de código y demás fauna silvestre. Si estuvieran en mi escritorio real, esto es, en la mesa de mi cuarto, lo que yo y cualquiera haría sería tirarlo todo al cajón para obtener una limpieza fácil y rápida. A falta de cajones, la carpeta Mis Documentos bien me sirve para ello.
Un vez limpito todo, me puse a trastear por la web, a ver si me acordaba de algo y en mi página de inicio vi un feed interesante de slashdot. Lo expandí y me puse a leerlo y en mitad de la lectura despareció el texto y salió "La información no se encuentra disponible". Como no era la primera vez que pasaba decidí abandonar Google y buscar algo mejor. Como hace tiempo vi que un amigo usaba netvibes me registré y lo estuve probando. Una maravilla, muchísimo mejor que iGoogle. Y cómo no, la opción de personalizar no pasó desapercibida y los skins que tiene son otra maravilla. Pero claro, el bonito skin negro del netvibes no pegaba nada con el modern del mozilla. Sabía que skins para seamonkey hay poquitos, pero es que los pocos que había han dejado de funcionar con las nuevas versiones. Así que decepcionado y con tiempo libre ya tenía algo que hacer.
Como los navegadores maduros se pueden contar con los dedos de una mano (bueno, y media) no iba a ser muy complicado.
Primer candidato: Safari 3. Lo había probado en el curro unos días antes en el PC de un compañero. Súper bonito, pero aun en fase beta, un pelín inestable y por lo que vi en la web, sin posiblidad de skins.
Segundo candidato: Opera. Los recientes comentarios sobre la v9.5 alpha sonaban muy bien y tenía ganas de probarlo. Trasteando por la web vi que tenía posiblidad de skins y me baje la estable, v9.23, para probar. ¡Y qué navegador! Me ha dejado impresionado. Cientos de skins súper currados, widgets, pestañas avanzadas, cliente torrent integrado, gran gestor de descargas y cosas que aun no he probado como gestos de ratón. Lo mejor son las pestañas. Si algo me mantenía usando seamonkey en lugar de firefox eran las pestañas. Nada de Ctrl + T para abrir pestañas. Se teclea la url, Cntrl + Enter y voilá, nueva pestaña con la url. Nada de teclear las busquedas en la barra de Google de la derecha. Se teclean los términos donde siempre, flecha arriba, Enter (o Cntrl + Enter para pestaña nueva) y voilá, tenemos la búsqueda. En el opera es incluso mejor. Si ponemos "g cosa" busca "cosa" en Google. Con "y cosa" busca "cosa" en Yahoo. Con Shift + Enter lo abre en una pestaña nueva y con Ctrl + Shift + Enter, en una pestaña nueva en segundo plano. Im - presionante. Tan sencillo y tan, tan cómodo. Y lo mismo para los links. Pero tantas cosas buenas tienen su punto en contra. Justo cuanto iba a postear todas estas maravillas... blogger no funciona con opera. Vaya desilusión, resulta que opera tampoco es "el navegador definitivo". Mientras espero al Opera 9.5 seguiré usando Seamonkey para bloguear y Opera para navegar.
Me he quedado tan satisfecho con Opera que he dejado de buscar y he decidido no probar Netscape (si, sigue vivo) y alguno otro que quedaba por ahí. Y los dos mas populares: IE7 y Firefox ya estaban descartados por su gestión de pestañas y urls.
Ah, y ya de paso, con el Opera y el netvibes en negro, mis ventanas de XP originales y fondo de escritorio en azul no pegaban, así que también los cambié. Ya que estaba... Aquí os dejo unas capturas del resultado final del invento:
Escritorio:
Menú inicio:
Netvibes en Opera:
Bueno, ya está bien por hoy. Ya toca cerrar el viejo Seamonkey y navegar un poco con el flamante Opera antes de dormir.
Hasta la próxima!
PD: en el anterior post, el codigo está un poco mal. Donde pone ptr->s debería poner sólo s. Fallo mío al adaptar el código original. No lo edito porque blogger y el código en C se odian y sale deformado en la edición :(
Bien, ahora al tema... más o menos. Ya que aún no me he presentado (¿lo haré algún día?) he de decir que hasta hace nada mi ordenador principal era un Sony Vaio SZ1XP con el XP original, con toda la mierda de fabrica desinstalada y para navegar usaba el Seamonkey.
Volviendo al tema de las cosas por hacer, yo he empezado por limpiar. Tenía el escritorio de mi XP hasta arriba de howtos, vídeos, apuntes, exámenes de años anteriores, links, ejemplos de código y demás fauna silvestre. Si estuvieran en mi escritorio real, esto es, en la mesa de mi cuarto, lo que yo y cualquiera haría sería tirarlo todo al cajón para obtener una limpieza fácil y rápida. A falta de cajones, la carpeta Mis Documentos bien me sirve para ello.
Un vez limpito todo, me puse a trastear por la web, a ver si me acordaba de algo y en mi página de inicio vi un feed interesante de slashdot. Lo expandí y me puse a leerlo y en mitad de la lectura despareció el texto y salió "La información no se encuentra disponible". Como no era la primera vez que pasaba decidí abandonar Google y buscar algo mejor. Como hace tiempo vi que un amigo usaba netvibes me registré y lo estuve probando. Una maravilla, muchísimo mejor que iGoogle. Y cómo no, la opción de personalizar no pasó desapercibida y los skins que tiene son otra maravilla. Pero claro, el bonito skin negro del netvibes no pegaba nada con el modern del mozilla. Sabía que skins para seamonkey hay poquitos, pero es que los pocos que había han dejado de funcionar con las nuevas versiones. Así que decepcionado y con tiempo libre ya tenía algo que hacer.
Como los navegadores maduros se pueden contar con los dedos de una mano (bueno, y media) no iba a ser muy complicado.
Primer candidato: Safari 3. Lo había probado en el curro unos días antes en el PC de un compañero. Súper bonito, pero aun en fase beta, un pelín inestable y por lo que vi en la web, sin posiblidad de skins.
Segundo candidato: Opera. Los recientes comentarios sobre la v9.5 alpha sonaban muy bien y tenía ganas de probarlo. Trasteando por la web vi que tenía posiblidad de skins y me baje la estable, v9.23, para probar. ¡Y qué navegador! Me ha dejado impresionado. Cientos de skins súper currados, widgets, pestañas avanzadas, cliente torrent integrado, gran gestor de descargas y cosas que aun no he probado como gestos de ratón. Lo mejor son las pestañas. Si algo me mantenía usando seamonkey en lugar de firefox eran las pestañas. Nada de Ctrl + T para abrir pestañas. Se teclea la url, Cntrl + Enter y voilá, nueva pestaña con la url. Nada de teclear las busquedas en la barra de Google de la derecha. Se teclean los términos donde siempre, flecha arriba, Enter (o Cntrl + Enter para pestaña nueva) y voilá, tenemos la búsqueda. En el opera es incluso mejor. Si ponemos "g cosa" busca "cosa" en Google. Con "y cosa" busca "cosa" en Yahoo. Con Shift + Enter lo abre en una pestaña nueva y con Ctrl + Shift + Enter, en una pestaña nueva en segundo plano. Im - presionante. Tan sencillo y tan, tan cómodo. Y lo mismo para los links. Pero tantas cosas buenas tienen su punto en contra. Justo cuanto iba a postear todas estas maravillas... blogger no funciona con opera. Vaya desilusión, resulta que opera tampoco es "el navegador definitivo". Mientras espero al Opera 9.5 seguiré usando Seamonkey para bloguear y Opera para navegar.
Me he quedado tan satisfecho con Opera que he dejado de buscar y he decidido no probar Netscape (si, sigue vivo) y alguno otro que quedaba por ahí. Y los dos mas populares: IE7 y Firefox ya estaban descartados por su gestión de pestañas y urls.
Ah, y ya de paso, con el Opera y el netvibes en negro, mis ventanas de XP originales y fondo de escritorio en azul no pegaban, así que también los cambié. Ya que estaba... Aquí os dejo unas capturas del resultado final del invento:
Escritorio:
Menú inicio:
Netvibes en Opera:
Bueno, ya está bien por hoy. Ya toca cerrar el viejo Seamonkey y navegar un poco con el flamante Opera antes de dormir.
Hasta la próxima!
PD: en el anterior post, el codigo está un poco mal. Donde pone ptr->s debería poner sólo s. Fallo mío al adaptar el código original. No lo edito porque blogger y el código en C se odian y sale deformado en la edición :(
Wednesday, September 12, 2007
Sockets para linux - cliente
A ver si esta vez ya me animo a ir actualizando el blog. El verano esta acabando, los exámenes están hechos, al fin tengo tiempo libre. Así que... ¿qué mejor para empezar que cumplir con lo prometido? Así que aquí va una de sockets de Berckley, por supuesto en C y en linux (GNU/Linux para los pedantes xD) La presentación... bueno, eso ya lo haré algún día.
El origen del código es una práctica para la asignatura de Sistemas Operativos Distribuidos, de la Facultad de Informática de la UPM. Pero esto es lo de menos, ya que el payload está, sólo interesa la parte de los sockets. Lo relevante es que viene de la implementación con sockets y sin estado. Esto afecta de manera que para cada comunicación se abre una nueva conexión y se cierra al terminar la petición. Algo al estilo HTTP 1.0. Bien, ¡manos a la obra!
Cuerpo del cliente
Este es el código útil que va a hacer cosas y entre ellas, enviar y recibir datos por la red. Sustituir ese código útil en los corchetes es tarea vuestra :P
Trivial, ¿verdad? Bueno, si sólo fuera eso sería estupendo, ya estaría todo claro, el código habla por sí mismo: conectar, enviar y recibir. De hecho también se podría usar read(...) y write(...) ya que s no es ni más ni menos que un descriptor de fichero. Pero se observa una sospechosa función conectar(), que como es de prever no viene en ninguna biblioteca y no hay direcciones, ni puertos ni nada de nada. Normalmente todo eso iría en el código principal, pero por hacerlo mas bonito y reusable lo separé en una función aparte, la cual no sería dificil de meter en un .h si fuera necesario.
Función conectar()
Esta es la que hace que el descriptor s contenga un socket listo para ser usado para hacer read y write sobre él, o si se prefiere, send(...) y recv(...).
Lo primero se definen dos estructuras de datos para contener la informacion del socket a crear y del host destino.
En segundo lugar se comprueba (de manera chapucera) que las variables de entorno que indiquen el server y puerto están puestas. Se podrían usar valores fijos, pedirlos interactivamente, o lo que prefiramos.
Más tarde se crea el socket en sí, con una función sorprendentemente llamada socket(...). Lo creamos del tipo stream y protocolo TCP (sí, un poco de redundancia nunca viene mal, jeje...). Una vez tenemos el socket creado, necesitamos conectarlo y para ello necesitamos una direccion. Como lo que tenemos es un nombre (host.dominio.com) lo resolvemos con gethostbyname(...) y vamos construyendo la estructura que nos define el host destino. El siguiente campo se rellena con el puerto destino, que se ha de pasar a formato de red con htons(...) (por el tema de máquinas big-endian/little-endian). De hecho este nombre tan raro viene de "host to network, short"
Llegados a este punto tenemos el socket creado y una estructura que nos define exactamente dónde conectarlo. Pues una llamada a connect(...) y tenemos un socket listo para usar.
Resumen
El proceso en caso de no haber conexión, en el cliente es:
crear socket -> identificar host+puerto destino -> conectar socket -> enviar/recibir -> cerrar socket.
El caso del servidor lo dejamos para la siguiente entrada.
El origen del código es una práctica para la asignatura de Sistemas Operativos Distribuidos, de la Facultad de Informática de la UPM. Pero esto es lo de menos, ya que el payload está, sólo interesa la parte de los sockets. Lo relevante es que viene de la implementación con sockets y sin estado. Esto afecta de manera que para cada comunicación se abre una nueva conexión y se cierra al terminar la petición. Algo al estilo HTTP 1.0. Bien, ¡manos a la obra!
Cuerpo del cliente
Este es el código útil que va a hacer cosas y entre ellas, enviar y recibir datos por la red. Sustituir ese código útil en los corchetes es tarea vuestra :P
RDIR *r_opendir(char *dirname) {
mensaje_t mensaje;
int s;
[...]
if ((ptr->s=conectar()) < 0) {
perror("error de conexion");
return NULL;
}
[...]
if ((aux=send(ptr->s, &mensaje, sizeof(mensaje), 0)) < 0)
perror("send mensaje");
if (recv(ptr->s, &mensaje, sizeof(mensaje), 0) < 0)
perror("recv mensaje");
close(s);
return [...];
}
Trivial, ¿verdad? Bueno, si sólo fuera eso sería estupendo, ya estaría todo claro, el código habla por sí mismo: conectar, enviar y recibir. De hecho también se podría usar read(...) y write(...) ya que s no es ni más ni menos que un descriptor de fichero. Pero se observa una sospechosa función conectar(), que como es de prever no viene en ninguna biblioteca y no hay direcciones, ni puertos ni nada de nada. Normalmente todo eso iría en el código principal, pero por hacerlo mas bonito y reusable lo separé en una función aparte, la cual no sería dificil de meter en un .h si fuera necesario.
Función conectar()
Esta es la que hace que el descriptor s contenga un socket listo para ser usado para hacer read y write sobre él, o si se prefiere, send(...) y recv(...).
int conectar(void){
struct sockaddr_in dir;
struct hostent *host_info;
int s;
if (getenv("SERVIDOR") == NULL || getenv("PUERTO") == NULL){
printf("Establecer SERVIDOR y PUERTO en variables de entrono\n");
return -1;
}
if ((s=socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) < 0) {
perror("error creando socket");
return -1;
}
host_info=gethostbyname(getenv("SERVIDOR"));
memcpy(&dir.sin_addr.s_addr, host_info->h_addr, host_info->h_length);
dir.sin_port=htons(atoi(getenv("PUERTO")));
dir.sin_family=PF_INET;
if (connect(s, (struct sockaddr *)&dir, sizeof(dir)) < 0) {
perror("error en connect");
close(s);
return -1;
}
return s;
}
Lo primero se definen dos estructuras de datos para contener la informacion del socket a crear y del host destino.
En segundo lugar se comprueba (de manera chapucera) que las variables de entorno que indiquen el server y puerto están puestas. Se podrían usar valores fijos, pedirlos interactivamente, o lo que prefiramos.
Más tarde se crea el socket en sí, con una función sorprendentemente llamada socket(...). Lo creamos del tipo stream y protocolo TCP (sí, un poco de redundancia nunca viene mal, jeje...). Una vez tenemos el socket creado, necesitamos conectarlo y para ello necesitamos una direccion. Como lo que tenemos es un nombre (host.dominio.com) lo resolvemos con gethostbyname(...) y vamos construyendo la estructura que nos define el host destino. El siguiente campo se rellena con el puerto destino, que se ha de pasar a formato de red con htons(...) (por el tema de máquinas big-endian/little-endian). De hecho este nombre tan raro viene de "host to network, short"
Llegados a este punto tenemos el socket creado y una estructura que nos define exactamente dónde conectarlo. Pues una llamada a connect(...) y tenemos un socket listo para usar.
Resumen
El proceso en caso de no haber conexión, en el cliente es:
crear socket -> identificar host+puerto destino -> conectar socket -> enviar/recibir -> cerrar socket.
El caso del servidor lo dejamos para la siguiente entrada.
Friday, August 17, 2007
Analisis de un ataque a un server Ubuntu
Aunque aún estoy de vacaciones y bastante viciadillo al Civilization IV: Beyond the Sword, quizá sea buen momento para vovler a actulizar el blog.
Y antes de ponerme a escribir un "micro how-to" sobre sockets, creo que lo mejor sería algo para leer de forma amena. Y que mejor que analizar los rastros dejados por un juanker después de convertir un server basado en Ubuntu en un zombie. Salió hace poco en barrapunto, pero por si os lo habéis perdido, aquí está:
http://blog.gnist.org/article.php?story=HollidayCracking
Y antes de ponerme a escribir un "micro how-to" sobre sockets, creo que lo mejor sería algo para leer de forma amena. Y que mejor que analizar los rastros dejados por un juanker después de convertir un server basado en Ubuntu en un zombie. Salió hace poco en barrapunto, pero por si os lo habéis perdido, aquí está:
http://blog.gnist.org/article.php?story=HollidayCracking
Saturday, June 23, 2007
El principio
Los exámenes ya han pasado. Para bien o para mal, como todo estudiante en junio,
ha habido que dejar alguna asignatura para septiembre, pero eso es lo de menos. Todo el verano por delante para cambiar el chip y pasar de estudiar informática a aprender informática.
Para empezar, en breve postearé un poco sobre programación de sockets y RPC, que es lo que más reciente tengo. También tengo pendiente presentarme, no lo olvido. Y pondré una lista de temas TO-DO para que no se me pase nada.
Aaaaaadios!
ha habido que dejar alguna asignatura para septiembre, pero eso es lo de menos. Todo el verano por delante para cambiar el chip y pasar de estudiar informática a aprender informática.
Para empezar, en breve postearé un poco sobre programación de sockets y RPC, que es lo que más reciente tengo. También tengo pendiente presentarme, no lo olvido. Y pondré una lista de temas TO-DO para que no se me pase nada.
Aaaaaadios!
Saturday, June 9, 2007
Por no estudiar
He descubierto un jueguecito en flash que me ha tenido hipnotizado durante varias horas, mi consejo es que no pinchéis en el link... Si habéis jugado a un mapa Matrix en battle.net veréis la genialidad del invento.
Por otro lado, he estado toqueteando el photoshop, como siempre modo autodidacta y he hecho una imagen maja para el blog, un efecto "bola de cristal" o al menos eso intentaba, jeje. Me he basado vagamente en este tutorial, aunque para una bola sin un fondo detrás me ha resultado algo más complicado.
Eso ha sido lo que me ha impedido estudiar los exámenes este día, ya veré que encuentro mañana. Aunque también podría estudiar de verdad y en serio...
Por otro lado, he estado toqueteando el photoshop, como siempre modo autodidacta y he hecho una imagen maja para el blog, un efecto "bola de cristal" o al menos eso intentaba, jeje. Me he basado vagamente en este tutorial, aunque para una bola sin un fondo detrás me ha resultado algo más complicado.
Eso ha sido lo que me ha impedido estudiar los exámenes este día, ya veré que encuentro mañana. Aunque también podría estudiar de verdad y en serio...
Thursday, June 7, 2007
El fenómeno de RSS
Pues vaya... uno se esperaba más después de tanta expectación. Resulta que el famoso RSS no es más que un resumen de una web. Un resumen ordenadito, en XML, bien definido y accesible, pero un resumen al fin y al cabo.
Básicamente, alguien con una web interesante crea el archivo XML con un resumen de las ultimas entradas de la web y publica que ese archivo existe para que la gente pueda acceder a él (una esquinita de la propia página sería un buen lugar para eso). Mas tarde, cada vez que agregue algo nuevo a su web, actualiza el XML con el nuevo contenido. Así, la gente no tiene porqué navegar hasta su página sino que accediendo al archivo XML (con un programa especifico, o una web que lo permita, p. ej. iGoogle) lee lo que hay de nuevo y mira si le interesa. Dicho así es una chorrada, pero la gracia está en evitar mirar 20 webs al día sino que mirar el lector de feeds y localizar de un vistazo lo que te interesa. Otro formato para ello (y que se usa en blogger.com) es Atom, que por lo visto es mejor por las razones que se indican en la Wikipedia.
Por supuesto la gran mayoría de feeds son automáticos, como en el caso de blogger: tu escribes un post en el blog y los monos entrenados reescriben el XML para incluir la nueva info. Para sitios sin monos entrenados, se puede usar estos, que los alquilan baratos y no consumen muchos plátanos ;)
Si quereis saber más sobre el tema, hay varias páginas bastante buenas. La primera es una pagina en español dedicada a la temática con algún enlace a herramientas y demás. Para una explicación general de toda la familia de formatos nada mejor que la de microsiervos. Aunque para algo fácil claro y simple, yo me quedo con esta pagina sobre el tema con un ejemplo paso a paso de como crear un feed. Y los ingleses tampoco se lo montan mal... Por último una página bastante exhaustiva para quien quiera los detalles y un tutorial todo-en-uno.
PD: para un feed con los contenidos de este blog, usad esta url.
Saludos!
Básicamente, alguien con una web interesante crea el archivo XML con un resumen de las ultimas entradas de la web y publica que ese archivo existe para que la gente pueda acceder a él (una esquinita de la propia página sería un buen lugar para eso). Mas tarde, cada vez que agregue algo nuevo a su web, actualiza el XML con el nuevo contenido. Así, la gente no tiene porqué navegar hasta su página sino que accediendo al archivo XML (con un programa especifico, o una web que lo permita, p. ej. iGoogle) lee lo que hay de nuevo y mira si le interesa. Dicho así es una chorrada, pero la gracia está en evitar mirar 20 webs al día sino que mirar el lector de feeds y localizar de un vistazo lo que te interesa. Otro formato para ello (y que se usa en blogger.com) es Atom, que por lo visto es mejor por las razones que se indican en la Wikipedia.
Por supuesto la gran mayoría de feeds son automáticos, como en el caso de blogger: tu escribes un post en el blog y los monos entrenados reescriben el XML para incluir la nueva info. Para sitios sin monos entrenados, se puede usar estos, que los alquilan baratos y no consumen muchos plátanos ;)
Si quereis saber más sobre el tema, hay varias páginas bastante buenas. La primera es una pagina en español dedicada a la temática con algún enlace a herramientas y demás. Para una explicación general de toda la familia de formatos nada mejor que la de microsiervos. Aunque para algo fácil claro y simple, yo me quedo con esta pagina sobre el tema con un ejemplo paso a paso de como crear un feed. Y los ingleses tampoco se lo montan mal... Por último una página bastante exhaustiva para quien quiera los detalles y un tutorial todo-en-uno.
PD: para un feed con los contenidos de este blog, usad esta url.
Saludos!
Subscribe to:
Posts (Atom)
