Surveillance et gestion à distance des appareils basés sur Linux/OpenWrt/Lede via le port 80, suite

Ceci est la dernière partie de l'article, voici le début habr.com/en/post/445568
La dernière fois que j'ai écrit sur la façon dont j'ai mis en œuvre la surveillance des appareils, nous allons maintenant parler de gestion. Lors des discussions avec les « techniciens » du côté client, je rencontre souvent une perception limitée des capacités de ces petits appareils (avec des ressources mémoire et des performances faibles), beaucoup pensent que « tout ce dont nous avons besoin est d'envoyer un redémarrage, pour quelque chose de plus sérieux, nous enverrons une équipe ».
Mais la pratique montre que ce n’est pas tout à fait vrai. Voici une petite liste de tâches typiques courantes :

1. Diagnostic et dépannage réseau. Derrière le port Ethernet de votre routeur se trouve généralement un autre élément matériel doté de sa propre adresse IP interne. Parfois, vous pouvez (devriez) le « pinger ». Ou la gestion du tunnel - si le tunnel ne monte soudainement pas sur un routeur fonctionnant via un modem 3G, mais que nous pouvons voir le routeur lui-même.
2. Entretien du système. Mise à jour du micrologiciel, mise à niveau du script de service.
3. Acte d’équilibriste. Cela pourrait être appelé « perversion », mais le concept d’« équilibriste » tel que, je cite, "la capacité d'un artiste de cirque à maintenir l'équilibre dans une position corporelle instable" - va mieux. De telles situations surviennent en raison du budget limité du client. Ci-dessous, j'ai donné quelques exemples, mais... Ils ne sont pas directement liés au thème de l'histoire, je les mets dans les notes

Surveillance Wi-FiUn sujet à la mode depuis cinq ans, surtout parmi les chaînes de vente au détail fédérales. Vous vous promenez tranquillement dans les salles des marchés et votre téléphone portable avec le Wi-Fi activé, pour tenter de « coller » à un fil du réseau, envoie régulièrement des paquets de requêtes de sonde, qui peuvent être analysés afin de calculer pour vous : à quelle fréquence venez-vous dans ce magasin, pour quelles raisons ? vous marchez selon des trajectoires, etc. Ensuite, les données sont collectées, analysées, des cartes thermiques sont dessinées et les managers « extorquent » de l'argent à la direction ou aux investisseurs pour de telles images. Bon, pour l'instant... "il n'y a pas d'argent, mais tu tiens bon...", et le résultat (réel) doit déjà être montré, la bonne vieille chanson commence : "Oui, oui, alors bien sûr nous va installer le cis et tout ce que vous voulez, mais maintenant nous devons montrer le résultat au client ! Nous avons d’ailleurs oublié de préciser que le Client nous permettait de connecter nos équipements à son hotspot via Wi-Fi, mais de manière générale, comme si nous étions des clients invités. Et nous devons donc créer des routeurs d'équilibrage - plusieurs sous-interfaces WiFi sont soulevées, dont l'une s'accroche au point d'accès, et la seconde surveille l'environnement, télécharge frénétiquement le résultat tcpdump sur elle-même, puis emballe le contenu du fichier dans une archive et risque mourant de « trop manger » essaie de recracher le contenu sur le serveur FTP. Il n'est pas surprenant que le routeur d'équilibrage « tombe en panne » souvent et doive être « réanimé » à distance.

RayonIl est plus facile de décrire la situation ici avec quelque chose comme cette déclaration du client : « Nous voulons un réseau décentralisé de hotspots qui fonctionneraient sur des équipements dont le modèle n'est pas connu à l'avance, via des canaux, mais lesquels on ne connaît pas encore. Oh, nous avons oublié de dire que nous voulons non seulement montrer de la publicité aux clients, mais également tout analyser autour de l'emplacement où le hotspot est installé. Non, nous ne savons pas encore pourquoi, mais nous allons le découvrir, n’en doutez pas, nous avons pu avoir cette idée.

Et il ne faut pas oublier qu'en raison de nombreuses circonstances jusqu'alors inconnues, le contrôle doit être effectué dans des conditions non standard, lorsque nous ne pouvons pas nous connecter directement au routeur via le port IP : et sommes obligés d'attendre simplement l'activité de celui-ci. Si l'on fait abstraction, le dialogue entre le serveur et le routeur peut être représenté ainsi :

• Routeur: Bonjour. Je suis tel ou tel routeur, y a-t-il des tâches à me confier ?
• Serveur: routeur tel ou tel, je t'ai enregistré, que tu es vivant. Voici le défi : me montrer le résultat de la commande ifconfig ?
• Routeur: Bonjour. Je suis tel ou tel routeur, la dernière fois que vous avez demandé de montrer le résultat d'ifconfig, le voici. Y a-t-il des tâches pour moi ?
• Serveur: routeur tel ou tel, je t'ai enregistré, que tu es vivant. Il n'y a aucune tâche pour vous.

La question la plus intéressante : comment un routeur distant peut-il envoyer une certaine quantité d'informations ? Dans la dernière partie, j'ai décrit qu'en raison de ressources limitées, le routeur ne dispose que d'un wget « allégé », qui fonctionne uniquement via GET et rien d'autre ; il n'y a pas de client FTP ni de curl. Plus précisément, nous avons besoin d'une méthode universelle, quelles que soient les caractéristiques de l'assemblage d'images. J'ai décidé d'utiliser wget. Plus précisément, comment j'ai "arrêté" - je n'avais tout simplement pas le choix :)

Juste un avertissementMa solution de gestion fonctionne, pas très limitée, et je suis sûr qu’elle est tordue, même si elle convient à la plupart de mes clients. Comment pourriez-vous le faire judicieusement - écrivez un petit utilitaire qui envoie des données binaires POST via le port 80. Incluez-le (l'utilitaire) dans le micrologiciel du routeur et accédez-y à l'aide de bash. Mais la réalité est la suivante : a) nous devons agir rapidement b) nous devons probablement tout faire sur le « zoo de routeurs » existant c) « ne pas faire de mal ! — si le routeur fonctionne et effectue d'autres tâches, essayez d'apporter des modifications qui n'affecteront pas les fonctionnalités existantes.

Passons à la mise en œuvre. Disons que votre client souhaite redémarrer le routeur à partir de Zabbix facilement et naturellement, d'un « clic de souris ». Aujourd'hui, nous allons commencer à décrire l'implémentation avec Zabbix.
Dans le menu « Administration » -> « Scripts », ajoutez un nouveau script. Nous l'appelons "Reboot", entrez "php /usr/share/zabbix/reboot.php {HOST.HOST}" comme commande

Suivant : Menu « Surveillance » -> « Dernières données » -> « Clic droit sur le nœud de réseau souhaité. » Voici à quoi ressemblera le menu après l'ajout du script.

En conséquence, nous plaçons le script reboot.php dans le répertoire /usr/share/zabbix (le vôtre peut être différent, j'utilise le répertoire racine zabbixa).

Avertissement de sécuritéPour rendre l'explication plus claire dans le script, j'utilise uniquement l'identifiant du routeur, mais n'utilise pas le mot de passe. Il n'est pas recommandé de faire cela dans la version de production ! Pourquoi ai-je fait cela : parce que la grande question est de savoir où stocker les mots de passe des routeurs ? Dans zabbixe lui-même dans « données d'inventaire » ? Une pratique controversée. Alternativement : restreindre l'accès externe au fichier reboot.php lui-même

Fichier reboot.php

<?php
	// присваиваем параметры с консоли переменным
	$user = $argv[1];
	// ВНИМАНИЕ. Вот здесь в целях безопасности все-таки прописывать пароль устройства! Но для демонстрации мы будем обращаться к базе данных без использования пароля. 
	//$password = $argv[2];
		
	$conn=new mysqli("localhost","db_user","db_password","db_name");
	if (mysqli_connect_errno()) {
		exit();
	}
	$conn->set_charset("utf8");
			
	// "Отправляем" команду reboot за счет изменения поля task таблицы users. В поле task можно отправлять любую команду.
	$sql_users=$conn->prepare("UPDATE users SET task='reboot' WHERE id=? AND status='active';");
	$sql_users->bind_param('s', $user);
	$sql_users->execute();
	$sql_users->close();
?>

C'est tout. La question reste ouverte : « comment obtenir le résultat de l'exécution d'une commande depuis l'appareil ». Examinons la tâche en utilisant la commande ifconfig comme exemple. Cette commande peut être envoyée à l'appareil :

message=`ifconfig`; wget "http://xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php?u=user&p=password!&m=$message" -O /tmp/out.txt

, où:
message=`ifconfig` — nous attribuons le résultat de la sortie de la commande ifconfig à la variable $message
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — notre script a.php qui enregistre les routeurs et reçoit des messages de leur part
u=utilisateur&p=mot de passe!&m=$message — les informations d'identification et la valeur de la variable de requête m — attribue le contenu de la variable $message
-O /tmp/out.txt — nous n'avons pas besoin de sortie dans le fichier /tmp/out.txt dans ce cas, mais si ce paramètre n'est pas spécifié, wget ne fonctionne pas

Pourquoi ça ne marche pas ?Parce que c'est une faille de sécurité potentielle. L'erreur la plus inoffensive qui puisse se produire est si, par exemple, il y a un caractère « & » dans la sortie de votre commande. Par conséquent, il est nécessaire de filtrer à la fois tout ce qui est envoyé depuis les routeurs et tout ce qui arrive au serveur. Ouais, j'ai vraiment honte. Pour ma défense, je peux seulement écrire que l'intégralité de l'article est consacrée à la façon de gérer des routeurs avec des firmwares prédéfinis et des canaux de communication qui ne sont pas définis à l'avance.

Eh bien, un début pour l'avenir : je n'ai pas encore compris comment utiliser les outils zabbix standard pour refléter les résultats (par exemple, le résultat de l'exécution d'une commande) qui arrivent au serveur.

Je vous rappelle que toutes les sources peuvent être obtenues depuis le dépôt Git à l'adresse : github.com/BazDen/iotnet.online.git

Source: habr.com