LAMP

Présentation de LAMP

LAMP est un ensemble de logiciels:

• Linux
• Apache
• MySql
• PHP

Sa fonction est d'héberger des sites web. LAMP est le plus connu mais on peut aussi l'ajuster : il existe par exemple des solutions WAMPServer ou EasyPHP sous Windows, et même XAMPP (avec PHP et Perl) qui fonctionne sur les 3 OS courants. On peut remplacer Apache par NGinx (Et puisque Nginx se prononce "engine X", on nomme alors la suite de logiciels LEMP). On peut aussi MariaDB au lieu de MySql.

NB: MariaDB est un fork de MySql : MySql a été racheté par Oracle, qui n'est pas forcément pour le logiciel libre.

Architecture 3 tiers

L'architecture 3 tiers concerne le développement applicatif : elle a été conçue pour faire face à plusieurs difficultés liées à l'architecture deux tiers habituellement utilisée (client serveur). Elle a plusieurs avantages, parmi lesquels :

• Allègement du poste de travail client
• Prise en compte de l'hétérogénéité des plate-formes (serveurs, clients, langage, etc)
• Amélioration de la sécurité des données en améliorant le lien entre le client et les données
• Rupture du lien de propriété exclusive entre applications et données; ici la BDD peut facilement être normalisée et intégrée à un entrepôt de données
• Meilleure répartition de la charge de travail entre les serveurs d'application.
• Facilitation de l'évolution du code de l'application (et encore plus dans les architectures n-tiers). La séparation en couches permet de faire évoluer plus facilement l'une d'entre elles, et permet aussi de prévoir plus simplement la différence des interfaces du client (smartĥone, PC, etc).

Le concept de l'architecture 3-tiers permet de définir une application logicielle comme un ensemble de 3 couches:

• La couche présentation, visible de l'utilisateur
• La couche métier (de traitement des données selon les règles de gestion locales)
• La couche d'accès aux données

 

Comme avec le modèle OSI, chaque couche ne communique qu'avec les couches qui lui sont adjacentes. Cette communication se fait grâce à des services et des protocoles d'échange précis.

Par exemple, avec une application web et par ordre chronologique:

• L'application va accéder à la couche données pour aller chercher les informations brutes dans une base de données (Oracle, MySQL, etc)
• L'application va effectuer des traitements sur ces données en fonction des règles de gestion métier (pour une application de e-commerce, gérer des stockes, par exemple). Cette logique est dite "métier" car elle dépend directement de l'environnement professionnel de l'application.
• Enfin, la présentation d'écrans/interfaces, résultant du traitement des données, est faite au client. Pour notre interface web, ce sera une page HTML.

Architectures n-tiers

L'architecture 3 tiers, n'est pas parfaite, et il existe d'autres architectures plus fines; cependant la logique reste la même.

Ces architecture répondent aux pré-requis techniques suivants :

• Plusieurs serveurs, un client
• Du réseau entre eux
• Et des firewalls entre les couches.

 

MySQL

MySQL est un système de gestion de base de données relationnelles (SGBDR) créé en 1995, un des plus utilisés au monde. Son nom vient du prénom de la fille du cocréateur Michael Widenius (My), et SQL (le langage utilisé). Racheté en 2009 par Sun, il a forké et la version libre s'appelle MariaDB. Il a été développé avec un souci de rapidité en lecture; c'est-à-dire qu'il est davantage orienté vers l'utilisation de système déjà en place que vers des systèmes fréquemment mis à jour. Il est libre et open source, payant seulement s'il est associé avec un produit propriétaire (sinon, il est sous licence GPL). Un produit gratuit qui l'utilise devra donc être libre lui aussi. Cependant si il est séparé du produit qui l'utilise, il n'as pas besoin de licence. Il fonctionne sous beaucoup d'OS et de nombreux langages de programmation possèdent une API dédiée.

Il supporte le SQL et le SQL /PSM (Persistent Stored Modules) une extension procédurale. Le PSM permet de créer des requêtes SQL possédant du code procédural (boucles, conditions...).

Il fait partie de LAMP et est souvent utilisé conjointement avec php pour l'hébergement de sites web. Il supporte la nome SQL2, ce qui en fait un SGBD sûr; cependant les fonctionnalités des normes SQL les plus récentes ne sont pas implémentées, ce qui fait que ses requêtes ne sont pas interopérables avec les autres SGBD.

Deux moteurs principaux sont présents : MyISAM et InnoDB. Il est interopérable avec les tableurs grâce à CSV et on peut sauvegarder en xml.

Serveur / clients

Lorsque l'on parle de MySQL en tant que service on rajoute le d de daemon à la fin. MySQLd est donc le service MySQL qui est fourni à des clients.

Le client peut être n'importe quel logiciel compatible :

• Un client lourd avec UI (MySQLWorkbench par exemple)
• Un serveur web
• Un client en ligne de commandes (comme mysql)

"mysql" est un client du service MySQLd, installé en même temps que celui-ci. Il ne faut don pas confondre MySQLd, MySQL, et mysql !

Environnement réseau

Dans une architecture LAMP, la base de données est un élément sensible : Il n'est pas conçu pour se protéger efficacement des attaques, et de plus il contient des données, soit la seule information pérenne dans notre architecture réseau. Il convient donc de le placer en MZ, avec le serveur web en DMZ. On peut cependant mettre le serveur web en MZ lui aussi, en utilisant un reverse proxy.

Dans la suite de ce cours on ne fera pas de reverse proxy, mais ça ne change rien pour notre serveur web.

Les privilèges

En matière de BDD, on parle de privilèges pour parler de droits. Ces privilèges s'appliquent à des comptes : tel compte a le droit de faire telle action, par exemple Justine a le droit de créer des tables sur telle base de données. La maîtrise des privilèges est fondamentale pour la sécurisation des bases de données.

Il est à noter que les comptes dans MySQL n'ont aucun rapport avec les comptes système : même le root de MySQL n'est pas le même root que celui de Linux.

Par rapport aux comptes, on peut définir plusieurs rôles :

• Celui qui administre (fais des sauvegardes, attribue des droits, gère une réplication, etc) la BDD, le DBA ou l'opérateur (c'est pareil)
• Celui qui développe une application disposant d'une BDD, le développeur
• L'application en elle-même, qui accède au serveur de données pour y effectuer des traitements

L'utilisateur n'est pas dans ce modèle car on est sur un système 3-tiers, et la couche de présentation n'accède pas directement à la base de données. Dans le modèle DevOps, l'opérateur et le dev ont tendance à se confondre.

Il existe de nombreux droits dans MySQL; cette quantité permet une gestion très fine des possibilités de chaque utilisateur.

La liste complète des droits est assez longue (cf la doc de MySQL), mais il y'en a quelques uns à connaître :

• GRANT : Le droit de donner des droits
• CREATE : Créer des utilisateurs, des bases, des tables, des index
• DROP Supprimer des utilisateurs, bases, tables, index
• ALTER Modifier la structure des tables
• DELETE Supprimer des données
• INSERT Ajouter des données
• UPDATE Modifier des données

Ce que l'on pourrait schématiser :

• Un admin doit pouvoir créer et supprimer des bases de données et des utilisateurs (CREAT, DROP) et donner des droits (GRANT)
• Un dev doit pouvoir modifier ses BDD (ALTER) mais pas celles des autres et gérer les données (DELETE, INSERT, UPDATE). En réalité il doit aussi pouvoir gérer les index, créer les déclencheurs (TRIGGERS), etc.
• Une application doit pouvoir gérer les données (DELETE, INSERT, UPDATE) voire créer des tables temporaires (CREATE TEMPORARY TABLES)

La configuration de MySQL

Le fichier de configuration

Il s'agit du fichier my.cnf qui est en général dans /etc/mysql. Rarement modifié, il contient principalement :

• Le port d'écoute de MySQLd : 3306
• Différents dossiers utilisés
• Le nom d'utilisateur des processus de MySQLd (mysql)
• Des paramètres liées aux perfs (taille mémoire allouée, taille du cache...) ou à la configuration fine de moteurs ISAM, InnoDB
• Les logs

Concernant les logs, il faut dé-commenter les lignes:

• general_log_file        = /var/log/mysql/mysql.log
• general_log             = 1

Ce sont des "tueurs de performance" mais ils sont parfois très utiles. À éviter en prod, mais ponctuellement en zone de test, pourquoi pas.

Ensuite, par défaut, le serveur ne répond qu'aux requêtes venant de sa boucle locale, ce qui est peut être embêtant. On utilise pour cela la directive bind-address.

bind-address

Cette directive sert à restreindre l'accès au service : par défaut elle est à 127.0.0.1, et seule la machine indiquée dans cette directive peut accéder à la base de données. Cela pose problème : notre serveur web, qui est en théorie sur une autre machine, doit pouvoir accéder à la BDD, de même que notre DBA.

Le problème c'est que cette directive ne peut acceuillir qu'une seule adresse : impossible d'y mettre notre serveur ET le poste de travail de notre DBA ! Il faut utiliser 0.0.0.0, qui autorise l'accès à toutes les machines. On a pas de demie-mesure.

MySQL n'est vraiment pas doué pour se protéger.

Les hôtes et leurs comptes

Les hôtes sont les postes (au sens réseau du terme) qui vont se connecter sur le serveur MySQLd. Il faudra donc que bind-address soit ouverte, mais aussi que l'on ait identifié quel hôte sera utilisé par qui (quel droits donner à quel utilisateur). Et il faut bien prendre garde à appliquer le principe de moindre privilège à tous les éléments du système.

Un compte se décompose en deux parties :

• Le nom de l'utilisateur
• Le nom ou l'adresse IP de l'hôte depuis lequel il se connecte

Donc par exemple : justine@192.168.1.41. Si je veux que justine puisse se connecter depuis n'importe quelle IP, je peux remplacer son IP par % : justine@%

Par défaut, on a un compte root@127.0.0.1 (voire root@::1 ou root@localhost).

La commande pour créer un compte est:

CREATE USER 'user'@'host' IDENTIFIED BY 'xxxxx'

Commandes de base

• Créer un compte : CREATE USER 'user'@'host'
• Se connecter au serveur MySQLd avec le client CLI mysql : mysql -h localhost -u root -p
• Supprimer un compte : DROP user 'user'@'host'
• Assigner un mot de passe : SET PASSWORD FOR 'user'@'localhost'=PASSWORD('motdepasse')
• Donner tous les droits sur la base toto à l'utilisateur justine : GRANT ALL ON *.toto TO 'justine'@'localhost'
• Donner tous les droits sur toutes les bases avec la possibilité de donner des droits aux autres : GRANT ALL ON *.*TO 'justine'@'localhost' WITH GRANT OPTION
• Actualiser les droits : FLUSH PRIVILEGES

Le serveur Web : Apache et sa configuration

Largement utilisé dans le monde, il définit la configuration des sites qu'il héberge et compile le code php au besoin.

Le dossier Apache

Le dossier de configuration d'Apache2 est /etc/apache2/

Il contient :

• Les fichiers de configuration : principalement apache2.conf
• le dossier sites-availables qui contient les vhosts disponibles, prêts à etre activés
• Le dossier sites-enabled : il contient les vhosts activés
• Le dossier mods-available : Il contient les modules disponibles (installés sur le serv)
• Le dossiers mods-enabled : il contient les modules activés

Un vhost, c'est un hôte virtuel : ie, un site web. On dit "virtuel" parce qu'une même machine peut acceuillir plusieurs sites (et donc plusieurs vhosts) : cette dénomination suit le même principe que la virtualisation.

Un site Web

Pour créer un site web, il faut aller dans le dossier sites-available et y mettre un fichier de configuration, dont on verra plus tard le contenu. Ce dossier contient déjà un site, par défaut : 000-default.conf. Cette façon de nommer les fichiers, avec un nombre à trois chiffres au début permet de précise à Apache l'ordre de chargement des fichiers de configuration.

Si je crée le site "simple exemple", je pourrais l'appeller "100_simpleexemple.conf". Pour l'activer, il me suffira d'utiliser la commande :

a2ensite 100_simpleexemple.conf

a2ensite signifie Apache2, Enable, Site : "Apache2, Active le site xxx.conf". Cette commande créée un lien symbolique dans le dossier sites-enabled.

Voice un résumé de ce qu'il se passe lors d'une requête client :

 

 

Apache regarde la requête, regarde dans ses sites activés, suis le lien vers sites disponibles, regarde le fichier du site, puis va voir dans le dossier racine du site en question.

Les logs

Les logs d'Apache se trouvent dans /var/log/apache2, et ils sont en général séparés en 2 pour chaque vhost:

• Un fichier access.log pour les accès au site
• Un fichier error.log pour les erreurs rencontrées

Lors de la configuration du vhost, on peut changer les noms des fichiers de logs, ce qui est une bonne pratique : nom_vhost.error.log et nom_vhost.access.log. On peut, de la même façon donner des directives à chaque vhost dans son fichier de configuration pour choisir le niveau de verbosité des logs en choisissant une des valeurs suivantes : debug, info, notice, warn, error, crit, alert, emerg. Ces deux configurations se font avec les lignes suivantes dans le fichier de configuration:

• ErrorLog /var/log/apache2/monsite_error.log
• CustomLog /var/log/apache2/monsite_access.log combined
• LogLevel warn

 

Les virtualhosts

Comme on l'as déjà dit, les vhosts représentent chacun un site, et ils ont chacun un fichier de configuration dédié. Ces fichiers contiennent des informations appellées directives; l'avantage de ce mode de fonctionnement est que chaque site peut être activé et désactivé indépendamment.

• Activation : a2ensite
• Désactivation : a2dissite

De nombreuses directives de configuration existent et sont présentées dans la doc d'Apache; cependant nous allons nous attarder ici que sur AllowOverride et Require.

AllowOverride

Cette commande précise à Apache2 à quel point un site va pouvoir modifier sa propre configuration. En effet, on peut préciser la configuration d'un site dans son fichier de configuration, mais aussi dans l'arborescence du site lui-même. Par exemple, les fichiers .htaccess placés dans l'arborescence du site vont modifier son comportement. Cela peut paraître dangereux car l'abrorescence du site est exposée au public; cependant c'est parfois nécessaire.

La documentation d'Apache nous donne :

Description:	Types de directives autorisées dans les fichiers .htaccess
Syntaxe:	AllowOverride All|None|type directive [type directive] ...
Défaut:	AllowOverride All
Contexte:	répertoire
Statut:	Core
Module:	core

Lorsque le serveur trouve un fichier .htaccess (dont le nom est défini par la directive AccessFileName), il doit savoir lesquelles des directives placées dans ce fichier sont autorisées à modifier la configuration préexistante.

Avec cette directive en All, toute directive valable trouvée dans .htaccess sera prise en compte.

L'argument type directive peut recevoir :

• AuthConfig : autorise les directives d'autorisation
• FileInfo : autorise les directives contrôlant les types de documents, les métadonnées des documents, et certaines autres
• Indexes : autorise les directives concernant l'indexation des répertoires
• Limit : autorise les directives contrôlant l'accès au serveur (Allow, Deny et Order)
• Options : Permet l'utilisation des directives contrôlant les fonctionnalités spécifiques d'un répertoire (Options et XBitHack). "Options" doit être suivi d'un signe "égal", puis d'une liste d'options séparées par des virgules (pas d'espaces) ; ces options doivent être définies à l'aide de la commande Options.

Pour faire plus simple :

• On peut tout accepter avec AllowOverride All
• Rien accepter avec AllowOverride None
• Ou en accepter certaines.

 

Contrôle d'accès (Require)

La gestion des accès à un site se fait via la directive de configuration Require, qui remplace Order qui est considérée comme obsolète depuis la version 2.4. Cette commande agit comme un petit pare-feu, en somme.

Si Require fonctionne comme Order, toutes les directives sont traitées, contrairement à un pare-feu dans lequel seule la première règle adéquate est prise en compte. Mais j'ai bien dit "Si" parce que ce n'est BIEN EVIDEMMENT pas marqué dans le cours.

Attention : si un serveur web est derrière un proxy, c'est ce proxy qu'il verra arriver, et non les clients.

La commande Require peut prendre trois formes, chacune contenant des élements de configuration sur ce qui est autorisé ou non. Ces trois formes sont :

• RequireAll : Toutes les directives d'autorisation doivent réussir
• RequireAny : Au moins l'une de ces directives doit réussir
• RequireNone : Aucune ne doit réussir.

Par réussir, on entend ici "retourner un résultat positif", c'est-à-dire True. 

La syntaxe réelle est donc dans l'ordre : Require - Ce qui est concerné - L'autorisation ou le blocage (granted/denied). Quels exemples :

• Par nom : Require host toto.com : donne l'autorisation au FQDN toto.com et tous ses membres
• Par IP : Require ip 127.0.0.1 ou Require ip ::1
• Pour tous : Require all granted
• Pour soi-même : Require local

Comparaison Order / Require

 

Requête :	Apache <=2.2	Apache >=2.4
toutes les requêtes sont rejetées	Order deny,allow Deny from all	Require all denied
toutes les requêtes sont acceptées	Order allow,deny Allow from all	Require all granted
tous les hôtes du domaine example.org ont accès, tous les autres sont rejetés	Order Deny,Allow Deny from all Allow from example.org	Require host example.org

 

 

Commandes Apache2

Des commandes existent dans Apache2, permettant d'agir rapidement et sans devoir modifier à la main des fichiers de configuration. Elles permettent de désactiver/activer un site ou un module, ou même de contrôler le serveur apache2 : redémarrage, arrêt, statut, test de la syntaxe d'un fichier de configuration, savoir quels vhosts sont actifs...

Commande d'activation/désactivation:

• Activer un vhost : a2ensite 001-toto.conf
• Désactiver un vhost : a2dissite 001-toto.conf
• Activer un module (php5 ici) : a2enmod php5
• Désactiver un module : a2dismod php5

apache2ctl permet de contrôler le serveur:

• apache2ctl start/stop/restart
• Connaitre l'état du serveur : apache2ctl status
• Connaître la liste des vhosts actifs : apache2ctl -S
• Connaître la liste des modules actifs : apache2ctl -M
• Tester la configuration (ce n'est pas utlime mais ça détecte pas mal d'erreurs de config): apache2ctl configtest

 

Quelques références externes

Deux guides provenant de l'ANSSI : Un guide de définition d'une architecture de passerelle d'interconnexion sécurisée, et un autre sur la sécurisation d'un site web.

<pdf>Fichier:DefPassANSSI.pdf</pdf>       <pdf>Fichier:SecWebANSSI.pdf</pdf>