Sådan sender du enhedslogfiler sikkert til en fjernindsamler

Enheden kan udsende logfiler, indsamleren står på den anden side af internettet, og det første spørgsmål, alle stiller, er, hvilken tunnel der skal bygges. Den ramme starter det forkerte sted. Det, der afgør transporten, er det format, enheden kan producere, den godkendelse, indsamleren vil acceptere, og hvad „leveret“ skal betyde, når forbindelsen falder. Skriv de tre svar ned, og så vælger transporten som regel sig selv.

Tag udgangspunkt i det, enheden kan udsende

I praksis findes der kun tre former. Enkelte syslog-hændelser over UDP eller TCP, en godkendt HTTPS-upload indbygget i produktet, eller komplette filer skrevet til disken, som skal flyttes. En firewall, der kun kan sende UDP-syslog, bliver ikke en TLS-afsender, fordi du har tilføjet en tunnel; den vil stadig sende ubekræftede datagrammer, nu inde i en krypteret konvolut.

Så lav først en oversigt over afsenderen: protokol, TLS-understøttelse og hvilket TLS-bibliotek, om den kan validere indsamlerens certifikat, om den kan fremvise et klientcertifikat, og om sendebufferen overlever en genstart. Alt, hvad enheden ikke kan, skal gøres af noget andet på vejen, og det noget andet bliver en del af dit design.

TLS-syslog: den korteste vej, når begge ender taler den

Hvis enheden understøtter syslog over TLS, og indsamleren terminerer det, så brug det og stop. Applikationsprotokollen beskytter sig selv, indsamleren godkender afsenderen, og der er ikke et ekstra hop, hvis tilgængelighed du nu ejer. Haken er, at „TLS-syslog“ dækker et bredt udvalg af implementeringer, og de nuværende retningslinjer for sikker syslog har bevæget sig videre fra cipher-listerne i ældre vejledninger, og det er derfor, en fungerende videresender bliver en brudt en efter en biblioteksopgradering.

I rsyslog fortæller selve transportmodulens navn, hvilken æra du er i: lmnsd_gtls indpakker GnuTLS, mens lmnsd_ossl indpakker OpenSSL og er det, nuværende 8.x-pakker leverer. En videresendelseshandling med certifikatvalidering ser nogenlunde sådan ud, og de præcise parameternavne er værd at tjekke mod din installerede version:

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

Validér endepunktet, før du fejlretter afsenderen. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error enten fuldfører et håndtryk med en gyldig kæde eller fortæller dig præcis, hvilken kontrol der fejlede. Test fra enheden, ikke fra din bærbare, fordi det er enhedens tillidslager, der tæller.

SFTP: godt til filer, forkert til streams

Filbaseret levering passer til enheder, der skriver roterende logfiler og intet andet. SSH-baseret overførsel giver dig værtsnøgler, nøgler pr. konto og et filsystem, du kan revidere, hvilket er en rimelig tillidshistorie for en enhed, der slet ikke kan TLS. Det er et dårligt valg til hændelsesstrømme, hvor „filen skrives hver time“ betyder, at et udfald koster dig halen af den aktuelle time.

Lad værtsvalidering være slået til. Et batch-kald, der slår det fra for at undgå en prompt, ødelægger den eneste godkendelse, transporten har:

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

Fastgør værtsnøglen i kontoens known_hosts under klargøringen, begræns kontoen til målkataloget, og foretræk internal-sftp-undersystemet med chroot. Planlæg også gensendelseshistorien: hvis en fil sendes igen efter en delvis fejl, skal indsamleren kunne skelne en dublet fra en ny fil, normalt efter navn plus kontrolsum og ikke efter ankomsttid.

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

Nogle enheder kan kun tale et format, som ingen vil eksponere. I så fald modtager en autoriseret indsamler på enhedens eget netværk det oprindelige format og videresender det videre over TLS. Det er et legitimt design, men vær præcis om, hvad det køber: kryptering, der starter ved gatewayen, beskytter ikke bagudrettet segmentet mellem enheden og gatewayen, så det hop har stadig brug for sin egen tillidsgrænse og adgangskontrol.

En rutet lokalitets- eller enhedstunnel er den tungeste mulighed og den rigtige, når indsamleren skal beholde en privat adresse og bære flere tjenester, ikke kun logfiler. Den bringer adresseplanlægning, adgangsregler, returveje og livscyklussen for tunnelens endepunkt. Den forbedrer heller ikke den indre protokol: UDP-syslog inde i en IPsec-tunnel er stadig en datagramtjeneste uden leveringsbekræftelse.

Uanset hvad du vælger, hold indsamlerens autorisation strammere end transporten. En tunnelidentitet tilhører et endepunkt og siger intet om, hvilken underliggende enhed der producerede et givet værtsnavnefelt i en besked.

Skriv leveringskontrakten, før du sender

Kryptering, godkendelse og opbevaring besvarer forskellige spørgsmål, og en kø er ikke en opbevaringspolitik. Før den første log forlader enheden, skal du beslutte, hvad en bekræftelse egentlig betyder på denne indsamler: modtaget på ledningen, accepteret til behandling eller holdbart skrevet til lageret. Det er tre forskellige garantier, og kun den sidste overlever en genstart af indsamleren.

Svar derefter skriftligt på de operationelle spørgsmål. Hvor venter usendte hændelser, og overlever den buffer en strømafbrydelse? Hvad sker der, når den bliver fuld, og hvem får besked? Hvordan er genforsøg begrænset, og hvordan identificeres dubletter? Hvilket felt beviser afsenderens identitet, når et videresendelseshop kan omskrive værtsnavnet?

Hold designet lille nok til at forklare i ét afsnit: den mindste understøttede transport, der bærer de krævede hændelser, plus en udtrykkelig erklæring om de garantier, den ikke giver. Hvis svaret kræver to hop, så sig det i runbooken, og giv hvert hop en ejer.