Are All Of Your IBM i Doors Open? - Part 2

By Rich Loeber

In my last tip, I pondered the need to watch the doors into your system. In the old days, there was a single door in the form of a display terminal. Today, that is only one of many doors where users can get into your system. While most users are trustworthy, there is always the opportunity for inadvertent damage to your data from someone who happens to get into your system through a door that should be closed to them. Then, there are always those lurking in the shadows who are just looking for an unlocked door to gain access and wreak havoc in the process.

Last time, I talked about the most obvious doors and the most obvious solutions for those situations. This week, we'll take a closer look at the less obvious doors and how you can deal with them.

In addition to the obvious doors to your system like FTP and Telnet, IBM i has a variety of server functions included that provide network access points for a wide variety of host-client connectivity. These includes the likes of a DRDA DDM server that can share data files on a record-by-record basis with a client; the File Server that allows files in the IFS to be directly accessed from desktop applications; the Remote Command server that allows a desktop system to issue IBM i commands directly from the desktop; and so on. The list is quite comprehensive and many IBM i managers are not even aware of all of the possibilities.

So, my first recommendation for you out there is to educate yourselves about the doors that are there. Play around with IBM Navigator For i (Navigator) on your system to see all of the server settings and whether or not they are running on your system.

To use Navigator (a component of IBM i Access Client Solutions [ACS]), it must be installed on your PC with all components. Then, the Admin HTTP server must be active on your IBM i. It runs in the QHTTPSVR subsystem and, if active, will show multiple jobs with names that start with ADMIN. If you need to start the admin server, the command is:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

You start Navigator from ACS. It will start a session in your browser and you will need to sign on with a user profile with security officer permission. From your browser, select the "Network" tab. This will present you with a short list of new tabs, open the "Servers" tab next. To see what servers are actually up and running on your system, look at the tabs marked "TCP/IP Servers" and "IBM i Access Servers". These will each show you a list of server functions on your system with a brief description of the function being served and what its current status is on your system. It behooves you to know about all of those that are showing as started.

Once you have identified all of the server functions that are running (each is a door into your system), then you will need to validate its use on your system. Identify the application that is using it and check to make sure that security is in place to control what can be accessed through each of these doors. Also, make sure you know what user profiles are in use for each server function. If common user profiles are shared between different server functions, you could have a security risk due to contextual conflicts between uses. This kind of exposure can happen when an FTP user profile needs access to different data than an ODBC user. If the same profile is used in both contexts, you could end up with a security exposure. Also, remember that when you open a door for one application, it ends up remaining open for all of the profiles on your system. You need to have a plan in place to keep the wrong people away from doors that they should not be using.

In some instances, the only way you will be able to make sense out of what is going on will be to implement one or more exit point programs to allow you to see exactly what kind of network requests are happening. You can either write your own or get one of the several commercially available exit point solutions. I recommend SafeNet/i from Kisco Information Systems, my company. This will tell you which profiles are getting into your system through each door and what they are doing when they are in there. Without knowledge at this level, you're only guessing at what's going on. Guessing at activity does not promote good security policy implementation.

If you have specific questions about this topic, you can reach me at rich at kisco.com. All email messages will be answered.