View a markdown version of this page

Ingestion de Syslog - Amazon CloudWatch Logs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Ingestion de Syslog

L'ingestion de syslog gérée par Amazon CloudWatch Logs vous permet d'envoyer des messages syslog (RFC 5424, RFC 3164 et Cisco FTD/ASA) à partir de pare-feux, de routeurs, de commutateurs et de serveurs Linux directement dans Logs, sans installer ni gérer aucun agent. CloudWatch Vos sources Syslog envoient des messages via TCP, TCP+TLS ou UDP à un point de terminaison VPC de votre compte. Le trafic est acheminé par tunnel AWS PrivateLink vers le service Syslog CloudWatch Logs, qui analyse automatiquement les messages entrants et extrait les champs structurés tels que l'installation, la gravité, le nom d'hôte et le nom de l'application, éliminant ainsi le besoin de pipelines d'analyse personnalisés. Vous pouvez ensuite interroger ces champs à l'aide de CloudWatch Logs Analytics pour étudier les événements de sécurité ou résoudre les problèmes de connectivité. Cela vous permet de centraliser la visibilité des journaux d'infrastructure, de simplifier les flux de travail opérationnels et de réduire les frais liés au déploiement et à la maintenance des agents de collecte de journaux dans les environnements distribués.

Si vos sources Syslog se trouvent déjà dans votre Amazon VPC, elles peuvent envoyer des messages directement au point de terminaison du VPC. Si vos sources se trouvent à l'extérieur AWS (centres de données sur site, succursales ou installations de colocation), elles peuvent accéder au point de terminaison VPC via votre connexion VPN ou Direct Connect.

Protocoles et ports pris en charge

Protocole Port Remarques
TCP + TLS 6514 Chiffré pendant le transport. Recommandé pour les exigences de conformité.
Texte brut TCP 1514 Texte brut sur AWS PrivateLink (isolé du réseau).
UDP 514 Best-effort livraison.

Le protocole TLS sur le port 6514 est résilié au niveau de l'équilibreur de charge réseau à l'aide d'un AWS certificat géré émis par Amazon Trust Services. Vos clients Syslog font automatiquement confiance à ce certificat sans aucune configuration particulière.

Note

L'UDP est un protocole basé sur le meilleur effort. Les messages peuvent être perdus en raison de l'état du réseau. Utilisez le protocole TCP pour une livraison fiable.

Formats syslog pris en charge

CloudWatch Logs détecte et analyse automatiquement les formats syslog suivants :

  • RFC 5424 (le nouveau format) : inclut des données structurées, des horodatages ISO 8601, ainsi que des champs explicites de nom d'application et d'identifiant de processus.

  • RFC 3164 (Syslog BSD, ancien format) — Inclut des BSD-style horodatages et un champ TAG. Encore largement utilisé par les périphériques réseau tels que les pare-feux, les routeurs et les commutateurs.

  • Cisco FTD/ASA — Format syslog utilisé par les appareils Cisco Firepower Threat Defense (FTD) et Adaptive Security Appliance (ASA). Les messages sont identifiés par la %ASA- balise %FTD- ou dans le corps du message.

Les messages sont stockés dans votre groupe de journaux dans leur format brut d'origine. CloudWatch Logs extrait automatiquement les champs structurés de chaque format, que vous pouvez interroger à l'aide de CloudWatch Logs Insights.

Champs extraits de la RFC 5424

Champ Description
facilityNom de la catégorie du journal (par exemplekern,auth,,local0).
facilityCodeCode numérique de l'établissement (0—23).
severityNom du niveau de gravité (par exempleemerg,,err,info).
severityCodeCode de gravité numérique (0—7).
timestampHorodatage du message au format ISO 8601.
hostnameNom d'hôte de l'appareil source.
appNameNom de l'application.
procIdID du processus.
msgIdIdentifiant du message.
structuredDataÉléments de données structurés RFC 5424 (métadonnées clé-valeur).
messageLe corps du message.

Champs extraits de la RFC 3164

Champ Description
facilityNom de la catégorie du journal.
facilityCodeCode numérique de l'établissement (0—23).
severityNom du niveau de gravité.
severityCodeCode de gravité numérique (0—7).
timestampHorodatage du message (converti du format BSD en ISO 8601).
hostnameNom d'hôte de l'appareil source.
appNameNom de l'application (extrait du champ TAG).
procIdID du processus (extrait du champ TAG, le cas échéant).
messageLe corps du message.

Champs FTD/ASA extraits par Cisco

Champ Description
deviceType d'appareil (FTDASA, ouFMC-AUDIT-LOG).
timestampHorodatage du message (format RFC 3164 ou RFC 5424, selon la configuration de l'appareil).
deviceIdNom d'hôte de l'appareil (présent lorsque la device-id journalisation est configurée sur l'appliance).
severityNom du niveau de gravité (par exempleinformational,,warning,critical).
severityLevelNiveau de gravité numérique (0—7).
messageIdIdentifiant de message numérique Cisco (par exemple,106023,302013).
subsystemNom du sous-système (présent pour certains types de messages).
messageCorps du message (texte brut) ou champs de valeur clés individuels lorsque le corps utilise le format structuré de Cisco.

Distribution des messages

Contrairement à HTTP-based l'ingestion où le serveur renvoie un code d'état pour chaque demande, Syslog ne fournit pas d'accusé de réception par message à l'expéditeur. Une fois les messages reçus par le service, ils sont mis en mémoire tampon et envoyés à votre groupe de journaux avec de nouvelles tentatives pour les erreurs transitoires. Les garanties de livraison dépendent du protocole de transport que vous choisissez :

  • TCP (ports 6514 et 1514) : fournit une livraison fiable dans des conditions de fonctionnement normales.

    Lorsque la livraison n'est pas possible, le service réinitialise la connexion TCP pour signaler l'échec à votre client. Les messages en cours sur cette connexion peuvent être abandonnés, mais la réinitialisation de la connexion entraîne une contre-pression immédiate afin que votre client puisse détecter le problème et mettre les messages en mémoire tampon localement jusqu'à ce que le problème soit résolu. Sous pression de capacité, le service rejette les nouvelles connexions TCP de manière anticipée, fournissant le même signal de contre-pression.

    Les conditions qui entraînent une réinitialisation de connexion sont les suivantes :

    • La politique de point de terminaison du VPC refuse l'accès

    • Le PutLogEvents quota de votre compte est dépassé

    • Le groupe de journaux cible n'existe pas

    • La politique de ressources du groupe de journaux refuse l'accès

  • UDP (port 514) — Best-effort livraison. Les messages qui ne peuvent pas être livrés sont supprimés sans qu'aucun commentaire ne soit envoyé à l'expéditeur. Les messages peuvent également être perdus en raison de la congestion du réseau ou de contraintes de capacité. Utilisez le protocole TCP si la fiabilité de la livraison est importante pour votre cas d'utilisation.

Pour détecter les problèmes de livraison et y répondre, surveillez la SyslogMessagesDropped métrique dans CloudWatch. La Reason dimension indique pourquoi les messages ont été supprimés afin que vous puissiez prendre des mesures correctives. Pour de plus amples informations, veuillez consulter Surveillance de l'ingestion de Syslog.

Quotas et limites

Limite Value Remarques
Taille maximale des messages (TCP) 64 Ko Les messages Syslog standard sont généralement bien en deçà de cette limite. Si votre cas d'utilisation nécessite des messages plus volumineux, contactez le AWS Support.
Taille maximale des messages (UDP) 8 Ko Les messages Syslog standard sont généralement bien en deçà de cette limite. Si votre cas d'utilisation nécessite des messages plus volumineux, contactez le AWS Support.
Débit d'ingestion Partagé avec PutLogEvents L'ingestion de Syslog est prise en compte dans le PutLogEvents quota de votre compte (5 000 demandes par seconde, par compte et par région par défaut).

Le quota PutLogEvents est réglable. Si votre trafic Syslog nécessite un débit plus élevé, demandez une augmentation de quota via Service Quotas.