Blog ENI : Toute la veille numérique !
-25€ dès 75€ sur les livres en ligne, vidéos... avec le code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. LINUX
  3. Services HTTP
Extrait - LINUX Préparation à la certification LPIC-2 (examens LPI 201 et LPI 202) - 5e édition
Extraits du livre
LINUX Préparation à la certification LPIC-2 (examens LPI 201 et LPI 202) - 5e édition
2 avis
Revenir à la page d'achat du livre

Services HTTP

Prérequis et objectifs

1. Prérequis

Les connaissances nécessaires à la certification LPIC-1 :

Commandes de suivi des processus.

Édition de fichiers.

Commandes de gestion de répertoires et de fichiers.

Les connaissances acquises dans les précédents chapitres, notamment :

Gestion du réseau local.

Gestion des services.

Gestion de DNS.

2. Objectifs

À la fin de ce chapitre, vous serez en mesure de :

Installer, configurer et administrer un serveur HTTP Apache.

Configurer un serveur Apache pour contrôler les clients, limiter la consommation de ressources et gérer des hôtes virtuels.

Configurer un serveur Apache en HTTPS.

Installer et de configurer un serveur proxy Squid.

Installer et de configurer un serveur HTTP Nginx, y compris en proxy inverse et en répartition de charge.

Services HTTP

Ce sujet est divisé en quatre parties de poids différents.

1. Configuration de base d’un serveur Apache

Poids

4

Objectifs

Installer et configurer un serveur web. Cela inclut le suivi de charge et de performance du serveur, le contrôle d’accès, la configuration des modules interpréteurs et l’authentification des clients.

Cela comprend également configurer les options du serveur pour limiter la consommation de ressources, configurer les hôtes virtuels et personnaliser les fichiers de contrôle d’accès.

a. Compétences principales

  • Configuration des fichiers journaux d’Apache et de leur contenu.

  • Méthodes et fichiers de restriction d’accès.

  • mod_perl et configuration PHP.

  • Fichier et outils d’authentification des clients.

  • Configuration du nombre maximum de requêtes, du nombre minimum et maximum de processus serveur et de clients.

  • Mise en place d’hôtes virtuels Apache 2.4 (avec ou sans adresse dédiée).

  • Utilisation des déclarations de redirection dans les fichiers de configuration Apache pour personnaliser l’accès aux fichiers.

b. Éléments mis en œuvre

  • Journaux d’accès et d’erreurs.

  • .htaccess

  • httpd.conf

  • mod_auth_basic, mod_authz_host et mod_access_compat

  • htpasswd

  • AuthUserFile, AuthGroupFile

  • apachectl, apache2ctl

  • httpd, apache2

2. Configuration HTTPS d’un serveur Apache

Poids

3

Objectifs

Configurer un serveur Apache pour gérer HTTPS.

a. Compétences...

Remarques concernant la sécurité

La sécurité est une préoccupation constante pour la gestion des systèmes modernes et particulièrement pour les accès réseau. Les distributions Linux activent donc par défaut de très nombreux mécanismes de protection, qu’il s’agisse des modules PAM, du pare-feu (iptables, firewalld…) ou de SELinux.

Ces protections indispensables en production peuvent perturber sérieusement vos expérimentations. Si vous constatez que, malgré tous vos efforts, la configuration de vos services réseau n’aboutit pas, avec des symptômes assez divers, vous pouvez désactiver temporairement certaines de ces protections système. Il vous faudra ensuite tester à nouveau et, si cela fonctionne, identifier précisément le problème pour adapter votre configuration fonctionnelle et la configuration de sécurité.

Cette désactivation temporaire des couches de sécurité doit être réservée à un environnement de test, hors production !

1. iptables

Par défaut, sur la plupart des distributions, iptables n’autorise aucune connexion entrante en dehors de SSH. Pour vérifier sa configuration, on peut utiliser la commande iptables -L.

Exemple

iptables -L 
Chain INPUT (policy ACCEPT) 
target     prot opt source...

Configuration de base d’un serveur HTTP Apache

Le protocole HTTP (HyperText Transfer Protocol) est à l’origine du Web. Il s’agit d’un protocole client/serveur, le client demandant au serveur HTTP de lui transmettre une "page", généralement structurée au format HTML (HyperText Markup Language). Une page peut correspondre à un fichier ou être générée dynamiquement par un composant logiciel du serveur.

Apache est le logiciel serveur HTTP le plus connu et l’un des plus utilisés dans le monde.

Son nom vient de son origine : dans les années 1990, aux États-Unis, le NCSA (National Center for Supercomputing Applications) avait créé l’un des premiers logiciels serveurs HTTP, httpd. Un groupe de développeurs proposa un ensemble de correctifs (patches) pour ce programme, avant de créer sa propre version, Apache (a patchy server), en 1995. Apache HTTP Server est aujourd’hui développé sous le contrôle de la fondation Apache Software Foundation, qui gère de très nombreux autres projets open source (avec une licence spécifique, la licence Apache).

Le logiciel Apache HTTP Server, d’origine Unix, a été implémenté sur Linux et d’autres systèmes d’exploitation (dont Windows). De très nombreux serveurs web s’appuient sur une architecture dite LAMP : Linux/Apache/MySQL/PHP.

La version principale actuelle d’Apache est la version 2, entièrement réécrite en 2002. En 2022, la version stable est la version 2.4.54.

1. Fichier de configuration

Le fichier de configuration du serveur Apache peut contenir des centaines de directives, en raison du grand nombre de fonctionnalités et de modules disponibles pour ce logiciel. Dans le cadre de ce sujet de certification, nous étudierons les éléments essentiels à la configuration de base d’un serveur HTTP.

a. Format du fichier de configuration

Le nom et l’emplacement du fichier de configuration du serveur Apache varient selon les versions et selon les distributions : httpd.conf, apache.conf ou apache2.conf. Il s’agit d’un fichier texte, composé de directives. Certaines directives sont globales, d’autres sont déclarées à l’intérieur...

Configuration HTTPS d’un serveur Apache

Pour renforcer la sécurité, on peut utiliser le protocole HTTPS (HyperText Transfer Protocol Secure), qui s’appuie sur une couche applicative sécurisée, SSL (Secure Socket Layer) ou TLS (Transport Layer Secure, successeur de SSL), pour la communication entre le client et le serveur Apache. Le protocole de sécurisation gère l’authentification des participants via des certificats, le chiffrage et le contrôle d’intégrité des données échangées.

TLS a remplacé à partir de 1999 la version 3 de SSL, abandonnée en raison de problèmes de sécurité. On utilise depuis les termes de SSL, SSL/TLS ou TLS pour désigner le protocole TLS. On utilisera dans la suite le terme SSL, conformément à la terminologie utilisée pour la certification LPIC-2.

Le protocole HTTPS utilise le port bien connu 443. Il tend à devenir le standard Internet et à remplacer HTTP.

1. Cryptographie et certificats

Le protocole SSL s’appuie sur des certificats pour authentifier les participants à la communication. Le serveur envoie son certificat au client pour que ce dernier soit sûr de son identité. Le client peut, de façon optionnelle, posséder lui-même un certificat qu’il transmet au serveur pour lui déclarer son identité.

Le protocole assure le chiffrement et le déchiffrement des données échangées, par une paire de clés, clé publique et clé privée, selon la technique de cryptographie asymétrique.

Une connaissance générale de ces concepts est demandée dans le cadre de la certification LPIC-2.

a. Cryptographie symétrique

Les algorithmes de chiffrement symétrique utilisent une clé unique qui permet de chiffrer et de déchiffrer l’information.

Ils ont l’avantage de nécessiter assez peu de ressources processeur et d’être rapides. Ils permettent donc d’échanger efficacement de grands volumes de données. En revanche, ils présentent une difficulté : les participants à l’échange chiffré doivent tous connaître la clé de chiffrement/déchiffrement. Par conséquent, toutes les entités...

Serveur proxy et de cache Squid

Squid (signifiant « calmar ») est un logiciel open source, créé en 1996, qui implémente un serveur mandataire (proxy) et mandataire inverse (reverse proxy), pour les protocoles FTP, Gopher, HTTP et HTTPS.

Dans le cadre de la certification LPIC-2, nous allons étudier ses fonctions de mandataire HTTP/HTTPS.

Bien que la traduction de proxy soit "mandataire", on utilise le plus souvent le terme "proxy" dans les documentations techniques.

1. Rôles des serveurs proxy

Un serveur proxy ou proxy inverse est un intermédiaire entre le client et le serveur d’un protocole applicatif :

  • Un serveur proxy prend en charge la demande du client, la soumet au serveur comme s’il en était l’émetteur, récupère la réponse et la transmet au client. Le serveur ne connaît donc pas le client initial.

  • Un proxy inverse (reverse proxy) reçoit la demande du client à la place du serveur, la transmet au serveur, récupère la réponse et la transmet au client. Le client ne connaît donc pas le serveur destinataire.

Il existe des logiciels proxy pour la plupart des protocoles applicatifs de la famille TCP/IP (FTP, Gopher, HTTP, etc.). Les plus utilisés sont les proxys et proxys inverses HTTP.

Le rôle de proxy inverse est vu dans le sujet suivant, Nginx.

a. Protection des clients

Dans beaucoup d’organisations, les postes de travail et les serveurs internes ne sont pas directement accessibles depuis Internet. Les systèmes qui doivent être accessibles de l’intérieur (intranet) et de l’extérieur de l’organisation (Internet ou extranet) sont situés dans une structure réseau particulière, appelée DMZ (DeMilitarized Zone), protégée par des routeurs et des pare-feu. Le proxy HTTP est installé dans cette zone et fait l’intermédiaire entre les clients HTTP et les serveurs HTTP externes. Ces derniers ne sont donc pas directement en contact avec les clients, ils communiquent exclusivement avec le serveur proxy, ce qui limite les risques de sécurité.

b. Serveurs de cache

Le proxy traite les demandes de tous les clients et les réponses des serveurs. Il peut donc stocker dans son cache les éléments qui transitent entre les deux...

Nginx serveur HTTP et reverse proxy

Si Apache est le serveur web le plus connu et était le plus utilisé sur Internet, il a vu apparaître des concurrents sérieux ces dernières années. Le plus souvent, l’objectif premier de ces nouveaux serveurs web est la performance. En effet, on reproche à Apache une certaine lourdeur, liée à sa conception ancienne et à ses très nombreuses fonctionnalités, ainsi qu’une consommation excessive de ressources quand il est très sollicité.

1. Nginx et les serveurs web

En 2002, un développeur russe, Igor Sysoev, a décidé d’écrire un logiciel entièrement nouveau, dans le cadre de la gestion d’un site internet russe très fréquenté, Rambler, qui devait supporter plus de 500 millions de requêtes HTTP par jour.

La première version de ce logiciel, Nginx (à prononcer « engineX ») est apparue en 2008. Écrit en langage C, conçu pour être simple et efficace, ce serveur web a rapidement gagné des parts de marché, surtout pour les sites à très forte volumétrie (Facebook en particulier). Selon une étude, il représentait en 2022 27,66 % des serveurs web d’Internet par nombre d’utilisateurs, derrière Apache (40,18 %) mais devant IIS de Microsoft (11,06 %).

Bien qu’il puisse également jouer le rôle de serveur proxy de messagerie (SMTP, POP3 et IMAP4), il est essentiellement utilisé aujourd’hui dans le domaine HTTP.

Nginx est un serveur de type asynchrone, contrairement à Apache qui fonctionne généralement en mode synchrone (les versions récentes peuvent être configurées pour le mode asynchrone). En mode synchrone, on affecte un processus à chaque client, ce qui est consommateur de ressources quand il y a beaucoup de demandes. En mode asynchrone, un même processus gère simultanément plusieurs clients, ce qui limite la consommation mémoire et améliore les temps de réponse (il n’y a pas besoin de recharger en mémoire les modules nécessaires au traitement du client).

Bien que la société NGINX Inc ait été rachetée par la société F5, Inc en 2019, il existe...

Validation des acquis : questions/réponses

Répondez à ces questions ouvertes, comparables à celles qui pourront vous être posées lors de la certification, mais ces dernières seront sous forme de QCM ou demandant une réponse courte saisie au clavier.

1. Questions

1 Quelle option de la commande httpd (ou équivalente) fournit la liste des modules d’Apache chargés ?

2 Comment valider la syntaxe d’un fichier de configuration Apache avant de le charger effectivement ?

3 Quelle directive de configuration limite le nombre de clients simultanés d’un serveur HTTP Apache ?

4 Quels éléments permettent de distinguer différents hôtes virtuels gérés par un seul serveur HTTP Apache ?

5 Quelle commande permet de créer un certificat X.509 autosigné ?

6 À quoi sert un fichier .htaccess ?

7 Quels sont les deux fichiers journaux par défaut d’un serveur HTTP Apache ?

8 Quel numéro de port bien connu est associé à HTTPS ?

9 Une directive de configuration http_access deny cli_non ne fonctionne pas pour un client du serveur Squid, bien que son adresse figure dans l’ALC cli_non spécifiée. Que faut-il vérifier ?

10 Où est stocké le contenu du cache du serveur proxy Squid ?

11 Quel est l’avantage majeur de Nginx par rapport à Apache ?

12 Qu’est-ce...

Travaux pratiques

Ces travaux pratiques proposent trois ateliers mettant en œuvre certains des points abordés dans ce chapitre. Pour chaque étape est donné un exemple commenté de réalisation, à adapter suivant la configuration de vos systèmes.

1. Serveur HTTP Apache avec deux hôtes virtuels

On configure un serveur HTTP Apache sur une distribution de type Red Hat. Il doit gérer deux hôtes virtuels, distingués par leur nom d’hôte :

  • www : cet hôte virtuel est accessible de tous les clients HTTP.

  • rh : cet hôte virtuel n’est accessible que des utilisateurs ayant un compte utilisateur créé localement pour le serveur HTTP Apache.

Les noms d’hôtes peuvent être définis comme des alias DNS de la machine hôte, ou déclarés dans les fichiers hosts du serveur et des clients de test.

Commandes et fichiers utiles

  • rndc

  • /etc/hosts

  • host

  • /etc/httpd/conf/httpd.conf

  • http

  • systemctl

  • wget

  • htpasswd

  • firefox

Manipulations

1.

Vérifiez que le paquet logiciel du serveur HTTP Apache est installé. Pour simplifier les tests, désactivez temporairement le pare-feu du serveur.

2.

Déclarez les deux noms d’hôtes www et rh (via DNS ou le fichier /etc/hosts).

3.

Configurez le serveur HTTP Apache avec l’hôte virtuel public www.

4.

Créez le répertoire de données de l’hôte virtuel, avec une page HTML de test.

5.

Vérifiez et chargez la configuration.

6.

Testez l’accès à l’hôte virtuel www, depuis la ligne de commande ou un navigateur local.

7.

Testez l’accès à l’hôte virtuel www, depuis un navigateur distant.

8.

Créez une base de comptes locale pour le contrôle d’accès à l’hôte virtuel rh.

9.

Configurez le serveur HTTP Apache avec l’hôte virtuel public rh, accessible uniquement par les comptes déclarés dans la base de comptes locale.

10.

Créez le répertoire de données de l’hôte virtuel, avec une page HTML de test.

11.

Vérifiez et chargez la configuration.

12.

Testez le contrôle d’accès à l’hôte virtuel rh, depuis la ligne de commande ou un navigateur local.

13.

Testez l’accès à l’hôte virtuel...