Kaip saugiai siųsti įrenginio žurnalus į nuotolinį surinkėją
Pritaikykite perdavimą prie to, ką įrenginys gali išleisti: TLS syslog, SFTP failai, vietinis tarpinė arba maršrutizuotas tunelis. Tada parašykite pristatymo sutartį.
Įrenginys gali išleisti žurnalus, surinkėjas yra kitoje interneto pusėje, o pirmas klausimas, kurį visi užduoda, yra kokį tunelį statyti. Toks rėmas prasideda ne ten, kur reikia. Perdavimą lemia formatas, kurį įrenginys gali sukurti, autentifikacija, kurią priims surinkėjas, ir tai, ką „pristatyta“ turi reikšti, kai ryšys nutrūksta. Užsirašykite šiuos tris atsakymus, ir perdavimas paprastai pasirenka pats save.
Pradėkite nuo to, ką įrenginys gali išleisti
Praktikoje yra tik trys formos. Atskiri syslog įvykiai per UDP arba TCP, produkte integruotas autentifikuotas HTTPS įkėlimas arba ištisi failai, įrašyti į diską, kuriuos reikia perkelti. Užkarda, galinti siųsti tik UDP syslog, netaps TLS siuntėju dėl to, kad pridėjote tunelį; ji ir toliau siųs nepatvirtintus datagramus, dabar užšifruotame voke.
Taigi pirmiausia inventorizuokite siuntėją: protokolas, TLS palaikymas ir kuri TLS biblioteka, ar jis gali patikrinti surinkėjo sertifikatą, ar gali pateikti kliento sertifikatą ir ar siuntimo buferis išgyvena perkrovimą. Viską, ko įrenginys negali, turi padaryti kažkas kitas kelyje, ir tas kažkas kitas tampa jūsų dizaino dalimi.
TLS syslog: trumpiausias kelias, kai abu galai jį kalba
Jei įrenginys palaiko syslog per TLS ir surinkėjas jį užbaigia, naudokite tai ir sustokite. Taikomosios programos protokolas apsaugo save, surinkėjas autentifikuoja siuntėją, ir nėra papildomo šuolio, kurio prieinamumą dabar valdote. Kabliukas tas, kad „TLS syslog“ apima platų įgyvendinimų spektrą, ir dabartinės saugaus syslog gairės nuejo toliau už senų pamokų šifrų sąrašus, todėl veikiantis peradresuotojas sugenda po bibliotekos atnaujinimo.
rsyslog atveju vien transporto modulio pavadinimas pasako, kurioje epochoje esate: lmnsd_gtls apgaubia GnuTLS, o lmnsd_ossl apgaubia OpenSSL ir tai tiekia dabartiniai 8.x paketai. Peradresavimo veiksmas su sertifikato patikra atrodo maždaug taip, o tikslius parametrų pavadinimus verta patikrinti pagal įdiegtą versiją:
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")
Patikrinkite galinį tašką prieš derindami siuntėją. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error arba užbaigia rankos paspaudimą su galiojančia grandine, arba tiksliai pasako, kuri patikra nepavyko. Testuokite iš įrenginio, o ne iš nešiojamojo kompiuterio, nes svarbi yra įrenginio patikimumo saugykla.
SFTP: tinka failams, netinka srautams
Failais grindžiamas pristatymas tinka įrenginiams, kurie rašo rotuojamus žurnalus ir nieko daugiau. SSH pagrindu veikiantis perdavimas suteikia pagrindinio kompiuterio raktus, kiekvienos paskyros raktus ir failų sistemą, kurią galite audituoti, o tai yra pagrįsta pasitikėjimo istorija įrenginiui, kuris visai nemoka TLS. Tai prastas pasirinkimas įvykių srautams, kur „failas rašomas kas valandą“ reiškia, kad sutrikimas jums kainuoja dabartinės valandos pabaigą.
Laikykite įjungtą pagrindinio kompiuterio patikrą. Paketinis iškvietimas, kuris ją išjungia, kad išvengtų raginimo, sunaikina vienintelę autentifikaciją, kurią turi perdavimas:
sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]
Paruošimo metu prisekite pagrindinio kompiuterio raktą paskyros known_hosts faile, apribokite paskyrą tikslinei katalogui ir pirmenybę teikite internal-sftp posistemei su chroot. Suplanuokite ir pakartotinio siuntimo istoriją: jei failas siunčiamas dar kartą po dalinės klaidos, surinkėjas turi atskirti dublikatą nuo naujo failo, paprastai pagal pavadinimą ir kontrolinę sumą, o ne pagal atvykimo laiką.
Kai vietinė tarpinė arba tunelis yra sąžiningas atsakymas
Kai kurie įrenginiai moka kalbėti tik formatu, kurio niekas nenori atskleisti. Tokiu atveju įgaliotas surinkėjas pačiame įrenginio tinkle gauna vietinį formatą ir persiunčia jį toliau per TLS. Tai teisėtas dizainas, bet būkite tikslūs, ką jis perka: šifravimas, prasidedantis prie tarpinės, neatgaline tvarka neapsaugo atkarpos tarp įrenginio ir tarpinės, todėl tam šuoliui vis dar reikia savo pasitikėjimo ribos ir prieigos kontrolės.
Maršrutizuotas svetainės ar įrenginio tunelis yra sunkiausias variantas ir teisingas, kai surinkėjas turi išlaikyti privatų adresą ir turi nešti kelias paslaugas, ne tik žurnalus. Jis atneša adresų planavimą, prieigos taisykles, grįžimo kelius ir tunelio galinio taško gyvavimo ciklą. Jis taip pat nepagerina vidinio protokolo: UDP syslog IPsec tunelyje tebėra datagramų paslauga be pristatymo patvirtinimo.
Kad ir ką pasirinktumėte, laikykite surinkėjo įgaliojimą siauresnį už perdavimą. Tunelio tapatybė priklauso galiniam taškui ir nieko nesako apie tai, kuris žemesnis įrenginys sukūrė konkretų pagrindinio kompiuterio vardo lauką pranešime.
Parašykite pristatymo sutartį prieš siųsdami
Šifravimas, autentifikacija ir saugojimas atsako į skirtingus klausimus, o eilė nėra saugojimo politika. Prieš pirmam žurnalui paliekant įrenginį, nuspręskite, ką patvirtinimas iš tikrųjų reiškia šiame surinkėjuje: gauta laidu, priimta apdoroti ar patikimai įrašyta į saugyklą. Tai trys skirtingos garantijos, ir tik paskutinė išgyvena surinkėjo perkrovimą.
Tada raštu atsakykite į operacinius klausimus. Kur laukia neišsiųsti įvykiai ir ar tas buferis išgyvena elektros nutrūkimą? Kas nutinka, kai jis prisipildo, ir kam pranešama? Kaip ribojami pakartotiniai bandymai ir kaip identifikuojami dublikatai? Kuris laukas įrodo siuntėjo tapatybę, atsižvelgiant į tai, kad peradresavimo šuolis gali perrašyti pagrindinio kompiuterio vardą?
Laikykite dizainą pakankamai mažą, kad jį būtų galima paaiškinti vienoje pastraipoje: mažiausias palaikomas perdavimas, kuris neša reikiamus įvykius, plius aiškus pareiškimas apie garantijas, kurių jis nesuteikia. Jei atsakymui reikia dviejų šuolių, pasakykite tai runbooke ir kiekvienam šuoliui paskirkite atsakingą.