Today’s blog post provides a practical example for using IBM i exit point programming to control i server access. We’ll review the basics of how IBM i exit point programming works, show an example of how to use exit points to allow or reject i server access, and compare using exit point programming versus using a third-party IBM i exit point manager such as iSecurity Firewall.
What are IBM i Exit Points and Exit Programs?
An IBM i exit point is a specific point in an i OS function or program where control can be passed to one or more exit programs that provide additional processing capabilities for system functions.
There are hundreds of IBM i exit points available for customer use. Exit points provide firewall-like capabilities to customize, limit and modify IBM i requests. As shown in figure 1, exit programs attached to exit points can impose extra security restrictions on Telnet, ODBC, SQL, FTP or other operating system functions beyond what’s natively provided with IBM i.
With exit point programming, native i operating system requests can be examined, approved, modified, or extended according to organizational needs, enabling additional security and access requirements.
See SEA’s Guide to Managing IBM i Security with Exit Points for more information on using IBM i exit points and exit programs to extend operating system functionality.
An exit point processing example
It’s easier to understand IBM i exit point processing by looking at an example. Let’s look at adding a user-written exit program to the FTP login exit point. When a user starts an FTP session, FTP sends the login request to all associated exit programs via its exit point.
This exit program will identify whether that user can FTP to the system or whether additional limitations should be imposed. If the login request is denied, the exit program will signal FTP to stop the user login and the IBM i FTP server will deny user access.
The exit point name for FTP server application request validation is QIBM_QTMF_SVR_LOGON. As shown in figure 2, exit point names can be found on the IBM i API Finder page, by viewing the All exit programs groups and searching for the specific exit point function you want to attach a new exit program to.
Exit programs attached to the QIBM_QTMF_SVR_LOGON exit point will analyze incoming FTP server requests and tell the operating system whether to allow or reject the requested operation. To do that, QIBM_QTMF_SVR_LOGON passes login information between the operating system and any associated exit programs by using the TCPL0100 exit point interface, which designates what parameters will be passed to our exit program. Parameters are designated as input or output parameters.
Exit point parameters can be found in the API finder entry for their associated exit point. Figure 3 shows the parameter format for the TCPL0100 exit point interface.
Knowing this information, we can perform the following steps to create and attach a custom-written exit program for FTP server login approval:
1. Create and test an exit point program called FTP_approve in any language supported under IBM I (RPG, CLP, C, Java, etc.). FTP_approve should analyze its TCPL0100 input parameters including the User Identifier making the request (parameter 2), the Authentication string such as a password (parameter 3), and the Client IP address where the session originated (parameter 6). Based on its’ analysis of an incoming FTP request, FTP_approve should place one of the following values in the Return code output field (parameter 8) and set other output parameters to let the exit point know how to process the incoming FTP logon operation.
‘0’ = Reject the login operation
‘1’ = Continue the login operation with the input User identifier (parameter 2), Authentication string (parameter 4), and the user’s current initial library. The User profile (parameter 9), Password (parameter 10), and Initial current library (parameter 11) output fields are all ignored with this return code.
‘2’= Continue the login operation with the input User identifier (parameter 2), and Authentication string (parameter 4). Override the FTP session’s initial current library with the library specified in the Initial current library (parameter 11) output field.
‘3’= Continue the login operation and override the FTP session user profile name, password, and initial current library with the values in the User profile (parameter 9), Password (parameter 10), and Initial current library (parameter 11) output fields.
2. Attach FTP_approve to the QIBM_QTMF_SVR_LOGON exit point using option 8=Work with exit programs from the Work with Registration Information (WRKREGINF) command (figure 4). After attachment, every time a user performs an FTP logon operation, the FTP server logon exit program (FTP_approve) will determine whether the operation should be approved or rejected.
Exit Point Programming Versus Third-Party Exit Point Monitoring Solutions
As you create user-written exit programs, consider whether your exit point programming needs can be better met by using a third-party exit point monitoring solution such as iSecurity Firewall.
In general, third-party exit point monitoring solutions offer these benefits over creating your own exit programs.
1. Out-of-the-box exit point security, firewall and intrusion protection: Third-party solutions can manage authorized user access upon installation.
2. IBM i-based firewall, intrusion prevention system (IPS) and exit point capabilities are immediately available for monitoring and controlling system activity: With user-written exit programs, new capabilities for these functions must be designed, coded, tested and deployed from scratch.
3. Established & supported solutions, enhanced over time: Third-party exit point security solutions have been developed, established and hardened over several years. They include software support, upgrades & fixes. Solutions are usually enhanced over time, providing new capabilities on a regular basis.
4. Established third-party exit point solutions may be preferred by enterprise security personnel over user-written programs. User-written security-related exit programs may not be immediately hardened upon deployment and need to be supported internally for new versions, application errors and fixes. New exit point programs may never have been deployed in a live environment and may be more vulnerable to failure or cyberattacks.
5. Frees up application resources for line-of-business processing: With third-party solutions, administrative & security personnel configure exit point, firewall & IPS processing, freeing up busy application talent to work online-of-business solutions. Applications staff must code, test and deploy user-written exit programs.
6. Advanced security reporting: Third-party solutions offer much more comprehensive and audit-ready reporting solutions than are available with user-written exit programs. Native IBM i exit point reporting options are more limited.
7. Simulation testing before going live: Third-party solutions often offer simulation mode, where exit point & firewall capabilities can be tested without implementation before going live. Similar capabilities must be custom coded in user-written exit programs.
