Monitoreo y administración remotos de dispositivos basados ​​en Linux / OpenWrt / Lede a través del puerto 80, continuación

Esta es la parte final del artículo, aquí está el comienzo .

La última vez que escribí sobre cómo implementé el monitoreo de dispositivos, ahora nos enfocaremos en la administración. En conversaciones con "técnicos" por parte del Cliente, a menudo encuentro una percepción limitada de las capacidades de dispositivos tan pequeños (con bajos recursos de memoria y rendimiento), muchas personas piensan que "lo máximo que necesitamos enviar es reiniciar, para algo más serio, enviaremos un equipo" .

Pero la práctica muestra que esto no es del todo cierto.

Aquí hay una breve lista de tareas comunes comunes:

  1. Diagnóstico de red y solución de problemas. Detrás del puerto ethernet de su enrutador, otra pieza de hardware generalmente tiene su propia dirección IP interna. A veces, puede (necesita) "ping". O administración de túneles: si un enrutador que no sube de repente en un enrutador que funciona con un módem 3G, pero vemos el enrutador en sí.
  2. Servicio del sistema. Actualización de firmware, actualización de script de servicio.
  3. Acto de equilibrio. Esto podría llamarse "perversiones", pero el concepto de "equilibrador" como, cito, "la capacidad de un artista de circo para mantener el equilibrio en una posición inestable del cuerpo" es más adecuado. Situaciones similares surgen debido al presupuesto limitado del cliente. A continuación hay un par de ejemplos, pero porque no tienen relación directa con el tema de la narración, póngalos en notas

Monitoreo wifi
Un tema de moda durante los últimos cinco años es principalmente entre las cadenas minoristas federales. Pasea lentamente por los pisos de negociación, y su teléfono móvil con Wi-Fi encendido, en un intento de "apegarse" a algún hilo de la red, envía regularmente paquetes de Solicitud de sonda que pueden analizarse para calcular la frecuencia con la que visita esta tienda, para qué caminar las trayectorias y así sucesivamente. Luego, los datos se recopilan, analizan, se dibujan mapas de calor y los gerentes de esas imágenes "eliminan" el dinero de la gerencia o los inversores. Mientras tanto ... "no hay dinero, pero espera ...", y el resultado (real) ya debe mostrarse, la vieja canción está incluida "Sí, sí, entonces por supuesto pondremos tsiska y lo que queramos, pero ahora necesitamos ¡Muestre al cliente el resultado! Por cierto, se olvidaron de decir que el Cliente permitió que nuestro equipo se conectara a su punto de acceso a través de Wi-Fi, pero en general, es como si fuéramos clientes invitados ". Y ahora tiene que hacer enrutadores-equilibradores: se elevan varias subinterfaces WiFi, una de las cuales se aferra a un punto de acceso, y la segunda monitorea el entorno, descarga frenéticamente el resultado de tcpdump en sí mismo, luego el contenido del archivo se empaqueta en el archivo y corre el riesgo de morir por "comer en exceso" tratando de escupir el contenido en el servidor ftp. No es sorprendente que el enrutador-equilibrador a menudo se "descomponga" y de alguna manera deba ser resucitado de forma remota.

Radio
Aquí es más fácil describir la situación con algo como esta declaración del cliente: "Queremos una red descentralizada de puntos de acceso que funcionen en equipos cuyo modelo no se conoce de antemano, a través de canales, pero aún no sabemos cuáles. Ah, se olvidaron de decir que no solo queremos mostrar anuncios a los clientes, sino también analizar todo lo relacionado con el lugar de instalación del punto de acceso. No, todavía no sabemos por qué, pero se nos ocurrirá, no lo dude, pudimos llegar a esta idea "

Y no debemos olvidar que debido a la gran cantidad de circunstancias inciertas de antemano, el control debe llevarse a cabo en condiciones no estándar, cuando no podemos conectarnos al enrutador directamente a través de ip: el puerto y nos vemos obligados a esperar la actividad del mismo. Si lo ignoramos, el diálogo entre el servidor y el enrutador puede representarse así:

  • Enrutador : hola. Soy un enrutador, ¿hay alguna tarea para mí?
  • Servidor : tal y tal enrutador te registré que estás vivo. Aquí está la tarea: ¿mostrarme el resultado del comando ifconfig?
  • Enrutador : hola. Soy un enrutador así, la última vez que me pediste que mostrara el resultado de ifconfig, aquí está. ¿Hay alguna tarea para mí?
  • Servidor : tal y tal enrutador te registré que estás vivo. No hay tareas para ti.

La pregunta más interesante: ¿cómo puede un enrutador remoto enviar cierta cantidad de información? En la última parte, describí que en el enrutador debido a los recursos limitados solo hay un wget "despojado" que funciona solo a través de GET y nada más, no hay un cliente ftp o curl. Más precisamente, necesitamos una forma universal, independientemente de las características del ensamblaje de la imagen. Me decidí a usar wget. Más precisamente, cómo me "detuve": simplemente no tenía otra opción :)

Reserva inmediata
Mi solución de administración funciona, pero es muy limitada y estoy seguro de que está torcida, incluso si se adapta a la mayoría de mis clientes. Cómo sería posible hacerlo sabiamente: escribir una pequeña utilidad que envíe datos binarios a través del puerto 80. Inclúyalo (utilidad) en el firmware del enrutador y use bash para acceder a él. Pero la realidad es que: a) necesita hacerlo rápidamente b) tal vez necesite hacer todo en el "zoológico enrutador" existente c) "¡no hacer daño!" - si el enrutador funciona y realiza otras tareas, intente realizar cambios que afecten la funcionalidad existente.

Pasemos a la implementación. Supongamos que su cliente desea que zabbix reinicie el enrutador de manera fácil y natural, con un "clic del mouse". Hoy comenzaremos la descripción de la implementación con zabbiksa.

En el menú "Administración" -> "Scripts" agregue un nuevo script. Lo llamamos "reiniciar", como comando escribimos "php /usr/share/zabbix/reboot.php {HOST.HOST}"



Además: Menú "Monitoreo" -> "Datos recientes" -> "Haga clic derecho en el nodo de red". Así es como se verá el menú después de agregar un script.


En consecuencia, colocamos el script reboot.php en el directorio / usr / share / zabbix (puede tener otro, yo uso el directorio raíz de zabbixa).

Descargo de responsabilidad por seguridad
Para mayor claridad en la secuencia de comandos, utilizo solo la identificación del enrutador, pero no utilizo la contraseña. ¡En la versión de trabajo, esto no se recomienda! ¿Por qué hice esto: porque la gran pregunta es dónde almacenar las contraseñas de los enrutadores? En zabbixe sí mismo en el "inventario"? Práctica contradictoria. Como opción: restringir el acceso externo al archivo reboot.php en sí

Reboot.php archivo

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

En realidad todo. La pregunta "cómo obtener el resultado de la ejecución de un comando desde el lado del dispositivo" permanece abierta. Considere el problema usando el comando ifconfig como ejemplo. Este comando se puede enviar al dispositivo:

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

donde:
message = `ifconfig` - asignamos el resultado de la salida del comando ifconfig a la variable $ message
wget " xn - 80abgfbdwanb2akugdrd3a2e5gsbj.xn - p1ai / a.php - nuestro script a.php que registra enrutadores y recibe mensajes de ellos
u = usuario & p = contraseña! & m = $ mensaje - credenciales y el valor de la variable de solicitud m - asigna el contenido de la variable $ mensaje
-O /tmp/out.txt : no necesitamos salida al archivo /tmp/out.txt en este caso, pero si no especifica este parámetro, wget no funciona

¿Por qué funciona torcidamente?
Porque es un potencial agujero de seguridad. El error más inofensivo que puede ocurrir es si, por ejemplo, hay un símbolo "&" en la salida de su comando. Por lo tanto, es necesario filtrar todo lo que se envía desde los enrutadores y todo lo que llega al servidor. Sí, estoy avergonzado, de verdad. En mi defensa, solo puedo escribir: que todo el artículo está dedicado a cómo administrar enrutadores con firmware indefinido de antemano, con canales de comunicación indefinidos de antemano.

Bueno, he tocado el futuro: no he descubierto cómo reflejar los resultados (por ejemplo, el resultado del comando) que llegan al servidor utilizando herramientas estándar de zabbix.

Les recuerdo que todas las fuentes se pueden tomar del repositorio de Git

Source: https://habr.com/ru/post/446230/


All Articles