HTTPD

De The Linux Craftsman
Aller à la navigation Aller à la recherche
HTTP HTTPS
Protocole tcp tcp
Port 80 443
Configuration Iptables iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT iptables -I INPUT 2 -p tcp --dport 443 -j ACCEPT

Préparation

Dans un premier temps, il faudra avoir une connexion à Internet, utiliser un serveur DNS et désactiver SELinux.

Pour ceux qui auraient manqué des étapes les voici:

Une fois ces étapes effectuées, entrons dans le vif du sujet !

Installation

HTTP

# yum -y install httpd

HTTP et HTTPS

# yum -y install httpd mod_ssl

Configuration de base

Avant le premier démarrage

Tout d'abord il faut paramétrer le nom de la machine ainsi que l'adresse d'écoute

Pour cela cherchez dans le fichier /etc/httpd/conf/httpd.conf les lignes commençant par :

  • Listen 80
  • #ServerName www.example.com:80

La première doit contenir l'adresse IP de la machine ou * pour que httpd écoute sur toutes les interfaces 

Listen *:80

La deuxième doit être cohérente avec le nom de la machine qui est précisé dans le fichier network 

ServerName web:80

Premier démarrage

Maintenant on peut démarrer httpd 

# service httpd start
Démarrage de httpd :                                       [  OK  ]

Vérification

On peut vérifier que httpd écoute sur la bonne adresse et les bons ports 

# netstat -atnp | grep httpd
tcp        0      0 :::80                       :::*                        LISTEN      1202/httpd
tcp        0      0 :::443                      :::*                        LISTEN      1202/httpd

Enregistrement dans le chargeur de démarrage

# chkconfig httpd on

Ajout d'une page html

Le dossier de travail de httpd est précisé grâce à la variable DocumentRoot qui a la valeur /var/www/html

Vous pouvez donc créer votre premier site web en ajoutant dans ce dossier le fichier désigné par la variable DirectoryIndex (généralement index.html) 

# vi /var/www/html/index.html

Une fois le fichier édité, il ne faut pas oublier de repositionner les bons droits pour qu'apache soit apte à le lire 

# chown apache.apache -R /var/www/html

Parcours des logs

httpd log dans le répertoire /var/log/httpd/ et utilise deux fichiers:

  • access_log → pour journaliser tous les accès
  • error_log → pour journaliser toutes les erreurs

Démarrage et erreurs

Le fichier /var/log/httpd/error_log est fait pour ça. Quand vous avez une erreur PHP ou autre, c'est ici qu'il faut venir faire un tour: 

[Sat Feb 15 02:32:53 2014] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Feb 15 02:32:53 2014] [notice] Digest: generating secret for digest authentication ...
[Sat Feb 15 02:32:53 2014] [notice] Digest: done
[Sat Feb 15 02:32:54 2014] [notice] Apache/2.2.15 (Unix) DAV/2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips configured -- resuming normal operations

Vérifier l'accès aux pages

Pour vérifier qui demande quoi sur à votre serveur, c'est dans le fichier /var/log/httpd/access_log qu'il faut venir regarder: 

192.168.200.254 - - [30/Dec/2013:13:43:38 +0100] "GET / HTTP/1.1" 200 130 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:39 +0100] "GET / HTTP/1.1" 304 - "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:42 +0100] "GET / HTTP/1.1" 200 14 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"
192.168.200.254 - - [30/Dec/2013:13:43:45 +0100] "GET / HTTP/1.1" 200 130 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

favicon.ico ??

Quand on parcourt le fichier access_log on peut croiser la ligne suivante 

192.168.200.12 - - [28/Dec/2013:19:58:13 +0100] "GET /favicon.ico HTTP/1.1" 404 278 "-" "Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0"

Et on peut se demander pourquoi le navigateur demande favicon.ico ?? En fait, il s'agit de l'icône qui figure dans l'onglet, à côté du titre

Fireforx favicon tab.png → Favicon tlc.png

Vous pouvez la générer grâce au site suivant www.favicon.cc et la placer à la racine du site web (/var/www/html)

Plusieurs Vhosts et une seule favicon

Si vous désirez une favicon pour plusieurs vhost, utilisez des alias: 

<Location "/favicon.ico">
    SetHandler none
</Location>

Alias /favicon.ico /var/www/html/favicon.ico

Favicon pas dans la DocumentRoot

Si votre favicon n'est pas dans la DocumentRoot (directive d'Apache) de votre site web, il faudra la rendre exécutable pour qu'Apache puisse la servir 

# chmod +x /chemin/vers/favicon.ico

Fonction Virtual Host

La fonction Vhost permet de faire tourner plusieurs sites Web différents sur un même serveur. Les moyens de différenciation sont multiples:

  • le port TCP
  • l'adresse IP
  • le nom DNS
  • un sous-ensemble de ces trois éléments

Emplacement du fichier de configuration

Les fichiers de configuration de httpd se trouvent dans le dossier /etc/httpd/conf.d 

# ll /etc/httpd/conf.d/
total 20
-rw-r--r--. 1 root root  392 13 août  19:28 README
-rw-r--r--. 1 root root 9473  2 août  13:59 ssl.conf
-rw-r--r--. 1 root root  299  2 août  13:59 welcome.conf

Ces fichiers sont importés dans la configuration de httpd grâce à la directive Include présente dans le fichier httpd.conf 

Include conf.d/*.conf

Nous allons donc créer un fichier spécifique pour nos VHost que nous appellerons vhost.conf 

# touch /etc/httpd/conf.d/vhost.conf

VHost par ports TCP

Ce choix permet avec une seule adresse IP d'avoir plusieurs sites qui sont accessibles sur des ports différents. C'est généralement le cas quand on veut installer des interfaces d'administration.

Tout d'abord le serveur httpd doit écouter sur les ports en question 

Listen 80 # Ne pas ajouter si déjà dans httpd.conf
Listen 8080
ServerName www.tala-informatique.fr

Ensuite les VHost possèderont une directive VirtualHost différente 

<VirtualHost *:80>
    DocumentRoot /var/www/html/public
</VirtualHost>

<VirtualHost *:8080>
    DocumentRoot /var/www/html/admin
</VirtualHost>

VHost par adresses IP

Des contenus différents

Ce choix est inintéressant quand le serveur Web possède deux cartes réseaux sur deux réseaux différents (vers Internet et vers l'intranet).

Tout d'abord on déclare un serveur httpd principal et cette configuration est généralement déjà dans httpd.conf. 

Listen 192.168.200.251:80
DocumentRoot /var/www/html/
ServerName www.tala-informatique.fr

Ensuite le VHost possèdera une directive VirtualHost différente 

<VirtualHost 192.168.200.250:80>
    DocumentRoot /var/www/html/intranet
</VirtualHost>

Le même contenu

Le serveur web peut avoir plusieurs interfaces, sur des réseaux différents, et en plus une interface d'administration sur laquelle on ne veut pas que httpd écoute.

Tout d'abord le serveur httpd doit écouter sur le port TCP/80 (en général) 

Listen *:80

Puis on précise les interfaces d'écoute 

<VirtualHost 192.168.200.250 192.168.200.251>
    DocumentRoot /var/www/html/intranet
    ServerName www.tala-informatique.fr
</VirtualHost>

VHost par noms DNS

C'est le type le plus courant de VHost. En effet, le plus souvent les gens ne possèdent qu'une seule adresse IP publique et il est donc plus simple de faire pointer plusieurs noms de domaine vers la même adresse.

Tout d'abord le serveur httpd doit écouter sur le port TCP/80 (en général) mais cette fois-ci on doit lui spécifier que l'on va utiliser des VHost par nom. Pour cela on utilise la directive NameVirtualHost soit:

  • en utilisant un nom différent de celui utilisé pour les VHost (c'est le cas dans cet exemple)
  • soit en utilisant une adresse IP
NameVirtualHost web.tala-informatique.fr:80

web.tala-informatique.fr = www.tala-informatique.fr = wiki.tala-informatique.fr = une adresse IP

Ensuite les VHost possèderont une variable ServerName différente 

<VirtualHost web.tala-informatique.fr:80>
    DocumentRoot /var/www/html/informatique
    ServerName www.tala-informatique.fr
</VirtualHost>

<VirtualHost wiki.tala-informatique.fr:80>
    DocumentRoot /var/www/html/wiki
    ServerName wiki.tala-informatique.fr
</VirtualHost>

Rediriger les brebis égarées

Il peut être utile d'utiliser la directive Redirect pour rediriger quelqu'un qui arrive en http si votre site est en https. Pour cela nous allons créer un Vhost http identique à celui en https et qui aura pour unique rôle d'effectuer une règle de redirection: 

<VirtualHost www.tala-informatique.fr:80>
        ServerName www.tala-informatique.fr
        Redirect "/" "https://www.tala-informatique.fr/"
</VirtualHost>

<VirtualHost www.tala-informatique.fr:443>
        ServerName www.tala-informatique.fr
        DocumentRoot /var/www/html/

        SSLEngine on
        SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
        SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key
</VirtualHost>

Le fichier .htaccess

Les fichiers .htaccess sont des fichiers de configuration d'Apache, permettant de définir des règles dans un répertoire et dans tous ses sous-répertoires.

Possibilités

Les principales raisons d'utilisation des fichiers .htaccess sont :

  • gérer l'accès à certains fichiers;
  • ajouter un mime-type;
  • protéger l'accès à un répertoire ou un fichier par un mot de passe;
  • définir des pages d'erreurs personnalisées.

Principe

Le fichier .htaccess est placé dans le répertoire dans lequel il doit agir. Il agit ainsi sur les permissions du répertoire qui le contient et sur tous ses sous-répertoires.

Vous pouvez placer un autre fichier .htaccess dans un sous-répertoire d'un répertoire déjà contrôlé par un fichier .htaccess. Le fichier .htaccess du répertoire parent reste en « activité » tant que les fonctionnalités n'ont pas été réécrites.

Exemples d'utilisation

Avant d'aller plus loin, assurez-vous qu'Apache lise les .htaccess en passant la directive AllowOverride de None à All dans le fichier /etc/httpd/conf/httpd.conf

Pour cela éditez le fichier et cherchez la ligne <Directory "/var/www/html" >. Plus loin, il vous suffit de modifier la ligne AllowOverride None en AllowOverride All.

Bloquer l'accès à des ressources

Un fichier .htaccess est composé de deux sections :

  • une première qui contient les chemins vers les fichiers contenant les définitions de groupes et d'utilisateurs;
  • une deuxième qui précise les conditions d'accès.
# Définition
AuthUserFile /path/to/.htpasswd 
AuthGroupFile /path/to/.htgroup
AuthName "Accès protégé" 
AuthType Basic
#Conditions d'accès
Require valid-user
  • AuthUserFile définit le chemin d'accès absolu vers le fichier de mot de passe;
  • AuthGroupFile définit le chemin d'accès absolu vers le fichier de groupe;
  • AuthName entraîne l'affichage dans le navigateur Internet de : « Tapez votre nom d'utilisateur et votre mot de passe. Domaine: "Accès protégé" »;
  • AuthType Basic précise qu'il faut utiliser AuthUserFile pour l'authentification;
  • Require valid-user précise que l'on autorise uniquement les personnes identifiées. Il est possible de préciser le nom des personnes autorisées : Require user {username}

Création du fichier de mot de passe

Pour créer le fichier de mot de passe, il faut utiliser la commande htpasswd 

# htpasswd -c /path/to/.htpasswd jcf
New password:
Re-type new password:
Adding password for user jcf

On vérifie que le fichier est bien crypté: 

# cat .htpasswd
jcf:RM1/WS9zqOV8o

La prochaine fois que l'on veut ajouter un compte il ne faut pas utiliser l'option -c (pour create): 

# htpasswd /path/to/.htpasswd magali
New password:
Re-type new password:
Adding password for user magali

Redirections

Vous vous demandez comment rediriger les âmes égarées qui se retrouvent à la racine de votre serveur Web...

Dans le fichier ou vous avez déclaré vos Vhost il vous suffit d'ajouter la ligne suivante: 

RedirectMatch ^/$ /wiki/

Comme cela, lorsque l'on arrive à la racine / (^/$ → ^ signifie début de ligne et $ fin de ligne) on est redirigé vers /wiki/.

Certificats

C'est la première chose que les utilisateurs vont voir lorsqu'ils se connectent à votre site, alors autant en prendre soin. On n'est pas en confiance lorsque l'on se connecte à un serveur qui fait parti de l'entreprise SomeOrganization et du département SomeOrganizationUnit... On va remédier à cela !

Auto-signé

Génération

Pour ce faire, nous allons utiliser openssl et notamment la commande suivante: 

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout www.tala-informatique.fr.key -out www.tala-informatique.fr.crt
Generating a 2048 bit RSA private key
...............+++
..........................................+++
writing new private key to 'www.tala-informatique.fr.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:FR
State or Province Name (full name) []:Herault
Locality Name (eg, city) [Default City]:Juvignac
Organization Name (eg, company) [Default Company Ltd]:Tala
Organizational Unit Name (eg, section) []:Informatique
Common Name (eg, your name or your server's hostname) []:www.tala-informatique.fr
Email Address []:tala.informatique@gmail.fr

Utilisation de la clé et du certificat

Il faut maintenant les faire utiliser par Apache, ce qui se fait dans le fichier où vous avez déclaré vos hôtes virtuels. 

...

SSLEngine on
SSLCertificateFile /opt/ssl/www.tala-informatique.fr.crt
SSLCertificateKeyFile /opt/ssl/www.tala-informatique.fr.key

...

On n’oublie pas de donner les droits à Apache: 

# chown -R apache. /opt/ssl

Automatisation

Maintenant nous allons faire un script Shell, que j'ai nommé gen_ssl_tokens.sh, pour automatiser tout cela: 

#!/bin/bash

###########################
# Key name
KEY=valhalla.tala-informatique.fr.key
# Cert name
CRT=valhalla.tala-informatique.fr.crt
# Validity period
VALIDITY=365
# Destination directory
DST_DIR="/opt/ssl"
###########################

echo -n "Generating key and certificate: "
openssl req -x509 -nodes -days ${VALIDITY} -newkey rsa:2048 -keyout ${KEY} -out ${CRT} << EOF
FR
Herault
Juvignac
Tala
Informatique
www.tala-informatique.fr
tala.informatique.fr

EOF

echo ""
echo "ok."

echo -n "Copying key and certificate: "
mv -f ${KEY} ${DST_DIR}/
mv -f ${CRT} ${DST_DIR}/
echo "ok."

echo -n "Giving rights to Apache: "
chown -R apache. ${DST_DIR}
echo "ok."

On n'aura plus qu'à lancer le script pour générer automatiquement la clé et le certificat pour le renouvellement... Vous pouvez également utiliser cron !

Let's Encrypt

On peut également utiliser une autorité de certification pour générer le certificat à notre place. L'avantage est que le certificat sera reconnu par les navigateurs.

Installation de acme.sh

Pour cela nous allons utiliser un script qui va faire le travail à notre place : 

# wget -O - --no-check-certificate https://get.acme.sh | sh 
--2016-10-10 15:10:16--  https://get.acme.sh/
Résolution de get.acme.sh... 195.154.91.106
Connexion vers get.acme.sh|195.154.91.106|:443...connecté.
AVERTISSEMENT : impossible de vérifier l'attribut get.acme.sh du certificat, émis par «/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3» :
  Le certificat émis a expiré.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 671 [text/plain]
Sauvegarde en : «STDOUT»

100%[======================================================>] 671         --.-K/s   ds 0s      

2016-10-10 15:10:16 (95,3 MB/s) - envoi vers sortie standard [671/671]

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  100k  100  100k    0     0   478k      0 --:--:-- --:--:-- --:--:-- 1277k
[lun. oct. 10 15:10:17 CEST 2016] Installing from online archive.
[lun. oct. 10 15:10:17 CEST 2016] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz
[lun. oct. 10 15:10:18 CEST 2016] Extracting master.tar.gz
[lun. oct. 10 15:10:18 CEST 2016] It is recommended to install nc first, try to install 'nc' or 'netcat'.
[lun. oct. 10 15:10:18 CEST 2016] We use nc for standalone server if you use standalone mode.
[lun. oct. 10 15:10:18 CEST 2016] If you don't use standalone mode, just ignore this warning.
[lun. oct. 10 15:10:18 CEST 2016] Installing to /root/.acme.sh
[lun. oct. 10 15:10:18 CEST 2016] Installed to /root/.acme.sh/acme.sh
[lun. oct. 10 15:10:18 CEST 2016] OK, Close and reopen your terminal to start using acme.sh
[lun. oct. 10 15:10:18 CEST 2016] Installing cron job
[lun. oct. 10 15:10:19 CEST 2016] Good, bash is found, so change the shebang to use bash as prefered.
[lun. oct. 10 15:10:19 CEST 2016] OK
[lun. oct. 10 15:10:19 CEST 2016] Install success!

Une fois le script acme.sh installé, il suffit de recharger le contexte en exécutant la commande : 

# cd
# . .bash_profile

Création des certificats

Mainteant le script acme.sh est accessible dans le shell: 

acme.sh --issue -d tala-informatique.fr -d www.tala-informatique.fr -w /var/www/html

Vous devriez voir la commande se finir par : Cert success.

Installation des certificats

Maintenant que l'on a généré les certificats, il faut les installer dans le répertoire /opt/cert/ : 

# acme.sh --installcert -d tala-informatique.fr -d www.tala-informatique.fr --certpath /opt/ssl/www.tala-informatique.fr.crt --keypath /opt/ssl/www.tala-informatique.fr.key --reloadcmd "service http restart"

Cela va installer les certificats et redémarrer le serveur Apache !

Maintenant, lorsque l'on se connecte on peut vérifier que le certificat est approuvé :

Fichier:Www.tala-informatique.fr-cert-letsencrypt.jpg

Exemple de configuration

Directive Valeur par défaut Config httpd Config Vhost Utilisation
ServerTokens OS X Permet de ne pas donner trop d'informations sur les modules qui sont installés. Généralement on passe cette directive à Prod
ServerRoot "/etc/httpd" X Permet d'indiquer le répertoire d'installation d'Apache. Normalement les scripts d'installation ont bien renseigné cette ligne. Vérifiez quand même.
PidFile run/httpd.pid X Indique au script de démarrage d'enregistrer le numéro de processus d'Apache pour que lors de l'arrêt du système le processus Apache soit stoppé correctement.
Timeout 60 X Temps en secondes avant que le serveur n'envoie ou ne reçoive un timeout . Quand le serveur attend une réponse qui dépasse le temps définit par 'Timeout, il va s'interrompre et prévenir l'utilisateur de l'erreur. Laissez cette valeur par défaut à moins que vous n'effectuiez des traitements dépassant cette limite. Ne pas monter trop haut cette valeur non plus car si le programme externe à "planté", ou si une erreur est survenue, vous risquez de rendre inaccessible le serveur Apache pour trop de temps (il est toujours désagréable d'attendre pour rien).
KeepAlive Off X X Autorise ou non les connexions persistantes (plusieurs requêtes par connexions). En fait cela permet aux utilisateurs de votre serveur de lancer plusieurs requêtes à la fois, et donc d'accélérer les réponses du serveur. Laissez cette valeur par défaut la plupart du temps. Pour de petits serveurs laissez cette option sur on . Pour un serveur très sollicité, dès que vous vous apercevez que le système ralentit énormément ou devient indisponible assez souvent, essayez avec la valeur off . Mais avant, essayez de baisser la valeur de l'option suivante.
MaxKeepAliveRequests X X En combinaison avec l'option précédente, indique le nombre de requêtes pour une connexion. Laissez cette valeur assez haute pour de très bonnes performances. Si vous mettez 0 comme valeur, vous en autorisez en fait un nombre illimité (attention donc). Laissez la valeur par défaut là aussi.
KeepAliveTimeout 15 X X Valeur d'attente en secondes avant la requête suivante d'un même client, sur une même connexion, avant de renvoyer un timeout. Laisser la valeur par défaut.
Listen 80 X X Indique au serveur des ports ou des adresses IP, ou les deux, où il doit écouter les demandes de connexions.
LoadModule, ClearModuleList & AddModule

LoadModule xxxxxx.mod libexec/yyyyyy.so
ClearModuleList
AddModule zzzz.c

X Support pour les modules DSO (Dynamic Shared Object). LoadModule permet de charger un module. Avant Apache 2, les directives ClearModuleList et AddModule permettaient de spécifier l'ordre d'exécution des modules, à cause de problèmes de dépendances. Apache 2 peut maintenant faire cela automatiquement, car les APIs de modules leur permet de spécifier eux-mêmes leur ordre. Sous Apache 1.*, il faut cependant y prêter une grande attention, et le maintenir à jour à l'ajout de tout nouveau module.
Récupérée de « https://tala-informatique.fr/index.php?title=HTTPD&oldid=2147 »