Så skickar du enhetsloggar säkert till en fjärrsamlare

Enheten kan sända ut loggar, insamlaren står på andra sidan internet, och den första frågan alla ställer är vilken tunnel som ska byggas. Den ramen börjar på fel ställe. Det som avgör transporten är formatet enheten kan producera, autentiseringen insamlaren accepterar och vad ”levererad” ska betyda när länken faller. Skriv ned de tre svaren, och transporten väljer oftast sig själv.

Börja med det enheten kan sända ut

I praktiken finns bara tre former. Enskilda syslog-händelser över UDP eller TCP, en autentiserad HTTPS-uppladdning inbyggd i produkten, eller kompletta filer som skrivs till disk och måste flyttas. En brandvägg som bara kan skicka UDP-syslog blir inte en TLS-avsändare för att du lade till en tunnel; den fortsätter skicka obekräftade datagram, nu i ett krypterat kuvert.

Kartlägg därför avsändaren först: protokoll, TLS-stöd och vilket TLS-bibliotek, om den kan validera insamlarens certifikat, om den kan presentera ett klientcertifikat och om sändbufferten överlever en omstart. Allt enheten inte kan måste göras av något annat på vägen, och det andra blir en del av din design.

TLS-syslog: den kortaste vägen när båda ändar talar den

Om enheten stöder syslog över TLS och insamlaren terminerar det, använd det och sluta. Applikationsprotokollet skyddar sig självt, insamlaren autentiserar avsändaren, och det finns ingen extra hopp vars tillgänglighet du nu äger. Haken är att ”TLS-syslog” täcker ett brett spektrum av implementationer, och de nuvarande riktlinjerna för säker syslog har gått förbi chifferlistorna i äldre guider, och det är därför en fungerande vidarebefordrare går sönder efter en biblioteksuppdatering.

I rsyslog säger själva namnet på transportmodulen vilken era du är i: lmnsd_gtls omsluter GnuTLS, medan lmnsd_ossl omsluter OpenSSL och det är vad nuvarande 8.x-paket levererar. En vidarebefordran med certifikatvalidering ser ungefär ut så här, och de exakta parameternamnen är värda att kontrollera mot din installerade 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")

Validera slutpunkten innan du felsöker avsändaren. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error slutför antingen en handskakning med en giltig kedja eller berättar exakt vilken kontroll som misslyckades. Testa från enheten, inte från din laptop, eftersom enhetens förtroendelager är det som räknas.

SFTP: bra för filer, fel för strömmar

Filbaserad leverans passar enheter som skriver roterande loggar och inget annat. SSH-baserad överföring ger dig värdnycklar, nycklar per konto och ett filsystem du kan granska, vilket är en rimlig förtroendehistoria för en enhet som inte kan TLS alls. Det är ett dåligt val för händelseströmmar, där ”filen skrivs varje timme” betyder att ett avbrott kostar dig slutet av den aktuella timmen.

Låt värdverifieringen vara på. Ett batch-anrop som stänger av den för att undvika en fråga förstör den enda autentisering transporten har:

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

Fäst värdnyckeln i kontots known_hosts under etableringen, begränsa kontot till målkatalogen och föredra internal-sftp-undersystemet med chroot. Planera också historien om återsändning: om en fil skickas igen efter ett delvis misslyckande måste insamlaren kunna skilja en dubblett från en ny fil, vanligtvis på namn plus kontrollsumma och inte på ankomsttid.

När en lokal gateway eller tunnel är det ärliga svaret

Vissa enheter kan bara tala ett format som ingen vill exponera. I så fall tar en auktoriserad insamlare på enhetens eget nätverk emot det inbyggda formatet och vidarebefordrar det över TLS. Det är en legitim design, men var precis om vad den köper: kryptering som börjar vid gatewayen skyddar inte segmentet mellan enheten och gatewayen i efterhand, så det hoppet behöver fortfarande sin egen förtroendegräns och åtkomstkontroll.

En routad plats- eller enhetstunnel är det tyngsta alternativet och det rätta när insamlaren måste behålla en privat adress och bära flera tjänster, inte bara loggar. Den tillför adressplanering, åtkomstregler, returvägar och livscykeln för tunnelns slutpunkt. Den förbättrar inte heller det inre protokollet: UDP-syslog i en IPsec-tunnel är fortfarande en datagramtjänst utan leveransbekräftelse.

Vad du än väljer, håll insamlarens auktorisation snävare än transporten. En tunnelidentitet tillhör en slutpunkt och säger ingenting om vilken underliggande enhet som producerade ett visst värdnamnsfält i ett meddelande.

Skriv leveransavtalet innan du skickar

Kryptering, autentisering och lagring svarar på olika frågor, och en kö är inte en lagringspolicy. Innan den första loggen lämnar enheten, bestäm vad en bekräftelse egentligen betyder hos den här insamlaren: mottagen på tråden, accepterad för bearbetning eller varaktigt skriven till lagring. Det är tre olika garantier och bara den sista överlever en omstart av insamlaren.

Svara sedan skriftligt på driftfrågorna. Var väntar oskickade händelser, och överlever bufferten ett strömavbrott? Vad händer när den blir full, och vem meddelas? Hur begränsas återförsöken, och hur identifieras dubbletter? Vilket fält bevisar avsändarens identitet, med tanke på att ett vidarebefordringshopp kan skriva om värdnamnet?

Håll designen liten nog att förklaras i ett stycke: den minsta stödda transport som bär de nödvändiga händelserna, plus ett uttryckligt uttalande om de garantier den inte ger. Om svaret kräver två hopp, säg det i runbooken och ge varje hopp en ägare.