Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Ingestione di Syslog
L'ingestione gestita di syslog da Amazon CloudWatch Logs ti consente di inviare messaggi syslog (RFC 5424, RFC 3164 e Cisco FTD/ASA) da firewall, router, switch e server Linux direttamente nei registri, senza installare o gestire alcun agente. CloudWatch Le tue fonti syslog inviano messaggi tramite TCP, TCP+TLS o UDP a un endpoint VPC nel tuo account. Il traffico viene convogliato tramite AWS PrivateLink il servizio CloudWatch Logs syslog, che analizza automaticamente i messaggi in arrivo ed estrae campi strutturati come struttura, gravità, nome host e nome dell'applicazione, eliminando la necessità di pipeline di analisi personalizzate. È quindi possibile interrogare questi campi utilizzando CloudWatch Logs Analytics per esaminare gli eventi di sicurezza o risolvere i problemi di connettività. Ciò consente di centralizzare la visibilità dei registri dell'infrastruttura, semplificare i flussi di lavoro operativi e ridurre il sovraccarico legato all'implementazione e alla manutenzione degli agenti di raccolta dei log in ambienti distribuiti.
Se le tue fonti syslog sono già all'interno del tuo Amazon VPC, possono inviare messaggi direttamente all'endpoint VPC. Se le tue fonti sono esterne AWS (data center locali, filiali o strutture di co-ubicazione), possono raggiungere l'endpoint VPC tramite la tua connessione VPN o Direct Connect.
Protocolli e porte supportati
| Protocollo | Porta | Note |
|---|---|---|
| TCP + TLS | 6514 | Crittografato in transito. Consigliato per i requisiti di conformità. |
| Testo semplice TCP | 1514 | Testo non crittografato (isolato dalla rete AWS PrivateLink ). |
| UDP | 514 | Best-effort consegna. |
Il protocollo TLS sulla porta 6514 viene terminato dal sistema di bilanciamento del carico di rete utilizzando un AWS certificato gestito emesso da Amazon Trust Services. I tuoi client syslog si fidano automaticamente di questo certificato senza alcuna configurazione speciale.
Nota
UDP è il protocollo migliore. I messaggi potrebbero andare persi a causa delle condizioni della rete. Usa TCP per una consegna affidabile.
Formati syslog supportati
CloudWatch Logs rileva e analizza automaticamente i seguenti formati syslog:
RFC 5424 (il formato più recente): include dati strutturati, timestamp ISO 8601 e campi espliciti per il nome dell'applicazione e l'ID del processo.
RFC 3164 (BSD syslog, il formato legacy): include timestamp e un campo TAG. BSD-style Ancora ampiamente utilizzato dai dispositivi di rete come firewall, router e switch.
Cisco FTD/ASA: il formato syslog utilizzato dai dispositivi Cisco Firepower Threat Defense (FTD) e Adaptive Security Appliance (ASA). I messaggi sono identificati dal tag o nel corpo del messaggio.
%FTD-%ASA-
I messaggi vengono archiviati nel gruppo di log nel loro formato raw originale. CloudWatch I log estraggono automaticamente i campi strutturati da ogni formato, che possono essere interrogati utilizzando CloudWatch Logs Insights.
Campi estratti RFC 5424
| Campo | Description |
|---|---|
facility | Nome della categoria di registro (ad esempio,kern,auth). local0 |
facilityCode | Codice numerico della struttura (0—23). |
severity | Nome del livello di gravità (ad esempio,emerg,err). info |
severityCode | Codice di gravità numerico (0—7). |
timestamp | Timestamp del messaggio in formato ISO 8601. |
hostname | Nome host del dispositivo di origine. |
appName | Nome applicazione. |
procId | ID processo. |
msgId | Identificatore del messaggio. |
structuredData | Elementi di dati strutturati RFC 5424 (metadati chiave-valore). |
message | Corpo del messaggio. |
Campi estratti RFC 3164
| Campo | Description |
|---|---|
facility | Nome della categoria di registro. |
facilityCode | Codice numerico della struttura (0—23). |
severity | Nome del livello di gravità. |
severityCode | Codice di gravità numerico (0—7). |
timestamp | Timestamp del messaggio (convertito dal formato BSD a ISO 8601). |
hostname | Nome host del dispositivo di origine. |
appName | Nome dell'applicazione (estratto dal campo TAG). |
procId | ID del processo (estratto dal campo TAG, se presente). |
message | Corpo del messaggio. |
Campi FTD/ASA estratti da Cisco
| Campo | Description |
|---|---|
device | Tipo di dispositivo (FTDASA, oFMC-AUDIT-LOG). |
timestamp | Timestamp del messaggio (formato RFC 3164 o RFC 5424, a seconda della configurazione del dispositivo). |
deviceId | Nome host del dispositivo (presente quando la device-id registrazione è configurata sull'appliance). |
severity | Nome del livello di gravità (ad esempio,informational,warning). critical |
severityLevel | Livello di severità numerico (0—7). |
messageId | Identificatore numerico del messaggio Cisco (ad esempio,). 106023 302013 |
subsystem | Nome del sottosistema (presente per determinati tipi di messaggi). |
message | Corpo del messaggio (testo semplice) o singoli campi chiave-valore quando il corpo utilizza il formato strutturato di Cisco. |
Consegna dei messaggi
A differenza dell' HTTP-based ingestione, in cui il server restituisce un codice di stato per ogni richiesta, syslog non fornisce al mittente un riconoscimento di successo per messaggio. Una volta ricevuti dal servizio, i messaggi vengono memorizzati nel buffer e recapitati al gruppo di log con nuovi tentativi per errori temporanei. Le garanzie di consegna dipendono dal protocollo di trasporto scelto:
-
TCP (porte 6514 e 1514): fornisce una consegna affidabile in condizioni operative normali.
Quando la consegna non è possibile, il servizio ripristina la connessione TCP per segnalare l'errore al client. I messaggi in transito su quella connessione possono essere interrotti, ma la reimpostazione della connessione fornisce una contropressione immediata in modo che il client possa rilevare il problema e memorizzare i messaggi nel buffer locale fino alla risoluzione della condizione. In caso di pressione della capacità, il servizio rifiuta tempestivamente le nuove connessioni TCP, fornendo lo stesso segnale di contropressione.
Le condizioni che causano il ripristino della connessione includono:
La policy degli endpoint VPC nega l'accesso
La quota del tuo account è stata superata
PutLogEventsIl gruppo di log di destinazione non esiste
La politica delle risorse sul gruppo di log nega l'accesso
UDP (porta 514): consegna. Best-effort I messaggi che non possono essere recapitati vengono eliminati senza alcun feedback al mittente. I messaggi possono inoltre andare persi a causa della congestione della rete o dei limiti di capacità. Usa TCP se la consegna affidabile è importante per il tuo caso d'uso.
Per rilevare e rispondere ai problemi di consegna, monitora la SyslogMessagesDropped metrica in. CloudWatch La Reason dimensione indica il motivo per cui i messaggi sono stati eliminati in modo da poter intraprendere azioni correttive. Per ulteriori informazioni, consulta Monitoraggio dell'ingestione di syslog.
Quote e limiti
| Limite | Valore | Note |
|---|---|---|
| Dimensione massima dei messaggi (TCP) | 64 KB | I messaggi syslog standard sono in genere ben al di sotto di questo limite. Se hai un caso d'uso che richiede messaggi più grandi, contatta l' AWS assistenza. |
| Dimensione massima dei messaggi (UDP) | 8 KB | I messaggi syslog standard sono in genere ben al di sotto di questo limite. Se hai un caso d'uso che richiede messaggi più grandi, contatta l' AWS assistenza. |
| Produttività di ingestione | Condiviso con PutLogEvents |
L'ingestione di Syslog viene conteggiata ai fini della PutLogEvents quota del tuo account (5.000 richieste al secondo per account e regione per impostazione predefinita). |
La quota PutLogEvents è modificabile. Se il traffico syslog richiede un throughput più elevato, richiedi un aumento della quota tramite Service Quotas.
