Communications Security
Question: I have IS staff in a number of remote sites that I would like to setup so that they can vary on and off their local devices. I thought that I would give them the rights to vary controllers and devices but not lines, tape drives or consoles.
The easiest and fastest way seemed to give them *IOSYSCFG rights but I still want to control some configuration objects. Here is what I tried but it doesn’t work, can anyone suggest a better way?
1. CRTUSRPRF called IOSYSCFG with only *IOSYSCFG special rights nothing else and even limit command line.
2. CRTCLPGM called WRKCFGSTS that is owned by IOSYSCFG and adopts. This program prompts the command WRKCFGSTS.
3. Replace the menu function they currently have with this new CLP.
4. Grant user IOSYSCFG *USE rights to the command WRKCFGSTS
5. For the few identified objects I don’t want them to have access to, set authority for user IOSYSCFG to *EXCLUDE.
The problem is that through this CLP I they can’t vary any devices on or off. It’s as if the adoption rights don’t carry through. Is this true of *IOSYSCFG rights?
Answer 1. Why don’t you just give the profile, IOSYSCFG menu level security with menu options for Devices and ctl only?
Answer 2. Write a program that varies them on and off, and compile it under a profile with *IOSYSCFG, and make the owner of the program the same as the profile you compiled it. When the user runs it it will adopt the authority of the owner.
Question: Are there any security vulnerabilities for APPC network?
Answer 1. learn them and decide what level of risk you are willing to live with. Like TCP/IP, APPC is susceptible to address spoofing, and like TCP/IP there are certain network tools that transmit passwords in clear text. APPC (like any network connection) also allows direct access to files and other objects without the intervention of any menu programs.
But there are some safeguards available. SNA devices support something called location password that allows authentication of remote nodes. There is also APPN filtering that can limit the amount of network roaming that an intruder might do, and there are exit programs that can prevent network access to objects on the AS/400.
The best and easiest place to get a high level view is the book “Tips and Tools for Securing your AS/400” from IBM. It is well organized and a very fast read, and it has a section that focuses on APPC security. Other good sources include News/400 (November is this year’s Security issue), Wayne Madden and Carol Woodbury’s book “Implementing AS/400 Security” (Duke Press) and this listserver
Question: If I wanted to write a CL on my 720 that would start a passthru session to my 620, how could I do this so that no sign on screen pops up? Is this possible? Is there anyway that I can start the remote session and have it log-in automatically without me having to actually sign on manually? (7/2000)
Answer: I believe this can be accomplished by specifying *YES for Secure Loc on the remote configuration list. From 720:
WRKCFGL
If QAPPNRMT exists, type 2
If entry for 620 exists, change Secure Loc from *NO (default) to *YES
If no entry for 620, add entry – be sure to specify *YES for Secure Loc
If no QAPPNRMT, CRTCGL TYPE(*APPNRMT)
Add entry for 620 – be sure to specify *YES for Secure Loc
The profile and password on both systems has to match. Also, be sure to specify RMTUSER(*CURRENT) RMTPWD(*CURRENT) on the STRPASTHR screen.
Another way to accomplish this (not recommended, but possible), is to store the profile and password in a file or data area, then use a CL to retrieve the information. On the STRPASTHR command, include RMTUSER(&user) RMTPWD(&pwd)
And a final way that I can think of (again, not recommended) is to hardcode the profile and password in the CL. On the STRPASTHR command, include RMTUSER(UserProfile), RMTPWD(CurrentPwd).
Another Note…
If you use SECURELOC(*YES) or SECURELOC(*VFYENCPWD) : Recommend you implement a location password into QAPPNRMT or the *DEVD (if APPN=*NO). This will prevent others from re-creating the communications environment without the password. It also helps to validate that the computer at tyhe other end of the pipe is the authorized one. If you forget the password, another one can always be re-assigned.
Client Access and ODBC Security
Question: How can I suppress transfer option on workstation from the menu (and the transfer icons) ?
Answer 1. Disabling menu options and icons is not sufficient. Anyone using an ODBC driver can access your data without requiring the menu. You have to change the authority to your data files on your AS/400 to truly lock things down.
- Access to data base files should be public *USE. Users should NOT have more authority to the files.
- A Super User should have *CHANGE rights to the data.
- Each program should adopt the authority of the Super User.
- The Super User should NOT be able to sign on (Password *NONE, initial program *SIGNOFF, initial menu *NONE)
Each user has authority to use the programs.
This plan (pieces may be missing; use at your own risk. No guarantees. Your mileage may vary) allows the user to run programs as a Super User, changing data using your edit programs and all your safeguards.
Users with ODBC drivers will access your data as a ‘normal’ user, with *USE (i.e. read only) access, protecting your data. You may create special interface libraries and files that are changeable by your users. Your programs will read those files, edit the data, and update your protected files.
Question: We are on an AS/400 running V3.2 and have been playing around with Client Access (latest PTF has been applied) on our own machines to check out security before giving it out to all of our users. Is it possible to eliminate the two sign-ons (the initial connection signin window then the standard AS/400 signon screen) without filling in the default user? We don’t want the system keeping the passwords for any users. Our need includes the use of the data transfer feature as well.
Answer 1. It will be possible when you get v3R1m3 of CA, as well as the supporting PTFs for V3R2 of OS/400. In v3r1m3 of CA, it will be possible to specify in PC5250 that you want to bypass signon. This is just like it was in APPC connections. Then the only entry will be for the initial connection.
At present (5/98), you can do this if you are running an APPC connection.
Answer 2. You can also use the user exit interface for Telnet. This lets you control who is allowed to access your system, and can also bypass the signon panel based on the IP address (or any other factors you want). Perhaps a not well understood feature of the user exits is NO PASSWORD IS REQUIRED to do auto-signon (although a user profile is required). The user exit can set the user profile to whatever it wants, accepting any client USER variable value from client access or overriding the USER variable to any desired low-level user profile.
With user exits, you don’t have stored passwords laying around. NEWS/400 magazine plans to publish some sample in their Sept 1998 issue.
Question: We are just in the process of setting up ODBC to our AS/400 (V3R2) and looking at security. Specifically, how we could set it up so that people that currently have a signon to the AS/400 could be prevented from connecting via ODBC. Any additional information on ODBC security (other than standard AS/400 file security) would be helpful too.
Answer 1. The most effective way to prevent ODBC access to AS/400 data is to write or buy Exit Programs that monitor your network interfaces. By setting Exit Points at the network entrance to your system, you can block and/or regulate ODBC, File Transfer (including FTP) and Remote Command request that are sent it’s way. The IBM manual “Client Access/400 for DOS and OS/2 Technical Reference V3R1” explains how to write exit programs.
To stop ODBC you need to plug both the DRDA and the Remote SQL servers (the latter has several functions). Be aware that if you are vulnerable to ODBC, you are also vulnerable to file Transfer, DDM, remote command, etc, so you’ll want exit points to plug those holes too.
To program this yourself, look at IBM Manual Client Access for Windows 3.1 ODBC User’s Guide, and AS/400 Client Access Host Server Manual. There is a sample ODBC exit program. You can control the following functions of ODBC.
- Whether ODBC is allowed at all.
- What functions are allowed for AS/400.
- What SQL statements are allowed.
- What information can be retrieved about database server objects.
- What SQL catalog functions are allowed.
Another alternative is the use of triggers to embed security access decisions into your database directly. This is the ONLY way to really protect your data when you have no idea where changes are coming from.
Question: We would like to find out what is the best way to control security to the AS/400 data from ODBC, FTP, Internet, Client Access & who knows what else. Is it best to use ;Application Only Access, Exit Programs, a combination of both or is there something new available? (6/2000)
Answer 1: Exit Programs are a good way to restrict access for FTP & ODBC. Internet stuff could probably be handled with permissions inside Operations Navigator. Client Access can be handled during the install process (i.e. Don’t install the transfer process)
Answer 2: We are currently in the process of testing two programs. One is Pentasafe (www.pentasafe.com) and the other is Powerlock (www.softlanding.com) These are supposed to be great programs.
Answer 3: I always recommend belt and braces;
Object authority, in whatever form you define it, is essential to normal AS/400 access to objects.
Exit points have been specifically provided by IBM so that you can add an extra layer of checks where the normal authority rules no longer apply. You want to give people tools which make use of ODBC etc but that could cause an exposure. Also be aware that some ODBC products in the past have bypassed the exit points anyway!
Another area I would advise you to consider is whether, for your business and applications, normal profile / password processing is tight enough for “external” access or whether you need stronger authentication.
If you would like to investigate one of the options for exit point control please consider our software DetectIT – www.detect-it.com
Answer 4: There is no substitute for proper application design…and you can quote me!
Exclude based authority using the AS/400 object authority, well designed exit programs, and a knowledge of what to shut down in the communications arena will help secure from outsiders.
Now insiders…that is an entirely different story.