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, such as FTP and Telnet, OS/400 (i5/OS) 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 TCP/IP DDM server that can share data files on a record-by-record basis with a client; the iSeries NetServer that allows files in the IFS to be directly accessed from desktop applications; the Remote Execution server that allows a desktop system to issue OS commands directly from the desktop; and so on. The list is quite comprehensive and many System i managers are not even aware of all of the possibilities.
My first recommendation for you is to educate yourselves about the doors that are there. Play around with iSeries Navigator and Management Central on your system to see all of the server settings and whether or not they are running on your system.To do this, open iSeries Navigator for your system and theN open 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" and "iSeries Access". 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 (these are each 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. 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, email me at email@example.com. All email messages will be answered.
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
This was first published in October 2006