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'inserimento di CloudWatch syslog gestito da Amazon Logs consente di inviare messaggi syslog (RFC 5424, RFC 3164 e Cisco FTD/ASA) da firewall, router, switch e server Linux direttamente in Logs, 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 incanalato AWS PrivateLink verso il servizio CloudWatch syslog Logs, 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. Puoi quindi interrogare questi campi utilizzando CloudWatch Logs Analytics per analizzare gli eventi di sicurezza o risolvere i problemi di connettività. Ciò consente di centralizzare la visibilità dei log dell'infrastruttura, semplificare i flussi di lavoro operativi e ridurre il sovraccarico derivante dall'implementazione e dalla gestione 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-location), possono raggiungere l'endpoint VPC tramite la tua VPN o la connessione Direct Connect.
Protocolli e porte supportati
| Protocollo | Porta | Note |
|---|---|---|
| TCP + TLS | 6514 | Crittografato in transito. Consigliato per i requisiti di conformità. |
| Testo in chiaro TCP | 1514 | Testo in chiaro terminato (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 certificato AWS gestito emesso da Amazon Trust Services. I tuoi client syslog si fidano automaticamente di questo certificato senza alcuna configurazione speciale.
Nota
UDP è il protocollo best-effort. 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 relativi al nome dell'applicazione e all'ID del processo.
RFC 3164 (BSD syslog, il formato precedente): include timestamp e un campo TAG. BSD-style Ancora ampiamente utilizzato da 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
%FTD-messaggio.%ASA-
I messaggi vengono archiviati nel gruppo di log nel formato raw originale. CloudWatch Logs estrae automaticamente i campi strutturati da ogni formato, che puoi interrogare utilizzando CloudWatch Logs Insights.
Campi estratti da 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 in 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 (FTD,ASA, 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 device-id la registrazione è configurata sull'appliance). |
severity | Nome del livello di gravità (ad esempio, informationalwarning,critical). |
severityLevel | Livello di gravità numerico (0—7). |
messageId | Identificatore numerico del messaggio Cisco (ad esempio,). 106023 302013 |
subsystem | Nome del sottosistema (presente per alcuni tipi di messaggi). |
message | Corpo del messaggio (testo normale) o singoli campi chiave-valore quando il corpo utilizza il formato strutturato di Cisco. |
Consegna dei messaggi
A differenza dell' HTTP-based inserimento in cui il server restituisce un codice di stato per ogni richiesta, syslog non fornisce una conferma di successo per messaggio al mittente. Una volta ricevuti dal servizio, i messaggi vengono memorizzati nel buffer e recapitati al gruppo di log con tentativi per individuare eventuali errori transitori. 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 corso su quella connessione potrebbero essere eliminati, ma il ripristino della connessione genera una contropressione immediata in modo che il cliente possa rilevare il problema e archiviare i messaggi in buffer a livello locale fino alla risoluzione della condizione. In condizioni di scarsa 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 politica 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 anche andare persi a causa della congestione della rete o dei limiti di capacità. Usa il protocollo TCP se la distribuzione 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 del messaggio (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 AWS l'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 AWS l'assistenza. |
| Throughput di ingestione | Condiviso con PutLogEvents |
L'inserimento di Syslog viene calcolato sulla PutLogEvents quota del tuo account (5.000 richieste al secondo per account per 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. https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html
