Auditing Telnet server connections

Incoming connections to the Telnet server are audited with SK (Sockets Connections) journal entries when audit level *NETTELSVR is enabled for system value QAUDLVL or QAUDLVL2 audit levels. Telnet server socket connections are not audited with other socket connections when audit level *NETSCK is enabled.

Telnet client configuration and the number of clients that connect to the Telnet server contribute to the rate of audit record generation. Connections to the Telnet server can be high and result in corresponding high rates of journal receivers that fill up. Consider system configuration and resources before you enable socket connection auditing for the Telnet server. Telnet clients that are configured to retry immediately without any delay after error generate audit records as fast as the Telnet server can accept the incoming connections. The following conditions are some common cases where connections end in error after the connection is accepted:

The Telnet server is active but the QINTER subsystem is not
QAUTOVRT rejects connections because there are no available devices and it is not able to create new ones
The certificate that is assigned to the Telnet server expired, or was renewed and clients are still using the old certificate

To audit incoming connections to the Telnet server, enable audit level *NETTELSVR for system value QAUDLVL or QAUDLVL2. The audit value *NETTELSVR replaces the System Service Tools (SST) Advanced Analysis command IPCONFIG option skTelnetServerAudit used to configure auditing the Telnet server in releases before IBM® i 7.3. A successful Telnet connection produces an SK-A journal entry when the Telnet server successfully accepts an incoming connection. The SK-A journal entry contains IP address and port information for the incoming connection to the Telnet server.

If your server is configured for SSL/TLS, you can also audit secure connection attempts to the Telnet server by enabling audit levels *NETTELSVR and *NETSECURE. A successful secure handshake with the Telnet server creates SK-A and SK-S audit journal entries. The SK-S journal entry includes the IP address and port information for the socket connection and the SSL/TLS properties that are associated with the established secure session. If the secure handshake fails, SK-A and SK-X audit journal entries are created indicating a socket connection was accepted by the Telnet server, but the secure handshake attempt failed. An error code for the handshake failure is included in the SK-X audit journal entry.

When your Telnet server is configured to accept only secure Telnet server connections, you might not want to see the SK-A journal entries for the incoming connections since the SK-S and SK-X journal entries include the same connection information for the secure handshake. To limit auditing to secure socket connections, including secure Telnet server connections, enable audit level *NETSECURE for system value QAUDLVL or QAUDLVL2 and the System Service Tools (SST) Advanced Analysis command SSLCONFIG option netsecureTelnetServer. SSLCONFIG option -h displays the help panel that describes how to set the secure Telnet server connection auditing option.