More snippets of archaic and mostly outdated stuff… but worth saving online because I’m contsantly amazed by the lax security setup at some shops I visit:
AS/400 and Internet Security:
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 184.108.40.206.
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. .
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 ENDPGM
Question: 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
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.