Controlling Remote Access to your IBM i

By Rich Loeber

These days, there is almost nowhere you can go on the planet where it is technically difficult to establish and internet connection and get beyond your current location.  We’ve all experienced this, especially with demands made on us during vacation trips and other travel requirements.  It seems like we’re always expected to be on call and available to react to issues back in the office.

While this sounds intrusive of our time, there are other situations where it is a huge benefit.  It allows people who are spread out all over the world to easily collaborate on projects just like they are in adjoining rooms.  It also lets you telecommute from home or even telecommute from a home office that is a long way from your physical office.  This gives you new options in choosing where to live, and it doesn’t always have to be near where you’re working.  It is just this kind of global connectivity that lets me live in a remote location in the Adirondack Mountains of northern New York and still be able to reach out to any potential customers on a worldwide basis.

The thing that makes all this possible is the Internet and remote access technology.  But, as you think about it, while you have access remotely to off site computing resources, so does anyone else who is connected to the Internet.  That is a huge security exposure to your IBM System i.  Even the much touted security on this exceptional system will have exposures.

Certainly, there are loads of infrastructure solutions that you can turn to.  There are no end of VPN (Virtual Private Network) solutions that you can implement that will create tunnels through the Internet to authenticate a connection, limit access and encrypt your data.  There are also firewalls you can implement that will limit traffic connections to your system.

But, these are all external to your IBM i.  What can you do, on your system, to protect yourself.  You need to be able to permit external access from users with legitimate needs but keep all others from doing the same.  There are so many different methods to establish remote access that you have to have a plan for each of them.  From simple FTP to Telnet, ODBC connections, IBM i Access connections, remote command submissions, file uploads and downloads, windows share drive connections and on and on.  The list is long and each one represents an exposure.

IBM has provided a good solution for this issue for more than 15 years now, system exit points.  The OS on your IBM i services each of these remote access requests through something called a Server Function.  FTP works through an FTP Server, Telnet through a Telnet Server, ODBC on most systems works through an SQL Server and so on.  Within the OS, IBM has implemented exit points in each of these server functions.

An exit point is a place in the OS where you can register a user written program to add processing that is not included in the OS.  The exit point passes a data stream that varies depending on the exit point, and your program sets a return code for the exit point in the OS to interpret.  The return code is typically a pass/fail code that lets the exit in the OS know whether or not to continue processing the remote access request.  Your program then examines the information in the data stream to determine if you want to allow or disallow the remote request.

A typical exit point program application might attach, for example, to the FTP server logon exit point and check the remote IP address of the FTP requester.  You can then easily compare this to a list of legitimate addresses that you have set up and then disallow remote access from any IP address that is not on your list.  Continuing with the FTP example, you can also create an exit program application for the FTP server point and then check the data stream to see which objects the FTP session is attempting to access on your system.  Again, you can compare these to a list of objects that the requesting user is trying access and the either accept for deny the request based on what you find.  You can even authenticate the user signed on to make sure that you have authorized them to even use FTP.

A word of caution is due at this point.  Programming for the exit point data stream is not for the faint of heart.  The documentation on certain exit points can be sketchy and testing can be problematic as it can easily interfere with normal operations on your system.  Fortunately, there are quite a few third party solutions available on the market today that are very good.  All that testing and figuring out of the data streams is done for you by programmers who have been wrestling with the issues for years.  I obviously recommend my company’s SafeNet/i as the best of the third party solutions currently available.

To give your IBM i the extra measure of control over remote access via network connections, the best solution is implementation of the exit point controls in the OS.

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.

Comments are closed.