By Rich Loeber
With more and more people working remotely, controlling remote access to your IBM i from 5250 terminal session users is more important than ever. More IBM i shops are opening their systems up to remote access and a terminal session exposes your system to potential abuse.
A good way to control terminal access is by authorizing the remote IP address before allowing a terminal session to connect. This way, you can control what specific IP address or address range can connect. This kind of control can be established on your system using an exit point for the Telnet Device Initialization point. Implementing this control will let you create your own exit program to validate the incoming IP address before allowing the Telnet server on your system establish the connection. Kisco's SafeNet/i Exit Point solution delivers this capability.
But, there is a small problem with this approach. The problem is that at the point at which the IBM Telnet Device Initialization exit calls your program, the only user profile available is QSYS. All Telnet connections run under the QSYS user profile. As a result, all exit point controls will be applied for all users, not on a user-by-user basis.
To implement source IP access controls by user profile, a much preferred method, you will need to create an initial program that can be recorded for each user profile that you want to control. This is recorded in the INLPGM parameter for each user profile. In your initial program, you can then access the source IP address that the user is connecting from and then do your own validation taking the actual signon user profile into account.
In your initial program, you can access the user profile signing on by a simple RTVJOBA CL command. Finding out the IP address that is being used is a bit more complicated, but not all that difficult.
For this, you will need to code a call to IBM's QUSRJOBI application program interface (API). Specifically, you will need to use the call format JOBI0600. This will retrieve a set of job information for the terminal session that includes the IP address for the user that is connecting. It will be in position 308 of the receiver variable specified for the API. If you're already familiar with using IBM API's, this is a fairly easy process. If you're new to API's, then prepare for somewhat of a learning curve.
Once you have the combination of user profile and IP address, then it is just a matter of validating the combination against a control database that you can set up for this purpose.
You will find yourself wanting to check a range of IP numbers for validation purposes. For example, you might want to specify that all IP addresses from 10.1.1.2 to 10.1.1.10 are legitimate. Depending on the range of numbers, this can be problematic. If you do a direct range comparison on the previous example, the range will not validate. When we set this up here, we converted the IP address into a standardized 12 digit number. For example, 10.1.1.10 ends up being stored at 010 001 001 010 (without the spaces). This gives you a good base for doing a range check and not having to worry about the effect of the periods and different individual ranges.
Once you have your initial program created and fully tested, you can then implement it by recording the program name and library in the INLPGM for each user profile where you want this control added. Since your initial program will always run when that user signs on to your system, we recommend that you throughly test your solution before locking down user profiles. You don't want to leave yourself in a place where you cannot sign in to your system.
If this looks like a little too much work for you, Kisco Information Systems has recently implemented this idea in is i2Pass 2FA Solution for the IBM i. It is available for a free trial if you'd like to examine it and it adds Two Factor Authentication to your 5250 terminal session controls as another layer of protection. An added benefit is that the software is supported in case you run into problems.
If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.