11.2. Servidor web (HTTP)

Els administradors de Falcot Corp han decidit utilitzar el servidor HTTP Apache, inclòs a Debian Bullseye amb la versió 2.4.52.

ALTERNATIVA Altres servidors web

Apache és probablement el servidor web més conegut, però n'hi ha d'altres. El seu principal oponent és nginx, que es troba disponible en diferents paquets amb diferents conjunts de característiques, com nginx-light, nginx-full, o nginx-extras. Una altra alternativa és lighttpd. Tots ells poden oferir un rendiment molt bo o fins i tot millor sota certes càrregues de treball o en certes situacions, però no tots proporcionen el mateix nombre de característiques i mòduls disponibles.

11.2.1. Instal·lació d'Apache

Instal·lar el paquet apache2 és tot el que es necessita. Conté tots els mòduls, incloent-hi els Multi-Processing Modules o “mòduls multiprocés” (MPMs) que determinen com Apache maneja el processament paral·lel de moltes sol·licituds, que solien proporcionar-se en paquets separats apache2-mpm-*. També estirarà apache2-utils que conté les utilitats de la línia d'ordres que descobrirem més endavant.

L'MPM que s'usi afectarà significativament la forma en què Apache manegarà les peticions concurrents. Amb el «worker» MPM, utilitza fils (processos lleugers o «threads»), mentre que amb la «prefork» MPM utilitza un conjunt de processos creats prèviament. Amb «event» MPM també utilitza fils, però les connexions inactives (en particular les que es mantenen obertes per la característica HTTP «keep-alive») es retornen a un fil dedicat a gestió.

Els administradors de Falcot també instal·len libapache2-mod-php per incloure el suport PHP 7.4 a Apache. Això fa que l'MPM per defecte «event» MPM quedi inhabilitat, i «prefork» s'utilitzi en el seu lloc. Per utilitzar l'MPM «event» es pot utilitzar php-fpm.

SEGURETAT Execució sota l'usuari www-data

Per defecte, Apache gestiona les peticions entrants sota la identitat de l'usuari www-data tal i com es defineix a /etc/apache2/envvars. Això significa que una vulnerabilitat de seguretat en un script CGI executat per Apache (per a una pàgina dinàmica) no comprometrà tot el sistema, sinó només els arxius propietat d'aquest usuari en particular.

Usar els mòduls suexec, proporcionats pels paquets apache2-suexec-*, permet saltar aquesta regla de manera que alguns scripts CGI s'executin sota la identitat d'un altre usuari. Això està configurat amb una directiva SuexecUserGroup usuarigrup a la configuració d'Apache.

Una altra possibilitat és utilitzar un MPM dedicat, com el que proporciona libapache2-mpm-itk. Aquest en particular té un comportament lleugerament diferent: permet “isolar” els amfitrions virtuals (en realitat, conjunts de pàgines) de manera que cadascun s'executa com un usuari diferent. Una vulnerabilitat en un lloc web, per tant, no pot comprometre arxius que pertanyen al propietari d'un altre lloc web.

Apache és un servidor modular, i moltes característiques són implementades per mòduls externs que el programa principal carrega durant la inicialització. La configuració per defecte només activa els mòduls més comuns, però activar altres mòduls és qüestió simplement d'executar a2enmod mòdul; per inhabilitar un mòdul, la comanda és a2dismod mòdul. Aquests programes en realitat només creen (o eliminen) enllaços simbòlics a /etc/apache2/mods-enabled/, apuntant als fitxers reals (desats a /etc/apache2/mods-available/).

Amb la configuració per defecte, el servidor web escolta al port 80 (com es configura a /etc/apache2/ports.conf), i serveix pàgines del directori /var/www/html/(com es configura a /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Afegir suport per a SSL

Apache 2.4 ja duu inclòs el mòdul SSL (mod.ssl) necessari per a HTTP segur (HTTPS). Només cal habilitar-ho amb a2enmod ssl, i després cal afegir les directives necessàries als arxius de configuració. Es proporciona un exemple de configuració a /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Si voleu generar certificats de confiança, podeu seguir la secció Secció 10.2.1, «Creació de certificats de confiança de franc» i després ajustar les següents variables:

SSLCertificateFile      /etc/letsencrypt/live/DOMINI/fullchain.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/DOMINI/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMINI/chain.pem
SSLCACertificateFile    /etc/ssl/certs/ca-certificates.crt

S'ha de tenir una mica més de cura si voleu afavorir les connexions SSL amb Perfect Forward Secrecy (on les connexions utilitzen claus de sessió efímeres assegurant que si la clau secreta del servidor queda en compromís, això no comprometi un possible trànsit encriptat antic que podria haver estat capturat de la xarxa). Doneu un cop d'ull a les recomanacions de Mozilla en particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

Com a alternativa al mòdul SSL estàndard, hi ha un mòdul d'extensió anomenat mod_gnutls, que s'inclou amb el paquet libapache2-mod-gnutls i s'habilita amb l'ordre a2enmod gnutls. Malauradament, la versió empaquetada per a Debian tenia incidències serioses amb fins i tot implicacions de seguretat i, en conseqüència, no forma part de la versió de Debian Bullseye.

→ https://mod.gnutls.org/

11.2.3. Configuració de servidors virtuals («virtual hosts»)

Un servidor virtual és una identitat addicional per al servidor web.

Apache considera dos tipus diferents de servidors virtuals: aquells que es basen en l'adreça IP (o el port), i aquells que es basen en el nom de domini del servidor web. El primer mètode requereix l'assignació d'una adreça IP diferent (o port) per a cada lloc, mentre que el segon pot treballar en una adreça IP única (i port), i els llocs estan diferenciats pel nom d'amfitrió enviat pel client HTTP (que només funciona en la versió 1.1 del protocol HTTP - afortunadament aquesta versió és prou antiga i tots els clients ja l'utilitzen).

L'escassetat (creixent) d'adreces IPv4 normalment afavoreix el segon mètode; no obstant això, es fa més complex si els servidors virtuals també necessiten proporcionar HTTPS, ja que el protocol SSL no sempre ha proporcionat l'allotjament virtual basat en noms; l'extensió SNI («Server Name Indication») que permet aquesta combinació no és acceptada per tots els navegadors. Quan diversos llocs HTTPS han d'executar-se en el mateix servidor, normalment es diferenciaran executant-se en un port diferent o en una adreça IP diferent (IPv6 pot facilitar les coses aquí).

La configuració predeterminada per a Apache 2 permet servidors virtuals basats en noms. A més, es defineix un amfitrió virtual per defecte al fitxer /etc/apache2/sites-enabled/000-default.conf; aquest servidor virtual s'utilitzarà si no es troba cap servidor que coincideixi amb la sol·licitud enviada pel client.

ULLADA RÀPIDA Suport d'Apache per a SNI

El servidor Apache suporta una extensió del protocol SSL anomenada «Server Name Indication» (SNI, de l'anglès “Indicació del nom de servidor”). Aquesta extensió permet al navegador enviar el nom d'amfitrió del servidor web durant l'establiment de la connexió SSL, molt abans que la sol·licitud HTTP mateixa, que abans s'utilitzava per identificar el host virtual sol·licitat entre els que es trobaven al mateix servidor (amb la mateixa adreça IP i port). Això permet a l'Apache seleccionar el certificat SSL més apropiat perquè la transacció continuï.

Abans de l'SNI, Apache sempre utilitzava el certificat definit en l'servidor virtual per defecte. Els clients que intentessin accedir a un altre servidor virtual mostrarien avisos, ja que el certificat que rebien no coincidia amb el lloc web que estaven intentant accedir. Afortunadament, la majoria dels navegadors ara treballen amb SNI; això inclou Microsoft Internet Explorer començant amb la versió 7.0 (a partir de Vista), Mozilla Firefox començant amb la versió 2.0, Apple Safari des de la versió 3.2.1, i totes les versions de Google Chrome.

El paquet Apache proporcionat a Debian està construït amb suport per a SNI; per tant, no es necessita cap configuració particular.

Cada servidor virtual extra és descrit per un fitxer emmagatzemat a /etc/apache2/sites-available// La creació d'un lloc web per al domini de falcot.org és, per tant, una qüestió tan senzilla com crear el següent fitxer, i després habilitar el servidor virtual amb a2ensite www.falcot.org.

Exemple 11.13. El fitxer /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, tal com està configurat fins ara, utilitza els mateixos fitxers de registre per a tots els servidors virtuals (encara que això es podria canviar afegint directives CustomLog a les definicions dels servidors virtuals). Per tant, té sentit personalitzar el format d'aquest fitxer de registre perquè inclogui el nom del servidor virtual. Això es pot fer creant un fitxer /etc/apache2/conf-available/customlog.conf que defineix un nou format per a tots els fitxers de registre (amb la directiva LogFormat) i habilitant-lo amb a2enconf customlog) La línia CustomLog també s'ha d'eliminar (o comentar) del fitxer /etc/apache2/sites-available/000-default.conf.

Exemple 11.14. El fitxer /etc/apache2/conf-available/customlog.conf

# Nou format de registre incloent el nom del servidor (virtual)
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Ara usem aquest format "vhost" per defecte
CustomLog /var/log/apache2/access.log vhost

11.2.4. Directives comunes

Aquesta secció revisa breument algunes de les directives de configuració Apache més usades.

El fitxer de configuració principal normalment inclou diversos blocs Directory; permeten especificar diferents comportaments per al servidor depenent de la ubicació del fitxer que s'estigui servint. Aquest bloc inclou normalment directives Opcions i allowOverride.

Exemple 11.15. Bloc «Directory»

<Directory /srv/www>
Options Includes FollowSymlinks
AllowOverride All
DirectoryIndex index.php index.html index.htm
</Directory>

La directiva DirectoryIndex conté una llista de fitxers per cercar quan la sol·licitud del client coincideix amb un directori. El primer fitxer existent de la llista s'utilitza i s'envia com a resposta.

La directiva Options és seguida per una llista d'opcions per habilitar. El valor None inhabilita totes les opcions; en conseqüència, All els activa tots excepte MultiViews. Les opcions disponibles inclouen:

ExecCGI indica que els «scripts» CGI poden ser executats.
FollowSymlinks indica al servidor que es poden seguir els enllaços simbòlics, i que la resposta hauria de contenir el contingut de l'objectiu d'aquests enllaços.
SymlinksIfOwnerMatch també li diu al servidor que segueixi els enllaços simbòlics, però només quan l'enllaç i el seu objectiu tenen el mateix propietari.
Includes habilita «Server Side Includes» (o “Inclusions a la banda de servidor”, SSI per abreujar). Es tracta de directives inserides en pàgines HTML i executades sobre la marxa per a cada sol·licitud.
IncludesNOEXEC permet Server Side Includes (SSI) però inhabilita l'ordre exec i limita la directiva include a fitxers de text o de marques.
Indexes indica al servidor que llisti els continguts d'un directori si la sol·licitud HTTP enviada pel client apunta a un directori sense fitxer d'índex (és a dir, quan no hi ha cap dels fitxers esmentats per la directiva DirectoryIndex).
MultiViews permet la negociació de contingut; això pot ser utilitzat pel servidor per retornar una pàgina web que coincideixi amb l'idioma preferit que tingui configurat el navegador.

La directiva allowOverride llista totes les opcions que es poden activar o desactivar mitjançant un fitxer .htaccess. Un ús comú d'aquesta opció és restringir ExecCGI, de manera que l'administrador tria quins usuaris poden executar programes sota la identitat del servidor web (l'usuari www-data).

11.2.4.1. Requerir autenticació

En algunes circumstàncies, l'accés a part d'un lloc web ha de ser restringit, de manera que només els usuaris legítims que proporcionen un nom d'usuari i una contrasenya tenen accés al contingut. Aquestes característiques són proporcionades pels mòduls mod_auth*.

Exemple 11.16. Fitxer .htaccess que requereix autenticació

Require valid-user
AuthName "Directori privat"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

El fitxer /etc/apache2/authfiles/htpasswd-private conté una llista d'usuaris i contrasenyes; es manipula habitualment amb l'ordre htpasswd. Per exemple, la següent ordre s'utilitza per afegir un usuari o canviar la seva contrasenya:

# htpasswd /etc/apache2/authfiles/htpasswd-private user
New password:
Re-type new password:
Adding password for user user

11.2.4.2. Restringint l'accés

La directiva Require controla les restriccions d'accés per a un directori (i també els seus subdirectoris, recursivament).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Es pot utilitzar per restringir l'accés basant-se en molts criteris; ens aturarem a descriure la restricció d'accés basada en l'adreça IP del client, però pot ser molt més potent que això, especialment quan diverses directives Require es combinen dins d'un bloc RequireAll.

Exemple 11.17. Permetre només des de la xarxa local

Requerir la ip 192.168.0.0/16

ALTERNATIVA Sintaxi antiga

La sintaxi Require només està disponible a Apache 2.4 (la versió inclosa a partir de Jessie). Per als usuaris de Wheezy, la sintaxi d'Apache 2.2 és diferent, i la descrivim aquí principalment com a referència, encara que també es pot usar amb Apache 2.4 utilitzant el mòdul mod_access_compat.

Les directives Allow from i Deny from controlen les restriccions d'accés a un directori (i recursivament als seus subdirectoris).

La directiva Order diu al servidor l'ordre en què s'apliquen les directives Allow from i Deny from; l'última que coincideix és la que té prioritat. En termes concrets, Order deny,allow permet l'accés si no s'aplica cap Deny from, o si s'aplica una directiva Allow from. Per contra, Order allow,deny rebutja l'accés si cap directiva Allow from coincideix (o si s'aplica una directiva Deny from).

Les directives Allow from i Deny from poden ser seguides per una adreça IP, una xarxa (com ara 192.168.0.0/255.255.255.0, 192.168.0.0/24 o fins i tot 192.168.0), un nom d'amfitrió o un nom de domini, o la paraula clau all, designant a tothom.

Per exemple, per rebutjar per defecte les connexions però permetre-les des de la xarxa local, podria utilitzar-se això:

Order deny,allow
Allow from 192.168.0.0/16
Deny from all

11.2.5. Analitzadors de registres

Un analitzador de registres és instal·lat sovint en un servidor web, ja que el primer proporciona als administradors una idea precisa dels patrons d'ús del servidor.

Els administradors de Falcot Corp han seleccionat AWStats (Advanced Web Statistics) per analitzar els fitxers de registre d'Apache.

El primer pas de configuració és la personalització del fitxer /etc/awstats/awstats.conf. Els administradors de Falcot el deixen tal com està excepte els següents paràmetres:

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"

Tots aquests paràmetres estan documentats amb comentaris al fitxer de plantilla. En particular, els paràmetres LogFile i LogFormat descriuen la ubicació i el format del fitxer de registre i la informació que conté; SiteDomain i HostAliases llisten els diversos noms sota els quals es coneix el lloc web principal.

Per a llocs amb trànsit alt, DNSLookup normalment no s'hauria d'establir a 1; per a llocs més petits, com el de Falcot descrit anteriorment, aquest ajustament permet obtenir informes més llegibles que inclouen noms de màquina complets en lloc de simples adreces IP.

AWStats també s'habilitarà per a altres servidors virtuals; cada servidor virtual necessita el seu propi fitxer de configuració, com ara /etc/awstats/awstats.www.falcot.org.conf.

Exemple 11.18. Fitxer de configuració de l'AWStats per a un servidor virtual

Include "/etc/awstats/awstats.conf"
SiteDomain="www.falcot.org"
HostAliases="falcot.org"

AWStats utilitza moltes icones emmagatzemades al directori /usr/share/awstats/icon/. Per tal que aquestes icones estiguin disponibles en el lloc web, la configuració d'Apache ha d'adaptar-se per incloure la següent directiva (trobareu un exemple més detallat si feu una ullada a /usr/share/doc/awstats/examples/apache.conf):

Alias /awstats-icon/ /usr/share/awstats/icon/

Després d'uns minuts (i una vegada que l'script s'hagi executat unes quantes vegades), els resultats estaran disponibles en línia:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

COMPTE Rotació del fitxer de registre

Per tal que les estadístiques tinguin en compte tots els registres, AWStats s'ha d'executar just abans que els fitxers de registre Apache siguin rotats. Mirant la directiva prerotate al fitxer /etc/logrotate.d/apache2, això és resolt per awstats posant un script a /etc/logrotate.d/httpd-prerotate que executa /usr/share/awstats/tools/update.sh.

Tingueu en compte també que els arxius de registre creats per logrotate han de ser llegibles per tothom, especialment AWStats. Això queda garantit canviant /etc/logrotate.d/apache2 perquè inclogui, per exemple, create 644 root adm (en lloc dels permisos per defecte 640). Però, si us plau, consulteu /usr/share/doc/awstats/README.Debian.gz per a una documentació més extensa sobre aquest tema i alternatives.