For years, security officers and administrators have relied on menu security to protect their production data and to control their users activities. Most were under the impression that if their users were sequestered from a command line, they did not pose much of a security threat. If their users had been connected to the AS/400 by way of nonprogrammable workstations, there may be some credence to that mindset. However, in todays current environment, most users are connected from a PC using a 5250 emulation program. This type of connectivity now classifies those users as remote users. Herein lies a tremendous security exposure of which few are cognizant. Remote users typically have several avenues at their disposal that allow them to easily circumvent AS/400 menu security, ostensibly providing them with the ability to not only access and change data, but also to upload and download files and execute CL commands (even if LMTCPB = *YES in their user profiles!).
Menu security alone will not prohibit these activities, which is the problem I address in this piece. I also show you how exit programs can be used to provide an additional layer of security for your data. By the time youre finished reading this article, you should have at least a beginning understanding of the following:
What additional security exit programs offer
Where and how exit programs fit into the security hierarchy of the AS/400
How remote users commonly circumvent menu security
Before examining what exit programs are and what they do, you must first understand the different layers of protection that may be used to secure an AS/400. Your AS/400 data can be secured by different layers of security, as shown in Figure 1. Menu security is commonly used to control or limit the activities of users. The menu offers users a simple interface to the AS/400 and data. User activities are controlled by the various menu options offered to them. Menu users are not commonly provided with a command line. Exit program security can be implemented in the application layer to also dictate the activities of AS/400 users.
What Are Exit Programs and What Is Being Exited?
Exit programs are named as such because the operating system (OS/400) has points where it can exit the OS/400 code to invoke an installation-created program either before or after a request from a remote user is processed. These installation-created programs are called exit programs. Heres how the process works:
1. A remote user requests a transaction that will read or write data or execute a command on your system.
2. The OS recognizes the request then routes the request to the appropriate server (i.e., FTP, RMTSRV, ETC.).
3. If an exit program has been implemented, the server detects it, calls it, and passes along the requested transaction parameters.
4. The exit program analyzes the requested transaction to determine if it should be allowed or rejected. Then, the exit program sets a return code to allow or reject the request before returning control to the server.
5. The return code from the exit program instructs the server to process or reject the request. (Keep in mind that object layer, (object level) security is enforced independently of this process.)
The AS/400 Isnt Secure?
Without question, the AS/400 is one of the most stable and secure platforms on the planet. The object layer security can be virtually bulletproof, if implemented properly. However, few administrators have taken the time (or more accurately, have the time) for proper implementation. Many administrators have inherited poorly implemented security from a predecessor. Despite the powerful capabilities of the object layer security, inappropriate access to production data may still be exacerbated by users who:
Possess *ALLOBJ authority unnecessarily
Exploit excessive public authorities, such as *ALL or *PUBLIC
Belong to a group profile that possesses special or powerful authorities
Have authority granted to them by various applications
These users may connect remotely to exploit these authorities, even if they do not have access to a command line. In most instances, exit programs can be implemented to restrict the activities of these remote users.
Unauthorized Access
TCP/IP has become the predominant protocol in use today. It permits users to upload and download data, as well as execute remote commands without the restrictions inherent to the applications they commonly use. The DOS prompt on a personal computer can often be used as a command line. Lets take a quick look at how easy it can be to circumvent your menu security using one TCP/IP service: FTP (File Transfer Protocol).
From a PC connected via TCP/IP to your AS/400, open a DOS window. Next enter the following FTP commands, shown in lower case. (Ignore the text in parenthesis; its included for explanatory purposes only.)
C:>ftp AS400HostName (signon when prompted)
ftp>help (for command list)
remotehelp (provides a list of FTP commands on your AS/400)
cd libraryname (set the current directory on your AS/400)
dir (list files and objects in that library)
get filename (downloads a file from your AS/400 to your PC)
Once the file has been downloaded to your PC, you may use a spreadsheet or word processing program to view and alter the data in this file. The altered file can then be uploaded back to the AS/400 by using the FTP Put command.
Another simple method of circumventing menu security is by using IBMs Client Access/400 Remote Command utility. If youve loaded Client Access on your users PC, they may have the ability to execute commands from a PC DOS prompt. Try it yourself. From a PC that has Client Access/400 loaded on it and is connected to an AS/400, try the following example, which will issue a remote command from a DOS prompt and create a file named Hacker in library QGPL:
RMTCMD CRTPF QGPL/HACKER +
RCDLEN(20) //SYSTEM NAME
As you can see, the exposures Ive shown here can be quite disconcerting. And remember this: Because the Limit Capabilities function is restricted to OS/400 green- screens only, remote users can employ the DOS prompt as a command line even if Limit Capabilities = *YES is in their user profile! At this point, the need for exit programs to control this type of access should be apparent.
IBMs exit point documentation is shown in the References and Related Materials section at the end of this article. As you can see, the information is scattered over a wide range of sources.
Exit Points and Remote Transactions
As of V4R4 of OS/400, fifty-six exit points had been defined. Want more? Then all you have to do is wait. The number of exit points increases with every release of OS/400. And unfortunately, reference materials describing exit point transactions are not cohesive. Ive listed exit point documentation in the References and Related Materials section at the end of this article; however, this information is scattered over a wide range of sources. No single documentation source for exit programs is available. In fact, an on-line search for exit programs in IBMs library returned over 360 references.
While these IBM references do an excellent job of describing the parameters that are passed and how the server interprets return codes, sorting through the ones you need is a chore. Youll need to do a lot of detective work on your own in order to figure out which exit points to monitor. One way you can do that is by using a CL program to monitor exit point usage (try the simple exit program shown in Figure 2). Change the type field on the Send Journal Entry (SNDJRNE) command to identify the different exits and register the program at all suspected exits.
Registering Exit Programs
Two methods are available to register an exit program: through network attributes and by registration facility. The registration facility has more flexibility for registering exit programs than the network attributes.
Network Attributes DDMACC and PCSACC
Distributed Data Management Access (DDMACC) and Client Request Access, or Client Access, (PCSACC) are network attributes that specify a qualified program name on the
Change Network Attributes (CHGNETA) command. A user with *ALLOBJ special authority can specify the exit programs using the following command:
CHGNETA DDMACC(EXITLIB/EXIT2) + PCSACC(EXITLIB/EXIT2)
Registration Facility
The registration facility (REGFAC) is the sole venue for the definition of new exit points; you can think of it as a repository for exit program names. To invoke the registration facility, enter the Work Registration Information (WRKREGINF) command. The registration facility may also include the exit programs of other software applications.
Exit programs all use the same parameters, which helps the coding effort a great deal. These parameters are the return code, which you will set to 1 to approve the request (other values will rejectyou may use 0 to reject.)
An Ounce of Prevention
How exactly do you use exit points and exit programs? The program shown in Figure 3 will prevent Client Access and DDM remote commands. In this example, the requested function is COMMAND, so this program will reject all remote commands. To employ this program, you use the command CHGNETA DDMACC(yourlib/EX002C). Please note, however, that you must have *ALLOBJ special authority to perform this action.
Now, tweak the exit program shown in Figure 3 (page 58) to include the prevention of file uploads, as well as remote commands issued from Client Access and DDM. The program shown in Figure 4 will restrict file uploads for all users except for those with SUPERUSER designation. The last statement in this program illustrates how to record user actions by writing entries in the audit journal. To use this example, create the program as shown, making sure to use the value *OWNER in the USRPRF parameter of the Create CL Program (CRTCLPGM) command.
Because the program writes to the audit journal, you must change the ownership of the program so that the program will adopt authority necessary to write to the audit journal. Use the following command:
CHGOBJOWN OBJ(EXITLIB/EXIT1) +
OBJTYPE(*PGM) NEWOWN(QSECOFR)
Next, because the program controls both the Client Access and DDM functions, you will also need to change the network attributes so that they both use the same exit program. Use this command:
CHGNETA DDMACC(yourlib/EX003C) +
PCSACC(yourlib/EX003C)
Help Is on the Way
So far, Ive only touched on examples that use the network attributes exit points. Theres another universe of functionalityand the attendant programming effort required through using the Work with Registration Information (WRKREGINF) display. When you start looking through the registration facility, youll quickly discover just how many exit points are available for you to use. Even more daunting than the sheer volume is the fact that its almost impossible to tell, simply by looking at the name of the exit point, which one does whatand many seem to do the same thing! Which one do you use and how do you use it? Thats where the detective work I mentioned earlier comes into play: Either you become the sleuth, or you need to find other resources to assist you with securing your system.
You can effectively use exit points to dumb down a users PC to the status of a dumb terminal. The downside to all of this is that there are still 34 additional exit points to
secure that I havent discussed in this article, FTP, TELNET, and SQL to name a few. While its true that creating, testing, and implementing your own exit programs can be a very time-consuming and frustrating project, for an experienced programmer, its not all that difficult.
However, if you dont want to take the time to do the research and coding on your own, many resources are available to you. For example, Midrange Computing has published several articles that detail exit points, such as Alex Garrisons Locking Down Your FTP Server, MC, December 1999. IBM also provides some great sample FTP and Telnet exit programs for you to clone and modify for your own installations. Check the references section at the end of this article for the URLs. And finally, there are many vendors who specialize in AS/400 security who have years of experience in writing and implementing exit programs. For a detailed listing, be sure to check Midrange Computings Online Yellow Pages at www.midrangecomputing.com/yellowpages. With all these great resources, theres no reason why your AS/400 needs to be vulnerable any longer.
Layer Method
Physical Requires a key, smart token, etc. Network Encrypted data transmission Application Program options and restrictions, menus, exit programs
Object Defines who can access an object and how it can be used (if implemented properly, this security layer cannot be circumvented) Encryption Requires an encryption key to view masked data
Figure 1: Different layers of security help to keep your AS/400 data secure.
/**************************************************************************/
/* TO CREATE: */
/* CRTCLPGM PGM(XXXLIB/EX001C) SRCFIL(XXXLIB/QCLSRC) */
/**************************************************************************/
PGM PARM(&RC &STRU)
DCL VAR(&RC) TYPE(*CHAR) LEN(1)
DCL VAR(&STRU) TYPE(*CHAR) LEN(80)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(EXIT))
/* ALLOW REQUESTES &RC = 1 */
CHGVAR VAR(&RC) VALUE('1')
/* SENDS AN ENTRY TO THE QAUDJRN SYSTEM JOURNAL */
SNDJRNE JRN(QAUDJRN) TYPE(X1) ENTDTA(&STRU)
EXIT:ENDPGM /**************************************************************************/
Figure 2: Use this simple exit program to record exit point use.
/* TO CREATE: */
/* CRTCLPGM PGM(XXXLIB/EX002C) SRCFIL(XXXLIB/QCLSRC) */
/**************************************************************************/
PGM PARM(&RTNCODE &DATA)
DCL VAR(&RTNCODE) TYPE(*CHAR) LEN(1)
DCL VAR(&DATA) TYPE(*CHAR) LEN(30)
DCL VAR(&FUNC) TYPE(*CHAR) LEN(10)
CHGVAR VAR(&FUNC) VALUE(%SST(&DATA 21 10))
IF COND(&FUNC *EQ 'COMMAND') THEN(DO)
CHGVAR VAR(&RTNCODE) VALUE('0')
ENDDO
ELSE (DO)
CHGVAR VAR(&RTNCODE) VALUE('1')
ENDDO
EXIT:ENDPGM /************************************************************************/
/* TO CREATE: */
/* CRTCLPGM PGM(XXXLIB/EX003C) SRCFIL(XXXLIB/QCLSRC) USRPRF(*OWNER) */
/************************************************************************/
/* Change owner of the program to user QSECOFR. */
/* Adopted authority allows the program sending */
/* to the audit journal */
/* CHGOBJOWN OBJ(EXITLIB/EXIT1) */
/* OBJTYPE(*PGM) NEWOWN(QSECOFR) */
/* Name the exit program in network attributes */
/* CHGNETA DDMACC(EXITLIB/EXIT1) */
/* PCSACC(EXITLIB/EXIT1) */
/* */
/* The audit journal QAUDJRN entries created are: */
/* X1 = Requests that are allowed */
/* X0 = Requests that are rejected */
/************************************************************************/
PGM (&RC &STRU )
DCL VAR(&RC) TYPE(*CHAR) LEN(1) /* Return +
1=allow; 0=prevent */
DCL VAR(&STRU) TYPE(*CHAR) LEN(200) /* Request +
description */
DCL VAR(&USER) TYPE(*CHAR) LEN(10) /* User +
profile name */
DCL VAR(&APP1) TYPE(*CHAR) LEN(10) /* Requested +
function */
DCL VAR(&APP2) TYPE(*CHAR) LEN(10) /* Sub +
function */
DCL VAR(&TYPE) TYPE(*CHAR) LEN(2) /* Journal +
entry type */
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(EXIT)) /* if +
error exit */
CHGVAR VAR(&RC) VALUE(1) /* Allow request */
CHGVAR VAR(&USER) VALUE(%SST(&STRU 1 10)) /* Get +
user */
CHGVAR VAR(&APP1) VALUE(%SST(&STRU 11 10)) /* Get +
appl */
CHGVAR VAR(&APP2) VALUE(%SST(&STRU 21 10)) /* Get +
function */
/* Do not log IBM request to check license */
IF COND(&APP1 = *LMSRV) THEN(GOTO CMDLBL(EXIT))
IF COND(&USER = SUPERUSER ) THEN(GOTO +
CMDLBL(LOG))
/* Prevent use of remote commands */
IF COND(&APP1 = *DDM *AND &APP2 = COMMAND) +
THEN(CHGVAR VAR(&RC) VALUE(0)) /* +
Prevent the request */
ELSE /* Prevent file upload from PC users */
/* File download to PC is not prevented */
IF COND(&APP1 = *TFRFCTL *AND &APP2 = +
REPLACE) THEN(CHGVAR VAR(&RC) +
VALUE(0)) /* Prevent the request */
/* Log request in the audit journal */
LOG: CHGVAR VAR(&TYPE) VALUE(X *CAT &RC)
SNDJRNE JRN(QAUDJRN) TYPE(&TYPE) ENTDTA(&STRU)
EXIT:ENDPGM
Figure 3: Prevent Client Access and DDM remote commands with this program.
Figure 4: Restrict file uploads for all users, except SUPERUSER, with this program.
LATEST COMMENTS
MC Press Online