8. Security Considerations (Considerazioni sulla sicurezza)
Syslog può trasportare informazioni sul livello di sicurezza di varie applicazioni su un sistema. Pertanto, i trasporti syslog stessi possono diventare obiettivi di attacchi in alcune distribuzioni, possibilmente prima che qualsiasi avviso di sicurezza a livello di applicazione possa essere trasmesso ai responsabili. Per questo motivo, questo documento raccomanda fortemente che i trasporti syslog utilizzino TLS, come specificato in [RFC5425]. Questo trasporto impone un minimo di sicurezza e può essere configurato per fornire molto di più.
Il traffico di rete dannoso (o applicazioni ostili con accesso al trasporto syslog su macchine locali) può ingannare il trasportatore syslog facendogli credere che un attacco sia in corso. Un sistema di difesa può quindi intraprendere azioni per spegnere macchine o segmenti di rete che in realtà non sono sotto attacco.
Una soluzione a questo problema è che gli originators firmino digitalmente i loro messaggi. I ricevitori possono quindi verificare che il messaggio sia stato inviato da una fonte nota e non sia stato alterato. Tuttavia, questo non risolve il problema di una macchina compromessa, certificata dal suo legittimo proprietario, che riporta falsamente un attacco.
L'ordine degli elementi STRUCTURED-DATA o dei loro SD-PARAM non è specificato. Sebbene gli elementi STRUCTURED-DATA siano facili da analizzare, questo fatto significa che è più costoso trovare un particolare elemento quando sono presenti molti di tali elementi.
Per questo motivo, le applicazioni syslog dovrebbero evitare quantità eccessivamente grandi di STRUCTURED-DATA in un singolo messaggio. Per limitare ulteriormente il problema, la specifica pone un limite superiore di 32 caratteri per i nomi degli elementi di dati strutturati (la lunghezza di SD-ID e PARAM-NAME). Tuttavia, anche con questo limite, un mittente dannoso può inondare collectors (o altre applicazioni syslog) con molti elementi STRUCTURED-DATA o STRUCTURED-DATA non validi. I ricevitori DOVREBBERO avere meccanismi per rilevare e tollerare tali attacchi. Ciò può includere l'ignorare dati strutturati non corretti, limitare quanti elementi vengono elaborati o scartare messaggi con troppi elementi.
Inoltre, messaggi syslog più lunghi possono essere utilizzati per inondare l'infrastruttura syslog. Un relay o collector DOVREBBE prendere misure appropriate per impedire che venga inondato.
Un originator non dovrebbe inviare timestamp falsificati. Tuttavia, i ricevitori non dovrebbero presumere di aver ricevuto un timestamp corretto. Il ricevitore dovrebbe considerare il TIMESTAMP come una rappresentazione di quando l'originator credeva che l'evento si fosse verificato. Non dovrebbe considerarlo come il tempo accurato dell'evento stesso.
I messaggi syslog dovrebbero essere utilizzati per segnalare eventi, ma non dovrebbero servire come unico canale attraverso cui vengono segnalati eventi critici. Ad esempio, un evento critico come uno spegnimento immediato del sistema non dovrebbe essere segnalato esclusivamente tramite syslog. Un operatore responsabile non dovrebbe presumere che i messaggi vengano trasmessi con successo tramite syslog. I sistemi che trasmettono eventi critici dovrebbero avere più canali per trasmettere tali informazioni.
Una macchina può inviare messaggi per conto di altre macchine. Ad esempio, un log del router DOVREBBE avere il router come HOSTNAME, ma può anche passare attraverso un collector. I ricevitori dovrebbero esserne consapevoli quando elaborano i messaggi, specialmente quando i messaggi provengono attraverso meccanismi di trasporto non sicuri.
I messaggi da un particolare HOSTNAME possono anche provenire da indirizzi di rete diversi. I ricevitori dovrebbero esserne consapevoli anche quando ricevono messaggi. Questo non è necessariamente un rischio per la sicurezza, ma una realtà delle varie configurazioni di rete.