Fjernovervåking og administrasjon av Linux/OpenWrt/Lede-baserte enheter via port 80, fortsatt

Dette er den siste delen av artikkelen, her er begynnelsen habr.com/en/post/445568
Sist gang jeg skrev om hvordan jeg implementerte enhetsovervåking, nå skal vi snakke om ledelse. I diskusjoner med "teknikere" på kundens side, møter jeg ofte en begrenset oppfatning av mulighetene til slike små enheter (med lave minneressurser og ytelse), mange tror at "det meste vi trenger er å sende en omstart, for noe mer seriøst, vi sender et team."
Men praksis viser at dette ikke er helt sant. Her er en liten liste over vanlige typiske oppgaver:

  1. Nettverksdiagnostikk og feilsøking. Bak ethernet-porten til ruteren din er det vanligvis en annen maskinvare som har sin egen interne IP-adresse. Noen ganger kan du (bør) "pinge" den. Eller tunnelhåndtering - hvis tunnelen plutselig ikke reiser seg på en ruter som opererer via et 3G-modem, men vi kan se selve ruteren.
  2. System vedlikehold. Firmwareoppdatering, serviceskriptoppgradering.
  3. Balansegang. Dette kan kalles "perversjon", men konseptet "ekvilibrist" som, jeg siterer, "evnen til en sirkusartist til å opprettholde balansen i en ustabil kroppsstilling" - passer bedre. Slike situasjoner oppstår på grunn av kundens begrensede budsjett. Nedenfor ga jeg et par eksempler, men... De er ikke direkte knyttet til historiens tema, jeg legger dem i notatene

Wi-Fi-overvåkingEt fasjonabelt tema de siste fem årene, hovedsakelig blant føderale butikkjeder. Du rusler rolig gjennom handelsgulvene, og mobiltelefonen din med Wi-Fi slått på, i et forsøk på å "holde seg" til en tråd i nettverket, sender regelmessig ut Probe Request-pakker, som kan analyseres for å beregne for du: hvor ofte kommer du til denne butikken, av hvilke grunner går du langs baner og så videre. Deretter samles dataene inn, analyseres, varmekart tegnes, og ledere «presser» penger fra ledelsen eller investorer for slike bilder. Vel, foreløpig... «det er ingen penger, men du holder på...», og resultatet (ekte) må allerede vises, starter den gode gamle sangen: «Ja, ja, da skal vi selvsagt vil installere cis og alt du ønsker, men nå må vi vise kunden resultatet! Forresten, vi glemte å si at kunden tillot oss å koble utstyret vårt til sin hotspot via Wi-Fi, men på generelt grunnlag, akkurat som om vi var gjestekunder.» Og så vi må lage balanserende rutere - flere WiFi-undergrensesnitt er hevet, hvorav det ene klamrer seg til hotspotet, og det andre overvåker miljøet, laster febrilsk opp tcpdump-resultatet til seg selv, pakker deretter innholdet av filen inn i et arkiv og risikerer dø av "overspising" prøver å spytte ut innholdet på FTP-serveren. Det er ikke overraskende at balanseringsruteren ofte "bryter sammen" og på en eller annen måte må "gjenopplives" eksternt.

RadiusDet er lettere å beskrive situasjonen her med noe slikt som denne uttalelsen fra kunden: "Vi vil ha et desentralisert nettverk av hotspots som fungerer på utstyr hvis modell ikke er kjent på forhånd, gjennom kanaler, men hvilke vi ennå ikke vet. Å, vi glemte å si, vi ønsker ikke bare å vise reklame til kunder, men også analysere alt rundt stedet der hotspotet er installert. Nei, vi vet ikke hvorfor ennå, men vi finner ut av det, tvil ikke på det, vi var i stand til å komme opp med denne ideen."

Og vi må ikke glemme at på grunn av mange tidligere ukjente omstendigheter, må kontroll utføres under ikke-standardiserte forhold, når vi ikke kan koble til ruteren direkte via IP:-porten og er tvunget til å bare vente på aktivitet fra den. Hvis vi abstraherer oss selv, kan dialogen mellom serveren og ruteren representeres slik:

  • router: Hallo. Jeg er en sånn og sånn ruter, er det noen oppgaver for meg?
  • Сервер: ruter slik og slik, jeg registrerte deg, at du er i live. Her er utfordringen: vis meg resultatet av ifconfig-kommandoen?
  • router: Hallo. Jeg er en sånn og sånn ruter, forrige gang du spurte om å få vise resultatet av ifconfig, her er det. Er det noen oppgaver for meg?
  • Сервер: ruter slik og slik, jeg registrerte deg, at du er i live. Det er ingen oppgaver for deg.

Det mest interessante spørsmålet: hvordan kan en ekstern ruter sende en viss mengde informasjon? I den siste delen beskrev jeg at på grunn av begrensede ressurser, har ruteren bare en "nedstrippet" wget, som bare fungerer via GET og ingenting annet; det er ingen FTP-klient eller krøll. Mer presist trenger vi en universell metode, uavhengig av funksjonene til bildemontering. Jeg bestemte meg for å bruke wget. Mer presist, hvordan jeg "stoppet" - jeg hadde rett og slett ikke noe valg :)

Bare en ansvarsfraskrivelseMin administrasjonsløsning fungerer, ikke veldig begrenset, og jeg er sikker på at den er skjev, selv om den passer de fleste av kundene mine. Hvordan kunne du gjøre det klokt - skriv et lite verktøy som sender POST binære data gjennom port 80. Inkluder det (verktøyet) i ruterens fastvare og få tilgang til det ved å bruke bash. Men realiteten er at: a) vi må raskt b) vi sannsynligvis trenger å gjøre alt på den eksisterende "zoo av rutere" c) "ikke skade!" — hvis ruteren fungerer og utfører andre oppgaver, prøv å gjøre endringer som ikke vil påvirke den eksisterende funksjonaliteten.

La oss gå videre til implementeringen. La oss si at kunden din ønsker å starte ruteren på nytt fra zabbix enkelt og naturlig, med et "klikk med musen." I dag skal vi begynne å beskrive implementeringen med Zabbix.
I menyen "Administrasjon" -> "Skript" legger du til et nytt skript. Vi kaller det "Reboot", skriv inn "php /usr/share/zabbix/reboot.php {HOST.HOST}" som en kommando

Fjernovervåking og administrasjon av Linux/OpenWrt/Lede-baserte enheter via port 80, fortsatt

Neste: Meny "Overvåking" -> "Siste data" -> "Høyreklikk på ønsket nettverksnode." Slik vil menyen se ut etter å ha lagt til skriptet.

Fjernovervåking og administrasjon av Linux/OpenWrt/Lede-baserte enheter via port 80, fortsatt
Følgelig legger vi reboot.php-skriptet i /usr/share/zabbix-katalogen (din kan være annerledes, jeg bruker zabbixa-rotkatalogen).

SikkerhetsfraskrivelseFor å gjøre forklaringen tydeligere i scriptet bruker jeg kun ruter-ID, men bruker ikke passordet. Det anbefales ikke å gjøre dette i produksjonsversjonen! Hvorfor gjorde jeg dette: fordi det store spørsmålet er hvor jeg skal lagre passord for rutere? I zabbixe seg selv i "inventardata"? Kontroversiell praksis. Alternativt: begrense ekstern tilgang til selve reboot.php-filen

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

Det er alt. Spørsmålet forblir åpent: "hvordan få resultatet av å utføre en kommando fra enheten." La oss se på oppgaven ved å bruke ifconfig-kommandoen som eksempel. Denne kommandoen kan sendes til enheten:

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

, hvor:
message=`ifconfig` — vi tildeler resultatet av ifconfig-kommandoen til $message-variabelen
wget "xn--80abgfbdwanb2akugdrd3a2e5gsbj.xn--p1ai/a.php — vårt a.php-skript som registrerer rutere og mottar meldinger fra dem
u=bruker&p=passord!&m=$melding — legitimasjon og verdien av forespørselsvariabelen m — tildeler innholdet i $message-variabelen
-O /tmp/out.txt — vi trenger ikke utdata til filen /tmp/out.txt i dette tilfellet, men hvis denne parameteren ikke er spesifisert, fungerer ikke wget

Hvorfor fungerer ikke dette?Fordi det er et potensielt sikkerhetshull. Den mest ufarlige feilen som kan skje er hvis det for eksempel er et "&"-tegn i utdataene til kommandoen din. Derfor er det nødvendig å filtrere både alt som sendes fra rutere og alt som kommer til serveren. Ja, jeg skammer meg egentlig. Til mitt forsvar kan jeg bare skrive at hele artikkelen er viet hvordan man administrerer rutere med forhåndsdefinert fastvare og kommunikasjonskanaler som ikke er definert på forhånd.

Vel, en start for fremtiden: Jeg har ennå ikke funnet ut hvordan jeg skal bruke standard zabbix-verktøy for å reflektere resultatene (for eksempel resultatet av å utføre en kommando) som kommer til serveren.

Jeg minner deg om at alle kilder kan hentes fra Git-depotet på: github.com/BazDen/iotnet.online.git

Kilde: www.habr.com

Legg til en kommentar