Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Syslog-Aufnahme
Mit der von Amazon CloudWatch Logs verwalteten Syslog-Ingestion können Sie Syslog-Meldungen (RFC 5424, RFC 3164 und Cisco FTD/ASA) von Firewalls, Routern, Switches und Linux-Servern direkt in Logs senden — ohne Agenten installieren oder verwalten zu müssen. CloudWatch Ihre Syslog-Quellen senden Nachrichten über TCP, TCP+TLS oder UDP an einen VPC-Endpunkt in Ihrem Konto. Der Datenverkehr wird AWS PrivateLink an den CloudWatch Logs-Syslog-Dienst weitergeleitet, der eingehende Nachrichten automatisch analysiert und strukturierte Felder wie Einrichtung, Schweregrad, Hostname und Anwendungsname extrahiert, sodass keine benutzerdefinierten Parsing-Pipelines erforderlich sind. Anschließend können Sie diese Felder mithilfe von CloudWatch Logs Analytics abfragen, um Sicherheitsereignisse zu untersuchen oder Verbindungsprobleme zu beheben. Dies hilft Ihnen, die Sichtbarkeit der Infrastrukturprotokolle zu zentralisieren, betriebliche Arbeitsabläufe zu vereinfachen und den Aufwand für die Bereitstellung und Wartung von Protokollerfassungsagenten in verteilten Umgebungen zu reduzieren.
Wenn sich Ihre Syslog-Quellen bereits in Ihrer Amazon VPC befinden, können sie Nachrichten direkt an den VPC-Endpunkt senden. Wenn sich Ihre Quellen außerhalb befinden AWS (lokale Rechenzentren, Zweigstellen oder Colocation-Einrichtungen), können sie den VPC-Endpunkt über Ihre VPN- oder Direct Connect-Verbindung erreichen.
Unterstützte Protokolle und Ports
| Protocol (Protokoll) | Port | Hinweise |
|---|---|---|
| TCP + TLS | 6514 | Bei der Übertragung verschlüsselt. Für Compliance-Anforderungen empfohlen. |
| TCP-Klartext | 1514 | Klartext über AWS PrivateLink (netzwerkisoliert). |
| UDP | 514 | Best-effort Lieferung. |
TLS auf Port 6514 wird am Network Load Balancer mithilfe eines von Amazon Trust Services ausgestellten AWS-verwalteten Zertifikats beendet. Ihre Syslog-Clients vertrauen diesem Zertifikat automatisch ohne spezielle Konfiguration.
Anmerkung
UDP ist ein Best-Effort-Protokoll. Nachrichten können aufgrund von Netzwerkbedingungen verloren gehen. Verwenden Sie TCP für eine zuverlässige Zustellung.
Unterstützte Syslog-Formate
CloudWatch Logs erkennt und analysiert automatisch die folgenden Syslog-Formate:
RFC 5424 (das neuere Format) — Enthält strukturierte Daten, ISO 8601-Zeitstempel und explizite Felder für Anwendungsnamen und Prozess-ID.
RFC 3164 (BSD-Syslog, das alte Format) — Beinhaltet Zeitstempel und ein TAG-Feld. BSD-style Wird immer noch häufig von Netzwerkgeräten wie Firewalls, Routern und Switches verwendet.
Cisco FTD/ASA — Das Syslog-Format, das von Geräten der Cisco Firepower Threat Defense (FTD) und Adaptive Security Appliance (ASA) verwendet wird. Nachrichten werden durch das
%FTD-oder%ASA--Tag im Nachrichtentext identifiziert.
Nachrichten werden in Ihrer Protokollgruppe in ihrem ursprünglichen Rohformat gespeichert. CloudWatch Logs extrahiert automatisch strukturierte Felder aus jedem Format, die Sie mit CloudWatch Logs Insights abfragen können.
Extrahierte Felder nach RFC 5424
| Feld | Description |
|---|---|
facility | Name der Protokollkategorie (z. B., kernauth,local0). |
facilityCode | Numerischer Einrichtungscode (0—23). |
severity | Name des Schweregrads (z. B., emergerr,info). |
severityCode | Numerischer Schweregradcode (0—7). |
timestamp | Zeitstempel der Nachricht im ISO 8601-Format. |
hostname | Hostname des Quellgeräts. |
appName | Anwendungsname |
procId | Prozess-ID. |
msgId | Nachrichten-ID. |
structuredData | Strukturierte Datenelemente nach RFC 5424 (Schlüsselwert-Metadaten). |
message | Nachrichtentext. |
Extrahierte Felder nach RFC 3164
| Feld | Description |
|---|---|
facility | Name der Protokollkategorie. |
facilityCode | Numerischer Einrichtungscode (0—23). |
severity | Name des Schweregrads. |
severityCode | Numerischer Schweregradcode (0—7). |
timestamp | Zeitstempel der Nachricht (vom BSD-Format in das ISO 8601 konvertiert). |
hostname | Hostname des Quellgeräts. |
appName | Anwendungsname (aus dem TAG-Feld extrahiert). |
procId | Prozess-ID (aus dem TAG-Feld extrahiert, falls vorhanden). |
message | Nachrichtentext. |
Von Cisco FTD/ASA extrahierte Felder
| Feld | Description |
|---|---|
device | Gerätetyp (FTDASA, oderFMC-AUDIT-LOG). |
timestamp | Zeitstempel der Nachricht (RFC 3164- oder RFC 5424-Format, je nach Gerätekonfiguration). |
deviceId | Geräte-Hostname (vorhanden, wenn die device-id Protokollierung auf der Appliance konfiguriert ist). |
severity | Name des Schweregrads (z. B.informational,warning,critical). |
severityLevel | Numerischer Schweregrad (0—7). |
messageId | Numerische Cisco-Nachrichten-ID (z. B.106023,302013). |
subsystem | Name des Subsystems (für bestimmte Nachrichtentypen vorhanden). |
message | Nachrichtentext (Klartext) oder einzelne Schlüsselwertfelder, wenn der Nachrichtentext das strukturierte Format von Cisco verwendet. |
Nachrichtenzustellung
Im Gegensatz HTTP-based zur Erfassung, bei der der Server für jede Anfrage einen Statuscode zurückgibt, sendet Syslog keine Erfolgsbestätigung pro Nachricht an den Absender zurück. Sobald Nachrichten vom Dienst empfangen wurden, werden sie gepuffert und an Ihre Protokollgruppe übermittelt, wobei vorübergehende Fehler wiederholt werden. Die Liefergarantien hängen vom ausgewählten Transportprotokoll ab:
-
TCP (Ports 6514 und 1514) — Sorgt für eine zuverlässige Lieferung unter normalen Betriebsbedingungen.
Wenn die Übertragung nicht möglich ist, setzt der Dienst die TCP-Verbindung zurück, um Ihrem Client den Ausfall zu signalisieren. Nachrichten, die über diese Verbindung gesendet werden, können gelöscht werden, aber das Zurücksetzen der Verbindung sorgt für einen sofortigen Gegendruck, sodass Ihr Client das Problem erkennen und Nachrichten lokal zwischenspeichern kann, bis der Zustand behoben ist. Bei Kapazitätsdruck lehnt der Dienst neue TCP-Verbindungen frühzeitig ab und liefert das gleiche Gegendrucksignal.
Zu den Bedingungen, die zum Zurücksetzen der Verbindung führen, gehören:
Die VPC-Endpunktrichtlinie verweigert den Zugriff
Das
PutLogEventsKontingent Ihres Kontos wurde überschrittenDie Ziel-Loggruppe ist nicht vorhanden
Die Ressourcenrichtlinie für die Protokollgruppe verweigert den Zugriff
UDP (Port 514) — Best-effort Lieferung. Nachrichten, die nicht zugestellt werden können, werden ohne Rückmeldung an den Absender verworfen. Nachrichten können auch aufgrund von Netzwerküberlastung oder Kapazitätsengpässen verloren gehen. Verwenden Sie TCP, wenn eine zuverlässige Übertragung für Ihren Anwendungsfall wichtig ist.
Überwachen Sie die SyslogMessagesDropped Metrik in, um Lieferprobleme zu erkennen und darauf zu reagieren CloudWatch. Die Reason Dimension gibt an, warum Nachrichten gelöscht wurden, sodass Sie Abhilfemaßnahmen ergreifen können. Weitere Informationen finden Sie unter Überwachung der Syslog-Aufnahme.
Kontingente und -Einschränkungen
| Limit | Wert | Hinweise |
|---|---|---|
| Maximale Nachrichtengröße (TCP) | 64 KB | Standard-Syslog-Meldungen liegen in der Regel deutlich unter diesem Limit. Wenn Sie einen Anwendungsfall haben, der größere Meldungen erfordert, wenden Sie sich an AWS den Support. |
| Maximale Nachrichtengröße (UDP) | 8 KB | Standard-Syslog-Meldungen liegen in der Regel deutlich unter diesem Limit. Wenn Sie einen Anwendungsfall haben, der größere Meldungen erfordert, wenden Sie sich an AWS den Support. |
| Durchsatz bei der Aufnahme | Geteilt mit PutLogEvents |
Syslog-Daten werden auf das PutLogEvents Kontingent Ihres Kontos angerechnet (standardmäßig 5.000 Anfragen pro Sekunde pro Konto und Region). |
Das PutLogEvents-Kontingent kann angepasst werden. Wenn Ihr Syslog-Verkehr einen höheren Durchsatz erfordert, fordern Sie über Service Contingents eine Erhöhung des Kontingents an. https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html
