These days, there is almost nowhere you can go on the planet where it is technically difficult to establish an...
internet connection and get beyond your current location. We've all experienced this, especially with demands made on us during business trips and other travel. 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, there are circumstances in which it is of huge benefit. This seamless connectivity allows people who are spread out all over the world to easily collaborate on projects as if they were in adjoining rooms. It also lets you to work from home even if it is a long distance from your physical office. This gives you new options in choosing where to live. 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.
Internet connectivity increases risk
The thing that makes all this possible is the Internet and remote access technology. But, as you think about it, while you have remote access to off-site computing resources, so does anyone else who is connected to the Internet. That is a huge security exposure to your IBM 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 virtual private network (VPN) solutions 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.
Protecting the IBM i from unwanted remote visitors
The examples above 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, iSeries 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 over 10 years now, system exit points. The OS on your AS/400 services each of these remote access requests through 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 if it should 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.
For example, a typical exit point program application might attach 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.
To give your System 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 firstname.lastname@example.org, I'll give it my best shot. All email messages will be answered.