Logging centralizzato che regge a una revisione di incidente

La vera prova del logging centralizzato non è se i messaggi arrivano in un pomeriggio tranquillo. È se, la mattina dopo che qualcosa è andato storto, riuscite a mettere insieme in pochi minuti una cronologia completa e ordinata correttamente attraverso router, firewall, storage e server. Per questo serve una pipeline costruita apposta. Ecco come costruiamo la nostra in Graylog, e cosa copiare per la vostra.

Partite dalla domanda che farete

Ogni scelta di progettazione in una pipeline di logging deve servire una domanda: «cosa è successo, ovunque, tra questi due istanti?». Quella domanda fallisce in quattro modi prevedibili. Mancano messaggi per una parte della finestra. Lo stesso dispositivo compare sotto più nomi, così una ricerca trova solo parte della sua storia. Gli orologi non concordano, così gli eventi finiscono nell'ordine sbagliato. Oppure tutto è in un unico mucchio indifferenziato, così le righe importanti sono sepolte. Ogni sezione qui sotto elimina uno di quei fallimenti.

Inoltrate in modo affidabile, e bufferizzate su disco

Il classico syslog su UDP è fire and forget: il mittente non sa mai se qualcosa ha ricevuto il messaggio. Per i server preferiamo l'inoltro TCP con una coda assistita da disco, così un riavvio del collector o un singhiozzo di rete ritarda i log invece di perderli. Un'action rsyslog minimale:

action(type="omfwd" target="<collector>" port="514" protocol="tcp"
       template="RSYSLOG_SyslogProtocol23Format"
       queue.type="LinkedList" queue.filename="fwd_central"
       queue.maxDiskSpace="1g" queue.saveOnShutdown="on"
       action.resumeRetryCount="-1")

Il template invia messaggi strutturati RFC 5424 con timestamp completo e hostname. La coda conserva su disco i messaggi non consegnati e ritenta finché il collector non torna. Validate con rsyslogd -N1 prima di riavviare il servizio.

I dispositivi di rete sono di solito limitati al syslog semplice, quindi per loro la protezione è diversa: inviate al collector da un indirizzo sorgente e da un'istanza di routing che possano sempre raggiungerlo, e verificate quel percorso ogni volta che il routing del dispositivo cambia.

Date a ogni dispositivo esattamente un nome

I vendor non concordano su cosa vada nell'header syslog. Alcuni dispositivi omettono il proprio hostname, alcuni inviano un nome breve, alcuni un indirizzo, e lo stesso dispositivo può cambiare formato dopo un aggiornamento software. Se il collector memorizza quello che arriva, un router finisce sparso su tre nomi sorgente, e una ricerca su di lui restituisce un terzo della sua storia.

Lo correggiamo all'ingresso. Una regola di pipeline Graylog riscrive la sorgente di ogni messaggio in un unico nome canonico del dispositivo, usando una lookup table indicizzata sull'indirizzo del mittente:

rule "normalise source name"
when
  has_field("gl2_remote_ip")
then
  let name = lookup_value("device_names", to_string($message.gl2_remote_ip));
  set_field("source", name);
end

Tenete la lookup table allineata con il vostro inventario, così un nuovo dispositivo riceve il suo nome pulito il giorno in cui viene registrato, non il giorno in cui qualcuno si accorge che manca.

Mettete a posto gli orologi

Ogni dispositivo dovrebbe loggare in UTC o portare un offset esplicito. Mescolare ora locale e UTC tra dispositivi è il modo classico per far sembrare che un incidente sia avvenuto nell'ordine sbagliato. Due verifiche rapide su un host Linux:

chronyc tracking   # offset from the reference, should be tiny
timedatectl        # time zone and whether NTP is synchronised

Sugli apparati di rete, controllate il comando di stato equivalente e assicuratevi che il timestamp del logging includa data, millisecondi e fuso orario. I secondi non bastano quando due router reagiscono allo stesso evento.

Instradate i messaggi in stream per ruolo

Un unico firehose è illeggibile. Instradiamo i messaggi in stream per ruolo: routing core, fabric del datacenter, firewall, storage, host. Poiché ogni sorgente ha ora un nome pulito, l'instradamento è questione di confrontare i nomi o un campo ruolo impostato dalla stessa pipeline. Ogni stream ha come lettori naturali le persone che gestiscono quei sistemi, e ciascuno può avere la propria retention, progettata per corrispondere a ciò che il servizio e un eventuale auditor richiedono.

Allarmate sui problemi, e sul silenzio

Allarmate su ciò che precede i problemi

Una volta che i log sono puliti e nel posto giusto, le righe di valore devono raggiungere una persona mentre contano ancora. Definiamo eventi per i messaggi che tendono ad arrivare prima di un'interruzione: una sessione BGP che cade, un link che fa flapping, BFD che dichiara morto un percorso, sessioni di cifratura che si rigenerano di continuo su un backbone, un guasto hardware, un errore fibre channel su una fabric di storage, un pool di indirizzi che si esaurisce. Arrivano all'ingegnere reperibile nella chat operativa nel momento in cui accadono, così il log diventa un allarme precoce invece di un'autopsia.

Allarmate anche sul silenzio

Un dispositivo che smette di inviare sembra esattamente un dispositivo che non ha nulla da dire. Quindi allarmate sull'assenza: un evento che scatta quando una sorgente che normalmente parla è rimasta in silenzio più a lungo di quanto faccia mai. Ai dispositivi naturalmente silenziosi date qualcosa da dire, come una riga di heartbeat scritta da un timer ogni ora, così il silenzio diventa un segnale. Dopo qualsiasi modifica che possa disturbare il percorso, inviate un messaggio di prova e trovatelo all'altro capo; il nostro team di rete descrive quella verifica, e il resto di un autotest del monitoraggio, in Testate il percorso dell'allarme, non la dashboard.

Controllate la vostra pipeline

• Qualche dispositivo compare sotto più di un nome sorgente?
• Cosa succede ai log di un server se il collector è giù per dieci minuti?
• Tutti gli orologi sono sincronizzati sulle stesse sorgenti, con fusi orari espliciti?
• Riuscite a trovare i messaggi di ogni firewall in un solo stream?
• Esiste un allarme per una sorgente che è diventata silenziosa?

Se volete log su cui contare durante una revisione di incidente, siamo lieti di aiutarvi a costruire la pipeline e a testarla. Parla con un ingegnere

Related

Correlati: Telemetria di rete e di alimentazione, logging, rilevamento DDoS · Monitoraggio della flotta e instradamento degli allarmi