Use this parameter to define how many bytes of outgoing messages are written to the audit log when AUDITASCIIONLY is set to TRUE.
Parameter Syntax
AUDITASCIIDUMPLENIN number
Arguments
-1
means that each outgoing message will be dumped fully N
means that only the first N bytes of each outgoing message will be dumped
Default
By default, a value of -1 will be used
Considerations
See parameter AUDITASCIIONLY
AUDITCONSOLE
Use this parameter to define if and to what console device NSSL audit messages are written to.
Parameter Syntax
AUDITCONSOLE * | % | $0 | auditdevice
Arguments
*
means that no audit messages are written to a console %
means that audit messages are written to the home terminal of the NSSL process $0
audit messages are written to $0
auditdevice
audit messages are written the given device (e.g. $DEV.#SUBDEV)
Considerations
• Audit messages will depend on the run mode – see parameter AUDITLEVEL for details.
Default
By default, audit messages will be not be written to a device ("*")
See also:
AUDITFILE, AUDITLEVEL, AUDITFORMAT
AUDITFILE
Use this parameter to define if and to what file NSSL audit messages are written to.
AUDITFILE * | file
Arguments
*
means that audit messages are written to a file
file
the name of the auditfile
Default
By default, no audit messages are written to a file ("*")
Considerations
• Audit messages will depend on the run mode – see parameter AUDITLEVEL for details
See also:
AUDITCONSOLE, AUDITLEVEL, AUDITFORMAT
AUDITFILERETENTION
Use this parameter to control how many audit files NSSL keeps when audit file rollover occurs.
Parameter Syntax
AUDITFILERETENTION n
Arguments
n
number of audit files to keep
Default
By default, 10 files are kept.
Considerations
• a minimum of 10 is enforced for that parameter
• See section “Logfile/Auditfile rollover using round robin” for details on logfile rollover.
See also:
AUDITMAXFILELENGTH, AUDITFILE
AUDITFORMAT
Use this parameter to control the format of audit messages that are written to the console or audit file.
Parameter Syntax
AUDITFORMAT format
Arguments
a number representing a bit mask controlling the format options. Please see parameter LOGFORMAT for the bit mask.
Default
The default log format is 93 (date, time, milliseconds, process ID and log level)
Example
Display date, time, milliseconds only: AUDITFORMAT 13
Display date, time only: AUDITFORMAT 5
Considerations
• Audit messages will depend on the run mode – see parameter AUDITLEVEL for details
See also:
AUDITCONSOLE, AUDITFILE, AUDITLEVEL
AUDITLEVEL
Use this parameter to control what audit messages are written to the audit console or file.
Parameter Syntax
AUDITLEVEL detail
Arguments
detail
a number representing the detail level
Default
The default audit level is 50
Considerations Considerations
• Audit messages are written only for the following run modes: PROXYS,PROXYC,PROXY,MQS,MQC,ODBCMXS, FTPS.
• The following table describes how to set AUDITLEVEL for the various run modes.
Audit Level Run Modes PROXYS,PROXYC,PROXY,MQS,MQC,O DBCMXS Run Mode FTPS 10 Startup of NSSL Startup of NSSL 30 Logon of user
50 Network events (connect, disconnect) FTP operations
60 Network events
80 Data flowing through NSSL: byte count only 90 Data flowing through NSSL: full byte dump
(see parameter AUDITASCIIONLY for details)
• For PROXYS,PROXYC,PROXY,MQS,MQC,ODBCMXS we recommend 50 for basic auditing and 99 for extended auditing including full traffic log.
Note: If set to 99, all data flowing through the network is dumped to the audit log. This could include confidential data or passwords so make sure to properly secure the audit log files.
• For FTPS mode, we recommend 50 for normal auditing
See also:
AUDITCONSOLE, AUDITFILE, AUDITFORMAT
AUDITMAXFILELENGTH
Use this parameter to control the maximum size of the audit file.
Parameter Syntax
AUDITMAXFILELENGTH length
Arguments
length
a number representing the maximum audit file length in kilobytes. Max. 40.000 or 40 MB
Min 100
Default
The default length is 20 000 KB.
Considerations
• After the current audit file reaches the maximum size a log rollover will occur. The current audit file will be renamed by replacing the last character with a "2". A new file with the AUDITFILE name will be created for subsequent audit output.
See also:
AUDITFILE, AUDITLEVEL
CACERTS
Use this parameter to specify a certificate chain validating the server or client certificate given by the SERVCERT or CLIENTCERT parameter.
Parameter Syntax
CACERTS file1 [, file2, ...]
Arguments
file1, file2, ...
Default
If omitted, NSSL will search for a single "CACERT" file on the default subvolume.
Example
CACERTS $DATA1.NSSL.MYCA
Considerations
• The first file on the list must contain a certificate signing the given server certificate. Subsequent files must contain certificates that sign the previous certificate in the list.
• During SSL handshake, the certificate chain will be sent along with the client or server certificate to the SSL communication partner
• If a value of * is used for CACERTS, it will be assumed that the client or server certificate is self-signed.
• A CA certificate for testing purposes is delivered as CACERT file on the NSSL installation subvolume to enable quick start installation. This test CA certificate signs the test server certificate contained in SERVCERT or CLIENTCERT.
See also:
SERVCERT, CLIENTCERT
CIPHERSUITES
Use this parameter to specify which cipher suites are admissible for an NSSL secure server.
Parameter Syntax
CIPHERSUITES suite [, suite, ...]
Arguments
suite
specifies a cipher suite. Currently the following cipher suites are supported by NSSL: o 0.1: RSA-key-exchange + NO ENCRYPTION and MD5 hash o 0.2: RSA-key-exchange + NO ENCRYPTION and SHA1
hash
o 0.4: RSA-key-exchange + RC4-128-bit encryption and MD5 (RC4-MD5)
o 0.5: RSA-key-exchange + RC4-128-bit encryption and SHA (RC4-SHA)
o 0.10: RSA-key-exchange + 3-DES encryption and SHA (DES-CBC3-SHA)
o 0.47: RSA-key-exchange + 128-bit AES encryption and SHA (AES128-SHA)
o 0.55: RSA-key-exchange + 256-bit AES encryption and SHA (AES256-SHA)
If omitted, NSSL will use 0.4, 0.10, 0.5 as accepted cipher suites.
Considerations
• During the SSL handshake the SSL client will send a list of cipher suites that it supports. If you allow multiple cipher suites, NSSL will select the first one from the list that matches a browser-supported cipher suite.
Example
CIPHERSUITES 0.5, 0.10
Note: The cipher suites 0.1 and 0.2 will NOT encrypt the traffic, they will only authenticate the partners and provide message integrity checking. Please only use if encryption is not required.