One way to look at all connections is to use the Work with TCP/IP Network Status (WRKTCPSTS) command, aka NETSTAT. Choosing to look at the IPv4 and IPv6 connections will show you the established connections and which server they’re connected to. The server name will indicate whether the connection is secure, typically by adding either -s or -ssl to the end of the server name (e.g., Telnet-ssl). The port used is also an indication of whether the connection is secure. For example, if the Telnet session is using port 23, then it’s not secure. But if it’s coming in via port 992, the connection is encrypted. Here’s a list of the well-known ports:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
In addition, you’ll need the list of ports used by the ACS:
https://www.ibm.com/support/pages/tcpip-ports-required-ibm-i-access-and-related-functions
By analyzing the output of NETSTAT, you can determine whether there are currently any unsecured connections established to your IBM i. The problem with NETSTAT is that it’s a point in time; it’s accurate only for the time at which you ran the command. Other connections may be established in the middle of the night, for example.
To have a complete analysis of your connections, you’ll need to utilize the audit journal. You’ll need to add two values to the QAUDLVL system value: *NETTELSVR to audit Telnet connections and *NETSCK to get all other IP connections. (If you want to analyze UDP connections, you’ll need to add *NETUDP.) Once you’ve added these values, all connections will be logged. (Note that these values may generate a significant number of audit journal entries, so once your analysis is completed you may want to remove these additional values from QAUDLVL.)
To analyze the connections, you’ll need to gather the SK audit journal entries. The SK entries aren’t (yet) available as a service, so we’ll use CPYAUDJRNE to get the information:
There are many subtypes within the SK audit journal entry (for the full list, see the IBM i Security Reference manual, chapter 9), but the subtype we’re looking for is ‘A’, meaning that the connection has been accepted. So right away, I’m going to use the following SQL statement to filter the SK entries to just look for the accepted connections.
Even with this filter, you’re still likely to have a lot of entries. At this point, your next step depends on why you’re examining these entries. If you think you’ve gotten all connections secured, you may want to specifically look for connections coming in over unsecured ports. The following SQL lists the ports that the connections should be using; anything coming in over a different port will be listed. (Note: This is not a complete list of secure ports!)
If you are just starting out with this project, you’ll probably want to be more selective in the entries. For example, if you want to ensure all Telnet sessions are encrypted, you can use an SQL that will only include cleartext Telnet sessions (that is, connections coming in over port 23).
Now that you’ve selected the audit entries, how do you read/make sense of the information in the audit journal entry? For most audit journal entry types, I find the job name, user, and number helpful as well as the program and program library. But in this case, these fields are worthless. That’s because these entries are generated before the user’s job has started. See Figure 12.5.
Figure 12.5: SK entries are generated before the user’s job starts, so traditional fields are of little use.
Likewise, the User profile field that typically contains the name of the current user is also worthless in this audit journal entry as it will always contain the value *NONE. So what is helpful about this entry? You’ll want to focus on these two fields:
- SKLPRT: Local port
- SKRADR: Remote IP address
To decipher where the connection is coming from, you’ll have to do a reverse DNS lookup using the remote IP address. You may also find the timestamp (SKTSTP) field helpful if the connections are coming from remote servers and you have to look through scheduled jobs to find the incoming task.
Helpful Hints
As you start to play around with the SK entries, you may want to force a few entries to understand how to better read and understand what you’re seeing. (That’s what I always do when I start using an audit journal entry type that I’m not familiar with.) To force the entry, remember that SK entries log new connections; therefore, it’s not sufficient to simply log off your Telnet session and log back on. That will not generate an SK entry. You must close and reinitiate the session to get an SK entry generated.
Note that the *NETCMN value was reworked in IBM i 7.3 such that it no longer logs accepts and connects. If you have *NETCMN specified in QAUDLVL and think you’re going to get the audit journal entries I’ve been describing, you won’t. As I said earlier, you must specify *NETTELSVR and *NETSCK (and NETUDP if you want to analyze your UDP connections) in the QAUDLVL system value. It may take a bit of investigation, but analyzing the SK audit journal entries will help you know whether all connections are secure (encrypted) or not.