ADC

Audit logging

May 23, 2024

Contributed by:

C S

Important

We recommend you to update a SYSLOG or NSLOG configuration only during maintenance or downtime. If you update a configuration after creating a session, the changes are not applied to the existing session logs.

Auditing is a methodical examination or review of a condition or situation. The audit logging feature enables you to log NetScaler states and status information collected by various modules. The log information can be in the kernel and in the user-level daemons.

You can configure NetScaler to store the log information locally on NetScaler or export it to a remote server or both.

Local logging

Local logging refers to the process of storing the event data generated by NetScaler such as, errors, warnings, and system events, locally within NetScaler. This data can be used for monitoring and troubleshooting, auditing, and security analysis.

By default, NetScaler saves its logs locally in NetScaler persistent storage using the UDP protocol. The logs are stored in the ns.log file under the /var/log/ folder. Since local logging is enabled by default, you don’t need to perform any additional configurations to store the logs.

Local logging provides the following advantages:

Accessibility: You can access the logs even if there are network issues. The logs can be accessed quickly because they are not dependent on network connections.
Security: The sensitive or confidential data remains within NetScaler and therefore reduces the risk of unauthorised access.
Compliance: Many regulatory requirements mandate the retention of log data for a certain period. So, by storing logs locally NetScaler ensures that it is compliant.

By default, all log levels are enabled except DEBUG. However, you can adjust the levels of logs stored in the ns.log file.

Warning

If you configure local logging for many features or set log level to store less severe logs, then the stability and performance of NetScaler might be impacted. We strongly recommend to avoid using local logging extensively. Instead, use remote logging if verbose logging is required.

To modify the default log setting, use the following command:

set syslogparams -acl ( ENABLED | DISABLED )
        -alg ( ENABLED | DISABLED )
        -appflowExport ( ENABLED | DISABLED )
        -ContentInspectionLog ( ENABLED | DISABLED )
        -dateFormat <dateFormat>
        -dns ( ENABLED | DISABLED )
        -logFacility <logFacility>
        -logLevel <logLevel> ...
        -lsn ( ENABLED | DISABLED )
        -serverIP <ip_addr|ipv6_addr|*>
        -serverPort <port>
        -sslInterception ( ENABLED | DISABLED )
        -subscriberLog ( ENABLED | DISABLED )
        -tcp ( NONE | ALL )
        -timeZone ( GMT_TIME | LOCAL_TIME )
        -urlFiltering ( ENABLED | DISABLED )
        -userDefinedAuditlog ( YES | NO )
<!--NeedCopy-->

Local logging has the following disadvantages:

Performance impact - Logging activities can consume system resources that can potentially impact the performance and stability of NetScaler.
Storage: NetScaler can store only a limited amount of log data since the local storage capacity is low compared to centralized storage.
Scalability - Not suitable for large-scale deployments. In large-scale deployments, centralized logging solutions are preferred for easier management and scalability.
- Compliance challenges in large scale deployments - Many industries have regulations and compliance requirements regarding log management and retention. Managing compliance becomes more complex when logs are stored locally, as it requires ensuring that each device adheres to the necessary standards.
Accessibility in large scale network - Accessing logs stored locally on NetScaler might require direct access to the device. This becomes inconvenient in large networks because accessing logs from multiple devices that are distributed across a network is cumbersome.
Single point of failure - If there is a hardware malfunction, any logs stored locally becomes inaccessible. This creates a single point of failure for logging data, potentially leading to loss of valuable information.

Remote logging

NetScaler allows you to store the log information on an external server. You can configure NetScaler to export the logs to the external server using UDP or TCP. Depending on your requirements, you can either store the log information locally or export it to an external server, or both. For detailed information on remote logging and how to configure remote logging, see Configuring NetScaler for audit logging.

SYSLOG and NSLOG

For audit logging, you can use the SYSLOG protocol, the native NSLOG protocol, or both.

SYSLOG is a standard protocol for logging. It has two components:

SYSLOG auditing module: Runs on NetScaler.
SYSLOG server: Runs on the underlying FreeBSD operating system (OS) of NetScaler or on a remote system.

SYSLOG uses a user data protocol (UDP) for data transfer.

Similarly, the native NSLOG protocol has two components:

NSLOG auditing module: Runs on NetScaler.
NSLOG server: Runs on the underlying FreeBSD OS of NetScaler or on a remote system.

NSLOG uses TCP for data transfer.

When you run a SYSLOG or NSLOG server, it connects to NetScaler. NetScaler then starts sending all the log information to the SYSLOG or NSLOG server. And the server filters the log entries before storing them in a log file. An NSLOG or SYSLOG server receives log information from more than one NetScaler. NetScaler sends log information to more than one SYSLOG server or NSLOG server.

If multiple SYSLOG servers are configured, NetScaler sends its SYSLOG events and messages to all the configured external log servers. It results in storing redundant messages and makes monitoring difficult for system administrators. To address this issue, NetScaler offers load balancing algorithms. NetScaler can load balance the SYSLOG messages among the external log servers for better maintenance and performance. The supported load balancing algorithms include RoundRobin, LeastBandwidth, CustomLoad, LeastPackets, and AuditlogHash.

Note

NetScaler can send audit log messages up to 16 KB to an external SYSLOG server.

The log information that a SYSLOG or NSLOG server collects from a NetScaler is stored in a log file in the form of messages. These messages typically contain the following information:

The IP address of NetScaler that generated the log message.
A time stamp
The message type
The predefined log levels (Critical, Error, Notice, Warning, Informational, Debug, Alert, and Emergency)
The message information

To configure audit logging, you first configure the audit modules on NetScaler. NetScaler involves creating audit policies and specifying the NSLOG server or SYSLOG server information. You then install and configure the SYSLOG or the NSLOG server on the underlying FreeBSD OS of NetScaler or on a remote system.

Note

SYSLOG is an industry standard for logging program messages, and various vendors provide support. The documentation does not include SYSLOG server configuration information.

The NSLOG server has its own configuration file (auditlog.conf). You can customize logging on the NSLOG server system by making extra modifications to the configuration file (auditlog.conf).

Note

ICMP access to SYSLOG server is mandatory if SYSLOG server is used as FQDN under SYSLOG Action in the network. If ICMP access is blocked in the environment, configure it as load balanced SYSLOG server and set the value of the healthMonitor parameter in the set service command to NO. For configuring ICMP, see Load balancing SYSLOG servers

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

Audit logging

May 23, 2024

Contributed by:

C S

May 23, 2024

Contributed by:

C S

Audit logging

Local logging

Remote logging

SYSLOG and NSLOG

In this article