Le format CEF (Common Event Format) fournit un format d'événement standard afin de faciliter la fusion et l'analyse des informations d'audit à partir de plusieurs composants au niveau du système distribué. Le format CEF utilise le format de message Syslog comme mécanisme de transport.
CEF est un format texte extensible conçu pour prendre en charge plusieurs types de périphériques, tels que les périphériques sur site et les services basés sur le cloud. Les événements CEF facilitent la compréhension des suivis d'audit d'applications hétérogènes.
La configuration d'OpenText eDirectory pour utiliser CEF offre les avantages suivants :
fournit des services d'audit uniformes et sécurisés pour un système distribué ;
CEF utilise un format de message standard qui simplifie la gestion des logs.
Le nouveau format d'événement s'intègre à Sentinel de manière transparente.
La section suivante explique comment configurer CEF avec OpenText eDirectory :
Le paquetage de téléchargement du kit d'installation d'OpenText eDirectory inclut un client CEF pour Linux et un autre pour Windows. Le programme d'installation d'OpenText eDirectory installe les paquetages CEF sur votre système d'exploitation. Le paquetage CEF contient les fichiers suivants :
Linux
novell-edirectory-xdaslog
novell-edirectory-xdaslog-conf
novell-edirectory-cefinstrument-9.2.0-0.x86_64.rpm
Windows
cefauditds.dlm
xdaslog.dll
Cette section contient les informations suivantes :
L'installation et l'utilisation de l'application Audit Identity Console nécessitent Identity Console 1.5 au minimum. Pour connaître les conditions requises et obtenir des instructions de téléchargement, voir Planification de l'installation d'OpenText Identity Console.
Pour installer l'application OpenText Identity Console, procédez comme suit :
Ouvrez OpenText Identity Console à partir d'un navigateur Web, à l'aide de l'URL suivante :
https://ip_address_or_DNS:Port/identityconsole/
où ip_address_or_DNS correspond à l'adresse IP ou au nom DNS, ainsi qu'au numéro de port de votre serveur OpenText Identity Console.
Par exemple :
http://111.111.1.1:9000/identityconsole.html
Connectez-vous à OpenText Identity Console à l'aide du nom et du mot de passe d'un utilisateur de l'arborescence.
Si vous souhaitez accéder à toutes les fonctions d'OpenText Identity Console, vous devez vous connecter à l'arborescence en tant qu'administrateur. Seul un administrateur dispose d'un accès complet à toutes les fonctionnalités. S'il n'est pas administrateur, l'utilisateur peut uniquement accéder aux rôles pour lesquels des droits lui sont assignés.
Pour plus d'informations, consultez le Guide d'administration d'OpenText Identity Console.
Un exemple de fichier de propriétés (auditlogconfig.properties.template) est inclus dans le répertoire configdir (n4u.server.configdir) sur le support d'OpenText eDirectory.
Le tableau suivant indique l'emplacement par défaut du fichier auditlogconfig.properties sur les systèmes d'exploitation Linux et Windows.
Tableau 23-1 Fichier de configuration CEF
|
Système d'exploitation |
Emplacement du fichier de propriétés |
|---|---|
|
Linux |
/etc/opt/novell/eDirectory/conf/ auditlogconfig.properties Pour les installations non-root, le fichier de propriétés CEF se trouve dans le répertoire conf. |
|
Windows |
<Install Path>/novell/nds/auditlogconfig.properties Le fichier de propriétés se trouve généralement dans le répertoire d'installation d'OpenText eDirectory. |
Si vous configurez le fichier de propriétés, puis mettez à niveau votre environnement OpenText eDirectory 9.2 vers une version plus récente, le programme d'installation ne remplace pas le fichier de propriétés. Le cas échéant, le processus de mise à niveau met à jour le fichier (auditlogconfig.properties) de manière à conserver la personnalisation.
Vous pouvez configurer CEF après l'installation d'Identity Console. Les paramètres de configuration de CEF sont stockés dans un simple fichier de configuration au format texte (auditlogconfig.properties). Vous pouvez personnaliser le fichier en fonction de vos besoins.
Le fichier de propriétés CEF (auditlogconfig.properties) contient les informations suivantes :
# Set the level of the root logger to DEBUG and attach appenders. #log4j.rootLogger=info, S, R
# Defines appender S to be a SyslogAppender. #log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server. #log4j.appender.S.Host=localhost #log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL) #log4j.appender.S.Protocol=TCP
# Specify SSL certificate file for SSL connection. # File path should be given with double backslash. #log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
# Minimum log-level allowed in syslog. #log4j.appender.S.Threshold=INFO
# Defines the type of facility. #log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender. # Inputs should be yes/no #log4j.appender.S.CacheEnabled=no
# Cache location directory # Directory should be available for creating cache files #log4j.appender.S.CacheDir=/var/opt/novell/eDirectory
# Cache File Size # Cache File size should be in the range of 50MB to 4000MB in limited growth mode # Cache File size should be set as 0MB to enable infinite growth of cache file #log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S. #log4j.appender.S.layout=org.apache.log4j.PatternLayout #log4j.appender.S.layout.ConversionPattern=%c: %m%n
# Defines appender R to be a Rolling File Appender. #log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R. #log4j.appender.R.File=/var/opt/novell/eDirectory/log/cef-events.log
# Max size of log file for appender R. #log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R. # Max can be 13. If set to zero, then there will be no backup files. #log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c %m%n
# Brief description for appenders and their options are provided.
# For detailed decriptions refer to log4cxx documentation.
# Set the level of the root logger to DEBUG and attach appenders.
#log4j.rootLogger=info, S, R
# Defines appender S to be a SyslogAppender.
#log4j.appender.S=org.apache.log4j.net.SyslogAppender
# Defines location of Syslog server.
#log4j.appender.S.Host=localhost
#log4j.appender.S.Port=port
# Specify protocol to be used (UDP/TCP/SSL).
#log4j.appender.S.Protocol=SSL
# Specify SSL certificate file for SSL connection.
# File path should be given with double backslash.
#log4j.appender.S.SSLCertFile=C:\\Novell\\mycert.pem
# Minimum log-level allowed in syslog.
#log4j.appender.S.Threshold=INFO
# Defines the type of facility.
#log4j.appender.S.Facility=USER
# Defines caching for SyslogAppender.
# Inputs should be yes/no
#log4j.appender.S.CacheEnabled=yes
# Cache location directory
# Directory should be available for creating cache files
#log4j.appender.S.CacheDir=C:\\NetIQ\\eDirectory
# Cache File Size
# Cache File size should be in the range of 50MB to 4000MB in limited growth mode
# Cache File size should be set as 0MB to enable infinite growth of cache file
#log4j.appender.S.CacheMaxFileSize=500MB
# Layout definition for appender Syslog S.
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c: %m%n
# Defines appender R to be a Rolling File Appender.
#log4j.appender.R=org.apache.log4j.RollingFileAppender
# Log file for appender R.
# File path should be given with double backslash.
#log4j.appender.R.File=C:\\cef-events.log
# Max size of log file for appender R.
#log4j.appender.R.MaxFileSize=100MB
# Set the maximum number of backup files to keep for appender R.
# Max can be 13. If set to zero, then there will be no backup files.
#log4j.appender.R.MaxBackupIndex=10
# Layout definition for appender Rolling log file R.
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c %m%n
Avant d'examiner le contenu du fichier auditlogconfig.properties, OpenText recommande de passer en revue les considérations suivantes :
Les lettres S et R correspondent respectivement à l'appender Syslog et à l'appender RollingFile.
Les entrées ne respectent pas la casse.
Les entrées peuvent apparaître dans n'importe quel ordre.
Les lignes vides dans le fichier sont valides.
Toute ligne commençant par un signe dièse (#) est commentée.
Le tableau ci-dessous fournit des informations à propos des paramètres du fichier auditlogconfig.properties :
IMPORTANT :vous devez redémarrer OpenText eDirectory après avoir modifié la configuration.
|
Paramètre |
Description |
|---|---|
|
log4j.rootLogger=info, S, R |
Définit le niveau de l'enregistreur racine sur Info et y associe un appender nommé S ou R, R correspondant à Rolling File et S à Syslog. Les niveaux disponibles pour l'enregistreur racine (dans le même ordre de priorité) sont : trace, debug, info, warn, error et fatal. Par défaut, info est spécifié et inclut les événements de tous les autres niveaux à l'exception de trace et de debug. Si vous souhaitez envoyer tous les événements au journal, indiquez TRACE ou ALL dans ce champ. |
|
log4j.appender.S=org.apache.log4j.net.SyslogAppender |
Indique que l'appender S doit être un appender Syslog. |
|
log4j.appender.S.Host=localhost |
Indique à quel emplacement du serveur Syslog les événements CEF sont consignés. Par exemple : log4j.appender.S.Host=192.168.0.1 |
|
log4j.appender.S.Port=port |
Port sur lequel CEF se connecte au serveur Syslog. Le numéro de port peut être compris entre 1 et 65535. Si vous spécifiez une valeur non valide, le numéro de port est défini par défaut sur 514. En cas d'échec de la connexion entre CEF et le serveur Syslog, Identity Manager ne peut pas consigner les événements tant que la connexion n'a pas été restaurée. |
|
log4j.appender.S.Protocol=TCP |
Indique le protocole à utiliser. Par exemple : UDP, TCP ou SSL. |
|
log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem |
Spécifie le fichier de certificat SSL pour la connexion SSL. Utilisez deux barres obliques inverses pour spécifier le chemin d'accès au fichier. Ce paramètre est facultatif. |
|
log4j.appender.S.Threshold=INFO |
Spécifie le niveau de consignation minimal autorisé dans Syslog. Les niveaux de consignation suivants sont pris en charge (dans le même ordre de priorité) : TRACE, DEBUG, INFO, WARN et ERROR. Le niveau de consignation par défaut minimum est INFO qui inclut tous les autres niveaux de consignation, à l'exception de TRACE et DEBUG. Autrement dit, si vous spécifiez INFO comme niveau de consignation minimal, les événements TRACE et DEBUG ne sont pas envoyés au serveur Syslog. Si vous souhaitez envoyer tous les événements au serveur Syslog, indiquez TRACE ou ALL dans ce champ. |
|
log4j.appender.S.Facility=USER |
Indique le type d'installation. L'installation est utilisée pour tenter de classer le message. Actuellement, l'installation USER est prise en charge. Ces valeurs peuvent être spécifiées en majuscules ou en minuscules. |
|
log4j.appender.S.layout=org.apache.log4j.PatternLayout |
Paramètre d'agencement de l'appender Syslog. |
|
log4j.appender.S.layout.ConversionPattern=%c : %p%m%n |
Paramètre d'agencement de l'appender Syslog. Pour plus d'informations sur les schémas de conversion et leur description, consultez le site logging.apache.org. |
|
log4j.appender.R=org.apache.log4j.RollingFileAppender |
Indique que l'appender R doit être un appender RollingFile. |
|
log4j.appender.R.File=/var/opt/novell/eDirectory/log/cef-events.log |
Emplacement du fichier journal pour l'appender RollingFile. |
|
log4j.appender.R.MaxFileSize=100MB |
Taille maximale, en Mo, du fichier journal pour l'appender RollingFile. Définissez cette valeur sur la taille maximale autorisée par le client. |
|
log4j.appender.R.MaxBackupIndex=10 |
Spécifiez le nombre maximal de fichiers de sauvegarde pour l'appender RollingFile. Le nombre maximal de fichiers de sauvegarde peut être 10. Une valeur 0 signifie qu'aucun fichier de sauvegarde n'est présent. |
|
log4j.appender.R.layout=org.apache.log4j.PatternLayout |
Paramètre d'agencement de l'appender RollingFile. |
|
log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n |
Paramètre d'agencement de l'appender RollingFile. Pour plus d'informations sur les schémas de conversion et leur description, consultez le site logging.apache.org. |
Le tableau suivant donne des exemples de modèles de date et d'heure interprétés aux États-Unis. Les date et heure en question sont le 04/07/2012, 12 h 08 min 56 s, heure du Pacifique aux États-Unis.
Tableau 23-2 Exemples de modèles de date et d'heure
|
Modèle de date et d'heure |
Résultat |
|---|---|
|
"aaaa.MM.jj G 'à' HH:mm:ss z" |
2012.07.04 AD at 12:08:56 PDT (04.07.2012 ap. J-C à 12:08:56 HAP) |
|
"EEE, MMM j, ''aa" |
Wed, Jul 4, '01 (Mer, 4 juil. 2001) |
|
"h:mm a" |
12:08 PM (12:08) |
|
"hh 'heures' a, zzzz" |
12 o'clock PM, Pacific Daylight Time (12 heures, heure avancée du Pacifique) |
|
"K:mm a, z" |
12:08 PM, PDT (12:08, HAP) |
|
"aaaaa.MMMMM.jj GGG hh:mm aaa" |
02012.July.24 AD 12:08 PM (02012.Juillet.24 ap. J-C 12:08) |
|
"EEE, j MMM aaaa HH:mm:ss Z" |
Wed, 24 Jul 2012 12:08:56 -0700 (Mer, 24 juil. 2012 12:08:56 -0700) |
|
"aaMMjjHHmmssZ" |
120724120856-0700 |
|
"aaaa-MM-jj'T'HH:mm:ss.SSSZ" |
2012-07-04T12:08:56.235-0700 (2012-07-04T12:08:56.235-0700) |
Vous pouvez utiliser l'appender Syslog pour afficher les événements en temps réel. Par ailleurs, un serveur Syslog offre une meilleure prise en charge des sauvegardes en cas de sinistre.
Pour activer l'appender Syslog, apportez les modifications suivantes au fichier auditlogconfig.properties :
Remplacez la valeur de l'entrée ci-dessous par S pour joindre un appender Syslog :
log4j.rootLogger=info, S
Supprimez les marques de commentaire des entrées suivantes :
log4j.appender.S=org.apache.log4j.net.SyslogAppender
log4j.appender.S.Host=localhost
log4j.appender.S.Port=port
log4j.appender.S.Protocol=SSL
log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem
#log4j.appender.S.Threshold=INFO
#log4j.appender.S.Facility=USER
#log4j.appender.S.layout=org.apache.log4j.PatternLayout
#log4j.appender.S.layout.ConversionPattern=%c: %m%n
Connectez-vous à OpenText Identity Console et modifiez les événements de consignation. Pour plus d'informations sur la configuration des événements CEF, reportez-vous à la section Configuration des événements CEF pour l'audit.
REMARQUE :le caching CEF qui utilise le protocole UDP pour SyslogAppender ne fonctionne pas.
Pour générer un certificat pour la connexion Syslog :
Créez le certificat à l'aide de la commande OpenSSL suivante :
openssl s_client -host LOG_SERVER -port 1443 -showcerts
Indiquez l'emplacement du fichier de certificat que vous avez créé dans le fichier /etc/opt/novell/eDirectory/conf/auditlogconfig.properties.
Si la solution d'audit est limitée à un seul serveur, il est préférable d'opter pour cet appender de fichier. L'appender Fichier propagé est plus fiable que l'appender Syslog, car il peut stocker les événements sur votre système de fichiers local et empêche la parte d'événements. Le nombre de composants à configurer étant limité, cette solution est également facile à mettre en oeuvre et plus adaptée aux démonstrations.
REMARQUE :si vous utilisez le connecteur de fichiers pour CEF, assurez-vous que le modèle de conversion pour l'appender Fichier propagé soit similaire à celui de l'appender Syslog comme indiqué ci-dessous :
log4j.appender.R.layout.ConversionPattern=%c: %m%n
Pour activer l'appender RollingFile, apportez les modifications suivantes au fichier auditlogconfig.properties :
Remplacez la valeur de l'entrée ci-dessous par R pour joindre l'appender RollingFile :
log4j.rootLogger=info, R
Supprimez les marques de commentaire des entrées suivantes :
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=/var/opt/novell/eDirectory/log/cef-events.log
log4j.appender.R.MaxFileSize=100MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c %m%nSélectionnez l'événement souhaité dans Identity Console.
Pour plus d'informations sur la configuration des événements CEF, reportez-vous à la section Configuration des événements CEF pour l'audit.
Ouvrez OpenText Identity Console à partir d'un navigateur Web, à l'aide de l'URL suivante :
https://ip_address_or_DNS/identityconsole/
où ip_address_or_DNS correspond à l'adresse IP ou au nom DNS, ainsi qu'au numéro de port de votre serveur OpenText Identity Console.
Par exemple :
http://111.111.1.1:9000/
Connectez-vous en utilisant le nom et le mot de passe utilisateur de l'arborescence.
Si vous souhaitez accéder à toutes les fonctions d'OpenText Identity Console, vous devez vous connecter à l'arborescence en tant qu'administrateur. Seul un administrateur dispose d'un accès complet à toutes les fonctionnalités. S'il n'est pas administrateur, l'utilisateur peut uniquement accéder aux rôles pour lesquels des droits lui sont assignés.
Pour plus d'informations, consultez le Guide d'administration d'OpenText Identity Console.
Sélectionnez Audit.
Dans la liste déroulante, sélectionnez le serveur NCP requis pour lequel vous souhaitez configurer l'audit.
Spécifiez les détails de configuration des événements si nécessaire.
Cliquez sur OK.
La page CEF Audit (Audit CEF) s'affiche. Passez à la Configuration de CEF.
REMARQUE :Nous recommandons à l'administrateur de désactiver les attributs suivants dans OpenText Audit Identity Console :
Expert
DirXML-DriverStorage
Notice nécrologique
État de la partition
Réplique
Revision
SAS :Secret de connexion
Cliquez sur Appliquer. Cliquez sur OK.
Connectez-vous à OpenText Identity Console à l'aide de votre nom d'utilisateur et de votre mot de passe.
Cliquez sur Audit.
Configurez les événements CEF.
Global : vous pouvez sélectionner ou désélectionner les paramètres globaux pour les entrées en double.
Ne pas envoyer d'événement répliqué : sélectionnez cette option pour ne plus recevoir les événements en double en raison de la réplication à partir d'autres serveurs.
Consigner les valeurs de l'événement : les événements sont consignés dans un fichier texte. Les valeurs d'événements de plus de 768 octets sont considérées comme de « grandes valeurs ». Vous pouvez consigner des événements de n'importe quelle taille.
Consigner de grandes valeurs : sélectionnez cette option pour consigner les événements dont la taille est supérieure à 768 octets.
Ne pas consigner de grandes valeurs : sélectionnez cette option pour consigner les événements dont la taille est inférieure à 768 octets.
Consigner les valeurs d'attribut : sélectionnez cette option pour afficher les valeurs d'attribut. Cette option s'applique uniquement aux événements Ajouter une valeur et Supprimer la valeur.
Ne pas consigner les valeurs d'attribut : Sélectionnez cette option pour supprimer les valeurs d'attribut. Cette option s'applique uniquement aux événements Ajouter une valeur et Supprimer la valeur. Par défaut, cette option est sélectionnée.
Consigner les valeurs d'attributs chiffrés : sélectionnez cette option pour afficher les valeurs d'attributs chiffrés. Cette option s'applique uniquement aux événements Ajouter une valeur et Supprimer la valeur.
Ne pas consigner les valeurs d'attributs chiffrés : sélectionnez cette option pour supprimer les valeurs d'attributs chiffrés. Cette option s'applique uniquement aux événements Ajouter une valeur et Supprimer la valeur. Par défaut, cette option est sélectionnée.
REMARQUE :Si l'événement est plus volumineux, sa valeur est tronquée et enregistrée dans le fichier journal.
Configuration des événements de base : spécifiez des valeurs pour les options ci-dessous, en fonction des événements requis pour votre environnement :
REMARQUE :par défaut, les catégories d'événements individuelles sous la section Configuration des événements de base sont réduites. Vous pouvez agrandir chaque catégorie pour sélectionner des événements individuels.
|
Options |
Description |
|---|---|
|
Événements de sécurité |
Sélectionnez les événements de sécurité pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour ajouter ou supprimer un membre, pour détecter un intrus, pour changer de mot de passe, pour authentifier des utilisateurs, etc. |
|
Événements d'objets |
Sélectionnez les événements d'objets pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour créer, supprimer, renommer, déplacer et rechercher des objets. |
|
Événements d'attributs |
Sélectionnez les événements d'attributs pour lesquels vous souhaitez consigner des événements. Vous pouvez consigner des événements pour lire et supprimer des attributs et pour ajouter, supprimer et comparer des valeurs d'attributs. |
|
Événements LDAP |
Sélectionnez les événements LDAP pour lesquels vous souhaitez consigner des événements. |
|
Événements EBA |
Sélectionnez l'événement EBA pour lequel vous souhaitez consigner des événements. |
Pour plus d'informations sur les événements internes OpenText eDirectory assignés aux événements CEF correspondants, reportez-vous à la section Assignation d'événements OpenText eDirectory à des événements CEF.
REMARQUE :une fois la configuration d'événement modifiée, l'application des modifications de configuration sur le serveur NCP peut prendre jusqu'à 3 minutes. Si vous voulez que les modifications apportées à la configuration soient immédiatement prises en compte sur le serveur NCP, vous devez décharger et charger le module cefauditds.
Une fois les événements CEF configurés, exécutez les commandes ci-dessous pour charger et décharger les modules CEF :
Pour charger automatiquement le module cefauditds à chaque démarrage du serveur ndsd :
Linux
Ajoutez cefauditds au fichier /etc/opt/novell/eDirectory/conf/ndsmodules.conf.
Windows
Exécutez le fichier ndscons.exe, sélectionnez cefauditds dans la liste des modules disponibles, cliquez sur Démarrage, puis définissez l'option Type de démarrage sur Automatique.
Pour charger et décharger manuellement le module cefauditds :
Linux
Pour charger le module, exécutez ndstrace -c "load cefauditds".
Pour décharger le module, exécutez ndstrace -c "unload cefauditds".
Windows
Pour charger le module, exécutez le fichier ndscons.exe, sélectionnez cefauditds dans la liste des modules disponibles, puis cliquez sur Démarrer.
Pour décharger le module, exécutez le fichier ndscons.exe, sélectionnez cefauditds dans la liste des modules disponibles, puis cliquez sur Arrêter.
OpenText eDirectory 9.2 vous permet en option de stocker en local des événements CEF sur l'agent dans un cache de l'appender Syslog. Lorsque les événements sont mis en cache, si l'agent ne peut pas communiquer avec le serveur d'audit, les événements d'audit générés sont conservés, ce qui permet d'éviter toute perte des données d'audit. Une fois la communication rétablie entre l'ordinateur de l'agent et le serveur d'audit, l'agent tente de renvoyer les événements mis en cache.
Le caching des événements CEF est désactivé par défaut. Pour activer le caching des événements, procédez comme suit :
Sur l'ordinateur de l'agent, accédez à l'emplacement du fichier de propriétés CEF. Par défaut, le fichier auditlogconfig.properties se trouve à l'emplacement /etc/opt/novell/eDirectory/conf/auditlogconfig.properties. Pour les installations non-root, le fichier de propriétés CEF se trouve par défaut dans le répertoire conf.
Utilisez un éditeur de texte pour ouvrir le fichier auditlogconfig.properties.
Dans le fichier de propriétés, accédez à la propriété log4j.appender.S.CacheEnabled et définissez sa valeur sur yes.
(Conditionnel) Si vous souhaitez mettre en cache les événements dans un répertoire spécifique, définissez la valeur de la propriété log4j.appender.S.CacheDir sur le chemin de répertoire. Si vous spécifiez un répertoire, assurez-vous que son chemin est un emplacement valide sur le serveur. Si la propriété log4j.appender.S.CacheDir n'est pas définie, les journaux de l'appender Syslog mettent en cache les événements dans le répertoire dib de cette instance.
Vous pouvez spécifier la taille de fichier personnalisée pour le fichier de cache dans deux modes différents :
Mode de croissance limité : en mode croissance limitée, la valeur minimale de la taille du fichier de cache doit être configurée à 50 Mo, avec une valeur maximale de 4 Go. Toute valeur configurée en dehors de cette plage définira par défaut la taille du fichier de cache sur 500 Mo. Une fois que la taille limite du fichier de cache a atteint son niveau maximal, le rollover du fichier de cache démarre. Le fichier de cache ne sera pas tronqué une fois que tous les journaux d'événements mis en cache auront été envoyés au serveur Syslog dans ce mode.
Mode de croissance infinie : Pour activer le mode de croissance infinie, définissez la taille du fichier de cache sur 0 Mo. Le rollover du fichier de cache n'a pas lieu dans ce mode. Une troncation du fichier de cache se produit lorsque tous les événements mis en cache ont été envoyés au serveur Syslog dans ce mode. Nous vous recommandons de placer le fichier de cache dans une partition ou un disque distinct, afin d'éviter tout impact sur la croissance de la DIB en raison de la croissance du fichier de cache.
Enregistrez, puis fermez le fichier auditlogconfig.properties.
Rechargez le module CEF.
Le mécanisme de mise en cache utilise tous les fichiers suivants sous l'emplacement du répertoire Cache :
CEF-S-cache.log
RolledOver-CEF-S-record
OffsetWriter-CEF-S-record
OffsetReader-CEF-S-record
Le fichier CEF-S-cache.log est alimenté par un Writer (processus d'écriture) et un Reader (processus de lecture) de cache. Le Writer écrit les événements dans le journal de cache en cas de perte de la connexion au serveur Syslog. Le OffsetWriter-CEF-S-record est mis à jour avec le décalage writer indiquant la quantité d'événements CEF consignés dans le fichier de cache. Lorsque le Writer atteint la taille maximale du fichier de cache, un rollover se produit au début du fichier de cache qui définit le drapeau dans le fichier .RolledOver-CEF-S-record de la valeur 1 à la valeur 0. Un message approprié sera imprimé dans le fichier ndsd.log à ce stade, indiquant le retour au début du Writer de cache. Le Writer continue à écrire des événements dans le journal de cache et s'arrête avant la valeur de décalage du Reader. Cela permet de s'assurer que le Writer n'écrase pas les événements qui doivent encore être envoyés au serveur Syslog. Tout événement généré après cette erreur sera perdu et un message indiquant l'utilisation complète du fichier de cache sera imprimé dans le fichier ndsd.log.
Le Reader lit les événements à partir du fichier de cache et les envoie au serveur Syslog lorsque la connexion est rétablie. Le fichier .offsetReader-CEF-S-record est mis à jour avec le décalage du Reader indiquant la quantité d'événements CEF envoyés au serveur Syslog à partir du fichier de cache. La position du Reader avance, ce qui donne au Writer la place d'écrire de nouveaux événements dans le cache. Le Reader revient au début une fois qu'il a atteint la fin du fichier et le drapeau présent dans le fichier .RolledOver-CEF-S-record revient à 0. Un message approprié sera imprimé dans le fichier ndsd.log à ce stade, indiquant le retour au début du Reader de cache. La lecture et l'envoi se poursuivent jusqu'à ce que le décalage du Reader corresponde au décalage du Writer. Cette procédure envoie toutes les données mises en cache au serveur Syslog. Une fois ce processus terminé, aucune autre mise à jour ne se produit dans le fichier de cache, car les événements sont envoyés directement au serveur Syslog.
REMARQUE :Étant donné que le rollover n'a pas lieu en mode de croissance infinie, le fichier de cache est tronqué après l'envoi de tous les événements mis en cache au serveur Syslog. Tous les décalages sont également réinitialisés une fois la troncation du fichier de cache terminée.
Vous pouvez configurer CEF de sorte à consigner les événements dans les catégories suivantes :
Sécurité
Objets
Attributs
LDAP
EBA
Vous pouvez auditer les ensembles de types d'événement par défaut suivants :
|
Catégorie |
Type d'événement |
|---|---|
|
Sécurité |
|
|
Objets |
|
|
Attributs |
|
|
LDAP |
|
|
EBA |
|
REMARQUE :L'événement Modification de la configuration du serveur LDAP est publié lors de l'actualisation du serveur LDAP via une requête client LDAP.
Pour plus d'informations sur l'utilisation de collecteurs d'événements CEF, reportez-vous à la documentation du collecteur OpenText eDirectory sur la page des plug-ins Sentinel.
À l'aide de filtres et de notifications d'événement, CEF est capable de signaler la survenue ou la non-survenue d'un type d'événement spécifique. Vous pouvez également filtrer les événements pour un(e) ou plusieurs classes ou attributs d’objet spécifiques, selon le type d’événement. CEF évalue tous les événements générés en fonction des filtres configurés sur le serveur OpenText eDirectory et ne consigne que les événements qui correspondent à ces filtres.
Cette section fournit les informations nécessaires pour configurer les filtres et les notifications du système.
Vous pouvez configurer le filtrage des objets de manière à ne rechercher qu'un seul événement ou un type d'événements spécifique. Par exemple, si vous souhaitez être averti lorsqu'une personne crée un compte utilisateur dans OpenText eDirectory, vous pouvez créer un filtre de sélection de la classe d'objet Utilisateur pour consigner les événements dans le cadre de la création d'un nouvel objet Utilisateur.
Pour configurer le filtrage des comptes, cliquez sur le lien Événements d'objets, sélectionnez la classe, puis cliquez sur OK pour quitter l'application.
Pour configurer des filtres pour les événements de gestion des comptes :
Sur la page d'accueil d'OpenText Identity Console, accédez à Audit.
Sélectionnez le serveur NCP à surveiller dans le menu déroulant, puis cliquez sur OK.
Cliquez sur la vignette Événements d'objets.
Sélectionnez l'événement d'objet requis à configurer.
Cliquez sur Appliquer et sur OK pour modifier les détails d'audit.
À l'aide du filtre configuré, le module d'audit CEF contrôle tous les événements générés pour les classes d'objet et les attributs sélectionnés et consigne ces événements.
Cliquez sur le lien Événements d'attributs pour configurer le filtrage des événements d'attributs. Par exemple, si vous souhaitez être averti lorsqu'une personne ajoute une nouvelle valeur d'attribut dans OpenText eDirectory, vous pouvez créer un filtre pour consigner des événements en cas d'ajout d'une nouvelle valeur.
Pour configurer le filtrage des événements de gestion des approbations :
Dans OpenText Identity Console, accédez à Audit eDirectory.
Sélectionnez le serveur NCP à surveiller, puis cliquez sur OK.
Cliquez sur Événements d'attributs.
La fenêtre Attribute Filtering (Filtrage des attributs) s'affiche.
Dans la liste Classes disponibles, sélectionnez les classes d'objet pour lesquelles vous souhaitez collecter des événements, puis cliquez sur la flèche droite pour les déplacer dans la liste Classes sélectionnées. Par défaut, les classes d'objet dynamicGroup, dynamicGroupAux, Groupe, Groupe LDAP et Rôle organisationnel sont sélectionnées.
Dans la liste Attributs disponibles, sélectionnez le nombre souhaité d'attributs pour les classes d'objet sélectionnées. Sélectionnez l'attribut, puis cliquez sur la flèche droite pour l'ajouter à la liste des attributs sélectionnés.
REMARQUE :si vous sélectionnez une classe d'objet, tous les événements d'attributs pour tous les attributs de cette classe d'objet sont sélectionnés. Dans ce cas, vous obtiendrez tous les événements d'attributs pour l'ensemble des attributs sélectionnés dans les classes d'objet sélectionnées.
Cliquez sur OK.
Lorsque le filtre est configuré, le module d'audit CEF contrôle tous les événements générés pour les classes d'objet et les attributs sélectionnés et consigne ces événements.
Cliquez sur le lien Filtre d'exclusion afin de configurer le filtrage des classes d'objet et des attributs pour lesquels vous ne souhaitez pas générer d'événement. Vous pouvez sélectionner des classes d'objet et des attributs.
Pour configurer le filtrage des événements OpenText eDirectory indésirables :
Sur la page d'accueil d'OpenText Identity Console, cliquez sur la vignette Audit.
Sélectionnez le serveur NCP à surveiller, puis cliquez sur OK.
Cliquez sur la liste déroulante Paramètres avancés, puis sélectionnez Filtre d'exclusion.
La fenêtre Filtrage des exclusions CEF s'affiche.
Dans la liste Classes d'objets disponibles, sélectionnez les classes d'objets pour lesquelles vous ne souhaitez pas collecter d'événements, puis cliquez sur la flèche droite pour les déplacer dans la liste Classes d'objets sélectionnées.
Dans la liste Attribut(s) disponible(s), sélectionnez le nombre souhaité d'attributs. Sélectionnez l'attribut, puis cliquez sur la flèche droite pour l'ajouter à la liste des attributs sélectionnés.
Cliquez sur OK.
À l'aide du filtre configuré, le module d'audit CEF arrête de générer des événements pour toutes les classes d'objet et les attributs sélectionnés.
Ce document définit le protocole CEF et fournit des informations sur la méthode à utiliser pour implémenter la norme. Il décrit en détail l'en-tête et les extensions prédéfinies utilisés dans le cadre de la norme.
CEF utilise Syslog comme mécanisme de transport. Il utilise le format suivant, constitué d'un préfixe Syslog, d'un en-tête et d'une extension, comme indiqué ci-dessous :
Jan 18 11:07:53 host CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]
La partie CEF:Version du message est un en-tête obligatoire. Le reste du message est mis en forme à l'aide de champs séparés par une barre verticale (« | »). Tous les autres champs doivent être présents et sont définis dans la section Définitions des champs CEF.
La partie prévue pour étendre le message est une marque de réservation pour des champs supplémentaires, mais n'est pas obligatoire. Tout autre champ supplémentaire est consigné en tant que paire clé-valeur. Pour plus d'informations, reportez-vous à la section Définitions des champs CEF.
Les champs inclus dans le schéma sont les champs CEF définis spécifiquement pour les événements d'audit. Certains ou l'ensemble de ces champs peuvent également être pertinents pour d'autres types d'événement, mais des informations de ce type sont requises pour les services d'audit.
Tableau 23-3 Définitions des champs CEF
|
Champ CEF |
Description |
|---|---|
|
Device Product |
Device Product est une chaîne qui identifie de manière unique le périphérique à l'origine de l'envoi. Deux produits ne peuvent pas avoir la même paire périphérique-produit. L'administrateur doit veiller à assigner un nom unique à chaque paire périphérique-produit. |
|
Device Version (Périphérique-version) |
Device Version est une chaîne qui identifie de manière unique le périphérique à l'origine de l'envoi. Deux produits ne peuvent pas avoir la même paire périphérique-version. L'administrateur doit veiller à assigner un nom unique à chaque paire périphérique-version. |
|
Device Vendor (Périphérique-fournisseur) |
Device Vendor est une chaîne qui identifie de manière unique le périphérique à l'origine de l'envoi. Deux produits ne peuvent pas avoir la même paire périphérique-fournisseur. L'administrateur doit veiller à assigner un nom unique à chaque paire périphérique-fournisseur. |
|
Device Event Class ID (ID de classe d'événement du périphérique) |
Device Event Class ID est un identificateur unique par type d'événement. Il peut s'agir d'une chaîne ou d'un nombre entier. Device Event Class ID identifie le type d'événement signalé. Dans la sphère des systèmes de détection d'intrus (intrusion detection system - IDS), chaque signature ou règle qui détecte certaines activités a un identificateur unique de classe d'événement du périphérique qui lui est assigné. Cette exigence est valable pour d'autres types de périphériques également, et aide les moteurs de corrélation à traiter les événements. Cet identifiant est également connu sous l'appellation ID de signature. |
|
Severity (Gravité) |
Il s'agit d'une chaîne ou d'un nombre entier qui reflète l'importance de l'événement. Les valeurs de chaîne valides sont : Unknown (Inconnue), Low (Faible), Medium (Moyenne), High (Élevée) et Very-High (Très élevée). Les valeurs de nombre entier valides sont 0 à 3 = faible, 4 à 6 = moyenne, 7 et 8 = élevée et 9 et 10 = très élevée. À partir d'eDirectory 9.2 SP2, les assignations de valeurs et d'entiers suivantes sont suivies :
|
|
Version |
Il s'agit d'un nombre entier qui identifie la version du format CEF. Les consommateurs d'événements utilisent ces informations pour déterminer ce que représentent les champs suivants. La version actuelle de CEF est 0. |
|
Device Address (Adresse du périphérique) |
Identifie l'adresse du périphérique à laquelle fait référence un événement dans un réseau IP. Le format est une adresse IPv4. |
|
c6a1 |
Un des quatre champs d'adresse IPV6 disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. |
|
dvchost |
Le format doit être un nom de domaine complet associé au nœud de périphérique, le cas échéant. Par exemple, hôte.domaine.com ou hôte. |
|
rt |
Heure de réception de l'événement associé à l'activité. Le format est MMM JJ aaaa hh:mm:ss ou millisecondes à partir de l'époque concernée. |
|
dtz |
Fuseau horaire du périphérique générant l'événement. |
|
sourceServiceName |
Service responsable de la génération de cet événement. |
|
sproc |
Nom du processus source de l'événement. |
|
src |
Identifie la source à laquelle un événement fait référence dans un réseau IP. Le format est une adresse IPv4. Par exemple, 192.168.10.1. |
|
spt |
Il s'agit du numéro de port source. Les numéros de port valides sont compris entre 0 et 65 535. |
|
shost |
Identifie la source à laquelle un événement fait référence dans un réseau IP. Le format doit être un nom de domaine complet associé au nœud de la source, le cas échéant. Par exemple, hôte.domaine.com ou hôte. |
|
suser |
Identifie l'utilisateur source à l'aide d'un nom. Les adresses électroniques sont également assignées aux champs UserName. L'expéditeur est un candidat à placer dans sourceUserName. |
|
dst |
Identifie l'adresse de destination à laquelle fait référence un événement dans un réseau IP. Le format est une adresse IPv4. Par exemple, 192.168.10.1. |
|
duser |
Identifie l'utilisateur de destination par son nom. Il s'agit de l'utilisateur associé à la destination de l'événement. Les adresses électroniques sont souvent assignées dans les champs UserName. Le destinataire est un candidat à placer dans destinationUserName. |
|
cn1 |
Un des trois champs de nombre disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomNumber1. |
|
cn2 |
Un des trois champs de nombre disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomNumber2. |
|
cn3 |
Un des trois champs de nombre disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomNumber3. |
|
cn1Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomNumber1Label. |
|
cn2Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomNumber2Label. |
|
cn3Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomNumber3Label |
|
cs1 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString1. |
|
cs2 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString2. |
|
cs3 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString3. |
|
cs4 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString4. |
|
cs5 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString5. |
|
cs6 |
Une des six chaînes disponibles pour affecter des champs qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Également appelé deviceCustomString6. |
|
cs1Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString1Label. |
|
cs2Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString2Label. |
|
cs3Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString3Label. |
|
cs4Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString4Label. |
|
cs5Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString5Label. |
|
cs6Label |
Tous les champs personnalisables comportent un champ d'étiquette pouvant accueillir une description du champ proprement dit. Chacun des champs est une chaîne qui décrit l'utilité de ce champ. Également appelé deviceCustomString6Label. |
|
flexString1 |
Un des deux champs de chaîne disponibles pour affecter des données de chaîne qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexString2 |
Un des deux champs de chaîne disponibles pour affecter des données de chaîne qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexString1Label |
Un des deux champs de chaîne disponibles pour affecter des données de chaîne qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexString2Label |
Un des deux champs de chaîne disponibles pour affecter des données de chaîne qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexNumber1 |
Un des deux champs de nombre disponibles pour affecter des données longues qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexNumber2 |
Un des deux champs de nombre disponibles pour affecter des données longues qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexNumber1Label |
Un des deux champs de nombre disponibles pour affecter des données longues qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
flexNumber2Label |
Un des deux champs de nombre disponibles pour affecter des données longues qui ne s'appliquent à aucun autre champ dans ce dictionnaire. À utiliser avec modération. Recherchez si possible un champ plus spécifique fourni par le dictionnaire. Ces champs sont généralement réservés à une utilisation par le client et ne doivent pas être définis par les fournisseurs, à moins que ce ne soit vraiment nécessaire. |
|
cat |
Représente la catégorie assignée par le périphérique d'origine. Les périphériques utilisent souvent leur propre schéma de catégorisation pour classer les événements. Également appelé deviceEventCategory. Par exemple, /Monitor/Disk/Read. |
|
reason (motif) |
Motif pour lequel un événement d'audit a été généré. Par exemple Bad password (mot de passe erroné) ou Unknown User (utilisateur inconnu). Il peut également s'agir d'un message d'erreur ou d'un code de renvoi. |
|
outcome (résultat) |
Affiche le résultat, généralement sous la forme de success (réussite) ou failure (échec). Également appelé eventOutcome. |
|
msg |
Description de l'événement |
Vous trouverez ci-dessous un exemple d'événement :
Apr 15 19:43:37 eDirectory CEF:0|NetIQ|eDirectory|9.2.2|CEF0B035D|AUTHENTICATE|4|dvc=164.99.179.219 dvchost=WIN-ADKHVNQHFCR rt=1586960017190 dtz=India Standard Time sourceServiceName=CN\=WIN19,O\=novell sproc=eDirectory#DS src=164.99.179.219 spt=0 suser=CN\=admin,O\=novell duser=CN\=admin,O\=novell cs2Label=Class Name cs2=User cs3Label=Tree Name cs3=WIN19_tree cs4Label=Correlation ID cs4=eDirectory#24# cs6Label=Server Name cs6=CN\=WIN19,O\=novell flexString2Label=SubEvent flexString2=DSE_AUTHENTICATE flexNumber2Label=Grouping flexNumber2=2131 cat=Security reason=0 outcome=Success msg=CN\=admin,O\=novell (Class: User) authenticated from to server CN\=WIN19,O\=novell : Success
Pour plus d'informations sur les événements CEF, reportez-vous à l'Section G.0, Assignation d'événements OpenText eDirectory à des événements CEF.