Korleis senda einingsloggar trygt til ein ekstern samlar

Eininga kan senda ut loggar, samlaren står på den andre sida av internett, og det første spørsmålet alle stiller, er kva tunnel som skal byggjast. Den ramma startar på feil stad. Det som avgjer transporten, er formatet eininga kan produsera, autentiseringa samlaren vil godta, og kva «levert» skal tyda når sambandet fell. Skriv ned dei tre svara, og transporten vel som regel seg sjølv.

Byrja med det eininga kan senda ut

I praksis finst det berre tre former. Einskild syslog-hendingar over UDP eller TCP, ei autentisert HTTPS-opplasting innebygd i produktet, eller komplette filer skrivne til disk som må flyttast. Ein brannmur som berre kan senda UDP-syslog, vert ikkje ein TLS-sendar fordi du la til ein tunnel; han vil framleis senda ubekrefta datagram, no inne i ein kryptert konvolutt.

Så kartlegg sendaren først: protokoll, TLS-støtte og kva TLS-bibliotek, om han kan validera sertifikatet til samlaren, om han kan presentera eit klientsertifikat, og om sendebufferen overlever ein omstart. Alt eininga ikkje kan, må gjerast av noko anna på vegen, og det andre vert ein del av designet ditt.

TLS-syslog: den kortaste vegen når begge endar snakkar han

Viss eininga støttar syslog over TLS og samlaren terminerer det, bruk det og stopp. Applikasjonsprotokollen vernar seg sjølv, samlaren autentiserer sendaren, og det er ikkje eit ekstra hopp som du no eig tilgjengelegheita til. Haken er at «TLS-syslog» dekkjer eit breitt spekter av implementasjonar, og dei gjeldande retningslinjene for trygg syslog har flytta seg forbi sifferlistene i eldre rettleidingar, og det er derfor ein fungerande vidaresendar vert øydelagd etter ein bibliotekoppgradering.

I rsyslog fortel sjølve namnet på transportmodulen kva æra du er i: lmnsd_gtls pakkar inn GnuTLS, medan lmnsd_ossl pakkar inn OpenSSL og det er det gjeldande 8.x-pakkar leverer. Ei vidaresending med sertifikatvalidering ser omtrent slik ut, og dei nøyaktige parameternamna er verdt å sjekka mot den installerte versjonen:

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

Valider endepunktet før du feilsøkjer sendaren. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error fullfører anten eit handtrykk med ei gyldig kjede eller fortel deg nøyaktig kva sjekk som feila. Test frå eininga, ikkje frå den berebara, fordi tillitslageret til eininga er det som tel.

SFTP: bra for filer, feil for straumar

Filbasert levering passar for einingar som skriv roterande loggar og ingenting anna. SSH-basert overføring gjev deg vertsnøklar, nøklar per konto og eit filsystem du kan revidera, noko som er ei rimeleg tillitshistorie for ei eining som ikkje kan TLS i det heile. Det er eit dårleg val for hendingsstraumar, der «fila vert skriven kvar time» tyder at eit avbrot kostar deg halen av den gjeldande timen.

La vertsvalidering vere på. Eit batch-kall som slår ho av for å unngå ei oppmoding, øydelegg den einaste autentiseringa transporten har:

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

Fest vertsnøkkelen i known_hosts til kontoen under klargjeringa, avgrens kontoen til målkatalogen, og føretrekk internal-sftp-undersystemet med chroot. Planlegg òg historia om ny innsending: viss ei fil vert send på nytt etter ein delvis feil, må samlaren kunne skilja ein duplikat frå ei ny fil, vanlegvis etter namn pluss kontrollsum og ikkje etter ankomsttid.

Når ein lokal gateway eller tunnel er det ærlege svaret

Nokre einingar kan berre snakka eit format ingen vil eksponera. I så fall mottek ein autorisert samlar på eininga sitt eige nettverk det opphavlege formatet og vidaresender det vidare over TLS. Det er eit legitimt design, men ver presis om kva det kjøper: kryptering som startar ved gatewayen, vernar ikkje segmentet mellom eininga og gatewayen bakover, så det hoppet treng framleis si eiga tillitsgrense og tilgangskontroll.

Ein ruta nettstads- eller einingstunnel er det tyngste alternativet og det rette når samlaren må halda på ei privat adresse og bera fleire tenester, ikkje berre loggar. Han bringar adresseplanlegging, tilgangsreglar, returvegar og livssyklusen til endepunktet til tunnelen. Han betrar heller ikkje den indre protokollen: UDP-syslog inne i ein IPsec-tunnel er framleis ei datagramteneste utan leveringsstadfesting.

Uansett kva du vel, hald autorisasjonen til samlaren strammare enn transporten. Ein tunnelidentitet høyrer til eit endepunkt, og han seier ingenting om kva underliggjande eining som produserte eit gjeve vertsnamnfelt i ei melding.

Skriv leveringsavtalen før du sender

Kryptering, autentisering og oppbevaring svarer på ulike spørsmål, og ein kø er ikkje ein oppbevaringspolicy. Før den første loggen forlet eininga, må du avgjera kva ei stadfesting faktisk tyder på denne samlaren: motteke på linja, akseptert for handsaming eller varig skriven til lagring. Det er tre ulike garantiar, og berre den siste overlever ein omstart av samlaren.

Svar deretter skriftleg på driftsspørsmåla. Kvar ventar usende hendingar, og overlever den bufferen eit straumbrot? Kva skjer når han vert full, og kven får melding? Korleis er nye forsøk avgrensa, og korleis vert duplikat identifiserte? Kva felt provar identiteten til sendaren, gjeve at eit vidaresendinghopp kan skriva om vertsnamnet?

Hald designet lite nok til å forklarast i eitt avsnitt: den minste støtta transporten som ber dei naudsynte hendingane, pluss ei uttrykkeleg fråsegn om garantiar han ikkje gjev. Viss svaret krev to hopp, sei det i runbooken og gje kvart hopp ein eigar.