Syslog protetto remoto Unisphere per PowerMax 9.2

Cronologia syslog

Syslog è stato sviluppato negli anni '80 da Eric Paul Allman (nato il 2 settembre 1955).
Eric è un programmatore di computer americano che ha sviluppato Sendmail e il suo precursore Delivermail tra la fine degli anni '70 e l'inizio degli anni '80 presso la UC Berkeley. Nel 1998, Allman e Greg Olson hanno co-fondato la società Sendmail, Inc. Formato di registrazione utilizzato dall'agente di trasferimento messaggi MTA, noto come syslog. Syslog è stato inizialmente utilizzato esclusivamente da Sendmail, ma alla fine è diventato un formato standard non ufficiale utilizzato da altri programmi non correlati per la registrazione. Successivamente, questo formato è stato ufficializzato dalla Rfc 3164 nel 2001; Tuttavia, il formato originale è stato reso obsoleto dalla revisione più recente, Rfc 5424.

Task force di ingegneria di Internet

L'Internet Engineering Task Force (IETF) è un'organizzazione di standard aperti, che sviluppa e promuove standard Internet volontari, in particolare gli standard che consistono nella suite di protocolli Internet (TCP/IP). 
Non ha un elenco formale di appartenenza o requisiti di appartenenza. Tutti i partecipanti e i manager sono volontari, anche se il loro lavoro è finanziato dai loro datori di lavoro o sponsor.

L'Internet Architecture Board (IAB) supervisiona le relazioni esterne dell'IETF e le relazioni con l'editore RFC. Lo IAB fornisce una direzione tecnica a lungo termine per lo sviluppo di Internet. Lo IAB è anche corresponsabile del Comitato di supervisione amministrativa IETF (IAOC), che supervisiona l'attività di supporto amministrativo IETF (IASA), che fornisce supporto logistico per l'IETF. 
Lo IAB gestisce anche l'Internet Research Task Force (IRTF), con la quale l'IETF ha diverse relazioni tra i gruppi.

Gruppo direttivo

L'Internet Engineering Steering Group (IESG) è un organismo composto dal presidente dell'Internet Engineering Task Force (IETF) e dai direttori di area. Fornisce la revisione tecnica finale degli standard Internet ed è responsabile della gestione quotidiana dell'IETF. Riceve i ricorsi contro le decisioni dei gruppi di lavoro e l'IESG prende la decisione di far progredire i documenti nel percorso degli standard.

Il protocollo Syslog

Syslog utilizes three layers
  o "syslog content" is the management information contained in a syslog message.
  o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
  o The "syslog transport" layer puts messages on the wire and takes them off the wire.
  o An "originator" generates syslog content to be carried in a message.
  o A "collector" gathers syslog content for further analysis.
  o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
  o A "transport sender" passes syslog messages to a specific transport protocol.
  o A "transport receiver" takes syslog messages from a specific transport protocol.

Diagram 1 shows the different entities separated by layer.

+-------------------------+  +----------------------+
 | content                |  | content              |
 |------------------------|  |----------------------|
 | syslog application     |  | syslog application   |
 |                        |  |                      | (originator,
 |                        |  |                      | (collector, relay)
 |------------------------|  |----------------------|
 | syslog transport       |  | syslog transport     | (transport sender,
 |                        |  |                      | (transport receiver)
 +------------------------+  +----------------------+
      ^                                     ^
      |                                     |
          -----------------------------

Come viene trasportato syslog?

Esistono due modi comuni per inviare messaggi syslog. Sebbene RFC 5424 richieda che tutte le implementazioni syslog supportino un trasporto di rete TLS crittografato su TCP, la maggior parte dei messaggi syslog viene ancora distribuita utilizzando il metodo UDP precedente. Nella versione UDP, i messaggi vengono semplicemente inseriti nella parte dati di un pacchetto UDP e inviati al server tramite la porta UDP 514. Ogni messaggio si adatta generalmente a un singolo pacchetto. UDP è senza stato e senza sessione, quindi non vi è alcun riconoscimento. I pacchetti vengono inviati alla rete. Questo ha l'ovvio problema che qualsiasi tipo di problema di rete potrebbe impedire la consegna del pacchetto, nel qual caso potresti non sapere che la rete è inattiva perché non può dirtelo. Significa anche che a volte pacchetti importanti possono essere persi o danneggiati durante il trasporto.

Principi di base

 I seguenti principi si applicano alla comunicazione syslog:
o Il protocollo syslog non fornisce la conferma della consegna dei messaggi. Sebbene alcuni trasporti possano fornire informazioni sullo stato, concettualmente syslog è un protocollo di comunicazione simplex puro.
 o Gli originatori e i relè possono essere configurati per inviare lo stesso messaggio a più raccoglitori e relè.
 o Le funzionalità di originatore, relè e raccoglitore possono risiedere sullo stesso sistema.

Mapping di trasporto minimo richiesto

 Tutte le implementazioni di questa specifica DEVONO supportare un trasporto basato su TLS come descritto in [RFC5425].
 Tutte le implementazioni di questa specifica DOVREBBERO supportare anche un trasporto basato su UDP come descritto in [RFC5426]. Si consiglia di utilizzare il trasporto basato su TLS per i deployment di questa specifica.
La natura libera dei messaggi syslog è il più grande punto di forza di syslog, ma è anche il più grande problema di syslog. È molto difficile analizzare un registro che include eventi provenienti da decine di sistemi diversi di fornitori diversi e dare loro un senso contemporaneamente. Quali messaggi rappresentano quali funzioni? E quali rappresentano gli eventi critici rispetto ai meri messaggi informativi?
Per rispondere a queste domande, il protocollo syslog (definito nella RFC 5424) fornisce questi messaggi in formato libero con campi speciali denominati "facility" e "severity".
(Si noti che RFC 5424 è lo standard per syslog, ma non tutte le implementazioni syslog sono conformi a RFC 5424. Il protocollo syslog esiste da molto tempo e ci sono alcune implementazioni pre-standard ancora in uso.)

Requisiti di sicurezza per Syslog

I messaggi Syslog possono transitare per diversi hop prima di arrivare al raccoglitore previsto. Alcune reti intermediarie potrebbero non essere considerate attendibili dall'originatore, dall'inoltro o dal destinatario perché la rete si trova in un dominio di sicurezza diverso o a un livello di sicurezza diverso dall'originatore, dall'inoltro o dall'agente di raccolta. Un altro problema di sicurezza è che l'originatore, il relè o il destinatario stesso si trova in una rete non protetta.
Esistono diverse minacce da affrontare per la sicurezza di syslog.

Le minacce principali sono:

  o Mascherata. Un mittente di trasporto non autorizzato può inviare messaggi a un destinatario di trasporto legittimo oppure un destinatario di trasporto non autorizzato può tentare di ingannare un mittente di trasporto legittimo inducendolo a inviargli messaggi syslog. 
 
  o Modifica. Un utente malintenzionato tra il mittente di trasporto e il destinatario di trasporto può modificare un messaggio syslog in transito e quindi inoltrare il messaggio al destinatario di trasporto. Tale modifica può indurre il destinatario del trasporto a fraintendere il messaggio o indurlo a comportarsi in modi indesiderati.

  o Divulgazione. Un entità non autorizzata può esaminare il contenuto dei messaggi syslog, ottenendo l'accesso non autorizzato alle informazioni. Alcuni dati nei messaggi syslog sono sensibili e possono essere utili per un utente malintenzionato, come la password di un amministratore o di un utente autorizzato.

La minaccia secondaria è

o Modifica del flusso dei messaggi. Un utente malintenzionato può eliminare uno o più messaggi syslog da una serie di messaggi, riprodurre nuovamente un messaggio o alterare la sequenza di recapito. Il protocollo syslog stesso non si basa sull'ordine dei messaggi. Tuttavia, un evento in un messaggio syslog può essere correlato semanticamente agli eventi di altri messaggi, pertanto l'ordinamento dei messaggi può essere importante per comprendere una sequenza di eventi.

Le seguenti minacce sono considerate di minore importanza per syslog e non vengono trattate in questo documento:
  o Denial of Service

o Analisi del traffico

Utilizzo di TLS per proteggere Syslog

TLS può essere utilizzato come trasporto sicuro per contrastare tutte le principali minacce a syslog descritte in precedenza

  o Riservatezza per contrastare la divulgazione del contenuto del messaggio.

  o Controllo dell'integrità per contrastare le modifiche apportate a un messaggio hop-by-hop.

  o Server o autenticazione reciproca per contrastare il mascheramento.

Nota: Questo trasporto sicuro (ovvero TLS) protegge solo il trasporto syslog in modo hop-by-hop e non riguarda il contenuto dei messaggi syslog. In particolare, l'identità autenticata del mittente del trasporto (ad esempio, il nome del soggetto nel certificato) non è necessariamente correlata al campo HOSTNAME del messaggio syslog. Quando è richiesta l'autenticazione dell'origine del messaggio syslog, è possibile utilizzare [SYS-SIGN].

Crittografia del traffico syslog con TLS (SSL)
https://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

GuidaSyslog e SIEM
di Dell Security Management Server https://www.dell.com/support/kbdoc/en-us/000124929/dell-security-management-server-syslog-and-siem-guide

Registrazione
Rsyshttps://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

 Guida utente Eventi e avvisi per PowerMax e VMAX 9.2

Guida di riferimento alla CLI di Solutions Enabler 9.2

Guida in linea di Unisphere for PowerMax 9.2.0