Usar un servidor de nombres en OpenSolaris

September 21, 2008 at 13:29 · Filed under OpenSolaris, Redes

Ayer tarde instalé OpenSolaris 2008.05 virtualizado sobre VMware Server en la Debian que uso habitualmente. El acceso a red lo configuré en VMware como NAT.

No hubo problemas que ahora mismo recuerde, excepto el uso de servidores DNS.

hacia mi ip (la averigüé con ifconfig -a) no hay problemas

hacia mi router (anfitrión/VMware) tampoco

hacia mi dirección para el anfitrión (VMware)

hacia el router de la LAN

Algo así como

Por defecto al instalar no había fichero

, que en Solaris, al igual que en Linux, también sirve para definir qué servidor(es) de nombres se utilizarán. Creé uno:

El

es como el

de Linux, más o menos, salvo que aquí nunca me pide mi password (supongo que será cuestión de la configuración por defecto).

Por lo demás se definen dos servidores de nombres: uno en mi red local (de la máquina anfitriona, sobre la que se está virtualizando), y otro en el exterior, en Internet.

Hasta aquí parecía resuelto:

[...]

Sin embargo al hacer

(p.ej.) no era capaz de resolver el nombre.

En Linux con añadir un

correcto suele bastar, pero eso es porque la configuración por defecto de la mayoría de las distribuciones dice que al resolver un nombre de dominio, primero se debe mirar en el fichero

y luego ya resolver el nombre de dominio si ahí no se encuentra.

Esa configuración viene definida en

(tanto en Linux como en OpenSolaris):

[...]

[...]

En esas dos líneas (

e

) originalmente sólo ponía “

” e “

“, por lo que tan sólo se buscaban en

las direcciones a resolver. Ahora se buscan primero ahí, y si no se encuentran se tratan de resolver por DNS, y si no lo consigue trata por último de usar mDNS.

No fue necesario en mi caso reiniciar ningún demonio ni nada más que modficiar esos dos ficheros. Con esos cambios pude navegar sin problemas desde Firefox y actualizar el IPS (

).

Comments

Redes de computadoras

February 11, 2008 at 13:59 · Filed under Libros, Redes

Un libro de uno de los míticos: Andy Tanenbaum. Junto con Silberschatz y Stallings creo que son la biblioteca básica de cualquier estudiante de ciencas de la computación.

800 y pico páginas, casi tan tocho como sus otros libros. Escrito en un tono muy cercano y ameno, y posiblemente gracias a esa forma de transmitir conocimiento le hayan dado el premio Karl V. Karlstrom.

El libro pretende ser una introducción a todo lo que es el campo de las redes de computadoras, tratando desde los niveles más bajos (sin mucha profusión) hasta los niveles más altos. Habla de normalización, de estándares y de las instituciones que se ocupan de ellos. Trata ligeramente el medio físico, procurando abarcar desde fibra óptica a satélites. A la capa de enlace le otorga casi doscientas páginas, para luego pasar a la capa de red. En la capa de red, aparte de algoritmos de enrutamiento, habla un poco de congestión y de calidad de servicio. Le siguen el nivel de transporte, protocolos del nivel de aplicación y seguridad en redes, donde repasa la criptografía simétrica y la de clave pública, además de hablar de certificados, SSL, PGP, S/MIME, IPsec, etc.

El libro es un must-read: una primera lectura sirve para introducirnos en (¿casi?) todos los temas de redes, lecturas posteriores como libro de referencia pueden ser útiles para reintroducirnos en algún aspecto en el que queramos trabajar, ya que además el libro finaliza con una extensa lista de bibliografía para profundizar más en ese tema en concreto.

Desde luego recomiendo su lectura, aunque cuesten las 800 páginas, tanto en términos de tiempo como de dinero (45 o 50 euros, aunque es fácil de encontrar en bibliotecas).

Comments

Pequeño parche para BlueZ/hcitool

February 11, 2008 at 13:33 · Filed under Bluetooth

Hace más de un mes trabajando con hcitool detecté lo que a mi juicio era un bug muy tonto y de fácil solución, así que me puse a ello, hice un parche y lo envié a los desarrolladores de BlueZ…

Copy+paste del mensaje que envié a la lista bluez-devel:

Hi! If I want to scan on hci0 the next sintax is bad, but hcitool
doesn't complain:
pablo@golgi:~$ hcitool hci0 scan
pablo@golgi:~$
(I better should use hcitool -i hci0 scan)

I've written a little patch to warn when an unrecognised command is given:

pablo@golgi:~/work/hcitool-patch1/utils/tools$ diff -u hcitool.c.orig
hcitool.c

--- hcitool.c.orig	2007-12-28 20:06:58.000000000 +0100
+++ hcitool.c	2007-12-29 11:35:00.000000000 +0100
@@ -2329,5 +2329,11 @@
 		command[i].func(dev_id, argc, argv);
 		break;
 	}
+
+	if(!command[i].cmd) {
+		fprintf(stderr, "\"%s\" isn't a valid command. Try --help for a list
of commands.\n", argv[0]);
+		exit(1);
+	}
+
 	return 0;
 }

Now, when I ask for an inexistent command it complains:
pablo@golgi:~$ ./hcitool nop scan
"nop" isn't a valid command. Try --help for a list of commands.
pablo@golgi:~$

If you find it useful, feel free to commit it.

Bye.

La verdad es que el parche es tontísimo y no sé si lo aplicarán, pero hay queda, por si a alguien le vale para algo. Me dio más guerra seguir el coding style que hacer el propio parche (por aquí va el hilo).

Update: me acabo de fijar que me dieron más indicaciones para el coding style de las que seguí (no las vi), razón adicional para omitir el parche.

Comments

Address changed – Reset device now

December 22, 2007 at 16:34 · Filed under Bluetooth

He adquirido un Bluetooth USB Adapter, es decir, un cacharro USB para conectarme por Bluetooth a otros chismes. Andaba tiempo detrás de uno, desde que empezó todo el tema del bluehacking.

Ayer tarde, cuando llegué con mi flamante Adapter de 17 euros –Conceptronic CBTU2, funciona perfecto en Linux hasta donde he probado– me puse a probarlo y a enredar con él. Al final acabé a las dos de la mañana habiendo leído la mitad del proyecto fin de carrera Seguridad en Bluetooth, de Alberto Moreno.

Uno de los ataques que se describen (dicho sea de paso, en la actualidad muy pocos de ellos son practicables) consiste en suplantar la identidad de otro dispositivo mediante el cambio de la MAC de nuestro adaptador Bluetooth.

Los interfaces Bluetooth tienen asociada una dirección unívoca cada uno de ellos. Bluetooth, de hecho, es el estándar IEEE 802.15 (ethernet es el 802.3, y wireless es el 802.11), por lo que las direcciones de Bluetooth son exactamente iguales que las Ethernet. Se trata de 48 bits, divididos en 24 superiores para indicar el OUI (identificador del fabricante del adaptador), y en 24 bits inferiores, para identificar el dispositivo fabricado por una determinada empresa. El espacio de direcciones se reparte por tanto, entre todas las normas 802.x que requieren direcciones MAC, por lo que no encontraremos un dispositivo Bluetooth con las misma MAC que una tarjeta inalámbrica o una ethernet.

El ataque llamado Blue MAC Spoofing se basa en los niveles de confianza en que se organiza el acceso a los servicios Bluetooth. Según sea el servicio, se podrá acceder tan sólo estando autorizado, o también estando autenticado.

Por estar autorizado se entiende que la MAC de tu adaptador Bluetooth está en la lista de MACs permitidas del receptor. La autenticación implica además el conocimiento de una clave compartida de 128 bits y una clave de sesión (un desafío de 128 bits). A partir de la dirección MAC propia, y esas dos claves se genera una respuesta de autenticación de 32 bits, que sirve para autenticarse ante el otro dispositivo.

Como hay servicios que tan sólo estando autorizados podemos utilizar, podemos dejar que sea otro dispositivo el que pase a ser autorizado, y luego suplantando su identidad, alcanzar su mismo nivel de privilegios. Supongamos un escenario donde una persona (A) le transfiere a otra conocida (B) un fichero (una fotografía, p.ej.). Si para poder hacer esta transferencia se necesita estar autorizado, al comenzar el móvil de B alertará y pedirá permiso para empezar a recibir la transmisión de A. Una vez que se le ha permitido la recepción (A y B son conocidos, y confían entre sí) la MAC de A pasa a la lista de autorizados de B. Si posteriormente cambiamos la MAC de nuestro dispositivo por la de A podremos hacernos pasar por A, heredando sus permisos.

El cambio de MAC se hace con la aplicación bdaddr, y no sé si funciona con todos los adaptadores (con el Conceptronic CBTU2 sí). Esta aplicación pareceser que viene en el paquete bluez-utils, aunque ahora mismo estoy con Debian SID actualizado y el paquete bluez-utils no cuenta con esa aplicación. Me he bajado el fuente de otro lado (aquí y acá) y he montado un .tar.bz2 con (casi) todo lo necesario para que compile el programa. Hay que tener instaladas las cabeceras en /usr/include/bluetooth/, y eso se consigue instalando el paquete libbluetooth-dev. Una vez bajado el bdaddr.tar.bz2, se descomprime y se compila:

Y se ejecuta:

O para cambiar la MAC, como root:

Lo de reset device hay que tomárselo al pie de la letra: he tenido que desenchufar y volver a enchufar el adaptador, la orden hciconfig hci0 reset no funcionó.

En principio con eso hemos cambiado la MAC (si hacéis un hciconfig hci0 veréis que ha cambiado). Pero, ¿cómo saber la MAC del dispositivo autorizado? Aún estoy en ello, pero me figuro que a base de hcidump se podrá sniffar el tráfico de la red y determinar qué MACs están autorizadas.

Más interesante aún sería automatizar todo esto de forma que permanentemente se esté analizando el tráfico del entorno, y se determine qué MACs establecen conexiones y son autorizadas.

Update (2007-12-29): Efectivamente con hcidump se puede esnifar el tráfico, pero el tráfico dirigido hacia ti. En Bluetooth no hay nada parecido al modo promiscuo de las tarjetas ethernet. Las tramas de bluetooth van saltando de canal en canal de forma seudoaleatoria. Predecir ese salto son palabras mayores (por lo menos para mí), y disponer de hardware que pueda seguir los saltos también. Lo explican en este hilo de la lista de desarrollo de Bluez. Desde luego esa idea de averiguar qué MACs se comunican con qué MACs es nada factible ahora mismo. De alguna forma hay que conseguir que la víctima se conecte con tú dispositivo bluetooth para hallar su MAC.

Comments (4)