Apache
Sumario
- 1 Enlaces y referencias
- 2 Módulos
- 3 Recetario
Enlaces y referencias
Módulos
mod_autoindex
- Ref: mod_autoindex
Este módulo permite exponer una relación de archivos y directorios desde el servidor web. Para activarlo en un directorio o localización se debe emplear la opción Indexex puesto que el módulo ya está incluído en la base del servidor.
Dispone de varias opciones que alteran la información que presenta:
<Directory /docs>
# Activamos el listado de archivos
Options +Indexes
# Ancho variable para el nombre de los archivos
IndexOptions DescriptionWidth=*
# Mostrar antes las carpetas
IndexOptions FoldersFirst
# Ordenar sin distinguir mayúsculas de minúsculas
IndexOptions IgnoreCase
# Archivo de cabecera en todas las páginas
HeaderName HEADER.html
# Descripciones alternativas a documentos concretos
AddAlt "Documento PDF" *.pdf
</Directory>
Recetario
Forzar conexión segura
Empleando mod_rewrite se puede incluir una estrofa como la siguiente:
# redirect to https when available (thanks omen@descolada.dartmouth.edu)
RewriteEngine on
RewriteCond %{HTTPS} !^on$ [NC]
RewriteRule . <nowiki>https://%{HTTP_HOST}%{REQUEST_URI}</nowiki> [L]
Proteger con contraseña
Ref: Apuntes personales en taquiones.net
Incluir la siguiente estrofa en el recurso que se quiera proteger:
AuthType Basic
AuthName "Password Required"
AuthUserFile /etc/apache/passwd/users
AuthGroupFile /etc/apache/passwd/groups
Require Group admins
crear el archivo de contraseñas de esta forma
# htpasswd -c /etc/apache/passwd/users victor
New password:
Re-type new password:
Adding password for user victor
#
y el de grupos de esta otra:
# echo "admin: victor" >> /etc/apache/passwd/groups
Definir nombre del servidor
Emplear la directiva ServerName en la configuración principal así como en cada host virtual. En caso contrario Apache intenta una resolución inversa DNS con los resultados que pueden llegar a esperarse. De esta forma también es posible indicar el número de puerto sin ninguna duda.
ServerName taquiones.net:80
Esto soluciona la advertencia que aparece cuando los certificados digitales (a través del campo CommonName) no coinciden con el nombre del servidor.
[Thu Nov 04 14:47:16 2010] [warn] RSA server certificate CommonName (CN) `taquiones.net' does NOT match server name!?
Incluir archivos en la configuración
Una manera sencilla y normalizada de incluir en copia archivos de configuración es emplear la directiva include:
Include /etc/apache2/sites-conf/esferas.org/[^.#]*.conf
Y de esta forma sólo se cargan los archivos cuyo nombre no comience por un punto, el carácter almohadilla (#) y tengan la extensión .conf.
Red interior y red exterior
- Ref: Mezclando host virtuales con nombre e IP
- Ref: Ejemplos de host virtuales en la documentación oficial
Si un servidor Apache está situado entre la red interior (la intranet) y la red exterior (Internet) y debe servir el mismo contenido pero con diferentes configuraciones de seguridad se pueden usar secciones VirtualHost para encauzar el tráfico.
Conviene echarle un vistazo a los ejemplos para ver cuánto pueden dar de sí las diferentes combinaciones; aquí me limito a anotar un caso real.
Tenemos un wiki instalado en un ordenador fronterizo en la dirección http://example.com/wiki y queremos que sirva el mismo contenido para la intranet que para el exterior, pero en éste último caso necesitamos que esté protegido por contraseña y usuario. Es más, no queremos que la identificación se realice en claro, así que también es necesaria una conexión segura con el servidor antes de pedir las credenciales.
Dado que no queremos incluir módulos extras ni escribir programas específicos nos limitamos a establecer un par de reglas cuando se accede al directorio /wiki:
- Si la conexión es segura siempre se solicita autentificación.
- Si la conexión no es segura y procede del exterior siempre se redirige a una conexión segura.
Conexión en claro
La estrofa es bastante simple y se emplea mod_rewrite para verificar desde dónde llega la petición.
# Forzamos una conexión segura si la petición procede de
# fuera y quiere acceder al url /wiki
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^192\.168\.0
RewriteCond %{REQUEST_URI} ^/wiki
RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L]
# Configuración para mediawiki
Alias /wiki /var/www/w/index.php
...
Conexión cifrada
En este caso la configuración es prácticamente la misma sólo que protegemos con contraseña el acceso al directorio principal del wiki.
Alias /wiki /var/www/w/index.php
<Directory /var/www/w>
Options +FollowSymLinks
AllowOverride All
order allow,deny
allow from all
AuthType Basic
AuthName "Acceso al wiki"
AuthUserFile /etc/apache2/passwd/passwords
AuthGroupFile /etc/apache2/passwd/group
Require valid-user
</Directory>
...
Host virtuales y redirecciones
También nos encontramos con que anteriormente el acceso al wiki se realizaba en la dirección http://wiki.example.net/, luego se trasladó a http://wiki.example.com y ahora queremos que ambas direcciones lleven al mismo sitio: http://example.com/wiki. Sin embargo no vamos a respetar la equivalencia de direcciones y los dominios de tercer nivel wiki. sólo servirán como punto de entrada a la página principal del wiki; es decir, el URL http://wiki.example.com/Hardware ya no se corresponderá con http://example.com/wiki/Hardware.
La razón de esta decisión está en la documentación de mediawiki, donde los autores aconsejan no emplear dominios específicos para el wiki por su falta de portabilidad entre instalaciones, ya que las referencias intra e inter wikis se romperían en caso de cambiar de dominio de segundo nivel.
La configuración de ambos dominios debe ser distinta a la fuerza. example.net reside en el servidor fronterizo por lo que las peticiones pueden llegarle tanto del interior como del exterior, mientras que el dominio example.com está situado en una máquina en el exterior y todos los accesos a la misma se consideran externos.
Para la máquina exterior la cuestión es simple, una configuración virtual que cubra las dos posibilidades y siempre redireccione al mismo sitio.
#
# wiki.example.com
#
<VirtualHost *:80>
ServerName wiki.example.com
ServerAdmin webmaster@example.com
Redirect permanent / https://example.net/wiki
</VirtualHost>
<VirtualHost *:443>
ServerName wiki.example.com
ServerAdmin webmaster@example.com
Redirect permanent / https://example.net/wiki
</VirtualHost>
Para la configuración exterior la configuración no es mucho más complicada puesto que redireccionamos siempre hacia el dominio principal y es allí donde se realizan las diferentes comprobaciones de origen.
#
# wiki.example.net
#
<VirtualHost *:80>
ServerName wiki.example.net
ServerAdmin webmaster@example.net
Redirect permanent / http://example.net/wiki
</VirtualHost>
<VirtualHost *:443>
ServerName wiki.example.net
ServerAdmin webmaster@example.net
Redirect permanent / https://example.net/wiki
</VirtualHost>
Depuración de errores
Para buscar errores durante el arranque del servidor, errores graves que abortan el proceso y no dejan el rastro habitual se puede emplear lo siguiente:
$ sudo apache2ctl -X -e debug -k start
Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module alias_module
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module auth_basic_module
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module authn_file_module
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module authz_default_module
...
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module status_module
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module userdir_module
[Fri Jan 14 09:13:52 2011] [debug] mod_so.c(246): loaded module wsgi_module
Los parámetros empleados son:
-X: activa el modo de depuración que consiste en arrancar un único proceso trabajador (worker en la jerga) y no desacoplarse del terminal para convertirse en demonio.-e debug: muestra los errores de arranque al nivel indicado.-k start: activa el arranque del servidor.
Se emplea el programa auxiliar apache2ctl porque prepara el entorno correspondiente y adecuado para el servidor y dispone de ese modo transparente en el que pasa todos los parámetros recibidos al nuevo servidor.
Acceso restringido por IP dinámica
Extraído del primer enlace, la siguiente estrofa establece una forma de control dinámico según direcciones IP almacenadas en un archivo de texto plano. Este archivo se recarga cada vez que cambia su sellado de mofidicación, pero también es posible indicar un programa externo que efectúe la consulta y retorne una dirección válida.
RewriteEngine On
RewriteMap isplist txt:/path/to/whitelist.txt
RewriteCond %{REMOTE_ADDR} ^(.*)$
RewriteCond ${isplist:%1|black} ^black$ [NC]
RewriteRule (.*) - [F]
La estrofa define un mapa al que llama isplist y añade dos condiciones:
- Comprueba que exista una dirección IP remota
- Busca esa dirección (%1) en el mapa de direcciones permitidas (ignorando mayúsculas y minúsculas).
Si no la encuentra emplea el valor por defecto black y comprueba que coincida en la misma condición.
Como se han cumplido las dos condiciones la regla de reescritura finalmente emite un código 403 con el indicador F.
- Comentario: Es un poco enrevesado pero hay que entender que la reescritura sólo se lleva a cabo si se han cumplido las dos condiciones anteriores. Es por eso que en la segunda fuerza a que se cumpla con el valor black y deja que las cosas fluyan.
Diferencias entre Apache 2.4 y 2.2
Control de acceso
Mezclar los dos tipos no es aconsejable pero tampoco está prohibido.
# En 2.2
Order allow,deny
Allow from all
# En 2.4
Require all granted
Cuando se combinan la autentificación y el control de acceso las diferencias son mayores:
#
# 2.2 configuration:
#
Order allow,deny
Deny from all
# Satisfy ALL is the default
Satisfy ALL
Allow from 127.0.0.1
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
Require valid-user
#
# 2.4 configuration:
#
AuthType Basic
AuthBasicProvider file
AuthUserFile /example.com/conf/users.passwd
AuthName secure
<RequireAll>
Require valid-user
Require ip 127.0.0.1
</RequireAll>
En ambos casos se deben cumplir todas las condiciones: filtrado por origen y por identificación de usuario.
