Tracking Remote Access Users On Your IBM i

By Rich Loeber

In the IBM i world, it has always been possible to track access to the system by user profile. It is just a simple matter of activating and configuring the system audit journal and sitting back to wait for some information to be accumulated. Then, using the DSPJRN judiciously, you can get a list of who signed on to your system and when they did so.

This was all well and good when your normal method of system access was through a green screen terminal, either hard wired or using a terminal emulator like IBM i Access. But, in this day of network connections through TCP/IP server functions in the OS, the model doesn't work well. Users can log into your system using FTP or IBM i Access with little or no trace left in your security journal that they were even there.

In certain cases, an audit journal record for "Process user profile swap" is left (a type PS record in the journal). I have seen this happen on a logon from IBM i Access using the TCP Signon Server. Apparently, after a successful logon, IBM i Access does a user profile swap to the QUSER profile and this gets logged in the journal. So, you could scan the journal for PS records and get some information about which user profiles are establishing network connections using this method.

You can also see some indication about remote users connecting to your system using IBM i Access (and similar clients) from the System History Log. If you run the DSPLOG command, you can scan for the CPIAD09 message. You can do this using the following command form:

DSPLOG PERIOD((*AVAIL *BEGIN)) MSGID(CPIAD09)

This will show you some evidence of remote logon activity too.

But these are just a drop in the bucket compared to everything that can go on within your system "under the covers". For example, if someone attempts to sign on to your system via FTP using a user profile that doesn't even exist on your system, you will never even know about it even though you are journaling all security events. Since this is a popular method that hackers use to try and break into your system, it would be nice to know when such attempts are being made.

When IBM opened up the system to TCP/IP connectivity, their solution to this issue was, and still is, to provide exit points in the OS. For each of these servers (such as FTP, Telnet, SQL, TCP Signon and many more), the OS lets you create your own program to monitor network activity and even control access to it.

The problem with this approach is that it is entirely passive. The OS is shipped with no exit program in place and the fact that exit points even exist is still not widely known. In the mean time, all sorts of nefarious system connection activity can be going on and you, as security officer would never know it. My company sells an exit point solution for the IBM i called SafeNet/i and the most common comment that we get from new customers who are just starting to use our product is that they had no idea so much activity was going on via network server connections.

Another problem with this approach is that coding and maintaining your own exit point solution is a daunting task. Over the life of these exit points (they've been around for more than a dozen years now), some of the exit point data streams have changed significantly. To IBM's credit, they have left the old data stream in place and created a new exit point for the enhanced version, but you have to re-code your application to take advantage of the improvements when they are made.

The best solution is for you to lay out some money and purchase a good exit point solution. There are a lot to choose from in the System i marketplace today including our SafeNet/i. The maintenance problem then becomes your software vendor's headache, not yours. And, most solutions cover all of the exit points available so that you're fully protected. These exit point solutions give you control over which user profiles can access your system, in many cases, what objects they can work with and what source IP addresses they can connect from. And, all network activity can be logged so that you can finally see everything that is going on "under the covers".

If you have any questions about this topic, you can reach me at rich at kisco.com, I'll give it my best shot. All email messages will be answered.