Product SiteDocumentation Site

11.2. Servidor web (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Buster at version 2.4.38.

ALTERNATIVA Otros servidores web

Apache es simplemente el servidor web más conocido (y más utilizado), pero existen otros; pueden ofrecen mejor rendimiento bajo ciertos tipos de carga pero tienen la desventaja de una menor cantidad de funcionalidad y módulos disponibles. Sin embargo, cuando el servidor web en consideración es para proveer archivos estáticos o funcionar como proxy, vale la pena investigar las alternativas como nginx y lighttpd.

11.2.1. Instalación de Apache

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.
El uso de MPM en Apache afecta significativamente al manejo de las peticiones concurrentes. Con el worker MPM, se usan hilos (procesos ligeros) mientras que con prefork MPM usa un conjunto de procesos creados préviamente. Con el uso de event MPM tambien usa hilos pero las conexiones inactivas (las que se mantienen abiertas por la característica keep-alive de HTTP) son llevadas por el gestor de hilos dedicado.
The Falcot administrators also install libapache2-mod-php7.3 so as to include the PHP support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php7.3-fpm.

SEGURIDAD Ejecución bajo el usuario www-data

De forma predeterminada, Apache administra todas las peticiones entrantes bajo la identidad del usuario www-data. Esto significa que, en caso de una vulnerabilidad de seguridad en un script CGI ejecutado por Apache (para una página dinámica), no se comprometerá todo el sistema sino sólo los archivos que son propiedad de este usuario en particular.
Using the suexec modules, provided by apache2-suexec-* packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a SuexecUserGroup usergroup directive in the Apache configuration.
Otra posibilidad es utilizar un MPM dedicado, como el que provee el paquete libapache2-mpm-itk. Este MPM en particular tiene un comportamiento ligeramente diferente: permite «aislar» los servidores virtuales («virtual hosts») (actualmente, conjuntos de páginas) para que cada uno ejecute como un usuario diferente. Por lo tanto, una vulnerabilidad en un sitio web no puede comprometer los archivos que pertenecen al dueño de otro sitio web.

VISTA RÁPIDA Lista de módulos

The full list of Apache standard modules can be found online.
→ https://httpd.apache.org/docs/2.4/mod/index.html
Apache es un servidor modular y mucha funcionalidad está implementada por módulos externos que el programa principal carga durante su inicialización. La configuración predeterminada sólo activa los módulos más comunes, pero activar nuevos módulos es tan simple como ejecutar a2enmod módulo; similarmente, podrá desactivar un módulo ejecutando a2dismod módulo. En realidad, estos programas sólo crean (o eliminan) enlaces simbólicos en /etc/apache2/mods-enabled/ que apuntan a los archivos en sí (almacenados en /etc/apache2/mods-available/).

IN PRACTICE Checking the configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.
→ https://httpd.apache.org/docs/2.4/mod/mod_info.html
Con su configuración predeterminada, el servidor web escuchará en el puerto 80 (según se encuentra configurado en /etc/apache2/ports.conf) y servirá páginas del directorio /var/www/html/ (según se encuentra configurado en /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adding support for SSL

Apache 2.4 includes the SSL module (mod_ssl) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with a2enmod ssl, then the required directives have to be added to the configuration files. A configuration example is provided in /etc/apache2/sites-available/default-ssl.conf.
→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
If you want to generate trusted certificates, you can follow section Sección 10.2.1, “Creating gratis trusted certificates” and then adjust the following variables: 
SSLCertificateFile      /etc/letsencrypt/live/DOMAIN/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/DOMAIN/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem
SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt
Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:
→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache
As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls.
→ https://mod.gnutls.org/

11.2.3. Configuración de servidores virtuales («virtual hosts»)

Un servidor virtual es una identidad adicional para el servidor web.
Apache considera dos tipos distintos de servidores virtuales: aquellos basados en la dirección IP (o puerto) y aquellos basados en el nombre de dominio del servidor web. El primer método requiere reservar una dirección IP (o puerto) diferente para cada sitio, mientras que el segundo puede funcionar en sólo una dirección IP (y puerto) y se diferencian los sitios por el nombre enviado por el cliente HTTP (que sólo funciona en la versión 1.1 del protocolo HTTP — afortunadamente esta versión es suficientemente antigua para que todos los clientes ya lo utilicen).
La escasez (creciente) de direcciones IPv4 generalmente favorece el segundo método; sin embargo, es más complejo si los servidores virtuales también necesitan proveer HTTPS ya que el protocolo SSL no siempre se adecuó a los servidores virtuales basados en nombres; no todos los navegadores son compatibles con la extensión SNI (indicación de nombre de servidor: «Server Name Indication») que permite esta combinación. Cuando varios sitios HTTPS necesitan ejecutar en el mismo servidor, generalmente se diferenciarán bien por ejecutar en un puerto o en una dirección IP diferente (IPv6 puede ayudar).
La configuración predeterminada de Apache 2, activa servidores virtuales basados en nombre. Además, define un servidor virtual predeterminado en el archivo /etc/apache2/sites-enabled/000-default.conf; utilizará este servidor virtual si no se encuentra ningún servidor que coincida con el pedido enviado por el cliente.

PRECAUCIÓN Primer servidor virtual

Los pedidos que involucren un servidor virtual desconocido siempre serán gestionados por el primer servidor virtual definido, razón por la que definimos allí a www.falcot.com.

VISTA RÁPIDA Compatibilidad SNI de Apache

El servidor Apache es compatible con la extensión del protocolo SSL llamada indicación de nombre de servidor (SNI: «Server Name Indication»). Esta extensión permite al navegador enviar el nombre del servidor web durante el establecimiento de la conexión SSL, mucho antes del pedido HTTP en sí, lo que antes utilizaba para identificar el servidor virtual pedido entre aquellos que se encuentran en el mismo servidor (con la misma dirección IP y puerto). Esto le permite a Apache seleccionar el certificado SSL apropiado para que continúe la transacción.
Antes de SNI, Apache siempre proveía el certificado configurado en el servidor virtual predeterminado. Los clientes que intentaban acceder a otros servidores virtuales recibirían advertencias ya que el certificado que recibieron no coincidía con el sitio web que estaban intentando acceder. Afortunadamente, la mayoría de los navegadores ahora utilizan SNI; esto incluye Microsoft Internet Explorer a partir de la versión 7.0 (comenzando con Vista), Mozilla Firefox desde la versión 2.0, Apple Safari desde la versión 3.2.1 y todas las versiones de Google Chrome.
El paquete Apache proporcionado en Debian está compilado con soporte SNI; de modo que no es necesario ninguna configuración particular.
Luego puede describir cada servidor virtual adicional con un archivo almacenado en /etc/apache2/sites-available/. La configuración de un sitio web para el dominio falcot.org es tan simple como crear el siguiente archivo y luego habilitar el servidor virtual con a2ensite www.falcot.org.

Ejemplo 11.13. El archivo /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80>
ServerName   www.falcot.org
ServerAlias  falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>
El servidor Apache, como está configurado hasta ahora, utiliza los mismos archivos de registro para todos los servidores virtuales (puede cambiarlo agregando directivas CustomLog en las definiciones de servidores virtuales). Por lo tanto, tiene sentido personalizar el formato de este archivo de registro para incluir el nombre del servidor virtual. Puede hacerlo creando un archivo /etc/apache2/conf-available/customlog.conf que define un nuevo formato para todos los archivos de registro (con la directiva LogFormat) y habilitándolo con la orden a2enconf customlog. También debe eliminar (o comentar) la línea CustomLog del archivo /etc/apache2/sites-available/000-default.conf.

Ejemplo 11.14. The /etc/apache2/conf-available/customlog.conf file

# Nuevo formato de registro que incluye el nombre del servidor (virtual)
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Ahora utilicemos este formato de forma predeterminada
CustomLog /var/log/apache2/access.log vhost

11.2.4. Directivas comunes

Esta sección revisa brevemente alguna de las directivas de configuración de Apache más utilizadas.
El archivo de configuración principal generalmente incluye varios bloques Directory que permiten diferentes comportamientos del servidor dependiendo de la ubicación del archivo que está proveyendo. Tales bloques usualmente incluyen directivas Options y AllowOverride.

Ejemplo 11.15. Bloque Directory

<Directory /srv/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>
La directiva DirectoryIndex contiene una lista de archivos a intentar cuando el pedido del cliente es un directorio. El primer archivo de la lista que exista será utilizado y enviado como respuesta.
La directiva Options debe seguirse de una lista de opciones a activar. El valor None desactiva todas las opciones; correspondientemente, All las activa todas excepto MultiViews. Las opciones disponibles incluyen:
  • ExecCGI indicates that CGI scripts can be executed.
  • FollowSymlinks tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.
  • SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and the its target have the same owner.
  • Includes enables Server Side Includes (SSI for short). These are directives embedded in HTML pages and executed on the fly for each request.
  • IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.
  • Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).
  • MultiViews enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.

VOLVER A LOS CIMIENTOS Archivo .htaccess

El archivo .htaccess contiene directivas de configuración de Apache que aplican cada vez que un pedido involucra un elemento del directorio en el que se encuentra este archivo. El alcance de estas directivas también incluye a sus subdirectorios.
La mayoría de las directivas que pueden ocurrir en un bloque Directory también son válidas en un archivo .htaccess.
La directiva AllowOverride enumera todas las opciones que pueden ser activadas o desactivadas en un archivo .htaccess. Un uso común de esta opción es restringir ExecCGI para que los administradores puedan elegir los usuarios que podrán ejecutar programas bajo la identidad del servidor web (el usuario www-data).

11.2.4.1. Autenticación obligatoria

En algunas cirucunstancia necesitará restringir el acceso a partes de un sitio web, de forma que sólo usuarios legítimos que provean un nombre de usuario y una contraseña tengan acceso al contenido.

Ejemplo 11.16. Archivo .htaccess para autenticación obligatoria

Require valid-user
AuthName "Private directory"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

SEGURIDAD Sin seguridad

El sistema de autenticación utilizado en el ejemplo anterior (Basic) tiene una seguridad mínima ya que se envía la contraseña en texto plano (codificada sólamente con base64 que es sólo una codificación, no un método de cifrado). También debe saber que los documentos «protegidos» por este mecanismo también son enviados sin cifrar a través de la red. Si la seguridad es importante, debe cifrar la conexión HTTP completa con SSL.
The /etc/apache2/authfiles/htpasswd-private file contains a list of users and passwords; it is commonly manipulated with the htpasswd command. For example, the following command is used to add a user or change their password: 
# htpasswd /etc/apache2/authfiles/htpasswd-private usuario
New password:
Re-type new password:
Adding password for user usuario

11.2.4.2. Restricción de acceso

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).
→ https://httpd.apache.org/docs/2.4/howto/access.html
Puede usarse para restringir el acceso basado en varios criterios; Pararemos describiendo la restricción de acceso basada en la dirección IP del cliente, pero puede realizarse de un modo mucho más potente que eso, especificando varias directivas Require combinadas con un bloque RequireAll.

Ejemplo 11.17. Sólo permitir desde la red local

Require ip 192.168.0.0/16

ALTERNATIVA Sintaxis antigua

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.
Las directivas Allow from y Deny from controlan las restricciones de acceso a un directorio (y sus subdirectorios de forma recursiva).
La directiva Order le indica al servidor el orden en el que aplicar las directivas Allow from y Deny from; la última que coincida tiene precedencia. En términos concretos, Order deny,allow permite acceso si no coincide ninguna regla Deny from o si coincide una directiva Allow from. A la inversa, Order allow,deny rechaza el acceso si no coincide ninguna directiva Allow from (o si coincide una directiva Deny from).
A las directivas Allow from y Deny from le puede seguir una dirección IP, una red (como 192.168.0.0/255.255.255.0, 192.168.0.0/24 o inclusive 192.168.0), un nombre de equipo o nombre de dominio o la palabra clave all que incluye a todos.
Por ejemplo, para rechazar conexiones de forma predeterminada pero permitir las que provienen de la red local podría usar esto: 
Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.5. Analizadores de registros

Generalmente se instala un analizador de registros en un servidor web; ya que éste provee a los administradores una idea precisa sobre los patrones de uso del servidor.
Los administradores de Falcot Corp seleccionaron AWStats (estadísticas web avanzadas: «Advanced Web Statistics) para analizar sus archivos de registro de Apache.
El primer paso de configuración es personalizar el archivo /etc/awstats/awstats.conf. Los administradores de Falcot lo mantuvieron sin cambios más que los siguientes parámetros: 
LogFile="/var/log/apache2/access.log"
LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
SiteDomain="www.falcot.com"
HostAliases="falcot.com REGEX[^.*\.falcot\.com$]"
DNSLookup=1
LoadPlugin="tooltips"
Todos estos parámetros están documentados con comentarios en el archivo de la plantilla. En particular, los parámetros LogFile y LogFormat describen la ubicación y el formato del archivo de registros y la información que contiene; SiteDomain y HostAliases enumeran los varios nombres con los que se conocerá el sitio web principal.
En sitios con mucho tráfico, no debería definir DNSLookup como 1; para sitios más pequeños, como el de Falcot ya descripto, esta configuración permite conseguir reportes más legibles que incluyen nombres completos de equipos en lugar de sólo direcciones IP.

SEGURIDAD Acceso a las estadísticas

De forma predeterminada AWStats genera estadísticas disponibles en el sitio web sin restricciones, pero puede configurarlas para que sólo unas pocas direcciones IP (probablemente internas) puedan accederlas; necesita definir la lista de direcciones IP permitidas en el parámetro ALlowAccessFromWebToFollowingIPAddresses
AWStats también estará activo para otros servidores virtuales; cada servidor virtual necesita su propio archivo de configuración, como /etc/awstats/awstats.www.falcot.org.conf.

Ejemplo 11.18. Archivo de configuración de AWStats para un servidor virtual

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"
AWStats utiliza varios íconos almacenados en el directorio /usr/share/awstats/icon/. Para que éstos estén disponibles en el sitio web, necesita adaptar la configuración de Apache para incluir la siguiente directiva: 
Alias /awstats-icon/ /usr/share/awstats/icon/
Luego de unos minutos (y una vez que el script ejecutó varias veces), los resultados estarán disponibles en el sitio web:
→ http://www.falcot.com/cgi-bin/awstats.pl
→ http://www.falcot.org/cgi-bin/awstats.pl

PRECAUCIÓN Rotación de archivos de registro

Para que las estadísticas tengan en cuenta todos los registros, AWStats necesita ejecutar justo antes que se roten los archivos de registro de Apache. Teniendo en cuenta la directiva prerotate del archivo /etc/logrotate.d/apache2, puede solucionarlo agregando un enlace simbólico a /usr/share/awstats/tools/update.sh en /etc/logrotate.d/httpd-prerotate: 
$ cat /etc/logrotate.d/apache2
/var/log/apache2/*.log {
  daily
  missingok
  rotate 14
  compress
  delaycompress
  notifempty
  create 644 root adm
  sharedscripts
  postrotate
    if invoke-rc.d apache2 status > /dev/null 2>&1; then \
      invoke-rc.d apache2 reload > /dev/null 2>&1; \
    fi;
  endscript
  prerotate
    if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
      run-parts /etc/logrotate.d/httpd-prerotate; \
    fi; \
  endscript
}

$ sudo mkdir -p /etc/logrotate.d/httpd-prerotate
$ sudo ln -sf /usr/share/awstats/tools/update.sh \
  /etc/logrotate.d/httpd-prerotate/awstats
Sepa también que los archivos de registro creados por logrotate necesitan ser legibles por todos, especialmente AWStats. En el ejemplo anterior, se garantiza esto con la línea create 644 root adm (en lugar de los permisos predeterminados 640).