« Webserver/Apache » : différence entre les versions
| Ligne 534 : | Ligne 534 : | ||
</syntaxhighlight>}} | </syntaxhighlight>}} | ||
= Journalisation conditionnelle = | |||
La récupération par un client d'une page web complète peut générer beaucoup de log: téléchargement des images, etc... On peut conditionner la journalisation. | La récupération par un client d'une page web complète peut générer beaucoup de log: téléchargement des images, etc... On peut conditionner la journalisation. | ||
Dernière version du 30 septembre 2013 à 10:54
Apache
Présentation d'Apache
Apache est un fournisseur de services Http. C'est un logiciel libre disponible pour la plupart des systèmes d'exploitation. Il équipe actuellement plus de 60% des serveurs internet mondiaux.
Liens :
- http://www.planetapache.org/ : Site de la "Apache Software Foundation"
- http://httpd.apache.org/ : Site officiel
- http://www.apachefrance.com/ : Le site francophone sur Apache
- http://www.planetapache.org/ : Planet Apache
Installation d'Apache
Installation
Il fait partie des logiciels fournis avec la distribution Fedora: <package>httpd</package>
Versions fournies :
- Versions actuelles :
- Fedora Rawhide : 2.4.2
- Fedora 17 : 2.2.22
- Fedora 16 : 2.2.22
- Anciennes versions (non maintenues) de Fedora (pour mémoire) :
- Fedora 15 : 2.2.22
- Fedora 14 : 2.2.17
- Fedora 13 : 2.2.17
- Fedora 12 : 2.2.15
- Fedora 11 : 2.2.15
- Fedora 10 : 2.2.14
- Fedora 9 : 2.2.10
- Fedora 8 : 2.2.9
- Fedora 7 : 2.2.8
- Fedora Core 6 : 2.2.6
- Fedora Core 5 : 2.2.2
- Fedora Core 4 : 2.0.54
- Fedora Core 3 : 2.0.53
- Fedora Core 2 : 2.0.51
- Fedora Core 1 : 2.0.50
Attention : il n'est pas nécessaire de vouloir la dernière sous-version (troisième chiffre), en effet il s'agit généralement uniquement de correctifs de sécurité qui sont intégrés dans les RPM de la distribution (exemple la version 2.2.2-1.2 de FC5 contient les correctifs de la version 2.2.3).
Nous allons l'installer avec sa documentation, très complète et source de renseignements précieux
$ su -c 'yum install httpd-manual'
Activation
Ensuite il est nécessaire de démarrer le service :
$ su -lc 'service httpd start'
Si vous souhaitez que son lancement soit automatique lors du démarrage de la machine :
$ su -lc 'chkconfig httpd on'
Le service httpd doit être démarré après le réseau. Ce qui est le cas lorsqu'on utilise le service network mais pas le service NetworkManager, donc
- pour un serveur : utiliser network (en général avec une connexion filaire et une IP fixe)
- pour un poste mobile : ne pas activer httpd au démarrage (connexion wifi, non permanente, ...)
Pour vérifier son fonctionnement, essayez les adresses suivantes dans votre navigateur :
- http://localhost/ : Test Page for the Apache HTTP Server on Fedora Core
- http://localhost/manual/ : Apache HTTP Server Version 2.2 Documentation
Fichiers et dossiers à connaitre
- /etc/httpd : dossier contenant l'ensemble des fichiers de configuration
- /etc/httpd/conf/httpd.conf : fichier principal de configuration. Nous verrons qu'il est possible - et fortement recommandé - de ne jamais modifier ce fichier
- /etc/httpd/conf.d : dossier contenant les fichiers secondaires de configuration, fournis par les extensions et les logiciels utilisant Apache. C'est ici que nous allons travailler
- /var/log/httpd : dossier contenant les journaux
- /var/log/httpd/access_log : journal retraçant toutes les pages traitées par le serveur
- /var/log/httpd/error_log : journal des erreurs
- /var/www : dossier contenant les données du site par défaut
- /var/www/cgi-bin : dossier (vide) contenant les scripts
- /var/www/error : dossier contenant les pages affichées en cas d'erreur
- /var/www/html : dossier (vide) contenant les pages du site par défaut
- /var/www/icons : dossier contenant quelques icônes
- /var/www/manual : dossier contenant la documentation
Exploitation d'Apache
Lors de l'installation d'une extension, il est nécessaire de relancer le service :
$ su -lc 'service httpd start'
Lors d'une modification de la configuration, il est nécessaire de demander à Apache de rechercher sa configuration. Pour cela il est toujours préférable de procéder en 2 temps.
Contrôle de la nouvelle configuration
$ su -lc 'service httpd configtest' Syntax OK
Cette opération permet de vérifier la syntaxe sans arrêter le service. C'est très pratique, notamment pour un serveur en production.
Ensuite, si tout est OK
$ su -lc 'service httpd reload'
L'outil logrotate est automatiquement configuré lors de l'installation pour faire tourner les journaux chaque semaine en conservant 4 générations. Il n'y a donc pas de risque de saturer le disque.
Si vous souhaitez modifier ces réglages, ça se passe dans le fichier /etc/logrotate.d/httpd.
L'outil logwatch est automatiquement configuré pour transmettre quotidiennement un rapport par courrier sur les anomalies (courantes et connues) rencontrées dans les journaux, et donc dans ceux d'Apache, voic un exemple de compte-rendu :
--------------------- httpd Begin ------------------------ A total of 6 unidentified 'other' records logged GET /test4 HTTP/1.1 with response code(s) 4 404 responses GET /thunderbird.jsc HTTP/1.0 with response code(s) 1002 200 responses GET /phpgwapi/js/tinymce/jscripts/tiny_mce/themes/advanced/images/%7B$lang_bold_img%7D HTTP/1.1 with response code(s) 8 404 responses GET /bei/test4 HTTP/1.1 with response code(s) 2 404 responses GET /phpgwapi/js/tinymce/jscripts/tiny_mce/themes/advanced/images/%7B$lang_italic_img%7D HTTP/1.1 with response code(s) 8 404 responses GET /phpgwapi/js/tinymce/jscripts/tiny_mce/themes/advanced/images/%7B$lang_underline_img%7D HTTP/1.1 with response code(s) 8 404 responses ---------------------- httpd End -------------------------
Configuration d'Apache
La configuration par défaut du service, livrée avec l'application, se trouve dans le fichier /etc/httpd/conf/httpd.conf.
Bien que de nombreux tutoriels conseillent sa modification il est préférable de ne pas le modifier. On préfèrera la création d'un fichier spécifique à nos besoins dans le dossier /etc/httpd/conf.d. Cette solution permet de ne pas bloquer les mises à jour éventuelles du fichier principal et simplifiera grandement les migrations (il suffit de récupérer notre fichier de configuration).
Dans le répertoire <path>/etc/httpd/conf.d/</path>, les fichiers seront chargés par ordre alphabétique. Dans la plupart des cas, ce n'est pas gênant... Mais nous avons bien évoqué la plupart des cas. Le fichier de configuration principal va déclarer - par exemple - la directive NameVirtualHost qui doit être présente dans certaines situations (nous vous conseillons de ne pas l'omettre, vous serez fixé :D).
Dans une telle situation, si votre fichier principal se nomme zeus.fedora-fr.org, il est fort probable qu'il soit chargé à la toute fin, et que les directives importantes ne soient pas prises en compte. Il en résulte des comportements que vous pouvez trouver parfaitement anormaux ; mais qui n'en sont pas moins logiques.
Cela étant expliqué, nous vous conseillons de préfixer votre fichier de configuration principal au sein de <path>/etc/httpd/conf.d/</path> de façon à ce qu'il soit chargé en premier (utilisez par exemple <path>0zeus.fedora-fr.org</path> en lieu et place de <path>zeus.fedora-fr.org</path>.La lecture de la documentation officielle et de nombreux sites consacrés à ce sujet vous permettra de découvrir les différentes directives de configurations.
Documentation officielle : Directive Index
Les fichiers de configuration ne peuvent être modifiés que par l'administrateur (root). Il est possible de "donner" ce fichier à votre utilisateur afin qu'il puisse l'éditer sans privilège (voir la commande chown).
Voici un exemple de fichier de configuration minimum, adapté à une machine de développement et de test.
Les commentaires doivent vous permettre de comprendre chaque partie.
Fichier /etc/httpd/conf.d/messites.conf
# activation des hôtes virtuels
NameVirtualHost *:80
# Hôte virtuel par défaut
<VirtualHost *:80>
# Activation des sites de quelques utilisateurs : http://localhost/~nomutilisateur
UserDir enabled nomutilisateur unautre undernier
UserDir public_html
<Directory /home/*/public_html>
AllowOverride all
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
# Activation de l'adresse : http://localhost/server-status
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
# Activation de l'adresse : http://localhost/server-info
<Location /server-info>
SetHandler server-info
Order deny,allow
Deny from all
Allow from 127.0.0.1
Allow from ::1
</Location>
</VirtualHost>
La définition d'un hôte virtuel permet de redéfinir les valeurs par défaut du fichier principal.
Lors de la création d'un compte utilisateur, les droits par défaut interdisent à Apache de traverser le dossier. Pour utiliser les sites personnels (dossier public_html), il faut donc donner aux "autres" (et donc à l'utilisateur Apache) le droit de traver le répertoire d'accueil. Chaque utilisateur fera : chmod o+x $HOME
L'ajout d'hôte supplémentaire est très simple et permet de varier les options de configuration.
- ajout du nom du site dans le DNS ou, pour test, dans le fichier /etc/hosts
127.0.0.1 nommachine site1 site2 site3 localhost.localdomain localhost
- définition de l'hôte dans notre fichier de configuration (messites.conf)
<VirtualHost *:80>
# home du site : URL = http://site1/
ServerName site1
# Dossier contenant les pages
DocumentRoot /var/www/site1
<Directory /var/www/site1>
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
AllowOverride FileInfo AuthConfig Limit
</Directory>
# jeu de caractères (UTF-8 par défaut)
AddDefaultCharset ISO-8859-1
</VirtualHost>
Extensions
L'une des principales forces d'Apache est de disposer d'une grande quantité d'extensions pouvant être installées en fonction des besoins. La plupart sont disponible dans la distribution.
Petite liste non exhaustive :
- mod_authz_ldap : gestion des authentifications LDAP
- mod_perl : un interpréteur Perl embarqué
- mod_python : un interpréteur Python embarqué
- mod_security : une extension de sécurité
- mod_ssl : extension SSL/TLS (pour les sites https)
- php : un interpréteur PHP embarqué. Voir la page Installation et configuration de PHP
- etc...
Liste exhaustive :
yum list mod_\*
SELinux et apache
Le dossier /var/www et ses sous dossiers doivent posséder un contexte SELinux particulier (si SELinux est activé, bien entendu).
La manifestation la plus évidente d'un problème de contexte SELinux pour les fichiers d'un site web se traduit dans le fichier log d'apache (/var/log/httpd/error_log) par un message du type :
[Thu Sep 06 09:04:54 2007] [error] [client 127.0.0.1] (13)Permission denied: access to /index.php denied
Accompagné dans le fichier /var/log/messages d'une entrée du type :
SELinux is preventing access to files with the default label, default_t. For complete SELinux messages. run sealert -l b5c3f837-f138-4853-97f9-8fd8dbd27531
Ces messages signifient que le contexte SELinux n'est pas correct pour le serveur web, et donc que SELinux en a bloqué l'accès. Dans ce cas précis, la commande sealert vous expliquera qu'il faut restaurer le contexte par défaut avec la commande :
restorecon -R -v /var/www/html
Cette astuce n'est évidemment pas universelle, mais c'est un problème fréquemment rencontré lorsque l'on commence à travailler sous apache. Pour de plus amples informations, je vous conseille de lire attentivement la page de manuel des commandes restorecon et sealert.
Gardez à l'esprit qu'il reste toujours possible qu'une erreur proviennent d'un problème de droits UNIX, et pas forcément de SELinux, dans ce cas vous aurez une entrée access denied dans le fichier de log d'apache, mais rien dans /var/log/messages
La commande
restorecon n'est utile que dans le répertoire des donnnées d'apache par défaut : /var/www/.
Si vous utilisez un répertoire ailleurs sur votre système, il vous faudra avoir recours à la commande chcon, de la façon suivante :
chcon -R -t httpd_sys_content_t /rep/donnees/apacheVous trouverez plus d'informations sur
chcon dans sa page de manuel.Par défaut, SELinux interdit l'accès aux répertoires utilisateurs au serveur httpd. En plus de modifier le contexte SELinux, il vous faudra également activer le booléen suivant afin d'autoriser la mise en ligne des sites utilisateurs :
setsebool -P httpd_enable_homedirs 1Notez que les répertoires et fichiers doivent être dans ce cas étiquettés en utilisant httpd_user_content_t (et non pas httpd_sys_content_t !). Les contextes d'accès en écriture, en exécution, etc. sont régis de la même façon ; vous devez dans les répertoires utilisateurs utiliser les étiquettes httpd_user_*
Conclusion
Cet article doit vous avoir permis de rendre apache opérationnel sur votre machine.
Il vous reste maintenant beaucoup de lecture pour découvrir un aperçu de ses fonctionnalités.
Configurer le module mod_ssl
Il faut générer un certificat signé par une autorité de certification.
On créé l'arborescence nécessaire à la génération des clés et certificats
mkdir /etc/pki/httpd/
cd /etc/pki/httpd/
mkdir {certs,private,confs}
touch index.txt
echo 01 > serial
Création du fichier de configuration de nos futurs certificats : <path>/etc/pki/httpd/ssl.cnf</path>
HOME = . RANDFILE = .rand [ca] default_ca = ca_default [ca_default] dir = . certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/%s_ca_cert.pem private_key = $dir/private/%s_ca_key.pem serial = $dir/serial crl = $dir/crl.pem x509_extensions = usr_cert name_opt = ca_default cert_opt = ca_default default_days = 3650 default_crl_days = 30 default_md = md5 preserve = no policy = policy_match [policy_match] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [req] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert string_mask = MASK:0x2002 req_extensions = v3_req [req_distinguished_name] countryName = Country Name (2 letter code) countryName_default = FR countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Paca localityName = Locality Name (eg, city) localityName_default = Cavaillon 0.organizationName = Organization Name (eg, company) 0.organizationName_default = B2PWeb organizationalUnitName = Organizational Unit Name (eg, section) commonName = Common Name (eg, your name or your server\'s hostname) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 [req_attributes] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [usr_cert] basicConstraints = CA:FALSE nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always [v3_ca] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true [v3_req] subjectAltName = "DNS:www-secure.b2pweb.com,DNS:statgeo.b2pweb.com"
On peut utiliser un wildcard (joker) du type *.b2pweb.com pour que le certificat s'applique à un ensemble de sous-domaines. Mais c'est plus propre d'ajouter un ou plusieurs subjectAltName au certificat. De cette manière, la liste est finie et ne peut s'appliquer qu'aux virtual hosts connus.
D'abord on génère une clé non chiffrée sur disque (pour éviter d'avoir à saisir un mot de passe à chaque redémarrage d'Apache) :
openssl genrsa -out private/server.key 2048
On crée un certificat signé avec cette clé ( validité 1 an ):
openssl req -config ssl.cnf -new -x509 -days 365 -key private/server.key -out server.crt -extensions v3_ca -extensions v3_req
Répondre à l'ensemble des questions posées. Le nom de la machine ( hostname --fqdn doit être donné en réponse à Common Name.
Ensuite, dans Apache, modifier le fichier de définition du VirtualHost qui va bien :
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on
SSLCertificateFile /etc/pki/httpd/server.crt
SSLCertificateKeyFile /etc/pki/httpd/private/server.key
SSLVerifyClient none
[etc., etc.]
</VirtualHost>
La méthode décrite ici permet de renouveler très facilement le certificat. En effet la configuration du certificat est toujours présente dans le fichier <path>/etc/pki/httpd/ssl.cnf</path>
On sauvegarde l'existant, on ne sais jamais:
mv /etc/pki/httpd/private/server.key /etc/pki/httpd/private/server.key.bak mv /etc/pki/httpd/server.crt /etc/pki/httpd/server.crt.bak
Puis de générer une nouvelle clé et un nouveau certificat
openssl genrsa -out private/server.key 2048 openssl req -config ssl.cnf -new -x509 -days 365 -key private/server.key -out server.crt \ -extensions v3_ca -extensions v3_req
F.A.Q.
How to solve particular security constraints for an SSL-aware webserver is not always obvious because of the coherences between SSL, HTTP and Apache's way of processing requests. This chapter gives instructions on how to solve such typical situations. Treat is as a first step to find out the final solution, but always try to understand the stuff before you use it. Nothing is worse than using a security solution without knowing it's restrictions and coherences.
Cipher Suites and Enforced Strong Security
Fichier httpd.conf
SSLProtocol -all +SSLv2
SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP
Fichier httpd.conf
SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
Fichier httpd.conf
# allow all ciphers for the inital handshake,
# so export browsers can upgrade via SGC facility
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Directory /usr/local/apache/htdocs>
# but finally deny all browsers which haven't upgraded
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
</Directory>
Fichier httpd.conf
# be liberal in general
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
<Location /strong/area>
# but https://hostname/strong/area/ and below requires strong ciphers
SSLCipherSuite HIGH:MEDIUM
</Location>
Client Authentication and Access Control
Fichier httpd.conf
# require a client certificate which has to be directly
# signed by our CA certificate in ca.crt
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt
Fichier httpd.conf
SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt
<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>
The first method
SSLVerifyClient none
<Directory /usr/local/apache/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Snake Oil Authentication"
AuthType Basic
AuthUserFile /usr/local/apache/conf/httpd.passwd
require valid-user
</Directory>
Fichier httpd.htaccess
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
The second method
Fichier httpd.conf
SSLVerifyClient none
<Directory "/var/www/html/area">
SSLVerifyClient require
SSLVerifyDepth 5
SSLCACertificateFile conf/ssl.crt/ca.crt
SSLCACertificatePath conf/ssl.crt
SSLOptions +FakeBasicAuth
SSLRequireSSL
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." and \
%{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
</Directory>
Fichier httpd.conf
SSLCACertificateFile conf/ssl.crt/company-ca.crt
<Directory /usr/local/apache/htdocs>
# Outside the subarea only Intranet access is granted
Order deny,allow
Deny from all
Allow from 192.168.1.0/24
</Directory>
<Directory /var/www/html/subarea>
# Inside the subarea any Intranet access is allowed
# but from the Internet only HTTPS + Strong-Cipher + Password
# or the alternative HTTPS + Strong-Cipher + Client-Certificate
# If HTTPS is used, make sure a strong cipher is used.
# Additionally allow client certs as alternative to basic auth.
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +FakeBasicAuth +StrictRequire
SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
# Force clients from the Internet to use HTTPS
RewriteEngine on
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond %{HTTPS} !=on
RewriteRule .* - [F]
# Allow Network Access and/or Basic Auth
Satisfy any
# Network Access Control
Order deny,allow
Deny from all
Allow 192.168.1.0/24
# HTTP Basic Authentication
AuthType basic
AuthName "Protected Intranet Area"
AuthUserFile conf/protected.passwd
Require valid-user
</Directory>
Journalisation conditionnelle
La récupération par un client d'une page web complète peut générer beaucoup de log: téléchargement des images, etc... On peut conditionner la journalisation.
La journalisation peut être conditionnelle et les variables d'environnement système contiennent une variable basée sur la requète. La directive CustomLog accepte une condition basée sur celle-ci.
- On créer une varible d'environnement conditionnée par la cible de la requète
- On applique notre filtrage sur les logs.
Ici on spécifie que l'on veut logguer uniquement les .html et .shtml dans le log:
SetEnvIf Request_URI "(\.html|\.shtml)$" html
CustomLog logs/access.log common env=html
Ici on spécifie que l'on veut tous logguer sauf les images dans le log (condition inverse):
SetEnvIf Request_URI "(\.gif|\.png|\.jpg)$" image
CustomLog logs/access.log common env=!image
Ici on dispatche les logs avec un filtre basé sur le premier répertoire de la requète:
SetEnvIf Request_URI "^/foo/" foo
SetEnvIf Request_URI "^/bar/" bar
CustomLog /logs/access_foo_log common env=foo
CustomLog /logs/access_bar_log common env=bar
Forcer l'utilisation d'https au lieu de http
Il suffit de rajouter, soit à la fin du fichier <path>/etc/httpd/conf/httpd.conf</path> pour tous les sites du serveur, soit dans la définition du vhost, ou encore dans un fichier htaccess les lignes suivantes
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}