Diferencia entre revisiones de «Apache»
mSin resumen de edición |
|||
Línea 2: | Línea 2: | ||
== Enlaces y referencias == |
== Enlaces y referencias == |
||
* |
* [https://httpd.apache.org/ Página principal del programa] |
||
== Módulos == |
== Módulos == |
||
Línea 8: | Línea 8: | ||
=== mod_autoindex === |
=== mod_autoindex === |
||
* |
* [https://httpd.apache.org/docs/2.2/mod/mod_autoindex.html 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 <code>Indexex</code> puesto que el módulo ya está incluído en la base del servidor. |
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 <code>Indexex</code> puesto que el módulo ya está incluído en la base del servidor. |
||
Línea 41: | Línea 41: | ||
=== Proteger con contraseña === |
=== Proteger con contraseña === |
||
Ref: Apuntes personales en taquiones.net |
|||
* [http://old.taquiones.net/sysadmin/htaccess.html Apuntes personales en taquiones.net] |
|||
Incluir la siguiente estrofa en el recurso que se quiera proteger: |
Incluir la siguiente estrofa en el recurso que se quiera proteger: |
||
Línea 54: | Línea 55: | ||
Re-type new password: |
Re-type new password: |
||
Adding password for user victor |
Adding password for user victor |
||
# |
# |
||
y el de grupos de esta otra: |
y el de [http://httpd.apache.org/docs/2.0/mod/mod_auth.html#authgroupfile grupos] de esta otra: |
||
# echo "admin: victor" >> /etc/apache/passwd/groups |
# echo "admin: victor" >> /etc/apache/passwd/groups |
||
Línea 65: | Línea 66: | ||
=== Incluir archivos en la configuración === |
=== Incluir archivos en la configuración === |
||
Una manera sencilla y normalizada de incluir en copia archivos de configuración es emplear la directiva include: |
Una manera sencilla y normalizada de incluir en copia archivos de configuración es emplear la directiva [http://httpd.apache.org/docs/2.2/mod/core.html#include include]: |
||
Include /etc/apache2/sites-conf/esferas.org/[^.#]*.conf |
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 (<code>#</code>) y tengan la extensión <code>.conf</code>. |
Y de esta forma sólo se cargan los archivos cuyo nombre no comience por un punto, el carácter almohadilla (<code>#</code>) y tengan la extensión <code>.conf</code>. |
||
Línea 71: | Línea 72: | ||
=== Red interior y red exterior === |
=== Red interior y red exterior === |
||
* |
* [http://docstore.mik.ua/orelly/weblinux2/apache/ch04_02.htm Mezclando host virtuales con nombre e IP] |
||
* |
* [http://httpd.apache.org/docs/2.0/vhosts/examples.html 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. |
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. |
||
Línea 86: | Línea 87: | ||
==== Conexión en claro ==== |
==== Conexión en claro ==== |
||
La estrofa es bastante simple y se emplea [[ |
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 |
# Forzamos una conexión segura si la petición procede de |
||
# fuera y quiere acceder al url /wiki |
# fuera y quiere acceder al url /wiki |
||
Línea 116: | Línea 117: | ||
</Directory> |
</Directory> |
||
... |
|||
==== Host virtuales y redirecciones ==== |
|||
También nos encontramos con que anteriormente el acceso al wiki se realizaba en la dirección <nowiki>http://wiki.example.net/</nowiki>, luego se trasladó a <nowiki>http://wiki.example.com</nowiki> y ahora queremos que ambas direcciones lleven al mismo sitio: <nowiki>http://example.com/wiki</nowiki>. Sin embargo '''no''' vamos a respetar la equivalencia de direcciones y los dominios de tercer nivel <code>wiki.</code> sólo servirán como punto de entrada a la página principal del wiki; es decir, el URL <code><nowiki>http://wiki.example.com/Hardware</nowiki></code> ya '''no''' se corresponderá con <code><nowiki>http://example.com/wiki/Hardware</nowiki></code>. |
|||
La razón de esta decisión está en la [http://www.mediawiki.org/wiki/Manual:Short_URL#Defaults 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 / <nowiki>https://example.net/wiki</nowiki> |
|||
</VirtualHost> |
|||
<VirtualHost *:443> |
|||
ServerName wiki.example.com |
|||
ServerAdmin webmaster@example.com |
|||
Redirect permanent / <nowiki>https://example.net/wiki</nowiki> |
|||
</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 / <nowiki>http://example.net/wiki</nowiki> |
|||
</VirtualHost> |
|||
<VirtualHost *:443> |
|||
ServerName wiki.example.net |
|||
ServerAdmin webmaster@example.net |
|||
Redirect permanent / <nowiki>https://example.net/wiki</nowiki> |
|||
</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: |
|||
Los parámetros empleados son: |
|||
* <code>-X</code>: 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. |
|||
* <code>-e debug</code>: muestra los errores de arranque al nivel indicado. |
|||
* <code>-k start</code>: activa el arranque del servidor. |
|||
Se emplea el programa auxiliar <code>apache2ctl</code> 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 === |
|||
* [http://stackoverflow.com/questions/4676954/dynamically-update-apache-config-allow-from-ip-without-a-restart-reload Dynamically update Apache config “allow from IP” without a restart/reload?] |
|||
* [http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap* RewriteMap] |
|||
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. |
|||
* [https://httpd.apache.org/docs/2.4/upgrading.html Upgrading to 2.4 from 2.2] |
Revisión del 07:37 23 abr 2024
Enlaces y referencias
Módulos
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
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
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:
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.