11.2. Nett-tjener (HTTP)

11.2.1. Å installere 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.

Når MPM brukes, påvirkes måten Apache vil håndtere samtidige forespørsler på betydelig. Med worker-MPM, bruker den threads (lettvektprosesser), mens med prefork-MPM bruker den en samling prosesser som er laget på forhånd. Med event-MPM vil den også bruke tråder, men de inaktive tilkoblingene (spesielt de som holdes åpne av HTTP keep-alive-funksjonen) blir levert tilbake til en øremerket management-tråd (ledelsestråd).

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.

SIKKERHET Kjøring under www-data-brukeren

Som standard håndterer Apache innkommende forespørsler under identiteten til www-data-brukeren. Dette betyr at en sikkerhetssårbarhet i et CGI-skript, utført av Apache (for en dynamisk side), ikke vil kompromittere hele systemet, men bare de filer som eies av denne bestemte brukeren.

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.

En annen mulighet er å bruke en dedikert MPM, slik som den som tilbys i libapache2-mpm-itk. Akkurat denne har en litt annen oppførsel: Den tillater å «isolere» virtuelle verter (faktisk, sett med sider), slik at hver av dem kjører som en ulik bruker. En sårbarhet i en nettside kan derfor ikke kompromittere filer som tilhører eieren av et annet nettsted.

Apache er en modulbasert tjener, og mange funksjoner legges inn av eksterne moduler som hovedprogrammet laster inn under sin initialisering. Standardoppsettet kan bare aktivere de mest vanlige moduler, men å tillate nye moduler skjer ved ganske enkelt å kjøre a2enmod modul; for å koble fra en modul, er kommandoen a2dismod modul. Disse programmene oppretter (eller sletter) bare symbolske lenker i /etc/apache2/mods-enabled/, som peker på de aktuelle filene (lagret i /etc/apache2/mods-available/).

Med sitt standardoppsett, lytter nettjeneren på port 80 (som satt opp i /etc/apache2/ports.conf), og betjener sider fra /var/www/html/-mappen (som satt opp i /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 Seksjon 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. Oppsett av virtuelle verter

En virtuell vert er en ekstra identitet for nett-tjeneren.

Apache vurderer to forskjellige typer virtuelle verter: De som er basert på IP-adressen (eller porten), og de som er avhengige av domenenavnet til nett-tjeneren. Den første metoden krever tildeling av en annen IP-adresse (eller port) for hvert område, mens den andre kan arbeide på en enkelt IP-adresse (og port), og nettstedene er differensiert etter vertsnavnet sendt av HTTP-klienten (som bare fungerer i versjon 1.1 av HTTP-protokollen - heldigvis at versjonen er gammel nok til at alle kunder bruker den allerede).

Den (økende) knapphet på IPv4-adresser favoriserer vanligvis den andre metoden; imidlertid er det gjort mer komplisert om de virtuelle verter må levere HTTPS også, ettersom SSL-protokollen ikke alltid har levert navn-baserte virtuelle verter; Ikke alle nettlesere håndterer SNI-forlengelsen (Server Name Indication). Når flere HTTPS-nettsteder må kjøre på samme tjener, vil de vanligvis bli differensiert enten ved å kjøre på en annen port, eller på en annen IP-adresse (IPv6 kan hjelpe til der).

Standardoppsettet for Apache 2 gir navn-baserte virtuelle verter. I tillegg er en standard virtuell vert definert i /etc/apache2/sites-enabled/000-default.conf-filen; Denne virtuelle verten vil bli brukt hvis det ikke finnes en vert som matcher anmodningen fra klienten.

HURTIGVISNING Apache støtter SNI

Apache-tjeneren støtter en SSL-protokollforlengelse kalt Server Name Indication (SNI). Denne utvidelsen lar nettleseren sende vertsnavnet til nett-tjeneren, ved etableringen av SSL-tilkoblingen, mye tidligere enn HTTP-forespørselen selv, som tidligere ble brukt til å identifisere den forespurte virtuelle verten blant dem som ligger på samme tjener (med samme IP-adresse og port). Dette gjør Apache ved å velge det mest passende SSL-sertifikatet slik at transaksjonen kan fortsette.

Før SNI, ville Apache alltid bruke sertifikatet i den virtuelle standard verten. Klienter som prøver å få tilgang til en annen virtuell vert vil da vise advarsler, siden sertifikatet de mottok ikke samsvarte med nettstedet de prøvde å få tilgang til. Heldigvis jobber de fleste nettlesere sammen med SNI. Dette inkluderer Microsoft Internet Explorer fra og med versjon 7.0 (som starter med Vista), Mozilla Firefox fra og med versjon 2.0, Apple Safari fra versjon 3.2.1, og alle versjoner av Google Chrome.

Apache-pakken, levert med Debian, er bygget med støtte for SNI. Intet spesielt oppsett er derfor nødvendig.

Hver ekstra virtuelle vert er deretter beskrevet av en fil lagret i /etc/apache2/sites-available/. Å sette opp et nettsted for falcot.org-domenet blir derfor en enkel sak ved å lage den følgende filen, og så aktivere den virtuelle verten med a2ensite www.falcot.org.

Eksempel 11.13. /etc/apache2/sites-available/www.falcot.org.conf-filen

<VirtualHost *:80>
ServerName   www.falcot.org
ServerAlias  falcot.org
DocumentRoot /srv/www/www.falcot.org
</VirtualHost>

Apache-tjeneren, satt opp så langt, bruker de samme loggfiler for alle virtuelle verter (selv om dette kan endres ved å legge til CustomLog-direktiver i definisjonene til de virtuelle vertene). Det er derfor klokt å tilpasse formatet på denne loggfilen slik at den inneholder navnet på den virtuelle verten. Dette kan gjøres ved å opprette en /etc/apache2/conf-available/customlog.conf-fil som fastsetter et nytt format for alle loggfiler (med LogFormat-direktivet), og ved å aktivere den med a2enconf customlog. CustomLog-linjen må også fjernes (eller kommenteres ut) fra /etc/apache2/sites-available/000-default.conf-filen.

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

# Nytt loggformat som inneholder (virtuelt) vertsnavn
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost

# Så bruker vi dette vhost-formatet som standard
CustomLog /var/log/apache2/access.log vhost

11.2.4. Vanlige direktiver

Dette avsnittet gir en kort gjennomgang av noen av de oftest brukte Apache-oppsettsdirektivene.

Den viktigste oppsettsfilen inneholder vanligvis flere Directory-blokker. De åpner for å spesifisere ulike virkemåter for tjeneren, avhengig av plasseringen av filen som blir betjent. En slik blokk omfatter vanligvis Options og AllowOverride-direktiver.

Eksempel 11.15. Katalogblokk

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

Direktivet DirectoryIndex inneholder en liste over filer som kan prøves når klientens forespørsel matcher en katalog. Den første filen som forekommer i listen brukes, og er sendt som en respons.

Direktivet Options er etterfulgt av en liste av alternativer som kan aktiveres. Verdien None slår av alle valg; tilsvarende aktiverer All alle sammen unntatt MultiViews. Tilgjengelige valg inkluderer:

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.

Direktivet AllowOverride lister opp alle alternativer som kan aktiveres eller deaktiveres ved hjelp av en .htaccess-fil. En vanlig bruk av dette valget er til å begrense ExecCGI, slik at administratoren velger hvilke brukere som har lov til å kjøre programmer under nett-tjenerens identitet (www-data-brukeren).

11.2.4.1. Å kreve autentisering

I noen tilfeller trenges det begrenset tilgang til en del av et nettsted, slik at bare legitime brukere som gir et brukernavn og et passord får tilgang til innholdet.

Eksempel 11.16. .htaccess-fil som krever autentisering

Require valid-user
AuthName "Privat katalog"
AuthType Basic
AuthUserFile /etc/apache2/authfiles/htpasswd-private

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 user
New password:
Re-type new password:
Adding password for user user

11.2.4.2. Adgangsbegrensning

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).

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

Den kan brukes til å begrense adgangen basert på flere kriterier: Vi vil stoppe med å beskrive adgangsbegrensning basert på klientens IP-adresse, men det kan gjøres mye kraftigere enn det, særlig når flere Require-direktiver kombineres i en RequireAll-blokk.

Eksempel 11.17. Tillat bare fra det lokale nettverket

Require ip 192.168.0.0/16

ALTERNATIV Gammel syntaks

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.

Direktivene Allow from og Deny from kontrollerer adgangsbegrensninger for en katalog (og gjentatt for katalogens undermapper).

Order-direktivet forteller tjeneren om rekkefølgen på Allow from og Deny from-direktivene; den siste som matcher har forrang. Konkret tillater Order deny,allow adgang hvis ingen Deny from passer, eller hvis et Allow from-direktiv gjør det. Omvendt, stanser Order allow,deny adgang hvis intet Allow from-direktiv matcher (eller hvis et Deny from-direktiv tillater).

Direktivene Allow from og Deny from kan etterfølges av en IP-adresse, et nettverk (slik som 192.168.0.0/255.255.255.0, 192.168.0.0/24, eller til og med 192.168.0), et vertsnavn eller domenenavn, eller all-nøkkelen som peker ut alle.

For eksempel, for å avvise forbindelser som standard, men tillate dem fra det lokale nettverket, kan du bruke denne:

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

11.2.5. Logg-analysatorer

En logg-analysator er ofte installert på en nett-tjener; siden den første gir administratorer en presis idé om bruksmønstre på sistnevnte.

Falcot Corp-administratorene valgte AWStats (Advanced Web Statistics) til å analysere sine Apache-loggfiler.

Det første oppsettstrinnet er å tilpasse /etc/awstats/awstats.conf-filen. Falcot-administratorene holdt den uendret, bortsett fra følgende parametre:

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"

Alle disse parametrene er dokumentert av kommentarer i male-filen. Spesielt beskriver LogFile og LogFormat-parameterene, plasseringen og formatet på loggfilen og informasjonen den inneholder;SiteDomain og HostAliases lister de ulike navnene som hovednettstedet er kjent under.

For områder med stor trafikk skal DNSLookup vanligvis ikke settes til 1. For mindre nettsteder, som for eksempel Falcot-eksemplet beskrevet ovenfor, tillater denne innstillingen mer lesbare rapporter med komplette maskinnavn i stedet for rå (enkle) IP-adresser.

AWStats er også aktivert for andre virtuelle verter; hver virtuell vert må ha en egen oppsettsfil, som for eksempel /etc/awstats/awstats.www.falcot.org.conf.

Eksempel 11.18. AWStats oppsettsfil for en virtuell vert

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

AWStats bruker mange ikoner lagret i /usr/share/awstats/icon/-mappen. For at disse ikonene skal være tilgjengelige på nettsiden, må Apache-oppsettet tilpasses ved å inkludere følgende direktiv:

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

Etter noen minutter (og så snart skriptet er kjørt et par ganger), er resultatene tilgjengelig på nettet:

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

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

VÆR VARSOM Loggfil-rotasjon

For at statistikken skal ta alle loggene med i betraktningen, trenger AWStats å kjøres rett før Apache loggfilene blir rotert. Se på prerotate-direktivet til /etc/logrotate.d/apache2-filen. Dette kan løses ved å sette en symlink til /usr/share/awstats/tools/update.sh i /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

Merk også at loggfilene som ble opprettet av logrotate, må kunne leses av alle, spesielt AWStats. I eksempelet ovenfor er dette sikret av create 644 root adm-linjen (i stedet for de standard 640- tillatelsene).