Today, there are more ways to connect to your AS/400 than ever before. With the addition of TCP/IP servers, users are no longer limited to green-screen sign-on or even Client Access/400 (CA/400). That’s the good news. The bad news is that each TCP/IP server is a potential security loophole you are responsible for closing. This article examines security issues for one of these servers, the FTP server, and shows you how to get the level of security that’s right for your company.

FTP was developed as an easy way to move files across a TCP/IP network. While somewhat eclipsed by the HTTP (Web browser) protocol, FTP is still the easiest way to move files across the Internet or within your own corporate LAN or intranet. If you are moving big files between AS/400s within your network, for example, you should really be using FTP. It’s faster than SNADS, which uses the SNA standard to transfer files. Also FTP doesn’t have the SNADS 2-GB maximum file size limit.

At this point, you may be reading this article and thinking to yourself that this information about FTP doesn’t really apply to your shop, but are you sure? You may be running the FTP server and not even know it. If you are using TCP/IP to connect to your AS/400 with CA/400, for example, your system administrator may have unintentionally also started the FTP server. Many shops put the Start TCP/IP Server (STRTCPSVR) command with option SERVER(*ALL) specified, as well as the Start Host Server (STRHOSTSVR) command also with SERVER(*ALL) specified, in their IPL startup routines. If these commands are executed, you are running the FTP server. One way you can tell whether FTP is running on your system is to issue the Work with Subsystem Job (WRKSBSJOB) command, specifying the QSYSWRK subsystem. Look for any jobs named QTFTPxxxxx, where xxxxx is any sequence of numbers. If even one such job is present, you are running the FTP server.

FTP Security and Exit Points

IBM does provide some default security tied back to the familiar user profile. By default, if you can sign onto a terminal, you can log on with FTP. More specifically, if you know the user ID and password of an active user profile, even one with INLPGM(*NONE) (Initial Program), INLMNU(*SIGNOFF) (Initial Menu), and LMTCPB(*YES) (Limit Capabilities) specified, you can still log on with FTP.

If you are unfamiliar with FTP, you can get a feel for the default security with this little experiment. Assuming TCP/IP is active on both your PC and the AS/400, open a DOS box on your PC and type in the following command:

C:>ftp 111.2 22.333.444

In this command, 111.222.333.444 is the TCP/IP address of your AS/400. You should then see a message similar to the following:

Connected to 111.222.333.444
220-QTCP at MYSYSTEM
2220 Connection will close if idle more than 5 minutes

Next, you should see a message prompting you to enter your user ID and password:

User (111.222.333.444:(none)):MYUSRPRF
331 Enter password.
Password:xxxxxxx

This should be followed by a message telling you that your logon is successful:

230 MYUSRPRF logged on.

That’s really all there is to it. After you get the ftp> prompt, you are connected and can do all kinds of things on the AS/400. To stop your FTP session, issue the FTP command quit:

ftp>quit

Any Holes in Your Security?

If your company is like many others, you rely on menu systems and application programs for interactive job security. You may not even let your users get to the AS/400 command line. While this security approach may have been sufficient in the days of twinaxial connections, it’s an open invitation for mischief today. Just as you wouldn’t allow most users to upload and download files to and from your AS/400 by using CA/400, you also wouldn’t want to allow the general population to use FTP for data transfers.

Perhaps you are still not convinced this is a big security issue for your company. After all, your users are all professionals, right? No one would maliciously try to gain access, and you don’t have to worry about inexperienced users accidentally deleting files or entire libraries, right? Well, since TCP/IP is the language of the Internet and your corporate network is probably connected to the Internet in some fashion, millions of users all over the world could be on your system trying the little experiment you just conducted. Perhaps you have some user profiles with passwords that are the same as the user profile names. Maybe you haven’t gotten around to disabling the user profile for the employee who was just fired. These are just some of the examples of common holes in security that someone with a knowledge of FTP can exploit.

IBM realizes that default security may not be enough. To help you plug the holes, IBM has created a series of exit points that allow you to register your own programs, which will be called by the system to authorize logons and FTP commands. Once registered, whenever someone tries to log on with FTP or execute any FTP command, your program is called and passed a series of informational parameters. Your program processes the data passed to it and returns a flag that either allows or disallows the action.

Locating Exit Programs

Use the Work with Registration Information (WRKREGINF) command to display a list of the various system exit points. As shown in Figure 1, you Page Down until you see the QIBM_QTMF_SERVER_ REQ and QIBM_QTMF_SVR_LOGON exit points.

The QIBM_QTMF_SERVER_REQ exit point allows you to specify a program that is called to validate all FTP commands. Use this exit point in conjunction with the sample program MSCFTPRV to control the directories and libraries a user may see by creating classes of users with various authorization levels. You could easily extend the sample code to provide additional layers of security. The QIBM_QTMF_ SVR_LOGON exit point allows you to specify a program that is called whenever a user tries to log onto your AS/400 by using FTP. You will use this exit point in the next section to provide additional security on top of the default user profile security already provided by IBM.

Loading Security Software

As a practical demonstration of how you can customize FTP security, you can download the sample programs described in this article from the Midrange Computing Web site at www.midrangecomputing. com/mc/ and restore them. Once the files have been downloaded, follow the steps listed below to install the programs on your AS/400:

1. Unzip the .zip file on your PC.
2. To make things simple, unzip the contents of this file onto the root drive (C:) on your PC. Once the .zip file has been opened, you should see two files. One is named FTPSEC.SAV. This is an AS/400 save file, and it needs to be moved to your AS/400 and restored by using the Restore Object (RSTOBJ) command. The other is a README.TXT file. This contains the instructions you’ll use to upload the save file to your AS/400, and once it’s there, restore it. Follow the instructions in the README.TXT file.

At this point, you should have a library on your AS/400 called FTPSEC, with the five objects shown in Figure 2. You now have a decision to make. You can either move these objects from the FTPSEC library to a library on your system library list or add FTPSEC to the user portion of your system library list. If you choose the latter option, use the Work with System Values (WRKSYSVAL) command to display the system values. Find the system value QUSRLIBL (the user part of the library list) and enter a 2 next to it to change it. Add the FTPSEC library to the values in this system parameter. This is necessary because the FTP server runs under the QTCP user profile. QTCP uses the QDFTJOBD job description, which, in turn, specifies the system library list by default. Since changing a system value is a major step, I suggest you simply move objects from the FTPSEC library to either QUSRSYS or QGPL instead.

You’re in the home stretch now. All that’s left is to register programs with the appropriate exit point, add users to the MSPFTPUS file, and restart the FTP server. To register the exit points, follow these steps:

1. Enter the WRKREGINF command on an AS/400 command line and press Enter. You should see a screen similar to the one shown in Figure 1.

2. Page Down to the QIBM_QTMF_SVR_LOGON exit point, select option 8, and press Enter. If you are on V4R4, make sure you specify format TCPL0100.

3. Choose option 1 to add an exit program when the next screen appears, as shown in Figure 3. Type in MSRFTPSC as the exit program and press Enter. You should get a confirmation screen like the one shown in Figure 4.

4. Press Enter to complete the registration. Make sure you specify the correct library location for the MSRFTPSC program if you have moved it to QUSRSYS or QGPL.

5. Repeat steps 1 through 4 for the QIBM_QTMF_SERVER_REQ exit point, specifying MSCFTPRV as the exit program.

Setup

Use your favorite database tool, such as IBM’s Data File Utility (DFU) or ProData’s licensed database tool, DBU, to add users to the MSPFTPUS file. Put the user profile name in the FTUSER field. FTACTIVE must be set to A. If FTACTIVE is set to I, the user cannot use FTP, regardless of whether or not the user has a user profile on the AS/400. FTACCESS can be set to either F for full access or C for customer access. The MSRFTPSC program maintains FTLLOGIN and FTIP automatically to provide you with historical information on the last time that the user logged in with FTP.

The FTACCESS field deserves a little more discussion. The sample security program provided allows you to specify two classes of FTP users. Those with full access pretty much have the run of the place. Customer access is very restricted, in terms of both which directories they can see and which commands they can use. Customer access restricts users to operations on the /home/XXXXXX directory and subdirectories, where XXXXXX is the given user’s ID. For example, a user with ID SMITHJ would be able to issue the change directory command cd /home/SMITHJ, but that user would not be able to issue the command cd /home/DOEJ. The idea is that you could create a series of directories for customers that are protected from other customers and that protect your system at the same time.

The last step is to end and restart the FTP server by issuing the following AS/400 commands:

ENDTCPSVR SERVER(*FTP)
STRTCPSVR SERVER(*FTP)

Now, your new exit points are active, and your FTP server is locked down.

Operation

The sample exit programs model a customer FTP mailbox. Customers can log on and either add or remove files in their directories, but they cannot add new directories or execute host CL commands. For example, user SMITHJ would be able to execute the following sequence of FTP commands:

cd /home/SMITHJ/dir1
mget file*.txt
put newfile1.txt

However, the same user would not be able to execute any of the following FTP commands:

cd /home/DOEJ (different user’s directory)
rmdir /home/CHUCKY (cannot delete a directory)
mkdir /home/SMITHJ/dir1 (cannot add a directory)

In order for users to log on with FTP, they have to have both a valid AS/400 user profile and an entry in the MSPFTPUS file with the FTACTIVE field set to A. You also need to create directories for any accounts flagged as customer (FTACCESS set to C). All customer directories must be subdirectories under the /home directory in the AS/400 Integrated File System (AS/400 IFS). In the examples shown, users must enter their directories in uppercase (e.g., /home/SMITHJ). This is a restriction designed into the MSCFTPRV program. In any case, you can easily change the program to allow lowercase directory names if desired.

Troubleshooting

If you have trouble with the FTP server, such as requests or logons being rejected when they should be approved, check the job logs for QTFTPxxxxx jobs in the QSYSWRK

subsystem. If more than one QTFTPxxxxx job is present, check each job log until you find the relevant error messages. You may find that the MSPFTPUS file is not in the right directory or that QTCP doesn’t have authority to one of the exit programs. You may have to grant QTCP authority to the Get Profile Handle API (QSYGETPH) since the MSRFTPSC program uses this API.

The downloadable save file has a target release of OS/400 V4R3. You should be able to restore the save file properly on V4R3 or V4R4 systems. Since some of the programs use features not available before V4R3, the system does not allow objects to be saved with a target release prior to V4R3.

Test, Test, and Test Some More!

These sample programs provide a tutorial on how to set up security for your FTP server. While the sample programs are certainly better than nothing, you should not assume they are sufficient for your organization. For example, the sample security programs do not limit the number or size of files that a customer may upload to your AS/400. Determine the security requirements for your company, examine the source code of the samples, and make the appropriate changes. Above all, test and retest the security until you are satisfied.

Click here to download code.

Figure 1: WRKREGINF displays available AS/400 exit points.

OBJECT TYPE DESCRIPTION MSCFTPRV *PGM pgm for QIBM_QTMF_SERVER_REQ MSRFTPAC *PGM get user access information from file MSPFTPUS MSRFTPSC *PGM pgm for QIBM_QTMF_SVR_LOGON
FTPSRC *FILE source code
MSPFTPUS *FILE physical file for user setup

Figure 2: These are the objects you should have on your system when you restore the *SAVF.

Figure 3: Use this screen to add an exit program to the QIBM_QTMF_SVR_LOGON exit point.

Figure 4: Use this screen to confirm the addition of an exit program to the QIBM_QTMF_SVR_LOGON exit point.