Come inviare i log di un'appliance a un raccoglitore remoto in sicurezza

L'appliance può emettere log, il raccoglitore si trova dall'altra parte di Internet, e la prima domanda che tutti fanno è quale tunnel costruire. Questa impostazione parte dal posto sbagliato. A decidere il trasporto sono il formato che l'appliance può produrre, l'autenticazione che il raccoglitore accetterà e che cosa deve significare «consegnato» quando il collegamento cade. Mettete per iscritto quelle tre risposte, e di solito il trasporto si sceglie da solo.

Partite da ciò che l'appliance può emettere

In pratica esistono solo tre forme. Eventi syslog individuali su UDP o TCP, un caricamento HTTPS autenticato integrato nel prodotto, oppure file completi scritti su disco che vanno spostati. Un firewall che può inviare solo syslog UDP non diventerà un mittente TLS perché avete aggiunto un tunnel; continuerà a inviare datagrammi non confermati, ora dentro una busta cifrata.

Quindi fate prima l'inventario del mittente: protocollo, supporto TLS e quale libreria TLS, se può validare il certificato del raccoglitore, se può presentare un certificato client e se il buffer di invio sopravvive a un riavvio. Tutto ciò che l'appliance non può fare deve farlo qualcos'altro sul percorso, e quel qualcos'altro diventa parte del vostro progetto.

Syslog TLS: il percorso più breve quando entrambe le estremità lo parlano

Se l'appliance supporta syslog su TLS e il raccoglitore lo termina, usatelo e fermatevi. Il protocollo applicativo protegge se stesso, il raccoglitore autentica il mittente e non c'è alcun salto aggiuntivo di cui ora possediate la disponibilità. La trappola è che «syslog TLS» copre un'ampia gamma di implementazioni, e le linee guida attuali per syslog sicuro sono andate oltre gli elenchi di cifrari dei vecchi tutorial, ed è così che un forwarder funzionante diventa rotto dopo un aggiornamento della libreria.

In rsyslog, il solo nome del modulo di trasporto dice in quale epoca siete: lmnsd_gtls avvolge GnuTLS, mentre lmnsd_ossl avvolge OpenSSL ed è quello che forniscono i pacchetti 8.x attuali. Un'azione di inoltro con verifica del certificato assomiglia all'incirca a questo, e vale la pena controllare i nomi esatti dei parametri rispetto alla versione installata:

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

Verificate l'endpoint prima di fare debug del mittente. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error o completa una stretta di mano con una catena valida o vi dice esattamente quale controllo è fallito. Provate dall'appliance, non dal vostro portatile, perché è l'archivio di fiducia dell'appliance che conta.

SFTP: buono per i file, sbagliato per i flussi

La consegna basata su file si adatta alle appliance che scrivono log a rotazione e nient'altro. Il trasferimento basato su SSH vi dà chiavi host, chiavi per account e un filesystem che potete verificare, il che è una storia di fiducia ragionevole per un dispositivo che non può fare TLS per niente. È una cattiva scelta per i flussi di eventi, dove «il file viene scritto ogni ora» significa che un'interruzione vi costa la coda dell'ora corrente.

Tenete attiva la verifica dell'host. Un'invocazione batch che la disattiva per evitare un prompt distrugge l'unica autenticazione che il trasporto ha:

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

Fissate la chiave host nel known_hosts dell'account durante il provisioning, limitate l'account alla directory di destinazione e preferite il sottosistema internal-sftp con chroot. Pianificate anche la storia della ritrasmissione: se un file viene reinviato dopo un guasto parziale, il raccoglitore deve distinguere un duplicato da un file nuovo, di solito per nome più checksum e non per ora di arrivo.

Quando un gateway locale o un tunnel è la risposta onesta

Alcune appliance sanno parlare solo un formato che nessuno vuole esporre. In quel caso un raccoglitore autorizzato sulla rete dell'appliance riceve il formato nativo e lo inoltra via TLS. È un progetto legittimo, ma siate precisi su cosa compra: la cifratura che parte dal gateway non protegge retroattivamente il segmento tra l'appliance e il gateway, quindi quel salto ha ancora bisogno del proprio confine di fiducia e del proprio controllo degli accessi.

Un tunnel instradato di sito o di dispositivo è l'opzione più pesante e quella giusta quando il raccoglitore deve conservare un indirizzo privato e trasportare più servizi, non solo log. Porta con sé pianificazione degli indirizzi, regole di accesso, percorsi di ritorno e il ciclo di vita dell'endpoint del tunnel. Non migliora nemmeno il protocollo interno: syslog UDP dentro un tunnel IPsec resta un servizio a datagrammi senza conferma di consegna.

Qualunque cosa scegliate, tenete l'autorizzazione del raccoglitore più stretta del trasporto. L'identità di un tunnel appartiene a un endpoint e non dice nulla su quale appliance a valle abbia prodotto un certo campo hostname in un messaggio.

Scrivete il contratto di consegna prima di spedire

Cifratura, autenticazione e conservazione rispondono a domande diverse, e una coda non è una politica di conservazione. Prima che il primo log lasci l'appliance, decidete che cosa significa davvero una conferma su questo raccoglitore: ricevuto sul filo, accettato per l'elaborazione o scritto in modo durevole nella memoria. Sono tre garanzie diverse e solo l'ultima sopravvive a un riavvio del raccoglitore.

Poi rispondete per iscritto alle domande operative. Dove attendono gli eventi non inviati, e quel buffer sopravvive a un'interruzione di corrente? Cosa succede quando si riempie, e chi viene avvisato? Come sono limitati i tentativi, e come vengono identificati i duplicati? Quale campo prova l'identità del mittente, dato che un salto di inoltro può riscrivere il nome host?

Tenete il progetto abbastanza piccolo da spiegarlo in un paragrafo: il più piccolo trasporto supportato che porta gli eventi richiesti, più una dichiarazione esplicita delle garanzie che non offre. Se la risposta richiede due salti, ditelo nel runbook e date a ogni salto un responsabile.