Installer le paquet openssl à l’aide de la commande
# apt install openssl
Connectez-vous sous root et aller dans le répertoire de configuration de votre serveur Apache2 /etc/apache2(on peut évidemment choisir un autre répertoire) et créez un répertoire appelé « ssl ». Vous vous placez dans ce répertoire afin que les clés et les certificats soient créés à l’intérieur avant d’effectuer les manipulations.
On génère la clé privée avec la commande suivante en définissant un nom de fichier :
# openssl genrsa 1024 > serveur.key
La sortie attendue est la suivante :
Si vous souhaitez que cette clé ait un mot de passe(qui vous sera demandé à chaque démarrage d’apache, donc à éviter !), ajoutez « -des3 » après « genrsa ».
Pour observer son contenu taper la commande:
# less serveur.key
Pour protéger votre fichier taper la commande :
# chmod 400 serveur.key
Ce fichier contient la clé publique à certifier
# openssl req -new -key serveur.key > serveur.csr
Le système va vous demander de saisir des champs ; remplissez-les en adaptant sauf le champ « Common Name » qui doit être identique au nom de votre serveur virtuel :
Ce n’est pas la peine de saisir d’autres « extra attributes »…
Ceci a pour effet de créer le formulaire de demande de certificat (fichier serveur.csr) à partir de notre clé privée préalablement créée.
Ce fichier contient la clé publique à certifier.
Deux possibilités :
Pour signer un certificat, vous devez devenir votre propre autorité de certification, cela implique donc de réaliser une clé et un certificat auto-signé.
La création de la clé privée de l’autorité de certification se fait comme précédemment :
# openssl genrsa -des3 1024 > ca.key
Ce qui a pour effet de créer la clé privée de l’autorité de certification. Dans ce cas, il vaut mieux rajouter l’option -des3 qui introduit l’usage d’une « passphrase » (mot de passe long qui peut même contenir du blanc) car c’est cette clé privée qui signera tous les certificats que l’on émettra ; cette « passphrase » sera donc demandée à chaque utilisation de la clé.
Ensuite, à partir de la clé privée, on crée un certificat x509 pour une durée de validité d’un an auto-signé
#openssl req -new -x509 -days 365 -key ca.key > ca.crt
Il faut saisir la passphrase… puisqu’on utilise « ca.key » que l’on a protégé. Et on donne les renseignements concernant cette fois-ci l’autorité de certification (c’est à dire nous-même).
Attention : le nom de « Common Name » doit être différent de celui qui a été donné pour la clé (ici cert_CA).
C’est notre certificat d’autorité de certification qui va permettre de signer les certificats créés.
La commande qui signe la demande de certificat est la suivante :
#openssl x509 -req -in serveur.csr -out serveur.crt -CA ca.crt -CAkey ca.key -CAcreateserial -CAserial ca.srl
Il faut saisir la passphrase…
L’option « CAcreateserial » n’est nécessaire que la première fois.
Le certificat signé est le fichier « serveur.crt« . La sortie de la commande attendue est la suivante:
Vous avez maintenant un certificat pour votre serveur qui se nomme « serveur.crt »
La commande ci-dessous permet de voir le certificat :
# less serveur.crt
C’est ce dernier qui va valider le certificat reçu par le client lors de la requête https://. Pour installer sur votre navigateur le certificat de l’autorité de certification, fichier ca.crt :
Sur Mozzila :
Aller sur préférence > confidentialité et Sécurité ou Vie Privée et Sécurité > Certificats > Click sur Afficher les certificats > Autorités, aller tout en bas et cliquer sur « Importer » chercher le dossier où se trouve le certificat ca.crt (/etc/apache2/ssl) valider et fermer la fenêtre
Vérifions tout d’abord si le serveur apache2 a déjà le module ssl chargé à l’aide de la commande :
# apache2ctl -M | grep ssl
Le module est chargé si le résultat de la commande renvoie :
Sinon nous rechargeons le module avec la commande :
# a2enmod ssl
La sortie de cette commande devrait ressembler à ça :
Dans un premier temps il est nécessaire que le serveur apache écoute sur le port 443. Pour cela il suffit d’éditer le ficher /etc/apache2/ports.conf et vérifier que la ligne Listen 443 y soit présente.
La meilleure manière de l’intégrer est de l’écrire de la sorte :
Ainsi, lors de la désactivation (volontaire ou non) du module SSL d’Apache, la configuration restera correcte et ne plantera pas le serveur
Dans un second temps il est nécessaire de créer un virtualhost, Apache prenant en compte notre certificat ssl. Debian et Ubuntu en fournissent un par défaut (/etc/apache2/sites-available/default-ssl) que nous allons modifier pour tester.
Ouvrir le fichier /etc/apache2/sites-available/default-ssl.conf
Chercher les sections suivantes ou rajouter celles qui manquent :
VirtualHost _default_ :443
ServerAdmin webmaster@localhost
Servername dns.pawoed.org :443
Vérifier que les variables suivantes sont correctement définies dans le même fichier :
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/serveur.crt # chemin du fichier du certificat signé
SSLCertificateKeyFile /etc/apache2/ssl/serveur.key #chemin du fichier de la clé privée du certificat
NB :
1-attention à bien renseigner le bon répertoire du DocumentRoot (c’est dans ce répertoire que se trouve la configuration de votre site)
2-penser à créer le répertoire ErrorLog renseigner dans ce fichier
À l’aide de la commande ci-dessous nous allons activer l’hôte virtuel (en étant dans le répertoire /etc/apache2/sites-available) :
# a2ensite default-ssl
Redémarrer avec la commande
# service apache2 restart
À partir d’un navigateur sur votre poste client renseigner votre url :
https://dns.pawoed.org ou https://www.pawoed.org
Télécharger l’intégralité de la documentation ici
Nous avons maintenant un serveur Zabbix fonctionnel et nous avons décider de rajouter les machines qui composent notre infrastructure dans notre solution de supervision. Ici, nous allons donc installer le client Zabbix sur lune machine Linux, afin de la remonter sur le serveur zabbix.
Sous Linux, l’installation est similaire à celle du serveur :
nous installons le paquet de l’agent Zabbix avec la commande « apt-get install zabbix-agent », par la suite, nous allons modifier sa configuration qui se trouve dans le fichier /etc/zabbix/zabbix_agentd.conf, et moifier les lignes suivantes
Server=’@IP_du_serveur’
ServerActive=’@IP_serveur’
Hostname=’nom_machine_zabbix’
Par la suite retourner sur l’interface web de notre serveur Zabbix, enter dans le menu : configuration>hosts et cliquer sur « Create host »
Indiquer un nom d’hôte, le(s) groupe(s) auxquels appartient la machine et son adresse IP.
Sélectionner le(s) template(s) voulu et cliquer sur le bouton « Add » puis sur le bouton « Update »pour valider.
Pour finir redémarrer le service zabbix-agent. Si nous retournons sur le serveur zabbix, nous allons voir apparaitre notre machine qui vient d’être configurée.
Afin de remonter chaque machine sur le serveur zabbix, nous devons au préalable installer l’agent sur chaque poste que l’on souhaite surveiller. L’agent remontera périodiquement les informations nécessaire.
Aller sur la page Télécharger l’agent en fonction de l’OS:
https://www.zabbix.com/download_agents
L’agent se présente sous la forme d’un fichier zip, on va décompresser ce fichier et copier le fichier zabbix_agentd.win.conf ainsi que zabbix_agentd.exe dans un dossier que l’on crée à la racine duC:\zabbix.
Modifier les lignes suivantes :
Server=’IP_DU_Server_Zabbix’
ServerActive=’IP_DU_Server_Zabbix’
Hostname=’Nom_exact_de_la_machine_Hote’
Ouvrir le terminal en tant qu’administrateur puis lancer cette commande :
c:\zabbix\bin\zabbix_agentd.exe --config c:\zabbix\conf\zabbix_agentd.win.conf --install
Le –config sert à lier l’exécutable et le fichier de configuration tandis que le –install installe l’agent.
Démarrer le service avec la commande:
c:\zabbix\bin\zabbix_agentd.exe --start
Vérifier les logs :
c:\zabbix_agentd.log
Afin de permettre au pare-feu Windows de ne pas bloquer la communication entre notre agent et notre serveur, nous allons créer une règle personnalisée pour autoriser la communication, par défaut l’agent fonctionne sur le port 10050 en UDP et TCP. Ouvrir le menu « configuration avancée« du pare-feu et cliquer sur « Nouvelle règle… » dans les règles entrantes.
Sélectionner la règle par port
Cocher le port TCP et renseigner son numéro, le 10050 par défaut.
On autorise la connexion et on ajoute les profils sur lesquels la règle s’applique.
Faire de même avec le protocole UDP, et terminer en donnant un nom aux règles créées afin de les retrouver facilement.
Par la suite retourner sur l’interface web de Zabbix et ajouter un nouvel hôte, en précisant son nom d’hôte ainsi que son groupe. Nous pouvons choisir de renseigner son nom FQDN pour communiquer avec le serveur.
Ensuite sélectionner le(s) template(s), les ajouter avec le bouton « Add » et valider pour terminer.
Désormais cette machine est bien supervisée par le serveur zabbix.
ZABBIX: est une application libre (open source) de supervision des systèmes et des réseaux en infrastructure IT. Elle a été créé par Alexei Vladishev.
Par sa polyvalence, Zabbix peut superviser et vérifier les statuts d’une multitude de services réseaux, ou systèmes (serveurs), tout en surveillant au niveau matériel de nombreux types d’équipements présents au sein d’une infrastructure IT, comme un routeur, une imprimante, un téléphone IP, … grâce à l’utilisation du protocole SNMP ( Simple Network Management Protocol) .
Installation ZABBIX
Pour l’installer, il faut aller sur le site, de Zabbix, et télécharger la bonne version.
http://repo.zabbix.com/zabbix/4.0/debian/pool/main/z/zabbix-release/
Une fois téléchargée, se déplacer dans le dossier où se trouve le paquet, en général les paquets téléchargés sont dans le répertoire Téléchargement. Ensuite faire la commande:
dpkg -i zabbix-release_4.0-2+stretch_all.deb
Pré-requis
apache + mysql + php qui sont contenus dans les paquets que nous installerons ci-dessous.
Avant l’installation faire une mise à jour des paquets avec « apt update » ensuite installer, les paquets zabbix-server-mysql zabbix-frontend-php zabbix-agent.
Création d’un utilisateur zabbix dans mysql
create user “zabbix”@”localhost” identified by “zabbix”;
Configuration de la base de données
se connecter à mysql avec la commande:
"mysql -u root -p" et renseigner le mot de passe
"CREATE DATABASE zabbix;" #pour Créer la base de donnée:
Donner tous les droits (grant all privileges) sur la base de donnée zabbix à l’utilisateur (to) zabbix identifié par le mot de passe (identified by) ‘azerty’.
GRANT ALL PRIVILEGES ON zabbix.* TO ‘zabbix’@’localhost’ IDENTIFIED BY 'azerty';
flush all privileges;
"quit" #pour quitter
Par la suite, importer le fichier SQL qui va créer tous les éléments nécessaires au bon fonctionnement de notre base de données (import des tables, etc.), avec la commande:
"zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix"
La commande zcat permet d’afficher le contenu d’un fichier gzipper, ensuite le contenu affiché par la commande, zcat sera envoyé dans mysql grâce au | (pipe), la commande mysql se présente comme ceci : mysql -u<utilisateur_bdd_zabbix> -p <bdd_de_zabbix>.
Configurons la base de données du serveur zabbix, en lui renseignant l’endroit où se trouve cette base, pour ce faire, éditer le fichier /etc/zabbix/zabbix_server.conf et modifier les lignes suivantes:
DBHost= »localhost » -> machine où se trouve la bdd »
DBName= »zabbix » -> nom de la bdd »
DBUser= »zabbix » -> nom de l’utilisateur de la bdd »
DBPassword= »azerty » -> mot de passe de l’utilisateur »
Par la suite, configurer le php, comme nous utilisons apache2 comme serveur web, en modifiant le fichier /etc/apache2/conf-available/zabbix.conf comme suit :
php_value max_execution_time 300
php_value memory_limit 128M
php_value post_max_size 16M
php_value upload_max_filesize 2M
php_value max_input_time 300
php_value always_populate_raw_post_data -1
php_value date.timezone Europe/Paris
Redémarrer les services zabbix-server zabbix-agent et apache2, ensuite aller sur l’interface web de zabbix qui se trouve à l’adresse http://@IP_zabbix_server/zabbix.
Une fois sur l’interface web, nous devons installer le front end, ensuite cliquez sur suivant sur la première page, la deuxième page vérifie la configuration et tout est vert grâce aux configurations que l’on a fait au préalable. Ensuite on nous demande des informations sur la base de données, remplir les champs demandés, la page suivante nous permet d’entrer un nom pour cette installation si on le souhaite ensuite nous avons un récapitulatif, le front end est ainsi installé. Pour s’y connecté on utilise le login Admin et le mot de passe azerty. vous pouvez dès à présent naviguer sur l’interface Web de votre serveur.
GLPI (Gestion Libre de Parc Informatique) est un gestionnaire de parc informatique libre. Il permet de centraliser des outils liés à l’administration de la structure informatique d’une entreprise. La fonctionnalité qui est en majeure partie utilisée par les services informatiques est la gestion de tickets d’incidents.
Pré-requis
Faire tout d’abord une mise à jour des paquets avec la commande
« apt-get update »
Installer les paquets suivants:
apt install apache2 php7.0-fpm mysql-server php7.0-curl php7.0-gd php7.0-mysql php7.0-cli php7.0-imap php7.0-ldap php7.0-apcu php7.0-xmlrpc php7.0-mbstring php7.0-xml php-cas.
Création d’un utilisateur et la base de données de GLPI :
Définir un mot de passe pour root
"mysql_secure_installation"
Se connecter au serveur de base de données MariaDB
"mysql -u root"
Création d’un utilisateur permettant d’accéder à la base de donnée de glpi
"create user 'glpi'@'localhost' identified by 'glpi'; "
Création de la base de donnée de glpi.
"create database glpi ;"
Donner des droits à l’utilisateur de la base de données.
" grant all privileges on glpi.* to 'glpi'@'localhost'; "
Recharger les privilèges pour la prise en compte des modifications avec la commande suivante:
"flush privileges;"
"quit" #pour quitter.
Aller sur le navigateur et télécharger glpi sur https://glpi-project.org/fr/telechargements/
Ouvrir votre terminal et déplacer vous dans le répertoire téléchargements, décompresser le fichier glpi qui s’y trouve en .tgz, à l’aide de la commande:
"tar -xvf glpi-9.4.2.tgz"
Copier le fichier décompressé dans le répertoire « /var/www »
"cp glpi /var/www -r"
Modifier le fichier d’apache afin de pouvoir accéder à l’interface Web de glpi.
"nano /etc/apache2/sites-available/000-default.conf"
Changer la ligne « DocumentRoot /var/www/html en /var/www/
Redémarrer le service apache
"service apache2 restart"
Se déplacer dans /var/www/glpi
"cd /var/www/glpi"
Donner des droits comme ci dessous:
"chmod 777 config"
"chmod 777 files -R"
Connectez-vous à l’interface web de GLPI via http://ServeurIP/glpi. Dans notre cas, http://172.16.2.4/glpi. Vous accédez à l’interface Web de GLPI, sélectionnez la langue et cliquez sur « OK ». Une nouvelle page s’ouvre comme sur l’image ci-dessous cliquez sur « Installer »
Les voyants sont en verts, cliquez sur continuer:
Étape -1: Saisir les informations concernant les accès à la base de données de GLPI :
Étape -2: Sélectionner le base de données GLPI :
Étape -3: Cliquer sur Continuer
Étape -4: Cliquer sur Continuer (vous pouvez décocher la case Envoyer « statistiques d’usage »)
Enfin cliquer sur « Utiliser GLPI »
Saisir les identifiants par défaut pour se connecter à l’interface web administration de GLPI : glpi/glpi
Le fichier .htaccess se situe à la racine du site web. Il permet de donner des instructions sur les modalités d’accès au contenu de notre site grâce à des fichiers de configuration spécifiques aux serveurs web Apache.
Le fichier htaccess sert principalement à protéger des répertoires par des mots de passes, créer des redirections ou encore des pages d’erreurs (type 401,404…). Mais dans le cadre de ce TP, nous n’aborderons que la protection d’une page web par mot de passe.
Configuration
Je vais faire le choix de protéger le répertoire crée plus haut sur le serveur web, à savoir « /var/www/html/epbooktic »
« nano /var/www/html/epbooktic/.htaccess » et renseigner les champs suivants :
AuthName : permet de renseigner le message qui s’affichera sur votre page web
AuthType : indique le type d’authentification
AuthUsersFile : indique le chemin du fichier qui contient les mots de passe
Require : précise que seuls les utilisateurs authentifiés pourront accéder à la page web
Pour cela, se déplacer dans le répertoire et taper la commande « htpasswd –c .htpasswd NomUtilisateur », il vous sera demandé de renseigner le mot de passe et le confirmer.
Cette commande sera répétée autant de fois qu’il y a d’utilisateur, mais sans l’option –c car elle permet de créer le fichier en même temps que la création du premier utilisateur.
Pour voir le fichier, taper la commande « ls -al » afin de voir les fichiers cachés, comme le fichier « .htaccess » et « .htpasswd ».
<Directory /var/www/html/epbooktic>
Options Indexes FollowSymlinks
AllowOverride AuthConfig
</Directory>
Nous nous rendons sur la page web de notre site www.epbooktic.local et nous constatons bien qu’il nécessite un identifiant et mot de passe pour y accéder.
Par serveur Web (aussi appelé serveur http), on entend, tout type de serveur qui permet de diffuser des contenus Web sur internet ou intranet. L’un de ces serveurs est le serveur apache celui que nous allons configurer dans ce TP. Il existe d’autre serveur web notamment: IIS, Lighttpd, Nginx.
Installation du serveur apache sous Debian
Pour l’installer, il faut taper la commande
« apt-get update && install apache2 »
La première commande permettant de mettre à jour les paquets et la seconde à installer le Service apache.
Après l’installation, redémarrer le service avec la commande
service apache2 restart
Après l’installation, redémarrer le service avec la commande « service apache2 restart »
Pour vérifier si le service est bien installé et fonctionnel taper la commande « ps –ax ». Pour vérifier le port du web est bien à l’écoute taper la commande : « netsat –atn »
Configuration d’une zone sur le serveur DNS
Nous allons créer une zone sur le serveur DNS (bind9), La zone: « epbooktic.local » et faire les enregistrements de « type A » du serveur apache ainsi qu’un enregistrement de type « CNAME ».
Création de l’arborescence
Nous allons par la suite créer un répertoire à la racine du répertoire « /var/www/html »
"mkdir /var/www/html/epbooktic "
Par la suite, se déplacer dans le répertoire nouvellement créé (cd /var/www/html/epbooktic) et éditer le fichier « index.html », renseigner les informations que vous souhaitez voir sur votre page web.
Configuration des hôtes virtuels ou VirtualHost
Chaque hôte est défini dans un fichier de configuration indépendant qu’on trouve et qu’on crée dans le répertoire /etc/apache2/sites-available/, dans ce fichier figure déjà le premier hôte virtuel « 000-default. conf »
Pour cela copier le fichier du premier Virtualhost défini dans le répertoire /etc/apache/sites-available/ vers le fichier de chaque hôte, avec la commande suivante:
« cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-avalaible/site1.conf »
Éditer ce fichier et modifier les lignes suivantes : « DocumentRoot » et le « ServerName »
Après la configuration du fichier /etc/apache2/sites-available/site1.conf
Activer l’hôte virtuel en créant un lien entre le répertoire « /etc/apache2/sites-available » (sites disponibles) et le répertoire « /etc/apache2/sites-enabled » (sites activés).
Se déplacer dans le répertoire « /etc/apache2/sites-enabled » et taper la commande:
« a2ensite site1.conf »
vous devez avoir le message ci-dessous:
Redémarrer le service après toutes ces configurations « service apache2 restart« .
Test
Aller sur le navigateur et taper l’URL http://www.epbooktic.local, le navigateur nous redirige bien sur la page epbooktic.
Schéma réseau
Installation du serveur DHCP
Pré-requis
Avant toute installation on commence par une mise à jour des paquets du système avec la commande « apt update& upgrade »
Ensuite nous installons le paquet suivant :
« apt-get install isc-dhcp-server »
Le système ne parvient pas à trouver le serveur DHCP : c’est normal car il n’est pas configuré. Nous allons consulter l’état du service isc-dhcp-server afin de visualiser le nom complet du fichier à configuré, à l’aide de la commande: « systemctl isc-dhcp-server »
Configuration du serveur DHCP
1er fichier de configuration/etc/network/interfaces
Je vais tout d’abord configurer l’interface réseau de mon serveur avec l’adresse IP statique.
2ème fichier de configuration /etc/default/isc-dhcp-server
Ce fichier permet de définir l’interface réseau sur laquelle écoute le serveur.
Avant de configurer ce fichier nous allons tout d’abord le copier afin de faire une sauvegarde en cas de déstructuration de l’original.
Par la suite éditez ce fichier et modifiez le comme suit :
« nano /etc/default/isc-dhcp-server »
À la fin de ce fichier modifiez la ligne suivante :
INTERFACES= « enp0s3 »
3ème fichier de configuration /etc/dhcp/dhcpd.conf
Nous allons faire une copie de ce fichier à l’aide de la commande :
« cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.old »
Ce fichier nous indique la configuration IP, donc les informations suivantes :
Option domain-name: « pawoed.net » ; qui indique le suffixe DNS ou le nom de mon domaine
Option domain-name-servers: indique le ou les serveurs DNS
Option routers: indique l’adresse de ma passerelle
Option broadcast-address: l’adresse de broadcast du réseau
Default-lease-time 606: indique le bail par défaut
Max-lease-time 7200: indique le bail maximum, il est exprimé en secondes
Par la suite nous allons l’éditer et le configurer comme sur l’image ci-dessous :
Dans ce fichier, nous allons configurer autant de plage que de réseaux dont nous disposons. Après la configuration, démarrer le système à l’aide de la commande « systemctl start isc-dhcp-server »
Et à l’aide de la commande « systemctl status isc-dhcp-server » nous pouvons constater que le serveur DHCP est bien en marche
Test de validation
Nous allons démarrer une machine cliente Debian dans le même réseau que le serveur dhcp afin de tester le fonctionnement de notre serveur. Une fois démarrée, configurer sa carte réseau dans le fichier /etc/network/interfaces en dhcp, ensuite taper la commande suite dans le terminal :
« dhclient -1 –v enp0s3 »
Nous pouvons apercevoir les étapes d’une requête dhcp
la commande ci-dessous nous permet de voir l’adresse IP attribuée, le serveur qui l’a attribué ainsi que l’interface d’attribution.
"systemctl isc-dhcp-server"
Pour visualiser les baux alloués sur le serveur
« cat /var/lib/dhcp/dhcpd.leases »
Visualiser l’adresse IP obtenue par le client Debian
Visualiser le bail obtenu par le client
« cat /var/lib/dhcp/dhclient.leases »
Mise en place d’un agent relais DHCP sur le routeur
Fonctionnement d’un agent relais
L’Agent-Relais est un service qui permet de diffuser des plages d’adresses aux machines qui ne sont pas sur le même réseau que celui du serveur DHCP.
Il permet d’assurer le routage entre les réseaux.
En général il dispose de deux cartes réseau configurés avec des adresses IP statiques. L’une de ses cartes sera sur le même réseau que le serveur DHCP contrairement à l’autre qui ne le sera pas.
Le serveur DHCP aura donc en passerelle l’adresse IP de l’Agent-Relais.
Mais dans notre cas, nous allons effectuer des configurations au niveau du routeur comme suit:
Sur l’interface virtuelle du routeur connectée au vlan 50 et 60, nous allons renseigné l’adresse IP de notre serveur DHCP.
interface FastEthernet0/0.50
encapsulation dot1Q 50
ip helper-address 192.168.0.36
ip address 172.19.0.129 255.255.255.128
vlan 60
interface FastEthernet0/0.60
encapsulation dot1Q 60
ip helper-address 192.168.0.36
ip address 172.19.0.1 255.255.255.128
Test
Pour les tests, lancez une machine virtuelle dans le vlan 50 ou 60. Configurez la carte réseau en DHCP.
Vérifiez l’IP qu’elle a reçu, ça doit correspondre à la plage configurée plutôt dans ce réseau.
Matériels indispensables
Installations des paquet sur le serveur VPN et sur le client Debian
"apt-get install openssl"
"apt-get install openvpn"
Construction d’un tunnel
Afin de faire de voir comment une connexion VPN est initiée, nous allons tout d’abord utiliser les commandes suivantes au niveau du serveur et du client.
Ouvrir le terminal en tant que root et taper les commandes suivantes:
Au niveau du serveur: openvpn –dev tun0 –verb 5 –ifconfig 10.0.1.1 10.0.1.2 #10.0.1.1 étant l’adresse IP de l’interface virtuelle du serveur et 10.0.1.2 l’interface virtuelle du client.
Au niveau du client: openvpn –dev tun0 –verb 5 –ifconfig 10.0.1.2 10.0.1.1 –remote 172.16.2.3 # 172.16.2.3 étant l’adresse IP du serveur VPN.
Test
Nous allons par la suite ouvrir un deuxième terminal depuis le client et essayer de faire un ping de l’interface virtuelle du serveur VPN depuis l’interface eth0 et capturer par la même occasion la trame:
NB: les machines sont dans le VLAN 10
Nous ferons de même au niveau de l’interface tun0
Création de certificat avec Openssl
pour crée des certificats, nous allons commencer par construire un tunnel chiffré avec des certificats. Pour cela nous allons mettre en place les certificats de l’autorité de certification du client et du serveur.
Nous commençons par créer les répertoires suivants:
Ex: mkdir -p /apps/esy-rsa
par la suite nous allons copier le répertoire /usr/share/easy-rsa dans le dossier /apps/easy-rsa, à l’aide de la commande suivante: cp -R /usr/share/easy-rsa /apps/easy-rsa
Nous allons modifier les variables suivantes dans le fichier /apps/easy(rsa/vars
Par la suite, nous exportons les variables créées en appliquant ces valeurs à l’aide de la commande: « source vars » ( commande à taper en étant dans le répertoire /apps/easy-rsa )
Créer 3 groupes de certificat/clés privées: pour l’autorité, le serveur et le client ( chaque nouveau client devra en avoir un).
Création du certificat de l’autorité
Créer un certificat d’autorité de certification et avec sa clé à l’aide du script « ./build-ca« . Le certificat sera enregistré dans un fichier nommé « ca.crt » et la clé dans un fichier nommé « ca.key« , tous deux dans le dossier /apps/easy-rsa.
Dans le répertoire /apps/easy-rsa nous lançons le script « ./build-ca », c’est ce certificat qui validera tous les autres excepté celui du serveur. nous répondrons aux questions pour lesquelles nous n’avons pas donné les valeurs par défauts.
Générer des certificats
Comme nous avons vu plus haut, le serveur aura son propre certificat, signé par la CA que nous venons de créer. pour cela, nous allons utiliser le script « ./build-key-server ». le certificat sera enregistré dans le fichier nommé « server.crt » et le la clé dans un fichier nommé « server.key« , tous deux dans le dossier /apps/easy-rsa/:
Exécuté le script « ./build-key-server srv-vpn » (srv-vpn étant le nom du serveur VPN ).
NB: lancer à chaque fois le script « source vars » pour charger le fichier où se trouve les scripts.
Pendant la configuration laisser les valeurs par défauts aux paramètres qui nous sont demandés ( paramètres qui ont été modifiés au départ dans le fichier /apps/easy-rsa/vars )
Pour générer le certificat du client, nous utiliserons le script « build-key« . Le certificat sera enregistré dans un fichier du nom de votre choix, en .crt et la clé dans un fichier du nom de votre choix en .key, tous deux dans le dossier /apps/easy-rsa/ . Le certificat et la clé doivent être uniques pour chaque vient.
Exécutez le script « ./build-key Deb-client »
Création de la clé de session de DIFFIE-HELLMAN
Diffie-Hellman: est un protocole de cryptographie utilisé dans les échanges de clés. Cette clé sera utilisée par le serveur et le client pour communiquer en utilisant la cryptographie symétrique. Nous allons utiliser le script « build-db » prévu à cet effet, qui va générer une clé de chiffrement de 2048 bits dans le fichier « dh2048.pem » qui se trouve dans le dossier /apps/easy-rsa.
Exécutez le script ./bulid-db
Récapitulatif des fichiers crées
Configuration du serveur VPN
Afin de démarrer une instance de serveur VPN, le démon Openvpn vient chercher le répertoire /etc/openvpn, un fichier nommé « server.conf » qui lui permettra de savoir avec quelles options lancer le tunnel.
bous allons commencer par créer ce fichier dans le répertoire « /apps/openvpn/conffiles« .
Après la création nous allons configurer le fichier comme suit:
proto udp
dev tun
ca /apps/openvpn/keys/ca.crt
cert /apps/openvpn/keys/srv-vpn.crt
key /apps/openvpn/keyx/srv-vpn.key
dh /apps/openvpn/dh2048.pem
server 192.168.0.0 255.255.255.0
client-to-client #permet aux clients de se voir entre eux
#règle permettant une persistance de connexion et du cryptage et déterminant la durée de cette persistance
keepalive 10 120
pesrsist-key
persist-tun
# tls-auth ta.key 0 # à décommenter si on souhate n’autoriser les demandes de connexions qu’au possesseur d’une clé de cryptage spécifique. ceci augmente la sécurité et prévient les attaques Dos
cipher AES-128-CBC # algorithme de cryptage identique sur le client
# règles et lieu d’écriture des logs
status openvpn-status.log
log /apps/openvpn/log/openvpn.log
log /apps/openvpn/log/openvpn.log
verb # mode verbeux pour l'écriture des logs
Afin de tester la bonne configuration de ce fichier nous allons ouvrir 2 terminaux et lancer les commandes suivantes:
"openvpn server.conf"
« tail -f /apps/openvpn/openvpn.log » pour voir les logs, nous devons avoir une « Initialization Sequence Completed » dans les logs.
Au niveau du client, créer les mêmes répertoires que sur le serveur du moins celui-ci /apps/openvpn/keys
Nous allons transférer les certificats et les clés privées clients générés au niveau du serveur dans le répertoire /apps/openvpn/keys du client ( Si le client est une machine Linux). Pour cela on va utiliser la commande « scp CheminFichieràEnvoyer utilisateur@IPClient:/ » pour le copier dans le répertoire personnel ensuite dans le bon répertoire.
Ensuite dans le répertoire /apps/openvpn/keys
Dans le répertoire « /etc/openvpn« , nous allons créer le fichier « client.conf«
"touch client.conf"
Après la création du fichier le fichier comme suit:
Nous allons par la suite copier ce fichier dans le répertoire /apps/openvpn/conffiles/
Test
Nous allons redémarrer notre notre serveur avec la commande « openvpn server.conf »
Sur le client lancer la commande suivante: « openvpn client.conf« , nous observons bine « Initialization sequence Completed«
Si nous lançons un ping de l’interface virtuelle du serveur, nous pouvons constater que le client communique bien avec le serveur.
Préparation du serveur VPN
Nous allons placer notre client dans le Vlan du Greta qui est le vlan 70 (considéré comme le WAN)
afin que le client se trouvant dans le WAN puisse avoir accès au réseau interne, le serveur doit posséder la route lui indiquant de rédiriger les requêtes vers le réseau concerné. Nous ajoutons les routes (à la fin du fichier) vers notre réseau de destination de la manière suivante dans le fichier /apps/openvpn/conffiles/server.conf:
push "route 172.16.2.0 255.255.255.0"
push "route 172.19.0.0 255.255.255.128"
Liaison VPN avec le client extérieur à notre réseau
Dans le fichier de configuration du client qui se trouve coté WAN de notre pare-feu, nous allons modifier la configuration comme suit:
Dans ce fichier nous indiquons l’adresse IP du pare-feu côté WAN avec le port associé
Nating et filtrage
Afin d’activer le routage sur notre serveur VPN, nous éditons le fichier « /etc/sysctl.conf » et nous décommettons la ligne suivante: « net.ipv4.ip_forward=1«
Créer une règle au niveau du pare-feu, afin que le client soit redirigé vers notre VPN lorsqu’il fait une demande sur le port « 1194« .
Pour cela aller dans le menu Pare-feu/Nat et remplir les champs comme suit:
NB: ne pas oublier de décocher les cases ci-dessous au niveau du pare-feu dans le menu INTERFACE >WAN. Car de base l’interface WAN bloque le trafic des adresses IP qui sont réservés au réseaux privées et les boucles locales.
Il faut renseigner au niveau du routeur, le chemin pour joindre notre réseau virtuel avec la commande suivante:
"ip route 192.168.0.0 255.255.255.0 172.16.2.3"
Test
Nous redémarrons le service openvpn sur le serveur et le client, puis nous initions une connexion entre les 2 à l’aide des commandes: « openvpn server.conf« côté serveur et « openvpn client.conf » côté client.
Nous pouvons voir au niveau du serveur que pour aller sur les réseaux Data et WiFi, le client se trouvant dans le WAN va emprunter le réseau virtuel 192.168.0.0 via le 192.168.0.5.
Si nous lançons un ping depuis notre client se trouvant dans le réseau du Greta vers notre réseau LAN, on peut apercevoir qu’il communique bien avec notre réseau DATA
Un peu d’histoire
Aux origines de TCP/IP, étant donné que les réseaux étaient très peu étendus, que le nombre d’ordinateurs connectés à un même réseau était faible, les administrateurs réseau créaient des fichiers appelés tables de conversion manuelle. Ces tables de conversion manuelle étaient des fichiers séquentiels ( c’est-à-dire des fichiers accessibles les uns après les autres), généralement nommés hosts ou hosts.txt, associant sur chaque ligne l’adresse de la machine et le nom littéral associé, appelé nom d’hôte.
Introduction au DNS
Le problème avec le système précédent est qu’il nécessitait néanmoins la mise à jour manuelle des tables de tous les ordinateurs en cas d’ajout ou de modification d’un nom de machine. Ainsi, avec l’explosion de la taille des réseaux, et de leur interconnexion, il a fallu mettre en place un système de gestion des noms hiérarchisés et plus facilement administrable. Le système nommé Domain Name System (DNS), traduisez Système de nom de domaine, a été mis au point en novembre 1983 par Paul Mockapetris, puis révisé en 1987 dans les RFCs 1034 et 1035. Le DNS a fait l’objet depuis de nombreuses RFCs.
L’architecture de réseau TCP/IP sur lequel est basé internet et la plupart des réseaux locaux actuels, utilisent des adresses IP numériques du type 192.168.0.1. mais pour faciliter la lecture de ces adresses par l’homme, un système permet de transformer ces adresses en adresses plus lisibles comme www.google.com.
Pour effectuer cette opération, il est nécessaire d’utiliser un serveur DNS. Il fera donc la correspondance entre les adresses IP et les noms de domaines. Un serveur DNS s’occupe en général d’un domaine limité et s’occupe de transmettre les questions à d’autres serveurs s’il ne connait pas la réponse.
Les serveurs de noms
Les machines appelées serveurs de nom de domaine permettent d’établir la correspondance entre le nom de domaine et l’adresse IP des machines d’un réseau. Chaque domaine possède un serveur de noms de domaines, appelé « serveur de noms primaire » (primary domain name server), ainsi qu’un serveur de noms secondaire (secondary domaine nameserver), permettant de prendre le relais du serveur de noms primaire en cas d’indisponibilité.
Chaque serveur de nom est déclaré dans un serveur de nom de domaine de niveau immédiatement supérieur, ce qui permet implicitement une délégation d’autorité sur les domaines. Les serveurs correspondant aux domaines de plus haut niveau (TLD) sont appelés « serveurs de noms racine ». Il en existe treize, répartis sur la planète, possédant les noms « a.root-servers.net » à « m.root-servers.net ».
Un serveur de noms définit une zone, c’est-à-dire un ensemble de domaines sur lequel le serveur a autorité. Le système de noms de domaine est transparent pour l’utilisateur, néanmoins il ne faut pas oublier les points suivants :
Résolution de noms de domaine
Le mécanisme consistant à trouver l’adresse IP correspondant au nom d’un hôte est appelé « résolution de nom de domaine ». L’application permettant de réaliser cette opération (généralement intégrée au système d’exploitation) est appelée « résolveur »
Lorsqu’un utilisateur souhaite se connecter à un hôte connu par son nom de domaine (par exemple « www.google.fr »), celui-ci va interroger un serveur de noms défini dans sa configuration réseau. Chaque machine connectée au réseau possède en effet dans sa configuration les adresses IP de deux serveurs de noms de son fournisseur d’accès.
Une requête est ainsi envoyée au premier serveur de noms (appelé « serveur de nom primaire »). Si celui-ci possède l’enregistrement dans son cache, il l’envoie à l’application, dans le cas contraire il interroge un serveur racine (dans notre cas un serveur racine correspondant au TLD « .fr »). Le serveur de nom racine renvoie une liste de serveurs de noms faisant autorité sur le domaine (dans le cas présent les adresses IP des serveurs de noms primaire et secondaire de google.fr).
Le serveur de noms primaire faisant autorité sur le domaine va alors être interrogé et retourner l’enregistrement correspondant à l’hôte sur le domaine (dans notre cas www).
Pourquoi installer un serveur DNS
Pour au moins deux raisons :
Lorsqu’une demande de résolution de nom est demandée, le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS.
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
Si le résultat n’est pas trouvé dans la table hosts, le système recherche le serveur DNS indiqué dans le fichier « /etc/resolv.conf »
BIND (Berkley Internet Naming Daemon): c’est le programme utilisé pour faire la maintenance d’un serveur DNS sous linux.
Dans ce TP, nous allons configurer un serveur pour qu’il agisse en tant que serveur DNS primaire/Master (c’est un serveur principal qui fonctionne tout le temps)
Avant l’installation du serveur DNS, nous allons tout d’abord faire une mise à jour de la source list, au cas où il y’ aurai eu des modifications depuis sa dernière utilisation. Pour cela nous allons taper la commande: « apt-get update».
Pour l’installer il faut ouvrir son terminal en mode administrateur et taper la commande suivante : « apt-get install bind9 »
Une fois installer vérifier avec les commandes :
« ps –ax » ; qui permet de voir la liste des processus en cours d’exécution.
« netstat –atn » ; qui permet de voir si le port du DNS est ouvert.
Ce serveur DNS peut aussi être configuré en tant que DNS cache, toutefois pour des raisons de sécurité il n’est pas conseillé de le faire. Le rôle d’un serveur DNS cache est d’envoyer les requêtes aux autres serveurs DNS et de garder en cache les réponses. Ainsi la prochaine fois que la requête sera faite, la réponse sera récupérée directement depuis le cache. Cache qui est mise à jour de façon régulière.
Les fichiers suivants se trouvent dans les répertoires « /etc »
Fichier /etc/network/interfaces
L’éditer et le configurer en IP statique, pour éviter le changement d’adresse lorsqu’il est configuré dynamiquement. Ensuite le redémarrer afin qu’il prennent les changement en compte avec la commande : « /etc/init.d/networking restart ». Ce fichier décrit la configuration des interfaces réseau disponibles sur mon système d’exploitation.
Il sera configuré comme suit :
Fichier /etc/host.conf
Lorsqu’une demande de résolution de nom est demandée (c’est-à-dire lorsque l’utilisateur tape par exemple l’adresse www.google.fr), le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS Bind.
Fichier /etc/hosts
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
La première ligne est obligatoire pour que le système fonctionne bien même quand le réseau est désactivé. L’adresse 127.0.0.1 est toujours associé au nom localhost.
La ligne suivante peut être ajoutée manuellement pour faire la correspondance entre les adresses IP et des noms. C’est ce qui est fait en l’absence du serveur DNS
Fichier « /etc/resolv.conf
À défaut de connaitre l’IP de la machine via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans le fichier /etc/resolv.conf pour effectuer ses requêtes
Toutes les configurations DNS sont stockées dans le répertoire /etc/bind.
Fichier /etc/bind/named.conf
C’est le fichier de configuration principale qui contient la liste des zones ou domaine que le serveur DNS doit prendre en charge.
Fichier /etc/bind/named.conf.options
L’option « forwarders » permet de rediriger les requêtes qui ne sont pas résolues par notre serveur DNS local vers un autre serveur DNS distant, celui de notre FAI par exemple. Cela permet d’utiliser le cache d’un serveur déjà existant et donc d’obtenir des temps d’accès plus rapides. Si la requête DNS n’est pas résolue par le serveur DNS distant, alors la requête sera envoyée aux autres serveur DNS racine.
L’option « version none » permet de dissimuler la version de Bind. Car une personne malveillante peut vouloir récupérer la version de notre Bind afin de mener une attaque contre ce dernier s’il n’est pas à jour.
Si vous mettez en place votre DNS dans un environnement où il existe un proxy, désactiver les options: dnssec-validation no; et dnssec-enable no; afin de contourner le proxy.
Après ces modifications redémarrer le service avec la commande : « service bind9 restart
Fichier /etc/bind/named.conf.local
Ce fichier contient la configuration locale du serveur DNS, on y déclare les zones associées au domaine. On peut configurer autant de zones si nécessaire. Y sont indiqués les différents fichiers qui seront configurés plus bas: Le fichier /etc/bind/db.pawoed.org net et le fichier /etc/bind/db.pawoed.org.rev
Redémarrer le service et taper la commande « named-conf » pour vérifier s’il n’y a pas d’erreur dans le fichier de configuration.
Fichier /etc/bind/db.pawoed.org
Pour configurer ce fichier, le copier à partir du fichier local et le modifier, à l’aide de la commande : « cp /etc/bind/db.local /etc/bind/db.pawoed.org »
Après la configuration redémarrer le service avec la commande « service bind9 restart »
Fichier /etc/bind/db.rev
C’est le fichier où se trouve la configuration de la zone inverse. Pour le configurer, il faut le copier à partir du fichier de configuration de la zone inverse locale, avec la commande : « cp /etc/bind/db.127 /etc/bind/db.rev », ensuite l’éditer et le configurer comme suit :
Les commandes utiles
La commande ci-dessous vérifie le bon fonctionnement du service.
« named-checkconf –z »
Les commandes ci-dessous permettent de vérifier la validité des fichiers de zone :
« named-checkzone pawoed.org /etc/bind/db.pawoed.org»
La commande « nslookup » permet de vérifier la résolution de nom DNS. « nslookup dns.pawoed.org » j’ai bien la réponse de mon serveur qui me dit le nom de domaine « dns.pawoed.org » a bien l’adresse IP ‘192.168.0.12’.
La commande « host » permet de tester la résolution du nom et la résolution inverse.
La commande « dig » permet également de tester la résolution du nom et la résolution inverse, mais surtout d’interroger directement le serveur bind9 et obtenir de nombreuses autres informations. Le paramètre–x est obligatoire pour obtenir une réponse « ANSWER SECTION »
« dig dns.pawoed.org »
« dig –x 192.168.0.12 »
Si je fais : ping dns, le domaine pawoed.org, sera ajouté avant d’effectuer la demande de résolution du nom (la recherche du nom, portera donc sur dns.pawoed.org).
Configurer des fichiers suivants comme précédemment sur le serveur maitre :
Dans le fichier /etc/bind/named.conf.local du serveur primaire, renseigner l’adresse IP du serveur esclave comme ci-dessous :
