Remote monitoring and management of Linux / OpenWrt / Lede-based devices through port 80, continued

bazden April 1, 2019 at 10:41

Remote monitoring and management of Linux / OpenWrt / Lede-based devices through port 80, continued

Tutorial

This is the final part of the article, here is the beginning .

The last time I wrote about how I implemented device monitoring, now we will focus on management. In discussions with "techies" on the part of the Customer, I often encounter a limited perception of the capabilities of such small devices (with low memory resources and performance), many people think that "the maximum that we need is to send a reboot, for something more serious - we will send a team" .

But practice shows that this is not entirely true.

Here is a short list of common common tasks:

Network diagnostics and troubleshooting. Behind the ethernet port of your router, another piece of hardware usually has its own internal IP address. Sometimes, it can (need) "ping". Or tunnel management - if a router that doesn’t suddenly go up on a router running through a 3G modem, but we see the router itself.
System service. Firmware upgrade, service script upgrade.
Balancing act. This could be called "perversions", but the concept of "balancer" as, I quote, "the ability of a circus artist to maintain balance in an unstable position of the body" is more suitable. Similar situations arise due to the limited budget of the customer. Below are a couple of examples, but because they have no direct relation to the subject of the narrative, put them in notes

Wifi monitoring

A fashionable topic for the last five years is mainly among federal retail chains. You walk slowly through the trading floors, and your mobile phone with Wi-Fi turned on in an attempt to “stick” to some network thread regularly sends Probe Request packets that can be analyzed to calculate how often you come to this store, for what walk the trajectories and so on. Then the data is collected, analyzed, heat maps are drawn and managers for such pictures “knock out” money from management or investors. In the meantime .... "there is no money, but you hold on ...", and the result (real) must already be shown, the good old song is included "Yes, yes, then of course we will put tsiska and whatever we want, but now we need show the customer the result! By the way, they forgot to say that the Customer allowed our equipment to be connected to his hotspot via Wi-Fi, but on a general basis, it’s just as if we are guest clients. ” And now you have to make routers-balancers - several WiFi subinterfaces rise, one of which clings to a hotspot, and the second monitors the environment, frantically unloads the result of tcpdump into itself, then the contents of the file are packed into the archive and risking dying from "overeating" trying to spit out the contents on the ftp server. It is not surprising that the router-balancer often “breaks down” and somehow has to be remotely resuscitated. then the contents of the file are packed into the archive and at the risk of dying from "overeating", it tries to spit the contents out onto the ftp server. It is not surprising that the router-balancer often “breaks down” and somehow has to be remotely resuscitated. then the contents of the file are packed into the archive and at the risk of dying from "overeating", it tries to spit the contents out onto the ftp server. It is not surprising that the router-balancer often “breaks down” and somehow has to be remotely resuscitated.

Radius

Here it’s easier to describe the situation with something like this statement by the customer: “We want a decentralized network of hotspots that work on equipment whose model is not known in advance, through channels, but which we don’t know yet. Ah, they forgot to say, we not only want to show ads to customers, but also analyze everything around the place of installation of the hotspot. No, we don’t know why yet, but we’ll come up, don’t doubt, we were able to come up with this idea ”

And we must not forget that due to the mass of circumstances uncertain in advance, control should be carried out in non-standard conditions, when we cannot connect to the router directly via ip: the port and are forced to just wait for activity from it. If we ignore it, then the dialogue between the server and the router can be represented like this:

Router : hi. I am such a router, are there any tasks for me?
Server : such and such a router I registered you that you are alive. Here's the task: show me the result of the ifconfig command?
Router : hi. I’m such a router, the last time you asked me to show the result of ifconfig, here it is. Are there any tasks for me?
Server : such and such a router I registered you that you are alive. There are no tasks for you.

The most interesting question: how can a remote router send a certain amount of information? In the last part, I described that on the router due to limited resources there is only a "stripped down" wget that works only through GET and nothing else, there is no ftp client or curl. More precisely, we need a universal way, regardless of the features of the image assembly. I settled on using wget. More precisely, how I “stopped” - I just had no choice :)

Immediately reservation

My management solution is working, but very limited and I'm sure it is crooked, even if it suits most of my customers. How it would be possible to do it wisely - to write a small utility that sends binary data through the 80th port. Include it (utility) in the firmware of the router and use bash to access it. But the reality is that: a) you need to quickly b) maybe you need to do everything on the existing “router zoo” c) “do no harm!” - if the router works and performs other tasks, try to make changes that will affect the existing functionality.

Let's move on to implementation. Let's say your customer wants from zabbix to reboot the router easily and naturally, with a “click of the mouse." Today we will begin the description of implementation with zabbiksa.

In the menu "Administration" -> "Scripts" add a new script. We call it “Reboot”, as a command we set it to “php /usr/share/zabbix/reboot.php {HOST.HOST}”

Next: Menu “Monitoring” -> “Recent data” -> “Right-click on the node network ". This is how the menu will look after adding a script.

Accordingly, we put the reboot.php script in the / usr / share / zabbix directory (you may have a different one, I use the zabbixa root directory).

Disclaimer for safety

For clarity of explanation in the script, I use only the id of the router, but I do not use the password. In the working version, this is not recommended! Why did I do this: because the big question is where to store passwords for routers? In zabbixe itself in the "inventory"? Contradictory practice. As an option: restrict external access to the reboot.php file itself

Reboot.php file

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();
?>

Actually everything. The question “how to get the result of the execution of a command from the device side” remains open. Consider the problem using the ifconfig command as an example. This command can be sent to the device:

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

, where:
message = `ifconfig` - we assign the $ message variable to the result of the output of the ifconfig
wget command “ xn - 80abgfbdwanb2akugdrd3a2e5gsbj.xn - p1ai / a.php - our a.php script that registers routers and receives messages from them
u = user & p = password! & m = $ message - credentials and the value of the request variable m - assigns the contents of the variable $ message
-O /tmp/out.txt - we do not need output to the file /tmp/out.txt, but if you do not specify this parameter, wget does not work

Why does it work crookedly

Because it is a potential security hole. the most harmless mistake that can happen is if, for example, there is a “&” symbol in the output of your command. Therefore, it is necessary to filter everything that is sent from routers and everything that comes to the server. Yeah, I'm ashamed, really. In my defense, I can only write - that the whole article is devoted to how to manage routers with undefined firmware in advance, with communication channels undefined in advance.

Well, I’ve touched the future: I haven’t figured out how to reflect the results (for example, the result of the command) that come to the server using standard zabbix tools.

I remind you that all sources can be taken from the Git repository

Tags: