Kā droši nosūtīt ierīces žurnālus uz attālinātu savācēju

Ierīce spēj izdot žurnālus, savācējs atrodas internetā otrā pusē, un pirmais jautājums, ko visi uzdod, ir kādu tuneli būvēt. Šis ietvars sākas nepareizajā vietā. Pārsūtīšanu nosaka formāts, ko ierīce spēj radīt, autentifikācija, ko pieņems savācējs, un tas, ko “piegādāts” nozīmēs, kad saite nokrīt. Pierakstiet šīs trīs atbildes, un pārsūtīšana parasti izvēlas pati sevi.

Sāciet ar to, ko ierīce spēj izdot

Praksē ir tikai trīs formas. Atsevišķi syslog notikumi pa UDP vai TCP, produktā iebūvēta autentificēta HTTPS augšupielāde vai veseli faili, kas ierakstīti diskā un ir jāpārvieto. Ugunsmūris, kas spēj sūtīt tikai UDP syslog, nekļūs par TLS sūtītāju tāpēc, ka pievienojāt tuneli; tas joprojām sūtīs neapstiprinātas datagrammas, tagad šifrētā aploksnē.

Tāpēc vispirms uzskaitiet sūtītāju: protokols, TLS atbalsts un kura TLS bibliotēka, vai tas spēj validēt savācēja sertifikātu, vai spēj uzrādīt klienta sertifikātu un vai sūtīšanas buferis pārdzīvo pārstartēšanu. Viss, ko ierīce nevar, ir jādara kaut kam citam ceļā, un tas kaut kas cits kļūst par jūsu dizaina daļu.

TLS syslog: īsākais ceļš, kad abi gali to runā

Ja ierīce atbalsta syslog pa TLS un savācējs to pārtrauc, izmantojiet to un apstājieties. Lietojumprogrammas protokols aizsargā sevi, savācējs autentificē sūtītāju, un nav papildu lēciena, kura pieejamība tagad pieder jums. Āķis ir tāds, ka “TLS syslog” aptver plašu ieviešanu klāstu, un pašreizējās droša syslog vadlīnijas ir attālinājušās no vecāku apmācību šifru sarakstiem, un tāpēc strādājošs pārsūtītājs sabrūk pēc bibliotēkas atjaunināšanas.

Rsyslog gadījumā jau transporta moduļa nosaukums pasaka, kurā laikmetā esat: lmnsd_gtls aptver GnuTLS, bet lmnsd_ossl aptver OpenSSL, un to piegādā pašreizējās 8.x pakotnes. Pārsūtīšanas darbība ar sertifikāta validāciju izskatās aptuveni šādi, un precīzos parametru nosaukumus ir vērts pārbaudīt pret instalēto versiju:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

Pārbaudiet galapunktu pirms sūtītāja atkļūdošanas. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error vai nu pabeidz rokasspiedienu ar derīgu ķēdi, vai precīzi pasaka, kura pārbaude neizdevās. Pārbaudiet no ierīces, nevis no klēpjdatora, jo svarīga ir ierīces uzticības krātuve.

SFTP: labs failiem, nepareizs plūsmām

Uz failiem balstīta piegāde piemērota ierīcēm, kas raksta rotējošus žurnālus un neko citu. SSH balstīta pārsūtīšana dod jums resursdatora atslēgas, atslēgas katram kontam un failu sistēmu, ko varat auditēt, kas ir saprātīgs uzticības stāsts ierīcei, kas nemaz neprot TLS. Tā ir slikta izvēle notikumu plūsmām, kur “fails tiek rakstīts katru stundu” nozīmē, ka pārtraukums jums izmaksā pašreizējās stundas asti.

Turiet resursdatora pārbaudi ieslēgtu. Paketes izsaukums, kas to izslēdz, lai izvairītos no uzvednes, iznīcina vienīgo autentifikāciju, kas pārsūtīšanai ir:

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

Nodrošināšanas laikā piespraudiet resursdatora atslēgu konta known_hosts failā, ierobežojiet kontu ar mērķa direktoriju un dodiet priekšroku internal-sftp apakšsistēmai ar chroot. Izplānojiet arī atkārtotas sūtīšanas stāstu: ja fails tiek nosūtīts vēlreiz pēc daļējas kļūmes, savācējam ir jāatšķir dublikāts no jauna faila, parasti pēc nosaukuma un kontrolsummas, nevis pēc ierašanās laika.

Kad vietējā vārteja vai tunelis ir godīgā atbilde

Dažas ierīces prot runāt tikai formātā, ko neviens negrib atklāt. Tādā gadījumā pilnvarots savācējs pašā ierīces tīklā saņem vietējo formātu un pārsūta to tālāk pa TLS. Tas ir likumīgs dizains, bet esiet precīzi par to, ko tas pērk: šifrēšana, kas sākas pie vārtejas, neatgriezeniski neaizsargā segmentu starp ierīci un vārteju, tāpēc šim lēcienam joprojām vajag savu uzticības robežu un piekļuves kontroli.

Maršrutēts vietnes vai ierīces tunelis ir smagākais variants un pareizais, kad savācējam jāsaglabā privāta adrese un jāpārvadā vairāki pakalpojumi, ne tikai žurnāli. Tas ienes adrešu plānošanu, piekļuves noteikumus, atgriešanās ceļus un tuneļa galapunkta dzīves ciklu. Tas arī neuzlabo iekšējo protokolu: UDP syslog IPsec tunelī joprojām ir datagrammu pakalpojums bez piegādes apstiprinājuma.

Lai ko izvēlētos, turiet savācēja pilnvarojumu šaurāku par pārsūtīšanu. Tuneļa identitāte pieder galapunktam, un tā neko nepasaka par to, kura zemākā ierīce radīja konkrētu resursdatora nosaukuma lauku ziņojumā.

Pierakstiet piegādes līgumu pirms nosūtīšanas

Šifrēšana, autentifikācija un glabāšana atbild uz dažādiem jautājumiem, un rinda nav glabāšanas politika. Pirms pirmais žurnāls atstāj ierīci, izlemiet, ko apstiprinājums šajā savācējā patiešām nozīmē: saņemts uz vada, pieņemts apstrādei vai noturīgi ierakstīts krātuvē. Tās ir trīs dažādas garantijas, un tikai pēdējā pārdzīvo savācēja pārstartēšanu.

Pēc tam rakstiski atbildiet uz operatīvajiem jautājumiem. Kur gaida nenosūtītie notikumi, un vai šis buferis pārdzīvo elektrības pārtraukumu? Kas notiek, kad tas piepildās, un kam tiek paziņots? Kā tiek ierobežoti atkārtojumi un kā tiek identificēti dublikāti? Kurš lauks pierāda sūtītāja identitāti, ņemot vērā, ka pārsūtīšanas lēciens var pārrakstīt resursdatora nosaukumu?

Turiet dizainu pietiekami mazu, lai to varētu izskaidrot vienā rindkopā: mazākā atbalstītā pārsūtīšana, kas pārvadā nepieciešamos notikumus, plus skaidrs paziņojums par garantijām, ko tā nesniedz. Ja atbildei vajag divus lēcienus, sakiet to runbook un piešķiriet katram lēcienam atbildīgo.