projet m1

Année 2005-2006
PROJET M1
Service d’hébergement Web mutualisé
Réalisé par :
BERTHELEMY Mathieu
GUILLOT Fabien
QUIGNON Alexandre
Encadrant : Abdenour MOKRANE
Sommaire
1
INTRODUCTION................................................................................................................................................... 4
2
CONCEPTION........................................................................................................................................................ 5
2.1
ARCHITECTURE GENERALE DE L'APPLICATION ................................................................................................. 5
2.1.1
Description du projet .................................................................................................................................. 5
2.1.2
Diagramme de cas d'utilisation .................................................................................................................. 6
2.1.3
Contraintes pour le choix d'une architecture.............................................................................................. 6
2.1.4
Architecture choisie .................................................................................................................................... 8
2.1.4.1
Architecture physique........................................................................................................................................ 8
2.1.4.2
Architecture logicielle ....................................................................................................................................... 9
2.2
STRUCTURE DES DONNEES................................................................................................................................ 9
2.2.1
Explication et description des données....................................................................................................... 9
2.2.2
Mettre la base de données sous une forme normale ................................................................................. 10
2.3
ORGANISATION DES TESTS.............................................................................................................................. 11
2.3.1
Les tests manuels ...................................................................................................................................... 11
2.3.2
Les tests automatisés................................................................................................................................. 11
2.4
LE PORTAIL WEB............................................................................................................................................. 12
2.4.1
2.4.1.1
Le module php-Mysql...................................................................................................................................... 12
2.4.1.2
Organisation d’une page web .......................................................................................................................... 12
2.4.1.3
Configuration de Apache ................................................................................................................................. 12
2.4.2
Description de l'architecture du module Web........................................................................................... 13
2.4.2.1
Le diagramme de paquetages........................................................................................................................... 13
2.4.2.2
Description des paquetages.............................................................................................................................. 13
2.5
LA BASE DE DONNEES ET SES REQUETES ......................................................................................................... 15
2.5.1
Enregistrement des informations .............................................................................................................. 15
2.5.2
Sélection et altération d’informations....................................................................................................... 16
2.5.2.1
La requête de sélection .................................................................................................................................... 16
2.5.2.2
La requête de modification .............................................................................................................................. 16
2.6
3
Choix d'implantation................................................................................................................................. 12
AUTHENTIFICATION........................................................................................................................................ 16
2.6.1
Confidentialité des données ...................................................................................................................... 16
2.6.2
Authentification des utilisateurs................................................................................................................ 17
2.6.3
Contrôle des droits.................................................................................................................................... 17
MISE EN PLACE DES SERVICES ET DE LA MACHINE ............................................................................ 18
3.1
PREAMBULE ................................................................................................................................................... 18
3.2
INSTALLATION DU SERVEUR ........................................................................................................................... 18
3.2.1
Serveur Web – Apache .............................................................................................................................. 19
3.2.2
Base de données et son outil d’administration ......................................................................................... 20
2/44
3.2.3
Serveur FTP.............................................................................................................................................. 21
3.2.4
Serveurs de messagerie............................................................................................................................. 22
3.2.4.1
Schéma général................................................................................................................................................ 22
3.2.4.2
Serveur SMTP ................................................................................................................................................. 23
3.2.4.3
Serveur POP3 / IMAP ..................................................................................................................................... 24
3.2.4.4
Anti-Spam........................................................................................................................................................ 24
3.2.4.5
Anti-virus......................................................................................................................................................... 24
3.2.4.6
Amavis............................................................................................................................................................. 24
3.2.4.7
Webmail .......................................................................................................................................................... 24
3.2.4.8
Recettes unitaires............................................................................................................................................. 25
3.2.5
Statistiques Web par sous-domaine via Awstats ....................................................................................... 25
3.2.6
Organisation des pages et gestion des mots de passes ............................................................................. 26
3.2.7
Automatisation des tâches d’administration ............................................................................................. 26
3.2.8
Sécurité du système ................................................................................................................................... 27
3.2.8.1
Préambule ........................................................................................................................................................ 27
3.2.8.2
SuPHP ............................................................................................................................................................. 27
3.2.8.3
Sudo................................................................................................................................................................. 27
3.2.8.4
Disponibilité des données des utilisateurs........................................................................................................ 28
4
CONCLUSION...................................................................................................................................................... 29
5
ANNEXES.............................................................................................................................................................. 30
6
SITOGRAPHIE............................................................................................... ERREUR ! SIGNET NON DEFINI.
7
BIBLIOGRAPHIE .......................................................................................... ERREUR ! SIGNET NON DEFINI.
3/44
1 Introduction
Le but de ce projet est la conception d’un service d’hébergement web mutualisé gratuit pour
particuliers et professionnels. Ce projet n’a été conçu qu’à partir d’outils du monde des logiciels
libres.
Nous avons choisi ce sujet pour plusieurs raisons :
C’est un sujet concret et au goût du jour (l’Internet est en pleine expansion)
Il pourra être mis en production à la fin du projet
Il reprend des concepts et des connaissances acquises durant l’année
L’acheminement d’un projet dans son intégralité
Il nous a permit de développer de nouvelles compétences et connaissances
De plus en plus d’Internautes possèdent leurs propres pages personnelles, pas seulement à travers
les blogs dont les fonctionnalités restent encore limitées mais surtout à travers des sites personnels.
Ces sites peuvent intégrer de nombreuses possibilités (forum, portail php…) si l’hébergeur possède
et offre à ces usagers le support de langage PHP, une base de donnée…
Toutes ces fonctionnalités sont donc à intégrer à notre projet pour pouvoir offrir l’ensemble de ces
services à nos usagers. Ainsi que des comptes e-mails, un sous-domaine personnalisé, des
statistiques personnelles.
4/44
2 Conception
2.1
Architecture générale de l'application
Le but de cette partie est de décrire l'architecture générale du projet « Service d’hébergement
mutualisé » et de préciser les matériels et logiciels requis pour sa mise en place.
2.1.1
Description du projet
Ce projet consiste à concevoir un service d'hébergement mutualisé pour particuliers ou bien pour
des professionnels. Ce projet consiste à héberger plusieurs sites Internet sur un seul et même
serveur et ainsi partager les ressources de celui-ci entre différents utilisateurs.
Ce type de formule est donc proposé aux personnes pour qu'elles puissent obtenir une configuration
donnée ce qui correspond à une offre logicielle comprenant : un serveur web, un sous-domaine, un
accès à sa base de données, des comptes de messagerie, un accès ftp avec un espace de stockage
bien défini en fonction de l’offre choisie ainsi que des statistiques Web par sous-domaine.
La personne pourra à tout moment changer d'offre logicielle afin que ses besoins restent en accord
avec ses attentes. Ce projet inclus donc la création d'un portail web muni d’une base de données,
une description des offres, une charte, l'inscription en ligne et l'administration de son compte (voire
la possibilité d’incorporer un système de payement par Internet pour les offres payantes).
5/44
2.1.2
Diagramme de cas d'utilisation
2.1.3
Contraintes pour le choix d'une architecture
Le choix d'une architecture pour ce projet est conditionné par un certain nombre de critères et de
contraintes qui doivent être respectés.
6/44
Les contraintes initiales de l'hébergeur de sites web mutualisé sont :
•
Type d'application
Application web sur réseau local, à terme, puis sur internet.
•
Stockage des documents
Après avoir étudié différentes possibilités, l'étude nous a révélés que la meilleure
solution pour stocker les différentes données était une base MySQL avec un module
php. En effet Mysql a pour avantages d'être libre, gratuite, performante et dont le
développement est très actif.
•
Testabilité
Afin de garantir la conformité et de simplifier la maintenance de ce projet, son
architecture doit permettre de mettre en place des procédures de tests automatisées
afin de pouvoir facilement et rapidement vérifier des propriétés de correction des
algorithmes de non-régression des fonctionnalités, etc.
•
Évolutivité
L'hébergeur de sites web mutualisé doit pouvoir être facilement adaptable aux
évolutions des données et des logiciels avec lesquels il devra interagir (base de
données, serveur ftp...). Il doit aussi être adaptable afin de supporter un
accroissement de la charge en terme de requêtes (ouverture sur internet).
•
Configurabilité
Ce projet doit pouvoir être facilement configurable (modifications mineures du
fonctionnement) pour s'adapter à son contexte et à son évolution (notamment
l'intégration dans un site web).
•
Coût
Pour sa mise en oeuvre, le projet ne doit pas nécessiter de matériels ou de logiciels
trop coûteux.
7/44
2.1.4
2.1.4.1
Architecture choisie
Architecture physique
L'architecture physique idéale serait de dédier une machine pour chaque service, de manière à
répartir au maximum les charges et de gagner en performance globale. Le schéma serait :
Cependant, nous n’avons pas le matériel nécessaire pour mettre un tel système en place nous
n’avons pas d’autre choix que de placer l’ensemble des services sur une seule machine. Nous ne
pouvons pas mettre en place un serveur de backup mais nous assurerons tout de même la
sauvegarde des données des utilisateurs par un autre biais, car c’est une fonction indispensable
pour un serveur Web de garantir l’intégrité de ces données.
Client
Le client est un navigateur web récent. Il doit disposer d'une connexion réseau s'il est en réseau
local ou d'une connexion Internet (le plus souvent utilisée) si nécessaire.
Base de données
La base de données utilisée est une base de données MySQL gérée avec PhpMyAdmin. Elle peut
tourner sur une machine dédiée ou sur un serveur d'applications. Dans notre cas, sur la même
machine.
8/44
Serveur d'applications
Le serveur d'applications doit être accessible depuis Internet (Transfert de ports sur le routeur vers
notre (nos) machine(s)). Un serveur Apache (ou autre serveur http) doit être installé sur ce serveur
ainsi que l'application développée. Un serveur FTP doit également être installé ainsi qu'un serveur
mail (POP, IMAP et SMTP) afin que chaque utilisateur puisse consulter ses e-mails.
2.1.4.2
Architecture logicielle
L'application est composée :
D’un ensemble de pages web (formulaires) qui en sont les points d'entrées.
D'un ensemble de scripts qui permettent d’automatiser les tâches telles que la création, la
suppression, la modification de comptes locaux à la machine (pour accès FTP) ; ou
encore la mise à jour des statistiques web, la sauvegarde et l’archivage des données des
utilisateurs et enfin l’automatisation de tâches comme le redémarrage de services…
2.2
Structure des données
Le but de ce document est de décrire la structure des informations telles qu'elles seront stockées
dans la base de données, et telles qu'elles seront retournées par les requêtes de la base de données.
2.2.1
Explication et description des données
Tout d'abord, il faudra séparer la base de données afin que seul un utilisateur puisse accéder à sa
propre base.
Le principe est de pouvoir établir un nombre de tables suffisamment explicite afin de stocker les
éléments essentiels.
L’identifiant d'un compte est unique et sera donc considéré comme clé primaire pour chaque table.
Les tables qui ne seront utiles d'établir de cette façon :
•
Une table « inscription » comprenant le login (clé primaire), prénom, nom, adresse, société,
code postal, ville, e-mail, offre, nom du domaine, message.
•
Une table « authentification » comprenant le login et le mot de passe (password) permettant
ainsi de renforcer un peu la sécurité.
•
Et les tables « users, domains, forwarding » dans une base db_postfix permettant de gérer
ses comptes mails.
9/44
Quelques contraintes sur les attributs :
Le mot de passe devra être crypté en md5 et devra être confirmé lors de la saisie du
formulaire et non vide (voir imposer 6 caractères au minimum).
Le login devra être non vide et unique.
Mot de passe sur machine UNIX (accès FTP) en cryptage DES.
Nom du sous-domaine unique.
2.2.2
Mettre la base de données sous une forme normale
Voici les tables décrites précédemment dans une forme décomposée :
Base de donnée : « projet » :
Pour la table « inscription »
Login → login, prénom, nom, adresse,société,postal, ville, email,nom_domaine,message
Pour la table « authentification »
Login → login, password
Base de donnée « db_postfix » :
Pour la table « users »
Login → email, mot de passe
Pour la table « forwardings »
email_source → email_destination
Pour la table « domains »
nom_domain
Ainsi on prouve que :
login → login, password, nom, adresse,société,postal, ville, email, nom_domaine, message, email1,
motDePasse1, email2, motDePasse2, mail3, motDePasse3 mail4, motDePasse4, mail5,
motDePasse5
► Donc la base de données que nous allons établir respect la 3ème forme normale.
10/44
2.3
Organisation des tests
Le but de cette partie est de décrire les mécanismes qui permettront de faire des tests de non
régression suite aux modifications faites durant la phase de développement, et de valider
l'application à la fin de la phase de développement. Notre ambition est d'automatiser au maximum
les tests qui permettront de valider l'application. Cette technique sera utile tant durant la phase de
développement que durant la phase de recettes.
2.3.1
Les tests manuels
Les tests manuels seront surtout pour la vérification finale notamment pour les pages web contenant
des interactions avec la base de données :
Inscription à une offre (conformité de l’inscription → tous les champs sont renseignés).
Gestion de son compte.
Ajout et suppression de pages web au serveur.
Création ou suppression de comptes mails.
Possibilité de faire du transfert de mail vers une autre adresse.
La gestion de son profil.
La gestion de sa base de données (et la sienne uniquement).
2.3.2
Les tests automatisés
Les tests automatiques s'effectueront à l'aide de nos scripts shell (en BASH). En effet, ceux-ci
permettent lors de la création d’un nouvel utilisateur sur le système de contrôler certains éléments
(utilisateur déjà existant, répertoire personnel déjà existant, « virtual-host » déjà existant…). De
cette manière, on vérifie certaines contraintes avant chaque création, suppression ou modification
d’utilisateur. Tous les résultats de ces tests sont enregistrés dans un fichier log. Celui-ci nous permet
de garder des traces des opérations effectuées sur la machine mais également de repérer les
éventuelles erreurs et de les corriger.
11/44
2.4
Le portail web
Le but de cette partie est de décrire les mécanismes liés au site web et aux choix qui ont été faits.
2.4.1
2.4.1.1
Choix d'implantation
Le module php-Mysql
PHP est un langage de programmation interprété. Correctement interfacé avec Apache il permet au
serveur de fournir des pages dynamiques gérées en fonction des demandes du client. En clair, la
page n'est plus un document statique mais peut évoluer, afficher des informations différentes selon
les souhaits de l'utilisateur. Pour des raisons de compatibilité, sur notre serveur, les pages pourront
soit être interprétées par PHP4 ou par PHP5 selon la volonté de l’utilisateur.
MySQL est un gestionnaire de bases de données assez puissant et rapide. Il peut très bien
fonctionner en utilisant son propre client en mode texte sans l'utilisation d'une quelconque interface
graphique. Le langage SQL est utilisé par MySQL (proche de la norme ANSI) et utilise des lignes
de commande pour adresser des requêtes au serveur.
2.4.1.2
Organisation d’une page web
Les pages PHP sont organisées généralement en deux parties, une partie proprement PHP ou
s’effectueront les traitements dynamiques de la page (en fonction de nos attentes) et une partie
HTML, contenant la structure de la page (tout ce qui est visible par l’utilisateur).
C’est dans la partie PHP que s’effectue l’ensemble des requêtes avec la base de données
(consultation, ajout, modification ou bien surpression de données).
2.4.1.3
Configuration de Apache
La configuration peut être prise en charge par le système de gestion de paquetages. Sinon, il faut
récupérer les sources du serveur Apache (http://www.apache.org). Il faut également récupérer le
module apache-php afin de permettre au serveur apache d'interpréter le langage php. Pour notre
projet nous aurons également besoin du module mod_ssl pour passer en données sécurisé.
Nous créons aussi des « VirtualHosts » afin que chaque utilisateur ait son propre sous-serveur Web
pointant vers le sous-domaine qu’il aura préalablement choisi. Ensuite, l’utilisateur pourra
ajouter/supprimer des pages à son espace web. Il aura uniquement accès à son dossier personnel.
Pour info, les VirtualHosts permettent d'établir plusieurs sites web (en fonction du sous-domaine
choisi) sur un seul serveur apache.
Le serveur SSH servira à l'administrateur de pouvoir prendre le contrôle du serveur à distance avec
un shell sécurisé.
12/44
2.4.2
2.4.2.1
Description de l'architecture du module Web
Le diagramme de paquetages
Voici le diagramme de classe (par module):
2.4.2.2
Description des paquetages
Le paquetage « authentification »
Ce paquetage va permettre à l'utilisateur déjà inscrit de pouvoir accéder à sa session. La fonction
verif_authentification.php renverra le menu ou un message d’erreur si l'authentification est correcte
ou non.
13/44
Le paquetage « inscription »
Ce paquetage a pour but d'inscrire une personne dans la base de donnée. On lui présentera un
formulaire et devra s'inscrire. On vérifiera si le login est déjà utilisé, si le mot de passe ne respecte
pas les critères souhaités, etc. Si tous les critères sont respectés alors l'utilisateur sera enregistré
dans la base de données. Puis, après contrôle de la validité des informations entrées par l’utilisateur
par l’administrateur, celui-ci valide son compte. Le système envoi ensuite automatiquement un email à l’utilisateur, pour qu’il confirme son inscription. Suite à cela, le système lui créera son accès
au serveur ftp, l’accès à la gestion de son compte, la gestion de ses mails, ses statistiques et sa base
de données personnelle.
Le paquetage « mails »
Ce paquetage est chargé de gérer les e-mails de l’utilisateur. Tout est géré par l’intermédiaire de la
base de données « db_postfix » : ajout, suppression, changement de mot de passe et transfert de
mails. En effet, le serveur de messagerie Postfix, est interfacé avec la base de donnée MySQL, ce
qui facilite grandement l’administration des e-mails.
Le paquetage « changement »
Ce paquetage permet à l'utilisateur de visualiser son profil et de le modifier à tout moment. Il peut
également changer de mot de passe (portail web, phpMyAdmin, FTP).
Le paquetage « ftp »
Ce paquetage permet d'ouvrir une connexion ftp avec le serveur. L'utilisateur aura le droit de
stocker qu'une certaine capacité de données (en fonction de l’offre choisie). L’utilisateur aura le
choix d’utiliser le client FTP de son choix ou d’utiliser un outil intégré à son interface
d’administration : « net2ftp »
Le paquetage « webmail »
Nous utiliserons le Webmail « SquirrelMail » pour l’accès à ses e-mails via l’explorateur Web.
Le paquetage « administrateur »
Ce paquetage n’est accessible que par l'administrateur. De sa console d’administration, il est
capable de voir tous les utilisateurs inscrits ou en demande d’inscription et consulter leurs
informations respectives. Il peut également les supprimer définitivement du système.
14/44
2.5
La base de données et ses requêtes
Le but de cette partie est de décrire le fonctionnement des requêtes avec la base de données
MySQL. La première partie décrit les classes qui permettent d'enregistrer les informations. La
seconde décrit les opérations de sélection, de modification et de suppression.
2.5.1
Enregistrement des informations
Après s'être inscrit, les informations sur l’utilisateur sont directement enregistrées dans la base de
données. En effet chaque champ rempli du formulaire sera directement incorporé dans la base de
données.
Les tables choisies sont les suivantes :
« authentification » avec le login et le mot de passe crypté en md5 et en DES.
« inscription » avec toutes les données de l'utilisateur
« users, domain et forwardings » de la base « db_postfix »avec les mails de l’utilisateur (5
maximum).
Tous ces comportements sont décrits plus en détail dans la partie 2 (Structure des données)
La base de données MySql s'appuie sur le langage SQL. Il faudra d'abord écrire la requête SQL
classique, puis l'exécuter à l'aide d'une fonction spécifique à MySQL dans une page PHP. Voici le
déroulement des requêtes :
1. Il faut se connecter à la base de données avant d'effectuer toutes les opérations sur la base:
$my=mysql_connect($serveraddr,$login,$password);
mysql_select_db($base_de_donnee,$my);
2. Les requêtes d'insertion seront du type (exemple):
Requête permettant d’insérer les informations relatives à un utilisateur :
$sql = "INSERT INTO inscritVALUES ('$login', '$nom', '$prenom', '$societe', '$adresse',
'$codepostal', '$ville', '$offre', '$nomdedomaine',
'$referencement', '$email','$message')";
mysql_query($sql) or die('Erreur SQL!'.$sql.'<br>'.mysql_error());
Requête permettant d’insérer l’identifiant et le mot de passe (crypté) d’un utilisateur :
$sql1= "INSERT INTO authentification VALUES ('$login',md5('$password'))";
mysql_query($sql1) or die('Erreur SQL!'.$sql1.'<br>'.mysql_error());
15/44
2.5.2
Sélection et altération d’informations
On peut également consulter des données ou les modifier. Pour cela le langage SQL utilise deux
requêtes différentes.
2.5.2.1
La requête de sélection
La requête de sélection a pour but d'afficher et de présenter de façon correcte le résultat à
l'utilisateur. Comme précédemment la requête vers la base de données MySQL vient du langage
SQL ; le résultat de cette requête est traité pour être affiché sous forme de tableau (mise en forme
par les balises HTML).
Voici la description d'une requête de sélection avec mise en forme :
$sql = "SELECT nom FROM inscrit WHERE login='$login1' ";
$req = mysql_query($sql) or die('Erreur SQL !<br>'.$sql.'<br>'.mysql_error());
if ($data = mysql_fetch_assoc($req)) { echo $data['nom'];}
2.5.2.2
La requête de modification
Cette requête sert à supprimer des données (modification d'un attribut en un champ vide) ou bien à
modifier la valeur d'un attribut. De même que précédemment le langage SQL sera le langage utilisé
pour cette requête.
Voici la description d'une requête pour une modification de son profil:
$sql="UPDATE inscrit SET email='$adressemail1', nom='$nom1',prenom='$prenom1',
codepostal='$adressepostal1' WHERE login='$login1'";
mysql_query($sql) ;
2.6
Authentification
Cette partie traite de l'authentification des utilisateurs et des problèmes de sécurité en terme de
confidentialité.
2.6.1
Confidentialité des données
L'authentification des utilisateurs est nécessaire parce que les données relatives à lui sont
confidentielles (Nom, adresse…).
Pour assurer que ces données ne puissent être lues par des personnes étrangères, il est impératif que
ces données soient protégées et que les mots de passes soient chiffrés. En effet, imaginons que ce ne
soit pas le cas, les équipements réseaux pourraient voir passer en clair ces données tant au niveau :
des serveurs, des routeurs, des routeurs du fournisseur d'accès, des routeurs Internet, ainsi que des
hubs ou des switches. Quel que soit le point de passage, on ne peut pas exclure que quelqu'un soit
équipé d'un logiciel d'administration réseau (sniffer) qui permette de récupérer des mots de passes
non crypté et ainsi d’accéder aux informations personnelles de nos utilisateurs.
16/44
Les mots de passes des utilisateurs sont cryptés au format MD5 dans la base de donnée et en DES
sur la machine UNIX. Les mots de passe sous Linux ou UNIX sont généralement contenus dans le
fichier /etc/password ainsi que toutes les infos systèmes des comptes utilisateurs. Ce fichier
est en lecture seule pour tout le monde pour le besoin de différents programmes, et juste en écriture
pour l'administration (ROOT). Le problème est que si on peut le lire, on peut donc le récupérer et
tenter un décryptage de force dessus. Alors on a inventé le shadowing. Les mots de passe ne sont
plus stockés dans le fichier /etc/password mais dans un fichier généralement (pas toujours)
appelé /etc/shadow. Ce fichier est par contre illisible par tout le monde sauf le root bien sur. Ce
qui permet déjà à tous les utilisateurs non root de ne pas pouvoir récupérer ce fichier et de tenter
une attaque du type « brute force » dessus.
Il faut ajouter à cela une règle permettant de renforcer la politique des mots de passe (longueur
minimale, caractères spéciaux…). Ainsi, on s’assure qu’aucun mot de passe ne pourra être
corrompu (à condition quand même que nos utilisateurs ne mettent leurs mots de passe sur un postit collé sur l’écran ;-)
2.6.2
Authentification des utilisateurs
Un système de login et mot de passe (pour l’accès à son compte) est suffisant pour nos besoins de
sécurité. La stratégie de conservation des mots de passe étant décrite précédemment.
2.6.3
Contrôle des droits
Le contrôle des droits d'accès sera renforcé au niveau du dossier de chaque utilisateur (la « home
directory » de son espace web). En effet à chaque création d’un nouvel utilisateur, on lui affecte les
droits appropriés (et seulement à lui). C'est à dire qu’il aura les droits en lecture, en écriture et en
exécution sur son dossier personnel.
De même pour sa base de données, on crée une base de données personnelle pour chaque utilisateur
avec son mot de passe et son login. Ainsi lui seul pourra y accéder et l’administrer (avec
phpMyAdmin).
Son sous-domaine (défini sur le serveur apache) sera en lecture pour tout le monde (ce qui est le but
du projet, permettre le partage d’information avec des millions d’autres personnes par Internet ;-).
Le compte administrateur en revanche aura accès à toutes les données et devra respecter la charte de
la CNIL. L'administrateur aura la responsabilité des données qui se situent sur son serveur. Il aura
le devoir de contrôler le contenu des sites web qu’ils hébergent et dans le cas de non-respect de la
charte (warez, racisme…) de les supprimer. C’est pourquoi, il a le privilège de suppression des
utilisateurs et de leur espace web dans l’interface d’administration.
17/44
3 Mise en place des services et de la machine
3.1
Préambule
Cette partie du rapport décrit les opérations que l’on a effectué pour mettre en œuvre l’intégralité
des services disponibles sur notre plate-forme d’hébergement Web mutualisé. Comme décrit dans
le cahier des charges et la phase de conception, nous avons installé et configuré principalement les
services suivants :
Serveur Web (apache)
Base de donnée (Myqld)
Administration Base de donnée par utilisateur (phpMyAdmin)
Serveur FTP (vsftpd)
Serveur de messagerie
Serveur POP (courier)
Serveur IMAP (courier-imap)
Serveur SMTP (postfix)
Accès Webmail (SquirrelMail)
Anti-virus (ClamAV)
Anti-Spam (SpamAssassin)
Statistique de chaque sous-domaine (Awstats)
Tous ces services ont été installés en prêtant particulièrement attention aux aspects sécurités qu’ils
imposent. Les Services disponibles doivent être récents et ne comporter aucune faille de sécurité
connue. Il est nécessaire également de retoucher aux fichiers de configuration, pour éviter des
lacunes dans les installations par défaut.
3.2
Installation du serveur
La première phase consistait à trouver une machine susceptible d’héberger notre service
d’hébergement mutualisé et puis de choisir l’OS le mieux adapté à nos besoins. Pour ce qui est de la
machine, nous avons récupéré un serveur DELL PowerEdge 1400 (PIII 800 et 512 de RAM avec 9
Go en SCSI) sur lequel nous avons choisi d’installer une Debian. Debian est toujours disponible en
3 versions (trois branches) qui sont :
•
stable : version figée où les seules mises à jour sont des correctifs de sécurité ;
•
testing : future stable où seuls les paquets suffisamment matures peuvent rentrer ;
•
unstable : version active, constamment nourrie de nouveaux paquets ou de mises à jour de
paquets déjà existants (surnommée Sid).
18/44
La version stable comporte des packages assez anciens par rapport aux distributions courantes (par
rapport à une mandrake 10.0 par exemple), mais ces packets ont été testés pendant un minimum de
6 mois par des spécialistes afin d'en corriger toutes les failles. La "stable" est donc bien plus
sécurisée et stable qu'une autre distribution (les "xBsd" n'étant pas des distributions linux), et
convient de ce fait parfaitement à une installation sur des serveurs de production.
La testing comporte des packets assez récents mais considérés comme suffisamment stables, datant
de 10 jours environ à 6 mois. Cela constitue donc une version intermédiaire, avec des packets plutôt
récents donnant ainsi accès à des logiciels en version récente.
Enfin, la "Sid" est à réserver aux connaisseurs, car parfois dangereuse. Lorsqu'un développeur
soumet un packet, celui-ci est directement mis en "Sid" pour être testé.
La distribution stable de Debian (Sarge) est celle qui convient le mieux à nos attentes, elle est très
sûre (et assez ancienne, encore au noyau 2.4), mais très sécurisé et stable, exactement ce qu’il
convient pour un serveur.
Pour ce qui est de l’installation, nous avons fait une installation minimale, c’est-à-dire, juste avec le
système de base, sans serveur X ni window manager. Seul le serveur SSH a été installé pour que le
serveur puisse être administrer et configurer à distance.
3.2.1
Serveur Web – Apache
Le logiciel Apache HTTP Server, souvent appelé Apache, est un serveur HTTP produit par la
Apache Software Foundation. C'est le serveur HTTP le plus populaire du World Wide Web. C'est
un logiciel libre avec un type spécifique de licence, nommée licence Apache.
Nous avons installé ce serveur Apache dans sa version 2.0.55. Ce serveur devait être capable
d’interpréter le PHP (php5, php4) et dialoguer avec une base de donnée (mysql). Toutes les
dépendances lors de l’installation de ces packages étaient gérées par le gestionnaire de packages de
Debian (APT), ce qui facilite bien la tâche.
Nous avons ensuite édité son fichier de configuration pour qu’il colle à nos spécifications. Il faut
que pour chaque utilisateur, notre service fournisse un sous-domaine. Pour cela, il faut spécifier au
fichier de configuration de Apache « /etc/apache2/httpd.conf », d’inclure un dossier contenant un
fichier par sous domaine existant (cela permet de faciliter l’administration des sous domaines :
ajout, suppression). Pour chaque sous-domaine nous avons un fichier contenant : (exemple toto) :
<VirtualHost 192.168.0.3>
<Directory /var/ftp/toto>
Allowoverride all
</Directory>
ServerName toto.homeonline.ath.cx
//nom du sous-domaine
DocumentRoot /var/ftp/toto
//Répertoire source – accès ftp
CustomLog /var/log/apache2/toto.homeonline.ath.cx-access.log common //log personalise par ss-domaine
ErrorLog /var/log/apache2/toto.homeonline.ath.cx-error.log
</VirtualHost>
Pour chaque nouvel utilisateur inscrit, il peut choisir son sous-domaine. Une fois ce nom récupéré,
on génère le fichier contenant son sous-domaine qui sera incluse dans la configuration de Apache.
On choisit de redémarrer que toute les 24 heures le serveur apache pour ne pas perdre en
disponibilité (on en peut pas se permettre de redémarrer le serveur à chaque fois qu’un utilisateur
19/44
s’inscrit). Le temps d’activation sera de 24 heures maximum pour un nouveau compte. On utilise
l’utilitaire crontab pour planifier cette tâche.
Note importante :
Au préalable, il a fallut cocher l’option « wildcard » pour notre nom DNS. Cette option est très
importante, c’est elle qui permet de faire fonctionner les sous-domaines. En effet, elle permet que
toutes les adresses de la forme : « *.homeonline.ath.cx » soit redirigées sur le nom de domaine en
question : « homeonline.ath.cx ». Ce n‘est pas une option qui est activé par défaut mais elle doit
absolument être activé, sinon un ping vers une adresse du type « test.homeonline.ath.cx », ne
pourrait fonctionner. (V. annexe 1)
3.2.2
Base de données et son outil d’administration
MySQL (SQL est acronyme de Structured Query Language en anglais) est un serveur de bases de
données relationnelles SQL très rapide, multi-thread, robuste et multi-utilisateurs. MySQL est un
logiciel libre développé sous double licence GPL et licence commerciale.
Nous avons installé le serveur « mysqld » sur notre serveur :
mysqld Ver 4.1.15-Debian_1-log for pc-linux-gnu on i486 (Source distribution)
Suite à l’installation de ce serveur, nous avons installé un outil d’administration de base de
données : « PhpMyAdmin » dans sa version 2.7.0. Il permet deux choses :
L’administration de la globalité des bases de données par l’administrateur.
La possibilité aux utilisateurs d’administrer directement leurs propres bases de données.
On utilise une authentification http et cookie qui convient parfaitement dans un
environnement multi-utilisateurs. Ainsi on donne l’accès qu’a la base de donnée de
l’utilisateur qui en est propriétaire.
PhpMyAdmin a besoin d'un utilisateur de contrôle - «controluser» - ayant seulement le privilège
SELECT sur les tables mysql.user (toutes les colonnes sauf «Password»), mysql.db (toutes les
colonnes), mysql.host (toutes les colonnes) et mysql.tables_priv (toutes les colonnes sauf
«Grantor» et «Timestamp»).
On doit spécifier les détails pour le controluser dans le fichier config.inc.php dans la section
paramètre $cfg[Servers][$i]['controluser']& $cfg[Servers][$i]['controlpass'].
On donne certains droits à cet utilisateur spécial, et enfin on accorde un ensemble de privilège sur
un utilisateur réel sur sa propre base. (V. annexe 2)
20/44
3.2.3
Serveur FTP
Nous avons choisi d’utiliser le serveur « vsftpd » (Very Secure FTPD). C’est un serveur FTP,
léger, rapide, conçu avec une volonté d'en faire un logiciel "sécurisé". Ce service FTP permet aux
utilisateurs de pouvoir uploader leurs fichiers sur leur espace Web.
A chaque fois qu’un nouvel utilisateur s’enregistre, un compte local est crée sur la machine avec un
répertoire d’accueil correspondant à l’endroit ou il enverra les fichiers qu’il veut rendre disponible
sur sa page web. Cet utilisateur appartiendra au groupe « chrvsftp » propre au serveur FTP. De plus,
pour une plus grande sécurité, tous les utilisateurs seront « chrooté » (c’est-à-dire enfermé) dans
leur home directory.
On adapte le fichier de configuration de vsftpd : « /etc/vsftpd.cond » en fonction de nos attentes.
Notamment le « umask » qui par défaut est à 077 alors que dans notre cas, il doit être positionné à
022 pour que le serveur Apache puisse interprété les fichiers dans la « home directory » des
utilisateurs (droit en lecture de l’utilisateur www-data – Apache).
Pour chaque nouvel utilisateur, on exécute la commande suivante dans le script de création d’un
nouvel utilisateur (exemple pour « toto ») :
#useradd -m --home /var/ftp/toto --password "pass_crypté_DES" --gid chrvsftp -shell /bin/false toto
Avec les droits suivants:
heracles:/var/ftp# ls -al
total 12
drwxr-xr-x 3 chrvsftp chrvsftp 4096 2006-02-27 20:42 .
[…]
drwxr-xr-x 2 toto chrvsftp 4096 2006-03-09 15:05 toto
21/44
3.2.4
3.2.4.1
Serveurs de messagerie
Schéma général
Voici le schéma général de la configuration d’un serveur de messagerie dont les éléments sont :
•
Postfix : C’est un serveur de messagerie électronique et un logiciel libre. Il se charge de la
livraison de messages électroniques (SMTP : Simple Mail Transfert Protocol). Il a été conçu
comme une alternative plus rapide, plus facile à administrer et plus sécurisée que l'historique
Sendmail.
•
MySQL : C’est la base de données qui contrôle le comportement de Postfix. Il contient des
tables pour les utilisateurs, les domaines et éventuellement les transferts d’e-mail.
•
Courier : C’est un serveur mail comme Postfix, seulement dans notre configuration, nous
allons juste l’utiliser comme serveur POP3 et IMAP. Ces deux protocoles permettent aux
utilisateurs d’accéder à leurs boites mails depuis l’extérieur.
22/44
•
SASL (La librairie Cyrius) : Pour « Simple Authentication and Security Layer » signifiant
« authentication simple et couche de sécurité » est un « framework » d'authentication et
d'autorisation normalisé par l'IETF.
•
AMaViS : C’est un élément qui permet de contrôler le contenu des e-mails qui passent par
Postfix. Il scanne les mails arrivant pour détecter les virus et les spams. Pour cela, ils
utilisent deux outils :
o Spamassassin : Le but de ce logiciel est de filtrer le trafic des courriels pour
éradiquer les courriels reconnus comme pourriel ou courriel non sollicité.
o ClamAV : C’est un logiciel antivirus très utilisé sous Unix. Il est utilisé avec les
serveurs de courriels pour filtrer les courriers comportant des virus. ClamAV est un
logiciel libre distribué sous licence GPL.
•
PhpMyadmin : Cet utilitaire permet de gérer sa base de donnée depuis une interface web.
Le serveur SMTP Postfix permet de gérer deux types de domaines : les domaines locaux et les
domaines virtuels. Les domaines locaux sont ceux définis dans le champs « mydestination » du
fichier de configuration de Postfix : « main.cf ». Ce type de domaine oblige de déclarer des
utilisateurs locaux aux systèmes (C’est-à-dire dans « /etc/passwd »). Les autres types de domaines
sont les domaines virtuels, ce sont des domaines très flexibles et ne nécessitent pas de compte
système pour chaque compte mail. On peut donc facilement gérer de multiples comptes mails sans
problème avec une base de données. On crée différents fichiers spécifiques qui vont permettre à
Postfix de connaître où chercher les informations pour router les messages vers les bons utilisateurs
(virtuels).
3.2.4.2
Serveur SMTP
On installe Postfix comme serveur SMTP avec le support de mysql. On a préalablement installé le
serveur de base de données « mysqld ». On a crée aussi la base « db_postfix » contenant les tables
des domaines, des utilisateurs ainsi que la table pour les transferts de mails (forwarding). Ensuite on
configure les fichiers permettant de faire le routage des mails vers la boite de l’utilisateur (virtuel)
concerné (v. Annexe 6). De plus, tous les mails sont ordonnés dans le répertoire « /home/vmail »,
celui-ci appartient à l’utilisateur ‘vmail’ qui possède les UID/GID 5000 (renseigné dans le fichier de
configuration de Postfix). Le fichier de configuration de Postfix « main.cf » se trouve en annexe 5.
Un autre point important concerne l’authentification des utilisateurs à utiliser le serveur SMTP afin
d’éviter de faire de notre serveur un « open relay » profitable aux spammeurs. Pour cela, on
demandera à Postfix d’utiliser SASL/MySQL, cela va permettre à Postfix de connaître un certain
nombre de méthodes d'authentification sécurisée.
La dernière étape consistera à utiliser TLS pour encrypter les sessionx SMTP de telle manière
qu’aucun mot de passe ne puisse circuler en clair. TLS utilise les librairies SSL pour encrypter les
communications entre le client et le serveur de messagerie. TLS utilisera un certificat X509 (vu en
cours de sécurité cette année) pour communiquer au client la clé publique de notre serveur de
messagerie.
23/44
3.2.4.3
Serveur POP3 / IMAP
Maintenant que nous avons notre serveur SMTP, il serait utile d’avoir un serveur POP3 et IMAP
afin de pouvoir récupérer nos e-mails. Nous allons donc mettre en place un serveur POP3 et IMAP
avec courier. Il faut indiquer à cet outil d’utiliser mysql pour l’authentification des utilisateurs, pour
cela on modifie « authdaemonrc » et « authmysqlrc » (dans « /etc/courier/ ») pour lui indiquer la
méthode à suivre. Ensuite on spécifie pour chaque services (POP3 et IMAP) leurs spécificités
(notamment type d’authentification, port…) dans les fichiers de configuration suivants : « pop3d »
et « imapd ». Les services sont maintenant configurés et actifs, il reste plus qu’à ouvrir les ports sur
le routeur pour qu’ils puissent être accessibles de l’extérieur.
3.2.4.4
Anti-Spam
L’autre outil important est bien sur un Anti-Spam. Spamassassin est un filtre anti-spam qui
effectue des tests heuristiques sur chaque mail afin de détecter les envois non sollicites.
3.2.4.5
Anti-virus
L’anti-virus est un outil important pour l’élaboration d’un service de messagerie. On utilise Clam
Antivirus, qui est un logiciel libre capable de reconnaître la plupart des virus connus.
3.2.4.6
Amavis
Pour luter contre ce fléau de virus, nous allons utiliser amavisd. Il a pour but de faire scanner les
e-mails par les antivirus enregistrés auprès de lui. Il permet de scanner les pièces attachées, et au
moyen de décompresseur de traiter tout type de pièces attachées.
Pour cela, il faut indiquer à Postfix, dans son fichier de configuration de renvoyer les e-mails qui lui
arrivent vers Amavis de telle manière qu’ils puissent les faire analyser (anti-virus et anti-spam).
3.2.4.7
Webmail
On a choisi d’installer SquirrelMail, C’est un webmail (c'est-à-dire une interface web pour
consulter son courrier électronique), écrit en PHP4. Il supporte les protocoles IMAP et SMTP.
Toutes les pages générées sont en HTML pur (sans aucun Javascript), ceci afin d'être compatible
avec le maximum de navigateurs.
Squirrelmail inclut de base toutes les options que nous attendions d'un logiciel de messagerie, y
compris le support MIME, un carnet d'adresses, et la création de dossiers pour trier les e-mails.
Ce système permet de pouvoir consulter ces e-mails n’importe où et sur n’importe quelles machines
dans le monde.
24/44
Notre Webmail fonctionne à l’adresse (via un sous-domaine « webmail ») :
http://webmail.homeonline.ath.cx
(V. Annexe 4)
3.2.4.8
Recettes unitaires
Il est évident qu’en installant un système aussi complet, il faut faire fréquemment des tests. Il faut
notamment tester que l’authentification SMTP, POP3 et IMAP fonctionnent, ainsi que l’anti-virus
et le Webmail.
Pour cela, on dispose de fichiers de log complet : « /var/log/mail.log » qui nous indique toutes les
informations nécessaire sur l’activité de notre serveur de messagerie (erreur d’authentification,
arrivée d’un e-mail, traitement par l’anti-virus, etc.).
Nous avons utilisé un outil disponible sur http://www.webmail.us/testvirus pour tester l’efficacité
de notre passerelle anti-virus. On constate aisément dans les logs les e-mails qui ont été bloqué ou
non.
Voici un exemple de rejet d’un e-mail car il contenait un virus :
May 11 15:50:58 heracles postfix/qmgr[1388]: 79923E3A93: from=<[email protected]>, size=1599, nrcpt=1 (queue active)
May 11 15:50:58 heracles amavis[9738]: (09738-04-5) Blocked BANNED (multipart/mixed,application/x-unparseable-multipart,.asc | .zip,eicar.zip
| .asc,EICAR.COM), [204.119.252.7] [204.119.252.7] <[email protected]> -> <[email protected]>, quarantine: banned0VGhhi9jX3I5, Message-ID: <[email protected]>, mail_id: 0VGhhi9jX3I5, Hits: -, 226 ms
May 11 15:50:58 heracles postfix/smtpd[25991]: disconnect from bmdc7.emailsrvr.com[204.119.252.7]
May 11 15:50:58 heracles postfix/smtp[25917]: 1C269E3A6B: to=<[email protected]>, relay=127.0.0.1[127.0.0.1], delay=3,
status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Message content rejected, id=09738-04-5 - BANNED: multipart/mixed,application/xunparseable-multipart,.asc | .zip,eicar.zip | .asc,EICAR.COM (in reply to end of DATA command))
May 11 15:50:58 heracles postfix/cleanup[25916]: 29FF2E3A78: message-id=<[email protected]>
May 11 15:50:58 heracles postfix/qmgr[1388]: 29FF2E3A78: from=<>, size=3682, nrcpt=1 (queue active)
May 11 15:50:58 heracles postfix/qmgr[1388]: 1C269E3A6B: removed
May 11 15:50:58 heracles postfix/cleanup[25960]: 06D37E3A6A: [email protected]
3.2.5
Statistiques Web par sous-domaine via Awstats
AWStats est un outil d’analyse statistique d’un site Web. Programmé en perl, il suffit de placer le
script dans le répertoire cgi de notre serveur, changer le chemin, et le tour est joué.
Voici quelques unes de ses fonctionnalités : le nombre de visites, de visiteurs uniques, de pages, de
hits, de transfert, par domaine/pays, hôte, heure, navigateur, OS, etc. Le tout apparaissant dans de
jolis graphiques simple à comprendre.
Chaque fois qu’un hôte virtuel est crée sur la machine (lors de l’ajout d’un utilisateur), on lui
attribue des logs personnalisés pour son sous-domaine. Ensuite on crée un fichier de configuration
awstats propre à son sous-domaine (pour une meilleure administration) de la forme suivante (sousdomaine test):
LogFile=/var/log/apache2/test.homeonline.ath.cx-access.log
LogType=W
LogFormat=4
DirIcons=/awstats-icon
25/44
SiteDomain=test.homeonline.ath.cx
On a ensuite crée un script en BASH qui va pour chacun de ses fichiers configuration (dans
/etc/awstats/) mettre à jour les statistiques du site (sous-domaine en fait). Ce script est mis en
annexe 9.
Il ne reste plus qu’à lancer ce script toutes les deux heures par exemple grâce à la crontab (v. annexe
8). On y accède ensuite à l’adresse (exemple sous-domaine test) :
http://homeonline.ath.cx/cgi-bin/awstats.pl?config=test.homeonline.ath.cx
3.2.6
Organisation des pages et gestion des mots de passes
Structure des pages :
Nous avons été obligés de suivre une structure bien particulière pour les pages php, à savoir pour
les variables de session et les header. Ce sont des fonctions qui permettent d’appeler une autre page
php. Elles doivent se faire tout au début du fichier php et avant tout affichage. Si cette règle n’est
pas respectée, l’en tête ne peut être envoyée avec les bonnes informations.
La structure des fichiers php sont toutes les mêmes. Elles sont constituées d’un en-tête (« top.php »)
et d’un pied de page (« bottom.php ») pour une meilleure maintenance des pages.
L’organisation complète de notre application Web est située en annexe 10 sous la forme d’un
organigramme.
Interopérabilité des mots de passes
A chaque inscription d’un utilisateur, il a accès à 3 outils différents (portail PHP pour gestion de
son compte, PhpMyAdmin et le serveur FTP). Pour chacun de ces outils, le mot de passe est stocké
à un endroit diffèrent et est souvent chiffré différemment. Lorsqu’il s’inscrit il faut donc le déclarer
au niveau de notre portail web mais aussi au niveau de PhpMyAdmin et de la machine UNIX pour
l’accès au serveur FTP. Il en est de même lors de la modification du mot de passe de l’utilisateur,
nous devons lancer des requêtes SQL pour la modification des deux premiers puis un script BASH
capable de modifier directement le fichier « /etc/shadow » pour celui su système.
Au niveau de PHP maintenant, les mots de passe se situant sur la base de données sont codés par la
fonction « md5() », pour celui sur le système, par la fonction « crypt() » (correspond au codage
DES).
3.2.7
Automatisation des tâches d’administration
Pour automatiser les tâches d’administration, nous avons créé des scripts shell (en BASH) lancés
depuis une page PHP ou depuis la « crontab ». Outre le script pour « awstats », nous avons créé des
scripts permettant d’automatiser la création d’un compte sur la machine (pour l’accès FTP), la
suppression des comptes mais aussi la modification du mot de passe. Ces 3 scripts sont lancés à
partir des pages PHP en prenant bien soins d’utiliser l’utilitaire « sudo » pour des raisons de
sécurité. (Annexe 11).
26/44
3.2.8
3.2.8.1
Sécurité du système
Préambule
La sécurité occupe une place importante dans un tel projet. Garantir la disponibilité des services,
l’intégrité et la confidentialité des données du système ainsi que celle de nos utilisateurs est un
facteur important de fiabilité pour un service d’hébergement Web.
C’est pourquoi l’aspect de la sécurité ne peut être négligé dans un tel projet. D’autant plus que le
Web est un endroit peu sur, les infractions sont de plus en plus nombreuses chaque jour, et les
services d’hébergement Web sont des cibles de choix aux attaques malveillantes.
Notre machine se doit d’être sécurisé. Au niveau du système en lui-même mais aussi de tous les
services accessibles depuis le Web. L’infrastructure réseau ne doit pas être négligée (Firewall, IDS,
DMZ…) mais ce n’est pas ici notre sujet. Nous nous occuperons donc seulement de la sécurité de
notre machine.
3.2.8.2
SuPHP
Sur un serveur accueillant de nombreux utilisateurs, tous n'étant pas de confiance, il est très
pratique que les scripts PHP s'exécutent avec les droits de leur propriétaire ! C'est possible grâce à
suPHP !
De plus grâce à ce module nous pourrons exécuter des scripts PHP4 et des scripts PHP5. C'est très
pratique car la plupart des applications PHP disponibles utilisent encore PHP4 (phpBB, DotClear...)
mais PHP5 c'est l'avenir.
Ainsi sur notre serveur, les fichiers se terminant par .php ou .php4 seront exécutés par PHP4 et ceux
qui terminent par .php5 s’exécuteront avec PHP5. Et chaque page PHP sera exécuté avec les droits
de son propriétaire, c’est une sécurité indispensable pour le service que nous fournissions.
3.2.8.3
Sudo
Nous avons eu l’occasion d’étudier cette année en administration l’utilité de cette commande, elle
permet d’autoriser certains utilisateurs à exécuter des commandes avec les droits du super
utilisateur (ROOT).
Dans notre cas il fallait que l’utilisateur système qui lance le daemon apache (www-data) ai le droit
d’exécuter certains scripts pour la création, suppression d’utilisateur ou encore création de fichiers
de configuration apache et awstats.
Le fichier de configuration sudoers se trouve en annexe 7.
27/44
3.2.8.4
Disponibilité des données des utilisateurs
Un service d’hébergement Web se doit de garantir la disponibilité et l’intégrité des données de ses
utilisateurs. Pour cela, le mieux serait de disposer d’un autre serveur dit de secours qui serait
capable de prendre le relais au moindre problème, comme nous l’avons stipulé dans la phase de
conception. Cependant à moindre échelle et dans notre cas (pour notre projet), nous n’avons pas les
moyens techniques pour mettre en place une telle infrastructure mais nous devons tout de même
prendre soin de sauvegarder les données de nos utilisateurs. L’idéal serait de disposer d’un système
de disques en RAID 1 de manière à conserver une image du disque à tout moment. Cependant
comme nous ne disposons pas d’un second disque, nous avons décidé de créer un petit script (en
BASH) qui aura pour tâche de compresser et d’archiver les pages personnelles de tous les
utilisateurs (« tar.gz ») puis ensuite de l‘envoyer sur un serveur distant via FTP (annexe 11). De
cette manière, en effectuant cette sauvegarde tous les jours (à 5 heures du matin via la crontab de
root), nous disposons d’un point de sauvegarde récent pour reprendre notre activité si jamais un
problème se déclare sur notre disque. Il en est de même pour la base de donnée, de manière à
conserver les informations ainsi que les comptes de nos utilisateurs (e-mail compris).
28/44
4 Conclusion
Ce projet qui s'est déroulé sur un peu plus de 7 mois, nous a permit d'approfondir nos connaissances
dans plusieurs domaines:
Appréhender et piloter un projet sur plusieurs mois en équilibrant et planifiant
correctement les différentes phases de travail.
Réaliser un document de conception sur un projet concret (comme nous l'avons appris
cette année en « Gestion de Projet »)
Installer et administrer une machine Linux sous Debian 3.0 ainsi que mettre en place et
configurer les différents services utiles à notre projet (apache, Postfix, MySQL,
vsftpd…)
Concevoir des scripts shell (BASH) sous Linux permettant d’automatiser les tâches
d’administration sur le serveur.
Apprendre le langage PHP utile à la conception de notre portail Web dynamique.
Réaliser des tests d’intégrations et effectuer des recettes.
Sécuriser une machine ainsi que les applications en place dessus.
C’est un projet qui fut intéressant et complet. Il aurait pu l’être encore plus, en mettant en place plus
de moyens, notamment aux niveaux de la disponibilité des données et des services (en séparant les
services sur différentes machines ainsi que les données). Mais aussi au niveau de l’architecture du
réseau en place dans une solution d’hébergement.
Cependant, au final, avec les moyens que nous possédions, nous avons tout de même réussi à
produire quelques choses de fiable et stable capable d’accueillir des dizaines voir des centaines
d’utilisateurs.
Nous pourrions même dans le futur, élargir nos offres et pourquoi pas, proposer une offre payante
fournissant autant de services et d’avantages que tout autres hébergeurs. L’avenir nous le dira…
29/44
5 Annexes
Annexe 1
30/44
Annexe 2
Configuration phpMyadmin pour authentification http par cookie
Pour debian: /etc/phpmyadmin/config.inc.php
$cfg['Servers'][$i]['controluser'] = 'crtluser';
// MySQL control user settings
$cfg['Servers'][$i]['controlpass'] = 'crtlpass';
// access to the "mysql/user"
//Droits à appliquer
GRANT USAGE ON mysql.* TO 'crtluser'@'localhost' IDENTIFIED BY 'projpodium';
GRANT SELECT (
Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv,
Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv,
File_priv, Grant_priv, References_priv, Index_priv, Alter_priv,
Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv,
Execute_priv, Repl_slave_priv, Repl_client_priv
)
ON mysql.user TO 'crtluser'@'localhost';
GRANT SELECT ON mysql.db TO 'crtluser'@'localhost';
GRANT SELECT ON mysql.host TO 'crtluser'@'localhost';
GRANT SELECT (Host, Db, User, Table_name, Table_priv, Column_priv)
ON mysql.tables_priv TO 'crtluser'@'localhost';
//création user et droits
CREATE DATABASE `db_user1` ;
GRANT ALL PRIVILEGES ON db_user1.* TO 'user1'@localhost IDENTIFIED BY 'passuser1';
31/44
Annexe 3
32/44
Annexe 4
(Ecran login)
(Ecran Webmail)
33/44
Annexe 5
Configuration Postfix (main.cf):
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
delay_warning_time = 4h
myhostname = homeonline.ath.cx
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = localhost
relayhost = smtp.free.fr
mynetworks = 127.0.0.0/8,192.168.0.0/24
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
//routage des mails
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_forwardings.cf mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
//authentification
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
//envoi mail vers Amavis pour contrôle
content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings
Configuration SASL avec SMTP (smtpd.conf):
pwcheck_method: auxprop
auxprop_plugin: sql
mech_list: plain login cram-md5 digest-md5
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: postfix
sql_passwd: passpostfix
sql_database: db_postfix
sql_select: select password from users where email='%u@%r'
Annexe 6
34/44
Fichiers pour le routage des mails par Postfix dans le système (via la base de donnée MySQL).
mysql-virtual_email2email.cf :
user = postfix
password = …
dbname = db_postfix
table = users
select_field = email
where_field = email
hosts = 127.0.0.1
mysql-virtual_forwardings.cf :
user = postfix
password = …
dbname = db_postfix
table = forwardings
select_field = destination
where_field = source
hosts = 127.0.0.1
mysql-virtual_mailboxes.cf :
user = postfix
password = …
dbname = db_postfix
table = users
select_field = CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/')
where_field = email
hosts = 127.0.0.1
mysql-virtual_domains.cf :
user = postfix
password = …
dbname = db_postfix
table = domains
select_field = 'virtual'
where_field = domain
hosts = 127.0.0.1
35/44
Annexe 7
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#
Defaults
env_reset
# Host alias specification
# User alias specification
# Cmnd alias specification
Cmnd_Alias
PHP=/var/www/scripts/add_account.sh,/var/www/scripts/del_account.sh,/var/www/scripts/maj_account.sh
# User privilege specification
root
ALL=(ALL) ALL
dany ALL=(ALL) ALL
www-data ALL=(ALL) NOPASSWD:PHP
Annexe 8
Tâches planifiées dans la « crontab » :
heracles:/etc/awstats# crontab -l
# m h dom mon dow command
#restart serveur web pour ajour des nouveau vhost ts les jous a 01h00
0 1 * * * /etc/init.d/apache2 restart 2>&1
#Mise a jour de awstats pour tous toues les deux heures
* */2 * * * /root/update_awstats.sh
#Sauvegarde des données personnels de nos utilisateurs tous les jours à 5 heures du matin
0 5 * * * /root/save_all_users.sht 2>&1
36/44
Annexe 9
Script de mise à jour des statistiques d’accès aux pages web des utilisateurs (par sous-domaine)
#!/bin/bash
#
# Auto update for all domains
#
#awstats directory
cd /etc/awstats/
#date
today=`date +%d-%m-%Y`
#sous-domaine
sousdomaine=homeonline.ath.cx
#pour tous les fichiers
for i in `ls *.conf`
do
#recupere le nom
nom=`echo $i | cut -f2 -d.`
#For mail statistic
/usr/lib/cgi-bin/awstats.pl -config=mail -update >/dev/null
status=$?
echo "[ $today ] Mise a jour pour serveur mail effectue - $status" >> /var/log/scripts/awstats.log
#si ce n'est pas un sous-domaine
if [ "$nom" == "homeonline" ]; then
/usr/lib/cgi-bin/awstats.pl -config=$nom.ath.cx -update >/dev/null
status=$?
echo "[ $today ] Mise a jour du domaine $nom.ath.cx effectue - $status" >>
/var/log/scripts/awstats.log
else
#Upadte $nom
/usr/lib/cgi-bin/awstats.pl -config=$nom.$sousdomaine -update >/dev/null
#Log It
status=$?
echo "[ $today ] Mise a jour du domaine $nom effectue - $status" >> /var/log/scripts/awstats.log
fi
done
37/44
Annexe 9
Script pour l’ajout d’un compte utilisateur sur la machine (accès FTP)
#!/bin/bash
#
# $1 : login (nom sous domaine)
# $2 : nom du sous domaine
# $3 : hash mdp (crypt)
#
#if [ "$n" != "2" ]; then
#echo "ERREUR: Nombre d'argument inccorrect : $n" >> /var/log/scripts/error.log
#exit
#fi
#variable
#sous_domaine=homeonline.ath.cx
test_home_user=`cat /etc/passwd | grep $1 | cut -f6 -d:`
#new user doent exist
if [ "$test_home_user" == "" ]; then
echo "AJOUT USER $1 - home : /var/ftp/$1 - domain : $2" >> /var/log/scripts/info.log
fi
#test user exist
if [ "$test_home_user" == "/var/ftp/$1" ]; then
echo "ERREUR: Utilisateur $1 deja existant" >> /var/log/scripts/error.log
exit
fi
#Ajout Utilisateur
test=`useradd -m --home /var/ftp/$1 --password "$3" --gid chrvsftp --shell /bin/false $1`
#test vhost doesnt exist
if [ -f /etc/apache2/sites-enabled/$2 ]; then
echo "ERREUR: Virtual host deja existant" >> /var/log/scripts/error.log
exit
fi
#Ajout sous-domaine
touch /etc/apache2/sites-enabled/$2
echo "<VirtualHost 192.168.0.3>"
echo "
<Directory /var/ftp/$1>"
> /etc/apache2/sites-enabled/$2
>> /etc/apache2/sites-enabled/$2
echo " Allowoverride all"
>> /etc/apache2/sites-enabled/$2
echo " </Directory>"
>> /etc/apache2/sites-enabled/$2
echo "ServerName $2" >> /etc/apache2/sites-enabled/$2
echo "DocumentRoot /var/ftp/$1"
>> /etc/apache2/sites-enabled/$2
echo "CustomLog /var/log/apache2/$2-access.log common"
>> /etc/apache2/sites-enabled/$2
echo "CustomLog /var/log/apache2/access.log combined" >> /etc/apache2/sites-enabled/$2
echo "ErrorLog /var/log/apache2/$2-error.log"
echo "</VirtualHost>"
>> /etc/apache2/sites-enabled/$2
>> /etc/apache2/sites-enabled/$2
38/44
#Partie awstats
#test vhost doesnt exist
if [ -f /etc/awstats/awstats.$2.$sous_domaine.conf ]; then
echo "ERREUR: Fichier configuration awstats deja existant" >> /var/log/scripts/error.log
exit
fi
#Creation
touch /etc/awstats/awstats.$2.conf
echo "LogFile="/var/log/apache2/$2-access.log""
> /etc/awstats/awstats.$2.conf
echo "LogType=W" >> /etc/awstats/awstats.$2.conf
echo "LogFormat=4" >> /etc/awstats/awstats.$2.conf
echo "DirIcons="/awstats-icon"" >> /etc/awstats/awstats.$2.conf
echo "SiteDomain="$2""
>> /etc/awstats/awstats.$2.conf
Script pour la suppression de ce compte
#!/bin/bash
#
# $1 : nom (login)
# $2 : nom sous domaine
#variable
#sous_domaine=homeonline.ath.cx
#home_user=`cat /etc/passwd | grep $1 |cat -d: -f6`
#Supprime user meme s'il ets logue et supprime sa HD
userdel -f -r $1
#Erase vhost
rm -f /etc/apache2/sites-enabled/$2
#erase apache user log
rm -f /var/log/apache2/$2-*
#erase awstats profil
rm -f /etc/awstats/awstats.$2.conf
echo "INFO: sous domaine $2 supprime" >> /var/log/scripts/info.log
echo "INFO: Utilisateur $1 supprime" >> /var/log/scripts/info.log
39/44
Script pour la modification du mot de passe
#!/bin/bash
#
# Modification mot de passe dans fichier shadow
#
# $1 : login utilisateur
# $2 : nouveau mot de passe deja crypte
#
echo "[ $today ] login : $1 - MDP : $2 " >> /var/log/scripts/info.log
#date
today=`date +%d-%m-%Y`
oldpass=`cat /etc/shadow | grep ^$1 | cut -d: -f2`
if [ -e /etc/shadow.sed ]
then
echo "[ $today ] Cannot migrate user account $1" >> /var/log/scripts/error.log
exit 1
fi
if grep "^$1:" /etc/shadow > /dev/null
then
echo "[ $today ] Upgrating /etc/shadow..." >> /var/log/scripts/info.log
touch /etc/shadow.sed
chmod 600 /etc/shadow.sed
cat /etc/shadow | sed -e "s|$oldpass:|$2:|" >> /etc/shadow.sed
mv -f /etc/shadow.sed /etc/shadow
echo "[ $today ] Mot de passe pour $1 modifie" >> /var/log/scripts/info.log
fi
40/44
Annexe 10
Organigramme de notre application Web
Index
Inscription
Verif_inscription
Identification
FAQ
Verifier_identification
Webmail
Chg_pass_mail
Verif_chg_pass_mail
private
admin
admin
User
Déconnexion
Edit profil
41/44
Développement des parties « admin » et édition de profil
42/44
Annexe 11
Script pour la sauvegarde des données des utilisateurs et envoi par FTP sur site distant
#!/bin/bash
doc_name=`date +%d-%m-%Y`-backup.tar.gz
cd /var/ftp
tar -czf /tmp/$doc_name .
cd /tmp/
#ouvre une session FTP jusqu'à ce que soit marqué FIN_FTP
ftp -n 192.168.0.2 <<FIN_FTP
user fab cartman
binary
bell
put /tmp/$doc_name $doc_name
quit
FIN_FTP
# ferme la session FTP
rm /tmp/*.tar.gz
# supprime les archives .tgz dans le dossier /tmp/
43/44
6 Références
Luke Welling & Laura Thomson « PHP & MySQL » (CampusPress) 2003
Jean-Michel Lévy « UNIX & Linux, Utilisation et administration » (PEARSON) 2004
Anonyme « Sécurité maximale des systèmes et réseaux » (CampusPress) 2003
Ressources internet :
Debian :
http://www.debian.org/index.fr.html
Généralité Linux :
http://lea-linux.org/cached/index/Accueil.html
Serveur apache 2 :
http://www.cri.univ-rennes1.fr/documentations/cours_adminweb/supports/httpd.conf.html
http://www.debian-administration.org/articles/161
Serveur de messagerie :
http://workaround.org/articles/ispmail-sarge/
http://postfixwiki.org/index.php?title=Virtual_Users_and_Domains_with_CourierIMAP_and_MySQL#mysql_setup
Webmail:
http://maply.univ-lyon1.fr/~tdumont/Webmail/webmail.html
Serveur FTP:
http://worldserver3.oleane.com/bouynot/gabuzomeu/alex/doc/vsftpd/index.html
Statistique via « Awstats » :
http://ghaint.no-ip.org:8942/~k2/debian/awstats-debian.html
http://www.debian-administration.org/articles/85
SuPHP :
http://placelibre.ath.cx/keyes/index.php/2005/08/04/7-suphp-php4-php5-meme-serveur-executionscripts-php-droits-proprietaire
44/44