ntop es la herramienta más popular y completa para monitorizar el tráfico de una red cuando nos interesa, no sólo conocer la magnitud del mismo sino su procedencia y características. Colocado en un punto estratégico de nuestra red nos sirve para detectar cualquier tipo de anomalía en la misma. Si lo instalamos en un servidor nos sirve para auditar el tipo de tráfico que este emite y recibe de forma gráfica y muy didáctica.

Como ocurre en algunas ocasiones la versión en la paquetería de debian (4.0.33 en la estable y 4.99.3 en testing y unstable) va bastante por detrás de la del producto (5.0.1) así que si te apetece jugar con lo último lo mejor es bajarte los fuentes y compilarlos en tu máquina. Pero ya sabes que, en este caso, tendrás que preocuparte de posibles actualizaciones de forma manual. ntop, en particular, no parece tener ningún aviso automático de la aparición de nuevas versiones. Vamos a ello.

Antes que nada, instalamos los paquetes necesarios para realizar la instalación, las dependencias y alguna otra cosa necesaria:

1

apt-get install build-essential libtool automake autoconf libpcap-dev libgdbm-dev zlib1g-dev rrdtool librrd-dev libssl-dev python-dev libgeoip-dev graphviz libgraphviz-dev subversion python-pip

A continuación nos descargamos de aquí la última versión estable de ntop, la copiamos en, por ejemplo, el directorio /tmp de nuestra máquina y la descomprimimimos

1
2

wget -c http://sourceforge.net/projects/ntop/files/ntop/Stable/ntop-5.0.1.tar.gz/download
tar xvfz download

Ahora entramos al directorio donde se han descomprimido los fuentes (ntop-5.0.1 en este caso) y generamos los binarios.

1
2
3
4
5

cd ntop-5.0.1/
./autogen.sh
make
make install
ldconfig

Y listo. Sólo nos quedan unos cuantos retoques. Los datos que ntop capture una vez esté en funcionamiento se guardarán en /usr/local/var/ntop. El daemon de ntop se ejecuta con el usuario nobody, así que debemos de hacerlo propietario de dicho directorio para que pueda escribir libremente en él:

1

chown -R nobody /usr/local/var/ntop

El binario de ntop ya está listo para ejecutarse y se encuentra en el directorio /usr/local/bin. Si escribes ntop -help tendrás una detallada lista de posibles opciones. Las mías son estas:

1

/usr/local/bin/ntop -i eth0 -w 3001 -L -d

De esta forma ntop monitorizará todo el tráfico enviado y recibido por el interfaz de red eth0 de nuestra máquina, el interface web de ntop escuchará peticiones en el puerto 3001 (por defecto lo haría en el 3000), guardará los mensajes de log en el syslog de la máquina (/var/log/syslog) y se ejecutará como daemon o servicio en segundo plano.

En la primera ejecución nos pedirá que introduzcamos la contraseña para el usuario admin necesaria para entrar a ciertas páginas restringidas del programa. Muy pocas, la verdad, pero luego veremos como solucionar esto. Para acceder a ntop ya sólo tenemos que ir a nuestro navegador y escribir lo siguiente sustituyendo ip-de-la-maquina por la dirección o nombre correcto donde hemos hecho la instalación y cambiando el puerto por el adecuado si lo hemos modificado en la orden de inicio anterior:

1

http://ip-de-la-maquina:3001

Para proteger el acceso a cualquier página de ntop (imprescindible sobre todo si es visible desde Internet) debemos de entrar en el menú superior (Admin -> Configure -> Protect URLs) y añadir una regla con un asterisco ‘*’ al limitado grupo de usuarios que deseemos (o al usuario admin si es una instalación de uso particular).

Ahora ya sólo nos quedan unos pequeños ajustes para disponer de algunos gráficos y diagramas adicionales que, por defecto, no vienen configurados. El plugin Round-Robin Database debería de estar activado para disponer de los gráficos de Network Load generales o por protocolo.

Para ello, además de activar el plugin (Plugins -> Round-Robin Database -> Activate), deberíamos de comprobar que en la pantalla de Preferencias (Admin -> Configure -> Preferences) la cadena rrd.rrdPath apunta a un directorio donde el usuario nobody tenga permisos de escritura (típicamente /usr/local/var/ntop/rrd), que en la configuración del plugin (Plugins -> Round-Robin Database -> Configure) las dos cadenas del bloque RRD Files Path apuntan al mismo directorio y que en el bloque Data to Dump de esta misma pantalla tenemos seleccionada, al menos, la opción de Interfaces. Si seleccionamos todas las opciones tendremos muchos más datos de captura pero a costa de cargar más la ejecución y el espacio ocupado por las capturas. Mucho cuidado con el espacio en disco, que podemos necesitar fácilmente 2 Gigas por día en un servidor con un tráfico corrientito.

Para ver los mapas por regiones tenemos que instalar las plantillas Mako para python. Como al principio de todo hemos instalado el paquete python-pip nos basta con salir a línea de comandos y ejecutar lo siguiente:

1

pip install Mako

Por último, aunque hemos instalado graphviz y Dot es uno de sus elementos integrantes, nos hace falta añadir un path en las Preferencias (Admin -> Configure -> Preferences) para disponer de los Mapas de Tráfico de Red Locales. Entramos en ellas y, al final de la tabla, añadimos la cadena dot.path con el valor /usr/bin/dot. Pulsamos Add, confirmamos y listo.

ntop tiene muchas otras gráficas y páginas de información útil e interesante además de estas que he mostrado y cuyo único motivo para aparecer aquí es que necesitan de algún retoque extra en la configuración para poder usarlas, así que lo mejor es que las explores una a una. La documentación para interpretarlas es escasa, todo hay que decirlo, pero últimamente se están poniendo las pilas en este sentido y han prometido, por fin, un manual de usuario en breve.

Y ya sólo nos queda un pequeño detalle para concluir. Si quieres que ntop se ejecute de forma automática como servicio cada vez que hagas un reinicio de la máquina donde la tienes instalada sólo tienes que crear un fichero .sh (por ejemplo ntop.sh) con la línea de ejecución que has usado antes para ponerlo en marcha, crear un enlace al mismo en el directorio init.d y ejecutar lo siguiente:

1
2

ln -s /opt/Scripts/ntop.sh /etc/init.d/ntop
update-rc.d ntop defaults 99

Hace poco contamos por aquí como instalar la última versión de OpenVAS en Fédora. Si prefieres trabajar con Ubuntu o una distribución derivada puedes seguir lo que se cuenta en ese mismo post salvo en algunos pequeños detalles:

• La instalación manual se hace descargando los paquetes desde esta dirección si usamos arquitectura i386 o desde este otra si nuestro sistema está compilado para 64 bits.
• Si queremos integrar el repositorio en nuestro sistema debemos de añadir la siguiente línea en nuestro fichero de fuentes de software (/etc/apt/sources.list):

  1	deb http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/xUbuntu_11.04/ ./

• Para añadir la firma de autenticación de los paquetes ejecutamos lo siguiente:

  1	sudo apt-key adv --keyserver hkp://keys.gnupg.net --recv-keys BED1E87979EAFD54</code>

• Ahora ya podemos instalar. Primero actualizamos la base de datos de paquetes (sudo apt-get update) y luego, si queremos una instalación que integre cliente y servidor en la misma máquina, ejecutamos lo siguiente:

  1	sudo apt-get install libopenvas4 libmicrohttpd10 openvas-scanner openvas-manager openvas-administrator greenbone-security-assistant gsd openvas-cli sqlite3

  Si sólo queremos la parte de servidor:

  1	sudo apt-get install libopenvas4 libmicrohttpd10 openvas-scanner openvas-manager openvas-administrator greenbone-security-assistant sqlite3

  Y para instalar sólo el cliente:

  1	sudo apt-get install libopenvas4 gsd openvas-cli

• Y ya casi. El último punto que nos falta a tener en cuenta es que los ficheros de configuración se encuentran aquí en el directorio /etc/default, así que será aquí donde tendremos que hacer las modificaciones necesarias para habilitar la conexión del cliente desde otra máquina si queremos una instalación distribuida.

OpenVAS es un scanner de vulnerabilidades de red de código abierto creado a partir de un fork de la versión 2 de Nessus que se convirtió en código propietario en su versión 3, allá por el año 2005. Si queremos instalar la última versión de OpenVAS, la 4, disponible en fase beta desde diciembre de 2010, tenemos que hacerlo manualmente. Existen indicaciones de como hacerlo para diferentes distribuciones en esta dirección pero, a mi parecer, son difíciles de seguir para quién no está bien familiarizado con la arquitectura que usa esta herramienta, he detectado algunos errores y no explican, por ejemplo, algo tan básico como la forma de realizar una instalación distribuida cliente-servidor que es uno de los puntos fuertes de la herramienta. Así que vamos allá.

ACTUALIZACIÓN: Desde el día 17 de marzo la versión 4 es ya definitiva (ya es casualidad que lo tuviera escrito desde una semana antes y que no mirara la lista de correo hasta días después ¿eh?). El procedimiento de instalación aquí descrito sigue siendo válido y si lo has seguido usando los repositorios se te habrán actualizado los últimos cambios de forma automática.

Para disponer de los paquetes necesarios podemos hacer dos cosas, descargarlos manualmente (de esta dirección si usas arquitectura de 64 bits o de esta otra si usas arquitectura i386) e instalarlos con rpm (o yum con la opción --localinstall) o, mucho más recomendable, añadir un nuevo repositorio a tu máquina para recibir las futuras actualizaciones. En este segundo caso debes de crear un nuevo archivo .repo (por ejemplo openvas.repo) en tu directorio /etc/yum.repos.d y copiar en él lo siguiente (o bajártelo diréctamente desde aquí):

1
2
3
4
5
6
7

[security_OpenVAS_STABLE_v4]
name=security:OpenVAS:STABLE:v4 (Fedora_14)
type=rpm-md
baseurl=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/
gpgcheck=1
gpgkey=http://download.opensuse.org/repositories/security:/OpenVAS:/STABLE:/v4/Fedora_14/repodata/repomd.xml.key
enabled=1

Lo siguiente que tenemos que hacer es decidir que instalar. Cómo decíamos antes, OpenVas tiene una estructura cliente servidor de forma que la parte del programa que realiza el escaneo propiamente dicho puede instalarse en una máquina diferente a aquella desde la que se lanza y monitoriza el análisis o, incluso, distribuirlo entre varias para aliviar la carga. Tenemos, así, la posibilidad de instalar servidores en diferentes puntos estratégicos de nuestra red y usar siempre el cliente desde nuestro ordenador de trabajo. Existe una detallada descripción de la arquitectura que se usa en esta dirección pero si no te interesa meterte en tantos detalles, échale al menos un vistazo a esta imagen para comprender lo que sigue:

El servidor de OpenVAS está formado por tres módulos (scanner, manager y administrator) y disponemos de tres posibles clientes para explotarlos: uno en línea de comando (openvas CLI), otro con una aplicación clásica de escritorio que usa las librerías qt4 (greenbone security desktop o gsd) y una tercera posibilidad que es acceder directamente a través de un navegador usando, para ello, el módulo denominado greenbone security assistant.

Y vamos a instalar. Si queremos hacer una instalación completa (cliente y servidor) en la misma máquina y estamos usando el repositorio que hemos puesto anteriormente, tenemos que instalar (recordad, como usuario root) los siguientes paquetes:

1

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant gsd openvas-cli

Si lo que queremos es hacer una instalación sólo con la parte de servidor y, además, tener la posibilidad de conectarnos usando un navegador como cliente, instalaríamos lo siguiente:

1

sudo yum install sqlite nmap libopenvas4 libmicrohttpd10  openvas-scanner openvas-manager openvas-administrator  greenbone-security-assistant

Si queremos instalar sólo el cliente en línea de comandos:

1

sudo yum install libopenvas4 openvas-cli

Y, por último, si sólo quisieramos instalar la aplicación cliente de escritorio:

1

sudo yum install libopenvas4 gsd

Instalación completada. Ahora hay que poner esto en marcha. Si hemos realizado una instalación distribuida (servidor en una máquina y cliente en otra) lo primero que tenemos que hacer es unos cambios en la configuración del servidor ya que este, por defecto, arranca los servicios usado el parámetro --listen=127.0.0.1 de forma que no admite conexiones que no vengan de la propia máquina. Para corregir esto procedemos de la siguiente forma:

Si lo que queremos es poder conectarnos al servidor a través de un navegador web desde otra máquina, debemos de editar el fichero /etc/sysconfig/greenbone-security-assistant y localizar las siguientes líneas:

1
2
3
4
5

GSA_ADDRESS=127.0.0.1
...
ADMINISTRATOR_ADDRESS=127.0.0.1
...
MANAGER_ADDRESS=127.0.0.1

En el fichero original no aparecen todas así una debajo de otra ¿eh? Bien, pues lo único que tenemos que hacer es sustituir el 127.0.0.1 por la ip real de la máquina que actúa como servidor.

Si lo que queremos es usar el cliente de escritorio gsd desde otra máquina, el fichero que debemos de editar es /etc/sysconfig/openvas-manager. Localizamos ahora la siguiente línea y hacemos la misma operación que hemos descrito antes:

1

MANAGER_ADDRESS=127.0.0.1

¿Continuamos? Lo siguiente (aún en el servidor) sería añadir un primer usuario con privilegio de administrador (cualquiera de los clientes nos pedirá autenticación antes de darnos acceso). El siguiente comando nos creará un usuario llamado josemaria y nos pedirá de forma interactiva la contraseña para este:

1

sudo openvasad -c add_user -n josemaria -r Admin

A continuación generamos los certificados que también usaremos en la autenticación:

1

sudo openvas-mkcert -q<br/>sudo openvas-mkcert-client -n om -i

Y ya casi estamos. Para quién no lo conozca, un programa como este que analiza vulnerabilidades se parece en algunos aspectos a un antivirus: alguien tiene que actualizar de forma permanente que nuevas vulnerabilidades existen y de que forma reconocerlas. Al igual que actualizamos las “firmas” de nuestro antivirus necesitamos actualizar estos patrones de reconocimiento que en OpenVAS reciben el nombre de NVT’s Es por lo tanto necesaria una sincronización periódica. El siguiente script podría servirnos para ello. Además de la sincronización realiza la activación de servicios en el orden correcto de forma que deberíamos de usarlo antes de la primera conexión y después de cada reinicio de la máquina con el servidor:

1
2
3
4
5
6
7
8
9
10
11
12

sudo openvas-nvt-sync
sudo service openvas-manager stop
sudo service openvas-scanner stop
sudo openvassd
sudo openvasmd --migrate
sudo openvasmd --rebuild
sudo service openvas-administrator stop
sudo service openvas-manager stop
sudo service openvas-scanner restart
sudo service openvas-manager start
sudo service openvas-administrator start
sudo /etc/init.d/greenbone-security-assistant restart

Y con esto está todo. Si queremos asegurarnos o posteriormente cuando lancemos un cliente tenemos algún problema, existe un pequeño script que podemos descargar desde aquí y que, ejecutado con privilegios de root, nos permite verificar si nuestra instalación está correcta o, por el contrario, nos alertaría acerca de que es lo que nos falta. Si lo ejecutamos con el parámetro --server obviaría en esta comprobación todo lo referente a la instalación del cliente.

Ahora ya podemos empezar a auditar la red. El cliente de escritorio no crea entrada en ningún menú, así que lo tenemos que ejecutar a mano (pulsando Alt+F2 o directamente desde un terminal) con el comando gsd. En las siguientes ilustraciones se ve la pantalla de conexión y la principal del programa

Si preferimos usar el cliente web (mucho más ligero, la verdad) “apuntamos” con nuestro navegador al puerto 9392 de la máquina donde hemos instalado el servidor usando protocolo seguro https (por ejemplo https://192.168.1.217:9392 o https://localhost:9392 en caso de que lo tengamos todo en la misma máquina). A continuación tienes también los pantallazos de la ventana de login y la principal del cliente:

ACTUALIZACIÓN: En systenadmin nos cuentan como instalarlo en una Cent.OS además de algunas notas útiles sobre el escalado de eventos y la sobreescritura de alertas para evitar falsos positivos recurrentes.

ACTUALIZACIÓN (y II): y si prefieres instalarlo en Ubuntu échale un vistazo a estas notas adicionales.

Se acaba de presentar al público Intypedia, una enciclopedia visual de la Seguridad. Se trata de un proyecto de Criptored que ofrecerá vídeos educativos sobre esta materia.

Por el momento sólo hay dos entradas: un vídeo introductorio y una primera entrega (incrustada aquí abajo) sobre la historia de la criptografía y su desarrollo en Europa, pero en las próximas entradas contará con nombres como Arturo Ribagorda de la Universidad Carlos III o Gonzalo Álvarez Marañón del CSIC (¿recordais el Criptonomicón?)

Las entregas se acompañan de ejercicios (propuestos y resueltos) lo cual facilita muchísimo el uso de este material en la enseñanza. En el correo de presentación en Una al Día reproducen una nota de prensa con mucha más información sobre este proyecto.

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
     AuthMYSQL on
     AuthMySQL_Authoritative on
     Auth_MySQL_Host localhost
     AuthMySQL_DB httpdauthmysql
     AuthMySQL_Password_Table usuarios
     Auth_MySQL_User apacheauth
     Auth_MySQL_Password 4pache3Sql
     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.

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>