Slik sender du enhetslogger sikkert til en ekstern samler

Enheten kan sende ut logger, samleren står på den andre siden av internett, og det første spørsmålet alle stiller, er hvilken tunnel som skal bygges. Den rammen starter på feil sted. Det som avgjør transporten, er formatet enheten kan produsere, autentiseringen samleren vil godta, og hva «levert» skal betyde når forbindelsen faller. Skriv ned de tre svarene, og transporten velger som regel seg selv.

Begynn med det enheten kan sende ut

I praksis finnes det bare tre former. Enkelte syslog-hendelser over UDP eller TCP, en autentisert HTTPS-opplasting innebygd i produktet, eller komplette filer skrevet til disk som må flyttes. En brannmur som bare kan sende UDP-syslog, blir ikke en TLS-avsender fordi du la til en tunnel; den vil fortsatt sende ubekreftede datagrammer, nå inne i en kryptert konvolutt.

Så kartlegg avsenderen først: protokoll, TLS-støtte og hvilket TLS-bibliotek, om den kan validere samlerens sertifikat, om den kan presentere et klientsertifikat, og om sendebufferen overlever en omstart. Alt enheten ikke kan, må gjøres av noe annet på veien, og det andre blir en del av designet ditt.

TLS-syslog: den korteste veien når begge ender snakker den

Hvis enheten støtter syslog over TLS og samleren terminerer det, bruk det og stopp. Applikasjonsprotokollen beskytter seg selv, samleren autentiserer avsenderen, og det er ikke et ekstra hopp hvis tilgjengelighet du nå eier. Haken er at «TLS-syslog» dekker et bredt spekter av implementasjoner, og de gjeldende retningslinjene for sikker syslog har beveget seg forbi chifferlistene i eldre veiledninger, og det er derfor en fungerende videresender blir ødelagt etter en bibliotekoppgradering.

I rsyslog forteller selve navnet på transportmodulen hvilken æra du er i: lmnsd_gtls pakker inn GnuTLS, mens lmnsd_ossl pakker inn OpenSSL og det er det gjeldende 8.x-pakker leverer. En videresending med sertifikatvalidering ser omtrent slik ut, og de nøyaktige parameternavnene er verdt å sjekke 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øker avsenderen. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error fullfører enten en håndtrykk med en gyldig kjede eller forteller deg nøyaktig hvilken sjekk som feilet. Test fra enheten, ikke fra den bærbare, fordi enhetens tillitslager er det som teller.

SFTP: bra for filer, feil for strømmer

Filbasert levering passer for enheter som skriver roterende logger og ingenting annet. SSH-basert overføring gir deg vertsnøkler, nøkler per konto og et filsystem du kan revidere, noe som er en rimelig tillitshistorie for en enhet som ikke kan TLS i det hele tatt. Det er et dårlig valg for hendelsesstrømmer, der «filen skrives hver time» betyr at et avbrudd koster deg halen av den gjeldende timen.

La vertsvalideringen være på. Et batch-kall som slår den av for å unngå en forespørsel, ødelegger den eneste autentiseringen 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 kontoens known_hosts under klargjøringen, begrens kontoen til målkatalogen, og foretrekk internal-sftp-undersystemet med chroot. Planlegg også historien om ny innsending: hvis en fil sendes på nytt etter en delvis feil, må samleren kunne skille en duplikat fra en ny fil, vanligvis etter navn pluss kontrollsum og ikke etter ankomsttid.

Når en lokal gateway eller tunnel er det ærlige svaret

Noen enheter kan bare snakke et format ingen vil eksponere. I så fall mottar en autorisert samler på enhetens eget nettverk det opprinnelige formatet og videresender det videre over TLS. Det er et legitimt design, men vær presis om hva det kjøper: kryptering som starter ved gatewayen, beskytter ikke segmentet mellom enheten og gatewayen bakover, så det hoppet trenger fortsatt sin egen tillitsgrense og tilgangskontroll.

En rutet nettsteds- eller enhetstunnel er det tyngste alternativet og det riktige når samleren må beholde en privat adresse og bære flere tjenester, ikke bare logger. Den bringer adresseplanlegging, tilgangsregler, returveier og livssyklusen til tunnelens endepunkt. Den forbedrer heller ikke den indre protokollen: UDP-syslog inne i en IPsec-tunnel er fortsatt en datagramtjeneste uten leveringsbekreftelse.

Uansett hva du velger, hold samlerens autorisasjon strammere enn transporten. En tunnelidentitet tilhører et endepunkt, og den sier ingenting om hvilken underliggende enhet som produserte et gitt vertsnavnfelt i en melding.

Skriv leveringskontrakten før du sender

Kryptering, autentisering og oppbevaring svarer på forskjellige spørsmål, og en kø er ikke en oppbevaringspolicy. Før den første loggen forlater enheten, må du bestemme hva en bekreftelse faktisk betyr på denne samleren: mottatt på ledningen, akseptert for behandling eller varig skrevet til lagring. Det er tre forskjellige garantier, og bare den siste overlever en omstart av samleren.

Svar deretter skriftlig på driftsspørsmålene. Hvor venter usendte hendelser, og overlever den bufferen et strømbrudd? Hva skjer når den blir full, og hvem får beskjed? Hvordan er nye forsøk begrenset, og hvordan identifiseres duplikater? Hvilket felt beviser avsenderens identitet, gitt at et videresendingshopp kan skrive om vertsnavnet?

Hold designet lite nok til å forklares i ett avsnitt: den minste støttede transporten som bærer de nødvendige hendelsene, pluss en uttrykkelig erklæring om garantiene den ikke gir. Hvis svaret krever to hopp, si det i runbooken og gi hvert hopp en eier.