Com enviar els registres d'un aparell a un col·lector remot de manera segura

L'aparell pot emetre registres, el col·lector és a l'altre costat d'Internet i la primera pregunta que tothom fa és quin túnel cal construir. Aquest plantejament comença al lloc equivocat. El que decideix el transport és el format que l'aparell pot produir, l'autenticació que el col·lector acceptarà i què ha de significar «lliurat» quan l'enllaç cau. Pengeu aquestes tres respostes per escrit i el transport normalment s'escull sol.

Partiu del que l'aparell pot emetre

A la pràctica només hi ha tres formes. Esdeveniments syslog individuals per UDP o TCP, una pujada HTTPS autenticada integrada al producte, o fitxers sencers escrits al disc que cal moure. Un tallafoc que només pot enviar syslog UDP no es convertirà en un emissor TLS perquè hàgiu afegit un túnel; continuarà enviant datagrames sense confirmació, ara dins d'un sobre xifrat.

Així, primer feu inventari de l'emissor: protocol, suport de TLS i quina biblioteca TLS, si pot validar el certificat del col·lector, si pot presentar un certificat de client i si el búfer d'enviament sobreviu a un reinici. Tot el que l'aparell no pot fer ho ha de fer una altra cosa al camí, i aquesta altra cosa passa a formar part del vostre disseny.

Syslog TLS: el camí més curt quan tots dos costats el parlen

Si l'aparell admet syslog sobre TLS i el col·lector el termina, feu servir això i atureu-vos. El protocol d'aplicació es protegeix sol, el col·lector autentica l'emissor i no hi ha cap salt addicional la disponibilitat del qual ara poseeixeu. La trampa és que «syslog TLS» cobreix un ventall ampli d'implementacions, i les directrius actuals de syslog segur han anat més enllà de les llistes de xifradors dels tutorials antics, i per això un reenviador que funciona es trenca després d'actualitzar una biblioteca.

A rsyslog, el nom del mòdul de transport ja us diu en quina època sou: lmnsd_gtls embolcalla GnuTLS, mentre que lmnsd_ossl embolcalla OpenSSL i és el que porten els paquets 8.x actuals. Una acció de reenviament amb verificació de certificat s'assembla aproximadament a això, i val la pena comprovar els noms exactes dels paràmetres amb la versió instal·lada:

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

Verifiqueu el punt final abans de depurar l'emissor. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error o bé completa una negociació amb una cadena vàlida o bé us diu exactament quina comprovació ha fallat. Proveu-ho des de l'aparell, no des del portàtil, perquè el magatzem de confiança de l'aparell és el que importa.

SFTP: bo per a fitxers, equivocat per a fluxos

El lliurament basat en fitxers s'adequa als aparells que escriuen registres rotatius i res més. La transferència per SSH us dona claus d'amfitrió, claus per compte i un sistema de fitxers que podeu auditar, cosa que és una història de confiança raonable per a un dispositiu que no pot fer TLS de cap manera. És una mala opció per a fluxos d'esdeveniments, on «el fitxer s'escriu cada hora» significa que una caiguda us costa la cua de l'hora actual.

Mantingueu la verificació d'amfitrió activada. Una invocació per lots que la desactiva per evitar una indicació destrueix l'única autenticació que té el transport:

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

Fixeu la clau d'amfitrió al known_hosts del compte durant l'aprovisionament, limiteu el compte al directori de destinació i preferiu el subsistema internal-sftp amb chroot. Planifiqueu també la història de reenviament: si un fitxer es torna a enviar després d'un error parcial, el col·lector ha de saber distingir un duplicat d'un fitxer nou, normalment pel nom més la suma de verificació i no pel moment d'arribada.

Quan una passarel·la local o un túnel és la resposta honesta

Alguns aparells només saben parlar un format que ningú vol exposar. En aquest cas, un col·lector autoritzat a la mateixa xarxa de l'aparell rep el format natiu i el reenvia més enllà per TLS. És un disseny legítim, però sigueu precisos sobre què compra: el xifratge que comença a la passarel·la no protegeix retroactivament el segment entre l'aparell i la passarel·la, així que aquell salt encara necessita la seva pròpia frontera de confiança i control d'accés.

Un túnel encaminat de lloc o de dispositiu és l'opció més pesada i la correcta quan el col·lector ha de conservar una adreça privada i ha de transportar diversos serveis, no només registres. Arriba amb planificació d'adreces, regles d'accés, camins de retorn i el cicle de vida del punt final del túnel. Tampoc no millora el protocol intern: el syslog UDP dins d'un túnel IPsec continua essent un servei de datagrames sense confirmació de lliurament.

Trieu el que trieu, manteniu l'autorització del col·lector més estreta que el transport. La identitat del túnel pertany a un punt final i no diu res sobre quin aparell inferior va produir un camp de nom d'amfitrió concret en un missatge.

Escriviu el contracte de lliurament abans d'enviar

Xifratge, autenticació i retenció responen preguntes diferents, i una cua no és una política de retenció. Abans que el primer registre surti de l'aparell, decidiu què significa realment una confirmació en aquest col·lector: rebut al cable, acceptat per processar o escrit de manera duradora a l'emmagatzematge. Són tres garanties diferents i només l'última sobreviu a un reinici del col·lector.

Després responeu per escrit les preguntes operatives. On esperen els esdeveniments no enviats, i aquest búfer sobreviu a un tall de llum? Què passa quan s'omple, i a qui s'avisa? Com es limiten els reintents, i com s'identifiquen els duplicats? Quin camp demostra la identitat de l'emissor, atès que un salt de reenviament pot reescriure el nom d'amfitrió?

Mantingueu el disseny prou petit per explicar-lo en un paràgraf: el transport admès més petit que porti els esdeveniments necessaris, més una declaració explícita de les garanties que no ofereix. Si la resposta necessita dos salts, digueu-ho al runbook i doneu a cada salt un responsable.