Common Event Format (CEF) provides a standard event format to facilitate the merging and analysis of audit information from multiple components at the distributed system level. The CEF format uses the Syslog message format as a transport mechanism.
CEF is an extensible text-based format that is designed to support multiple device types such as on-premise devices and cloud-based services. CEF events helps you easily understand the audit trails of heterogeneous applications.
Configuring eDirectory to use CEF provides the following benefits:
Provides secured uniform audit services for a distributed system.
CEF uses a standard message format that simplifies log management.
The new event format seamlessly integrates with Sentinel.
NOTE:If you are using eDirectory 9.1 with Identity Manager 4.7, you can either enable CEF or XDAS audit module. If you upgrade your Identity Manager from a previous version to 4.7, disable the XDAS audit module to use CEF with eDirectory.
This following section covers how to configure CEF with eDirectory:
The eDirectory installation kit includes both a Linux and a Windows CEF client as part of its download package. The installation program for eDirectory installs the CEF packages on your operating system. The CEF package contains the following files:
Linux
novell-edirectory-xdaslog
novell-edirectory-xdaslog-conf
novell-edirectory-cefinstrument-9.2.0-0.x86_64.rpm
Windows
cefauditds.dlm
xdaslog.dll
This section provides the following information:
Installing and using the NetIQ Audit iManager Plug-in requires iManager 3.1 at a minimum. See NetIQ iManager Product Page for requirements and download instructions.
The iManager plug-in for CEF is bundled with eDirectory 9.2 plug-ins. Alternatively, you can download the eDirectory plug-ins from the Software License and Download portal.
To install the iManager plug-in:
Open iManager from a Web browser, using the following URL:
https://ip_address_or_DNS/nps/iManager.html
where ip_address_or_DNS is the IP address or DNS name of your iManager server.
For example:
http://111.111.1.1/nps/iManager.html
Log in to the iManager using your username and password.
If you want to access all the NetIQ iManager features, you must login as an administrator to the tree. Only administrative user has full access to all the features. A non-administrative user can only access those roles for which rights are assigned.
For more information, see the NetIQ iManager Administration Guide.
The eDirectory media includes a sample properties file, auditlogconfig.properties.template file in the configdir (n4u.server.configdir) directory.
Table 23-1 lists the default location of the auditlogconfig.properties file on Linux and Windows operating systems.
Table 23-4 CEF Configuration File
|
Operating System |
Location of the Property File |
|---|---|
|
Linux |
/etc/opt/novell/eDirectory/conf/ auditlogconfig.properties For non-root installations, the CEF property file is located in the conf directory. |
|
Windows |
<Install Path>/novell/nds/auditlogconfig.properties The property file is usually in the eDirectory installation directory. |
If you configure the property file and then upgrade your environment eDirectory 9.2 to any latest version, the installer does not replace the property file. Instead, the upgrade process updates the file (auditlogconfig.properties) to retain the customization.
You can configure CEF after installing iManager. The CEF configuration settings are stored in a simple text-based auditlogconfig.properties configuration file. You can customize the file based on your requirements.
The CEF auditlogconfig.properties file contains the following information:
# 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
Before going through the content of the auditlogconfig.properties file, NetIQ recommends reviewing the following considerations:
The letters S and R specify Syslog Appender and Rolling File Appender respectively.
The entries are not case sensitive.
The entries can appear in any order.
Empty lines in the file are valid.
Any line that starts with a hash (#) is commented out.
The following table provides information about the settings in the auditlogconfig.properties file:
IMPORTANT:You must restart eDirectory after changing any configuration.
|
Setting |
Description |
|---|---|
|
log4j.rootLogger=info, S, R |
Sets the level of the root logger to debug and attaches an appender named S or R, where S specifies a Syslog appender and R specifies a Rolling File appender. The available levels of root logger (in the same order of their priority) are: trace, debug, info, warn, error and fatal. By default, info will be specified which includes events from all other levels except trace and debug. If you want to send all the events to log, specify TRACE or ALL in this field. |
|
log4j.appender.S=org.apache.log4j.net.SyslogAppender |
Specifies the appender S to be a Syslog appender. |
|
log4j.appender.S.Host=localhost |
Specifies the location of the Syslog server where CEF events are logged. IFor example,log4j.appender.S.Host=192.168.0.1 |
|
log4j.appender.S.Port=port |
The port at which the CEF connects to the Syslog server. The port supports values from 1 to 65535. If you specify an invalid value, the port defaults to 514. If the connection between CEF and the Syslog server fails, Identity Manager cannot log events until the connection is restored. |
|
log4j.appender.S.Protocol=TCP |
Specifies the protocol to use. For example, UDP, TCP, or SSL. |
|
log4j.appender.S.SSLCertFile=/etc/opt/novell/mycert.pem |
Specifies the SSL certificate file for the SSL connection. Use double backslashes to specify the path of the file. This is an optional setting. |
|
log4j.appender.S.Threshold=INFO |
Specifies the minimum log level allowed in the Syslog. The following log-levels are supported (in the same order of their priority): TRACE, DEBUG, INFO, WARN and ERROR. The minimum default log-level is INFO that includes all other log levels except TRACE and DEBUG. Which means, if you specify INFO as the minimum log-level, TRACE and DEBUG events will not be sent to the Syslog server. If you want to send all the events to the Syslog server, specify TRACE or ALL in this field. |
|
log4j.appender.S.Facility=USER |
Specifies the type of facility. The facility is used to try to classify the message.Currently, USER facility is supported. These values may be specified as upper or lower case characters. |
|
log4j.appender.S.layout=org.apache.log4j.PatternLayout |
Layout setting for Syslog appender. |
|
log4j.appender.S.layout.ConversionPattern=%c : %p%m%n |
Layout setting for Syslog appender. For information about the conversion patters and their descriptions, see logging.apache.org. |
|
log4j.appender.R=org.apache.log4j.RollingFileAppender |
Specifies appender R to be a Rolling File appender. |
|
log4j.appender.R.File=/var/opt/novell/eDirectory/log/cef-events.log |
The location of the log file for a Rolling File appender. |
|
log4j.appender.R.MaxFileSize=100MB |
The maximum size, in MBs, of the log file for a Rolling File appender. Set this value to the maximum size that the client allows. |
|
log4j.appender.R.MaxBackupIndex=10 |
Specify the maximum number of backup files for a Rolling File appender. The maximum number of the backup files can be 10. A 0 value means no backup files. |
|
log4j.appender.R.layout=org.apache.log4j.PatternLayout |
Layout setting for Rolling File appender. |
|
log4j.appender.R.layout.ConversionPattern=%d{MMM dd HH:mm:ss} %c : %p%m%n |
Layout setting for Rolling File appender. For simple date format patterns, see Table 23-2. For information about the conversion patters and their descriptions, see logging.apache.org. |
Table 23-2 lists examples with the date and time patterns interpreted in the U.S. The given date and time are 2012-07-04 12:08:56 local time in the U.S. Pacific Time time zone.
Table 23-5 Date and Time Pattern Example
|
Date and Time Pattern |
Result |
|---|---|
|
"yyyy.MM.dd G 'at' HH:mm:ss z" |
2012.07.04 AD at 12:08:56 PDT |
|
"EEE, MMM d, ''yy" |
Wed, Jul 4, '01 |
|
"h:mm a" |
12:08 PM |
|
"hh 'o''clock' a, zzzz" |
12 o'clock PM, Pacific Daylight Time |
|
"K:mm a, z" |
0:08 PM, PDT |
|
"yyyyy.MMMMM.dd GGG hh:mm aaa" |
02012.July.24 AD 12:08 PM |
|
"EEE, d MMM yyyy HH:mm:ss Z" |
Wed, 24 Jul 2012 12:08:56 -0700 |
|
"yyMMddHHmmssZ" |
120724120856-0700 |
|
"yyyy-MM-dd'T'HH:mm:ss.SSSZ" |
2012-07-04T12:08:56.235-0700 |
You can use the Syslog appender to view the real time events. Additionally, a Syslog server offers better backup support in the event of a disaster.
To enable the Syslog appender, make the following changes in the auditlogconfig.properties file:
Change the following entry to S to attach a Syslog appender:
log4j.rootLogger=info, S
Uncomment the following entries:
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
Log into iManager and change the log events. For information about configuring CEF Events, see Configuring the CEF Events for Auditing.
NOTE:CEF caching using UDP protocol for SyslogAppender does not work.
To generate a certificate for syslog connection:
Create the certificate by using the following OpenSSL command:
openssl s_client -host LOG_SERVER -port 1443 -showcerts
Specify the location of the certificate file that you created in the /etc/opt/novell/eDirectory/conf/auditlogconfig.properties file.
This File appender is preferred, if the auditing solution is limited to an individual server. Rolling file appender is more reliable as compared to the Syslog appender because it can store the events on your local file system and prevents loss of events. Also, it is easy to bring up this solution because the number of components to be setup are few and thus, is more suited for demonstrations.
NOTE:If you are using the File Connector for CEF, ensure that the conversion pattern for the Rolling File appender is similar to the Syslog appender as shown below:
log4j.appender.R.layout.ConversionPattern=%c: %m%n
To enable the Rolling File appender, make the following changes in the auditlogconfig.properties file:
Change the following entry to R to attach a Rolling File appender.
log4j.rootLogger=info, R
Uncomment the following entries:
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%nSelect the desired event from iManager.
For information about configuring CEF Events, see Configuring the CEF Events for Auditing.
Open iManager from a Web browser using the following URL:
https://ip_address_or_DNS/nps/iManager.html
where ip_address_or_DNS is the IP address or DNS name of your iManager server.
For example:
http://111.111.1.1/nps/iManager.html
Log in using your username and password.
If you want to access all the NetIQ iManager features, you must login as an administrator to the tree. Only administrative user has full access to all the features. A non-administrative user can only access those roles for which rights are assigned.
For more information, see the NetIQ iManager Administration Guide.
Select Roles and Tasks. > Audit Configuration.
Specify the name of your eDirectory server in NCP Server, then click the Object Selector icon to browse for the eDirectory server.
Click OK.
The CEF Audit page is displayed. Continue with Configuring CEF.
NOTE:We recommend the administrator to disable the following attributes in the Audit iManager plug-in:
Authoritative
DirXML-DriverStorage
Obituary
Partition Status
Replica
Revision
SAS:Login Secret
Log in to iManager using your username and password.
Select Roles and Tasks. > eDirectory Auditing > Audit Configuration.
Select the CEF tab.
Configure the CEF events.
Global: You can select or clear the global settings for duplicate entries.
Do Not Send Replicated Events: Select this option to stop receiving duplicate events due to replication from other servers.
Log Event’s Values: The events are logged into a text file. Event values with more than 768 bytes in size are considered “large values.” You can log events of any size.
Log Large Values: Select this option to log events that are more than 768 bytes in size.
Don’t Log Large Values: Select this option to log events that are less than 768 byte in size.
Log Attributes Values: Select this option to display the attribute values. This is applicable to Add Value and Delete Value events only.
Don’t Log Attribute Values: Select this option to suppress the attribute values. This is applicable to Add Value and Delete Value events only. By default, this option is selected.
Log Encrypted Attribute Values: Select this option to display the encrypted attribute values. This is applicable to Add Value and Delete Value events only.
Don’t Log Encrypted Attribute Values: Select this option to suppress the encrypted attribute values. This is applicable to Add Value and Delete Value events only. By default, this option is selected.
NOTE:If the event size is more, the event value is truncated and saved to the log file.
Basic Events Configuration: Specify the values for the following options based on the events required for your environment:
NOTE:Individual event categories under the basic events configuration section will be collapsed by default. You can expand each category to select individual events.
|
Options |
Description |
|---|---|
|
Security Events |
Select the security events for which you want to log events. You can log events to add or delete member, to detect intruder, to change password and to authenticate users etc. |
|
Object Events |
Select the object events for which you want to log events. You can log events to create delete, rename, move and search objects. |
|
Attribute Events |
Select the attribute events for which you want to log events. You can log events to read and delete attributes and to add, delete and compare attribute value. |
|
LDAP Events |
Select the LDAP events for which you want to log events. |
|
EBA Events |
Select the EBA event for which you want to log events. |
For information about eDirectory internal events mapped with the corresponding CEF events, see Mapping eDirectory Events with CEF Events.
NOTE:After modifying the event configuration, it takes up to 3 minutes for the configuration changes to take effect on the NCP Server. If you want the configuration changes to be effective immediately on the NCP server, you must unload and load the cefauditds module.
After you configure the CEF events, run the following commands to load and unload the CEF modules:
To automatically load the cefauditds module whenever the ndsd server is started:
Linux
Add cefauditds to the /etc/opt/novell/eDirectory/conf/ndsmodules.conf file.
Windows
Run ndscons.exe, select cefauditds from the list of available modules, click Startup, and then select Automatic for Startup Type.
To manually load and unload the cefauditds module:
Linux
To load, run ndstrace -c "load cefauditds".
To unload, run ndstrace -c "unload cefauditds".
Windows
To load, run ndscons.exe, select cefauditds from the list of available modules, then click Start.
To unload, run ndscons.exe, select cefauditds from the list of available modules, then click Stop.
eDirectory 9.2 allows you to optionally store CEF events locally on the agent in a Syslog Appender cache. With events cached, if the agent cannot communicate with the auditing server, the audit events generated are retained, ensuring that audit data is not lost. The agent then attempts to re-send the cached events when the agent computer can once again communicate with the auditing server.
CEF event caching is disabled by default. To enable event caching, complete the steps below.
On the agent computer, navigate to the location of the CEF property file. The auditlogconfig.properties file is located at /etc/opt/novell/eDirectory/conf/auditlogconfig.properties by default. For non-root installations, the CEF property file is located in the conf directory by default.
Use a text editor to open the auditlogconfig.properties file.
Within the property file, navigate to the log4j.appender.S.CacheEnabled property and change the property value to yes.
(Conditional) If you want to cache events in a specific directory, modify the value of the log4j.appender.S.CacheDir property to specify the directory path. If you specify a directory, ensure that the directory path is a valid location on the server. If the log4j.appender.S.CacheDir property is not set, the Syslog Appender logs cache events in the dib directory of that particular instance.
You can specify the custom file size for cache file in two different modes:
Limited growth mode: In limited growth mode, the minimum value for the cache file size should be configured at 50 MB, with a maximum value of 4 GB. Any value configured outside this range will set the cache file size value to 500MB by default. Once the cache file size limit reaches its maximum level, the cache file rollover starts. Cache file will not be truncated after all cached event logs are sent to Syslog server in this mode.
Infinite growth mode: To enable the infinite growth mode, set the Cache File size to 0MB. The cache file rollover does not happen in this mode. A truncation of cache file will happen once all cached events are sent to Syslog server in this mode. We recommend that you place the cache file in a separate partition or disk, to avoid impact to DIB growth due to cache file growth.
Save and close the auditlogconfig.properties file.
Reload the CEF module.
The caching mechanism uses all of the following files under the Cache directory location:
CEF-S-cache.log
RolledOver-CEF-S-record
OffsetWriter-CEF-S-record
OffsetReader-CEF-S-record
The CEF-S-cache.log file is serviced by an Cache Writer and a Cache Reader. The Writer writes events into the Cache log when the connection to the Syslog server is lost. The .OffsetWriter-CEF-S-record file gets updated with the Writer Offset indicating the amount of CEF events logged into the Cache file. When the Writer reaches the maximum cache file size, a rollover happens to the beginning of the cache file which sets the flag in .RolledOver-CEF-S-record file to value 1 from 0. An appropriate message will be printed in the ndsd.log at this point indicating Cache Writer rollback. The Writer continues writing events into the Cache log and stops before the Reader's offset value. This is to ensure that the Writer does not overwrite the events which are yet to be sent to the Syslog server. Any event generated post this will be lost and an appropriate message indicating the full utilization of the Cache file will be printed in the ndsd.log.
The Reader reads the events from the cache file and sends them to the Syslog server when the connection is re-established. The .OffsetReader-CEF-S-record file gets updated with the Reader Offset indicating the amount of CEF events sent to the Syslog server from the Cache file. Reader position moves ahead giving room for the Writer to write more new events to cache. The Reader rolls back once it reaches the end of the file and the flag in.RolledOver-CEF-S-record file gets reverted to 0. An appropriate message will be printed in the ndsd.log at this point indicating Cache Reader rollback. Read and send continues until the Reader offset matches the Writer offset. This procedure sends all Cached data to the Syslog server. After this process completes, no further update happens to the Cache file as events will be sent directly to the Syslog server.
NOTE:Since rollover does not happen in Infinite growth mode, the Cache file gets truncated after all Cached events are sent to the Syslog server. All offsets will also be reset once the truncation of the Cache file completes.
You can configure CEF to log events in the following categories:
Security
Objects
Attributes
LDAP
EBA
You can audit the following default set of event types:
|
Category |
Event Type |
|---|---|
|
Security |
|
|
Objects |
|
|
Attributes |
|
|
LDAP |
|
|
EBA |
|
NOTE:The event Modify LDAP Server Configuration is published when the LDAP server is refreshed through an LDAP client request.
For more information about using collectors for collecting CEF events, see the eDirectory Collector documentation at the Sentinel Plug-ins page .
Using filters and event notifications, CEF is capable of reporting when a specific type of event occurs, or when it does not occur. You can also filter events for one or more specific object classes or attributes, depending on the event type. CEF evaluates all the generated events against the configured filters on the eDirectory server and logs only the events matching to those filters.
This section provides the information you need to configure your system filters and notifications.
You can configure filtering for Objects to look for only a specific event or events. For example, if you want to be notified when someone creates a user account in eDirectory, you can create a filter selecting the User Object class to log events for creating a new user object.
To configure accounts filtering, click the Object Events link, select the class, and then click OK to exit the application.
To configure filters for Account Management events:
In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.
Select the NCP Server you want to monitor, and then click OK.
Click Object Events.
The CEF Object Filtering window appears.
In the Available Classes list, select any object class, then click the right arrow to move the object class to the Selected Classes list, and then click OK. By default Computer object class is selected.
Using the configured filter, CEF audit module checks all generated events for the selected object classes and attributes and logs those events.
Click the Attribute Events link to configure filtering for the Attribute Events. For example, if you want to be notified when someone adds a new attribute value in eDirectory, you can create a filter to log events for adding a new value.
To configure filtering for Trust Management Events:
In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.
Select the NCP Server you want to monitor, and then click OK.
Click Attribute Events.
The Attribute Filtering window appears.
In the Available Classes list, select object classes for which you want to collect events, then click the right arrow to move them to the Selected Classes list. By default dynamicGroup, dynamicGroupAux, Group, LDAP Group and Organizational Role object classes are selected
In the Available Attributes(s) list, select any number of attributes for the selected object classes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.
NOTE:If you select an object class, then all the Attribute Events for all attributes on that object class are selected. In this case, you will get all the Attribute Events for the all attributes on the selected object classes.
Click OK.
With the filter configured, CEF audit module checks the generated events for all the selected object classes and attributes and logs those events.
Click the Exclusion Filter link to configure filtering for those object classes and attributes for which you do not want an event to be generated. You can select object classes and attributes.
To configure filtering for unwanted eDirectory Events:
In iManager, navigate to Roles and Tasks > eDirectory Auditing > Audit Configuration.
Select the NCP Server you want to monitor, and then click OK.
Click Exclusion Filter.
The CEF Exclusion Filtering window appears.
In the Available Classes list, select object classes for which you do not want to collect events, then click the right arrow to move them to the Selected Classes list.
In the Available Attributes(s) list, select any number of attributes. Select the attribute and click the right arrow to add the attribute to the selected list of attributes.
Click OK.
Using the configured filter, CEF audit module stops generating events for all the selected object classes and attributes.
This document defines the CEF protocol and provides details on how to implement the standard. It details the header and predefined extensions used within the standard.
CEF uses syslog as a transport mechanism. It uses the following format, comprised of a syslog prefix, a header and an extension, as shown below:
Jan 18 11:07:53 host CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]
The CEF:Version portion of the message is a mandatory header. The remainder of the message is formatted using fields delimited by a pipe ("|") character. All of these remaining fields should be present and are defined under CEF Field Definitions.
The extension portion of the message is a placeholder for additional fields, but is not mandatory. Any additional fields are logged as key-value pairs. For more information, see CEF Field Definitions.
These fields in the schema are the CEF fields defined specifically for audit events. Some or all of these fields may also be relevant to other types of event, but information of this sort is required for auditing services.
Table 23-6 CEF Field Definitions
|
CEF Field |
Description |
|---|---|
|
Device Product |
Device Product is a string that uniquely identifies the sending device. Two products cannot have the same device-product pair. The administrator must ensure to assign unique name to every device-product pair. |
|
Device Version |
Device Version is a string that uniquely identifies the sending device. Two products cannot have the same device-version pair. The administrator must ensure to assign unique name to every device-version pair. |
|
Device Vendor |
Device Vendor is a string that uniquely identifies the sending device. Two products cannot have the same device-vendor pair. The administrator must ensure to assign unique name to every device-vendor pair. |
|
Device Event Class ID |
Device Event Class ID is a unique identifier per event-type. This can be a string or an integer. Device Event Class ID identifies the type of event reported. In the intrusion detection system (IDS) world, each signature or rule that detects certain activity has a unique Device Event Class ID assigned. This is a requirement for other types of devices as well, and helps correlation engines process the events. This is also known as Signature ID. |
|
Severity |
This is a string or integer and reflects the importance of the event. The valid string values are Unknown, Low, Medium, High, and Very-High. The valid integer values are 0-3=Low, 4-6=Medium, 7-8=High, and 9-10=Very-High. From eDirectory 9.2 SP2 onwards, the following mapping of values and integers are followed:
|
|
Version |
This is an integer and identifies the version of the CEF format. Event consumers use this information to determine what the following fields represent. The current CEF version is 0. |
|
Device Address |
Identifies the device address that an event refers to in an IP network. The format is an IPv4 address. |
|
c6a1 |
One of four IPV6 address fields available to map fields that do not apply to any other in this dictionary. |
|
dvchost |
The format should be a fully qualified domain name associated with the device node, when a node is available. For example, host.domain.com or host. |
|
rt |
The time at which the event related to the activity was received. The format is MMM dd yyyy HH:mm:ss or milliseconds since epoch. |
|
dtz |
The timezone for the device generating the event.. |
|
sourceServiceName |
The service which is responsible for generating this event. |
|
sproc |
The name of the event's source process. |
|
src |
Identifies the source that an event refers to in an IP network. The format is an IPv4 address. For example, 192.168.10.1. |
|
spt |
This is the source port number. The valid port numbers are 0 to 65535. |
|
shost |
Identifies the source that an event refers to in an IP network. The format should be a fully qualified domain name associated with the source node, when a node is available. For example, Examples: host.domain.com or host. |
|
suser |
Identifies the source user by name. Email addresses are also mapped into the UserName fields. The sender is a candidate to put into sourceUserName. |
|
dst |
Identifies the destination address that the event refers to in an IP network. The format is an IPv4 address. For example, 192.168.10.1. |
|
duser |
Identifies the destination user by name. This is the user associated with the event's destination. Email addresses are often mapped into the UserName fields. The recipient is a candidate to put into destinationUserName. |
|
cn1 |
One of three number fields available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomNumber1. |
|
cn2 |
One of three number fields available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomNumber2. |
|
cn3 |
One of three number fields available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomNumber3. |
|
cn1Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomNumber1Label. |
|
cn2Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomNumber2Label. |
|
cn3Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomNumber3Label |
|
cs1 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString1. |
|
cs2 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString2. |
|
cs3 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString3. |
|
cs4 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString4. |
|
cs5 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString5. |
|
cs6 |
One of six strings available to map fields that do not apply to any other in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. Also known as deviceCustomString6. |
|
cs1Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString1Label. |
|
cs2Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString2Label. |
|
cs3Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString3Label. |
|
cs4Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString4Label. |
|
cs5Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString5Label. |
|
cs6Label |
All custom fields have a corresponding label field where the field itself can be described. Each of the fields is a string describing the purpose of this field. Also known as deviceCustomString6Label. |
|
flexString1 |
One of two string fields available to map String data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary. |
|
flexString2 |
One of two string fields available to map String data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary. |
|
flexString1Label |
One of two string fields available to map String data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary. |
|
flexString2Label |
One of two string fields available to map String data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary. |
|
flexNumber1 |
One of two number fields available to map Long data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary |
|
flexNumber2 |
One of two number fields available to map Long data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary |
|
flexNumber1Label |
One of two number fields available to map Long data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary |
|
flexNumber2Label |
One of two number fields available to map Long data that does not apply to any other field in this dictionary. Use sparingly and seek a more specific, dictionary supplied field when possible. These fields are typically reserved for customer use and should not be set by vendors unless necessary |
|
cat |
Represents the category assigned by the originating device. Devices oftentimes use their own categorization schema to classify events. Also known as deviceEventCategory. For example, /Monitor/Disk/Read. |
|
reason |
The reason for which an audit event was generated. For example Bad password or Unknown User. This could also be an error or return code. |
|
outcome |
Displays the outcome, usually as success or failure. Also known as eventOutcome. |
|
msg |
Description of the event |
An example event is given below:
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
For more information about CEF events, see Section I.0, Mapping eDirectory Events with CEF Events.