Passa al contenuto principale

Appendix A. Implementer Guidelines (Linee guida per gli implementatori)

Questa appendice non è normativa.

Ogni implementazione syslog DOVREBBE essere in grado di accettare messaggi fino a una lunghezza di almeno 480 ottetti. Questa è la lunghezza minima richiesta. Le implementazioni DOVREBBERO essere in grado di accettare messaggi fino a una lunghezza di 2048 ottetti.

A.2. Transport Considerations (Considerazioni sul trasporto)

Gli implementatori dovrebbero essere consapevoli delle diverse proprietà offerte dai vari trasporti:

  • Trasporto UDP: Non fornisce garanzie di consegna. I messaggi possono essere persi, duplicati o riordinati.

  • Trasporto TLS: Fornisce consegna affidabile e ordinata dei messaggi e riservatezza.

A.3. Syslog Message Format (Formato del messaggio Syslog)

A.3.1. PRI Part (Parte PRI)

La parte PRI del messaggio syslog è compatibile con il syslog BSD originale, come documentato in [RFC3164].

A.3.2. VERSION (Versione)

L'introduzione del campo VERSION consente di distinguere diverse versioni del messaggio syslog. Questo è importante per la futura sicurezza del protocollo.

A.3.3. TIMESTAMP (Marca temporale)

Il formato TIMESTAMP utilizzato in questo documento si basa su [RFC3339]. Questo fornisce una rappresentazione del tempo precisa e standardizzata internazionalmente.

Gli implementatori dovrebbero notare che:

  • L'uso di UTC è raccomandato quando possibile.
  • Gli offset del fuso orario dovrebbero essere utilizzati quando si utilizza il tempo locale.
  • La precisione della marca temporale dovrebbe essere indicata tramite l'SD-ID "timeQuality" se non è ottimale.

A.3.4. HOSTNAME

Il campo HOSTNAME dovrebbe contenere il Fully Qualified Domain Name (FQDN) quando disponibile. Se il FQDN non è disponibile, possono essere utilizzati valori alternativi, come descritto nella Sezione 6.2.4.

A.3.5. STRUCTURED-DATA (Dati strutturati)

STRUCTURED-DATA è una funzionalità potente che consente di trasportare informazioni strutturate in un messaggio syslog. Gli implementatori dovrebbero:

  • Utilizzare gli SD-ID predefiniti quando appropriati per la loro applicazione.
  • Creare propri SD-ID con il loro numero di impresa privata quando è necessario trasmettere informazioni speciali.
  • Limitare il numero di SD-ELEMENT in un singolo messaggio per evitare problemi di prestazioni.

A.3.6. MSG Part (Parte MSG)

La parte MSG contiene il messaggio di testo libero. Gli implementatori dovrebbero:

  • Utilizzare la codifica UTF-8 quando sono necessari caratteri internazionali.
  • Utilizzare il BOM per indicare che viene utilizzato UTF-8.
  • Evitare l'uso di caratteri di controllo quando possibile.

A.4. Relay Considerations (Considerazioni sui relay)

Un relay riceve messaggi syslog e li inoltra. I relay dovrebbero:

  • Non modificare i messaggi a meno che non sia assolutamente necessario.
  • Aggiornare il TIMESTAMP se lo fanno, dovrebbero documentarlo in STRUCTURED-DATA.
  • Inoltrare STRUCTURED-DATA non corretti senza modifiche.

A.5. Security Considerations (Considerazioni sulla sicurezza)

Gli implementatori dovrebbero considerare le considerazioni sulla sicurezza descritte nella Sezione 8. In particolare, dovrebbero:

  • Utilizzare il trasporto TLS quando è richiesta la sicurezza.
  • Implementare meccanismi per proteggersi dagli attacchi di flooding.
  • Non presumere che le marche temporali siano accurate.
  • Utilizzare più canali per eventi critici.

A.6. Esempio di implementazione

Ecco un esempio di messaggio syslog completo:

<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOMAn application event log entry...

Questo messaggio mostra:

  • PRI: <165> (Facility=20 (local4), Severity=5 (notice))
  • VERSION: 1
  • TIMESTAMP: 2003-10-11T22:14:15.003Z (UTC)
  • HOSTNAME: mymachine.example.com
  • APP-NAME: evntslog
  • PROCID: - (NILVALUE)
  • MSGID: ID47
  • STRUCTURED-DATA: Un elemento con tre parametri
  • MSG: Codificato UTF-8 (con BOM)