Diferencia entre revisiones de «Apache»

De Taquiones
(Página creada con « == Enlaces y referencias == * Ref: Página principal del programa == 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 <code>Indexex</code> 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>…»)
 
 
(No se muestran 2 ediciones intermedias del mismo usuario)
Línea 2: Línea 2:
== Enlaces y referencias ==
== Enlaces y referencias ==


* Ref: Página principal del programa
* [https://httpd.apache.org/ Página principal del programa]


== Módulos ==
== Módulos ==
Línea 8: Línea 8:
=== mod_autoindex ===
=== mod_autoindex ===


* Ref: 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 50: Línea 51:
Require Group admins
Require Group admins
crear el archivo de contraseñas de esta forma
crear el archivo de contraseñas de esta forma
<code># htpasswd -c /etc/apache/passwd/users victor
<# htpasswd -c /etc/apache/passwd/users victor
New password:
New password:
Re-type new password:
Re-type new password:
Adding password for user victor
Adding password for user victor
#</code>
#
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 63: Línea 64:
Esto soluciona la advertencia que aparece cuando los certificados digitales (a través del campo ''CommonName'') no coinciden con el nombre del servidor.
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!?
[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 [http://httpd.apache.org/docs/2.2/mod/core.html#include 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 (<code>#</code>) y tengan la extensión <code>.conf</code>.

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

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 <nowiki>http://example.com/wiki</nowiki> 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 . <nowiki>https://%{HTTP_HOST}%{REQUEST_URI}</nowiki> [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 <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]
[[Categoría:Apache]]
[[Categoría:Servidores]]
[[Categoría:Configuración]]
__FORZAR_TDC__

Revisión actual - 07:38 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:

  1. Comprueba que exista una dirección IP remota
  2. 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.

Obtenido de «https://wiki.taquiones.net/index.php?title=Apache&oldid=133»