![]() |
Conception et déploiement d?une architecture réseau sécurisée : cas de SUPEMIR( Télécharger le fichier original )par Angeline Kone SUPEMIR - Ingénieur 2011 |
Tableau 1 : Caractéristiques des ordinateurs du réseau de SUPEMIR. 4. Les équipements d'interconnexionDans une architecture, le matériel d'interconnexion représente le coeur du réseau. S'il est mal configuré (équipement manageable), il peut avoir des effets néfastes sur le trafic réseau, allant à la détérioration de celui-ci. Le réseau de SUPEMIR comporte des commutateurs qui de par leur fonction permettent de réduire les domaines de collision, et un routeur auquel tout le a accès, ce qui laisse le droit à tout un chacun de le manipuler à sa guise. Le réseau se constitue des équipements d'interconnexion suivants :
Tableau 2 : Equipements d'interconnexion 5. Adressage, connexion externeComme dit précédemment, le réseau de SUPEMIR n'est pas segmenté en sous-réseau, ainsi l'adresse privée 192.168.1.0/24 est utilisée. Le réseau ne dispose vraiment pas d'un véritable plan d'adressage ; le routeur que l'opérateur offre intègre un serveur DHCP qui attribue systématiquement une adresse IP à tout ordinateur qui se connecte au réseau de l'école. Par ailleurs certains ordinateurs utilisent des adresses statiques. Vu qu'il n'y pas d'équipement d'interconnexion manageable, seul le protocole IGMP activé par défaut par l'opérateur est utilisé ; le routeur intègre la fonction NAT qui permet de masquer les adresses privées du réseau local qui accèdent à Internet. Le réseau local est connecté au réseau public via une liaison spécialisée d'un opérateur local (Maroc Telecom) qui fournit un modem/routeur ADSL à cet effet. II. CRITIQUE DE L'EXISTANT ET SPECIFICATION DES BESOINS1. Critique de l'existantUne analyse du réseau de SUPEMIR nous a permis de définir un nombre de contraintes pouvant réduire ses performances voir sa dégradation ; et de plus certains de ces contraintes peuvent être un obstacle à la réalisation de la mission de SUPEMIR : Ø Trafic web important Ø Volume accru du trafic généré par chaque utilisateur Ø Accès non restreint aux données de l'administration Ø Libre accès au routeur (paramètres de configuration) Ø Démotivation de certains professeurs Ø Conflit d'adressage IP 2. Spécification des besoinsSuite à la critique de l'existant, quelques besoins ont été relevés à fin de pallier aux contraintes précédemment mentionnées. a. Besoins fonctionnelsLes besoins fonctionnels expriment une action qui doit être menée sur l'infrastructure à définir en réponse à une demande. C'est le besoin exprimé par le client; ce besoin peut être exprimé de manière fonctionnelle mettant en évidence les fonctions de services (pour répondre à la question «A quoi ça sert ?») et les fonctions techniques (comment cela peut marcher ?). Dans ce cadre, nous allons : Ø Déployer un serveur DHCP dans le but de centraliser la gestion de l'adressage et d'éviter des conflits d'adresses IP, Ø Déployer un serveur DNS qui permettra la résolution de nom dans le réseau local, Ø Déployer un serveur Web pour une haute disponibilité en cas de rupture du lien avec le réseau public, Ø Déployer un serveur mandataire générique qui va relayer différentes requêtes et entretenir un cache des réponses. Il permettra aussi de sécurisé le réseau local, Ø Déployer un firewall pour protéger le réseau interne, Ø Déployer un serveur de mail pour la gestion de la messagerie local, Ø Déployer un serveur de fichiers à fin de mieux gérer les droits d'accès aux informations de l'école. b. Besoins non fonctionnelsLes besoins non fonctionnels représentent les exigences implicites auquel le système doit répondre. Ainsi à part les besoins fondamentaux, notre système doit répondre aux critères suivants : Ø La simplicité d'utilisation des services implémentés, Ø La centralisation de l'administration, Ø La sécurité des accès (local, mot de passe : longueur, caractères spéciaux, politique de réutilisation), Ø La performance du réseau (temps de réponse), Ø La disponibilité (heures de connexion), Ø La fiabilité (moyenne de temps de bon fonctionnement, Le temps moyen de Rétablissement), Ø La gestion des sauvegardes (fichiers, mails), Ø La documentation du réseau. III. LES SOLUTIONSLes solutions que nous avons proposées consistent à déployer les différents services, sécuriser les accès à ces services et implémenter une sécurité accrue à travers un filtrage de paquet au niveau du firewall et un proxy cache jouant le rôle d'un firewall à relayage de paquets. Nous proposons également une sécurité sur un plan global en faisant référence à la mise en place d'un local technique, la restriction des accès. L'enjeu principal d'une architecture réseau sécurisée, est de pouvoir est de pouvoir réglementer les accès aux ressources du réseau tant à partir du réseau local qu'à l'extérieur, tout en essayant au maximum de limiter les failles d'éventuelles attaques ou vols d'informations à fin d'accroître la sécurité du réseau local. En effet, face à des applications telle la messagerie qui permettent la mobilité donc les accès d'origine diverse, il est toujours important de définir une architecture fiable de sécurisation du réseau. L'implémentation d'une telle architecture aboutira à un gain en termes de performance et sécurité du réseau. CHAPITRE II : PHASE DE PLANIFICATION DU DEPLOIEMENTI. PLANIFICATION DU DEPLOIEMENTUne bonne mise en oeuvre des solutions requiert une bonne planification. Dans cette phase, nous allons présenter le matériel et les pré-requis nécessaires à la mise en place de la solution. Il est important de noter les différentes contraintes qui pourront être rencontrées : Ø Les services rendus à l'utilisateur doivent être interrompu le moins longtemps possible pendant les heures de travail Ø L'accès aux pages web ne doit pas être de piètre performance du fait de la mise en place de la DMZ. 1. Matériels utilisés
Tableau 3 : Matériels pour le déploiement. 2. Pré-requisDans ce document il est question de créer des serveurs particuliers, ce qui requiert dans un environnement unix la connaissance de certaines commandes. Nous les présentons ici qui permettra par la suite de s'en passer de longues explications et se limiter aux différentes commandes et modifications de fichier de configuration. Nous allons donc rappeler quelques commandes unix que nous avons utilisé : cd - changer de répertoire, vi - éditeur système, df - afficher l'espace disponible, more - afficher un fichier page à page, (la touche x permet de passer une page), grep - filtrer la sortie, chmod - changer les droits d'accès à un fichier, (chmod +x rendre un fichier exécutable), cp - copier de fichiers, find - rechercher de fichiers, man - afficher l'aide sur une commande, mkdir - créer un dossier, mv - déplacer un fichier, passwd - changer le mot de passe, ps - lister des process, pwd - afficher le chemin du dossier en cours, rm - détruire un fichier, adduser - useradd (suivant la distribution et l'installation) ajouter un utilisateur, userdel - supprimer un utilisateur, addgroup - groupadd - ajouter un group wget - télécharger un fichier, elle est souvent utilisée pour les installations manuelles, chgrp - changer un fichier de groupe, chown - changer le propriétaire d'un fichier, ln - créer un lien sur un fichier, ls - lister des fichiers, rmdir - détruit un dossier, tar - sauvegarde / compresse, mount - monte un système de fichier, ifconfig - Affiche les informations d'une interface, configure une interface, assigne une adresse, assigne un masque de sous-réseau, active et désactive une interface, route - ajoute un route dans la table de routage, killall - tue un processus mais au lieu d'indiquer le PID vous indiquerez le nom du processus, smbpasswd - /etc - contient la plupart des fichiers de configuration du système Linux, /dev - contient les fichiers correspondant au matériel, /proc - contient les fichiers de processus, avec pour les fichiers portant un numéro: leur ID, /var - contient la plupart des variables, /var/log - contient la plupart des fichiers de log générés par le système, init.d/ - contient les scripts de démarrage (/etc/init.d). 3. Architecture de mise en oeuvreFigure 3 : Architecture du réseau de SUPEMIR Dans cette nouvelle architecture, le réseau de l'école est scindé en deux parties : le réseau local et la DMZ. On voit également sur cette architecture la liaison avec le réseau public. Dans la nouvelle infrastructure, nous disposons de trois serveurs (srvsupemir2, srvsupemir2, srvsupemir2) et un firewall (PC/linux nommé srvfirewall) sur lesquels sont déployés les différents services. Le routeur de l'opérateur joue le rôle de passerelle entre le réseau de l'école et le réseau public. 4. Architecture de déploiementFigure 4 : Architecture de déploiement. A travers le logiciel Microsoft Visio, nous avons reproduit notre environnement de travail (figure ......). Cet environnement nous permettra d'aboutir à une bonne configuration de notre solution. II. LES DIFFERENTS SERVICES ET L'ADRESSAGE1. ServicesVu les contraintes de matériels, nous avons cumulé plusieurs services sur un des serveurs, il s'agit du serveur nommé srvsupemir3. Nous avons opté pour une plate-forme open source, ainsi tous les logiciels que nous avons utilisés pour déployer les services sont des logiciels open-source. Les services sont repartis come suit sur les serveurs : srvsupemir2 : il est installé sur cet ordinateur le serveur mandataire Squid http qui est une solution open-souce, il est couplé à SquidGuard qui est également une solution open-source qui permet le filtrage en servant des URI (uniform ressouce Identifier). Nous avons aussi installé le logiciel webmin pour une administration en mode graphique. srvsupemir3 : il héberge notre serveur web. Nous y avons utilisé xampp qui est un ensemble complet de services pour faire tourner un serveur web. srvsupemir4 : sur ce poste est installé les services DHCP, DNS, messagerie, partage de fichier. srvfirewall : ici nous n'avons pas installer un service particulier, nous avons utilisé iptables qui est un firewall natif aux systèmes unix. 2. AdressageLe plan d'adressage IP que nous avons utilisé est le suivant :
Nous avons utilisé un adressage statique pour ces serveurs à fin de faciliter l'accès aux ressources qu'elles hébergent. CHAPITRE III : PHASE DE MISE EN OEUVREI. SCENARIOS D'INSTALLATION ET DE CONFIGURATION1. Installation et configuration des serveursL'installation et la configuration s'opèrent via le shell en ligne de commande avec le compte root (saisir la commande sudo -s et entrer le mot de passe root) qui est le compte administrateur sur linux, à fin d'avoir les pleins pouvoirs de modification des fichiers de configuration. a. Serveur DHCPNous avons configuré l'adresse IP du serveur dans le fichier /etc/network/interfaces comme suit : Configuration de l'interface réseau # interface r(c)seau de bouclage auto lo iface lo inet loopback address 127.0.0.1 netmask 255.0.0.0 # carte r(c)seau en ip statique iface eth0 inet static address 192.168.3.254 broadcast 192.168.3.255 netmask 255.255.255.0 gateway 192.168.3.1 auto eth0 Installation Nous avons installé le serveur DHCP depuis la logithèque d'Ubuntu ou en tapant la commande apt-get install dhcp3-server. Cette installation place dans le répertoire /etc/dhcp3/ le fichier dhcpd.conf qui est le principal fichier de configuration. Configuration En plus de la fonction principale qui est celle de l'attribution d'adresse IP, nous avons configuré une synchronisation avec le serveur DNS c'est-à-dire que le serveur DHCP enregistre l'hôte à qui il attribue une adresse les fichiers de zone (zone direct et zone inversée) du serveur DNS. Ainsi voici le contenu de notre fichier de configuration : # configuration du DDNS server-identifier 192.168.3.254; ddns-updates on; ddns-update-style interim; ddns-domainname "labs.supemir.ma."; ddns-rev-domainname "in-addr.arpa."; update-static-leases on; # Ignore Windows FQDN updates ignore client-updates;
# Include the key so that DHCP can authenticate itself to BIND9 key dhcp_updater{ algorithm hmac-md5; secret "5STvKYJR/wkFEPCoG1BTI8dDAQ2mzYJSTB82jBqHVs3uBYsF3wW1NsMQKq23xTTZMFtXJRY93tnynjZ9Pfa1ZQ=="; }; # This is the communication zone zone labs.supemir.ma. { primary 127.0.0.1; key dhcp_updater; } # dur(c)e par d(c)faut et dur(c)e max des baux d'adrese default-lease-time 600; max-lease-time 7200; # d(c)claration du serveur dns et du nom de domaine option domain-name-servers 192.168.3.254; option domain-name "labs.supemir.ma"; # notre serveur dhcp fait autorit(c) sur le r(c)seau authoritative; # configuration du serveur dhcp subnet 192.168.3.0 netmask 255.255.255.0 { option broadcast-address 192.168.3.255; option subnet-mask 255.255.255.0; range 192.168.3.100 192.168.3.200; option routers 192.168.3.1; # zone DNS mette jour zone 3.168.192.in-addr.arpa. { primary 192.168.3.254; key dhcp_updater; } zone labs.supemir.ma. { primary 192.168.3.254; key dhcp_updater; } } # attribution d'adresses statiques aux pc de l'administration host shaita { hardware ethernet 00:0B:DB:7C:B8:E7; fixed-address 192.168.3.211; option host-name "shaita.labs.supemir.ma"; } host AZERTY { hardware ethernet 00:11:43:CB:F6:E7; fixed-address 192.168.3.212; option host-name "AZERTY.labs.supemir.ma"; } host BUREAU { hardware ethernet 00:08:74:FA:A3:7D; fixed-address 192.168.3.213; option host-name "bureau.labs.supemir.ma"; } host UNICORNI-D9DEED { hardware ethernet 00:0E:A6:C7:97:14; fixed-address 192.168.3.214; option host-name "UNICORNI-D9DEED.labs.supemir.ma"; } host KHALID { hardware ethernet 00:0E:A6:9A:0F:A1; fixed-address 192.168.3.215; option host-name "KHALID.labs.supemir.ma"; } # fin de fichier La clé dhcp_updater est une clé avec laquelle le serveur dhcp s'authentifie auprès du serveur bind. Elle est générée a vec la commande suivante : dnssec-keygen -a HMAC-MD5 -b 512 USER dhcp_updater Après la configuration, il faut redémarrer le service à fin de prendre en charge les paramètres configurés : service dhcp3-server restart. Utilisation : Test du serveur Nous avons édité le fichier /etc/dhcpd3/dhcpd.leases pour voir les baux d'adresses que le serveur a octroyé. Nous avons également connecté le serveur sur un switch et d'autres postes clients et renouveler le bail comme l'indique le schéma ci -après. Au niveau des postes nous avons fait la manipulation suivante pour obtenir l'adresse IP : Client Windows : ipconfig /release : pour libèrer les connexions. Ipconfig /renew : pour rétablir les connexions. Figure 5 : Renouvèlement de bail IP. Client linux : dhclient : interroge le serveur DHCP pour configurer l'interface réseau et les services associés en conséquence. b. Serveur DNSInstallation Ubuntu est livré par défaut avec BIND le serveur DNS le plus utilisé sur Internet. C'est ce serveur BIND, que nous allons utiliser comme serveur DNS. Nous avons choisi la dernière version de bind qui est BIND9, disponible dans le dépôt principal. Ce choix ce justifie par le fait que cette version résout certains bugs des précédentes versions, ajoute la prise en charge de DNSSEC qui est le protocole standardisé par l'IETF permettant de résoudre certains problèmes de sécurité liés au protocole DNS et bien d'autres points importants tel IPV6. Pour l'installer, il suffit de saisir la commande apt-get install bind9. Nous avons opté pour le nom de domaine labs .supemir.ma. Configuration La configuration de ce serveur nécessite la modification de plusieurs fichiers et la création des fichiers de zone. Ce sont : /etc/bind/named.conf.local /etc/bind/named.conf.options /etc/bind/db.labs.supemir.ma (c'est le fichier de zone direct que nous avons créé) /etc/bind/db.192.168.3 (c'est le fichier de zone inversée que nous avons créé) /etc/resolv.conf /etc/hosts Nous avons édité le fichier named.conf.local (gedit /etc/bind/named.conf.local) et l'avons modifié comme suit : // Do any local configuration here // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; # cl(c) que le serveur dhcp utilisera lors de la synchronisation avec le serveur dns key dhcp_updater{ algorithm hmac-md5; secret "5STvKYJR/wkFEPCoG1BTI8dDAQ2mzYJSTB82jBqHVs3uBYsF3wW1NsMQKq23xTTZMFtXJRY93tnynjZ9Pfa1ZQ=="; }; zone "labs.supemir.ma" {
type master; file "/etc/bind/db.labs.supemir.ma"; allow-update { key dhcp_updater; }; notify yes; }; // configuration de la zone invers(c)e zone "3.168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168.3"; allow-update { key dhcp_updater; }; notify yes; }; // fin de fichier
Le fichier suivant nécessitant une modification est named.conf.options (gedit /etc/bind/named.conf.options), son contenu est modifié comme suit : options { directory "/var/cache/bind"; // If there is a firewall between you and nameservers you want // to talk to, you may need to fix the firewall to allow multiple // ports to talk. See http://www.kb.cert.org/vuls/id/800113 // If your ISP provided one or more IP addresses for stable // nameservers, you probably want to use them as forwarders. // autres dns contacter si la resolution local est sans succ·s forwarders { 192.168.1.1; 212.217.0.1; 212.217.0.12; }; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; }; // fin de fichier Les fichiers des zones sont utilisés pour lister les différentes ressources d'un domaine, comme les serveurs de mails (MX), les serveurs de noms (NS), ou les enregistrements machine/IP (A) et redirections (CNAME). Voici une petite liste des principaux types d'enregistrements dont nous avons fait usage dans les fichiers de zone : NS : Déclare un serveur DNS pour la zone. MX : Déclare un serveur mail pour la zone. A : Réalise le lien entre le nom d'une machine et son adresse IP. PTR : Réalise le lien entre l'IP d'une machine et son nom. Utilisé pour le fichier de zone inverse. CNAME : C'est une espèce d'alias, permettant de définir un nom par rapport à un autre nom. Nous avons créé les fichiers de la manière suivante : gedit /etc/bind/db.labs.supemir.ma, ci dessous son contenu : $ORIGIN . $TTL 604800 ; 1 week labs.supemir.ma IN SOA srvsupemir4.labs.supemir.ma. root.labs.supemir.ma. ( 16 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) NS srvsupemir4.labs.supemir.ma. A 192.168.3.254 AAAA ::1 $ORIGIN labs.supemir.ma. srvsupemir4 A 192.168.3.254 dhcp IN CNAME srvsupemir4 dns IN CNAME srvsupemir4 mail IN CNAME srvsupemir4
gedit /etc/bind/db.192.168.3, ci dessous son contenu : $ORIGIN . $TTL 604800 ; 1 week 3.168.192.in-addr.arpa IN SOA srvsupemir4.labs.supemir.ma. root.labs.supemir.ma. ( 11 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) NS srvsupemir4.labs.supemir.ma. MX 10 srvsupemir4.labs.supemir.ma. 254 PTR srvsupemir4.labs.supemir.ma. Contenu du fichier /etc/resolv.conf (gedit /etc/resovl.conf) domain labs.supemir.ma search labs.supemir.ma order local,bind nameserver 192.168.1.1 nameserver 192.168.3.254 nameserver 212.217.0.1 # fin de fichier Contenu du fichier /etc/hosts (gedit /etc/hosts), dans fichier nous avons juste ajouté la première ligne 192.168.3.254 srvsupemir4.labs.supemir.ma srvsupemir4 # Added by NetworkManager 127.0.0.1 localhost.localdomain localhost ::1 srvsupemir4 localhost6.localdomain6 localhost6 127.0.1.1 srvsupemir4 # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts # fin de fichier Lorsqu'une application est installée sur le système, apparmor la verouille en limitant strictement ses accès aux seules ressources auxquelles elle a droit sans empêcher son fonctionnement, ainsi il lui ait attribué un profil standard de sécurité qui restreint ses capacités. Les profils standards sont stockés dans /etc/apparmor.d mais les modifications locales de ces profils sont stockés dans /etc/apparmor/local et les profils standards incluent les profils locaux. La synchronisation entre le serveur DHCP et le serveur DNS implique une modification de profil, c'est ainsi que nous avons ajouté « <include/usr.sbin.named>» dans le fichier /etc/apparmor.d/usr.sbin.named avant l'accolade fermante ; puis nous avons crée le fichier /etc/apparmor.d/local/usr.sbin.named dont le contenu est : /etc/bind/* rw, /etc/bind rw, A la suite de ce qui précède, il faut accorder les droits nécessaire à l'utilisateur bind qui est crée lors de l'installation de bind. Lorsqu'il est crée, il est ajouté au groupe root et est propriétaire du répertoire /etc/bind, par contre le groupe root n'est pas le droit d'écriture dans ce répertoire par défaut. Nous avons accordé le droit d'écriture au groupe avec le commande « chmod 774 /etc/bind ». Test du serveur Plusieurs outils sont disponibles pour réaliser des tests de la configuration du serveur et de ses zones tels que named-checkconf, named-checkzone, nslookup et dig, nous avons utilisé nslookup à cet effet, voici un aperçu du test : Figure 6 : Résultat du test de résolution de nom par le serveur DNS. c. Serveur de fichiersLe logiciel Samba est un outil permettant de partager des dossiers et des imprimantes à travers un réseau local. Il permet de partager et d'accéder aux ressources d'autres ordinateurs fonctionnant avec des systèmes d'exploitation Microsoft® Windows et Apple Mac OS X, ainsi que des systèmes GNU/Linux, BSD et Solaris dans lesquels une implémentation de Samba est installée. Pour partager de manière simple des ressources entre plusieurs ordinateurs, l'utilisation de Samba est conseillée. Vu les fonctionnalités qu'offrent ce logiciel, nous avons en usé de sa possibilité d'émuler un domaine Windows pour le configurer en contrôleur de domaine principal (PDC). Le contrôleur de domaine principal est un serveur chargé du contrôle de l'authentification des requêtes de connexion et d'accès aux ressources dans un domaine windows qui est quant à lui un groupe d'ordinateurs (techniquement appelé forêt) où l'accès à une variété de ressources hébergée sur un ordinateur est contrôlé par la PDC. Il existe divers outils pour une configuration graphique de samba mais nous avons souhaité utiliser le shell car celui-ci offre la possibilité de configurer tous les paramètres de samba. Installation Afin d'installer les paquets minimums nécessaires pour la suite des opérations, nous avons lancé les commandes suivantes : apt-get update apt-get update --fix-missing apt-get install ssh (pour l'accès au serveur à distance) apt-get install samba Création des groupes et des utilisateurs Afin que tout le monde ne puisse pas accéder à tous les fichiers, il a fallu restreindre l'accès à certains utilisateurs et à certains groupes et pour cela nous les avons créé au préalable. Nous avons crée trois groupes : etudiants, profs et cadre. Chacun de ces groupes contient des utilisateurs et nous avons créé juste ceux donc nous avions besoins. Figure 7 : Création des groupes et des utilisateurs. Dans notre cas, nous avons utilisé plusieurs options. L'option -m qui permet de créer directement le répertoire home du nouvel utilisateur. Ce répertoire se situe dans /home/. L'option -g permet à l'utilisateur de rejoindre le groupe spécifié en paramètre. L'option -R de la commande chmod permet d'appliquer le mode d'accès préciser à tous les fichiers dans les sous répertoires de manière récursive. Après cette manipulation il faut activer ces comptes utilisateurs dans Système> Administration> Utilisateurs et groupes, en saisissant le mot de passe de chaque utilisateur à la demande. Pour que les utilisateurs aient accès aux ressources de samba, il a fallu que nous les ajoutions à samba grâce à la commande smbpasswd de la manière ci-dessous : Figure 8 : Ajout des utilisateurs au serveur Samba. L'option -a permet juste de spécifier le nom de l'utilisateur. Il faut faire pareil pour le compte root à fin de lui permettre d'intégrer des postes clients au domaine. Ajout des machines sous samba Pour que chaque machine puisse se connecter au domaine au démarrage, il faut qu'il ait un compte au niveau du contrôleur de domaine samba pour cela nous avons créé un groupe ordinateurs qui contiendra toutes les machines du domaine. Par exemple pour joindre le poste portant le nom supemirpc3, il faut un compte machines portant ce nom sur le PDC. Création du groupe ordinateus Ajoute de l'utilisateur supemirpc3$ Ajout de son mot de passe à /etc/samba/smbpasswd : Ne pas oublier le $ à la fin du nom, tout se passe comme ci-dessous : Figure 9 : Ajout du groupe des ordinateurs et d'un compte machine à Samba. L'option -m permet de préciser que ce compte est un compte machine et de ce fait il n'a pas de mot de passe. Création des dossiers de partage Vu que le répertoire public est accessible par tout le monde, nous avons donné le droit de lecture, écriture er exécution des fichiers et répertoires à tout le mode : chmod 777 /home/public. Figure 10 : Création des répertoires de partage. Le répertoire profiles permet de stocker les profiles des utilisateurs qui se connectent au domaine à fin de le permettre de garder leur environnement de travail quelque soit le poste sur lequel ils se connecteront, le répertoire netlogon quant à lui permet de stocker les scripts de connexion. Configuration de smb.conf Le fichier smb.conf est le fichier de configuration de samba contenu dans le répertoire /etc/samba/. Ce fichier décrit les ressources que l'on désire partager, ainsi que les permissions/restrictions qui leur sont associées. gedit /etc/samba/smb.conf pour éditer le fichier de configuration et le modifier comme suit : # smb.conf par A.K #--------CONFIGURATION GLOBALE--------------------------- [global] workgroup = labs.supemir.ma # nom sous lequel appara®tre le serveur dans le voisinage r(c)seau netbios name = srvsupemir4 # ce qui appara®tra dans la rubrique d(c)tail du voisinage r(c)seau, %v fait appara®tre le n° de version de samba server string = %h Serveur Samba %v # les mots de passes transitent chiffr(c)s encrypt passwords = Yes # lieux de stockage du journal des (c)v(c)nements log file = /var/log/samba/log.%m # taille max du journal max log size = 50 # param·tre qui permet d'augmenter les performances r(c)seau socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 # pas de proxy dns dns proxy = No username map = /etc/samba/smbusers # oblige les utilisateurs avoir un compte sur le serveur pour se connecter security = user # crypter le mot de passe encrypt passwords = true # base de donn(c)es des utilisateurs, groupes et mots de passe passdb backend = tdbsam:/var/lib/samba/pdcpass.tdb smb passwd file = /etc/samba/smbpasswd # synchronisation des mots de passe samba avec les mots de passe linux unix password sync = yes pam password change = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . #pour pouvoir synchroniser l'horloge des client sur celle du serveur time server = yes # autorise la connection des utilisateurs sur le domaine domain logons = yes # ce serveur est le controleur du domaine domain master = yes # dans le cas de la pr(c)sence de plusieurs contr'leurs de domaine, c'est le serveur qui est le favori preferred master = yes # il fait autorit(c) sur le r(c)seau local local master = yes # permet de gagner l'(c)lection contre les autres machines windows os level = 255 #sp(c)cifie que root et les user du groupe cadre peuvent joindre le domaine sur les clients #domain admin group = @root,@cadre # repertoire de connexion logon home = \\%N\%H logon path = \\%N\profile\%U logon script = %U.bat # administrateur du domain admin users = root manager #--------CONFIGURATION DU PARTAGE DES FICHIERS------------- [netlogon] comment = R(c)pertoire des scripts de connextion path = /home/netlogon/ browseable = no writeable = no write list = root, manager # [profile] comment = R(c)pertoire des profiles de connextion path = /home/profile browseable = no writeable = yes create mask = 0700 directory mask = 0700 # [public] comment = R(c)pertoire Public public = yes path = /home/public # il est accessible en (c)criture writeable = yes valid users = @profs,@cadre,@etudiants write list = @profs,@cadre,@etudiants read list = @profs,@cadre,@etudiants # les fichiers cr(c)(c)s sont en lecture seule, sauf pour le propri(c)taire create mode = 0755 # [cours] comment = Repertoire des cours acc(c)ssibles par les profs path = /home/cours browsable=no #valid users = @profs valid users = @profs write list = @profs read list = @profs # [direction] comment = Repertoire des cours acc(c)ssibles par les profs path = /home/direction browsable=no valid users = @cadre write list = @cadre read list = @cadre # [amine] comment = Repertoire amine path = /home/amine browsable=no valid users = amine # [achraf] comment = Repertoire achraf path = /home/achraf browsable=no valid users = achraf # [mounir] comment = Repertoire mounir path = /home/mounir browsable=no valid users = mounir # [khalid] comment = Repertoire khalid path = /home/khalid browsable=no valid users = khalid # [niveau1] comment = Repertoire des cours niveau1 path = /home/niveau1 #browseable = no valid users = @profs,niveau1 write list = @profs read list = niveau1 # [niveau2] comment = Repertoire des cours niveau2 path = /home/niveau2 #browseable = no valid users = @profs,niveau2 write list = @profs read list = niveau2 # [niveau3] comment = Repertoire des cours niveau3 path = /home/niveau3 #browseable = no valid users = @profs,niveau3 write list = @profs read list = niveau3 # [niveau4] comment = Repertoire des cours niveau4 path = /home/niveau4 #browseable = no valid users = @profs,niveau4 write list = @profs read list = niveau4 # [niveau5] comment = Repertoire des cours niveau5 path = /home/niveau5 #browseable = no valid users = @profs,niveau5 write list = @profs read list = niveau5 # # partarge supervision [manager] comment = Repertoire de supervision browseable = no path = /home/ valid users = manager write list = manager read list = manager # fin de fichier Scripts de connexion Etant donnée que les utilisateurs ne son pas nombreux, nous avons créé un script pour chacun d'eux, ainsi ne seront montés à la connexion au domaine uniquement les partages auxquels l'utilisateur a droit. gedit /home/netlogon/achraf.bat REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\direction NET USE S: \\srvsupemir4\public NET USE X: \\srvsupemir4\achraf REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES gedit /home/netlogon/amine.bat REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\direction NET USE S: \\srvsupemir4\public NET USE X: \\srvsupemir4\amine REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES gedit /home/netlogon/mounir.bat REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\direction NET USE S: \\srvsupemir4\public NET USE X: \\srvsupemir4\mounir REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES gedit /home/netlogon/khalid.bat REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\direction NET USE S: \\srvsupemir4\public NET USE X: \\srvsupemir4\khalid REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES gedit /home/netlogon/prof1.bat REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\niveau1 NET USE S: \\srvsupemir4\niveau2 NET USE X: \\srvsupemir4\niveau3 NET USE Y: \\srvsupemir4\niveau4 NET USE W: \\srvsupemir4\niveau5 NET USE Y: \\srvsupemir4\niveau4 NET USE W: \\srvsupemir4\public REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES gedit /home/netlogon/niveau1 REM montage du répertoire de l'utilisateur NET USE R: \\srvsupemir4\niveau1 NET USE S: \\srvsupemir4\public REM réglage de l'heure du client par arpport à celle du serveur NET TIME \\srvsupemir4\ /SET /YES Ceci a été fait pour les 4 autres niveaux. Test de la configuration Avant le démarrage du serveur, nous avons procédé à une examination de la syntaxe du fichier de configuration grâce à la commande testparm. Pour cela nous avons du installé le package samba-common-bin (apt-get install samba-common-bin). Cette commande vérifie la syntaxe du fichier de configuration par contre elle ne garantit pas le bon fonctionnement du serveur. Elle inspecte toutes les sections du fichier de configuration, il n'y pas d'erreur dans la syntaxe, nous avons un aperçu comme ci-dessous. Figure 11 : Résultat du test de la syntaxe du fichier de configuration. Connexion au serveur Le serveur configuré, il est nécessaire de le relancer pour que les modifications soient prises en compte : service smbd stop / service smbd start. Le service smbd est celui qui gère le partage de fichiers et d'imprimantes. Pour vérifier que les répertoires ont été correctement partagés nous avons utilisé la commande smbclient de la manière suivante : smbclient -L //127.0.0.1/ (le 127.0.0.1 car nous sommes toujours sur le serveur, sur un machine linux à distance on doit préciser l'adresse IP du serveur), puis saisir le mot de passe root ; nous obtenons cet aperçu : Figure 12 : Aperçu des répertoires partagés sur le serveur. L'option -L permet de spécifier l'hôte en renseignant son adresse IP. La commande smbclient permet aussi à un utilisateur d'accéder au partage sur linux. Figure 13 : Utilisation du serveur. L'option -U permet de préciser l'utilisateur qui veut se connecter au partage. Le console nous demande le mot de passe de l'utilisateur et autorise l'accès si ce dernier est correct et si l'utilisateur possède les droits pour accéder à ce partage. Connexion au partage : smbclient Affiche des fichiers présents dans le répertoire de partage : ls Quitter le partage : exit Intégration d'un client windows dans samba L'intégration au domaine samba permet à l'utilisateur de monter directement ses répertoires de partage sur son poste de travail et là il verra des lecteurs réseaux identifiants les partages auxquels il a accès au niveau du serveur. Là c'est plus sécurisant parce que l'utilisateur ne voit que les partages auxquels il a droit. La procédure est la suivante : Démarrer > clic droit sur poste de travail > Propriétés > Nom de l ordinateur > Modifier Figure 14 : Intégration d'un client windows au domaine. Il est nécessaire de s'authentifier avec un compte Administrateur de domaine sur notre poste client. Notre ordinateur est désormais intégré au domaine. A l'ouverture de session, le client doit choisir de se connecter au domaine afin de monter les répertoires de partage auxquels il a accès dans l'explorateur. Voici l'aperçu de ces lecteurs dans l'explorateur. Figure 15 : Lecteurs réseau associées au partage de l'utilisateur achraf. d. Serveur de mailsLa plupart des serveurs de messagerie possèdent ces deux fonctions (envoi/réception), mais elles sont indépendantes et peuvent être dissociées physiquement en utilisant plusieurs serveurs. L'agent de transfert de courriel communément appelé MTA (Mail Transfert Agent), en anglais est un programme qui reçoit et envoie les courriels depuis votre serveur, et par conséquent, en est la pierre angulaire. On distingue plusieurs sortes de MTA dont les plus connus sont : Postfix, Exim4, SendMail, Google Mail, Fetchmail, Mailman Xmail et Zimbra. Pour notre projet, nous avons choisi d'utiliser Postfix. Pour permettre le téléchargement des courriels depuis les postes clients, il est nécessaire de configurer un serveur IMAP ou POP3. Il en existe de nombreux. On a par exemple Dovecot, Cyrus et Courier. Tous les serveurs cités dessus peuvent être installés depuis le dépôt principal, et donc bénéficier des mises à jour de sécurité lorsque cela est nécessaire. Mais celui pour lequel nous avons opté pour ce projet est le serveur Dovecot. Postfix est un serveur de messagerie électronique et un logiciel libre développé par Wietse Venema et plusieurs contributeurs. Il se charge de la livraison de courriers électroniques ( courriels) et a été conçu comme une alternative plus rapide, plus facile à administrer et plus sécurisée que l'historique Sendmail. Postfix permet de gérer presque tous les cas d'une utilisation professionnelle, il permet d'éviter bon nombre de spams sans même devoir scanner les contenus de message. La mise en place de ce serveur passe par plusieurs étapes : Vérification du nom du serveur Cette opération se fait à l'ai de la commande hostname de la manière suivante :
Installation des paquets requis Une mise à jour de la liste des fichiers disponibles dans les dépôts APT présents dans le fichier de configuration /etc/apt/sources.list et une mise à jour de tous les paquets installés sur le système vers les dernières versions sont nécessaires pour la suite. Pour cela nous avons utilisé les commandes ci-après : apt-get update apt-get upgrade Les paquets postfix, mysql, dovecot et bien d'autres sont installés comme suit : apt-get install postfix postfix-mysql postfix-doc mysql-client mysql-server dovecot-common dovecot-imapd dovecot-pop3d postfix libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl telnet mailutils Lors de cette installation, nous avons configuré dans différentes boîtes de dialogues les paramètres suivants : Ø Le mot de passe root pour MySQL Ø Le type de configuration du serveur mail : 'Site internet' Ø Le nom de domaine pleinement qualifié du système de messagerie : 'labs.supemir.ma'. Configuration de Mysql pour les domaines et utilisateurs virtuels Pour ce faire nous nous sommes connectés à la base de données au travers de cette commande : Figure 17 : Connexion à la base de données. Nous avons créé la base de données pour notre serveur de messagerie de la manière suivante : CREATE DATABASE mail; USE mail; Après sa création nous nous sommes connectés à elle pour créer les différentes tables qu'elle doit contenir. Nous avons créé un compte administrateur « mail_admin » avec mot de passe pour gérer la base de données des mails, nous lui avons donné les droits adéquats : Figure 18 : Création d'un utilisateur avec d'c droits. Nous avons crée les tables : Ø domains qui contient les domaines virtuels Ø forwardings qui gère l'acheminement des mails Ø users qui enregistre les adresses email des utilisateurs Ø transport Après ces manipulations, il faut quitter l'invite de commande avec la commande « quit » pour pourvoir continué la configuration. Il faut vérifier dans le fichier /etc/mysql/my.cnf que Mysql est configuré pour utiliser localhost c'est-à-dire l'adresse IP 127.0.0.1 ; ceci est confirmé par la présence de la ligne « bind-address = 127.0.0.1 » dans le dit fichier. Cette ligne permet à postfix de communiquer avec le serveur de base de données en local. Il faut redémarrer mysql pour la prise en compte des modifications : service mysql restart . Configuration de postfix pour utiliser Mysql Nous avons créé des fichiers de configurations suivants : Ø /etc/postfix/mysql-virtual_domains.cf pour la gestion du domaine virtuel postfix, ci-dessous son contenu : user = mail_admin password = password_admin dbname = mail query = SELECT domain AS virtual FROM domains WHERE domain='%s' hosts = 127.0.0.1 Ø /etc/postfix/mysql-virtual_forwardings.cf pour le transfert postfix, ci-dessous son contenu : user = mail_admin password = password_admin dbname = mail query = SELECT destination FROM forwardings WHERE source='%s' hosts = 127.0.0.1 Ø /etc/postfix/mysql-virtual_mailboxes.cf pour les boîtes aux lettres virtuelles, ci-dessous son contenu : user = mail_admin password = password_admin dbname = mail query = SELECT CONCAT(SUBSTRING_INDEX(email,'@',-1),'/',SUBSTRING_INDEX(email,'@',1),'/') FROM users WHERE email='%s' hosts = 127.0.0.1 Ø /etc/postfix/mysql-virtual_email2email.cf, ci-dessous son contenu : user = mail_admin password = password_admin dbname = mail query = SELECT email FROM users WHERE email='%s' hosts = 127.0.0.1 La valeur de password_admin dans les fichiers ci-dessus est le mot de passe de l'administrateur `mail_admin' que nous avons précédemment créé. Nous avons attribué des autorisations appropriées au groupe utilisant ces fichiers de configurations ainsi : chmod o= /etc/postfix/mysql-virtual_*.cf chgrp postfix /etc/postfix/mysql-virtual_*.cf Nous avons aussi créé un utilisateur et un groupe pour le traitement des courriers électroniques, ainsi toutes les boîtes aux lettres des utilisateurs sont stockées dans ce répertoire : Groupadd -g 5000 vmail Useradd -g vmail -u 5000 vmail -d /home/vmail -m Pour compléter la suite de la configuration, nous avons exécuté la suite des commandes ci-dessous : Figure 19 : Suite configuration postfix. Création d'un certificat SSL pour postfix Nous avons créé ce certificat avec la commande suivante : Figure 20 : Création du certificat SSL. Le certificat créé, nous lui avons attribué les droits nécessaires pour l'utilisation de la clé par cette commande : chmod o = /etc/postfix/smtpd.key Configuration de saslauthd pour utiliser Mysql Le saslauthd est le processus démon qui prend en charge l'authentification en texte plein des requêtes des utilisateurs. Il faut créer un répertoire pour saslauthd avec la commande : mkdir -p /var/spool/postfix/var/run/saslauthd Ensuite, il faut faire une sauvegarde du fichier /etc/default/saslauthd avec la commande : cp -a /etc/default/saslauthd/etc/default/saslauthd.bak Nous avons remplacé son contenu comme suit : START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="pam" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r" Il faut aussi crée le fichier /etc/pam.d/smtp avec ce contenu : auth required pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1 account sufficient pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1 Le dernier fichier à créer est /etc/postfix/sasl/smtp.conf avec ce contenu : pwcheck_method: saslauthd mech_list: plain login allow_plaintext: true auxprop_plugin: mysql sql_hostnames: 127.0.0.1 sql_user: mail_admin sql_passwd: mail_admin_password sql_database: mail sql_select: select password from users where email = '%u' Nous avons donné des permissions et droits adéquats pour l'utilisation de ces fichiers de configuration de la manière suivante : chmod o= /etc/pam.d/smtp chmod o= /etc/postfix/sasl/smtpd.conf Pour que postfix puisse utiliser les services du deomon saslauthd, il faut ajouter l'utilisateur postfix au groupe sasl, puis redémarrer les services pour la prise en compte des configurations faites : adduser postfix sasl service postfix restart service saslauthd restart Configuration de Dovecat Nous avons choisi ce serveur IMAP/POP3 pour sa aisance à configurer et son efficacité. Pour configurer Divecot, nous avons édité le fichier /etc/postfix/master.cf et ajouté en fin de ligne : dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient} Avant la modification du fichier /etc/dovecot/dovecot.conf de sauvegarde avec cette commande : cp -a /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.bak Nous l'avons édité ensuite remplacé son contenu par celui-ci : protocols = imap imaps pop3 pop3s log_timestamp = "%Y-%m-%d %H:%M:%S " mail_location = maildir:/home/vmail/%d/%n/Maildir ssl_cert_file = /etc/ssl/certs/dovecot.pem ssl_key_file = /etc/ssl/private/dovecot.pem namespace private { separator = . prefix = INBOX. inbox = yes } protocol lda { log_path = /home/vmail/dovecot-deliver.log auth_socket_path = /var/run/dovecot/auth-master postmaster_address = postmaster@labs.supemir.ma mail_plugins = sieve global_script_path = /home/vmail/globalsieverc } protocol pop3 { pop3_uidl_format = %08Xu%08Xv } auth default { user = root passdb sql { args = /etc/dovecot/dovecot-sql.conf } userdb static { args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes } socket listen { master { path = /var/run/dovecot/auth-master mode = 0600 user = vmail } client { path = /var/spool/postfix/private/auth mode = 0660 user = postfix group = postfix } } } Etant donné que Mysql est utilisé pour stocker les mot de passe, nous avons faites une copie de sauvegarde et l'avons ainsi modifié : driver = mysql connect = host=127.0.0.1 dbname=mail user=mail_admin password=mail_admin_password default_pass_scheme = CRYPT password_query = SELECT email as user, password FROM users WHERE email='%u'; La configuration de dovecot terminées, il faut redémarrer pour se rassurer qu'il fonctionne: service dovecot restart . Une vérification également dans le fichier /var/log/mail.log est nécessaire en utilisant la commande tail : tail /var/log/mail.log , nous avons obtenu ceci Figure 21 : Aperçu des fichiers logs. Avant de tester dovecot, nous avons modifié les permissions sur le fichier /etc/dovecot/dovecot.conf pour permettre à l'utilisateur vmail d'y accéder : chgrp vmail /etc/dovecot/dovecot.conf chmod g +r /etc/dovecot/dovecot.conf Test de connexion au serveur pop Figure 22 : Test de connexion au serveur POP. Configuration des alias massagerie Pour ce faire, nous avons édité le fichier /etc/aliases et l'avons ainsi modifié : postmaster: root root: postmaster@labs.supemir.ma Après avoir modifié ce fichier, un redémarrage de Postfix est requis pour mettre à jour les alias. La configuration de Postfix est complète, nous sommes au test du serveur mail pour être sûr qu'il fonctionne correctement. Figure 23 : Redémarrage de postfix Test de Postfix Pour ce faire, il faut saisir la commande suivante : telnet localhost 25 Etant connecté, il faut saisir cette commande pour continuer le test : ehlo localhost Nous obtenons ceci : Figure 24 : Aperçu du test de connexion au serveur. Pour quitter Postfix, il faut entrer la commande quit. Configuration des domaines et des utilisateurs Nous avons dans cette partie, ajouté notre domaine labs.supemir.ma à la table domains et ajouté également un utilisateur nommé test à la table users . Ceci a nécessité une connexion à la base de données comme suit : mysql -u root -p USE mail; INSERT INTO domains (domain) VALUES ('labs.supemir.ma'); INSERT INTO users (email, password) VALUES ('test@labs.supemir.ma', ENCRYPT('password')); Quit Pour activer les nouveaux comptes emails, il faut leur envoyer un message afin qu'ils soient accessibles par IMAP ou POP3. Ceci est au fait que les emails des nouveaux utilisateurs ne sont pas créés jusqu'à ce qu'un mail ne leur soit envoyés. Nous nous sommes servis de mailutils pour envoyer un message à notre nouvel utilisateur test, pour ce faire on tape la commande : La combinaison de touche ctrl+D est utilisé pour compléter le message. Ensuite une vérification des fichiers de log de Dovecot situé dans /var/log/mail.log est requise, nous avons obtenu le message ci-dessous, ce qui signifier que le mail a bien été envoyé : Figure 26 : Aperçu du fichier mail.log Enfin une vérification des fichiers de log de Dovecot situé dans /home/vmail/dovecot-deliver.log est requise, nous avons obtenu le message ci-dessous, ce qui signifier que le mail a bien été envoyé : La configuration de notre serveur mail s'achève ici, mais pour permettre à nos utilisateurs de pouvoir accéder à leur mail en interface graphique nous avons donc à cet effet mis en place un webmail. Installation de squirrelmail Un webmail ou messagerie Web, est une interface Web rendant possible l'émission, la consultation et la manipulation de courriers électroniques directement sur le Web depuis un navigateur. Un logiciel de webmail est un client de messagerie qui s'exécute sur un serveur Web, Il sert d'interface entre un serveur de messagerie et un navigateur web contrairement au client lourd qui permet les mêmes opérations à partir d'un logiciel installé localement sur un ordinateur personnel. Les avantages du webmail pour l'utilisateur sont de ne pas avoir à installer un logiciel spécialisé sur sa ou ses machines, de ne pas avoir à faire la configuration de base pour envoyer et recevoir le courrier et de déporter la responsabilité de la sécurité de l'installation vers le serveur. Les inconvénients de cette solution sont d'être dépendant en performance de la rapidité du réseau, en particulier si le nombre de message est grand ou s'il y a des pièces jointes de taille importante dans les messages. Nous avons plusieurs sortes de webmail sous la distribution GNU/Linux dont les plus connus sont : Squirrelmail et Roundcube. Dans la suite de notre projet, nous avons utilisé Squirrelmail pour sa facilité de déploiement, sa rapidité et sa configuration assez simple. Nous avons installé Squirrelmail en saisissant la commande : apt-get install squirrelmail Il est fournit avec une interface qui facilite sa configuration. Cette interface est accessible par la commande : squirrelmail-configure Figure 27 : Interface de configuration de squirrelmail. Le menu 2 'Server settings' (paramètres du serveur de messagerie) permet de renseigner les paramètres IMAP tels que le nom du serveur, le port utilisé et dans le menu 4 `General options', nous avons activé l'option `Allow server-side sorting' pour permettre le tri des mails côté serveur. Squirrelmail est livré avec un fichier de configuration apache dans /etc/squirrelmail/apache.conf . Pour permettre l'accès à squirrelmail via un navigateur, nous avons copié ce fichier dans /etc/apache2/sites-available/squirrelmail avec la commande: cp /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrelmail Ensuite nous avons créé un lien vers le répertoire sites-enabled avec la commande : ln -s /etc/apache2/sites-available/squirrelmail /etc/apache2/sites-enabled/squirrelmail Nous avons terminé la configuration, en saisissant en fin la commande : a2ensite squirrelmail Test d'utilisation Squirrelmail est accessible à travers cette url http://labs.supemir.ma/squirrelmail et nous obtenons cette interface qi permet à l'utilisateur de s'identifier pour accéder à sa boîtes aux lettres. Figure 28 : Aperçu de l'interface de connexion à squirrelmail. En entrant le login test@labs.supemir.ma et le mot de passe de notre utilisateur `test', nous entrons dans la boîte mail et nous apercevons ci-dessous le contenu de sa boîte aux lettres. Figure 29 : Interface de la boîte aux lettres d'un utilisateur. Nous avons créé des mails virtuels pours les membres de l'administration et les étudiants par niveau, tous ces utilisateurs peuvent désormais accéder à leurs boîte aux lettres à partir de toutes les machines du réseau local en saisisant l'adresse : http://labs.supemir.com/squirrelmail . Après la mise en place de notre serveur mail et d'un webmail, nous avons pensé à implémenter une sécurité contre les spams, qui représentent une réelle entrave pour les serveurs mail. C'est ainsi que pour pallier au problème des spams, nous avons d'installer SpamAssassin. Mise en place de SpamAssassin Ce logiciel a pour but de filtrer le trafic des courriels pour éradiquer les courriels reconnus comme pourriels ou courriels non sollicités. Face à l'augmentation importante du spam, ce logiciel connaît un engouement important et est adaptable sur de nombreux serveurs de courriels Postfix. SpamAssassin est un programme (en Perl) qui fait passer un certain nombre de tests au message. En fonction du résultat de ces tests, il attribue un score au message. Si le score dépasse un certain seuil, le courriel est alors considéré comme du Spam. SpamAssassin modifie alors le titre du message (il l'encadre par ** SPAM **). De plus, SpamAssassin positionne deux nouveaux en-têtes au message : X-Spam-Status et X-Spam-Level. Ces deux en-têtes permettent alors de créer des filtres dans votre client de messagerie pour orienter le message (par exemple vers la corbeille). Tous les messages doivent donc passer par SpamAssassin pour être traités, avant d'arriver dans leur dossier définitif. Nous allons donc procéder à l'installation de SpamAssassin. Ubuntu possède par défaut un anti-spam Bogofilter, il est installé et activé par défaut, il faut donc au préalable le désinstaller, cela se fait en ligne de commande ou en passant par la logithèque Ubuntu. Ensuite on peut installer SpamAssassin, en tapant la commande : apt-get install spamassassin spamc Nous avons souhaité qu'il ne démarre pas en tant que root, de ce fait nous avons créé un groupe et un utilisateur spamd de la manière suivante : groupadd spamd useradd -g spamd -s /bin/false -d /var/log/spamassassin spamd mkdir /var/log/spamassassin chown spamd:spamd /var/log/spamassassin Pour automatiser le demarrage de spamassassin au démarrage du système, nous avons faites la modification suivante dans le fichier /etc/default/spamassassin : ENABLED=1 SAHOME="/var/log/spamassassin/" OPTIONS="--create-prefs --max-children 2 --username spamd \-H ${SAHOME} -s ${SAHOME}spamd.log" -max-children définit le nombre de processus enfant -username définit le nom d'utilisateur de spamd précédemment créé -H définit le répertoire de base -s définit le fichier de log Ensuite le redémarrage du deamon spamassassin se fait en exécutant la commande : /etc/init.d/spamassassin start . Pour permettre à spamassassin d'utiliser Postfix, nous avons modifié le fichier /etc/postfix/master.cf en ajoutant cette ligne en début de ce fichier : smtp inet n - - - - smtpd -o content_filter=spamassassin Puis en ajoutant cette autre à la fin du même fichier : spamassassin unix - n n - - pipe user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient} Ceci fait, nous avons redémarré, nous avons redémarré Postfix pour charger la modification effectuée. Il a été important de faire un test pour s'assurer du bon fonctionnement se spamassassin, de cet fait nous avons envoyé des spams volontairement à notre adresse test@labs.supemir.ma et une vérification des fichiers de log nous a donné le resultat ci-dessous qui attest le bon fonctionnement du filtre antispam. Jul 26 14:56:10 localhost postfix/pipe[12139]: 9CBD5DA4BF: \ to=<test@labs.supemir.ma>, relay=spamassassin, delay=17, status=sent (localhost) Le serveur srvsupemir4 hébergeant plusieurs services, l'administration, la supervision de tous ces services en ligne de commande s'avère très lourde ; afin faciliter ces tâches d'administration, nous avons installé un logiciel qui prend en charge une vue générale sur tous les services que nous avons installés sur ce serveur. C'est dans ce cadre qu'est intervenu Webmin. Installation de Webmin Webmin est un outil permettant d'administrer une machine Linux. Il s'utilise par le biais d'un navigateur web. Webmin est une mine d'or pour les administrateurs réseaux : presque tout peut être configuré avec Webmin. Nous avons procédé à l'installation de Webmin en ajoutant d'abord sa clé à notre système en tapant : cd /root wget http://www.webmin.com/jcameron-key.asc apt-key add jcameron-key.asc la modification se fait également dans le fichier /etc/apt/sources.list en ajoutant cette ligne : deb http://download.webmin.com/download/repository sarge contrib Ceci fait, l'installation en ligne de commande est donc possible en exéxutant ces commandes : apt-get update apt-get install webmin Pour utiliser Webmin, il faut entrer dans notre navigateur l'adresse https://localhost:10000. Et nous avons l'interface de login : Figure 30 : Interface de connexion à Webmin. Après avoir renseigné les champs de login et de mot de passe correctement, nous obtenons le panneau visuel ci-dessous : Figure 31 : Aperçu de la page d'accueil de Webmin. Au travers de cette interface, nous avons une visibilité sur l'ensemble des services du système, nous pouvons leur apporter des modifications d'une manière aisée. Il reste à noter que pour des configurations affinées, il serait primordial de faire recourt aux fichiers de configuration afin de faire les modifications manuellement. Notre serveur est désormais fonctionnel, tout en respectant le cahier de charge qui a été définit. e. Serveur webLe poste nommé srvsupemir3 est le nom du serveur qui nous a servi de serveur web. Pour ce faire, nous avons procédé en deux étapes : d'abord nous avons installé un serveur web et ensuite hébergé un site web qui nous a servi de site de test. Sous le système GNU/Linux, nous disposons d'une variété de serveurs mais les plus réputés sont : LAMP Server, Nginx, XAMPP. Pour notre serveur, nous avons opté d'utiliser XAMPP car est que tout est bien ficelé pour que tout s'installe facilement et s'utilise très facilement. XAMPP est un kit d'installation d'Apache qui contient MySQL, PHP et Perl. Nous avons donc utilisé le kit Xampp pour les systèmes Linux ; ce kit (testé sous SuSE, RedHat, Mandrake and Debian) comprend : Apache, MySQL, PHP & PEAR, Perl, ProFTPD, phpMyAdmin, OpenSSL, GD, Freetype2, libjpeg, libpng, gdbm, zlib, expat, Sablotron, libxml, Ming, Webalizer, pdf class, ncurses, mod_perl, FreeTDS, gettext, mcrypt, mhash, eAccelerator, SQLite et IMAP C-Client. Installation Nous avons récupéré l'archive de xampp sur le site http://www.apachefriends.org/fr/xampp-linux.html . Il s'installe de la manière suivante : Explication : · tar : le programme permettant de gérer les archives tar ou tar.gz (c'est le cas échéant). · x : extrait l'archive. · v : montre ce qu'il fait (vous verrez par vous-même si vous l'activez). · f : utilise le fichier donné en paramètre, dans notre cas nous avons donné le chemin d'accès absolu à ce fichier. · z : prend en charge le type d'archive gzip (qui est utilisé ici). · -C : redirige l'extraction de l'archive vers le dossier donné en paramètre après. · /opt : répertoire d'installation des logiciels supplémentaires. L'installation terminée, il est nécessaire de démarrer le service pour pouvoir l'utiliser, ceci au travers de la commande : /opt/lampp/lampp start . Figure 32 : Démarrage de xampp. Test d'utilisation Notre serveur web installé, il a fallu vérifier qu'il fonctionne correctement et pour ce faire nous avons saisi l'adresse http://localhost dans la barre d'adresse du. Sécurisation L'inconvénient de xampp est qu'il est destiné à un usage de développement afin d'offrir le plus d'ouverture possible. Les éléments de sécurité absents observés sont les suivants : Ø Le mot de passe de l'administrateur de la base de données Mysql, Ø L'accès au serveur de base de données depuis le réseau, Ø Le serveur ftp intégré utilise un mot de passe par défaut connu, Ø phpMyadmin est accessible depuis le réseau, Ø Mysql et Apache s'exécutent via le même utilisateur. Ceci ouvre des brèches exploitables par un utilisateur malveillant ou des initiateurs d'attaques sur internet. Pour corriger ces faiblesses de sécurité, il a été important pour nous d'exécuter cette commande : /opt/lampp/lampp security, elle effectue une vérification de sécurité et rend le service xampp plus sécurisé. Elle permet en fait de modifier les paramètres par défaut de la manière suivante. Figure 33 : Sécurisation du serveur Web. Déploiement de notre site web Pour ce déploiement, nous avons utilisé le CMS Joomla! sous lequel nous avons créé un site pour l'école SUPEMIR. Joomla! Est un système de gestion de contenu libre, open source et gratuit. Il est écrit en PHP et utilise une base de données MySql. Nous avons donc exporté notre site créé localement et nous l'avons hébergé sous le serveur web. Voici les étapes de mise en place de notre site web sous notre serveur : Ø Exportation de la base de données de notre site, Ø Création d'une nouvelle base de données qui va accueillir la base de données sous PhpMyAdmin de Xampp, Ø Copie de l'ensemble des fichiers de notre site que nous avons placé à l'arborescence de la racine de notre site que nous avons créé avec la commande : sudo mkdir /opt/lampp/htdocs/supemir Ø Pour que le site soit fonctionnel sous notre serveur, nous avons donc modifié le fichier de configuration de notre site config.php ( se trouvant à la racine de notre site) pour qu'il puisse avoir accès à la base de données. Nous avons renseigné ce fichier par rapport à la configuration de notre serveur. Ø Pour permettre ensuite aux utilisateurs d'avoir accès à notre site, nous leur avons donné les droits d'accès au dossier supemir et à ses arborescences grâce à la commande : sudo chmod -R 777 /opt/lampp/htdocs/supemir Maintenant nous pouvons nous connecter à notre site, en saisissant dans notre navigateur https://localhost/supemir, ou depuis une machine du réseau nous saisissons : https://192.168.4.2/supemir. Figure 34 : Aperçu du site de test de SUPEMIR hébergé sur notre serveur. f. Serveur proxyNotre choix pour Squid se justifie par sa nature de logiciel libre et sa performance. Pour sa mise en place tout comme les autres logiciels il faut avoir les doits d'administration. Installation L'installation se fait au moyen de la commande : apt-get install squid, celui-ci s'installe et crée un répertoire /etc/squid/ contenant le principal fichier de configuration nommé squid.conf. Configuration La configuration par défaut de squid est fonctionnelle, mais nous avons apporté des modifications au fichier de configuration afin de l'optimiser, de mieux l'adapter à notre environnement et également pour rester en parfaite adéquation avec notre cahier de charges. Nous avons édité le fichier squid.conf et nous avons ajouté les lignes suivantes : Ø Définition des droits d'accès (contrôle d'accès) Nous avons définit ici les liste de contrôle d'accès pour la gestion des droits d'accès. # définit le réseau local que squi doit gérer acl local_network src 192.168.3.0/24 # définit un ensemble de poste auxquels nous autoriserons l'accès à l'interface du routeur acl allow_clients src 192.168.3.11 192.168.3.12 192.168.3.13 192.168.3.14 192.168.3.15 définit l'adresse du routeur auquel nous avons autorisé l'accès à partir de certains postes acl router dst 192.168.1.1/24 # définit l'horaire de connexion le matin acl matin time MTWHFA 06:00-09:00 # définit l'horaire de connexion à la pause acl pause time MTWHA 12:00-13:00 # définit l'horaire de connexion dans l'après midi acl pauseven time F 12:00-14:00 # définit l'horaire de connexion le matin acl soir time MTWHFA 16:00-23:00 Nous avons ajouté ces acls à la suite des lignes commaçant par « acl local_net » afin de respecter la structure du fichier. Ø Application des ACLs Après avoir créé les listes de contrôle d'accès, nous les avons autorisé à utiliser le proxy come suit : # autoriser les acces aux heures définies http_access allow local_network matin http_access allow local_network pause http_access allow local_network pauseven http_access allow local_network soir # permettre un accès permanent à internet aux members de l'administration http_access allow allow_clients # permettre aux member de l'administration d'accéder à l'interface web du routeur, refuser aux postes http_access allow allow_clients router http_access deny !allow_clients router Ces lignes sont ajoutées juste avant la ligne http_access deny all qui bloque tout ce qui n'est pas permit explicitement. Ø Autres modifications
Dans la partie TAG : visible_hostname, nous avons ajouté le nom de notre serveur avec cette ligne : visible_hostname srvsupemir2
Nous avons désactivé l'option qui permet d'inclure l'adresse IP ou le nom du système dans les requêtes http que le serveur proxy transfert, ceci en décommentant et en modifiant la ligne « # forwarded_for on|off » comme suit : forwarded_for on. Ceci permet de réduire les failles de sécurité au niveau du proxy.
Par défaut les messages d'erreur de squid sont en anglais, nous avons configuré la langue française pour faciliter la compréhension des erreurs aux utilisateurs. Ainsi dans la partie TAG : error_directory, nous avons décommenté et modifié la ligne comme suit : error_directory /usr/share/squid/errors/French .
Puisque notre proxy doit jouer le rôle de cache, nous avons augmenté la taille du cache en décommentant et en modifiant la ligne comme suit : cache_dir ufs /var/spool/squid 50000 32 512 .
Nous avons ajouté cette ligne pour préciser les serveurs dns que le proxy doit interroger. Ce ci se fait dans la partie TAG : dns_nameservers : dns_nameservers 192.168.1.1 192.168.3.254 212.217.0.1 212.217.0.12
Afin d'obliger tous les utilisateurs à passer par le proxy avant d'aller sur internet, nous avons configuré pour un usage transparent. Ainsi nous avons modifié la ligne « http_port 3128 » comme suit : http_port 3128 transparent. Pour un bon fonctionnement nous avons ajouté une règle au niveau du firewall qui redirige toutes les requêtes du réseau local utilisant le port 80 vers le serveur proxy. Redémarrage du service Après tout les modifications, il est important de redémarrer le processus squid pour la prise en compte des paramètres configurés : service squid stop puis service squid start. Installation et configuration de SquidGuard Nous avons opté de couplé squid avec squidGuard qui est un rédirecteur utilisé par ce dernier pour limiter l'accès à certaines URL en fonction de l'utilisateur, de la machine, de l'heure, du contenu ... Ce logiciel a plusieurs avantages, mais n'en avons utilisé que deux. Le premier d'entre eux est de limiter l'accès à des sites potentiellement dangeureux pour le poste client et plus généralement pour le réseau. Enfin, d'un point de vue légal, le fait de détenir des documents dégradants étant répréhensible, la mise en place de SquidGuard contribue à se prémunir de ce genre de mésaventure. - Installation : apt-get install squidGuard - Récupération des blacklists (liste noire, elle contient des une liste des urls malveillantes) wget ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz tar -zxvf blacklists.tar.gz -C /var/lib/squidguard/db/ cd /var/lib/squidguard/db mv blacklists/* . rm -rf blacklists Nous avons paramétré une mise à jour hebdomadaire des listes noires du squidGuard en créant une tâche cron. Pour ce faire, nous avons le fichier nommé squidguard_blacklists (gedit /etc/cron.weekly/squidguard_blacks) et nous y avons inscrit les lignes suivantes : #!/bin/sh # # Fichier de recup hebodmadaire /etc/cron.weekly/squidguard_blacklists if [ -d /var/lib/squidguard ]; then wget ftp://ftp.univ-tlse1.fr/pub/reseau/cache/squidguard_contrib/blacklists.tar.gz -O /var/lib/squidguard/blacklists.tar.gz tar -zxvf /var/lib/squidguard/blacklists.tar.gz -C /var/lib/squidguard/ rm -rf /var/lib/squidguard/db mkdir /var/lib/squidguard/db || true mv -f /var/lib/squidguard/blacklists/* /var/lib/squidguard/db/ chmod 2770 /var/lib/squidguard/db rm -rf /var/lib/squidguard/blacklists /var/lib/squidguard/blacklists.tar.gz /usr/bin/squidGuard -C all chown -R proxy:proxy /etc/squid /var/log/squid /var/spool/squid /usr/lib/squid /usr/sbin/squid /var/lib/squidguard /etc/init.d/squid restart fi Nous avons rendu ce fichier exécutable comme suit : chmod +x /etc/cron.weekly/squidguard_blacklists Nous avons également modifié le fichier de configuration de squidGuard afin de préciser les domaines auxquels nous avons appliqué des restrictions : # # CONFIG FILE FOR SQUIDGUARD # dbhome /var/lib/squidguard/db logdir /var/log/squid # ---------------------------------------- # Définition de la base de données de filtrage utilisée # ---------------------------------------- dest adult { domainlist adult/domains urllist adult/urls } dest publicite { domainlist publicite/domains urllist publicite/urls } dest warez { domainlist warez/domains urllist warez/urls } dest porn { domainlist porn/domains urllist porn/urls } dest violence { domainlist violence/domains urllist violence/urls } # ---------------------------------------- # Définition des ACL # ---------------------------------------- acl { default { # les thèmes supplémentaires sont à ajouter avant le mot-clé all par !<nom du thème> pass !porn !adult !publicite !warez !violence all # page qui s'affichera lors d'une tentative d'accès àaux sites interdits redirect http://localhost/interdiction.html } } Ceci fait, nous avons redémarré squid (service squid restart) pour charger les paramétrages effectués. Configuration d'une machine cliente Puisque le service fourni utilise un port particulier du serveur, les machines clientes doivent bien sûr être configurées en conséquence. Sur un poste client connecté sur le réseau local (avec une adresse IP valide) et qui établit parfaitement un 'ping' vers le serveur proxy, nous avons faites la configuration suivante. Pour Firefox Dans Outils -> Options Sélection de l'onglet Connexion puis un clic sur Réseau Local Cocher Serveur Proxy et entrer l'adresse IP 192.168.2.2 et le numéro de port d'écoute qui est 3128. Pendant les heures où la connexion est interdite, les utilisateurs reçoivent ce message lorsqu'ils essaient de se connecter : Figure 35 : Message d'erreur pendant les heures où la connexion est interdite. Nous avons paramétré cette page pour qu'elle informe l'utilisateur des horaires auxquels il peut se connecter g. FirewallNotre firewall est un ordinateur sur lequel nous avons installé Red Had Enterprise linux server 5. Netfilter que nous avons utilisé est un firewall natif intégré à linux qui utilise iptables comme interface en ligne de commande pour sa configuration. Nous avons intégré trois cartes réseau à ce poste afin de le relier au serveur web et au serveur proxy par des câbles croisés ; il est relié au réseau local et au routeur par des câbles droits. Nous avons attribué des adresses statiques à ces interfaces du firewall Nous avons édité les fichiers et les avons modifiés comme suit : gedit /etc/sysconfig/network-script/ifcfg-eth0 DEVICE=eth1 ONBOOT=yes BOOTPROTO=dhcp HWADDR=00:0c:29:74:15:67 TYPE=Ethernet gedit /etc/sysconfig/network-script/ifcfg-eth1 DEVICE=eth0 ONBOOT=yes BOOTPROTO=none HWADDR=00:0c:29:74:15:5d TYPE=Ethernet NETMASK=255.255.255.0 IPADDR=192.168.2.1 USERCTL=no IPV6INIT=no PEERDNS=yes gedit /etc/sysconfig/network-script/ifcfg-eth2 DEVICE=eth2 ONBOOT=yes BOOTPROTO=none HWADDR=00:0c:29:74:15:71 TYPE=Ethernet NETMASK=255.255.255.0 IPADDR=192.168.4.1 USERCTL=no IPV6INIT=no PEERDNS=yes gedit /etc/sysconfig/network-script/ifcfg-eth3 DEVICE=eth3 ONBOOT=yes BOOTPROTO=none HWADDR=00:0c:29:74:15:7b NETMASK=255.255.255.0 IPADDR=192.168.3.1 TYPE=Ethernet USERCTL=no IPV6INIT=no PEERDNS=yes Mise en place de la passerelle Afin d'activer le routage entre les quatres interfaces réseaux, nous avons activé le service routage de Linux par la commande : « echo 1 > /proc/sys/net/ipv4/ip_forward » . Pour rendre ce routage permanant nous avons modifié cette valeur dans le fichier /etc/sysctl.conf en remplaçant la ligne « net.ipv4.ip_forward= 0 » par « net.ipv4.ip_forward = 1 ». Règles de filtrage Accès au réseau local à partir du réseau externe interdit Toutes les requêtes http du réseau local doivent passer par le proxy Accès au serveur web depuis le réseau local autorisé Accès au serveur web depuis l'extérieur autorisé Accès au réseau local depuis le serveur web interdit Accès au serveur mail depuis l'extérieur autorisé Accès au serveur proxy depuis l'extérieur interdit Accès au réseau local depuis le serveur proxy interdit II. SECURITEMise en oeuvre d'un politique de sécurité Nous avons axé notre politique de sécurité selon cinq axes : - Se prémunir des attaques (proactif) en évitant, dans un premier temps, la présence des failles dans les composants du système d'information. Dans l'optique de respecter ce premier point, nous avons opté pour des versions stables des logiciels mis sur le réseau. - Bloquer les attaques en leur empêchant de parvenir jusqu'aux composants sensibles et potentiellement vulnérables du système d'information ou plus généralement réduire les chances de succès des attaques même si elles visent des éléments vulnérables. Nous avons ainsi mis en oeuvre un système de filtrage des paquets en fonction des adresses sources, destinations, les protocoles. - Renforcer la défense (rétroactif) afin de limiter les conséquences d'une compromission de l'un ou l'autre des éléments du système d'information. Ce point nous semblait être le plus difficile à mettre en oeuvre du fait de l'accessibilité de la salle accueillant les postes serveurs. Malgré cela, nous avons suggérer une mise en place d'un local technique à accès restreint. - Détecter et identifier les incidents ou compromissions survenant sur le système d'information afin d'y faire face. - Réparer le système suite à un incident ou à une compromission. Nous avons pensé à une sauvegarde périodique des configurations réalisées sur les machines, les fichiers de partages et les mails sur un support externes. Réalisations En terme de sécurité pour cette architecture, voici autres points abordés : Ø Définition du domaine à protéger qui est le réseau local, Ø Définition de l'architecture du réseau (pare-feu,DMZ), Ø Mise en place d'une méthode d'authentification des utilisateurs lors de l'ouverture de session sur les postes clients, Ø Mise en place d'une méthode d'authentification des utilisateurs lors de la connexion au domaine, Ø Mise en place d'une méthode d'authentification des utilisateurs pour l'utilisation de certains services (messagerie, partage de fichiers) Ø Restriction de l'accès au routeur aux membres de l'administration. Suggestions Ø Aménagement d'un local technique à accès restreint où tous les serveurs seront placés, ce dernier doit être une salle donc l'accès n'est autorisé qu'aux personnes qui administrent le réseau. Ø Définition d'une fréquence de changement des mots de passe du compte administrateurs sur les serveurs. Ø Sensibilisation des utilisateurs : tout utilisateur a le droit de recevoir les renseignements nécessaires à la bonne compréhension de ses responsabilités en matière de sécurité informatique. Ce document peut servir de documentation à d'autres étudiants, pour ne pas donc compromettre la sécurité de nos serveurs, les mots de passe n'ont pas été diffusés dans ce document, ils seront remis à l'administrateur du réseau à la fin du projet. CHAPITRE IV : EVALUATION FINANCIEREQuelque que soit le type et la nature d'un projet, une analyse de sa faisabilité économique s'avère primordiale. Ce chapitre repose essentiellement sur l'étude de faisabilité au niveau économique. Elle permet d'estimer grossièrement les coûts d'investissement et de fonctionnement du projet, les délais prévus et les retours sur investissements possibles. I. PLANNING DE REALISATION DES TRAVAUXLa planification indique le calendrier général d'exécution des grandes étapes du projet. Chacune de ces étapes contient des sous étapes qui vont être développées lors de l'exécution du projet.
Tableau 5 : les étapes t la durée du projet. Vu le temps que nous avons mis pour le déploiement du réseau de SUPEMIR, pour un éventuelle projet de même nature, nous estimons à trois mois le temps nécessaire pour présenter une solution complète, avec une documentation à l'appui. II. COUT DE MISE EN OEUVREL'offre financière est exprimée en journées homme de travail, auxquelles sont associés les coûts unitaires suivants, fonction des profils des experts intervenant sur le projet : Ø Direction de projet / Responsable technique : 300 Dhs HT / jour Ø Chef de projet: 250 FCFA Dhs / jour Ø Ingénieur système et réseaux : 300 Dhs / jour Sur ces bases, le budget lié à la réalisation des composants de la solution global est présenté comme suit. 1. Fourniture matériels
Tableau 6 : Fourniture matériels, coût en Dirham. Ces matériels peuvent varier si le client opte pour la virtualisation de ses certains serveurs. 2. Mise en place des serveurs
Tableau 7 : Coût de la mise en oeuvre. 3. Coordination
4. Récapitulatif du coût de la prestation
CONCLUSIONLa sécurité des systèmes d'informations prend tout son sens dans un contexte tel que celui dans lequel nous avons travaillé. La connaissance des principes de base de la sécurité ainsi que la mise en place d'une bonne politique de sécurité a contribué, dans ce cadre, à instaurer un réseau sécurisé même si l'activité de ce dernier n'était pas significative par rapport à la durée du projet. Même si les exigences fonctionnelles et non fonctionnelles ont été satisfaites, ce manque aurait pu être comblé par une capacité étendue de virtualisation du parc, offrant une continuité de service à ce dernier. Les enseignements acquis par le biais de notre autonomie et la démarche de recherche ont incontestablement participé à l'acquisition de méthodes valorisantes pour l'avenir professionnel se dessinant à cours terme. REFERENCES BIBLIOGRAPHIES· Support électronique http://www.apachefriends.org/fr/xampp-windows.html http://library.linode.com/email/postfix/dovecot-mysql-ubuntu-10.10-maverick https://help.ubuntu.com/community · Support papier Supports de cours technologies réseaux, sécurité internet, administration réseaux sous Unix. GLOSSAIREBande de base : Mode de transmission où les informations à transmettre ne subissent pas de modification de rythme entre l'émetteur et le canal de transmission, et où la modulation occupe la totalité de la bande passante. Laser : fondamentalement, un amplificateur de lumière (fonctionnant grâce à l'émission stimulée) dont la sortie est branchée sur l'entrée. Garde-barrière : Système logiciel ou matériel utilisé pour empêcher les intrusions non autorisées sur un réseau. URI : courte chaîne de caractères identifiant une ressource sur un réseau. Latence : décalage entre le temps d'émission et de réception d'une information. Gigue : variation du délai de transfert de l'information. Blacklist : listes des sites internet qui ne respectes pas certaines règles et conditions et qui sont de ce fait réprimandés par les moteurs de recherches. LISTES DES FIGURESFigure 1 : Evolution du risque en fonction de la vulnérabilité et de la menace. 27 Figure 2 : Architecture du réseau existant 37 Figure 3 : Architecture du réseau de SUPEMIR 45 Figure 4 : Architecture de déploiement. 46 Figure 5 : Renouvèlement de bail IP. 51 Figure 6 : Résultat du test de résolution de nom par le serveur DNS. 55 Figure 7 : Création des groupes et des utilisateurs. 56 Figure 8 : Ajout des utilisateurs au serveur Samba. 57 Figure 9 : Ajout du groupe des ordinateurs et d'un compte machine à Samba. 57 Figure 10 : Création des répertoires de partage. 58 Figure 11 : Résultat du test de la syntaxe du fichier de configuration. 63 Figure 12 : Aperçu des répertoires partagés sur le serveur. 64 Figure 13 : Utilisation du serveur. 64 Figure 14 : Intégration d'un client windows au domaine. 65 Figure 15 : Lecteurs réseau associées au partage de l'utilisateur achraf. 66 Figure 16 : Vérification du nom d'hôte. 66 Figure 17 : Connexion à la base de données. 67 Figure 18 : Création d'un utilisateur avec d'c droits. 68 Figure 19 : Suite configuration postfix. 70 Figure 20 : Création du certificat SSL. 71 Figure 21 : Aperçu des fichiers logs. 74 Figure 22 : Test de connexion au serveur POP. 74 Figure 23 : Redémarrage de postfix 75 Figure 24 : Aperçu du test de connexion au serveur. 75 Figure 26 : Aperçu du fichier mail.log 77 Figure 27 : Interface de configuration de squirrelmail. 78 Figure 28 : Aperçu de l'interface de connexion à squirrelmail. 79 Figure 29 : Interface de la boîte aux lettres d'un utilisateur. 79 Figure 30 : Interface de connexion à Webmin. 82 Figure 31 : Aperçu de la page d'accueil de Webmin. 82 Figure 32 : Démarrage de xampp. 84 Figure 33 : Sécurisation du serveur Web. 85 Figure 34 : Aperçu du site de test de SUPEMIR hébergé sur notre serveur. 86 Figure 35 : Message d'erreur pendant les heures où la connexion est interdite. 92 LISTE DES TABLEAUXTableau 1 : Caractéristiques des ordinateurs du réseau de SUPEMIR. 38 Tableau 2 : Equipements d'interconnexion 38 Tableau 3 : Matériels pour le déploiement. 43 Tableau 4 : Plan d'adressage 47 Tableau 5 : les étapes t la durée du projet. 96 Tableau 6 : Fourniture matériels, coût en Dirham. 97 Tableau 7 : Coût de la mise en oeuvre. 98 LISTE DES SIGLES ET ABREVIATIONSADSL : Asymetric Digital Suscriber Line AFNIC: Association Française pour le Nommage Internet en Coopération ANSI/TIA/EIA: American National Standards Institute/Telecommunications Industry Association/ Electronic Industries Alliance ATM : Asynchronous Transfer Mode BIND: Berkley Internet Naming Daemon BNC: Bayonet Neill-Concelman CPU: Centrat Process Unit DD: Disque Dur DHCP : Dynamic Host Configuration Protocol DIFFServ: Differentiated Services or DiffServ DMZ: Demilitarized zone DNS: Domain Name Sever DNSSEC : DNS Security Extensions DWDM: Dense Wavelength Division Multiplexing FDDI : Fiber Distributed Data Interface FTP : Foiled Twisted Pair HTTP: Hypertext Transfert Protocol IAP : Internet Access Provider ICMP: Internet Control Message Protocol IEEE: Institute of Electrical and Electronics Engineers IGMP (Internet Group Management Protocol) IIS: Internet Information Services IMAP: Internet Message Access Protocol IP : Internet Protocol IPSec: Internet Protocol Security IPV4:Internet Protocol version 4 ISO: Interconnection des Systèmes Ouverts LDAP : Lightweight Directory Access Protocol LAN: Local Area Network L2TP: Layer 2 Tunneling Protocol MAC : Media Access Control MAN: Metropolitan Area Network MIME : Multiputpose Internet Mail Extention MRTG: Multi Router Traffic Grapher NAT : Network Address Translation NIC: Network Interface Card OSI: Open System Interconnect OSPF : Open Shortest Path First PCMCIA: Personal Computer Memory Card International Association PDC : Primary Domain Controler PID: Proccess Identifier POP: Post Office Protocol PPTP: Point-to-Point Tunneling Protocol QOS: Quality Of Service RAID :Redundant Array of Inexpensive Disks RAM: Read Access Memory RIP : Routing Information Protocol RFC: Request Form Comment R-LAN - WIFI: Radio Local Area Network - Wireless Fidelity RSVP: Resource Reservation Protocol STP : shielded twisted pair SFTP : shielded foiled twisted pair SGBD: Système de Gestion de Base de Données SMIME: Secure/Multipurpose Internet Mail Extensions SNMP:Simple Network Management Protocol SSL: Secure Sockets Layer SSTP : Super Shielded Twisted Pair TCP : Transport control Protocol URI : Uniform Ressource Identifier UTP : Unshielded Twisted Pair VLAN:Virtual Locan Area Network VPN: Virtual Private Network WAN : Wide Area Network
| ![]() "Ceux qui rêvent de jour ont conscience de bien des choses qui échappent à ceux qui rêvent de nuit" |