Installation & Configuration LTSP 5

Linux Terminal Server Project (LTSP) permet de démarrer des Clients Légers (CL) à partir d’un serveur LTSP. LTSP diminue les coûts matériels en permettant l’utilisation de machines obsolètes en tant que CL, conduisant à une administration réduite du fait que les frais généraux soient destinés au maintien du serveur LTSP. Lorsqu’un CL échoue, il peut simplement être remplacé sans perte de données ou réinstallation du système d’exploitation.

Le concept est le suivant :

  1. Le client léger ne prend en charge que les fonctions de base telles que l’affichage, le clavier, la souris et le son ;
  2. Le serveur gère l’ensemble des ressources nécessaire au fonctionnement du CL. Toutes les applications s’exécutent sur le serveur, et elles s’affichent simplement sur le CL.

Cette solution est avant-tout avantageuse pour les établissements scolaires qui n’ont pas les moyens financiers pour investir dans de nouveaux postes de travail. Il est plus simple d’investir 5000 € pour un serveur qui fera fonctionner 20 CL, que 10 000 € pour 20 nouveaux ordinateurs.

Ce tutoriel explique comment installer & configurer un serveur LTSP 5 sous Debian 7.11.0. Si vous utilisez une autre distribution (ou version), il pourrait y avoir quelques divergences de paramétrage.

Toutes les manipulations à venir seront à effectuer en tant que super-utilisateur de la machine.


Présentation

Principe de fonctionnement

2 éléments définissent un CL :

  1. Lors de son démarrage sur le réseau en PXE, il va monter par le réseau son environnement de travail présent sur le serveur LTSP : il n’a pas besoin de disque dur ;
  2. Il peut exécuter des applications en utilisant ses propres ressources ou celles du serveur d’application.

L’identification des utilisateurs, les communications sont sécurisées par le protocole SSH, qui est géré par le gestionnaire d’affichage LDM spécialement créé pour LTSP.

Un serveur LTSP regroupe les services suivants :

  • DHCP pour fournir la configuration IP, le chemin vers l’environnement à monter, l’adresse IP du serveur TFTP et le chemin du chargeur d’amorçage PXE ;
  • TFTP pour réaliser le boot PXE des clients légers (récupérer le noyau linux) ;
  • NFS pour mettre à disposition l’environnement de travail, c’est à dire la racine / montée par les CL via le réseau lors de leur démarrage ;
  • SSH pour sécuriser l’identification des utilisateurs et éventuellement les échanges graphiques entre le serveur et les clients légers ;
  • LDM pour lancer les applications et gérer la liaison entre le serveur LTSP et ses clients légers. Dans notre structure ce service sera installé sur le serveur d’application.

Remarque : Il est possible d’utiliser NBD à la place de NFS : le boot du CL est censé être plus rapide (image compressée) et NBD devrait économiser de la bande passante sur le réseau. Par contre, il est nécessaire à chaque modification de l’environnement du client léger de reconstruire l’image compressée.

Voici un document détaillant simplement le démarrage d’un CL : Démarrage CL LTSP 5.

Types de client léger

Il existe trois types d’environnements différents pour les clients légers :

  • L’environnement léger

Le CL lance une session X sur le serveur LTSP et tout est exécuté sur celui-ci puis « déporté » sur l’écran du CL dans un tunnel X : le client se comporte alors comme un terminal X et a besoin de peu de ressources (128 à 256 Mo de RAM).

  • L’environnement hybride (LOCAL-APP)

Il s’agit d’un environnement léger dans lequel certaines applications sont exécutées avec les ressources locales du CL  et d’autres sur le serveur LTSP. 
Attention : il faut que le CL dispose de suffisamment de RAM. Si vous exécutez un logiciel qui demande 50 Mo de stockage en RAM et que votre poste n’a que 32Mo, votre CL crashera. 

  • L’environnement lourd (FAT CLIENT)

Le CL lance une session X de son environnement et exécute les applications avec ses propres ressources locales : le serveur LTSP est alors seulement utilisé pour identifier l’utilisateur et mettre à disposition des CL leur environnement de travail. Cette configuration permet d’alléger le serveur d’application mais nécessite des CL plus performants.
Il est également possible de créer plusieurs environnements sur un même serveur LTSP et de les assigner à des groupes de CL.

L’environnement chroot

Précédemment, j’ai parlé d’environnement sans le définir. Pour transformer un ordinateur en CL, il faut exécuter une mini version de GNU/Linux sur le poste de travail. Elle doit être démarrée sur le réseau, car le poste de travail n’a pas obligatoirement de disque dur (et donc on ne peut pas démarrer une version complète).
Cette mini installation est stockée sur le serveur. Elle est personnalisée afin de pouvoir démarrer sur le réseau et s’appelle un environnement chroot (environnement racine).
La raison pour laquelle elle s’appelle un environnement chroot est que, sur le serveur, on va créer un (ou plusieurs) nouvel environnement GNU/Linux dans le répertoire /opt/ltsp/Nom_Du_Chroot (un répertoire par environnement, avec un nom différent).  Dans ce répertoire vous retrouvez une arborescente identique à une machine GNU/Linux de base (/etc, /home, /bin…).
En utilisant la commande chroot vous pourrez changer de répertoire racine pour gérer vos environnements, afin d’y aller vos logiciels ou encore faire des mises à jour.

Visualisation de l’objectif

L’objectif, est de mettre en service au moins 3 clients légers (CL), qui auront accès à un environnement de bureau exploitable sous Debian GNOME 3.

Pour cela nous allons mettre en service un serveur de démarrage qui va fournir aux CL les informations et fichiers nécessaires à leur démarrage sur le réseau. De plus, un serveur d’application pour contenir les ressources, les logiciels et le système d’exploitation qu’utiliseront les CL, sera requis.

Petite précision, il est possible de créer un unique serveur indépendant, qui va contenir tous les composants logiciels et matériels nécessaires à la mise en service d’un réseau LTSP, ou bien de séparer la partie démarrage sur le réseau et la partie gestion des ressources.

Ici nous allons séparer les 2 parties en mettant en place un serveur de démarrage avec LTSP, TFTP, NFS et DHCP et un serveur d’application avec un (ou plusieurs) environnement(s) de travail dans lequel seront installés les applications qu’utiliseront les utilisateurs.

Voici un petit schéma très simple pour vous donner une idée  :

Schéma Partie 1.png

Configuration matérielle des CL et du serveur

Les informations ci-dessous sont extraites du manuel LTSP et n’ont pas été testées.

Configuration pour environnement léger

CPU : au moins 533 Mhz

Mémoire : 256 Mo

Carte réseau : 100 Mbs (usage normal de 0,5 à 2 mbit mais pic possible à 70 Mbs si consultation de contenu multimédia sur le serveur LTSP)

Configuration pour environnement lourd

La configuration du serveur LTSP en Fat Client  (FC) va nécessiter moins de ressources du serveur. Par contre, les ressources réseaux sont sollicitées différemment :

  • Pour les CL, c’est le déport d’affichage graphique qui circule sur le réseau.
  • Pour les FC, à chaque fois qu’un utilisateur lance une application, cette
    application est chargée via le réseau dans la RAM du FC puis exécutée par son
    processeur. Plus la quantité de RAM demandée par l’application sera élevée, plus le temps nécessaire au lancement de l’application sera élevé.

En claire, le lancement d’une application en FC peut être plus long qu’en environnement léger (par contre, une fois chargée, l’utilisation de cette application doit être plus rapide qu’en environnement léger).

C’est pourquoi il est préférable d’utiliser le service NBD (car les fichiers sont compressés et donc moins
volumineux) plutôt que NFS, lorsque les CL sont configurés en FC.

Configuration pour le serveur d’application

Mémoire

Mémoire du serveur d’application se calcule de la manière suivante :

  • 256 + (192 * Nb_CL) MB

Exemple : pour gérer 20 CLs, au moins 4 Go de mémoire est nécessaire (Si les clients ont un usage graphique gourmand, doublez cette valeur précédente).

Si vous n’avez pas assez de mémoire dans votre serveur, vous constaterez que votre serveur devra utiliser le disque dur pour créer de la mémoire virtuelle. Un disque dur étant beaucoup plus lents, vous remarquerez des lenteurs.

Processeur

Le processeur dont vous avez besoin dépend entièrement des programmes que vous envisagez d’utiliser. Les jeux interactifs nécessiteront beaucoup plus de puissance de calcul qu’un logiciel de traitement de texte. Si vous envisagez d’utiliser des programmes comme Java ou Flash player dans votre navigateur Web, ceux-ci peuvent consommer beaucoup de puissance de traitement. Pour un modèle mixte, c’est-à-dire certaines personnes qui jouent à TuxMath, quelques personnes naviguant sur le Web,
et d’autres personnes qui entrent dans OpenOffice, un processeur de 2GHz ou mieux devrait être en mesure de gérer efficacement 20 personnes avec quelques retards mineurs. Un processeur 3GHz serait mieux.

Pour les réseaux plus importants, passer à un SMP (Symmetric Multi Processing) ou à un serveur à processeurs multiples peut être avantageux.

Rappelez-vous, si vous avez besoin de servir un grand nombre de clients, il vaut la peine de configurer plusieurs LTSP serveurs, chacun manipulant certains des terminaux.

Stockage

Il est conseillé d’utiliser du RAID. En plus de préserver vos données lorsqu’un disque unique échoue, il
améliore les performances (en particulier les performances lues, qui est le type d’accès au fichier le plus courant). Pour les personnes à faible budget, la configuration d’un RAID 1, avec 2 disques SATA avec NCQ fournira bons résultats. Si vous disposez d’un budget plus important et d’un réseau plus grand, configurez votre serveur avec du RAID 10.

Réseau

Si vous avez plus de 20 utilisateurs, il est recommandé d’utiliser une connexion Ethernet de l’ordre du Gigabit. Au moins 1 Gibatbit est nécessaire (surtout pour le multimédia).


Installation des serveurs

Les méthodes

Il existe 2 méthodes d’installation de LTSP. La première est destinée à séparer les éléments d’une infrastructure LTSP. Quant à la deuxième, elle permet de centraliser sur une seule machine tous les services nécessaires au fonctionnement d’une infrastructure LTSP.

  • Méthode élément par élément

Cette méthode regroupe 4 paquets principaux :

ltsp-server

Ce paquet est à installer sur le serveur de démarrage. Il permet d’installer un serveur LTSP + un serveur TFTP + un serveur NFS + un client OpenSSH.

ldm-server

Ce paquet est à installer sur le serveur d’application. Il permet d’installer un serveur LDM + un serveur OpenSSH.

isc-server-dhcp [Facultatif]

Ce paquet s’installe sur un serveur dédié ou non (il peut être installé sur le serveur de démarrage). Il permet d’installer un serveur DHCP. Si vous possédez déjà un serveur DHCP (linux), alors vous n’êtes pas obligé d’en installer un autre.

ltsp-docs [Facultatif]

Ce paquet s’installe sur le serveur de démarrage. Il permet d’obtenir la documentation de LTSP.

  • Méthode centralisée

Cette méthode de nécessite un seul paquet : ltsp-server-standalone

Il installe ltsp-server + ltsp-docs + ldm-server + isc-server-dhcp + openssh-serveur + openssh-client

Voici un tableau résumant ce que nous venons de voir :

Capture.PNG

Dans notre cas, nous voulons séparer le serveur d’application du serveur de démarrage. Nous allons donc utiliser la méthode élément par élément.

Installer le serveur de démarrage

Exécutez la commande suivante :

apt-get install ltsp-server ltsp-docs isc-dhcp-server

Le serveur DHCP retournera une erreur lors de la tentative de démarrage : ceci est normal car il n’est pas encore configuré.

Installer le serveur d’application

Exécutez la commande suivante :

apt-get install ldm-server

Une fois le serveur installé, vous pouvez déjà installer toutes les applications (apt-get install …) de bureau qui seront utilisées par les CLs (par exemple, LibreOffice).

Configuration du serveur de démarrage

Déclarer l’export NFS

Les CLs auront besoin de monter un environnement (racine /), stocké dans le répertoire /opt/ltsp/, grâce au serveur NFS. Pour qu’il puisse effectuer le montage il faut d’abord autoriser l’accès dans fichier /etc/exports.

Éditez le fichier exports :

nano /etc/exports

Ajoutez la lignes suivante à la fin du fichier :

/opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

/opt/ltsp : dossier sur lequel s’applique les autorisations ;

* : représente « tout le monde » pour qui s’applique les instructions ;

Pour obtenir plus d’informations sur les options, exécutez la commande suivante :

man exports

Redémarrez le service nfs-kernel-server :

service nfs-kernel-server restart

Construire un environnement chroot

Les commandes

Pour construire l’environnement des CLs sur le serveur LTSP, on utilise la commande ltsp-build-client. Si vous souhaitez avoir une liste détaillée des options possibles, exécutez la commande suivante :

ltsp-build-client --extra-help

Pour un environnement léger ou hybride, la commande est la suivante :

ltsp-build-client --arch i386 --chroot Nom_Du_Chroot --prompt-rootpass
  • –arch i386 : Spécifie que l’environnement doit être en 32 bits ;
  • -chroot Nom_Du_Chroot : Spécifie le nom du chroot (de la racine de l’environnement client) ;
  • –prompt-rootpass : Spécifie qu’il faut demander la saisie d’un mot de passe super-utilisateur de l’environnement durant la construction de celui-ci.

Pour un environnement lourd, la commande est la suivante : 

ltsp-build-client --arch i386 --chroot Nom_Du_Chroot --fat-client-desktop gnome-desktop-environment --promptrootpass
  • –fat-client-desktop : Spécifie qu’on exécute toutes les applications, ou presque, localement ;
  • gnome-desktop-environment : Spécifie qu’il faut utiliser l’environnement de bureau GNOME.

Dans le cas de l’environnement hybride ou lourd, les applications doivent directement être installées dans l’environnement chroot, pour être exécutées avec les ressources locales du CL.

Pour cela, il vous faut à la racine de cet environnement, à l’aide de la commande suivante :

ltsp-chroot --mount-dev --mount-proc --arch Nom_Du_Chroot

Une fois dans l’environnement, vous pouvez installer vos applications de la même manière que sur une machine normale, en utilisant la commande apt-get install. Par exemple, pour Firefox :

apt-get install firefox-esr

Pour valider les modifications et sortir de l’environnement, utilisez la commande suivante :

exit

Il est très important de quitter votre environnement de cette façon, sinon vous vous risquez à un Kernel panic l’or du démarrage d’un CL ;

Attention : Dans le cas de ces 2 environnementd, le mode hybride ou fatclient, que nous verrons plus tard devra, être activé dans le fichier /opt/ltsp/hybridclient/etc/lts.cfg.

Configurer le serveur DHCP

Pré-requis

Pour que le serveur DHCP fonctionne il faut lui indiquer dans sa liste d’interfaces réseau (eth0, eth1…), située dans le fichier /etc/default/isc-dhcp-server, le ou les noms des interfaces connectées au réseau LTSP.

Comme vous avez pu le voir sur le schéma réseau plus haut, une interface du serveur de démarrage est connectée au switch qui relie tous les éléments du réseau LTSP, c’est donc le nom de cette interface qu’il faudra renseigner.

Éditez le fichier isc-dhcp-server :

nano /etc/default/isc-dhcp-server

Repérez la ligne suivante :

INTERFACES=""

Renseignez entre les guillemets le ou les noms des interfaces réseau que vous utilisez pour vous relier au réseau LTSP ;

Maintenant, il nous faut configurer le fichier /etc/dhcp/dhcpd.conf, qui va contenir toute la configuration du
serveur DHCP. 
La configuration du fichier dépendra du nombre d’environnements que vous voulez créer.

Sauvegardez le fichier par défaut dhcpd.conf :

mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.save

Configuration pour un seul environnement

Créez un nouveau fichier dhcpd.conf :

nano /etc/dhcp/dhcpd.conf

Configurez le fichier de la même manière que ci-dessous (à adapter), en retirant les commentaires :

authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {            # Adresse sous-réseau
     range 192.168.1.50 192.168.1.60;                 # Étendue DHCP
     option domain-name "example.com";                # Nom du serveur DNS
     option domain-name-servers 192.168.1.1;          # Adresse du serveur DNS
     option broadcast-address 192.168.1.255;          # Adresse de broadcast
     option routers 192.168.1.1;                      # Adresse de la passerelle
     next-server 192.168.1.253;                       # Adresse du serveur TFTP
     option subnet-mask 255.255.255.0;                # Adresse masque du réseau
     option root-path "/opt/ltsp/hybridclient";       # chemin de l'environnement hybride
     if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
          filename "/ltsp/hybridclient/pxelinux.0";   # chemin du chargeur d'amorçage PXE
     } else {
          filename "/ltsp/hybridclient/nbi.img";      # chemin charg. d'amorç. Etherboot
     }
}

Enregistrez les modifications ;

Redémarrez le service isc-dhcp-server :

service isc-dhcp-server restart

Configuration pour plusieurs environnements

A chaque environnement il faudra définir un groupe dans lequel sera renseigné les CL ayant accès à tel
environnement. La configuration (principale) d’un groupe sera la même quelque soit l’environnement.

Créez un nouveau fichier dhcpd.conf :

nano /etc/dhcp/dhcpd.conf

Configurez le fichier de la même manière que ci-dessous (à adapter), en retirant les commentaires :

authoritative;
     subnet 192.168.1.0 netmask 255.255.255.0 {     # Adresse sous-réseau
     option broadcast-address 192.168.1.255;        # Adresse de broadcast
     range 192.168.1.50 192.168.1.60;               # Étendue DHCP4
     option subnet-mask 255.255.255.0;              # Addresse masque du réseau
     option routers 192.168.1.1;                    # Adresse de la passerelle
     option domain-name-servers 192.168.1.1;        # Adresse du serveur DNS
     option domain-name "example.com";              # Nom du serveur DNS
     next-server 192.168.1.253;                     # Adresse IP du serveur TFTP
}

Configurez ensuite les groupes (dans le sous-réseau) de la manière suivante, en retirant les commentaires :

Group {
     # next-server 192.168.1.253;                          # @IP du serveur TFTP si plusieurs
     option root-path "/opt/ltsp/hybridclient";            # Chemin de l'environnement
     if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
          filename "/ltsp/hybridclient/pxelinux.0";        # Chemin du charg. d'amorç. PXE
     } else {
          filename "/ltsp/hybridclient/nbi.img";           # chemin charg. d'amorç. Etherboot
     }
# On définit ensuite chaque CL dans un  host
# Client léger N°1
     host Nom_CL {
          hardware ethernet 00:fc:b9:15:13:gh;             # @MAC du CL
          # fixed-address 192.168.1.50;                    # @IP du CL [Facultatif]
     }
# (...)
}

Vous pouvez assigner des adresses IP fixes (fixed-address) aux hôtes ou encore, si vous avez plusieurs serveurs TFTP, indiquer l’adresse des serveurs TFTP (next-server) en fonction du groupe ;

Enregistrez les modifications ;

Redémarrez le service isc-dhcp-server :

service isc-dhcp-server restart

Configurer l’environnement

Nous allons configurer le fichier /opt/ltsp/Nom_Du_Chroot/etc/lts.cfg en renseignant l’adresse IP du serveur
d’application, en activant le mode hybride ou fatclient si besoin et en configurant quelques
options supplémentaires.

Éditez le fichier lts.conf :

nano /opt/ltsp/Nom_Du_Chroot/etc/lts.conf

Renseignez les options suivantes, en retirant les commentaires :

[default]                                       # Section par défaut
     LTSP_CONFIG=True                           # Activer la configuration
     NBD_SWAP=True                              # Utiliser le swap
     LDM_LANGUAGE=fr_FR.UTF-8                   # Configurer langue française
     XKBLAYOUT=fr                               # Régler le clavier en français
     LDM_SERVER="192.168.1.253"                 # Indiquer @IP du serveur d'application
     SOUND=True                                 # Activer le son
     LOCALDEV=True                              # Activer le montage de périphérique
     X_NUMLOCK=True                             # Activer le pavé numérique
     CONFIGURE_X=False                          # Désactiver la conf. du serveur d'app.
     SYSLOG_HOST=SERVER                         # Enregistrer logs sur serv. démarrage
# Activer l'environnement hybride
     # LOCAL_APPS=True                          # Activer le mode hybride
     # LOCAL_APPS_MENU=True                     # Autorise l'exécution des applications
     # LOCAL_APPS_MENU_ITEMS="firefox-esr"      # Liste des applications
# Ou, activer l'environnement fatclient
     # LTSP_FATCLIENT=True                      # Activer le mode fatclient
#  Vous pouvez également assigner une configuration spécifique à un CL, en créant une
#  nouvelle section avec son adresse MAC
# [00:01:GE:AE:45:31]                           # Section du CL 00:01:GE:AE:45:31
     # LTSP_CONFIG=True                         # Activer la configuration
     # LDM_LANGUAGE=fr_FR.UTF-8                 # Langue française
     # XKBLAYOUT=fr                             # Régler le clavier français

Pour plus d’options, exécutez la commande suivante :

man lts.conf

Enregistrez les modifications ;

Renseigner l’option LOCALDEV=True n’est pas suffisant pour pouvoir monter des périphériques, telle qu’une
clé USB. En effet, l’utilisateur connectait doit également faire partie du groupe fuse en rapport au logiciel
fuse qui permet, entre autres, de monter un système de fichier. Celui-ci a été installé sur le serveur
d’application en même temps que le paquet ldm-server.

Pour ajouter un utilisateur au groupe fuse, utilisez la commande suivante :

adduser Nom_Utilisateur fuse

Récupérer la clé publique du serveur d’application

Un CL ne pourra s’identifier sur un serveur d’application de manière sécurisée que s’il possède dans son environnement la clé publique de celui-ci.

Récupérez la clé publique du serveur d’application :

ltsp-update-sshkeys @IP_Serveur_Apps

La clé est sauvegardée dans le fichier /etc/ltsp/ssh_known_hosts.auto ;

Mettez à jour les clés publiques de(s) l’environnement(s) :

ltsp-update-sshkeys

Mise en route des clients légers

Si vos clients ont plusieurs cartes réseaux, désactivez-les toutes, sauf la carte utilisée pour le boot réseau. Si vous laissez activé une carte réseau inutilisée, celle-ci tentera également de booter sur le réseau et empêchera le démarrage du CL.

La configuration de l’infrastructure est maintenant terminée, vous pouvez démarrer vos clients. Vous devriez accéder à l’écran d’ouverture de session graphique ressemblant à ceci :

02.PNG

Si c’est le cas, alors cela signifie que votre client a bien récupéré son environnement et qu’il a démarré le
gestionnaire d’affiche LDM.

Maintenant, connectez-vous à l’aide d’un utilisateur du serveur d’application. Vous devriez accéder à une session utilisateur :
03.PNG Si ça ne fonctionne pas et que vous avez en retour un message du type Not found @IP, alors vérifiez que vous avez correctement renseigné l’adresse IP du serveur d’application dans le fichier lts.conf et que celui-ci soit bien connecté au réseau.

Ou encore, si vous avez un message du type Connection refused, assurez de bien avoir récupéré la clé
publique du serveur d’application et d’avoir mis à jour l’environnement client.


Ce tutoriel est terminé. Prochainement je vous montrerez comment assurer la continuité de service et la tolérance de panne.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Restauration d'une image disque

Clonezilla est un programme de partitionnement et de clonage de disques/partitions. Il permet de créer des images système pouvant être utilisées pour du déploiement, pour servir de sauvegarde disque/partition ou encore pour être restaurées sur un disque/partition en cas de problème.

Ce tutoriel est la suite sur celui concernant la création d’une image disque et il explique comment restaurer une image disque à l’aide de Clonezilla 2.5.0.5.  Si vous utilisez une autre version, il pourrait y avoir quelques divergences de paramétrage.

Clonezilla doit être installé sur une clé usb ou un CD. Vous devrez ensuite booter sur le CD/USB pour accéder à l’interface Clonezilla.


Insérez le CD (ou la clé usb) Clonezilla dans la machine et bootez dessus ;

00

Sélectionnez l’option Clonezilla live (Default settings, VGA 800×600) ;

02

Sélectionnez le langage fr_FR.UTF-8 French | Français ;

03

Sélectionnez l’option Ne pas modifier le codage clavier ;

07

Sélectionnez l’option Start_Clonezilla Démarrage de Clonezilla ;

08

Sélectionnez l’option device-image     disque/partition vers/depuis image ;

09

Sélectionnez l’option local_dev      Monter un périphérique local (p.ex : disque dur, clef USB) ;

10

Insérez le périphérique sur lequel est stockée l’image système à restaurer, attendez quelques secondes (le temps qu’il soit détecté), puis appuyez sur la touche Entrée ;

11

Le fichier /dev/sda correspond au disque local, tandis que le fichier /dev/sdb correspond au périphérique externe qui contient l’image système. Si la machine à plusieurs disques locaux, comme par exemple 3, le nom du fichier du périphérique sera sdd (a, b, c, d…). Appuyez sur les touches Ctrl + C pour continuer ;

12

Sélectionnez le périphérique externe où est stockée l’image système (ici sdb1 : 1 partition n°1, qui est la seule sur ce périphérique) ;

13

Sélectionnez le dossier (dans le périphérique externe) où se trouve l’image système (ICI IMAGES) ;

11

Appuyez sur la touche Tabulation 2 fois pour placer votre curseur sur l’option <Done>, puis appuyez sur la touche Entrée ;

16

Sélectionnez l’option Beginner    Mode débutant : Accepter les options par défaut ;

14

Sélectionnez l’option restoredisk           Restaurer_une_image_vers_le_disque_local ;

15

Sélectionnez l’image à restaurer (ici il n’y en a que 1) ;

16

Sélectionnez le disque local à restaurer (ici il n’y a que 1 disque local) ;

17

Sélectionnez l’option Oui, vérifier l’image avant de restaurer ;

18

Sélectionnez l’option -p reboot      Redémarrer ;

19

Appuyez sur la touche Entrée ;

20

La vérification de l’image démarre ;

21

Répondez y à la question « Êtes-vous sûr de vouloir continuer ? » ;

22

Répondez à nouveau y à la question « Êtes-vous sûr de vouloir continuer ? » ;

23

La restauration de l’image démarre ;

24

Appuyez sur la touche Entrée ;

25.PNG

L’image système a été restaurée.


Ce tutoriel est terminé. Si vous avez des problèmes, où besoin d’explications, n’hésitez pas à m’avertir.

Création d'une image disque

Clonezilla est un programme de partitionnement et de clonage de disques/partitions. Il permet de créer des images système pouvant être utilisées pour du déploiement, pour servir de sauvegarde disque/partition ou encore pour être restaurées sur un disque/partition en cas de problème.

Ce tutoriel explique comment créer une image système d’un disque dur entier (toutes partitions comprises) à l’aide de Clonezilla 2.5.0.5.  Si vous utilisez une autre version, il pourrait y avoir quelques divergences de paramétrage.

Clonezilla doit être installé sur une clé usb ou un CD. Vous devrez ensuite booter sur le CD/USB pour accéder à l’interface Clonezilla.


Insérez le CD (ou la clé usb) Clonezilla dans la machine et bootez dessus ;

00

Sélectionnez l’option Clonezilla live (Default settings, VGA 800×600) ;

02

Sélectionnez le langage fr_FR.UTF-8 French | Français ;

03

Sélectionnez l’option Ne pas modifier le codage clavier ;

07

Sélectionnez l’option Start_Clonezilla Démarrage de Clonezilla ;

08

Sélectionnez l’option device-image     disque/partition vers/depuis image ;

09

Sélectionnez l’option local_dev      Monter un périphérique local (p.ex : disque dur, clef USB) ;

10

Insérez le périphérique sur lequel créer l’image système du disque local, attendez quelques secondes (le temps qu’il soit détecté), puis appuyez sur la touche Entrée ;

11
 

Le fichier /dev/sda correspond au disque local, tandis que le fichier /dev/sdb correspond au périphérique externe qui va contenir l’image système du disque local. Si la machine à plusieurs disques locaux, comme par exemple 3, le nom du fichier du périphérique sera sdd (a, b, c, d…). Appuyez sur les touches Ctrl + C pour continuer ;

12

Sélectionnez le périphérique externe où sera créée l’image système (ici sdb1 : 1 partition n°1, qui est la seule sur ce périphérique) ;

13

Sélectionnez le dossier (dans le périphérique externe) destination de l’image système (ICI IMAGES) ;

14

Appuyez sur la touche Tabulation 2 fois pour placer votre curseur sur l’option <Done>, puis appuyez sur la touche Entrée ;

16

Sélectionnez l’option Beginner    Mode débutant : Accepter les options par défaut ;

17

Sélectionnez l’option save disk           Sauvegarder_le_disque_local_dans_une_image ;

18

Renseignez le nom de l’image système à créer ;

19

Sélectionnez le disque local à sauvegarder (ici il n’y a que 1 disque local : sda) ;

20

Sélectionnez l’option -sfsck      Ne pas vérifier/réparer le système de fichier ;

23

Sélectionnez l’option -p poweroff    Arrêter ;

24

Appuyez sur la touche Entrée ;

25

Répondez y à la question « Etes-vous sûr de vouloir continuer ? » ;

26

Le création de l’image démarre ;

27

Une fois terminée, vous retrouvez l’image dans le périphérique externe.


Ce tutoriel est terminé. Prochainement je vais vous montrer comment restaurer une image système à l’aide de Clonezilla.

Si vous avez des problèmes, où besoin d’explications, n’hésitez pas à m’avertir.

Installation & Configuration OpenVPN

OpenVPN est un logiciel libre de création de réseau privé virtuel (VPN). Il permet à 2 hôtes (ou réseaux) distants de communiquer entre eux de manière sécurisée grâce à la cryptographie asymétrique, d’un certificat électronique ou d’un couple de noms d’utilisateur/mot de passe.

Ce tutoriel explique comment installer & configurer un serveur OpenVPN 2.3.4 sous Debian 8.6.0.
Si vous utilisez une autre distribution (ou version), il pourrait y avoir quelques divergences de paramétrage.

Toutes les manipulations à venir seront à effectuer en tant que super-utilisateur de la machine.


Avant de commencer, quelques expliquons s’imposent pour comprendre l’avantage de l’utilisation de certificats électroniques.

Cryptographie asymétrique

L’utilisation de certificat électronique fonctionne avec la cryptographie asymétrique. Elle-même fonctionne avec une clé publique (connue de tous) et une clé privée (connue seulement de son propriétaire). La clé publique permet de chiffrer les messages tandis que la clé privée permet de les déchiffrer (là où la cryptographie symétrique utilise une unique clé pour chiffrer et déchiffrer).

Fonctionnement

Avec cette méthode, le destinataire des messages doit fournir sa clé publique à l’expéditeur qui l’utilisera pour crypter ses messages. Etant donné que le destinataire possède la clé privé, seul lui pourra décrypter le message. Les 2 acteurs peuvent être un expéditeur et un destinataire, chacun doit juste avoir sa propre pair de clés. Pour exemple :

Fonctionnement cryptographie asymétrique

Point faible

Le point faible de ce système se situe au niveau de la clé publique que reçoit l’expéditeur. Comment être sûr que la clé publique récupérée soit bien celle du destinataire du message et non celle d’un pirate  qui aurait intercepté les communications ? Après tout, supposons qu’Alice ait publiée sur son site internet sa clé publique (ou dans un annuaire) et que le pirate accède à celui-ci, puis qu’il remplace la clé d’Alice par la sienne. Les personnes qui iront chercher la clé pour envoyer des messages en Alice et le pirate n’aura plus qu’à écouter les communications qu’il pourra décrypter. Pour exemple :

Point faible cryptographie asymétrique

La solution à ce problème n’est d’autre que l’utilisation du certificat électronique.

Le certificat électronique

Le certificat électronique est en quelque sorte la carte d’identité de la clé publique. C’est grâce à lui que nous seront en mesure de savoir si la clé et celle du bon destinataire. Le certificat est composé d’une multitude d’informations dont la clé publique de son propriétaire et d’une signature électronique. C’est la signature qui permet de garantir l’authenticité du destinataire et elle est créée par une autorité de certification (CA) qui est la garante de l’authenticité de la signature.

La CA possède son propre certificat d’autorité de certification et sa clé privée qu’elle utilise pour signer les certificat de ses clients.

Dans le cadre de OpenVPN, nous utiliserons des certificats au format X.509 avec les informations suivante :

Version du certificat

Numéro de série

Algorithme de signature utilisé

Nom de domaine de l’autorité de certification

Période de validité du certificat

Nom de domaine du propriétaire du certificat

Clé publique du propriétaire

ID de l’autorité de certification (optionnel pour X.509v2)

ID du propriétaire du certificat (optionnel pour X.509v2)

Extensions (optionnel, à partir de X.509v3)

Signature électronique

Types de certificats

Il existe 2 types de certificats, selon l’origine de la signature :

  • Certificat auto-signé : certificat signé sois-même à l’aide de sa propre CA. C’est le cas d’OpenVPN qui permet donc de créer une CA et de générer des certificats auto-signés. Cette solution est adaptée aux réseaux d’entreprises.

  • Certificat signé par une entité de certification : certificat signé par une entité tiers. Cette solution est obligatoire pour les échanges sur l’internet.

Signature électronique

La signature électronique est créée à partir des informations contenue dans le certificat et la clé privée du CA. Elle s’effectue en 2 étapes :

    1. Application d’une fonction de hachage : condenser les informations du certificat (le résultat est appelé condensat).
  1. Cryptage du condensat : crypter le condensat  à l’aide de la clé privée du CA.

Une fois le condensat crypté, on appel le résultat « signature électronique ».

Voyons maintenant l’utilité de ces 2 étapes…

Débutons avec la première, le hachage, qui permet de contrôler l’intégrité des données. En appliquant une fonction de hachage sur les données on obtient un condensat unique. Quand le client voudra envoyer des données, il devra envoyer le condensat et les données écrites en clair. Ensuite, le serveur va à son tour appliquer la même fonction de hachage (indiqué parmi les informations) sur les données écrites en clair reçu du client et il va comparer le condensat obtenu avec le condensat envoyé par le client. Si le condensat du message crypté par le serveur est différent de celui envoyé par le client, alors le message a été falsifié.

Puis, la seconde, le cryptage du condensat, qui permet d’assurer la provenance des données. Une clé privée (celle du CA) est utilisée pour crypter le condensat tandis que la clé publique associée (celle du CA : que tout le monde possède) permet d’obtenir le condensat original à partir de celui crypté. De ce fait, si le condensat obtenu à l’aide de la clé publique est identique à celui reçu par le client, alors les données sont authentiques.

Une autre méthode pour contrôler la validité d’un certificat est de stocker tous les certificats des clients autorisés sur le serveur afin d’effectuer une comparaison (plus rapide mais plus coûteuse en espace de stockage).

En résumé, si le pirate falsifie la clé publique du certificat, les informations seront différentes de celles d’origine et quand le serveur va les hacher pour les comparer au condensat directement créé par la CA, il remarquera qu’il y a eu falsification. Le seul moyen pour le pirate de passer inaperçu et d’obtenir la clé privée du CA (bon courage ^^). Pour exemple :

Fonctionnement certificat électronique

Dans le cas d’OpenVPN, l’authentification est bidirectionnelle : le client et le serveur doivent s’authentifier entres (donc chacun envoyer son certificat à l’autre). Le serveur OpenVPN et tous les clients possèdent le certificat d’autorité de certificat du CA.

Petite remarque, vous avez du vous poser des questions quand j’ai dit que la clé privée servirait à crypter (le condensat) et la clé publique à décrypter (la signature) alors que dans la cryptographie asymétrique « classique » c’est l’inverse. Néanmoins, afin de d’être certain de la provenance des données on inverse les rôles car tout le monde peut avoir la clé publique mais, une seule personne possède la clé privée (et c’est la CA).

Pour terminer les explications, il n’est pas obligatoire que la CA génère elle-même les pairs de clés. Il est possible de générer sois-même sa pair de clés et d’envoyer la clé publique à une autorité de certification pour qu’elle puisse créer le certificat, signé.


Installation et préparation d’OpenVPN

Mettre à jour la distribution

Exécutez la commande suivante :

apt update -y && apt upgrade -y

Cette commande permet de mettre à jour la liste des paquets et de mettre à jour les paquets installés sur votre système.

Installer OpenVPN

Exécutez la commande suivante :

apt install openvpn

Pour sécuriser d’avantage votre serveur OpenVPN, vous pouvez installer fail2ban pour limiter le nombre d’essais possibles d’authentification (recommandé pour éviter les attaques brutes et DDOS) :

apt install fail2ban

fail2ban est pré-configuré à l’installation, il n’est pas obligatoire de le configurer : la limite d’essais possibles est de 3. Au bout les 3 essais, l’adresse de l’hôte tentant de se connecté est bannie pendant 10 minutes.

Configuration de l’architecture

Générer le certificat d’autorité de certification maître (CA)

Récupérer le dossier easy-rsa

Le dossier /usr/share/easy-rsa/ contient les scripts nécessaires pour générer les certificats dont nous allons avoir besoin.

Par précaution, faite une copie de ce dossier dans le dossier personnel (sécurisé) de l’utilisateur que vous voulez utiliser pour la génération des certificats :

mkdir -p ~/openvpn/easy-rsa/ && cp /usr/share/easy-rsa/* ~/openvpn/easy-rsa/

De préférence la génération des certificats est a faire sur une machine différente du serveur OpenVPN et des clients mais ici nous ferons cela sur le serveur même.

Initialiser les variables globales

Placez-vous dans le dossier easy-rsa et éditez le fichier vars qui doit si trouver :

cd ~/openvpn/easy-rsa/ && nano vars

6 variables sont présentes dans ce fichier (vers la fin) : KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, KEY_EMAIL et KEY_OU. C’est en ce basant sur les valeurs de chacune de ces variables que sera généré le CA.

Complétez-les de la manière suivante (exemple) :

export KEY_COUNTRY="FR"                     # Pays (en 2 lettres)
export KEY_PROVINCE="Nord-Pas-Calais"       # Région
export KEY_CITY="Dunkerque"                 # Ville
export KEY_ORG="JeanBart"                   # Organisation
export KEY_EMAIL=steven.douilliet@lycee.jb  # Adresse mail
export KEY_OU="BTSSIO"                      # Section

Ne laissez aucune de ces variables vide !

Enregistrez les modifications ;

Initialisez les variables :

. ./vars

Le script vars (à lancé avec un . devant) est sourcé et les variables sont initialisées. A chaque démarrage du serveur, il faut de nouveau initialiser les variables.

Générer le certificat

Nettoyez le dossier keys :

./clean-all

Le script clean-all supprime toutes les clés et certificats existants dans le dossier ~/openvpn/easy-rsa/keys/. C’est dans ce dossier que sera généré nos futurs fichiers. Si vous devez générer un nouveau CA il est préférable de vider keys au préalable.

Maintenant nous allons créer un certificat d’autorité de certification et avec sa clé privée à 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 ~/openvpn/easy-rsa/keys.

Exécutez le script build-ca :

./build-ca

Laissez les valeurs par défauts (que vous avez renseigné dans les variables précédemment) aux paramètres qui vous seront demandés, sauf à celui-ci :

 Common Name (eg, your name or your server's hostname)

Renseignez le nom de l’autorité de certification (ou laissez la valeur par défaut) ;

Vous devriez obtenir un résultat similaire à celui-ci (exemple) :

Country Name (2 letter code) [FR]:
State or Province Name (full name) [Nord-Pas-Calais]:
Locality Name (eg, city) [Dunkerque]:
Organization Name (eg, company) [JeanBart]:
Organizational Unit Name (eg, section) [BTSSIO]:
Common Name (eg, your name or your server's hostname) [JeanBart CA]:
Name [EasyRSA]:
Email Address [steven.douilliet@lycee.jb]:

Attention : le paramètre Common Name doit être unique, ne générez pas plusieurs certificats avec le même nom !

Générer des certificats

Pour un serveur OpenVPN

Comme vous avez dû le comprendre durant la phase d’explication au début du tutoriel, le serveur aura de 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 un fichier nommé server.crt et la clé dans un fichier nommé server.key, tous deux dans le dossier ~/openvpn/easy-rsa/keys.

Exécuter le script build-key-server :

./build-key-server server

Laissez les valeurs par défauts aux paramètres qui vous sont demandés. Le paramètre Common Name prendra le nom du certificat (ici server) mais, vous pouvez le modifier si vous le voulez.

Vous pouvez ensuite renseigner un mot de passe et un nom d’entreprise si vous le souhaitez ;

Répondez positivement aux autres questions, pour auto-signer le certificat.

Pour un client

Pour générer le ceryficiat du client, nous utiliserons le script build-key ou build-key-pass (si vous voulez votre clé privée avec un mot de passe). 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 ~/openvpn/easy-rsa/keys.  Le certificat et la clé doivent être uniques pour chaque client.

Exécutez le script build-key[-pass] :

./build-key NomClient

Laissez les valeurs par défauts aux paramètres qui vous seront demandés ;

Vous pouvez ensuite renseigner un mot de passe et un nom d’entreprise si vous le souhaitez ;

Répondez positivement aux autres questions, pour auto-signer le certificat.

Générer les paramètres Diffie-Hellman

Diffie-Hellman est un protocole de cryptographie utilisé dans les échanges de clés. Cette clé sera utilisé 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 de dans le dossier ~/openvpn/easy-rsa/keys

Exécutez le script build-db :

./build-dh

L’opération peut être longue en fonction des ressources de votre machine.

Configuration des éléments

Envoyer les certificats au serveur et aux clients

Il est coutume de faire un récapitulatif des fichiers créé à laide d’un tableau, alors voici :

Fichier Utile à Utilité Privée ?
ca.crt Serveur et clients Certificat du CA Non
ca.key CA Clé privée du CA Oui
dh{2048}.pem Serveur Clé de chiffrement sysmétrique Non
server.crt Serveur Certificat du serveur Non
server.key Serveur Clé privée du serveur Oui
client.crt Client Certificat du client Non
client.key Cient Clé privée du client Oui

Si nous nous fions à ce tableau, nous voyons que le serveur OpenVPN va avoir besoin des fichiers ca.crt, server.crt, server.keyet dh{n}.pem.

Copiez ces fichiers dans le répertoire/etc/openvpn/ : 

cp keys/dh*.pem keys/ca.crt keys/server.crt keys/server.key /etc/openvpn/

Quant au client, il aura besoin des fichiers ca.crt, client.crt, client.key.  Nous allons lui envoyer à l’aide de la scp, dont le format sera le suivant :

scp CheminFichieràEnvoyer utilisateur@IPClient:~/

L’utilisateur est celui que vous souhaitez autoriser à créer VPN avec votre serveur OpenVPN ou un administrateur que vous utiliserez ensuite pour placer les fichiers dans le dossier personnel de l’utilisateur devant utilisant un VPN. Je vous conseille de créer un dossier openvpn dans le dossier personnel de l’utilisateur concerné, avec les fichiers que vous enverrez.

Configurer le serveur OpenVPN

Créer le fichier de configuration

Dans le répertoire /usr/share/doc/openvpn/examples/sample-config-files/, vous trouverez le fichier compressé server.conf.gz qui contient un exemple de fichier de configuration d’un serveur OpenVPN. Nous allons le récupérer et l’adapter.

Décompressé le fichier server.conf.gz dans le dossier /etc/openvpn/ :

zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz > /etc/openvpn/server.conf

Éditez le fichier server.conf :

nano /etc/openvpn/server.conf

Repérez la ligne suivante :

dh dh1024.pem

Si vous avez généré une clé Diffie Hellman de 2048 bits (normalement oui), remplacez la valeur 1024 par 2048 ;

Repérez la ligne suivante :

server 10.8.0.0 255.255.255.0

Si l’adresse du réseau auquel donne accès le VPN est identique à l’adresse spécifiée ici (adresse du réseau qui sera utilisée dans le VPN), modifiez-la.

Pour que le client puisse avoir accès au réseau à l’autre bout du tunnel, le serveur doit posséder la route lui indiquant de rediriger les requêtes vers le réseau concerné. Ajoutez une route (à la fin du fichier) vers votre réseau de destination de la manière suivante :

push route @RéseauDestination Masque

Enregistrez les modifications ;

Redémarrez le serveur :

reboot

Le service openvpn n’est pas exécuté automatiquement (sous Debian 8) en tâche de fond après son redémarrage, il faut redémarrer la machine pour cela.

Affichez les informations des interfaces réseau IP :

ifconfig

Vous devriez maintenant voir l’interface virtuelle d’OpenVPN (exemple) :

tun0      Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet adr:172.17.17.1 P-t-P:172.17.17.2 Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:100
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Cette interface est utilisé par le VPN (pour le routage) et permet d’écouter les connexions clientes sur le port UDP 1194, et de distribuer des adresses virtuelles aux clients se connectant depuis le réseau par défaut 10.8.0.0/24 (dans mon cas 172.17.17.0/24).

Activer le FORWARDING

Si le forwarding n’est pas activé, le serveur OpenVPN ne redirigera pas (NAT) les requêtes vers le réseau auquel vous voulez accéder et vous ne pourrez communiquer qu’avec le serveur lui-même.

Éditez le fichier /etc/sysctl.conf :

nano /etc/sysctl.conf

Repérez et dé-commentez la ligne suivante pour activer le routage :

#net.ipv4.ip_forward=1

Enregistrez les modifications ;

Redémarrez le service procps :

service procps restart

Configurez la règle d’iptables qui activera le NAT sur l’interface connecté au réseau auquel donne accès le VPN :

iptables -t nat -A POSTROUTING -o NomInterface -j MASQUERADE

Sauvegardez les règles iptables dans le fichier /etc/iptables_rules.save :

iptables-save > /etc/iptables_rules.save

Éditez le fichier /etc/network/interfaces :

nano /etc/network/interfaces

Ajoutez la ligne suivante à la fin du fichier :

 post-up iptables-restore < /etc/iptables_rules.save

Cette ligne permet de restaurer les règles iptables au démarrage du service networking (donc du serveur).

Enregistrez les modifications ;

Redémarrez le service networking :

service networking restart

Configurer le client OpenVPN

Installer OpenVPN

Exécutez la commande suivante :

apt install openvpn

Créer le fichier de configuration

Dans le répertoire /usr/share/doc/openvpn/examples/sample-config-files/ (du client), vous trouverez le fichier client.conf qui contient un exemple de fichier de configuration d’un client. Nous allons le récupérer et l’adapter.

Copiez le fichier client.conf là où se trouve le certificat et les autres fichiers du client (dans mon cas, ~/openvpn) :

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/openvpn/client.conf

Éditez le fichier client.conf :

nano ~/openvpn/client.conf

Repérez la ligne suivante :

remote my-server-1 1194

Renseignez l’adresse IP du serveur OpenVPN à la place de la valeur my-server-1 (1194 correspond au port utilisé pour la connexion) ;

Repérez les lignes suivantes :

cert client.crt
key client.key

Remplacez les noms des fichiers .crt et .key par les noms de ceux que vous avez créé pour le client (si ce sont les mêmes, ne changez rien) ;

Enregistrez les modifications.

Créer un VPN

Le client et le serveur sont près, il ne vous reste plus qu’à tester la création d’un VPN entre le client et le serveur OpenVPN.

Exécutez le fichier de configuration de votre client (pour moi, client.conf:

 cd ~/openvpn/ && sudo openvpn client.conf &

L’option & permet de lancer le service en tâche de fond, pour pouvoir continuer à utiliser la console.

Vous devez obtenir un résultat final similaire à celui-ci :

[1] 815
root@Debian-8:/home/debian/openvpn# Tue Jul 18 18:26:46 2017 OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [E POLL] [PKCS11] [MH] [IPv6] built on Jun 26 2017
Tue Jul 18 18:26:46 2017 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08
Tue Jul 18 18:26:46 2017 Socket Buffers: R=[163840->131072] S=[163840->131072]
Tue Jul 18 18:26:46 2017 UDPv4 link local: [undef]
Tue Jul 18 18:26:46 2017 UDPv4 link remote: [AF_INET]192.168.1.254:1194
Tue Jul 18 18:26:46 2017 TLS: Initial packet from [AF_INET]192.168.1.254:1194, sid=fb00021f 2f78fddd
Tue Jul 18 18:26:46 2017 VERIFY OK: depth=1, C=FR, ST=Nord-Pas-Calais, L=Dunkerque, O=JeanBart, OU=BTSSIO, CN=JeanBar t CA, name=EasyRSA, emailAddress=steven.douilliet@lycee.jb
Tue Jul 18 18:26:46 2017 VERIFY OK: nsCertType=SERVER
Tue Jul 18 18:26:46 2017 VERIFY OK: depth=0, C=FR, ST=Nord-Pas-Calais, L=Dunkerque, O=JeanBart, OU=BTSSIO, CN=server, name=EasyRSA, emailAddress=steven.douilliet@lycee.jb
Tue Jul 18 18:26:46 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 18 18:26:46 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 18 18:26:46 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Jul 18 18:26:46 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 18 18:26:46 2017 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jul 18 18:26:46 2017 [server] Peer Connection Initiated with [AF_INET]192.168.1.254:1194
Tue Jul 18 18:26:48 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Tue Jul 18 18:26:48 2017 PUSH: Received control message: 'PUSH_REPLY,route 10.15.17.0 255.255.255.0,route 172.17.17.1 ,topology net30,ping 10,ping-restart 120,ifconfig 172.17.17.6 172.17.17.5'
Tue Jul 18 18:26:48 2017 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jul 18 18:26:48 2017 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jul 18 18:26:48 2017 OPTIONS IMPORT: route options modified
Tue Jul 18 18:26:48 2017 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=08:00:27:9c:12:89
Tue Jul 18 18:26:48 2017 TUN/TAP device tun0 opened
Tue Jul 18 18:26:48 2017 TUN/TAP TX queue length set to 100
Tue Jul 18 18:26:48 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jul 18 18:26:48 2017 /sbin/ip link set dev tun0 up mtu 1500
Tue Jul 18 18:26:48 2017 /sbin/ip addr add dev tun0 local 172.17.17.6 peer 172.17.17.5
Tue Jul 18 18:26:48 2017 /sbin/ip route add 10.15.17.0/24 via 172.17.17.5
Tue Jul 18 18:26:48 2017 /sbin/ip route add 172.17.17.1/32 via 172.17.17.5
Tue Jul 18 18:26:48 2017 Initialization Sequence Completed

Vous devriez ensuite pouvoir communiquer avec les machines à l’autre bout du tunnel (dans mon cas je communique avec mon serveur interne) :

PING 10.15.17.1 (10.15.17.1) 56(84) bytes of data.
64 bytes from 10.15.17.1: icmp_seq=1 ttl=63 time=0.612 ms
64 bytes from 10.15.17.1: icmp_seq=2 ttl=63 time=2.02 ms
64 bytes from 10.15.17.1: icmp_seq=3 ttl=63 time=2.05 ms

Ce tutoriel est terminé. Pour la configuration d’un client OpenVPN sous Windows, c’est par ici.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Superviser un hôte Windows via NSCP

NSClient++ (NSCP) est un logiciel de surveillance capable de travailler avec Nagios.

Ce tutoriel est la suite de celui sur l’installation et la configuration de Nagios, il explique comment utiliser le NSCP avec Nagios 3 et a été réalisé sous Debian 7.11.0. Si vous utilisez une distribution (ou version) différente il pourrait y avoir quelques divergences de paramétrage.

Vos machines supervisés doivent possède le service NSClient, si ne n’est pas encore fait, vous pouvez suivre le tutoriel sur l’installation et la configuration de NSClient++.

Ce tutoriel sera cours, si vous avez bien suivi  le précédent, vous devez déjà savoir créer des services pour vos hôtes. Ici la configuration d’un service reste la même, c’est seulement le greffon utilisé qui est différent.

Toutes les manipulations à venir seront à effectuer en tant que  super-utilisateur de la machine.


Configurer des services

Nous utiliserons le plugin check_nt, qui permet de récupérer des données collectées par le service NSClient, à partir du serveur Nagios.

Nous allons créer ensemble quelques services. Voici le fichier check_nt, contenant les définitions du plugin check_nt (dont celles que nous allons utiliser). Vous pouvez le télécharger et le placer dans le dossier /etc/nagios-plugins/config/ de votre serveur Nagios si vous le souhaitez, ou bien créer vous-même ce fichier et créer vos propres définitions en vous aidant de ce site.

Attention, vous remarquerez que dans chaque définition se trouve [MotDePasse]. Vous devez remplacer cette chaîne par le mot de passe que vous avez renseigné pendant l’installation du logiciel NSClient++.

Le format de la commande que nous utiliserons dans les définitions sera le suivant :

/usr/lib/nagios/plugins/check_nt -H [IPHôte] -s [MotDePasse] -p 12489 -v [VARIABLE] [OPTIONS]
[IPHôte]

Adresse IP de l’hôte supervisé

[MotDePasse] Mot de passe que vous avez renseigné à l’installation de NSClient++ sur l’hôte en question
[VARIABLE]

Nom de la variable qu définit l’opérateur à effectuer. Vous trouvez la liste des variables disponible et leur description ici

[OPTIONS]

Arguments supplémentaire qui suivent la variables. En fonction de la variables utilisé vous devrez renseigner des arguments.

Si avant de commencer la supervision, vous voulez vous assurer que vous avez bien installé et configuré le NSClient++ sur vos hôte, vous pouvez utiliser la commande suivante :

/usr/lib/nagios/plugins/check_nt -H [IPHôte] -s [MotDePasse] -p 12489 -v CLIENTVERSION

La commande devrait vous retourner un résultat similaire à celui-ci :

NSClient++ 0.5.0.62 2016-09-14

Contrôler l’espace disque utilisé

Vous trouvez dans le fichier check_nt.cfg, fourni plus haut, la définition suivante (au début du fichier) :

define command{
command_name check_nt_disk
command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -s [MotDePasse] -p 12489 -v USEDDISKSPACE -l $ARG1$ -w $ARG2$ -c $ARG3$
}

La variable utilisé USEDDISKSPACE et elle requise arguments :

  • $ARG1$ : Lettre associée au disque à contrôler (C par exemple) ;
  • $ARG2$ : Pourcentage d’espace utilisé pour le statue WARNING ;
  • $ARG3$ : Pourcentage d’espace utilisé pour le statue CRITICAL.

Si vous testez cette commande vous devriez obtenir un résultat similaire à celui-ci :

C:\ - total: 223,02 Gb - utilisé: 90,87 Gb (41%) - libre 132,15 Gb (59%) | 'C:\ Espace Utilisé'=90,87Gb;44,60;22,30;0.00;223,02

Ici c’est le lecteur C qui est contrôlé ;

Maintenant, supposons que nous voulons contrôler l’espace disque du Lecteur C et que le statue de service soit WARNING si 70% de l’espace disque est utilisé et qu’il soit CRITICAL si 90% de l’espace disque est utilisé. Le service sera donc configuré de la manière suivante :

define service{
       use generic-service ; Name of service template to use
       host_name [NomHôte]
       service_description PING
       check_command check_nt_disk!C!70!90
}

Pour rappel, chaque argument doit être séparé par un « ! ».

Contrôler la mémoire utilisée

Vous trouvez dans le fichier check_nt.cfg, fourni plus haut, la définition suivante :

define command{
command_name check_nt_memuse
command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -s [MotDePasse] -p 12489 -v MEMUSE -w $ARG1$ -c $ARG2$
}

Ici seul la limite WARNING et CRITICAL sont a renseigné (toujours en pourcentage) comme argument ;

Si vous testez cette commande vous devriez obtenir un résultat similaire à celui-ci :

Mémoire utilisée: total:9858,66 Mb - utilisée: 5045,20 Mb (51%) - libre: 4813,46 Mb (49%) | 'Mémoire utilisée'=5045,20Mb;6901,06;8872,80;0.00;9858,66

Le service utilisant cette commande pourrait être configuré de la manière suivante :

define service{
       use generic-service ; Name of service template to use
       host_name windows
       service_description MEMORY
       check_command check_nt_memuse!70!90
}

Le statue de l’hôte est WARNING si 70% de la mémoire est utilisée et CRITICAL si 90% de la mémoire est utilisée.

Contrôler la charge du processeur

Vous trouvez dans le fichier check_nt.cfg, fourni plus haut, la définition suivante :

define command{
command_name check_nt_cpuload
command_line /usr/lib/nagios/plugins/check_nt -H $HOSTADDRESS$ -s [MotDePasse] -p 12489 -v CPULOAD -l $ARG1$
}

La commande ne nécessite qu’un argument, mais celui-ci demande 3 paramètres :

  • -l [Intervale],[Seuil WARNING],[Seuil CRITICAL]

[Intervale] s’exprime en minutes (et les 2 seuil en pourcentage) et doit être inférieur à 1440 (soit 1 jour).

En indiquant l’intervalle, la commande va récupèrer la charge moyenne du processeur durant les X dernière minutes (si [Intervale] = 5 alors la moyenne sera fait sur les 5 dernières minutes d’utilisation du processeur) ;

Si vous testez cette commande vous devriez obtenir un résultat similaire à celui-ci :

Charge CPU 7% (5 moyenne minimale) | '5 Charge moyenne minimale'=7%;70;90;0;100

Le service utilisant cette commande pourrait être configuré de la manière suivante :

define service{
       use generic-service ; Name of service template to use
       host_name windows
       service_description MEMORY
       check_command check_nt_cpuload!5,70,90
}

L’intervalle est de 5, le statue de l’hôte est WARNING si 70% du CPU est utilisé et CRITICAL si 90% du CPU est utilisé.


Ce tutoriel est terminé. Vous pouvez continuer la supervision en supervisant hôte Linux via NRPE ou encore des actifs via SNMP.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Superviser un hôte Linux via NRPE

NRPE (Nagios Remote PluginExecutor) est un agent de supervision qui permet de récupérer les informations à distance. Son principe de fonctionnement est simple : il suffit d’installer le serveur NRPE sur la machine distante et de l’interroger à partir du serveur Nagios.

Ce tutoriel est la suite de celui sur l’installation et la configuration de Nagios, il explique comment installer et configurer NRPE 2.13 et a été réalisé sous Debian 7.11.0. Si vous utilisez une distribution (ou version) différente il pourrait y avoir quelques divergences de paramétrage.

Toutes les manipulations à venir seront à effectuer en tant que super-utilisateur de la machine.


Installation & configuration de NRPE

Installer le plugin NRPE

Pour effectuer des requêtes NRPE, le serveur (ou plutôt client) Nagios aura besoin du plugin NRPE.

Exécutez la commande suivante :

apt-get install nagios-nrpe-plugin

Installer le serveur NRPE

Le serveur NRPE doit être installé sur chaque hôte supervisés par le serveur Nagios via NRPE.

Exécutez la commande suivante :

apt-get install nagios-nrpe-server

Configurer le serveur NRPE

Les manipulations à venir seront à appliquer sur chaque hôte possédant un serveur NRPE.

Autoriser l’accès au serveur NRPE

Pour que le serveur Nagios puisse récupérer des informations au sujet de son hôte, il faut lui donner l’accès au serveur NRPE dans le fichier /etc/nagios/nrpe.cfg.

Éditez le fichier nrpe.cfg :

nano /etc/nagios/nrpe.cfg

Repérez la ligne suivante :

allowed_hosts=127.0.0.1

Remplacez la valeur 127.0.0.1 par l’adresse IP du serveur Nagios ;

Enregistrez les modifications ;

Autoriser les requêtes NRPE

Par défaut, tout le trafic passe sur la machine, aucune requête n’est bloquée mais, si vous avez configuré les pares-feu de votre serveur pour qu’ils interdisent tout trafic entrant non autorisé, il vous faudra créer une nouvelle règle à l’aide du logiciel iptables (installé par défaut). Cette règle devra autoriser le trafic entrant sur le port 5666 (celui utilisé par NRPE).

Exécutez la commande suivante :

iptables -A INPUT -p tcp --dport 5666 -j ACCEPT

Cette commande permet d’ajouter (-A) la règle indiquant que le trafic en entrée (INPUT), utilisant le protocole TCP (-p tcp), sur le port 5666 (–dport 5666) est autorisé (-j ACCEPT)

Automatiser le démarrage de NRPE

Le serveur NRPE (le service nagios-nrpe-server) ne démarrage automatiquement au démarrage de la machine. Nous allons donc automatiser (facultatif) son lancement au démarrage de la machine à l’aide de la commande update-rc.d (permet d’activer, ou désactiver un service à exécuter au démarrage)

Automatisez le lancement du service nagios-nrpe-server  :

update-rc.d nagios-nrpe-server defaults

Redémarrez le service nagios-nrpe-server :

service nagios-nrpe-server restart

Vous pouvez tester le fonctionnement de NRPE depuis le serveur Nagios, à l’aide de la commande suivante :

/usr/lib/nagios/plugins/check_nrpe -H IPServeurNRPE

La commande devrait vous retourner la version du serveur NRPE :

NRPE v2.13

Fonctionnement de NRPE

Côté serveur NRPE

Pendant l’installation du serveur NRPE, les plugins de Nagios ont également été installés et son stockés dans le répertoire /usr/lib/nagios/plugins/. Leurs fichiers de configuration sont quant à eux stockées dans le dossier /etc/nagios-plugins/config/.

Sur le serveur NRPE, nous allons définir des commandes dans le fichier /etc/nagios/nrpe.cfg. Ces commandes utiliseront les plugins de Nagios et elle seront exécutées à distance par le serveur (ou plutôt client) Nagios, qui récupérera le résultat.

Si vous consultez le fichier nrpe.cfg, vous remarquerez que 5 commandes sont déjà définit par défaut (vers la fin du fichier) :

# The following examples use hardcoded command arguments...
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1
command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z
command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200

Vous retrouverez les descriptions des plugins utilisés (et bien d’autres) dans le dossier /etc/nagios-plugins/config/ (en cherchant un peu bien sûr) ou bien en consultant ce site. À chaque greffon (plugin) que vous souhaiterez utiliser à distance, vous devrez créer une commande.

Exemple

Nous allons créer une commande utilisant le plugin check_disk, pour surveiller l’espace disque disponible dans le dossier /home/.

Éditez le fichier nrpe.cfg :

nano /etc/nagios/nrpe.cfg

Ajoutez la ligne suivante (à la fin de fichier de préférence) :

command[check_home]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /home

Ici, le statue du service que nous allons créer plus tard sera en WARNING (-w), s’il reste moins de 20% (20) d’espace disque disponible et le statue sera CRITICAL (-c) s’il reste moins de 10% (10) d’espace libre.

Enregistrez les modifications ;

Redémarrez le service nagios-nrpe-server (à faire à chaque ajout/suppression/modification de commande) :

service nagios-nrpe-server restart

Si vous souhaitez tester le fonctionnement de la commande, exécutez le plugins check_nrpe depuis le serveur Nagios, de la manière suivante :

/usr/lib/nagios/plugins/check_nrpe -H IPServeurNRPE -c check_home

Vous devriez obtenir un résultat ressemble à ceci :

DISK OK - free space: / 5997 MB (82% inode=89%);| /=1295MB;7663;7673;0;7683

Côté serveur Nagios

A l’installation du plugin NRPE, un fichier de configuration du plugin NRPE a été créé. Il s’agit du fichier /etc/nagios-plugins/config/check_nrpe.cfg :

# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}
# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

Ce fichier contient 2 définitions. Celle qui nous intéresse est la seconde, check_nrpe_1arg. C’est grâce à cette commande que seront exécutées  à distance les commandes définit dans le fichier /etc/nagios/nrpe.cfg.

Exemple

Supposons que nous voulons créer un service pour l’hôte (sur lequel est installé le serveur NRPE). Ce service doit utiliser le plugins check_nrpe pour exécuter à distance la commande check_home que nous avons créé sur l’hôte précédemment.

La syntaxe du service sera donc la suivante :

define service{
        use generic-service ; Name of service template to use
        host_name NomHôte
        service_description HOME
        check_command check_nrpe_1arg!check_home
}

On remarquera le la variable check_command contient le plugin check_nrpe_1arg suivie de l’argument check_home qui est le nom de la commande à exécuter à distance.


Ce tutoriel est terminé. Vous pouvez continuer la supervision en supervisant un hôte Windows via NSCP.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Installation & Configuration Nagios

Nagios est un logiciel permettant de superviser (par définition, les surveiller) des serveurs d’un réseau.

Ce tutoriel explique comment installer et configurer Nagios3 sous Debian 7.11.0. Si vous utilisez une distribution (ou version) différente il pourrait y avoir quelques divergences de paramétrage.

Toutes les manipulations à venir seront à effectuer en tant que super-utilisateur de la machine.


Installation de Nagios

Mettre à jour la distribution

Exécutez la commande suivante :

apt-get update -y && apt-get upgrade -y

Cette commande permet de mettre à jour la liste des paquets de Debian et de mettre à jour les paquets installés sur votre système Debian.

Installer Nagios

Exécutez la commande suivante :

apt-get install nagios3

Pendant l’installation il vous sera demandé de renseigner un mot de passe pour l’utilisateur administrateur de Nagios ;

A l’installation de Nagios, 2 dossiers principaux sont créés :

  • /etc/nagios3/ : contient les fichiers de configuration de Nagios, c’est dans celui-ci que nous configurerons les services de supervision à utiliser pour les clients. Il contient notamment :
nagios.cfg

Fichier qui contient la configuration du serveur

cgi.cfg

Fichier qui contient les droits des utilisateurs de Nagios

htpasswd.users

Fichier qui contient la liste des utilisateurs Nagios

conf.d

Dossier qui contiendra les fichiers de configuration pour chaque client à superviser

  • /etc/nagios-plugins/ : contient le dossier config/ qui lui contient les services disponibles pour la supervision des clients.

Une fois installé pour pouvez déjà accéder à Nagios à l’adresse http://IPServeur/nagios3/, avec les identifiants administrateurs suivants :

  • Utilisateur : nagiosadmin
  • Mot de passe : mot de passe que vous avez choisi pendant l’installation

Configuration de Nagios

Créer un utilisateur Nagios

Comme dit plus haut, le fichier htpasswd.users va contenir les utilisateurs de Nagios. Pour pouvoir créer un utilisateur, vous devez utilisez la commande htpasswd de la manière suivante :

htpasswd /etc/nagios3/htpasswd.users nomutilisateur

Un mot de passe vous sera ensuite demandé pour l’utilisateur.

Définir les droits d’un utilisateur Nagios

Un utilisateur fraîchement créé n’a pas de droit sur Nagios. Si vous vous rendez sur l’interface vous remarquerez que l’utilisateur n’a même pas le droit de consulter les informations sur les hôtes de Nagios.

La configuration des droits de l’utilisateur se fera dans le fichier cgi.cfg comme dit précédemment. Si vous souhaitez créer un utilisateur standard permettant seulement la consultation, par exemple, la configuration du fichier ce sera de la manière suivante :

Éditez le fichier cgi.cfg :

nano /etc/nagios3/cgi.cfg

Repérez la ligne suivante :

authorized_for_system_information=nagiosadmin

Cette option permet d’autoriser un utilisateur à accéder à toutes les informations sur Nagios ;

Ajoutez le nom de l’utilisateur standard après nagiosadmin : chaque utilisateur doit être séparé par une virgule « , » ;

Repérez la ligne suivante :

authorized_for_all_services=nagiosadmin

Cette option permet d’autoriser un utilisateur à accéder à la liste des services de Nagios ;

Ajoutez le nom de l’utilisateur standard après nagiosadmin : chaque utilisateur doit être séparé par une virgule « , » ;

Repérez la ligne suivante :

authorized_for_all_hosts=nagiosadmin

Cette option permet d’autoriser un utilisateur à accéder à la liste des hôtes supervisés par Nagios. Les services visibles sur l’interface Nagios sont liés à ces hôtes ;

Ajoutez le nom de l’utilisateur standard après nagiosadmin : chaque utilisateur doit être séparé par une virgule « , » ;

Enregistez les modification ;

Relancer le service nagios3 :

service nagios3 reload

Configuration d’un hôte

Nous ne verrons ici que quelques services de supervision, libre à vous de tester les autres services disponibles pour votre réseau.

Plus tôt, nous avons vue que le dossier /etc/nagios3/conf.d/ contiendrait les fichiers de configuration des hôtes de Nagios.  Chaque hôte aura son propre fichier de configuration .cfg. Il est possible de configurer plusieurs hôtes dans un même fichier mais, par soucis de d’organisation je vous conseille de créer un fichier par client : ce fichier aura le nom du client en question.

Pour l’exemple, nous allons superviser un serveur web nous le nom sera Website. Vous devrez donc adapter les manipulation à venir à votre cas.

Nagios met a disposition le fichier /etc/nagios3/conf.d/localhost_nagios2.cfg qui est un exemple de configuration d’un hôte. Nous allons faire une copie de ce fichier en la renommant website.cfg.

Faite une copie du fichier localhost_nagios2.cfg :

cp /etc/nagios3/conf.d/localhost_nagios2.cfg /etc/nagios3/conf.d/website.cfg

Éditez le fichier de configuration que vous venez de créer :

nano /etc/nagios3/conf.d/website.cfg

Le contenu de votre fichier devrait être plus ou moins comparable à ceci :

# A simple configuration file for monitoring the local host
# This can serve as an example for configuring other servers;
# Custom services specific to this host are added here, but services
# defined in nagios2-common_services.cfg may also apply.
#
define host{
 use generic-host ; Name of host template to use
 host_name localhost
 alias localhost
 address 127.0.0.1
 }
# Define a service to check the disk space of the root partition
# on the local machine. Warning if < 20% free, critical if
# < 10% free space on partition. define service{  use generic-service ; Name of service template to use  host_name localhost  service_description Disk Space  check_command check_all_disks!20%!10%  } # Define a service to check the number of currently logged in # users on the local machine. Warning if > 20 users, critical
# if > 50 users.
define service{
 use generic-service ; Name of service template to use
 host_name localhost
 service_description Current Users
 check_command check_users!20!50
 }
# Define a service to check the number of currently running procs
# on the local machine. Warning if > 250 processes, critical if
# > 400 processes.
define service{
 use generic-service ; Name of service template to use
 host_name localhost
 service_description Total Processes
 check_command check_procs!250!400
 }
# Define a service to check the load on the local machine.
define service{
 use generic-service ; Name of service template to use
 host_name localhost
 service_description Current Load
 check_command check_load!5.0!4.0!3.0!10.0!6.0!4.0
 }

Ce qui va nous intéressé ici est la fonction define host qui permet de définir un hôte et define service qui permet de lui attribuer des services ;

Supprimez les defines service jusqu’à ce qu’il ne vous en reste plus qu’un et commentez ce dernier. De cette manière vous aurez toujours un modèle pour définir un service dans votre fichier. Il ne dverait rester que la définition de l’hôte et celle d’un service comenté :

define host{
 use generic-host ; Name of host template to use
 host_name localhost
 alias localhost
 address 127.0.0.1
 }
# host_name : permet de définir un nom court utilisé pour identifier l'hôte
# alias : permet de définir (ou pas) un nom plus long ou une description utilisée pour identifier l'hôte.
# address : permet de définir l'adresse IP de l'hôte
# define service{
#  use generic-service ; Name of service template to use
#  host_name localhost
#  service_description Disk Space
#  check_command check_all_disks!20%!10%
#  }
# host_name : permet de renseigner le nom de l'hôte
# service_description : permet de définir la description du service. Si un hôte à plusieurs services, ils ne doivent pas avoir la même description !
# check_commande : permet de définir le nom de la commande à utilisé et ses arguments (nous verrons cela prochainement)

Si vous souhaitez approfondir la configuration de votre hôte, vous pouvez consulter ce site.

Définir un hôte

Nous allons pour commencer définir l’hôte en question à l’aide de la fonction define host :

define host{
 use generic-host ; Name of host template to use
 host_name website
 alias website
 address @IPHôte
 }

Ajouter une sonde ICMP (ping)

Ce service permet de contrôler la présence sur le réseau des hôtes de Nagios.

Dans le dossier /etc/nagios-plugins/config/ vous trouvez le fichier ping.cfg qui contient les différents commandes disponibles pour ce service. La commande qui va nous intéresser est nommée check_ping et ressemble à ceci :

# 'check_ping' command definition
define command{
 command_name check_ping
 command_line /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'
 }

Nagios exécutera cette commande :

/usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'

Cette commande comprend 3 paramètres que vous nous devrons renseigner au moment de la définition du service dans le fichier de configuration de l’hôte :

-H ‘$HOSTADDRESS$’

Adresse IP de l’hôte

-w ‘$ARG1$’

Informations sur le temps maximum de l’envoie en secondes et le pourcentage paquets que l’on accepte de perdre.

-c $ARG2$’

Informations sur le temps maximum de réponse en secondes et le pourcentage de paquets que l’on veut en retour.

Nous verrons prochainement comment les paramétrer ;

Éditez le fichier de configuration de votre hôte :

nano /etc/nagios3/conf.d/website.cfg

Créer un nouveau service utilisant la commande check_ping de la manière suivante :

define service{
 use generic-service ; Name of service template to use
 host_name website
 service_description PING
 check_command check_ping!100.0,20%!500.0,60%
 }

La partie la plus intéressé et celle après la définition de du nom de la commande (check_ping). Nous avons vue précédemment que la commande comprendre 3 paramètres dont 2 arguments :

/usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'

Le paramètres $HOSTADDRESS$ est automatiquement complété. c’est Nagios lui-même qui ira chercher l’adresse IP de l’hôte (que nous avons définit dans define host) auquel le service est associé.

Il nous faut seulement paramétrer les arguments $ARG1$ et $ARG2$. Les arguments doivent être placés après le nom de la commande à utiliser et chacun doit être séparé par un point d’exclamation « ! ». De plus, si un argument demande plusieurs paramètre (comme c’est le cas pour la commande check_ping), alors chaque paramètre doit être séparé par une virgule « , ».

A noter qu’en fonction de la commande utilisée, le paramétrage des arguments n’est pas le même ; il vous faudra vous renseigner dans la documentation de Nagios pour savoir comment chacun se paramètre.

Dans le cas de la commande check_ping, les arguments doivent être paramétré de la manière suivante :

  • $ARG1$ : cet argument demande 2 paramètres, le temps d’envoie et le pourcentage de paquet que l’on accepte de perdre pendant l’envoie. Il se configure de la manière suivante :
    • TempDeRéponse,%dePerte (exemple : 100.0,20%)
  • $ARG2$ : cet argument demande 2 paramètres, le temps de réponse et le pourcentage de paquet que l’on veut en retour. Il se configure de la manière suivante :
    • TempDeRéponse,%deRetour (exemple : 500.0,60%)

Enregistrez les modifications ;

Vérifiez qu’il n’y ait pas d’erreur dans les fichiers de configuration de Nagios :

nagios3 -v /etc/nagios3/nagios.cfg

Cette commande contrôle les fichiers de configuration de Nagios (dont ceux des hôtes) afin de vérifier qu’il n’y ait aucune erreur de syntaxe ou autre ;

Si vous n’avez aucune erreur, relancez le service nagios3 (à faire a chaque modifications d’un fichier de configuration) :

service nagios3 reload

Depuis l’interface Nagios, vous devriez voir dans la liste des services (Current Status > Services) le service que vous venez de créé avec le statut PENDING. Si tout ce passe bien, le statut devrait passer à OK si l’hôte réponse.

Ajouter une sonde SSH

Ce service permet de contrôler l’accès SSH aux hôtes Nagios. Dans le dossier /etc/nagios-plugins/config/ vous trouverez le fichier ssh.cfg qui contient les commandes disponibles.

Nous allons utiliser la commande check_ssh qui permet de contrôler que le service ssh de l’hôte est fonctionnel :

# 'check_ssh' command definition
define command{
 command_name check_ssh
 command_line /usr/lib/nagios/plugins/check_ssh '$HOSTADDRESS$'
 }

Éditez le fichier de configuration de votre hôte :

nano /etc/nagios3/conf.d/website.cfg

Créer un nouveau service utilisant la commande check_ssh de la manière suivante :

define service{
 use generic-service ; Name of service template to use
 host_name website
 service_description SSH
 check_command check_ssh
 }

Comme nous avons pu le voir, la commande ne comporte pas d’argument. De ce fait, vous n’avez rien à renseigner après le nom de celle-ci ;

Enregistrez les modifications ;

Vérifiez qu’il n’y ait pas d’erreur dans les fichiers de configuration de Nagios :

nagios3 -v /etc/nagios3/nagios.cfg

Si vous n’avez aucune erreur, relancez le service nagios3 :

service nagios3 reload

Depuis l’interface Nagios, vous devriez voir dans la liste des services (Current Status > Services) le service que vous venez de créé avec le statut PENDING. Si tout ce passe bien, le statut devrait passer à OK si l’hôte réponse.

Ajouter une sonde HTTP

Ce service permet de contrôler l’accès via le protocole HTTP. Dans le dossier /etc/nagios-plugins/config/ vous trouverez le fichier http.cfg qui contient les commandes disponibles.

Nous allons utiliser la commande check_http qui permet de contrôler que le service http de l’hôte est fonctionnel :

# 'check_http' command definition
define command{
 command_name check_http
 command_line /usr/lib/nagios/plugins/check_http -H '$HOSTADDRESS$' -I '$HOSTADDRESS$'
 }

Éditez le fichier de configuration de votre hôte :

nano /etc/nagios3/conf.d/website.cfg

Créer un nouveau service utilisant la commande check_http de la manière suivante :

define service{
 use generic-service ; Name of service template to use
 host_name website
 service_description HTTP
 check_command check_http
 }

Comme nous avons pu le voir, la commande ne comporte pas d’argument. De ce fait, vous n’avez rien à renseigner après le nom de celle-ci ;

Enregistrez les modifications ;

Vérifiez qu’il n’y ait pas d’erreur dans les fichiers de configuration de Nagios :

nagios3 -v /etc/nagios3/nagios.cfg

Si vous n’avez aucune erreur, relancez le service nagios3 :

service nagios3 reload

Depuis l’interface Nagios, vous devriez voir dans la liste des services (Current Status > Services) le service que vous venez de créé avec le statut PENDING. Si tout ce passe bien, le statut devrait passer à OK si l’hôte réponse.


Ce tutoriel est terminé. Vous pouvez continuer la supervision en supervisant un hôte Linux via NRPE, un hôte Windows via NSCP, un actif (comme un switch) via SNMP.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Créer un tunnel SSH

Un tunnel SSH est une connexion sécurisée entre 2 machines par laquelle transitent des données (cryptés). Un tunnel SSH permet de relier 2 machines dans un même réseau ou encore dans 2 réseaux différents.

Représentons cela avec un client qui le point de départ du tunnel et un serveur qui est le point d’arrivé.

Cette solution présente de nombreux avantages, notamment celui de contourner les règles de pares-feu que vous rencontrez habituellement pour communiquer avec un autre réseau (ou machine). C’est-à-dire qu’elles ne s’appliquent pas à l’intérieur du tunnel.

Le tunnel peut permettre de relier seulement le client et le serveur, ou bien permettre d’utiliser le serveur comme proxy pour accéder au autres machines se trouvant dans son réseau.


Créer un tunnel ssh

La commande pour créer un tunnel SSH est la suivante :

ssh -p portconnexion -L portécouté:@IPDestionation:portDestionation utilisateur@IPServeur

Expliquons cette commande :

portconnexion

Port utilisé pour la connexion au serveur.

portécouté

Port que le client va écouter.

IPDestination

Adresse IP de la machine vers laquelle il faut rédiger les requêtes arrivant sur portécouté.

Cette adresse peut être l’adresse du serveur lui-même ou bien celle d’une machine sera trouvant dans le même réseau que le serveur.

Si l’adresse est celle d’une machine lambda, alors le serveur servira simplement de passerelle pour arriver jusque celle-ci.

portDestination

Port de la machine vers laquelle il faut rédiger les requêtes arrivant sur le portécouté.

utilisateur

Nom d’utilisateur utilisé pour se connecter au serveur.

IPServeur

Adresse IP du serveur.

Pour fermer le tunnel, il vous suffit de quitter la connexion SSH à l’aide de la commande suivante :

exit

Ce tutoriel est terminé. Vous pouvez continuer à sécuriser votre serveur en mettant en place une connexion par clés authentification.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.

Authentification SSH par clés

Avec SSH, l’authentification peut se faire sans l’utilisation de mot de passe en utilisant la cryptographie asymétrique. Celle-ci se constitue d’une paire de clés contenant une clé publique et une clé privée. La clé publique est distribuée sur les systèmes auxquels on souhaite se connecter. La clé privée, protégeable par une pass-phrase (en résumé un mot de passe) ou non, est placée sur la machine que l’on souhaite utiliser pour se connecter.

Source : Wikipédia

La mise en place d’une connexion par clés est très simple et identique pour la plus part des distributions. Ce tutoriel sera donc très rapide (en manipulation) et a été réalisé sous Debian 7 et 8.


Configuration de l’authentification par clés

Le serveur comme le client doit posséder le service ssh. Si ce vous ne l’avez pas encore installé, exécutez la commande suivante pour le faire :

apt-get install ssh

Autoriser la connexion par clés

Cette partie est à appliquer sur le serveur auquel vous voulez connecter.

En fonction de la distribution, la connexion par clés n’est pas activité.

Éditez le fichier  sshd_config :

nano /etc/ssh/sshd_config

Pour rappel, le fichier sshd_config est le fichier de configuration du service ssh ;

Repérez et décommettez la ligne suivante :

#AuthorizedKeysFile     %h/.ssh/authorized_keys

L’option AuthorizedKeysFile permet de spécifier le fichier contenant les clés publiques à utiliser pour l’authentification de l’utilisateur. Par défaut c’est dans un fichier nommé authorized_keys, stocké dans un dossier caché .ssh du home de l’utilisateur à qui on a envoyé la clé, qui contiendra la clé publique ;

Enregistrez les modifications ;

Redémarrez le service ssh :

service ssh restart

Générer une paire de clés

Le reste du tutoriel est à appliquer sur le client avec lequel vous voulez vous connecter.

Éclaircissons un point avant de continuer. Il ne suffit pas que le client possède la clé privée et le serveur clé publique pour que la connexion soit fonctionnelle, quelque soit l’utilisateur utilisé.

Tout d’abord, du côté du client. Seul l’utilisateur possédant dans son dossier personnel (dans un dossier caché nommé .ssh) la clé privé pourra être utilisée pour la connexion par clés. Le plus simple étant donc de générer la paire de clés avec l’utilisateur (administrateur ou non) que vous souhaitez utiliser.

Générez une paire de clés :

ssh-keygen

Il vous est demandé de renseigner un chemin où créer le fichier id_rsa qui contiendra la clé privée : par défaut le chemin est ~/.ssh/id_rsa et je vous conseil de le laisser tel quel ;

Il vous est ensuite proposé de renseigner une pass-phrase en complément de la clé privée pour la connexion par clés. Si vous voulez utiliser la connexion par clés de manière automatique entre plusieurs systèmes, ne renseignez par de pass-phrase ;

Pour résumer, la commande ssh-keygen a créé un fichier id_rsa qui contient la clé privée et un fichier id_rsa.pub qui contient la clé publique que nous enverrons au serveur auquel nous voulons nous connecter. Ces fichiers sont créés dans un dossier caché nommé .ssh et qui a été créé dans le home de l’utilisateur utilisé pour la génération de ces clés : ~/.ssh/.

Envoyer la clé publique

Placez vous dans le dossier où se trouve le fichier id_rsa.pub :

cd ~/.ssh/

Nous allons utilisé la commande ssh-copy-id qui permet (entre autre) d’envoyer à une machine distante une clé publique ;

La commande s’utilise de la manière suivante (parmi d’autres) :

ssh-copy-id -i id_rsa.pub '-p port utilisateur@IPMachineDistante'

port correspond au numéro de port utilisé pour se connecter à la machine distante ;

utilisateur correspond à l’utilisateur qui possédera la clés publique. Ce sera avec cet utilisateur que vous pourrez établir une connexion par clés ;

IPMachineDistance correspond à l’adresse IP de la machine à laquelle nous voulons nous connecter ;

Cette commande créé un dossier .ssh dans le home de utilisateur et créé le fichier authorized_keys qui contient la clé publique envoyée ;

Une fois la clé publique envoyé, vous devriez pouvoir connecter sans devoir renseigner de mot de passe :

ssh -p port utilisateur@IPMachineDistante

Ce tutoriel est terminé. Vous pouvez continuer à sécuriser les communication SSH à votre serveur en mettant en utilisant un tunnel SSH.

Si vous avez des problèmes, où que vous trouvez que certains points sont mal expliqués (ou faux), n’hésitez pas à m’avertir.