By Rich Loeber
IBM i has included security exit points for adding protection for platforms that work with connected systems. These exit points have been included in the IBM i OS for years and have regularly expanded to provide for more and more network applications. Using the exit points, you can add protection for FTP, ODBC, File Server, Remote Command submissions and much more. This has gone a long way towards making the IBM i a truly secure platform.
For many years, however, there were a whole group of applications that could run under the radar on the IBM i and not get picked up by the existing exit point traps. These are socket level communication applications. The good news is that starting with IBM i 7.2, IBM has added three new exit points to address this issue.
The three exit points added let you control Socket Accepts, Socket Connects and Socket Listens. Applications that use socket connections can sometimes also use other network services, like FTP or remote commands, which existing exit points will cover; but some applications bypass all other network services and work directly with data at the socket level. Having control over socket connections is critical to having a secure environment on your IBM i.
The TCP Accept exit point watches for systems trying to establish a connection to your system at the socket level. Using the exit point, you can control which IP addresses to accept or reject, what user profiles to allow use and even control what TCP/IP port numbers that the connection can use.
The TCP Connect does the same thing as Accept except it is for outward connections from your IBM i system to remote systems. The same controls can be implemented controlling the IP address, user profile and port number.
The TCP Listen runs on your IBM i and watches for incoming TCP Connects from remote systems. A typical socket connection starts with a Listen and then proceeds on to the Connect with subsequent Accept. Following this sequence, socket communication can take place without any other network services being involved.
Some of the existing applications that run on the IBM i and use these socket connections include the Apache HTTP server which does not have any additional exit point control available. If you want to control who can use a browser on your system, this is a way to approach this issue.
Another area where this can help improve security on your system is by denying that initial contact with your system. By denying the initial contact, a potential hacker is denied information about the system they are attempting to connect with. For example, when you try to sign on to your system via FTP and before you even attempt to enter a user profile, the following is what you see for your FTP session:
This clearly identifies your system as IBM i by virtue of the reference to the QTCP user profile. A savvy hacker will know that and this information will inform their future attempts to gain access to your system. Many of the other TCP network services on the IBM i return this kind of identifying information in response to connection requests even when an invalid user profile is used.
When you implement socket level controls on your IBM i, you can deny access to all but approved IP addresses and port numbers. When you do this, then this is what that same FTP access attempt looks like to a hacker:
Denying this connection at the socket level stops the session before any information is sent back to the requester.
Adding implementation of the socket exit points on your system can help you achieve your security goals for the IBM i. The good news is that you don’t need to code your own solution if you don’t have the time or the talent. Kisco’s SafeNet/i software, in its recently announced Release 11 of the product, now includes general use implementations of all three of these exit points along with all other security exit points available in the IBM i OS.
If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.