One place for hosting & domains

      surveiller

      Comment surveiller les annonces et les itinéraires BGP en utilisant BGPalerter sur Ubuntu 18.04


      L’auteur a choisi le COVID-19 Relief Fund pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      BGP (Border Gateway Protocol) est l’un des principaux protocoles utilisés pour le routage des paquets sur Internet, de sorte que lorsqu’il se trompe, des pannes importantes peuvent se produire. Par exemple, en 2019, un petit FAI a effectué une mauvaise configuration de BGP qui s’est malheureusement propagée en amont et a mis hors ligne une grande partie de Cloudflare et d’AWS pendant plus d’une heure. De plus, un an plus tôt, un détournement du BGP avait eu lieu afin d’intercepter le trafic vers un fournisseur bien connu de portefeuille de crypto-monnaie et de voler les fonds de clients peu méfiants.

      BGPalerter est un outil de surveillance open source du réseau BGP qui peut fournir des alertes en temps réel sur l’activité du BGP, y compris la visibilité des itinéraires et l’annonce de nouveaux itinéraires, ainsi que sur les activités potentiellement néfastes telles que les détournements ou les fuites d’itinéraires. BGPalerter ingère automatiquement les informations de routage réseau disponibles au public, ce qui signifie qu’il n’a pas besoin d’avoir un niveau d’accès privilégié ou d’intégration dans le(s) réseau(x) que vous souhaitez surveiller.

      Remarque : BGPalerter ingère automatiquement les informations de routage de réseau disponibles au public, ce qui signifie qu’il n’a pas besoin d’avoir un niveau d’accès privilégié ou d’intégration dans le(s) réseau(x) que vous souhaitez surveiller. Tous les contrôles sont entièrement conformes à la loi sur l’utilisation abusive de l’informatique, à la loi sur la fraude et les abus informatiques et à d’autres lois similaires. Toutefois, il est recommandé de divulguer de manière responsable toute constatation pertinente au gestionnaire de réseau concerné.

      Dans ce tutoriel, vous allez installer et configurer BGPalerter pour surveiller vos réseaux importants afin de détecter toute activité potentiellement suspecte.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      • Un serveur Ubuntu 18.04 configuré en suivant la Configuration initiale du serveur avec Ubuntu 18.04, y compris un utilisateur sudo non root.

      • Un ou plusieurs réseaux ou appareils que vous souhaitez surveiller, par exemple :

        • Un serveur dont vous êtes chargé de la maintenance
        • Le réseau de votre entreprise
        • Votre FAI local

      Pour chaque appareil ou réseau, vous devrez identifier soit l’adresse IP individuelle, soit la plage d’adresses IP, soit le numéro du système autonome dont il fait partie. Cette opération est couverte dans l’Étape 1.

      Une fois que tout cela est prêt, connectez-vous à votre serveur en tant qu’utilisateur non root pour commencer.

      Étape 1 — Identification des réseaux à surveiller

      Au cours de cette étape, vous identifierez les détails pertinents des réseaux que vous souhaitez surveiller.

      BGPalerter peut effectuer un suivi sur la base d’adresses IP individuelles ou de préfixes de réseau. Il peut également surveiller des réseaux entiers sur la base de leur numéro de système autonome (SA), qui est un identifiant unique au niveau mondial pour un réseau appartenant à une entité administrative particulière.

      Pour trouver ces informations, vous pouvez utiliser le IP-to-ASN WHOIS lookup service fourni par le service de renseignements sur les menaces Team Cymru. Il s’agit d’un serveur WHOIS personnalisé conçu pour la recherche d’adresses IP et d’informations sur le routage du réseau.

      Si vous n’avez pas encore installé whois, vous pouvez le faire en utilisant les commandes suivantes :

      • sudo apt update
      • sudo apt install whois

      Une fois que vous avez confirmé que whois a été installé, commencez par rechercher l’adresse IP de votre propre serveur, en utilisant l’argument -h pour spécifier un serveur personnalisé :

      • whois -h whois.cymru.com your-ip-address

      Vous obtiendrez alors une sortie similaire à celle qui suit, qui indique le nom et le numéro du SA dont votre serveur fait partie. Il s’agit généralement du SA de votre fournisseur d’hébergement de serveur, par exemple, DigitalOcean.

      Output

      AS | IP | AS Name 14061 | your-ip-address | DIGITALOCEAN-ASN, US

      Ensuite, vous pouvez effectuer une recherche pour identifier le préfixe/la plage de réseau dont votre serveur fait partie. Pour ce faire, vous devez ajouter l’argument -p à votre demande :

      • whois -h whois.cymru.com " -p your-ip-address"

      La sortie sera très similaire à la commande précédente, mais affichera désormais le préfixe de l’adresse IP à laquelle appartient l’adresse IP de votre serveur :

      Output

      AS | IP | BGP Prefix | AS Name 14061 | your-ip-address | 157.230.80.0/20 | DIGITALOCEAN-ASN, US

      Enfin, vous pouvez consulter d’autres détails sur le SA dont votre serveur fait partie, notamment la région géographique et la date d’attribution.

      Modifiez le numéro SA que vous avez identifié en utilisant les commandes précédentes. Vous utilisez l’argument -v pour permettre une sortie verbeuse, ce qui garantit que tous les détails pertinents sont affichés :

      • whois -h whois.cymru.com " -v as14061"

      La sortie affichera de plus amples informations sur le SA :

      Output

      AS | CC | Registry | Allocated | AS Name 14061 | US | arin | 2012-09-25 | DIGITALOCEAN-ASN, US

      Vous avez identifié les principaux détails concernant le(s) réseau(x) que vous souhaitez surveiller. Prenez note de ces détails quelque part, car vous en aurez besoin plus tard. Ensuite, vous commencerez la configuration de BGPalerter.

      Étape 2 — Création d’un utilisateur sans privilège pour BGPalerter

      Au cours de cette étape, vous allez créer un nouveau compte utilisateur sans privilège pour BGPalerter, car le programme n’a pas besoin de fonctionner avec les privilèges sudo/root.

      Tout d’abord, créez un nouvel utilisateur avec un mot de passe désactivé :

      • sudo adduser --disabled-password bgpalerter

      Vous n’avez pas besoin de définir un mot de passe ou des clés SSH, car vous utiliserez cet utilisateur uniquement comme compte de service pour l’exécution/la maintenance de BGPalerter.

      Connectez-vous au nouvel utilisateur à l’aide de su :

      Vous êtes maintenant connecté en tant que nouvel utilisateur :

      bgpalerter@droplet:/home/user$
      

      Utilisez la commande cd pour vous déplacer vers le répertoire d’accueil de votre nouvel utilisateur :

      bgpalerter@droplet:/home/user$ cd
      bgpalerter@droplet:~$
      

      Vous avez créé un nouvel utilisateur sans privilège pour BGPalerter. Ensuite, vous installerez et configurerez BGPalerter sur votre système.

      Étape 3 — Installation et configuration de BGPalerter

      Au cours de cette étape, vous allez installer et configurer BGPalerter. Assurez-vous d’être toujours connecté en tant que nouvel utilisateur sans privilège.

      Tout d’abord, vous devez identifier la dernière version de BGPalerter, afin de vous assurer que vous téléchargez la version la plus récente. Naviguez vers la page BGPalerter Releases et sélectionnez une copie du lien de téléchargement de la version Linux x64 la plus récente.

      Vous pouvez maintenant télécharger une copie de BGPalerter en utilisant wget, en vous assurant de substituer le bon lien de téléchargement :

      • wget https://github.com/nttgin/BGPalerter/releases/download/v1.24.0/bgpalerter-linux-x64

      Une fois le téléchargement du fichier terminé, marquez-le comme exécutable :

      • chmod +x bgpalerter-linux-x64

      Ensuite, vérifiez que BGPalerter a été téléchargé et installé avec succès en vérifiant le numéro de version :

      • ./bgpalerter-linux-x64 --version

      Le numéro de la version actuelle sera alors affiché :

      Output

      1.24.0

      Avant de pouvoir exécuter correctement BGPalerter, vous devez définir les réseaux que vous souhaitez surveiller dans un fichier de configuration. Créez et ouvrez le fichier prefixes.yml dans votre éditeur de texte préféré :

      Dans ce fichier de configuration, vous spécifierez chacune des adresses IP individuelles, des plages d’adresses IP et des numéros SA que vous souhaitez surveiller.

      Ajoutez l’exemple suivant et ajustez les valeurs de configuration selon les besoins, en utilisant les informations réseau que vous avez identifiées à l’Étape 1 :

      ~/prefixes.yml

      your-ip-address/32:
        description: My Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      157.230.80.0/20:
        description: IP range for my Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      options:
        monitorASns:
          '14061':
            group: default
      

      Vous pouvez surveiller autant de plages d’adresses IP ou de numéros SA que vous le souhaitez. Pour surveiller les adresses IP individuelles, représentez-les en utilisant /32 pour IPv4, et /128 pour IPv6.

      La valeur ignoreMorespecifics est utilisée pour contrôler si BGPalerter doit ignorer l’activité pour les itinéraires qui sont plus spécifiques (plus petits) que celui que vous surveillez. Par exemple, si vous surveillez un /20 et qu’un changement de routage est détecté pour un /24 à l’intérieur de celui-ci, cela est considéré comme plus spécifique. Dans la plupart des cas, vous ne voulez pas les ignorer, mais si vous surveillez un grand réseau avec plusieurs préfixes clients délégués, cela peut contribuer à réduire le bruit de fond.

      Vous pouvez maintenant lancer BGPalerter pour la première fois, afin de commencer à surveiller vos réseaux :

      Si BGPalerter démarre avec succès, vous obtiendrez une sortie similaire à celle qui suit. Notez qu’il faut parfois quelques minutes pour que la surveillance commence :

      Output

      Impossible to load config.yml. A default configuration file has been generated. BGPalerter, version: 1.24.0 environment: production Loaded config: /home/bgpalerter/config.yml Monitoring 157.230.80.0/20 Monitoring your-ip-address/32 Monitoring AS 14061

      BGPalerter continuera de fonctionner jusqu’à ce que vous l’arrêtiez en utilisant Ctrl+C.

      Dans l’étape suivante, vous interpréterez certaines des alertes que BGPalerter peut générer.

      Étape 4 — Interprétation des alertes BGPalerter

      Dans cette étape, vous allez examiner quelques exemples d’alertes BGPalerter. BGPalerter émettra des alertes sur le flux de sortie principal, ainsi qu’en option sur tout autre point final de rapport pouvant être configuré dans config.yml, comme décrit dans la documentation de BGPalerter.

      Par défaut, BGPalerter surveille et alerte sur les points suivants :

      • Détournement d’itinéraire : se produit lorsqu’un SA annonce un préfixe qu’il n’est pas autorisé à utiliser, ce qui entraîne un acheminement erroné du trafic. Il peut s’agir soit d’une attaque délibérée, soit d’une erreur de configuration accidentelle.

      • Perte de visibilité de l’itinéraire : un itinéraire est considéré comme visible lorsqu’une majorité de routeurs BGP sur Internet sont capables de l’atteindre de manière fiable. La perte de visibilité signifie que votre réseau est potentiellement indisponible, par exemple si votre peering BGP a cessé de fonctionner.

      • Annonces de nouveaux sous-préfixes : renvoie au moment où un SA commence à annoncer un préfixe plus petit que ce qui est prévu. Cela peut être le signe d’un changement de configuration prévu, d’une mauvaise configuration accidentelle ou, dans certains cas, d’une attaque.

      • Activité au sein de votre SA : fait généralement référence aux annonces de nouveaux itinéraires. Un itinéraire est considéré comme “nouveau” si BGPalerter ne le connaît pas encore.

      Vous trouverez ci-dessous quelques exemples d’alertes, ainsi qu’une brève description de leur signification :

      Alert #1

      The prefix 203.0.113.0/24 is announced by AS64496 instead of AS65540
      

      Cette alerte montre la preuve d’un détournement d’itinéraire, où l’AS64496 a annoncé 203.0.113.0/24 alors qu’il est prévu que ce itinéraire soit annoncé par l’AS65540. C’est un indicateur fort d’une mauvaise configuration menant à une fuite d’itinéraire, ou à un détournement délibéré par un agresseur.

      Alert #2

      The prefix 203.0.113.0/24 has been withdrawn. It is no longer visible from 6 peers
      

      Cette alerte montre que le réseau 203.0.113.0/24 n’est plus visible. Cela peut être dû à un problème de routage en amont, ou à une panne de courant sur un routeur.

      Alert #3

      A new prefix 203.0.113.0/25 is announced by AS64496. It should be instead 203.0.113.0/24 announced by AS64496
      

      Cette alerte montre qu’un préfixe plus spécifique a été annoncé là où il n’est pas prévu, par exemple en annonçant un /25 alors que seul un /24 est prévu. Il s’agit très probablement d’une mauvaise configuration, mais dans certains cas, cela pourrait être la preuve d’un détournement d’itinéraire.

      Alert #4

      AS64496 is announcing 192.0.2.0/24 but this prefix is not in the configured list of announced prefixes
      

      Enfin, cette alerte montre que l’AS64496 a annoncé un préfixe dont BGPalerter n’a pas encore connaissance. Cela pourrait être dû au fait que vous annoncez légitimement un nouveau préfixe, ou cela pourrait être le signe d’une mauvaise configuration qui vous amènerait à annoncer accidentellement un préfixe appartenant à quelqu’un d’autre.

      Dans cette étape, vous avez passé en revue quelques exemples d’alertes BGPalerter. Ensuite, vous configurerez BGPalerter pour qu’il s’exécute automatiquement au démarrage.

      Étape 5 — Démarrage de BGPalerter au démarrage

      Lors de cette dernière étape, vous configurerez BGPalerter pour qu’il se lance au démarrage.

      Assurez-vous que vous êtes toujours connecté en tant que nouvel utilisateur sans privilège, puis ouvrez l’éditeur crontab :

      Ensuite, ajoutez l’entrée suivante au bas du fichier crontab :

      crontab

      @reboot sleep 10; screen -dmS bgpalerter "./bgpalerter-linux-x64"
      

      À chaque fois que votre système démarrera, cela créera une session d'écran détachée appelée “bgpalerter”, et lancera BGPalerter dans cette session.

      Sauvegardez et quittez l’éditeur crontab. Vous souhaitez peut-être désormais redémarrer votre système afin de vous assurer que BGPalerter est correctement lancé au démarrage.

      Vous devez d’abord vous déconnecter de votre utilisateur BGPalerter :

      Ensuite, procédez à un redémarrage normal du système :

      Une fois que votre système a redémarré, reconnectez-vous à votre serveur et utilisez su pour accéder à nouveau à votre utilisateur BGPalerter :

      Vous pouvez alors vous joindre à la session à tout moment afin de visualiser les résultats de BGPalerter :

      Lors de cette dernière étape, vous avez configurer BGPalerter pour qu’il se lance au démarrage.

      Conclusion

      Dans cet article, vous avez configuré BGPalerter et l’avez utilisé pour surveiller les réseaux afin de détecter les changements de routage BGP.

      Si vous souhaitez rendre BGPalerter plus facile à utiliser, vous pouvez le configurer pour envoyer des alertes à un canal Slack via un webhook :

      Si vous souhaitez en savoir plus sur le BGP lui-même, mais que vous n’avez pas accès à un environnement de production de BGP, vous pouvez utiliser DN42 pour expérimenter le BGP dans un environnement sûr et isolé :



      Source link

      Comment surveiller la santé des serveurs avec Checkmk sur Ubuntu 18.04


      L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for Donations.

      Introduction

      En tant qu’administrateur de systèmes, il est préférable de connaître l’état de votre infrastructure et vos services. Idéalement, vous voulez remarquer les disques défaillants ou les temps d’arrêt des applications avant que vos utilisateurs ne le fassent. Des outils de surveillance comme Checkmk peuvent aider les administrateurs à détecter ces problèmes et à maintenir les serveurs en bon état.

      En général, les logiciels de surveillance peuvent suivre l’état du matériel, du temps de fonctionnement et des services de vos serveurs, et ils peuvent émettre des alertes en cas de problème. Dans un scénario très simple, un système de surveillance vous avertira si un service tombe en panne. Dans un scénario plus complexe, les notifications interviendraient peu après l’apparition de signes suspects, tels qu’une utilisation accrue de la mémoire ou un nombre anormal de connexions TCP.

      Il existe de nombreuses solutions de surveillance offrant divers degrés de complexité et de fonctionnalités, tant gratuites que commerciales. Dans de nombreux cas, l’installation, la configuration et la gestion de ces outils sont difficiles et prennent beaucoup de temps.

      Checkmk, cependant, est une solution de surveillance qui est à la fois robuste et plus simple à installer. Il s’agit d’un ensemble de logiciels autonomes qui combine Nagios (un service d’alerte populaire et open source) avec des modules complémentaires de collecte, de surveillance et de représentation graphique des données. Il est également fourni avec l’interface web de Checkmk – un outil complet qui répond à de nombreuses lacunes de Nagios.  Il offre un tableau de bord convivial, un système de notification complet et un référentiel d’agents de surveillance faciles à installer pour de nombreuses distributions Linux. Sans l’interface web de Checkmk, nous devrions utiliser différentes vues pour différentes tâches et il ne serait pas possible de configurer toutes ces fonctionnalités sans avoir recours à des modifications importantes des fichiers.

      Dans ce guide, nous allons configurer Checkmk sur un serveur Ubuntu 18.04 et nous allons surveiller deux hôtes distincts. Nous surveillerons le serveur Ubuntu lui-même ainsi qu’un serveur CentOS 7 séparé, mais nous pourrions utiliser la même approche pour ajouter un nombre quelconque d’hôtes supplémentaires à notre configuration de surveillance.

      Conditions préalables

      Étape 1 – Installer Checkmk sur Ubuntu

      Pour pouvoir utiliser notre site de surveillance, nous devons d’abord installer Checkmk sur le serveur Ubuntu. Cela nous donnera tous les outils dont nous avons besoin. Checkmk fournit des fichiers officiels de paquets Ubuntu, prêts à l’emploi que nous pouvons utiliser pour installer le paquet de logiciels.

      Tout d’abord, mettons à jour la liste des paquets afin d’avoir la version la plus récente des listes du référentiel :

      Pour parcourir les paquets, nous pouvons aller sur le site de la liste des paquets. Ubuntu 18.04, entre autres, peut être choisi dans le menu de la page.

      Maintenant, téléchargez le paquet :

      • wget https://checkmk.com/support/1.6.0p8/check-mk-raw-1.6.0p8_0.bionic_amd64.deb

      Ensuite, installez le paquet nouvellement téléchargé :

      • sudo apt install -y ./check-mk-raw-1.6.0p8_0.bionic_amd64.deb

      Cette commande installera le paquet Checkmk ainsi que toutes les dépendances nécessaires, y compris le serveur web Apache qui est utilisé pour fournir un accès web à l’interface de surveillance.

      Une fois l’installation terminée, nous pouvons maintenant accéder à la commande omd. Essayez-la :

      Cette commande omd donnera la sortie suivante :

      Output

      Usage (called as root): omd help Show general help . . . General Options: -V <version> set specific version, useful in combination with update/create omd COMMAND -h, --help show available options of COMMAND

      La commande omd peut gérer toutes les instances de Checkmk sur notre serveur. Elle peut démarrer et arrêter tous les services de surveillance en même temps, et nous l’utiliserons pour créer notre instance Checkmk. Cependant, nous devons d’abord mettre à jour les paramètres de notre pare-feu afin d’autoriser l’accès extérieur aux ports web par défaut.

      Étape 2 – Ajuster les paramètres du pare-feu

      Avant de pouvoir travailler avec Checkmk, il est nécessaire d’autoriser un accès extérieur au serveur web dans la configuration du pare-feu. En supposant que vous avez suivi les étapes de configuration du pare-feu citées dans les conditions préalables, vous disposerez d’un pare-feu UFW configuré pour restreindre l’accès à votre serveur.

      Au cours de l’installation, Apache s’enregistre lui-même auprès d’UFW afin de fournir un moyen facile d’activer ou de désactiver l’accès à Apache par le biais du pare-feu.

      Pour autoriser l’accès à Apache, utilisez la commande suivante :

      Vérifiez maintenant les changements :

      Vous verrez qu’Apache est listé parmi les services autorisés :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Cela nous permettra d’accéder à l’interface web de Checkmk.

      Dans l’étape suivante, nous allons créer la première instance de surveillance Checkmk.

      Étape 3 – Création d’une instance de surveillance Checkmk

      Checkmk utilise le concept d’instances ou d’installations individuelles pour isoler plusieurs copies de Checkmk sur un serveur. Dans la plupart des cas, une seule copie de Checkmk suffit et c’est ainsi que nous allons configurer le logiciel dans ce guide.

      Nous devons d’abord donner un nom à notre nouvelle instance, et nous utiliserons monitoring tout au long de ce texte. Pour créer l’instance, tapez :

      • sudo omd create monitoring

      L’outil omd configurera tout automatiquement. La sortie de la commande ressemblera à ce qui suit :

      Output

      Adding /opt/omd/sites/monitoring/tmp to /etc/fstab. Creating temporary filesystem /omd/sites/monitoring/tmp...OK Restarting Apache...OK Created new site monitoring with version 1.6.0p8.cre. The site can be started with omd start monitoring. The default web UI is available at http://your_ubuntu_server/monitoring/ The admin user for the web applications is cmkadmin with password: your-default-password (It can be changed with 'htpasswd -m ~/etc/htpasswd cmkadmin' as site user.) Please do a su - monitoring for administration of this site.

      Dans cette sortie, l’adresse URL, le nom d’utilisateur par défaut et le mot de passe pour accéder à notre interface de surveillance sont mis en évidence. L’instance est maintenant créée, mais elle doit encore être démarrée. Pour démarrer l’instance, tapez :

      • sudo omd start monitoring

      Tous les outils et services nécessaires seront maintenant démarrés en même temps. À la fin, nous verrons une sortie vérifiant que tous nos services ont démarré avec succès :

      Output

      Starting mkeventd...OK Starting rrdcached...OK Starting npcd...OK Starting nagios...OK Starting apache...OK Initializing Crontab...OK

      L’instance est opérationnelle.

      Pour accéder à l’instance Checkmk, ouvrez http://your_ubuntu_server_ip/monitoring/ dans le navigateur web. Un mot de passe vous sera demandé. Utilisez les informations d’identification par défaut imprimées au préalable à l’écran ; nous modifierons ces valeurs par défaut ultérieurement.

      L’écran Checkmk s’ouvre avec un tableau de bord, qui présente tous nos services et les statuts de nos serveurs sous forme de listes, et il utilise des graphiques pratiques ressemblant à la Terre. Immédiatement après l’installation, ces graphiques sont vides, mais nous allons bientôt faire en sorte qu’ils affichent les états de nos services et de nos systèmes.

      Tableau de bord Checkmk vierge

      Dans la prochaine étape, nous modifierons le mot de passe par défaut pour sécuriser le site à l’aide de cette interface.

      Étape 4 – Changer votre mot de passe administratif

      Au cours de l’installation, Checkmk génère un mot de passe aléatoire pour l’utilisateur administratif de cmkadmin. Ce mot de passe est censé être modifié lors de l’installation, et, par conséquent, il est souvent court et peu sûr. Nous pouvons modifier cela via l’interface web.

      Tout d’abord, ouvrez la page USERS depuis le menu WATO – Configuration à gauche. La liste affichera tous les utilisateurs qui ont actuellement accès au site Checkmk. Dans le cas d’une nouvelle installation, la liste ne comprendra que deux utilisateurs. Le premier, automation, est destiné à être utilisé avec des outils automatisés ; le second est l’utilisateur cmkadmin que nous avons utilisé pour nous connecter au site.

      Liste des utilisateurs Checkmk

      Cliquez sur l’icône représentant un crayon à côté de l’utilisateur cmkadmin pour modifier ses coordonnées, y compris le mot de passe.

      Formulaire d'édition pour l'utilisateur Checkmk admin

      Mettez à jour le mot de passe, ajoutez un courriel admin et effectuez toute autre modification désirée.

      Après avoir enregistré les modifications, il nous sera demandé de nous connecter à nouveau en utilisant nos nouveaux identifiants. Faites-le et revenez au tableau de bord, où il y a encore une chose que nous devons faire pour appliquer pleinement notre nouvelle configuration.

      Ouvrez à nouveau la page Users dans le menu WATO – Configuration sur la gauche. Le bouton orange dans le coin supérieur gauche intitulé 1 Change nous indique que nous avons apporté quelques modifications à la configuration de Checkmk, et que nous devons les enregistrer et les activer. Cela se produira chaque fois que nous modifierons la configuration de notre système de surveillance, et pas seulement après avoir modifié les informations d’identification d’un utilisateur. Pour enregistrer et activer les changements en attente, nous devons cliquer sur ce bouton et accepter d’activer les changements énumérés à l’aide de l’option Activate affected​​ sur l’écran suivant.

      Liste des utilisateurs de Checkmk après modificationsÉcran de confirmation de l'activation des changements de configurationChangements de configuration activés avec succès

      Après l’activation des changements, les données du nouvel utilisateur sont écrites dans les fichiers de configuration et seront utilisées par tous les composants du système. Checkmk se charge automatiquement de notifier les différents composants du système de surveillance, de les recharger si nécessaire et de gérer tous les fichiers de configuration nécessaires.

      L’installation Checkmk est maintenant prête à être utilisée. Dans l’étape suivante, nous ajouterons le premier hôte à notre système de surveillance.

      Étape 5 – Surveillance du premier hôte

      Nous sommes maintenant prêts à surveiller le premier hôte. Pour ce faire, nous allons d’abord installer check-mk-agent sur le serveur Ubuntu. Ensuite, nous limiterons l’accès aux données de surveillance en utilisant xinetd.

      Les composants installés avec Checkmk sont responsables de la réception, du stockage et de la présentation des informations de surveillance. Ils ne fournissent pas les informations elles-mêmes.

      Pour recueillir les données réelles, nous utiliserons Checkmk agent. Conçu spécifiquement pour ce travail, l’agent Checkmk est capable de surveiller tous les composants vitaux du système en une seule fois et de renvoyer ces informations à l’instance Checkmk.

      Installer l’agent

      Le premier hôte que nous surveillerons sera your_ubuntu_server—le serveur sur lequel nous avons installé l’instance Checkmk elle-même.

      Pour commencer, nous devons installer l’agent Checkmk. Les paquets de toutes les distributions principales, y compris Ubuntu, sont disponibles directement à partir de l’interface web. Ouvrez la page Monitoring Agents depuis le menu WATO – Configuration à gauche. Vous verrez les téléchargements d’agents disponibles avec les paquets les plus populaires sous la première section intitulée Packaged agents.

      Liste des agents de surveillance packagés disponibles

      Le paquet check-mk-agent_1.6.0p8-1_all.deb est celui adapté aux distributions basées sur Debian, y compris Ubuntu. Copiez le lien de téléchargement de ce paquet depuis le navigateur web et utilisez cette adresse pour télécharger le paquet.

      • wget http://your_ubuntu_server_ip/monitoring/check_mk/agents/check-mk-agent_1.6.0p8-1_all.deb

      Après le téléchargement, installez le paquet :

      • apt install -y ./check-mk-agent_1.6.0p8-1_all.deb

      Vérifiez maintenant que l’agent a été installé avec succès :

      La commande produira un texte très long qui ressemble à du charabia mais qui regroupe toutes les informations vitales sur le système en un seul endroit.

      Output

      <<<check_mk>>> Version: 1.6.0p8 AgentOS: linux . . . ["monitoring"] <<<job>>> <<<local>>>

      C’est la sortie de cette commande que Checkmk utilise pour recueillir les données d’état des hôtes surveillés. Maintenant, nous allons restreindre l’accès aux données de surveillance avec xinetd.

      Restreindre l’accès aux données de surveillance à l’aide de xinetd

      Par défaut, les données de check_mk_agent sont servies par xinetd, un mécanisme qui produit des données sur un certain port de réseau lors de l’accès. Cela signifie que nous pouvons accéder au check_mk_agent en utilisant telnet sur le port 6556 (le port par défaut pour Checkmk) depuis n’importe quel autre ordinateur sur Internet, à moins que la configuration de notre pare-feu ne le refuse.

      Ce n’est pas une bonne politique de sécurité que de publier à quiconque des informations vitales concernant les serveurs sur l’internet. Nous devons autoriser uniquement les hôtes qui exécutent Checkmk (et qui sont sous notre supervision) à accéder à ces données, de sorte que seul notre système de surveillance puisse les collecter.

      Si vous avez suivi le tutoriel de configuration initiale du serveur, y compris les étapes relatives à la mise en place d’un pare-feu, l’accès à l’agent Checkmk est bloqué par défaut. Il est toutefois recommandé d’appliquer ces restrictions d’accès directement dans la configuration du service et de ne pas compter uniquement sur le pare-feu pour le protéger.

      Pour restreindre l’accès aux données de l’agent, nous devons éditer le fichier de configuration à l’adresse /etc/xinetd.d/check_mk. Ouvrez le fichier de configuration dans votre éditeur préféré. Pour utiliser nano, tapez :

      • sudo nano /etc/xinetd.d/check_mk

      Localisez cette section :

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      #only_from      = 127.0.0.1 10.0.20.1 10.0.20.2
      . . .
      

      Le paramètre only_from est responsable de la restriction de l’accès à certaines adresses IP. Comme nous travaillons maintenant à la surveillance du même serveur que celui sur lequel tourne Checkmk, il est normal de n’autoriser que localhost à se connecter. Décommentez et mettez à jour le paramètre de configuration :

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      only_from      = 127.0.0.1
      . . .
      

      Enregistrez et quittez le fichier.

      Le démon xinetd doit être redémarré pour que les changements soient pris en compte. Faites-le maintenant :

      • sudo systemctl restart xinetd

      Notre agent est maintenant opérationnel et est limité pour n’accepter que les connexions locales. Nous pouvons procéder à la configuration de la surveillance pour cet hôte en utilisant Checkmk.

      Configurer l’hôte dans l’interface web Checkmk

      Tout d’abord, pour ajouter un nouvel hôte à surveiller, nous devons nous rendre dans le menu Hosts du menu WATO – Configuration (à gauche). À partir d’ici, cliquez sur Create new host. Nous serons invités à donner quelques informations sur l’hôte.

      Créer un nouvel hôte dans Checkmk

      Le Hostname est le nom familier que Checkmk utilisera pour la surveillance. Il peut s’agir d’un nom de domaine pleinement qualifié, mais ce n’est pas nécessaire. Dans cet exemple, nous nommerons l’hôte monitoring, tout comme le nom de l’instance de Checkmk elle-même. Comme monitoring ne peut pas être résolu à notre adresse IP, nous devons également fournir l’adresse IP de notre serveur. Et comme nous surveillons l’hôte local, l’IP sera simplement 127.0.0.1. Cochez la case IPv4 Adresse pour activer la saisie manuelle de l’adresse IP et entrez la valeur dans le champ de texte.

      La configuration par défaut de la section Data Sources repose sur Checkmk pour fournir des données de surveillance, ce qui est bien. Le paramètre Networking Segment​​​ est utilisé pour désigner les hôtes sur les réseaux distants, qui se caractérisent par une latence attendue plus élevée qui ne constitue pas un signe de dysfonctionnement. Comme il s’agit d’un hôte local, le paramètre par défaut est également correct.

      Pour enregistrer l’hôte et configurer les services à surveiller, cliquez sur le bouton Save & go to services.

      Liste des services disponibles à surveiller

      Checkmk fera un inventaire automatique. Cela signifie qu’il recueillera les informations fournies par l’agent et les déchiffrera pour savoir quels types de services il peut contrôler. Tous les services disponibles pour la surveillance figureront sur la liste, y compris la charge du processeur, l’utilisation de la mémoire et l’espace libre sur les disques.

      Pour permettre la surveillance de tous les services découverts, nous devons cliquer sur le bouton Monitor sous la section Undecided services ( actuellement non surveillés). La page sera ainsi actualisée, mais tous les services seront désormais répertoriés sous la section Monitored services, nous informant qu’ils sont effectivement surveillés.

      Comme c’était le cas lors de la modification de notre mot de passe utilisateur, ces nouveaux changements doivent être enregistrés et activés avant d’être effectifs. Appuyez sur le bouton “2 changes” et acceptez les changements en utilisant le bouton Activate affected. Après cela, la surveillance de l’hôte sera opérationnelle.

      Vous êtes maintenant prêt à travailler avec les données de votre serveur. Jetez un coup d’œil au tableau de bord principal en utilisant l’élément de menu Overview/Main Overview sur la gauche.

      Travailler avec les données de surveillance

      Examinons maintenant le tableau de bord principal à l’aide de l’élément de menu Overview/Main Overview sur la gauche :

      Tableau de bord de surveillance avec tous les services en état de marche

      La sphère terrestre est maintenant entièrement verte et le tableau indique qu’un hôte est en place sans aucun problème. Nous pouvons voir la liste complète des hôtes, qui se compose maintenant d’un seul hôte, dans la vue Hosts/All hosts (en utilisant le menu à gauche).

      Liste des hôtes avec tous les services en état de marche

      Nous y verrons combien de services sont en bonne santé (indiqués en vert), combien sont défaillants et combien sont en attente de contrôle. Après avoir cliqué sur le nom d’hôte, nous pourrons voir la liste de tous les services avec leur statut complet et leur Perf-O-Meters. Le Perf-O-Mètre montre la performance d’un seul service par rapport à ce que Checkmk considère comme une bonne santé.

      Détails sur l'état d'un service hôte

      Tous les services qui renvoient des données graphiques affichent une icône graphique à côté de leur nom. Nous pouvons utiliser cette icône pour accéder aux graphiques associés au service. Comme la surveillance de l’hôte est récente, il n’y a presque rien sur les graphiques – mais après un certain temps, les graphiques fourniront des informations précieuses sur l’évolution des performances de notre service dans le temps.

      Graphiques représentant la charge du CPU sur le serveur

      En cas de défaillance ou de rétablissement de l’un de ces services, les informations seront affichées sur le tableau de bord. Pour les services défaillants, une erreur rouge sera affichée, et le problème sera également visible sur le graphique de la Terre.

      Tableau de bord avec un hôte ayant des problèmes

      Après la reprise, tout sera indiqué en vert comme fonctionnant correctement, mais le journal des événements sur la droite contiendra des informations sur les défaillances passées.

      Tableau de bord avec un hôte restauré suite à des problèmes

      Maintenant que nous avons un peu exploré le tableau de bord, ajoutons un second hôte à notre instance de surveillance.

      Étape 6 – Surveillance d’un deuxième hôte CentOS

      La surveillance devient vraiment utile lorsque vous avez plusieurs hôtes. Nous allons maintenant ajouter un deuxième serveur à notre instance Checkmk qui, cette fois-citourne sous CentOS 7.

      Comme pour notre serveur Ubuntu, l’installation de l’agent Checkmk est nécessaire pour recueillir les données de surveillance sur CentOS. Cette fois, cependant, nous aurons besoin d’un paquet rpm de la page Monitoring Agents de l’interface web, appelé check-mk-agent-1.6.0p8-1.noarch.rpm.

      Mais nous devons d’abord installer xinetd, qui par défaut n’est pas disponible sur l’installation de CentOS. Xinetd, rappelons-le, est un démon qui est chargé de rendre disponibles sur le réseau les données de surveillance fournies par check_mk_agent.

      Sur votre serveur CentOS, installez d’abord xinetd :

      • sudo yum install -y xinetd

      Nous pouvons maintenant télécharger et installer le paquet de l’agent de surveillance nécessaire à notre serveur CentOS :

      • sudo yum install -y http://your_ubuntu_server_ip/monitoring/check_mk/agents/check-mk-agent-1.6.0p8-1.noarch.rpm

      Tout comme précédemment, nous pouvons vérifier que l’agent fonctionne correctement en exécutant check_mk_agent :

      La sortie sera semblable à celle du serveur Ubuntu. Nous allons maintenant restreindre l’accès à l’agent.

      Restriction de l’accès

      Cette fois, nous ne surveillerons pas un hôte local, donc xinetd doit permettre les connexions provenant du serveur Ubuntu, où Checkmk est installé, pour recueillir les données. Pour cela, ouvrez d’abord votre fichier de configuration :

      • sudo vi /etc/xinetd.d/check_mk

      Vous y verrez la configuration de votre service check_mk, en précisant comment l’agent Checkmk peut être accessible via le démon xinetd. Trouvez les deux lignes commentées suivantes :

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      #only_from      = 127.0.0.1 10.0.20.1 10.0.20.2
      . . .
      

      Décommentez maintenant la deuxième ligne et remplacez les adresses IP locales par your_ubuntu_server_ip:

      /etc/xinetd.d/check_mk

      . . .
      # configure the IP address(es) of your Nagios server here:
      only_from      = your_ubuntu_server_ip
      . . .
      

      Enregistrez et quittez le fichier en tapant :x et ensuite ENTER. Redémarrez le service xinetd en utilisant :

      • sudo systemctl restart xinetd

      Nous pouvons maintenant procéder à la configuration de Checkmk pour surveiller notre hôte CentOS 7.

      Configurer le nouvel hôte dans Checkmk

      Pour ajouter des hôtes supplémentaires à Checkmk, nous utilisons le menu Hosts comme auparavant. Cette fois-ci, nous allons nommer l’hôte centos, configurer son adresse IP et choisir WAN (high-latency) sous la case Networking Segment, puisque l’hôte est sur un autre réseau. Si nous laissons cette option en local, Checkmk nous avertira rapidement que l’hôte est hors service, car il s’attend à ce qu’il réponde aux requêtes des agents beaucoup plus rapidement qu’il n’est possible sur Internet.

      Créer l'écran de configuration d'un deuxième hôte

      Cliquez sur “Save & go to services”, qui affichera les services disponibles pour la surveillance sur le serveur CentOS. La liste sera très similaire à celle du premier hôte. Là encore, nous devons également cliquer sur Monitor et ensuite activer les changements à l’aide du bouton orange situé dans le coin supérieur gauche.

      Après l’activation des changements, nous pouvons vérifier que l’hôte est surveillé sur la page All hosts. Allez sur cette page. Deux hôtes, monitoring et centos, seront maintenant visibles.

      Liste des hôtes avec deux hôtes surveillés

      Vous surveillez maintenant un serveur Ubuntu et un serveur CentOS avec Checkmk. Il est possible de surveiller encore plus d’hôtes. En fait, il n’y a pas de limite supérieure autre que la performance du serveur, ce qui ne devrait pas poser de problème tant que vos hôtes ne se comptent pas par centaines. En outre, la procédure est la même pour tout autre hôte. Les agents Checkmk dans les paquets deb et rpm fonctionnent sur Ubuntu, CentOS et la majorité des autres distributions Linux.

      Conclusion

      Dans ce guide, nous avons configuré deux serveurs avec deux distributions Linux différentes : Ubuntu et CentOS. Nous avons ensuite installé et configuré Checkmk pour surveiller les deux serveurs, et nous avons exploré la puissante interface web de Checkmk.

      Checkmk permet de mettre en place facilement un système de surveillance complet et polyvalent, qui regroupe tout le travail de configuration manuelle dans une interface web facile à utiliser, pleine d’options et de fonctionnalités. Avec ces outils, il est possible de surveiller plusieurs hôtes, de configurer des notifications par courriel, SMS ou push en cas de problème, de mettre en place des contrôles supplémentaires pour plus de services, de surveiller l’accessibilité et les performances, etc.

      Pour en savoir plus sur Checkmk, n’oubliez pas de consulter la documentation officielle.



      Source link