Plugin Syslog pour Log Shipper

Ce document explique comment configurer le Syslog v4.1.2 avec le module Log Shipper de la plateforme Netskope Cloud Exchange. Ce plugin prend en charge l’ingestion d’alertes (DLP (Prévention des pertes de données), malware, politique, identifiant compromis, malsite, quarantaine, remédiation, évaluation de sécurité, liste de surveillance, UBA, CTEP, périphérique, contenu), événements (page, application, audit, infrastructure, réseau, incident, point de terminaison, statut client), événements BWAN (authentification, audit, client, passerelle, système), WebTx et journaux (débogage, informations, erreur, avertissement). Les données seront ingérées dans la plateforme SIEM. Ce plugin prend en charge l’ingestion en formats CEF et JSON.

Conditions préalables

Pour compléter cette configuration, vous avez besoin de :

• Un locataire Netskope (ou plusieurs, par exemple des instances de production et de développement/test).
• Un locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Log Shipper déjà configurés.
• Un locataire Netskope Cloud Exchange avec le plugin BWAN déjà configuré.
• Le plugin AWS Log Streaming et le plugin Azure Log Streaming sont déjà configurés pour l'ingestion d'alertes, d'événements et de WebTx à partir du plugin Netskope Log Streaming.
• Une instance Splunk.
• Connectivité avec un serveur syslog.

Support du plugin Syslog

Le plugin Syslog est utilisé pour ingérer tous les journaux d'alerte, d'événements, WebTx et Syslog CE au format CEF et JSON vers le serveur syslog spécifié. Ce plugin prend également en charge l'ingestion d'alertes, d'événements et de WebTx à partir des plugins Netskope Log Streaming.

Type de données	Support
Événements	Oui (Page, Application, Audit, Infrastructure, Réseau, Incident, Point final, Statut du client)
Alertes	Oui (DLP (Prévention des pertes de données), Malware, Policy, Compromised Credential, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, périphérique, Content)
Journaux Syslog CE	Oui (Info, Erreur, Avertissement, Débogage)
Événements BWAN	Oui (authentification, audit, client, passerelle, système)
WebTx	Oui (via Netskope LogStreaming)

Matrice de performance

Cette analyse des performances a été réalisée sur une grande pile dans Cloud Exchange avec ces spécifications de VM. Ces données sont ajoutées en tenant compte du fait que le système ingérera environ 10 000 alertes/événements Netskope en 2 secondes dans le SIEM.

Description	Spécifications
Détails de la pile	Taille : Grande RAM : 32 GB CPU : 16 cœurs
Alertes/événements intégrés au SIEM	~200K EPM
WebTx (via Netskope LogStreaming) ingéré dans SIEM (non compressé)	~165 000 EPM

Workflow

Regardez une vidéo

Cliquez sur "play" pour regarder une vidéo :

Créer une entrée de données sur Splunk

Suivez les étapes de ce document pour installer Splunk.

1. Connectez-vous à l'instance Splunk.

   

2. Depuis le tableau de bord, accédez à Settings > Data inputs.

   

3. Cliquez sur Add new pour l'entrée TCP.

   

4. Ajoutez votre port et cliquez sur Next. Notez que le port sélectionné doit être exposé sur la machine hôte pour ingérer les entrées données à données.

   

5. Select le type de source si vous en avez déjà un, ou cliquez sur New pour créer un type de source New.
6. Saisissez le type de source. Select la catégorie de type de source en fonction de vos besoins, ou conservez-la telle quelle.

   

7. Faites défiler vers l’index vers le bas. Si vous avez déjà un index que vous souhaitez utiliser. Select depuis le menu déroulant de l’Index ; Sinon, cliquez Create a new index. Ajoutez un nom d’index, puis cliquez Save, puis cliquez sur Review.
8. Vérifiez tous les détails et cliquez sur Submit.

   

9. Cliquez sur Start Searching.

Configurer le plugin Syslog pour l'intégration Splunk

1. Dans Cloud Exchange, allez sur Settings > Plugin Store. Recherchez et sélectionnez le plugin Syslog v4.1.2 (CLS).

   

2. Saisissez un nom de configuration de plugin et assurez-vous d’avoir sélectionné le fichier de correspondance par défaut Syslog si vous souhaitez utiliser le format CEF.

   

   Pour ingérer des données au format JSON, sélectionnez le format JSON sous Informations de base.

3. Cliquez sur Next et entrez les paramètres de configuration :

   • Syslog server: Adresse IP/FQDN du serveur Syslog où les données seront ingérées.
   • Syslog ProtocolProtocole à utiliser lors de l'ingestion des données.
   • Syslog Port: Le port utilisé lors de la création de la configuration d’entrée de données sur Splunk.
   • Syslog Certificate: Le certificat est uniquement requis pour le protocole TLS.
   • Log source Identifier: L’identifiant ajouté comme préfixe à tous les journaux.
   • Exclude Timestamp Field: Select Yes pour ingérer les données sans le champ de l'horodatage. Cette option ne s'applique qu'aux données au format JSON.
   • Exclude Log Source Identifier Field: Select Yes d’ingérer les données sans le champ Identifiant de source de journal. Cette option ne s’applique qu’aux données formatées JSON.
   • Exclude Priority Field: Select Yes d’ingérer les données sans le champ de priorité dans le message syslog. Cette option ne s’applique qu’aux données formatées JSON.

   

   

   Si le champ Exclure Priorité est maintenu comme Non, alors la priorité par défaut sera 14 (Info) pour toutes les données.

4. Cliquez sur Save. La configuration du plugin sera disponible sur la page Log Shipper > Plugins.

   

Configurer une règle de gestion de l'expéditeur de logs pour l'intégration Splunk

1. Accédez à la page Règle de gestion. 

2. Par défaut, une règle de gestion filtre toutes les alertes et tous les événements. Si vous souhaitez filtrer un type spécifique d'alerte ou d'événement, cliquez sur Create New Rule et configurez une règle de gestion New en ajoutant le nom de la règle et le filtre.

   

3. Cliquez sur Save.

   

Configurer l'envoi de logs par Log Shipper pour l'intégration Splunk

1. Dans Log Shipper, allez à Log Delivery et cliquez sur Add Log Delivery Configuration. 
2. Select le plugin Source (CLS Netskope ou tout autre plugin source), le plugin Destination (CLS Syslog), votre règle métier, et cliquez Save.
3. Pour WebTx, sélectionnez le plugin Source (CLS Netskope WebTx) et le plugin Destination (CLS Syslog).
4. Pour le partage des journaux, sélectionnez le plugin Source (CLS Cloud Exchange Logs) et le plugin Destination (CLS Syslog).
5. Après l'ajout de Log Delivery, les données commenceront à être extraites du locataire Netskope ou de la plateforme source, puis transformées et ingérées dans la plateforme Syslog.

Valider le Syslog avec Splunk Plugin

Valider le retrait

Pour valider l'extraction d'événements, d'alertes, de journaux, d'événements BWAN et de Webtx à partir du locataire Netskope.

Allez sur le site Logging dans Cloud Exchange et recherchez les journaux tirés.

Valider le push

Pour valider le plugin workflow dans Cloud Exchange, allez sur Logging et recherchez les événements ingérés, les alertes, les journaux WebTx & avec le filtre "message contains ingested". Les journaux ingérés seront filtrés.

Pour valider le push sur le Splunk :

Connectez-vous à Splunk Platform.

Cliquez sur Search & Reporting.

Saisissez la source et le protocole, ainsi que le port et l'identifiant de la source de journalisation (exemple : source="tcp:5001" index="syslogdemo" sourcetype="dev" netskopece).

Voici des exemples d'alertes ingérées :

Voici des exemples d'événements ingérés :

Voici à quoi ressemblent les événements BWAN du plugin à Splunk :

Voici à quoi ressemblent les logs Syslog for CE depuis le plugin vers Splunk :

Voici à quoi ressemblent les données WebTx entre le plugin et Splunk :

Voici à quoi ressemblent les données lorsqu'elles sont partagées en JSON entre le plugin et Splunk (format non analysé) :

Voici à quoi ressembleront les données si elles sont ingérées au format JSON sans les champs d'horodatage et d'identification de la source du journal :

Voici à quoi ressembleront les données si elles sont ingérées en format JSON sans champ de priorité :

Échantillonnage de données ingérées au format JSON avec une correspondance personnalisée ne contenant que des champs sélectionnés :

Dépannage du plugin Syslog

Une erreur s'est produite lors de la configuration du plugin Syslog.

Bien que vous ayez saisi tous les paramètres et cliqué sur Save, une erreur peut se produire pour l'une des raisons suivantes :

• La configuration du serveur/port peut différer des paramètres spécifiés (Netskope CE/Splunk).
• Le port n'est pas exposé sur le serveur Splunk.

What to do:

1. In the Splunk Platform, go to Settings and click Data inputs > TCP (whichever configuration you have used). Check that both are the same.

   

2. Exposez le port sur le serveur Splunk.

Les champs imbriqués ne sont pas mappés correctement lors de l'ingestion de données via le plugin Syslog

Sur les anciennes versions du plugin Syslog, vous ne pourrez pas mapper les champs imbriqués. Ce problème est résolu dans la dernière version du plugin Syslog.

What to do: Mettez à jour le plugin Syslog vers Syslog v4.0.1 ou supérieur.

Une erreur s'est produite lors de l'ingestion des données de Cloud Exchange vers Syslog.

Si vous ne parvenez pas à envoyer des alertes/événements/logs/webtx données sur la plateforme Syslog, cela peut être dû à l'une des raisons suivantes :

• Le port est supprimé/désactivé sur la plate-forme Syslog.
• La mémoire du serveur Splunk est pleine.

What to do:

1. Assurez-vous que le port est présent et activé. Si ce n'est pas le cas, créez un port New.
2. Veillez à nettoyer les données d'événements si elles ne sont pas nécessaires, ou augmentez la capacité de stockage du serveur Splunk.

Si les données ingérées ne sont pas reflétées sur la plate-forme Syslog

Si vous n'arrivez pas à visualiser les alertes/événements/logs/webtx données sur la plateforme Syslog, cela peut être dû à l'une des raisons suivantes :

• Le filtre n'est pas correct sur la plateforme Splunk.
• Il peut y avoir une erreur, mais UDP est sélectionné dans le Port lors de la configuration du plugin syslog, donc les logs ingérés ne sont pas visibles.

What to do:

1. Assurez-vous que les données sont recherchées à l'aide du bon filtre.
2. Veillez à sélectionner le port TCP pour vérifier s'il y a un problème.

Les données Webtx ont été sautées en raison de l’ordre du syntaxique Configuré du flux de journal ou du champ x-cs-timestamp désactivé

Si les données Webtx ne sont pas ingérées à destination, cela peut être dû à un mauvais mappage utilisé lors de la configuration du plugin Syslog ou à la désactivation du champ x-cs-timestamp. Les correspondances par défaut pour Syslog v4.1.2 sont compatibles avec l’ordre 2 de l’analyseur.

What to do:

Mettez à jour l’ordre de l’analyseur de votre Log Streaming sur le tenant Netskope à l’ordre 2 de l’analyseur, ou utilisez la correspondance personnalisée. Pour mettre à jour l’ordre de l’analyseur :

1. Modifiez le flux WebTx puis, sous Événements de transaction, cliquez Manage Fields, et changez l’ordre de l’analyseur en ordre 2.

   

2. Assurez-vous également que le champ horodatage x-cs est activé

   

Événement réseau ignoré en raison d'un type inattendu pour le champ ID de session réseau

Si vous ne pouvez pas obtenir de valeur pour le champ ID de session réseau, cela peut être dû à l’utilisation d’un ancien plugin syslog où le champ ID de session réseau est de type numéro.

What to do:

1. Mettez à jour avec le dernier plugin syslog ou mettez à jour le champ de l'identifiant de la session réseau pour qu'il soit de type chaîne de caractères afin de gérer les données non numériques.
2. Pour mettre à jour le mappage, allez sur Settings > Log Shipper et clonez les Syslog Default Mappings. Ajoutez un nom pour le mappage cloné.
3. Cliquez sur Events > Network > Extension > networkSessionId > Select Type “String” puis sur Save. 
4. Utilisez le fichier de correspondance mis à jour dans la configuration du plugin.

Comportement connu

• Vous pouvez rencontrer des caractères d’échappement dans les données ingérées en raison de plusieurs facteurs, tels que les caractères accentués (en anglais), les caractères de langues autres que l’anglais, les espaces non cassés, les caractères de nouvelle ligne et d’autres symboles de mise en forme spéciaux.
  
  Ici, il y a des caractères japonais qui ont été ingérés, qui ressemblaient à \\u4ed5\\u4e8b dans le journal ci-dessous.
  Exemple :

  <14>Apr 07 09:32:56 alltypes CEF:0|Netskope|Mock Netskope Tenant|NULL|application|NULL|Unknown|act=Download appcategory=Cloud Storage applicationType=nspolicy browser=unknown \\u4ed5\\u4e8b cci=89 ccl=high device=Other dst=ef82::1a12:1234:1b12 os=unknown requestClientApplication=Box sourceServiceName=Box src=ef82::1a12:1234:1b12 suser=support@netskope.com timestamp=1743736484

• Le contenu ingéré peut présenter des champs/données manquants si vous avez défini le champ Pull DLP (Prévention des pertes de données) Incident Forensics sur Yes, ou si le contenu de l'un des champs est très volumineux.
  Nous avons observé que certains champs sont très grands et que leur longueur dépasse la longueur maximale supportée par le Netskope Cloud Exchange. Pour cette raison, vous pouvez rencontrer l'avertissement ci-dessous et vous pouvez observer que l'événement ingéré est incomplet car le reste des valeurs sera ignoré.

  

• Nous avons testé le plugin en utilisant une instance Splunk pour l'ingestion de données et avons observé le comportement suivant :
  Lorsque le champ Exclude timestamp est défini sur Yes, les données sont ingérées en utilisant l'horodatage local actuel.
  Lorsque le champ Exclure l'horodatage est défini sur Non, les données sont intégrées en utilisant l'horodatage UTC actuel.