The following Question and Answer was originally published in Midrange Computing (Security Patrol by Wayne Evans, January 1996). Because of its relevance and importance to Client Access developers, we are including it in this issue of Client Access/400 Expert.
Q: Our location uses the same user profile and password to start the Client Access router at the 200 PCs attached to our AS/400. What are the security ramifications of all users starting the router with the same profile? If all users use the same user profile, will it have a performance impact?
A: There is no performance impact for the same user profile being used to start the router. The major disadvantage of using the same user profile for each PC is there is no way to distinguish the users for file transfer purposes. System auditors do not like the use of shared user profiles because there is no individual accountability for actions when a large number of users share the same profile and password.
The use of the same user profile and password to start the Client Access router is often done so that the router startup can be automated through input redirection to avoid entry of the user profile and password. The following example illustrates the use of redirection to supply the user profile and password from the file SECRET.TXT.
STARTRTR < C:SECRET.TXT I do not recommend this technique, but many AS/400 installations use it to simplify the startup procedures for the end users. The exposure is that anyone who can power on the PC will be able to start the Client Access router. At a minimum, I would recommend that the file that contains the user profile and password not be stored on the local hard drive (C) but instead be stored on a network server. Users will be required to sign on to the network before they are allowed to start the router. Storing the user profile
and password on the network server also makes it easier to change the file that contains the profile and password. Making the change on 200 individual PCs is very labor-intensive.
If you are going to use a widely known user profilesuch as PCUSER or GUESTthen youll waant to prevent users from being able to sign on to the AS/400 with the profile. The recommended procedure is to create the user profile in such a way that, if the user profile is used for an interactive sign-on, the user is immediately signed off. This can be done by specifying an initial menu of *SIGNOFF and no initial program.
CRTUSRPRF USRPRF(PCUSER) +
PASSWORD(PCUSER) +
INLPGM(*NONE) +
INLMNU(*SIGNOFF) +
LMTCPB(*YES)
In this situation, you should also prevent the user from getting access to the system request menu. The system request menu can be exploited to display information and messages that allow a hacker to break into your system.
I was conducting a security penetration test (i.e., getting paid to be a hacker), and I found a profile that had been created as shown above. When I signed on, I was immediately given a screen that told me my initial program had terminated and to press Enter to sign off. However, I used system request at that point and was able to display the messages for QSYSOPR and other user profiles. It took less than five minutes to find the name of another user profile that had a password that was the same as the user profile, and I had a command line.
To prevent specific users from seeing the system request menu, you must restrict their access to the QGMNSYSR panel group in QSYS. You can prevent a user from accessing QGMNSYSR by specifying *EXCLUDE authority.
GRTOBJAUT OBJ(QSYS/QGMNSYSR) +
OBJTYPE(*PNLGRP) +
USER(PCUSER) +
AUT(*EXCLUDE)
I discovered another method (by accident) that is equally effective. If the user profile specifies an initial program that the user profile has no authority to, the user profile cannot be used to sign on, and IBM automatically blocks the system request menu.
CRTUSRPRF USRPRF(PCUSER) +
PASSWORD(PCUSER) +
LMTCPB(*YES) +
INLPGM(NO_ACCESS) +
INLMNU(*SIGNOFF)
Even with these techniques, a PC user who starts the Client Access router in this way will still be able to perform file transfers to any files that have *PUBLIC authority. This exposure can be eliminated by using resource security, creating an exit program for the PCSACC parameter of the network attributes, or specifying *REJECT for the PCSACC parameter.
LATEST COMMENTS
MC Press Online