Appendix A. Implementer Guidelines (Linee guida per gli implementatori)
Questa appendice non è normativa.
A.1. Minimum Recommended Message Size (Dimensione minima del messaggio raccomandata)
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)