Name: Apache 2.4 Installation et configuration
Rating: 5 (1 reviews)

Introduction

De par sa nature, Apache HTTP Server se veut exposé sur Internet et donc potentiellement soumis à des attaques de sécurité. Bien qu’il ait une bonne réputation, notamment grâce à sa communauté lui apportant une grande réactivité dans la publication de patchs en cas de découverte de failles, il est primordial de prendre quelques mesures sécuritaires : la première étant bien entendu de maintenir son système à jour. Il existe quelques précautions à prendre et des solutions à mettre en place permettant de limiter tout risque de compromission.

La version 2.4 apporte des améliorations de sécurité de par le paramétrage par défaut de certaines directives. Citons par exemple le passage de AllowOverride à None par défaut, évitant ainsi la potentielle utilisation du fichier .htaccess à la racine du serveur.


<Directory />  
      AllowOverride None 
      Require all denied  
</Directory>

Permissions de répertoire

Apache est démarré par l’utilisateur root, puis passe sous la propriété de l’utilisateur défini par la directive User, dans notre cas, httpd24 :


root     20990  0.0  0.2 144636  4888 ?        Ss   20:14    
0:00 /opt/prod/apache2.4/bin/httpd -k start  
httpd24  20993  0.0  0.1 135688  2124 ?        S    20:14    
0:00  \_ /opt/prod/apache2.4/bin/httpd -k start  
httpd24  20994  0.0  0.1 358120  4088 ?        Sl   20:14    
0:00  \_ /opt/prod/apache2.4/bin/httpd -k start  
httpd24  20995  0.0  0.1 358120  4080 ?        Sl   20:14    
0:00  \_ /opt/prod/apache2.4/bin/httpd -k start  
httpd24  20996  0.0  0.1 358120  4084 ?        Sl   20:14    
0:00  \_ /opt/prod/apache2.4/bin/httpd -k start

Il est donc important de s’assurer que les fichiers de configuration, mais aussi les répertoires (bin, logs, etc.) ne puissent pas être modifiables par un autre utilisateur que root.

Seuls les répertoires des DocumentRoot peuvent appartenir à d’autres utilisateurs, puisque l’utilisateur root n’accédera à aucun fichier dans...

Chroot d’Apache

Le chroot (change root) d’un programme consiste à enfermer l’exécution des processus dans un répertoire cible. Cette isolation permet ainsi d’éviter la compromission complète d’un système en cas d’exploitation d’une faille de sécurité par un pirate. Ce dernier sera cloisonné dans le chroot et ne pourra donc pas accéder à l’ensemble du système d’exploitation.

Le module Apache mod_unixd met à disposition la directive ChrootDir permettant d’indiquer à Apache le répertoire dans lequel il doit se positionner après avoir effectué un chroot.

Pour illustrer son utilisation, nous allons déployer notre environnement dans le répertoire /opt/chroot, avec :

/opt/chroot/apache : répertoire d’installation d’Apache.
/opt/chroot/opt/app1/www : répertoire de notre application App1 dans le chroot.
/opt/chroot/opt/app1/logs : répertoire contenant les logs de l’application App1dans le chroot.

Dans un premier temps, il s’agit donc de créer l’arborescence :


marty@vm-compilation-eni:~$ sudo mkdir /opt/chroot 
marty@vm-compilation-eni:~$ sudo mkdir /opt/chroot/opt 
marty@vm-compilation-eni:~$ sudo mkdir /opt/chroot/apache

1. Installation d’Apache dans le chroot

Dans le répertoire des sources, créez un layout CHROOT dans le fichier config.layout, définissant le prefix dans le répertoire chroot précédemment créé :


marty@vm-compilation-eni:~$ cd /opt/src/httpd-2.4.12/


# Layout Custom CHROOT  
<Layout CHROOT>  
    prefix:        /opt/chroot/apache  
    exec_prefix:   ${prefix}  
    bindir:        ${exec_prefix}/bin  
    sbindir:       ${exec_prefix}/bin  
    libdir:        ${exec_prefix}/lib  
    libexecdir:    ${exec_prefix}/modules  
    mandir:        ${prefix}/man  
    sysconfdir:    ${prefix}/conf  
    datadir:       ${prefix}  
    installbuilddir: ${datadir}/build...

Protection d’accès

Apache permet la protection d’accès à des ressources à l’aide de différents modules gérant l’autorisation et l’authentification.

Ces deux notions sont souvent confondues, il s’agit pourtant de deux mécanismes bien différents.

1. Autorisation d’accès

Le contrôle d’accès (ou autorisation) consiste à accorder ou refuser l’accès à une ressource en fonction de certaines conditions.

Ces conditions peuvent notamment être :

une appartenance à un réseau informatique (adresse IP, nom de domaine, etc.),
la présence d’un en-tête ou d’une variable envoyés lors d’une requête,
la validation d’un mécanisme d’autorisation.

a. Contrôle d’accès en fonction du réseau

S’il est nécessaire de donner l’accès à une ressource uniquement depuis un réseau, l’utilisation du module mod_authz_host est la plus indiquée.


LoadModule authz_host_module modules/mod_authz_host.so

À l’aide de la directive Require ip ou host, ainsi qu’avec ses déclinaisons (RequireAll, RequireAny, et RequireNone), de nombreuses possibilités de contrôle d’accès sont offertes.

Dans l’exemple ci-dessous, un contrôle d’accès sur le chemin /it_ops est effectué, indiquant que seuls les clients ayant pour adresse IP 10.75.1.x pourront y accéder :


<Location /it_ops/>  
      <Require>  
            Require ip 10.75.1  
      </Require>  
</Location>

Il est possible d’apporter un niveau de condition supplémentaire, par exemple :

toutes les conditions doivent être remplies,
au moins une condition doit être remplie,
aucune des conditions ne doit être remplie.

Exemples :

Dans l’exemple ci-dessous, les utilisateurs doivent remplir l’ensemble des conditions suivantes :

ils possèdent une adresse IP sur la plage 10.75.1.0/24
ils appartiennent aux groupes DSI
ils n’appartiennent pas au groupe Dev.


<Location /it_ops/>  
      <RequireAll>  
            Require ip 10.75.1...

Protection contre les attaques et limitation du trafic

1. Protection contre les attaques de type "déni de service"

Parmi la multitude d’attaques auxquelles un serveur web peut être exposé, celle du type DoS (Denial of Service) consiste en la saturation des ressources d’un serveur distant en lui envoyant un grand nombre de requêtes simultanées.

Il est possible de limiter l’impact de ce type d’attaques par différents moyens :

avec le filtrage en amont par des équipements de type firewall (pare-feu) ou des solutions dédiées au filtrage et à l’analyse du trafic, limitant le nombre de connexions pour une même adresse IP.
en ajustant les paramétrages de gestion des connexions d’Apache.
avec l’utilisation de modules Apache spécifiques à ce besoin.

a. Ajustement du paramétrage d’Apache

Différents paramétrages d’Apache peuvent aider à limiter l’impact d’une attaque de type DoS, notamment au niveau des directives liées aux connexions client :

Directive Timeout pouvant être diminuée, définissant le temps maximum pendant lequel le processus httpd attend lors du traitement des requêtes.
Directive KeepAliveTimeout, étant le délai en secondes pendant lequel Apache va attendre une requête avant de fermer la connexion.
Directive MaxRequestWorkers qui doit être ajustée de manière à définir le nombre maximum de connexions simultanées qu’Apache peut servir avant d’être à court de ressources.

b. Module mod_reqtimeout

Le module mod_reqtimeout permet de définir le délai maximum et le taux minimum de transfert des données pour la réception des requêtes.


LoadModule reqtimeout_module modules/mod_reqtimeout.so

Il limite donc les attaques de type « Slow Request » grâce à la directive RequestReadTimeout permettant de définir la limite de temps que met un client pour envoyer sa requête, suite à quoi un code d’erreur « 408 REQUEST TIME OUT » lui sera renvoyé.

Dans l’exemple ci-dessous, la requête doit se faire dans un délai de :

10 secondes pour la réception d’un en-tête.
30 secondes pour la réception...

Protocole de sécurisation SSL/TLS

1. Présentation et historique

SSL ou Secure Sockets Layer est un protocole de sécurisation des échanges, indépendant du protocole de service utilisé.

Il est donc possible d’utiliser le SSL (ou TLS) avec n’importe quel protocole réseau, tel que le FTP, les protocoles de messagerie POP, IMAP ou SMTP, et bien entendu le protocole des serveurs web, HTTP.

Les principaux objectifs lors de l’utilisation du SSL/TLS sont :

l’authentification des serveurs lors de la connexion,
la confidentialité et l’intégrité dans les données échangées,
l’authentification du client par le serveur.

L’historique des versions du SSL est :

1994 : première spécification du protocole, développé par Netscape SSL 1.0.
Février 1995 : version 2.0 qui sera la première version réellement utilisée.
Novembre 1996 : version 3.0, dernière version de SSL qui sera la base de son successeur, le TLS.

Le TLS (Transport Layer Security) fait alors son apparition afin de résoudre certaines faiblesses du SSL, notamment dans la génération des clés symétriques.

TLS conservera une compatibilité avec les versions précédentes du protocole SSL, jusqu’en 2011, où la compatibilité avec la version SSL 2 sera abandonnée pour des raisons de sécurité.

Les dates clés du TLS sont les suivantes :

Janvier 1999 : publication de la norme TLS 1.0, développée par l’IETF (Internet Engineering Task Force).
Avril 2006 : publication de la norme TLS 1.1.
Août 2008 : publication de la norme TLS 1.2.
Mars 2011 : abandon de la compatibilité avec SSLv2.

Pour sécuriser les données servies par Apache, SSL/TLS utilise des certificats numériques délivrés par une autorité de certification (AC). Cette organisation de confiance a pour mission de signer, d’émettre et de maintenir ces certificats, et de gérer les listes de révocation de certificats.

Un certificat est un document constitué de deux parties :

Informations sur l’entité à certifier, à savoir :

le nom de l’AC,
le nom du propriétaire du certificat...

Notions de sécurité