Answer 1. Carol Woodbury authors Security FAQs (almost) monthly in NEWS/400 and there is a Security FAQ link off their web site at www.news400.com. In addition, she and Wayne Madden co-authored a book, Implementing AS/400 Security, 4th Edition from 29th Street Press, ISBN 1-58304-073-0. It can be ordered on-line from MC Press. This is a good (easy to understand and very readable) account of AS/400 security and is current through V4R2. An IBM publication that is actually readable and helpful in this area is Tips and Tools for Securing your AS/400, SC41-5300. It's a guideline for all the areas of the AS/400 you should consider securing.
Answer 2. There are some manuals from IBM in the net:
SC41-5300-01 = Tips & Tools for Securing Your AS/400 V4
http://publib.boulder.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/docnum/SC41-5300
SC41-5301-00 = AS/400 Security - Basic
http://publib.boulder.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/docnum/SC41-5301
SC41-5302-01 | OS/400 Security - Reference
http://publib.boulder.ibm.com/cgi-bin/bookmgr/bookmgr.cmd/docnum/SC41-5302
SC41-5303-00 | AS/400 Security -- Enabling for C2 (not available online)
(Note: This is as of April 2003. IBM is known for frequently changing URLs for useful information. You may not find these items at the above sites!)
Answer: DSPUSRPRF *ALL OUTPUT(*PRINT)
Question: What commands are used to get auditing turned on? What commands are used to check audit logs?
Answer: You must create the security auditing journal QAUDJRN if it doesn't already exist. If it does exist, then you can turn auditing on for specific profiles with the CHGAUD command, or for specific object using the CHGOBJAUD command. You'll need more detail than I've provided here, so refer to the manual Security - Basic V4Rx (SC41-5301) and/or the Tips and Tools for Securing your AS/400.
Question: What is the command to list the applications and their security level?
Answer: The WRKOBJ command will allow you to see (option 5) and change authority to specific objects. Use the WRKOBJ on the application library itself to determine who can even see an application (assuming that for your system 'An Application' means some small number of say (less than 5) libraries. If the *PUBLIC authority on the library is set to *EXCLUDE, then only those User Profiles or Group Profiles that are specifically authorized to the library will be able to use the application. Be aware that this is where the similarity to UNIX directory structure ends. If *PUBLIC authority to a library is *USE (read only), this does not mean that the public is restricted to read only access for objects in the library. Once someone has a minimum of *USE to a library, authority to objects in the library is governed by the authority of each individual object (Some could be *EXCLUDE, some could be *USE, and others could be *CHANGE, etc.)
Question: How do I limit Command line access to normal users i.e. in the USER class? I want them to interface with the system via Menu only. Can this be set system wide for all USER class members?
Answer 1. There is a parameter on the CRTUSRPRF/CHGUSRPRF command called LMTCPB (Limited capability user). When this parameter is set to *YES, the user is prevented from entering commands at an AS/400 command line. You could do a DSPUSRPRF with *OUTFILE, then use that file to do a MASS CHGUSRPRF cmd.
Note that this restriction is not absolute. The user would still be able to enter commands using the Client Access remote command and the FTP rcmd facility (prior to V4R1). To block command entry from these sources you would have to use the corresponding exit points
Question: How do I use adopted authority in a CL program?
Answer:
CHGPGM PGM(MYLIB/MYPGM) USRPRF(*OWNER)
CHGOBJOWN OBJ(MYLIB/MYPGM) OBJTYPE(*PGM) NEWOWN(SUPERUSER)
Question: Can you reset the QSECOFR password through DST? Is this the only way?
Answer: Yes . You can also reset it using another user ID if that user ID has the required authority (is the equivalent of another security officer).
Question: Is there a way to check/zap/reset the DST passwords short of a scratch reload? Will a scratch reload reset the DST passwords?
Answer: This procedure works well
1. Put the system in manual mode.
2. Sign on to the DST sign-on screen with the DST security capability password. QSECOFR
3. Select option 5 (Work with DST Environment) from the Use Dedicated Service Tools menu.
4. Select option 9 (Change DST passwords) from the Work with DST Environment menu. Note: The menu option may be different depending on which release of OS/400 your system is running.
5. Select option 4 (Reset System Default Password) from the Change DST Password menu. This option resets QSECOFR's password back to the default of 'QSECOFR'.
6. F3 TWICE BACK TO MAIN MENU( NOT DST MENU!!!)—1 EXIT DST, and go back to main menu with option 1: IPL system.Your QSECOFR password will be reset and is QSECOFR.
Some more on this ..
Just a brief note...there are ways to regain access to your system if DST and QSECOFR are both lost. However, bypassing the security should probably be performed via supportline <don't laugh>. The odds are that the DST passwords or even the operating system has not been secured.
Also, be careful if you educate a user on hacking security. The last thing you want is a misunderstanding that leads to any form of legal problems!
FYI -- we always get a letter on company stationary from a corporate officer before we will reset security.
Question: In the future we will be running an application that will need the HTML Server up and access to the Internet. Of course IBM Security Manuals just say go to QSECURITY 40. What insights for problems does anyone have about Level 40 security to say standard RPG jobs that adopt user authority. How does it change profiles authority or authority lists. (12/99)
Answer 1: Going to level 40 affects more than just RPG programs that adopt authority.....Level 40 effects *every* object on the system. The best way to see where you are in prepping for such a change is to turn on the audit journal and watch it for a period of time. I did this earlier this year. Started monitoring the audit journal and it was over 60 pages of stuff printing out for the AF entries alone......You will be amazed at what will show up initially on the reports!
Another thing to watch for are vendor packages that are not level 40 compliant. ASC's SEQUEL product had to be upgraded to be Level 40 compliant.
Answer 2: The good news is that a level 30 to level 40 jump does not involve changes to any profiles or authorization lists, and has absolutely no effect on programs that adopt authority.
QSECURITY Level 40 has two principle benefits over level 30 security. First, some well known holes regarding Job Descriptions were plugged, and second the differences between System State and User State programs are enforced (a potentially big hole most likely to be exploited by your application vendors).
The JOBD hole that level 30 addresses has two manifestations. The first is that a user could submit a job using an existing JOBD and have it run under the user profile that is named in the JOBD. If you have any JOBD's on your system with user profiles attached, or if anyone has the ability to restore a JOBD with a user profile attached, then your level 30 system is vulnerable to this situation (hint: IBM ships JOBD QBATCH with User Profile QPGMR attached). The second is where a JOBD can be specified on a Subsystem's Device description so that users could get on to the system without actually signing on (there was a thread out here last week about doing this for a printer support terminal). At level 40 this is no longer allowed.
The other major hole that QSECURITY Level 40 plugs is a problem where (mostly MI) programs can illegally acquire authority though the misuse of pointers. At Level 40 the MI instructions that allow this are restricted from "user domain" programs (It's actually more involved than this, but this is the quick explanation :). At level 40 some third party software may have a problem (Hawkeye is the only one that I've seen recently that uses these unsanctioned interfaces, and even they have a work around for it). As others have mentioned, you should turn on the Security Audit Journal (QAUDJRN) to log any potential violations prior to actually moving to QSECURITY level 40. This can be done easily with the CHGSECAUD command (it creates QAUDJRN and a receiver, and handles receiver rolling for you). You need to monitor for *AUTFAIL and *PGMFAIL, but don't get fooled into thinking that every authority failure entry (Journal Type AF) is a level 40 violation. You need only be concerned with types B,C,D,J,R, & S. My prediction is that the number of these entries will be few.
Section 2.4 in the Security Reference Manual will give you all the details you need.
Question: Is there a URL out there that shows step by step the requirements forchanging from QSECURITY 30 to 40? Pros/Cons? Anyone who's gonethrough this? Is it worth it? (1/2000)
Answers: Try this:
http://archive.midrange.com/midrangelarchives/199912/msg00774.html
http://archive.midrange.com/midrangelarchives/200003/msg01112.html
Also, take a look at IBM's AS/400e Security Advisor. This will
also help you tighten down your AS400.
http://www.as400.ibm.com/tstudio/secure1/advisor/secwiz.htm
One "gotcha" was with vendors. Some of them had programs that are sensitive to the security level. When we planned our upgrade the second question I got from several vendors was "what security level will you be running?". I told them security level 40 and they changed the distribution CD. All of my vendors' technical folks knew about security level 40; all knew what the impact (if any) was to their product(s) right off the bat. I'd suggest a "poll" of you vendors would be in order before "throwing theswitch". You may have to re-install some products.
Question: What should I do if I find a security vulnerability (or something that looks like a vulnerability) in an AS/400? (6/2000)
Answer: It is best to use the normal support channels. Anyone can report errors free of charge via ECS or via www.as400service.com and then selecting problem reporting. Users must first register at the Web site and need a customer number and machine serial number. Users are also free to report these problems through their business partners which many times also have a support contract.
Be sure to clearly state that the problem is a security problem and your opinion of its severity.
Also at the Web site, users can select PTF Maintenance and view/search for all HIPER and/or data Integrity PTFs for a particular release. User's should also able to order or download PTFs from this Web site.
Question: I need some help. I have AS/400 F20 in central
site and about 30 terminals and PC connected to it by several HDLC lines
or X.25 satellite lines. I'm looking for companies offering cryptographic
modems, cryptographic cards, ciphering programs or other solutions providing
security in this system.
Answer: For AS/400, there are 2 different cryptography products available. The first is Cryptographic Support/400. This is software implementation of the DES. It contains around 10-12 API verbs for encipher/decipher, PIN functions, MAC functions, and some key management. The second product is the Cryptographic Processor, feature 2620 (or 2628) along with PRPQ IBM Common Cryptographic Architecture Services/400. This is a hardware implementation of DES. On V3R1, the RSA public key algorithm is also supported. The PRPQ contains CL commands for initializing and starting the processor, 99 API verbs, and key storage. The API is a superset of IBM's Common Cryptographic Architecture and contains support for encipher/decipher, MAC functions, MDC, PIN functions, digital signatures, and Key management including ANSI X9.17.
Both products have US Export restrictions. Generally, they may only be exported to financial institutions or US subsidiaries. Feature 2628 is available, however, for customers that are not one of the above. Feature 2628 uses Commercial Data Masking Facility (CDMF) for the data privacy verbs.
For PC's, there are a number of encryption products available. The IBM Workstation Security Services Program together with the Cryptographic Adapter provide the same support and API as the PRPQ and Cryptographic Processor for AS/400.
Here's a brief description of IBM's crypto product offering:
IBM Cryptographic Support/400 Version 3 Program Number 5763-CR1
The IBM* Cryptographic Support/400 program provides support for the
encryption and decryption of data and facilities to assist the user in
managing cryptographic keys. The encryption and decryption are performed
in accordance with the American National Standard Data Encryption Algorithm/Data
Encryption Standard (DEA/DES).
(Note: This response is now outdated. IBM's Cryptography offerings have been substantially revised).
Question: Does anyone know if PGP (Pretty Good Privacy) has been ported to the AS/400? (asked 2/6/96)
Answer 1. I've ported PGP 2.6.2 to my system and recompiled most of the code. There are several items that needed to be completed if I am to make this package functional on the AS/400. They are as follows:
1. Resolve programs that didn't compile for whatever reason. (About
4-6)
2. Provide some form of coded character set id or conversion for the
ASCII to EBCDIC problem.
3. Make the PGP functions more compatible with the AS/400 technique
for executing software packages.
4. Get some beta test users who want to test the heck out of this.
As with Zimmerman's PGP, source will be provided... No MI compiler
will be needed.
Steve Glanstein
(Note: Steve was unable to complete the port at this time and apparently abandoned the effort. He did, however, provide a very good lab at COMMON on using the PC version of PGP. More recent midrange-l discussions (8/99) indicate renewed interest in use of this product, but no available port).
Question: Does anybody have any ideas on how to encrypt a file in such a manner that the AS/400 can decrypt it with no user intervention?
Answer 1. How about a batch job on the PC that performs the encrypt, and then runs an ftp script. The script sends the file, then does a quote/rcmd to force the process on the 400. This process can also provide notification on the 400 that the file was received.
Answer 2. Another option is to use a VPN over the Internet, using NT PPTP on the server side and the PPTP (VPN) client that comes with Windoze on the client side. The raw performance is not as good as a straight connection to our AS400 via the Internet thru our proxy server, but for secure access to all the services on our network, it works fine. Other VPN products (such as the one from Checkpoint, maker of Firewall-1) could work as well.
Question: I have currently done a VPN setup for Host to Host
connection, but somehow unfortunately I've made a wrong set of VPN configuration
and right now we can't access the AS/400 through any TCP/IP connection.
How can we reset the VPN configuration, while to do that we have to access
the CA Express Operation Navigator which it is one thing that we can't
do
right now. Is there any other setup alternative through 5250 session?
(12/99)
Answer: Use the RMVTCPTBL command to remove the filter rules you created on your line, you'll need to do this from the console or a non - IP device. This should allow you to return to normal operation using the line.
Question: What security level (30, 40, or 50) is adequate
for an AS/400 on the Internet?
Answer 1. Levels 40 and 50 will have little or no impact in regard
to remote connections. Level 30 provides logon and resource security. Level
40 adds user and system domain differentiation, and makes sure that only
the officially "blessed" interfaces and APIs will run. Level 50 adds DOD
data protection and auditing features that are supposedly resource hogs,
and probably completely unnecessary unless you're keeping military secrets
at your site.
Question: Can anyone tell me how OS/400 compares to unix
where Internet
security is concerned?
Answer 1. Unix has security???? :)
Answer 2. I would second what you say about AS/400 security being more robust & having fewer (known) holes. I do believe a properly configured UNIX system can be quite secure. Also a good many UNIX systems are in inherently unsecure environments (on the Internet, in Universities, etc.). I suspect many AS/400 systems in similar environments would be subject to break-ins, especially as they are now typically configured (using default APPN/APPC parameters on networks, PC Support with no exit programs for security, etc.) The one area (again) where I think some UNIX systems are more vulnerable is the etc/passwd file with the encrypted passwords in place (no shadow password file in some version of UNIX). A hacker can download this file & try to crack poorly chosen passwords using some commonly available software. Passwords are well hidden enough under the OS/400 system that I don't believe this sort of vulnerability is possible on the AS/400.
I think it would be an interesting exercise to compare the APPC/APPN stack with TCP/IP in order to see if they are equivalent vulnerabilities in APPC/APPN to those known (and published) in TCP/IP.
Passwords are well hidden enough under the OS/400 system that I don't believe this sort of vulnerability is possible on the AS/400. I'm sure you're right about that. It's a double-edged sword on the Unix side; I love having the ability to sniff out so much over the 'net, and it makes me nervous that people can sniff out so much over the 'net. :)
I think it would be an interesting exercise to compare the APPC/APPN stack with TCP/IP in order to see if they are equivalent vulnerabilities in APPC/APPN to those known (and published) in TCP/IP. (3/96)
Question: I have installed Client Access Express on company PCs so the users can sign on to the AS/400 through internet access. Everything works fine. I had the Network Administrator open only 6 ports on our firewall to allow the access. This was done with the help of the IBM Support line.
Now the Network Administrator wants to close the ports because it is too dangerous to have them open. Someone with a sniffer could detect User-id and passwords.
I suggested that we upgrade to SSL but that idea was not received with a lot of acceptance.
I would appreciate any suggestions on ways to make the connection secure.
Answer 1: Have you looked into using VPN (assuming you are on V4R4). The AS/400 and PC side encryption are no-charge orders on V4R4 -- but you must ask your BP or IBM for them (I'm told this is due to U.S. crypto laws). Your BP (or IBM rep) _should_ be able to help you pick the right items for your situation.
Answer 2: Recommend using SSL on V4R4...you can make a certificate that goes into the browser of the client and verifies that the client is talking to the AS/400. Then you can lock out the non-SSL ports in the firewall as well as on the AS/400 host. The data is entirely encrypted and the 128 bit encryption looks like the way to do.
If this network admin. needs a demo, get 5769-AC3, 5759-CE3, 5769-SS1 options 34 & 35, use the HTTP (*ADMIN) server to setup digital certificates, get authority to the proper directories using the procedures in the Redbook (SG24-5191), install Client Express on a lan PC, install the digital certificates, check off SSL, start a communications trace, and see if the network admin. can find any user ids, password, or any other data.. (Whew, that was a large sentence!)
<btw> see if your firewall is configured from "outside" of the network by an "outside" software vendor. SSL is surely better than that approach...
Question: Is there a way to configure TCP/IP on the AS/400 to allow or deny an incoming TELNET or FTP session based on the incoming IP number.
Answer: There isn't really a supported way to do this with an access list, but you may be able to get what you want through creative use of routing entries. For example, if you wanted to prevent systems from network 6 from accessing your AS/400, you could add a route entry for network 6 with a next hop being some unused address. This way packets could be sent to the AS/400, but the 400 would route return packets into the bit bucket. You could also do this using host routes instead of network routes where instead of network 6, you could specify a particular IP address such as 6.1.2.3.
Question: Is there support in the AS/400 for SSL when connecting TN5250 or TN5250E?
Answer: This has been rumored to be coming in V4R4. The rumor I heard also mentioned in the same breath that the SSL secured Telnet connection would _not_ be PTFed back behind V4R4.
A beta SSL Telnet Proxy Server that provides what you're looking for is available there for V4R2 and V4R3 users. Probably not the kind of thing you'd want to deploy in a production environment, but interesting anyway.
(Note: Answer posted in January 1999, before V4R4 release)
Question: Is there a way to exclude a specific user profile from having FTP access?
Answer 1. If you check out the IBM technical Reference on the "AS/400 EXPERT ONLINE site for setting up for anonymous FTP" . It has examples of FTP Signon and FTP Validation Programs written in RPG/ILE, C and CL. .
http://http://www.redbooks.ibm.com/tstudio/secure1/workshop/comsol3.htm
You could write in hard coding to restrict login to a select group of users.
Answer 2. There are some 'FTP exit points' that are really easy to program for. You can cut and paste the code from the online redbook entitled 'Cool Title about the AS/400 and the Internet' available at the IBM site. We use this program and have modified it to log every FTP access to a file. We use another program from this site to log every FTP request to another file. We've built 'trojan horses' to accomplish some tasks. For example Customer A sends us a file. The FTP exit point program will start up a process based on the receipt of the file.
Program is RPG. How to implement this program is also documented in the above book. See WRKREGINF.
If you have an aversion to do it yourself then you can all Pentasafe. I do not use their products currently but they've been trying to get me to.
Question: Can anyone help me setup an outside user that can FTP into the AS/400.
1. I need him to 'put' data into a directory that I created, I would
like it to be in IFS.
2. I would like to restrict him to just that directory. So he cannot
'get' or 'put' to anywhere else on our box.
Answer 1. That's fairly easy, just create a exit program that restricts him to whatever directory that you specify.
Answer 2. Another good solution may be found at www.pentasafe.com (now part of NetIQ). Or, if you want to roll your own, go to: http://www.redbooks.ibm.com/abstracts/sg244815.html 'Cool Title about the AS/400 and Internet'. Copy the sample code and modify it for your use. Register the exit point programs and you're done.
Question: What versions and PTF's support the clear text and encrypted substitute password in TN5250e? This is an important feature because it prevents a user's password from being transmitted in clear text across the internet. It also bypasses the sign on screen.
Answer: 1) Native support begins at V4R3 and up.
2) V3R2, V3R7, V4R1, V4R2 support with PTF's.
3) Encrypted and clear-text support are in all versions, with support
being cut-in simultaneously.
4) See answer to 3 above.
It is the CLIENT that determines if the Telnet Server is to treat the password as encrypted or clear-text by the IBMRSEED value returned (or not returned). If not returned or has an empty value, then clear-text is defaulted. The Telnet Server will always support encrypted if the client indicates with non zero IBMRSEED value.
Here's the initial PTF where TN5250E support was cut-in; all have since been superseded.
+----------+-----------+-----------+-----------+ | V3R2 | V3R7 | V4R1 | V4R2 | +----------+-----------+-----------+-----------+-----------+ | 57xx-SS1 SF49121 | SF46693 | SF47990 | In Base | | | SF49565 | SF47030 | SF48012 | SF46155 | +----------+-----------+-----------+-----------+-----------+ | 57xx-999 | MF19563 | MF18448 | MF18869 | MF18061 | +----------+-----------+-----------+-----------+-----------+ | 57xx-TC1 | SF49564 | SF47007 | SF47602 | SF46013 | | SF46542 | SF46543 | SF46544 | SF45762 | | +----------+-----------+-----------+-----------+-----------+Initial PTF's where fix first cut-in
Caveat: These PTF's listed are the initial PTF's for TN5250E support, and may have been superseded since they were first released. A superseding PTF can be used in place of any one of the listed PTF's here.
Question: What is the potential threat to AS/400 native SSL enabled servers from a PKCS #1 attack, and how can I prevent this from affecting my system?
Answer: RSA Data Security Inc. announced Friday, June 26th 1998, on its website at http://www.rsa.com, that there is a security exposure with protocols and applications that use RSA PKCS#1 for key or data exchange. SSL is one such protocol. To see more about the technical announcement visit the RSA PKCS #1 webpage at http://www.rsa.com/rsalabs/pkcs1/.
Please note that this attack is theory - it has not been implemented by anyone or successfully tested in an actual real life situation.
AS/400 has analyzed the recently found potential threat to the PKCS #1 based interactive key exchange used in the OS/400 native SSL implementation. Below is the result of that analysis, including a discussion of the current counter measures that exist in the current code, and the proposed additional counter measure implementation.
The problem, as it relates to an SSL user, is as follows:
1) A hacker could record an SSL session between an interactive SSL enabled client and server. If the session was recorded over the Internet, the hacker would have to ensure that they filtered out all other traffic other than the actual SSL packets between a specific client and a specific server.
2) After recording the SSL session, the hacker could extract handshake messages from within that recorded session and use the handshake messages as a basis for construction of carefully formatted messages to be used to probe the server.
3) The hacker would attempt to repeatedly establish an SSL session connection with the SSL enabled server using these carefully constructed messages. The response to each probe would need to be carefully analyzed and based on the server's response, each additional probe would be adjusted accordingly. Eventually, after approximately 1,000,000 probes, the hacker could break the encrypted handshake message's PKCS #1 digital envelope.
4) Once the handshake message's digital envelope is broken, the hacker could eventually determine the read and write symmetric keys for that particular, recorded SSL session and would be able to decode any encrypted data from that specific recorded SSL session.
5) The hacker would only be able to recover data from a single session per attack. No other SSL session's data could be decrypted unless the hacker went through all of the same steps for each SSL session.
6) The private key of the server is not exposed or at risk by this attack.
7) This problem only affects the server implementations of SSL or server applications built using SSL. It does not affect client SSL code.
There are counter measures for this type of attack. for details.
Three of these counter measures relate directly to the code for any SSL implementation. OS/400 native SSL implements two of the three counter measures in the original V4R1M0 and V4R2M0 native SSL server code. These two counter measures alone increases the number of messages required to break the digital envelope of the handshake message from 1,000,000 message probes to over 20,000,000 message probes.
Even though the risk from this attack to OS/400 SSL servers is very small (based on the fact that this attack has not actually been implemented, and the fact that the original OS/400 native SSL code already implements two of the three counter measures) we take this potential attack very seriously. Therefore, the third counter measure is currently being implemented for V4R1M0 and V4R2M0 releases. PTFs containing the updated SSL code with the third counter measure have been released. Please note that these PTFs are NOT hiper PTFs but they will be on the next cum package for V4R1M0 and for V4R2M0. The PTFs are:
V4R1M0 5769999 MF19823
V4R2M0 5769999 MF19824
Question: Are there any "gotchas" in powering down an AS/400 with an IPCS Firewall?
Answer: You must End Network Server Application *FIREWALL and then vary it off BEFORE doing a power down. If you don't, you risk getting your firewall corrupted, requiring a painful restore from tape.
IBM is apparently changing the power down system command to take care of this for you in V4R4 _IF_ you do a controlled power down.
Consider using a program similar to this for power-down:
/* SHUTDOWN - END (ALMOST) ALL PROGRAMS BEFORE PWRDWNSYS. */ PGM MONMSG CPF0000 MONMSG TCP0000 /* Also need to end *M36 Machine NXT36A if active so that */ /* library M36LIB backup can be used to restore *M36. */ /* Because of waits in OCL proc it will take a little */ /* over 2 minutes to end, but will be done by the time */ /* the following SAVLIB (prior to SAVLIB M36LIB) is run. */ SBMNETJOB FILE(QGPL/QCLSRC) TOUSRID((POWEROFF NXT36A)) + MBR(PWROFM36) PTY(*HIGH) /* Submit job to + machine NXT36A via SNADS */ DLYJOB DLY(10) ENDCALSRV ENDDIRSHD ENDWTR PRT01 ENDWTR PRT02 ENDWTR PRT03 ENDWTR PRT08 ENDWTR PRT09 ENDWTR XEROX_N32 STOPTCP ENDMSF ENDSBS QSNADS DELAY(30) ENDSBS QEUX ENDSBS QSPL ENDSBS QBATCH ENDSBS QSERVER ENDSBS Q1PGSCH *IMMED /* ENDSBS SVCDRCTR *IMMED V4R1 version not yet installed */ /* ENDSBS QSYSWRK *IMMED V4R1 - QSYSWRK handles Passthru (QPASVRS) */ ENDDUPJOB CHKFWDMAIL ENDPGMQuestion: Is there an equivalent to the unix hosts.allow and hosts.deny tcp/ip access control scheme available on the 400 (V3R7)?
Answer 1. I don't think so... the hosts.allow/deny functionality depend on a tcp wrapper function (used here on midrange.com to keep people out of the unix system)... and the tcp wrapper depends on a superserver internet daemon, which the as/400 does not have.
Answer 2. You can use the AS/400 exit point or an initial program that retrieves the IP address of the Telnet session, and then provide the controls you want. The system API that does this is QDCDEVD. If you are interested in a commercial product you can check out the Alliance Telnet Security product at: http://www.patownsend.com
Question: Recently I was playing around with a CGI program that I developed to run on our old V3R2 machine. Now we are on V4R3. In the past, I'm sure that when you were calling an RPG CGI program it had to be in uppercase in the URL.
Now it seams it doesn't matter. Using /cgi-bin/CGIPGM1 or /cgi-bin/cgipgm1 will do the same thing and call the CGI program just fine. Which leads to an interesting point:
If you have a protection directive set up in your HTTP Config on CGIPGM1.PGM, if the user types the URL in in lower case, the protection is ignored.
Taking this a step further, any combination of upper and lower case will be ignore except the EXACT protection directive you have given. So, if your directive looks like this:
Protect /QSYS.LIB/AS400CGI.LIB/CGIPGM.PGM CGIPGMP
where CGIPGMP is a protection directive set up, if the user types in
CGIPGM on the url, the protection will work. If, on the other hand, they
type in
cgipgm
CgiPgm
cgiPgm
etc.. etc...
The protection is ignored.
This has got to be a bug or else I'm missing something else here. I'd like to hear from anyone using a protection directive on an CGI program and see if they have the same results.
Response I was just reading that the major difference between the root "/" file system and the QOpenSys file system is that the QOpenSys file systems supports case sensitive object names and root, QDLS, and QSYS.LIB do not. Could this explain the behavior you saw?
Counter Response: Possibly, but I doubt it.
The thing is, on V3R2, if I used the URL to call CGIPGM1: http://my.as400.com/cgi-bin/cgipgm1?parm1=hello
It would error out saying that cgipgm1, in lower case, could not be found. cgi-bin is mapped to library AS/400 CGI so is is in the QSYS portion of the IFS.
Now, since we are up to V4R3, this URL _will_ work. The only problem
is, I have a PROTECT directive on CGIPGM1 so that no one can access the
info without a userid and password. This works find as long as the URL
contains CGIPGM1 in upper case. But if it's in lower case, or mixed case
(A log of patterns with 6 letters that can work), it blows right by the
PROTECT directive.
Answer 1. It sounds like someone has used the Security Toolkit to activate the "automatically disable inactive profiles" option. That's not really it's name. It's name is "Analyze Profile Activity" on the menu option, which sounds benign enough, but in fact it will initiate this scheduled auto-disable.
From the Security Toolkit (GO SECTOOLS) choose option 4 (ANZPRFACT) and set the number of days to *NOMAX. This will prevent any profile from being automatically disabled by this new feature.
Alternately, you could leave the auto-disable at 90 days, and then use options 2 & 3 on that same menu to exclude certain profiles from being disabled.
Answer 2. When you use ANZPRFACT command for the first time it creates an entry in the job scheduler to run weekly. Just delete the job from the job scheduler. I don't know what problems you are having with the command. But I had a problem with the command under V3R2 for new profiles. If the user profiles weren't use they would get disabled. I called IBM support line and I installed a PTF that would look at the last used date and the creation date of the object.
Answer 3. Check QSYSOPR messages for if users are signing on wrong more than X number of times. The system value QMAXSIGN and QMAXSGNACN for when this happens....they may be set to disable your user profiles. You would also get a msg in QSYSOPR msgs if this happens.
Question: I would like to create a program to change group profiles on the fly. The idea is to create a generic menu that will allow a user to have one user profile and password but be able to get into different softwares. 1- BPCS 2- Payroll, each software requires a different library list and different group profile. I thought I could just do a chgjobd for the job description to pick up the new library list (?), but how can I change the group profile?
Answer 1. You might look at QWTSETP API to change effective user profile for the job. You will have two user profiles and switch between them under the covers. Of course, this will require additional password maintenance.
You can find API's descriptions in a set of API books. Books can be found either on softcopy library CD or directly from IBM online library http://as400bks.rochester.ibm.com/. Look for a bookshelf named "Systems Programming Support Bookshelf". This particular API is in the book " OS/400 Security APIs".
Answer 2. Changing the Group Profile attribute for a User's Profile requires *SECADM special authority. It would be possible to have your menu program call a program, that would run under owner authority and be owned by a profile with *SECADM authority, that could change the User's Group Profile. But I wouldn't do it.
CHGJOBD is not used to change a user's library list, it is used to change the attributes of a JOBD.
I would break your problem into it's two parts: For the LIBL, each menu option needs to do it's own CHGLIBL to set up it's needed LIBL. If you want to be more polished, before the CHGLIBL do a RTVJOBA USRLIBL(&LIBL) and store it in a DTAARA in QTEMP so you can put it back the way it was when the user comes out of the menu option.
For the Group Profiles, I would challenge why and how they are being used. With BPCS, if you have a Group Profile called maybe SSA that everyone belongs to and it has complete access to data files, then from a security perspective you are very vulnerable to any non-BPCS interfaces, i.e.. ODBC, FTP, data-transfer, etc. I would recommend looking at implementing Object/Resource control with programs adopting authority to control data access. Then most users don't need to belong to any groups. That said, another area you may want to look at is Supplemental Groups. You can now set up a profile so that it gets group authority to objects from more than one group.
Answer 3. CHGJOBD will not change the library list on the fly. The user would have to signoff and signon again for the change to take effect. The simplest way to change library lists would probably be to use the CHGLIBL command from a CL program associated with the menu options.
As for changing the group profile, the CHGUSRPRF command would do it, but I think that too would only take effect after signing off and signing back on. I would look into having one group profile for all software packages.
Question: I notice that IBM recommends that the QSECOFR and QSYSOPR
profiles not
be used. They instead recommend creation of alternate profiles
for
these.
I don't really know the reasoning behind using a different profile instead the system supplied ones. Anyone know why?
Answer: This protects against someone guessing user IDs and passwords. Using a profile with a different username means one more thing for a hacker to guess. As always, pay close attention to which special authorities are actually needed by users, and audit those with certain ones - secadm/allobj especially.
Question: Is it possible to look up an AS400 user's password within the system? Any input on this will be appreciated. Thank you. (6/2000)
Answer 1: Essentially no. There are some hackers who claim to crack AS/400 passwords with brute force, but the risk of this kind of attack will always exist, unless IBM extends the character set or length of passwords in the future.
Answer 2: Passwords are stored on the AS/400 in encrypted form. There is an API to retrieve the encrypted password. The encryption method is DES. Due to the limited character set allowed in passwords, the password can be decrypted on a modern PC in a few hours.
BTW: if you apply any or all of the rules for passwords controlled by the QPWD* system values, you make the decryption easier as you diminish the key space. A long password is not more secure than a short password. What I really mean to say, though, is that since the password is encrypted in pieces, it is the size of the largest piece (7 characters) that determines the time. The 8th, 9th, and 10th characters are part of the last piece (only 3 long - so decrypts in seconds)).
A 7-character piece only takes a couple of hours on average.
Answer 3: Just a few days ago, a 17-line RPG-IV program was posted to MI400-L that sniffs user IDs and passwords as they sign on to the system. I tried it, it works. I understand that it works at security level 30 and below and for user classes that 95% of the AS/400 shops out there use. From what I can tell, the author has managed to get this to work at level 40 with the same features as the code published the other day and at level 50 with the program changed to a system state program.
The signon program reads a screen buffer with your user ID and password you just typed. The contents of that buffer hangs around until signoff or another signon (when it will contain yet another password !). A general principle of secure working is the erase the contents of all buffers and variables as soon asthey are no longer needed. IBM violated that simple principle.
This is real, folks. Any programmer in your shop can do this. With a 17-line RPG-IV program! I remember the flap awhile ago with the brute force password cracker; too much trouble and too prone to being discovered. But this monster appears to give me all the anonymity I need. A little patience to sniff out all the ID's & passwords and, with any luck, get the QSECOFR or any other UserID with security officer privileges.
Question: Is there a solution for the password sniffing problem just mentioned? (6/9/2000)
Answer: IBM is working on a solution to the password sniffing problem. PTFs should be available soon for all supported releases. For product 5769SS1 (OS/400), the V4R3 PTF number is SF62894, the V4R4 PTF is SF62895, and the V4R5 PTF is SF62896.
After you apply the PTF for your system you will need to activate it by terminating and then restarting all subsystems that perform interactive work. Doing an IPL is one way to do this. Since your passwords may have been compromised, after applying and activating the fix, you may wish to change the passwords on your systems.
Subsystem monitor jobs use a single open for each 250 or so display devices. So for example, if the subsystem supports 600 display devices, there will be three opens and three input/output buffers. Each buffer is used for the sign-on screens for only one set of devices.
The fix provided by the PTFs is to blank out the password in the buffer
immediately after it is read into a local variable. The program that does
this already blanked out its local variables when it was done verifying
the users sign-on password. Not blanking out the password in the
input buffer was an oversight. I will not try to offer an excuse for why
the developer missed this. (I am not that developer.)
Or is the security level at the library used for all objects under it. My understanding is that the library *USE means the user can use all objects under it and that the security of the files (objects) is used to check what the user can do to the file.
Answer You are correct, having Use to the library means you cant add objects to that library, but if a file has *PUBLIC *CHANGE inside a library that you only have *USE to, you can still change the data in the file
*USE at the library level will let a user pretty much do anything to an object in that library that is not excluded by authority on that object. One exception I've found is the ability to add a member to a file, which requires *CHANGE at the library level.
*USE on the object level only lets a user read data in a file - not
change it. Note that they could download the file to a PC (but couldn't
upload & overlay). So take this example:
Library authority *USE
FILE1 - *PUBLIC *USE <- USER1 can read file
FILE2 - *PUBLIC *ALL <- USER1 can change data in file
FILE3 - *PUBLIC *ALL, USER1 *EXCLUDE <- USER1 cannot access file
Question. I would like to find (if one indeed exists) something that has a listing of all the CL commands and what authority they need to run them. Is there such a thing out there? I have looked in all my CL reference guides with no luck.
Answer 1. Appendix D. Authority Required for Objects Used by
Commands in OS/400 Security - Reference SC41-5302 contains the list of
commands and authorities required.
(http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QB3ALC02/CCONTENTS)
Question: I am in the process of securing some of our data and was wondering if someone could answer if the following assumption would be correct.
I have
LIBRARYA with FILE1 and FILE2. LIBRARYB with VIEW1 which points to FILE1 and FILE2 in LIBRARYANow for the fun part. USER1 does not have any authority to LIBRARYA at all but does have *USE authority to LIBRARYB and VIEW1.
Would USER1 be able to view the data from LIBRARYA in FILE1 and FILE2 through VIEW1.
Answer 1. NO WAY.
Your user profile would be able to "see" object description or member description of logical, but it won't be able to retrieve data from library in which physical file resides unles it has at least EXECUTE rights to that library. It also has to have "READ" right to physical file.
Question. *PUBLIC's authority to an object is stored in the object itself. But where exactly is it kept? If you do a DSPOBJD to an outfile, it doesn't show up as a field in the outfile, does anyone know how to retrieve it?
Answer 1. Use the command DSPOBJAUT
Answer 2. Object authority is stored in the Header. Try using
the DMPOBJ command ... It shows the *PUBLIC authority attribute. Here is
an example DMPOBJ listing...
See under " SPACE- " ... the value of *USE is the *PUBLIC authority
to this object...
SPACE-
000000 C0E80000 04200001 00000000 00D50000 00000000 00005CE4 E2C54040
40404040 *{Y N *USE *
000020 00000000 00000000 012B0000 00000000 0000003C 00000100 40000000
00F0F9F8 * 098*
This dump seems to vary by object type. If you dump a database file you get the space information. If a display file you also get the space info, but the public authority seems to be in a different place. If a program, no space information, no public authority. This doesn't seem to be a very general or reliable method, and you might get changes from release to release.
Answer 2 Footnote. The authority is stored differently according to different object types. The architected method for fetching the public authority is the MATAU instruction which is exposed via the QSYRUSRA API DSPOBJD shows the information returned by the MATSOBJ instruction (and some other stuff). It is interesting that the MATSOBJ instruction will return authorization list information but not public authority.
Answer 3. The Retrieve User Authority to Object (QSYRUSRA) API supports the special value *PUBLIC for the User profile name parameter. The List Users Authorized to Object (QSYLUSRA) API can also be used to determine public authority as the first entry returned in the list is for *PUBLIC. Both APIs are found in the Security chapter of the System API Reference.
Question: We just received the *official* findings of an audit that was done in June of this year on our Model 530 AS/400. In his findings, the auditor is wanting the system value QCRTAUT changed from *CHANGE to *USE....
According to Al Barsa's COMMON handout on system values, the CRTAUT parameter for the libraries QSYS and QGPL should be changed to *CHANGE before changing the system value. Are there any other IBM supplied 'Q' libraries that I should be concerned about changing as well???
Answer: I have recent experience in changing QCRTAUT to *EXCLUDE, and with two notable exceptions it has been a breeze.
The exceptions are device creation and message queue creation. Because both QSYS and QUSRSYS have been changed to *EXCLUDE, we have to manually authorize folks to newly created device descriptions and their associated message queue's. This is not a big problem as there is the system has Authorization Lists for both of these object types. We just have to remember to add newly created Device and Message queue's to the list.
Question: We are looking for a way to secure our files from ODBC, DFU, File Transfer etc etc What I would like to do is restrict user access to the files to using programs only. I would like to give the programs access to the files and not the user. We have been a S36 shop and are converting over and as part of this conversion would like to secure all production files from unauthorized access. The S36 setup is really poor security.
I know I can restrict the commands that will access the files CPYF, DFU etc but there are more and more ways to get at the DATA and if you miss one (such as FTP) then you really don't have any security.
Also certain people (Programmers) will need to use some of these but not on production files.
Answer 1. One way to secure files from access other than by programs is to have them owned by one user profile. This profile is not a group profile. Then all your programs use that user profile. For example:
CHGOBJOWN OBJ(FILELIB/FILEA) OBJTYPE(*FILE) NEWOWN(SECUREGUY) GRTOBJAUT OBJ(FILELIB/FILEA) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE) CHGOBJOWN OBJ(PGMLIB/PGMA) OBJTYPE(*PGM) NEWOWN(SECUREGUY) GRTOBJAUT OBJ(PGMLIB/PGMA) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE) CHGPGM PGM(PGMLIB/PGMA) USRPRF(*OWNER) USEADPAUT(*YES)Answer 2. Check out adopted authority. Some don't like it but you essentially revoke all authority to all data files to all users. Grant file authority to the creator of a program, grant the user authority to the program and have the user adopt the owners authority during the running of the program.
This way even if a user is granted authority to DFU, they are blocked at the file level. The only DFU that could be run against a file would have a CL wrapper and appropriate authorities.
Answer 3. I've just been wrestling with this also. You can certainly use adopted authority to access the database, but look at the security APIs. It will get pretty complicated if you try to adopt the program owner's authority. I rejected this because it doesn't seem to work very well with the package software that we have, but it may work for you. Here's what I've come up with so far:
Only grant update access to the objects that the user will actually be updating. We allow read access to virtually everything else (company policy), so there are plenty of spreadsheets, Access databases and crystal reports. That's a good use for ODBC.
For interactive users, remove the command line, only let them run the programs that they need to run in order to do their jobs, and make them use the menus. They're all LMTCPB(*YES).
Use exit programs to prevent updating of ANYTHING in a production library by ODBC or FTP unless the exact command has been registered as a permissible command (not really as difficult as it sounds, but I still have some work to do on that part). The preferred method of updating the data is via server programs on the AS/400. Remember that Client Access users can issue commands using Remote Command regardless of whether they are defined as LMTCPB(*YES), so exit programs are essential here.
Since FTP enforces the LMTCPB setting (ODBC doesn't), and since some file transfers require an AS/400 update job to be invoked, provide a special version of the CALL command that allows LMTCPB users to run it, in a library that has no public access, and is available only to a very special user profile that can do nothing but run little FTP transfer jobs. Command line FTP scripts work well for this. The login and password can be put in there without risk, because the user can't do anything but run the little jobs that he's authorized to run and other users can't get at his stuff either.
Oh yes, Level 40 for QSECURITY, passwords must be changed every 60 days, tear down the postit notes that are pasted on the side of the monitor, and deactivate device and user profile after 3 invalid login attempts. A little missionary work is probably helpful too, so that users understand that you are protecting their jobs, not making their lives more difficult.
Question Are there problems with having one profile own a lot of objects?
Answer: Beware of having one Profile owning all objects. There is a limit as to the amount of space that the "security table" associated with a profile can occupy. As objects are deleted, their space in this table is not recovered/reused. The only way to recover the space is to "crash" the machine, the IPL will rebuild the table.
Some sites with a VERY LARGE number of objects, have had problems with this - this is NOT an academic issue.
Question: What are some of the pitfalls of using the adopted authority approach ("application only access") to production files? In this approach, users have no rights to application database files. All programs adopt the authority to access appropriate files, and only authorized users are allowed to execute these programs.
Answer: Here is a short list of pitfalls to avoid;
A) Don't have one profile own everything on your system. Separate ownership by applications (or some other logical business delineation). This provides for more granularity in your security design, and prevents having one profile own too many objects.
B) Don't have the same profile own the data and the 'adopting' programs. If you do then users will effectively have '*ALL' authority to the entire application. Better to have one profile own the all data and all 'un-adopted' program objects. The grant a second profile (the adopter) appropriate (*USE or *CHANGE) rights to the data. Now when users call the adopting program they have *USE, or at the most *CHANGE rights to the data rather than *ALL.
C) Neither of these profiles should have passwords. Their only purpose is to own objects.
D) The profiles should not be group profiles for any system user. You don't want users to inherit *ALL authority to any of these objects.
E)To restrict access to entire applications, secure at the library level. It's fast, it's easy to do (and undo if you must), and it requires little long term maintenance. I'm convinced that overall AS/400 security could improve by a phenomenal percentage if System Administrators would just lock library authority down. *PUBLIC *CHANGE access to a library seems awfully excessive, but you'd be surprised at the number of shops I've run across that are configured this way.
The above scheme works well if your users don't expect to get directly at the data using some AS/400 or PC query tool. If users do use query or other report writing tools, they will need a front end built for them that provides them access to the specific data that they expect to query.
Question: Is there a good alternative to "application only" security?
Answer: Another option that can used instead of, or in conjunction with, the ideas laid out above is to use exit point programs to secure ODBC, FTP, RMTCMD, etc. Exit point programs can control who is allowed to read, update, and even delete files that are accessed from remote systems. There are exit points for Client Access servers (yes, there is even one now for non-IBM ODBC drivers!) as well as for DDM and TCP/IP connections. You can certainly write your own exit programs, but if you'd just like to buy a solution, many vendors sell exit point packages that can handle this for you.
Question: I'd like to set up someone as a security officer, but exclude them from certain libraries (such as payroll). What is the best way to go about doing this?
Answer 1. Does this guy really need *ALLOBJ authority, or can he get by with *ALL authority to select LIBRARIES and FILES?
Utopian Answer: One of my former bosses once said to me, when this issue came up, (paraphrased) "Wouldn't it be great if we could just post everyone's salary on the bulletin board? No politics, nothing to hide. You can only do that, though, when noone's being treated unfairly and noone's being favored. Unfortunately, that seems never to be the case."
Answer 2. If you user profile has *ALLOBJ special authority then you cannot restrict access to libraries. Typically a *SECOFR user will have *ALLOBJ.
Here's what you can do:
This works because of the sequence that that the authority is checked. I have an old redbook that lists the Authority search order:
USER PROFILE
Answer 3. If you give a user profile *ALLOBJ, it is impossible to keep them out of any library. *ALLOBJ really means All Object. The user can read anything. An enterprising user with just *ALLOBJ can quickly gain any other Special Authority that they desire.
Consider using adopted authority instead to give them the extra authority they need in a tightly scripted adopted authority routine. This will prevent them from getting too much authority all of the time. If you describe why you want to give them this secial authority, someone may have a way to accomplish your goal.
If you must give them *ALLOBJ, don't give them *AUDIT (or any other special authority they don't absolutely need). Then audit either their User Profile or the objects that you are concerned about. Tell the user that you have turned on auditing and that any attempt to access the payroll library will result in corrective action. (*SWAT!)
Question: We need to set up a development lib for a contractor how do we protect the rest of our data and programs? (1/2000)
Answer: Use an authorization list, to provide *EXCLUDE authority for the programmer to specified libraries. Although not a perfect fix, it's cheap and effective.
Answer 1. TAATOOL has a nifty command called - PRTADPPGM
Answer 2. Try GO SECTOOLS. If you roll down, option 21 might prove useful.
Answer 3. Yes and no. The DSPPGMADP can show programs that adopt a specific user profile, as in compiled *OWNER and can put it to a file. Otherwise, its into the APIs for you. Check on QCLRPGMI, retreive program information. The PGMI0100 format has the information that you are looking for. Of course, it isn't a file, but because it uses a receiver variable, you could code this in a CL program.
Answer 4. You can't do it by library, but you can do it by user profile. The PRTADPOBJ command allows you to single out a particular user, or specify *ALL users. Unfortunately, the PRTADPOBJ *ALL option prints all of the IBM user profiles as well as the all of your users.
But with a little CL like the one below, you can do the PRTADPOBJ on only the user profiles that you care about. You just have to create the file called USRPRFS in advance and populate it with the names of the profiles that you want to run the report on....
PGM DCLF USRPRFS ReadLoop: RCVF MONMSG CPF0864 + EXEC( RETURN ) PRTADPOBJ USRPRF( &USRPRF ) GOTO ReadLoop ENDPGMQuestion: I am needing to write a program, command, or whatever, that will enable my users to adopt a higher authority when they want to delete or vary on/off a device. All the users will be at *USER. What would be the best way for me to do this?
Answer 1. Give the folks that need to do that *IOSYSCFG special authority.
(Note, according to another post, this doesn't do it. IOSYSCFG doesn't provide authority to the objects themselves. Create commands to handle these which adopt authority and call the OS/400 native commands. Restrict access to these commands.)
Answer 2. Create a program do do the desired function and compile it with with USRPRF(*OWNER)... after the *PGM object is compiled, change it's owner to that of QSECOFR.
Then, when this program is run, the authority of QSECOFR will be used to run the program.
Ensure that the program can ONLY do what you specify... Programs like this should be very limited. Don't do anything other than the function that requires the extra authority, and never allow access to a command line while the program is active.
I would recommend that you qualify any commands (VRYCFG, etc) with the appropriate library (QSYS/VRYCFG).
Answer 3 (combines answers 1 & 2). To change or delete a device the user must have *IOSYSCFG special authority. If you want to adopt this authority (a good choice), The look at the CRTxxxPGM command and/or the CHGPGM commands. There is a parameter called USRPRF that defaults to *USER (run under the authority of the user). You can change this parameter to *OWNER (run under the authority of the program's owner). You'll then want to change the ownership of your program (CHGOBJOWN) to a user profile that has *IOSYSCFG special authority.
Question (multipart): I've got two 'adopted authority' questions:
PRG-AUTH adopts authority, PRG-NOAUTH doesn't.
1. If PRG-AUTH calls PRG-NOAUTH, does PRG-NOAUTH run with the users authority or with the authority adopted by PRG-AUTH?
2. If PRG-AUTH transfers control (TRFCTL) to PRG-NOAUTH, does PRG-NOAUTH run with the users authority or with the authority adopted by PRG-AUTH?
Are there any gotchas with either scenario?
Answer 1 part 1 In this scenario PRG-AUTH remains in the stack above PRG-NOAUTH so PRG-NOAUTH uses the adopted authority of PRG-AUTH.
Answer 1 part 2 In this case PRG-AUTH is no longer in the stack so PRG-NOAUTH does not adopted authority from it. Answer 1 part 3 In order to adopt authority the USEADPAUT parameter of PRG-NOAUTH must be set to *YES. If it is set to *NO the program will be unable to adopt authority from a program higher in the stack.
Question: I have a batch job which is run by the user but needs to use a file with security denied to the user. Somewhere I heard or read about adopt authority, which would allow the job to use the file if the adopted authority was granted
Answer 1. Happens all the time in packaged software. Change the owner of the program to a profile that would have authority, then use the change program command with adopt authority *yes and usrprf *owner.
CHGOBJOWN OBJ(PROGRAM) OBJTYPE(*PGM) NEWOWN(QSECOFR) CUROWNAUT(*SAME)
CHGPGM PGM(PROGRAM) USRPRF(*OWNER) USEADPAUT(*YES)
Question: While doing some testing I found several system facilities that ignore adopted authority, several areas have work-arounds, but triggers in particular do not. At this point I suspect that adopted authority is only viable in a discrete application. Does anyone know where I can find a list of system supplied programs and functions that ignore adopted authority? Are there any other ways to end adoption other than the specifying USEADPAUT(*NO) on the program or MODINVAU MI instruction? If there are no other ways to end adoption, is possible to find all programs that use MODINVAU? (4/2000)
Answer: To find out programs that use MODINVAU, try this command DSPPGMREF
Answer 1. Spool file security is quite a bit different than usual AS/400 security.
First, The user should not have any special authorities, especially not *SPLCTL *JOBCTL or *ALLOBJ. (OK their are ways to secure an outq when the user has some of these special authorities, but I'm giving you the fast path).
Then create (or change) the OUTQ's in question so that "Authority to Check" parameter is eqaul to "Data Authority" (Ex: AUTCHK(*DTAAUT)) and the "Display Data" parameter is equal to yes (Ex: DSPDTA(*YES)).
Then set the object authority on the outq to *USE for that user. This will give the user read authority only.
Question: We have some output queues we wish to secure. The problem is several users have *SPLCTL and *ALLOBJ. We want to secure an outq such that only specific users can view/change spool files in that queue. I've created an outq with public *EXCLUDE, and added an authorization list to it. I've revoked my ownership of the queue to QSECOFR. Even if my name is not on the authorization list, I can still view and change spool files in this out queue. My profile has *ALLOBJ and *SPLCTL, among others. What are my options?
Answer 1. remove *ALLOBJ
Answer 2. You've almost got the worst of both worlds here. If a user has *ALLOBJ authority, there is no way to prevent them from seeing an out queue. You can however prevent an *ALLOBJ user from seeing or changing _entries_ in a queue by creating the queue like this:
CRTOUTQ OUTQ(QGPL/SECOUTQ) DSPDTA(*OWNER) + AUTCHK(*DTAAUT) OPRCTL(*NO) AUT(*EXCLUDE)(Note: example shamelessly lifted from the Security Reference manual) In this example, only those people who own a file may access the file.... unless the user has *SPLCTL special authority.
*SPLCTL compounds this issue. Even if you take away *ALLOBJ, *SPLCTL can be viewed as *ALLOBJ for spool files. Just as it's impossible to protect an _object_ from an *ALLOBJ user, it is also impossible to protect a spool file from a *SPLCTL user.
By way of a solution, you might consider taking away *SPLCTL authority from all interactive users. One view is that *SPLCTL is almost never needed for an interactive profile. You might use it for a dedicated batch processes that works with spool files, but for an everyday interactive profile it is definitely overkill. A user with *JOBCTL special authority can work with the entries on an outq that is defined as *OPRCTL(*YES). Isn't this enough authority for what they need to do?
We map a network drive to our system's root:
\\CSCNJ
When she clicks on QDLS is says access denied?? Any ideas??
Here is some of the things that we tried:
Delete all the *.PWL files
Cleared the CA/400 password Cache
Response 1. Is she in the AS/400 directory?(WRKDIRE). (note: turned out to be the most useful response in this particular case)
Response 2. Is she enrolled as a CA user on the AS/400?
Response 3. What userid is she signing on as. Do a WRKACTJOB and make sure it is her userid that is signing on. Also, make sure that she has a Directory entry, and the directory entry points to the right user profile.
Question: I'm having a little trouble with IFS authorities, and can't quite find the source of the problem. Any help would be greatly appreciated.
I'm looking at providing a programmer profile (*JOBCTL only) with individual authority to copy something out of an IFS directory and I'm having a devil of a time with (I think) the target authority.
The specifics: User profile JOHN is trying to copy a "Hello.java" from "/QIBM/ProdData/Java400/com/ibm/as400/system" into directory "/john" that user profile JOHN created and has ownership authority over. Message CPFA09C is issued saying ' Authority is not sufficient to access object *N.' Any idea's on how I find out what *N is?
I'm guessing that there must be a rule about authority needed to the parent directory structure, I just can't put my finger on it.
Answer: The user profile doing the copy needs to have *OBJMGT authority to the source object in order to get the authority attributes of the source, in order to copy them.
Side Note on IFS Authority: Apparently IFS authorities differ from native DB2 authorities in that you must have *OBJMGT in order to copy a file. The IFS function must be more similar to a CRTDUPOBJ than it is to a CPYF.
Question: Has anyone noticed that you cannot assign a group profile as the owner of an IFS directory or object with OpsNav? You can with WRKLNK (actually CHGOWN) on the green screen. Once you assign it there you can modify the permissions within OpsNav, but Group Profiles are not available to be selected as owner. (12/99)
Answer: The best I've found so far is to use the CHGAUT command with '/dir1/..../*' for the object name. That gets all files and directories in the specified path. Be sure to do the CHGOWN command (same syntax) first and the CHGAUT command second. You still need to chase the subdirectories yourself however. (F9 is your friend!).
If you map the drive to a PC and do DIR /F/S > dirfile (works in OS/2 anyway) you get a file with just the list of files all the way down the tree. You could upload this to the 400 and read it in a CLP processing each record. That'd save some typing!
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.
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.
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, or you take a look at software available at PowerTech. You might look at two additional products. One is available from KISCO, they have a website at http://www.kisco.com. The other is available from Pat Townsend.
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.
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: Try SECURE/NET from Palace Guard Software. Its
a cool exit point suite..
very easy to use. www.pgsas400.com
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.
Answer: Yes, but you must write a data structure as same as it in the C header file. The C header file is H/QSYSINC. This include is also available for other languages in QSYSINC/QRPGSRC, QSYSINC/QRPGLESRC, QSYSINC/QLBLSRC, and QSYSINC/QCBLLESRC.
Question: I have been asked to find out how AS/400 users can change their passwords using a web browser application. We will synch user info to the NT Domain server to enable validation and signon. The AS/400 passwords expire every 30 days. The users must be able to maintain their passwords without leaving the web application (a combination of Cold Fusion, Javascript and HTML). Off the shelf packages are OK, or IBM supplied API that support some sort of encryption (we don't want passwords xmitted over the internet in the clear.) Any and all suggestions are appreciated. (12/99)
Answer 1: If Java is an option then you can use the Java ToolKit for AS/400. The code used to exchange and/or change passwords is encrypted out the wazoo before it is sent over the net. Unless you are going to use some sort of strong encryption for sending the password from the browser (implemented in an applet) to the http server I would suggest supporting SSL on the www server.
Answer 2. There are two API's, from V3R7 that allow you to send encrypted passwords form one machine to another. QSYRUPWD (retrieve encrypted password) and QSYSUPWD (set encrypted password). These two API's can (and are meant to) be used together to sync passwords between AS/400s
QSYRUPWD retrieves the DES5 encrypted version of the password from the user password table. This value is already encrypted.
QSYSUPWD sets a users password (using an encrypted value retrieved by QSYRUPWD) in the table to the supplied value. At no point is the password decrypted in to the plain text form.
Passing this encrypted value over the net work should be fairly safe (as safe as passing any encrypted data can be) I my self would probably double encrypt it with another public domain routine (such as Blowfish) just to obscure the data even more.
One thing however, is to ensure that the multiple systems that you are trying to sync passwords between are using the same password limiting system values, to ensure that the passwords can be sync'ed.
1. PRFMON is getting a Authorization Failure (code A = Unauthorized Object Access Attempt) accessing the library ODS400. What functions does PFRMON access individual libraries for?
2. Another Job is getting an Authorization Failure (code D = A program accessed an object through an unsupported interface or callable program not listed as a callable API). We are getting _flooded_ with these in QAUDJRN. QAUDJRN is about a GB/day. This is a vendor program, we have no source, and no response from the vendor yet.
Answer 1. Some programs try to get authority to every library in your library list. This is true with IBM's program when you STRTCPSVR (either *DNS or *DHCP - I forget which one) as an example.
The work around was to make sure there are no user libraries the job's library list.
Answer 2. Item 2 looks like you are running at level 40/50 with 3rd party software that does not support that level.
Question: I have some programs that are doing security like functions.
To stay ahead of the auditors I would like to write entries to the security
journal.
1.) Can a user application write to QUADJRN?
2.) If so, how?
Answer 1. Any user can basically write to any IBM journal. All journals are the same object type. However, the security audit journal (AUDJRN) is one that contains basic security information based on how the values and auditing levels are set.
You can write to a journal (including QAUDJRN) through the basic IBM command of SNDJRNE. Be aware that any entry you write in this fashion is always a "U" code entry (user entry). You can include any type code you desire.
Answer 2. The Send Journal Entry (QJOSJRNE) API can do this. It is documented in the Journal and Commit APIs chapter of the System API Reference.
A sample insertion from the command line would be:
call qjosjrne ('QAUDJRN *LIBL' x'00000000' 'User test' x'00000009' x'00
000000')
which with DSPJRN JRN(QAUDJRN) FROMTIME('1998/12/09') shows:
91179 U 00 QPADEV0025 10:24:54 and Column *...+....1....+....2....+....3....+....4....+....5 00001 'User test'See the API documentation for more options that the API provides.
Question: I have a requirement to audit particular OS400 commands - across all users. Is there any simple way to do this?
Answer: By doing a CHGOBJAUD on the commands you are interested in, and then turning on system value QAUDCTL.
Question: My company is considering buying some application for auditing our AS/400 systems. Can you share your opinions about available products, any cons or pros for using given/any at all third party solution (vs. just copying security journal to database files and querying them...).(6/2000)
Answer 1: Pentasafe is an AS/400 product that could be used to do a variety of things. It has basically automated everything that you could check. One problem however, is that it is very steep price-wise.
I would recommend doing it in house unless you get a lot of pressure from up above to secure your environment. Exit points, journalling, etc. can be used to monitor and maintain security.
Answer 2: For a proven and cost effective solution, check out Rapport Software's Audit Master ( www.rapportsoftware.com). They've been selling AS/400 auditing software in Europe since the beginning of the AS/400.
If you're also interested in auditing network traffic into your AS/400, checkout our PowerLock Network Security software. The audit portion is free, and can be downloaded from our website at www.400security.com. It also interfaces nicely with Rapport's Audit Master.
Question: What AS/400 Journals, programs or methods, if any, will audit programmer jobs? (12/99)
Answer : Have you tried walking past the person's desk to see
what they're up to?