Installation Structure Configuration Directives Hôtes virtuels Modules Interception des erreurs & trace Contenu dynamique Authentification & SSL Proxy & Load Balancer Règles pour la performance et la sécurité

1. 17/03/14 1
APACHE HTTP
Rachid NID SAID
rachid.nidsaid@gmail.com

2. 17/03/14 2
Plan
 Introduction
 Installation
 Structure
 Configuration
 Directives
 Hôtes virtuels
 Modules
 Interception des erreurs & trace
 Contenu dynamique
 Authentification & SSL
 Proxy & Load Balancer
 Règles pour la performance et la
sécurité

3. Introduction
 Apache HTTP Server, est un serveur HTTP connu pour avoir joué
un rôle clé dans la croissance de l’Internet.
 Continuité du serveur NCSA HTTPd de l’université de l’Illinois et
alternative non payante de la solution Netscape Communications
Corporation web server (Sun Java System Web Server)
 Logiciel open source développé et maintenu par la communauté
Apache Software Foundation.
 Il représente le 1er
serveur HTTP en part de marché avec 52%,
devant Nginx 14% et IIS 11% (NetCraft Survey)
 L'application est disponible pour une grande variété de systèmes
d'exploitation, Unix, GNU, FreeBSD, Linux, Solaris, Novell
NetWare, Mac OS X, Microsoft Windows, OS2, …

4. Introduction
 Versions en cours :
 2.0.x : en mode maintenance, pas de nouveaux
développement
 2.2.x : en mode maintenance, pas de nouveaux
développement
 2.4.x : version actuelle
 2.5 : la nouvelle version en cours de développement
 Disponible sur le site http://httpd.apache.org/

5. Installation
 Le serveur Apache HTTP peut être téléchargé à
partir du site http://httpd.apache.org/download.cgi
 Apache offre deux sortes de livrables :
 Livrable binaire prêt a l’installation
 Code source de la version pour une compilation sur
la machine cible.
 cette option permet de mettre en place une
installation optimisé pour le besoin cible

6. Installation
Mode statique et mode dynamique
 L’architecture Apache est une architecture modulaire, et
seulement les fonctionnalités de base d’un serveur HTTP
sont disponible dans le noyau apache.
 Écoute réseau, interception des requêtes, traitement des
requêtes, envoi de la réponse.
 Toutes les autres fonctionnalités Apache sont gérés par
des modules externes.
 Contenu dynamique, journalisation, authentification, ssl, …

7. Installation
Mode statique et mode dynamique
 Mode dynamique : Les modules apaches sont
configurés dans le fichier de configuration httpd.conf
et peuvent être modifiés à tout moment
 Le module n’est chargé qu’au besoin
 Mode statique : Les modules apache sont définies
lors de la compilation et ne peuvent être modifiés
que par une autre compilation
 Identifier les modules de façon pertinente pour ne pas
être obligés de recompiler
 Chaque module incorporés est chargé en mémoire
même si elle n’est pas utilisé
 Performance accrue du serveur

8. Installation
Sous Unix like
 Extraction : $ gzip -d httpd-NV.tar.gz
$ tar xvf httpd-NV.tar
$ cd httpd-NV
 Configuration : $ ./configure --prefix=installPath
 pour charger un module en mode statique, utiliser l’option
–enabled-mods-static=‘mod1 mod2 mod3’.
 Compilation : $ make
 Installation : $ make install
 Test : $ installPath/bin/apachectl -k start
accéder à l’url : http://localhost
Pour plus de détail sur la procédure d’installation voir le document
Compilation et installation sous Unix

9. Installation
Sous Unix like

10. Installation
Sous Unix like
 Démarrage :
installPath/bin/apachectl -k start
installPath/bin/apachectl -k start –f path-to-configFile.conf
 Arrêt :
installPath/bin/apachectl -k stop
installPath/bin/apachectl -k graceful-stop
kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
 Redémarrage :
installPath/bin/apachectl -k restart
installPath/bin/apachectl -k graceful
 Tester le fichier de configuration :
installPath/bin/apachectl -k configtest
installPath/bin/apachectl -k configtest –f path-to-configFile.conf

11. Installation
Sous Unix like
 La plupart des distributions Linux modernes offre un
package apache prêt pour installation :
 Debian et Ubuntu :
 Installation : apt-get install apache2
 CentOS, Fedora, Red Hat :
 Installation : yum install httpd

12. Installation
Sous Windows
 Apache offre aussi la possibilité de compiler le code
source pour la plateforme Windows
 Utiliser l'environnement de développement Visual
Studio de VC++
 Il est possible d’installer Apache en tant que service
httpd.exe -k install -n "nom-service"
Pour plus de détail sur la procédure d’installation voir le document
Compilation et installation sous Windows

13. Structure
Section Windows Unix
Chemin
d’Install par
défaut
C:Program FilesApache
Group
Apache2
/usr/local/apache2
Exécutable et
scripts
bin/apache.exe
bin/
bin/httpd
bin/
Fichiers de log log/error.log
log/access.log
log/httpd.pid
log/error.log
log/access.log
log/httpd.pid
Fichier de
configuration
conf/httpd.conf conf/httpd.conf
Scripts CGI cgi-bin cgi-bin

14. Structure
Section Windows Unix
Fichiers entêtes .h Include/
build/
Messages
d’erreurs
error/ error/
Modules et
bibliothèques
modules/
lib/
modules/
lib/
Documentation manual/ manual/
Emplacement par
défaut des fichiers
html
htdocs/ htdocs/

15. Configuration
 Les fichiers de configuration sont placés dans le
dossier conf, selon les distributions le fichier par
défaut est soit httpd.conf soit apache2.conf
 Pour utiliser un autre fichier autre que le fichier par
défaut, il faut informer Apache de l’emplacement du
nouveau fichier
httpd –f /path/to/httpd/file.conf

16. Configuration
 Directives : paramètres pour configurer et contrôler
la comportement du serveur Apache tels que les
droits d’accès, les ports d’écoute, …
 Sections : identifient le contexte dans le quel les
directives sont appliqués. Par exemple les directives
de droit d’accès peuvent s’appliquer sur l’ensemble
du serveur ou bien sur un dossier spécifique.

17. Configuration
Sections
Directive Description
Directory/
DirectoryMatch
Définie un répertoire par son chemin ou bien
par une expression régulière pour
DirectoryMatch
Files / FilesMatch Définie une liste de fichiers par leurs chemins
ou bien par une expression régulière pour
FilesMatch
If / ElseIf / Else Définie une condition qui doit être réalisé lors
du traitement d’une requête pour appliquer les
directives.
<If "-z req('Host')">
…
</If>
Les expressions dans le serveur HTTP Apache
IfDefine Définie une condition qui doit être réalisé lors
du démarrage du serveur pour appliquer les
directives, il prend en argument un paramètre
fourni par –D à la commande de démarrage
httpd
IfDefine peuvent être imbriqués

18. Configuration
Sections
Directive Description
IfModule Les directives ne seront appliqués que si un
module est chargé ou pas.
<IfModule [!] nomModule>
IfModule peuvent être imbriqués
IfVersion Les directives ne seront appliqué que si la
version est la même
Utilisent les opérateurs logiques pour le test
<IfVersion >= 2.1.5>
Location / LocationMatch Similaire à la directive Directory, mais utilise
des URL au lieu de nom de dossier
Proxy / ProxyMatch Utilisé si Apache est configuré en tant que
proxy, et ne s’appliquent que sur le contenu
mandaté
Il prend en argument une URL ou une
expression régulière
VirtualHost S’appliquent à un hôte virtuel et permet
d’indiquer les directives appliqués pour un hôte
virtuel identifié par NameVirtualHost

19. Configuration
Sections
 Certains types de sections peuvent être imbriqués
 on peut utiliser les sections <Files> à l'intérieur des
sections <Directory>,
 on peut utiliser les directives <If> à l'intérieur des
sections <Directory>, <Location> et <Files>.
 On peut utiliser les directives <if> à l’intérieur d’autres
directives <If>
 On peut utiliser n’importe quelle section au sein de la
section <virtualHost>

20. Configuration
Sections
 L’ordre d’application des sections suit l’ordre
suivant :
1. Les sections <Directory> (à l'exception des
expressions régulières) et les fichiers .htaccess sont
appliqués simultanément
2. Les sections <DirectoryMatch> et <Directory ~>
3. Les sections <Files> et <FilesMatch> sont appliquées
simultanément
4. Les sections <Location> et <LocationMatch> sont
appliquées simultanément
5. Les directives <If>

21. Configuration
Sections
 Pour chaque type de section, les directives sont
appliqués dans leurs ordre d’apparition dans le
fichier de configuration
 Pour la section <Directory>, les sections sont
traitées dans l'ordre du répertoire, du plus court
vers le plus long
 Les sections situées à l'intérieur de
sections <VirtualHost> sont appliquées après les
sections correspondantes situées en dehors de la
définition de l'hôte virtuel, ce qui permet à l'hôte
virtuel de prévaloir sur la configuration du serveur
principal.

22. Configuration
Directives : Adresse IP et Ports d’écoute
 La directive Listen signifie à Apache de se mettre à
l'écoute sur les adresses IP et ports spécifiés et de
n’accepter des requêtes entrante que sur les ports
et l’interface réseau spécifiés
Listen [<IP>:]<Port Number> [protocole]
 La directive <Listen> accepte des adresse IPV6
Listen [2001:db8::a00:20ff:fea7:ccea]:80

23. Configuration
Directives : configuration de base
 ServerName permet de définir un nom pour identifier le
serveur, ce nom est utile lors de l’utilisation des
redirections ou de l’utilisation du serveur en tant que
frontal
ServerName [protocole://]domain name or ip adress[:port]
 User, Group indiquent au serveur de traiter les requêtes
avec les privilèges de l’utilisateur ou du groupe spécifié.
User userName
Group groupeName
 Pour utiliser ces directives le serveur doit être démarré en
tant que root
 Il faut faire attention à l’utilisateur ou groupe et de ne pas
utiliser un avec des privilèges trop fort et trop étendues

24. Configuration
Directives : configuration de base
 ServerRoot indique le répertoire racine ou est
installé apache .
ServerRoot installPath
 DocumentRoot indique le répertoire par défaut ou
sont stocké les fichiers visible depuis Internet
DocumentRoot path
 Si le path ne commence pas par un /, il est considéré
comme sous dossier du ServerRoot

25. Configuration
Directives : dossier virtuel
 Apache permet de rendre visible des documents et
du contenu qui n’est pas disponible sous le dossier
DocumentRoot.
 Ce comportement est possible grâce à la directive
Alias.
Alias <virtualdirectory> <real directory>
 Exemple :
Alias /image /ftp/pub/image
http://www.demaine.com/image/pic.gif

26. Configuration
Directives : Redirect
 Dans le cas d’un changement d’url ou d’une
migration de domaine, il est préférable de garder
l’ancienne url pour un certain temps pour ne pas
perturber les utilisateurs
 La directive Redirect (RedirectMatch) permet de
réaliser ce comportement, et de faire correspondre
une ancienne URL à une nouvelle.
Redirect [etat] oldPath url
 etat : indique un code HTTP indiquant le type de
redirection

27. Configuration
Directives : Include
 La directive Include permet d’inclure le contenu d’un
fichier de configuration dans le fichier appelant
Include filePath|folderPath|wildcard
 Cette directive permet d’organiser la configuration
apache d’un telle façon que le fichier racine ne devient
pas ingérable.
 Les directives contenu dans le fichier inclus sont
intégrés dans l’ordre d’apparition de la directive
Include dans le fichier appelant
 IncludeOptional, même comportement qu’Include
sauf si le dossier spécifié n’existe pas, apache ne
génère pas d’erreur à la différence d’Include

28. Configuration
Directives : fichier de configuration distribué
 Apache offre un mécanisme très fort pour pouvoir
redéfinir des directives de configuration de façon fine et
distribué.
 La directive AccessFileName permet ce mécanisme en
spécifiant un nom de fichier que apache va vérifier à
chaque requête et pour chaque dossier de l’url de la
requête
AccessFileName .htaccess
 Contenu du fichier .htaccess
AllowOverride All|None|type directive [types directive…]
 Mécanisme à utiliser avec parcimonie, il a de forts impact
sur les performance du serveur, préférer l’utilisation de la
section <Directory>

29. Configuration
Directives : Contrôle d’accès
 Le directive Require fournit un mécanisme très riche
pour configurer un contrôle d’accès à des
ressources du serveur
 Require all granted : l’accès est autorisé sans restriction
 Require all denied : l’accès est refusé sans restriction
 Require env env_variable [env-var] … : l’accès est autorisé si le
variable d’environnement est définie
 Require method http-method [http-method] … : l’accès n’est autorisé
que pour les méthodes HTTP spécifié
 Require user iserID [userID] … : l’accès est autorisé pour les
utilisateurs indiqués
 Require group groupeName [groupName] … : l’accès est autorisé pour
les membres des groupes indiqués
 Require valid-user : l’accès est autorisé pour tout utilisateur valide
 Require ip adresseIP [adresseIP] … : l’accès est autorisé pour les
requêtes dont la source sont les adresses IP

30. Configuration
Directives : Contrôle d’accès
 RequireAll permet de regrouper des directives d’accès
Require dont aucune ne doit échouer pour permettre
l’accès
 RequireAny permet de regrouper des directives d’accès
Require dont au moins doit être positif pour permettre
l’accès
 RequireNone permet de regrouper des directives d’accès
Require dont aucune ne doit être positif pour permettre
l’accès
Les directives de contrôle d’accès s’appliques seulement dans
la section Directory ou bien au sein d’un fichier .htaccess

31. Configuration
Directives : Contrôle d’accès
SetEnvIf User-Agent geck1_8 let_me_in
<Directory /www/mydocs>
<RequireAll>
<RequireAny>
Require user superadmin
<RequireAll>
Require group admins
Require ldap-group cn=Administrators,o=Airius
<RequireAny>
Require group sales
Require ldap-attribute dept="sales"
</RequireAny>
</RequireAll>
</RequireAny>
<RequireNone>
Require env let_me_in
Require ldap-group cn=Temporary Employees,o=Airius
</RequireNone>
</RequireAll>
</Directory>

32. Configuration
Hôtes virtuels
 Le principe des Hôtes Virtuels consiste à faire
fonctionner un ou plusieurs domaines Web sur une
même machine. L'utilisateur final ne perçoit pas
qu'en fait il s'agit d'une même machine.
 Le configuration d’un hôte virtuel est faite par la
directive VirtualHost
<VirtualHost [IP ADDRESS:PORT] >
ServerAdmin
DocumentRoot
ServerName
ServerAlias
ErrorLog
</ VirtualHost >

33. Configuration
Hôtes virtuels
 Il existe deux façons pour identifier des hôtes virtuels :
 Par adresse IP : l’hôte virtuel est identifié sur la base
d’un couple adresse IP et port.
 Pour pouvoir utiliser des adresses IP différentes pour
chaque hôte, la machine doit avoir un interface réseau
pour chaque adresse IP
 Apache doit être à l’écoute du port choisi au niveau de
la configuration serveur via la directive Listen
 Par nom de domaine : l’hôte virtuel est identifié sur la
base d’un nom de domaine « www.mondomaine.com »
 Le nom de domaine doit déjà être associé à l’adresse
IP de la machine au niveau du DNS

34. Configuration
Hôtes virtuels
Définition de serveurs virtuels à base d’adresse IP :
Listen 172.20.30.40:80
Listen 172.20.30.50:8080
<VirtualHost 172.20.30.40:80>
DocumentRoot /www/example1-80
ServerName www.example.com
Directives …
</VirtualHost>
<VirtualHost 172.20.30.50:8080>
DocumentRoot /www/example2-8080
ServerName www.example.org
Directives …
</VirtualHost>

35. Configuration
Hôtes virtuels
Définition de serveurs virtuels par nom IP :
1. Serveur qui répond au nom de domaine www.example.com et
site.example.com
2. Serveur qui répond au nom de domaine other.example.com
3. Serveur qui répond à toute autre requête qui ne cible pas les
domaines précédents
<VirtualHost *:80>
ServerName www.example.com
ServerAlias www.example.com site.example.com
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *:80>
ServerName other.example.com
DocumentRoot /www/otherdomain
</VirtualHost>
<VirtualHost _default_:*>
DocumentRoot /www/default
</VirtualHost>

36. Configuration
Modules DSO
 L’architecture modulaire du serveur APACHE permet
de fournir un produit performant pour répondre à
divers besoins :
 Disponibilité sur une très grande variété de
plateformes et d‘OS. Ne reconstruire que les modules
qui le nécessitent pour la plateforme cible.
 Souplesse de configuration et de mise en place d’une
plateforme performante et optimisé pour les besoins
de la production Cette conception autorise. N’intégrer
que les fonctionnalités (modules) nécessaire pour la
plateforme.

37. Configuration
Modules DSO
 Lors du chargement en mémoire, les modules DSO
mènent une existence séparée du processus
principal httpd.
 Les modules sont chargés de deux façons :
 Statique, Les modules DSO sont compilés en même
temps que le serveur,
 Dynamique : Les modules sont chargé via la directive
loadModule du module mod_so.
LoadModule module nom-fichier
 Les deux modules mod_so et core sont les seules
modules qui ne peuvent être chargé de façon
dynamique et le sont toujours de façon statique.

38. Configuration
Modules DSO

39. Configuration
Modules DSO
 Traduction des URI en chemin physique :
 mod_userdir : gestion des dossiers personnels des
utilisateurs
 mod_rewrite : moteur de réécriture à base de règles
permettant de réécrire les URLs des requêtes à la
volée
 Authentification / gestion d’accés :
 mod_auth, mod_auth_anon,mod_auth_db,
mod_auth_dbm : gestion d’authentification des
utilisateurs.
 mod_access : gestion des accès au ressources du
système.
 Journalisation:
 mod_log_*: journalisation

40. Configuration
Modules DSO
 Identification des MIME types :
 mod_mime : associe les extensions des fichiers
demandés avec l'action déclenchée par ces fichiers et
avec leur contenu (type MIME, langue, jeu de
caractère et codage) .
 mod_mime_magic : détermine le type MIME d'un
fichier à partir de de son contenu "magic numbers"
(e.g. fichiers gif démarrent avec le même contenu)
 Gestion de URL :
 mod_alias : permet d’accéder à certaines parties du
système qui ne sont pas public
 mod_env : création de variables d’environnement
 mod_speling : correction automatique des URL

41. Configuration
Modules DSO
 Gestion de la réponse :
 mod_actions : identifier les types de fichiers qui sont
des exécutables CGI
 mod_autoindex : construction automatique de l’index
d’un répertoire lors de sa consultation
 mod_cgi : gestion du contenu CGI
 mod_include : gestion des directives SSI
 mod_dir : Permet la redirection des adresses se
terminant par un répertoire sans slash de fin et la mise
à disposition des fichiers index de répertoire.
 mod_imagemap : Traitement des cartes des zones
interactives d'une image (imagemaps) au niveau du
serveur

42. Configuration
Modules DSO : Avantages
 Le construction du serveur est plus flexible à l'exécution car
le processus serveur peut être assemblé à l'exécution via la
directive LoadModule du fichier de configuration plutôt que
par des options du script configure à la compilation.
 Par exemple, on peut exécuter différentes instances du
serveur (standard et version SSL, version minimale et version
dynamique [mod_perl, mod_php], etc...) à partir d'une seule
installation d'Apache httpd.
 Le construction du serveur peut être facilement étendu avec
des modules tiers, même après l'installation.
 Facilité de montée en version des modules statiques
 apxs permet de travailler en dehors de l'arborescence des
sources d'Apache, et de n'avoir besoin que de la
commande apxs pour introduire une nouvelle version du
module fraîchement développé, dans le serveur HTTP Apache
en cours d'exécution.

43. Configuration
Modules DSO : Inconvénients
 Le serveur est environ 20 % plus lent au démarrage à cause
des résolutions de symboles supplémentaires que le chargeur
Unix doit effectuer.

44. Configuration
Interception des erreurs & trace
 ErrorLog définit le nom du fichier dans lequel le serveur va
journaliser toutes les erreurs qu'il rencontre.
ErrorLog filePath
 La syntaxe Loglevel syslog permet de rediriger la sortie log vers le
journal système.
 LogLevel définit le niveau de détail (verbosité) des
messages enregistrés dans les journaux d’erreurs
LogLevel level
 La syntaxe Loglevel nomModule:level permet de spécifier un niveau de
log pour un module donné
 PidFile définit le nom du fichier dans lequel le serveur va
journaliser les identifiants du processus apache

45. Configuration
Interception des erreurs & trace

46. Configuration
Interception des erreurs & trace
 CustomLog permet d’activer la journalisation de des
requêtes destinées au serveur et d’en spécifier une
politique.
 Nécessite l’activation du module mod_log_config
CustomLog fichier|pipe format|alias [env=[!]variable-environnement|
expr=expression]

47. Configuration
Interception des erreurs & trace
# Journal personnalisé avec alias de format
LogFormat "%h %l %u %t "%r" %>s %b" common
CustomLog logs/access_log common
SetEnvIf Request_URI .gif$ gif-image
CustomLog gif-requests.log common env=gif-image
CustomLog "|/usr/local/apache/bin/rotatelogs
/log/access_log 86400" common

48. Contenu dynamique
CGI
 CGI (Common Gateway Interface) permet de définir
une interface de communication entre un serveur
HTTP et un programme exécutable qui renvoi vers le
serveur du contenu HTML pour affichage
 C’est cette interface qui a permis de rendre le WEB
dynamique
 Le plus populaire des langages de programmation
CGI est PHP

49. Contenu dynamique
CGI
 Apache est capable de s’interfacer avec CGI pour
permettre de communiquer avec des programmes
externes
1. Charger le module CGI apache cgi_module, s’il n’est pas
chargé en statique
LoadModule cgi_module path/mod_cgi.so
2. Définir l’emplacement des fichiers programmes
 Au niveau serveur :
ScriptAlias /scripts/ /usr/local/apache2/cgi-bin/
 Au niveau dossier :
<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>
2. Identifier les type de fichiers (extension) qui sont des
programmes
AddHandler cgi-script .cgi .pl .php

50. Contenu dynamique
CGI
 Configurer Apache pour traiter du contenu PHP en
tant que programme CGI:
ScriptAlias /scripts/ scripts/php/
AddHandler cgi-script .php
AddType application/x-httpd-php .php
Action application/x-httpd-php
/usr/bin/php/php-cgi.exe

51. Contenu dynamique
SSI
 SSI pour Server Side Includes
 C’est un mécanisme d’intégrer dans des pages HTML du
code qui est interprété et évalué coté serveur, sans
utiliser un langage CGI ou toute autre technologie coté
serveur.
<!--#fonction attribut=valeur attribut=valeur ... -->
 Exemples :
<!--#config timefmt="%A" -->
<!--#echo var="DATE_LOCAL" -->
<!--#include virtual="/cgi-bin/counter.pl" -->
<!--#flastmod file="ssi.shtml" -->

52. Contenu dynamique
SSI
1. Indiquer à apache la prise en charge des directives
SSI
Options +Includes
 Cette directive peut être ajouté au niveau serveur,
hôte virtuel, ou répertoire
2. Indiquer quels fichiers sont concernés par la prise
en charge de directives
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml

53. Configuration
Authentification par mot de passe
 L’authentification est le mécanisme qui permet de
vérifier qu’un utilisateur est bien celui qu’il prétend
être.
 Authentification par mot de passe
 Authentification par certificat SSL
 Apache fournit un ensemble de modules qui
permettent de configurer un mécanisme
d’authentification complet est riche.
 mod_auth_basic, mod_auth_digest, mod_authn_anon,
mod_authn_dbd, mod_authn_dbm, mod_authn_file,
mod_authnz_ldap, mod_authn_socache.

54. Configuration
Authentification par mot de passe
 La directive AuthType permet d’activer
l’authentification au niveau d’Apache et d’indiquer
de quelle façon elle va être géré.
 Deux types sont disponibles :
 mod_auth_basic : permet d’activer une
authentification basique par de mot passe
AuthType basic
 mod_auth_digest : même mécanisme que le
précedent, sauf que le mot de passe envoyé du client
vers le serveur est crypté.
AuthType Digest

55. Configuration
Authentification par mot de passe
 La directive AuthBasicProvider (AuthDigestProvider)
permet d’indiquer le fournisseur utilisé pour identifier et
authentifier les utilisateurs.
 mod_authn_file : les utilisateurs et les mots de passe sont
stockés dans un fichier texte.
AuthBasicProvider file
 mod_authn_dbm : les utilisateurs et les mots de passe sont
stockés dans un fichier dbm.
AuthBasicProvider dbm
 mod_authn_dbd : les utilisateurs sont stockés au niveau
d’une base de données
AuthBasicProvider dbd
 mod_authnz_ldap : les utilisateurs sont stockés au niveau
d’un annuaire LDAP
AuthBasicProvider ldap

56. Configuration
Authentification par mot de passe
 Les directives d’authentification sont insérés soit au
sein de la section <Directory>, soit au sein des
fichiers .htaccess
 Pour l'utilisation de fichiers .htaccess, ne pas oublier
d’utiliser la directive AllowOverride, qui spécifie
quelles directives pourront éventuellement être
redéfinie.
AllowOverride AuthConfig

57. Configuration
Authentification par mot de passe
# htpasswd -c /path/to/passwordFile userName
New password: mot-de-passe
Re-type new password: mot-de-passe
Adding password for user userName
<Directory /var/www/html/private>
AuthName ‘user and password please !.’
AuthType Basic
AuthBasicProvider file
AuthUserFile /path/to/passwordFile
Require valid-user
</Directory>

58. Configuration
Authentification par mot de passe
<Directory /www/docs/private>
AuthName "Private«
AuthType Basic
AuthBasicProvider file ldap
AuthUserFile /usr/local/apache/passwd/passwords
AuthLDAPURL ldap://ldaphost/o=yourorg
AuthGroupFile /usr/local/apache/passwd/groups
Require group GroupName
Require ldap-group cn=mygroup,o=yourorg
</Directory>

59. Configuration
Authentification par mot de passe
# configuration de mod_dbd
DBDriver pgsql
DBDParams "dbname=apacheauth user=apache pass=xxxxxx"
DBDMin 4
DBDKeep 8
DBDMax 20
DBDExptime 300
<Directory /usr/www/mon.site/team-private/>
# configuration de mod_authn_core et mod_auth_basic pour mod_authn_dbd
AuthType Basic
AuthName Team
AuthBasicProvider dbd
# requête SQL de mod_authn_dbd pour authentifier un utilisateur qui se
connecte
AuthDBDUserPWQuery "SELECT password FROM authn
WHERE user = %s AND login = 'true'"

60. Configuration
Authentification par mot de passe
# le processus de connexion dbd exécute une requête pour enregistrer la
connexion de l'utilisateur
Require dbd-login
AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE
user = %s"
# configuration de mod_authz_core pour mod_authz_dbd
Require dbd-group team
# configuration de mod_authz_dbd
AuthzDBDQuery "SELECT group FROM authz WHERE user = %s"
# lorsqu'un utilisateur échoue dans sa tentative d'authentification ou
# d'autorisation, on l'invite à se connecter ; cette page doit
# contenir un lien vers /team-private/login.html
ErrorDocument 401 /login-info.html
<Files login.html>

61. Configuration
Authentification par mot de passe
# il n'est pas nécessaire que l'utilisateur soit déjà connecté !
AuthDBDUserPWQuery "SELECT password FROM authn
WHERE user = %s"
# redirige l'utilisateur vers la page d'origine (si elle existe) après une
connexion réussie
AuthzDBDLoginToReferer On
</Files>
<Files logout.html>
# le processus de déconnexion dbd exécute une requête pour enregistrer la
déconnexion de l'utilisateur
Require dbd-logout
AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE
user = %s"
</Files>
</Directory>

62. Configuration
Authentification par mot de passe & SSL
 La 1er
étape pour intégrer du SSL est de charger le module
ssl_module
LoadModule ssl_module modules/mod_ssl.so
SSLVerifyClient none
SSLCACertificateFile path/ssl.crt/ca.crt
SSLCACertificatePath path/ssl.crt
<Directory /usr/local/apache2/htdocs/secure/area>
SSLVerifyClient require
SSLVerifyDepth 5
SSLOptions +FakeBasicAuth
SSLRequireSSL
AuthName "Authentication"
AuthType Basic
AuthBasicProvider file
AuthUserFile /usr/local/apache2/conf/httpd.passwd
Require valid-user
</Directory>

63. Proxy
 Le serveur Apache est capable le rôle d’un proxy au
sein d’une architecture réseau que ce soit en tant
que proxy directe ou bien en tant que reverse proxy
(frontal ou passerelle).
 Proxy Directe : Serveur intermédiaire qui s'intercale
entre le client et le serveur demandé. Pour obtenir un
contenu hébergé sur un serveur externe, le client envoie
sa requête au proxy en nommant le serveur demandé
comme cible, c’est le proxy qui est responsable de
contacter le serveur cible, de récupérer le contenu depuis
le serveur demandé et de le renvoiyer vers le client.
 Reverse proxy : apparaît au client comme étant le
serveur web qui héberge le contenu. Et c’est ce dernier
qui sait où renvoyer les requêtes clients pour récupérer le
contenu et le renvoyer client comme s'il l'hébergeait lui-
même.

64. Proxy

65. Proxy

66. Proxy
 Le module mod_proxy est le responsable des
fonctionnalités proxy du serveur APACHE
 Proxy directe :
 Directive ProxyRequests active le proxy directe
 Directive ProxyVia, elle est est optionnel, elle indique au serveur de
mettre à jour l’entete HTTP « via » pour indiquer le chemin suivi par la
requête
ProxyRequests On
ProxyVia On
# ne permettre l’utilisation du proxy que pour les machines locaux
<Proxy *>
Require ip 182.125
</Proxy>

67. Proxy
 Reverse Proxy :
 Directive ProxyPass active le reverse proxy, elle associe une
location au niveau local à une adresse distante
 Directive ProxyPassReverse nécessaire lors de l’activation du
reverse proxy, elle force le serveur à ajuster les entêtes HTTP
location et URI afin d’éviter de court-circuiter le reverse proxy
lors des redirections dans le serveur distant.
ProxyPass /mirror/foo http://foo.example.com/bar
ProxyPassReverse /mirror/foo http://foo.example.com/bar
<Location /mirror/foo>
ProxyPass http://foo.example.com/bar
ProxyPassReverse http://foo.example.com/bar
</Location>

68. Répartition de charge
 La répartition de charge (load balancing) est un
ensemble de techniques permettant de distribuer
une charge de travail entre différents ordinateurs
d'un groupe.
 L’activation de la répartition de charge nécessite le
chargement des modules mod_proxy,
mod_proxy_balancer, et l’un des modules suivant
pour l’algorithme de planification de la répartition
 mod_lbmethod_byrequests : nombre de requêtes
 mod_lbmethod_bytraffic : taille du trafic
 mod_lbmethod_bybusyness : requêtes en attente
 mod_lbmethod_heartbeat : comptage de trafic Heartbeat,
nécessite le mod_heartbeat et mod_heartmonitor au niveau
des membres

69. Répartition de charge
 La directive BalancerMember définit les nœuds qui
participent à la répartition de charge
 Le paramètre lbmethod indique quel algorithme est utilisé
pour la répartition
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.50:80
BalancerMember http://192.168.1.51:80
ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass /test balancer://mycluster
ProxyPassReverse /test balancer://mycluster

70. Répartition de charge
 Répartition de charge avec abonnement :
ProxyPass /test balancer://mycluster stickysession=JSESSIONID|
jsessionid scolonpathdelim=On
ProxyPassReverse /test balancer://mycluster
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.50:80 route=node1
BalancerMember http://192.168.1.51:80 route=node2
</Proxy>
Au niveau des serveurs membres :
ProxyPass route=node1
ProxyPass route=node2

71. Répartition de charge
 Apache fournit un module pour pouvoir gérer le
répartiteur de charge de façon dynamique via un
gestionnaire.
1. Activer le module mod_status
2. Au niveau de fichier de config :
<Location /balancer-manager>
SetHandler balancer-manager
Require host serveur
</Location>
3. Accéder au gestionnaire sur l’url
http://serveur/balancer-manager

72. Règles pour la performance et la
sécurité
 Ne Jamais exécuter Apache comme root de la machine
 Utiliser un utilisateur dédié
 Utilisateur sans shell
 Utilisateur sans mot passe valide
 Désactiver les modules qui ne sont pas utilisés
 Si l’accès à des dossiers n’est pas nécessaire, désactiver le
module mod_autoindex
 Faire attention aux modules et directives CGI et SSI,
 ne les configurer que pour les ressources qui ont en besoin
(jamais au niveau serveur)
 Ne garder que les directives Listen qui sont actives

73. Règles pour la performance et la
sécurité
 Nettoyer le fichier de config, vérifier les directives
include et supprimer ceux qui ne sont pas
necessaire.
 Éviter d’utiliser les fichiers de configurations distribués
.htaccess
 préférer la directive Directory au niveau du fichier de
configuration
 Bien étudier la politique d’activation des modules
(statique / dynamique)
 L’activation statique sollicite la mémoire de la machine
 L’activation dynamique sollicite le processeur de la
machine

74. Règles pour la performance et la
sécurité
 Utiliser le module mod_cache pour accélérer le
rendu du contenu dynamique
 Le niveau de journalisation doit être bien étudié
 un niveau trop fin engendre des écritures qui ne
sont nécessaires.
 Les journaux doivent être situé dans un disk autre
que le disk apache
 Utiliser la journalisation par programme que par
fichier directe

75. Atelier
1. Configurer un serveur Apache avec 2 hôtes virtuels
par nom
1. Le 1er
nécessite une authentification, utiliser mdb
comme provider
1. Le sous dossier /private, ne doit être accessible que
pour l’utilisateur specialUser
2. Activer Customlog au niveau de cet hôte
2. Le 2éme est à accès public, est accepte les directives
SSI
3. Bloquer l’accés au site par défaut du serveur.
2. Configurer un cluster avec 3 serveur, 1 proxy
reverse et 2 serveurs membres.