Kuidas saata seadme logisid turvaliselt kaugkogujasse

Seade suudab logisid väljastada, koguja asub interneti teisel poolel ja esimene küsimus, mida kõik küsivad, on see, millist tunnelit ehitada. Selline raamistamine algab valest kohast. Transpordi määrab vorming, mida seade suudab luua, autentimine, mida koguja aktsepteerib, ja see, mida „kohale toimetatud“ peaks tähendama, kui ühendus katkeb. Kirjutage need kolm vastust üles ja transport valib enamasti ise enda.

Alustage sellest, mida seade suudab väljastada

Praktikas on ainult kolm kuju. Üksikud syslog-sündmused UDP või TCP kaudu, tootesse ehitatud autenditud HTTPS-üleslaadimine või terved kettale kirjutatud failid, mida tuleb liigutada. Tulemüür, mis suudab saata ainult UDP syslogi, ei muutu TLS-saatjaks sellepärast, et lisasite tunneli; see saadab endiselt kinnitamata datagramme, nüüd krüpteeritud ümbrikus.

Seega inventariseerige esmalt saatja: protokoll, TLS-i tugi ja milline TLS-i teek, kas see suudab koguja sertifikaati valideerida, kas see suudab esitada kliendisertifikaati ja kas saatmisbuffer peab restardi üle elama. Kõik, mida seade ei suuda, peab tegema miski muu teel, ja see miski muu saab teie disaini osaks.

TLS syslog: lühim tee, kui mõlemad otsad seda räägivad

Kui seade toetab syslogi üle TLS-i ja koguja selle lõpetab, kasutage seda ja lõpetage. Rakendusprotokoll kaitseb ennast, koguja autendib saatja ega ole lisahüpet, mille käideldavust te nüüd omate. Konks on selles, et „TLS syslog“ katab laia rakenduste valiku ja praegused turvalise syslogi juhised on vanemate õpetuste šifriloenditest kaugemale liikunud, mistõttu töötav edastaja muutub pärast teegi uuendamist katkiseks.

Rsyslogis ütleb juba transpordimooduli nimi, millises ajastus olete: lmnsd_gtls mässib GnuTLS-i, samas lmnsd_ossl mässib OpenSSL-i ja seda pakuvad praegused 8.x paketid. Sertifikaadi valideerimisega edastustoiming näeb umbes selline välja ja täpseid parameetrinimesid tasub kontrollida paigaldatud versiooni vastu:

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")

Kontrollige lõpp-punkti enne saatja silumist. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error kas lõpetab käepigistuse kehtiva ahelaga või ütleb täpselt, milline kontroll ebaõnnestus. Testige seadmest, mitte sülearvutist, sest oluline on just seadme usaldushoidla.

SFTP: hea failidele, vale voogudele

Failipõhine tarne sobib seadmetele, mis kirjutavad pöörlevaid logisid ja mitte midagi muud. SSH-põhine ülekanne annab teile hostivõtmed, konto kohta võtmed ja failisüsteemi, mida saate auditeerida, mis on mõistlik usalduslugu seadmele, mis ei suuda üldse TLS-i. Sündmusvoogude jaoks on see halb valik, sest „fail kirjutatakse iga tund“ tähendab, et katkestus võtab teilt jooksva tunni lõpu.

Jätke hosti kontroll sisse lülitatuks. Partiikõne, mis lülitab selle välja viiba vältimiseks, hävitab ainsa autentimise, mis transpordil on:

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

Kinnitage hostivõti ettevalmistamise ajal konto known_hosts faili, piirake konto sihtkataloogiga ja eelistage internal-sftp alamsüsteemi koos chrootiga. Planeerige ka uuestisaatmise lugu: kui fail saadetakse pärast osalist ebaõnnestumist uuesti, peab koguja eristama duplikaati uuest failist, tavaliselt nime ja kontrollsumma järgi, mitte saabumisaja järgi.

Kui kohalik lüüs või tunnel on aus vastus

Mõned seadmed oskavad rääkida ainult vormingus, mida keegi ei taha paljastada. Sel juhul võtab seadme enda võrgus asuv volitatud koguja vastu loomuliku vormingu ja edastab selle TLS-i kaudu edasi. See on legitiimne disain, kuid olge täpne selles, mida see ostab: lüüsil algav krüpteerimine ei kaitse tagasiulatuvalt seadme ja lüüsi vahelist lõiku, seega vajab see hüpe endiselt oma usalduspiiri ja juurdepääsukontrolli.

Marsruuditud saidi- või seadmetunnel on kõige raskem valik ja õige siis, kui koguja peab säilitama privaatse aadressi ja kanda mitut teenust, mitte ainult logisid. See toob kaasa aadresside planeerimise, juurdepääsureeglid, tagasiteed ja tunnelilõpp-punkti elutsükli. See ei paranda ka sisemist protokolli: UDP syslog IPsec-tunneli sees on endiselt datagrammiteenus ilma tarnekinnituseta.

Mida iganes valite, hoidke koguja volitus transpordist kitsam. Tunneli identiteet kuulub lõpp-punktile ega ütle midagi selle kohta, milline allpool asuv seade tootis teatud hostinime välja sõnumis.

Kirjutage tarnekokkulepe enne saatmist

Krüpteerimine, autentimine ja säilitamine vastavad erinevatele küsimustele ning järjekord ei ole säilitamispoliitika. Enne kui esimene logi seadmest lahkub, otsustage, mida kinnitus sellel kogujal tegelikult tähendab: võrgus vastu võetud, töötlemiseks vastu võetud või vastupidavalt salvestatud. Need on kolm erinevat garantiid ja ainult viimane elab koguja restardi üle.

Seejärel vastake kirjalikult tegevusküsimustele. Kus ootavad saatmata sündmused ja kas see buffer elab üle voolukatkestuse? Mis juhtub, kui see täitub, ja keda teavitatakse? Kuidas on korduskatsed piiratud ja kuidas tuvastatakse duplikaadid? Milline väli tõestab saatja identiteeti, arvestades et edastushüpe võib hostinime ümber kirjutada?

Hoidke disain piisavalt väike, et seda ühes lõigus selgitada: väikseim toetatud transport, mis kannab vajalikke sündmusi, pluss selgesõnaline avaldus garantii kohta, mida see ei anna. Kui vastus nõuab kahte hüpet, öelge seda runbookis ja andke igale hüppele omanik.