Carol explains why you need to be concerned about profiles' limited capability setting when considering the risks FTP poses to your organization.
Many IBM i shops continue to allow FTP to be run by all users (or I should say have done little or nothing to ensure only selected users can use FTP). The excuse that some administrators use is that their users have been configured as limited capability users, so what's the threat? This article describes the threat, even when a user is a limited capability user.
What Is a Limited Capability User?
If you're not familiar with IBM i security or you're new to the platform, you may not be familiar with this user profile setting. The limited capability attribute of the user profile has three values: *YES, *NO, and *PARTIAL.
The value *YES means that even if users can get to a command line, they can run only the commands that have been configured as "Allow by limited capability user." IBM i ships six commands that can be run by limited capability users: Signoff (SIGNOFF), Display Message (DSPMSG), Display Job (DSPJOB), Display Joblog (DSPJOBLOG), Start PC Organizer (STRPCO), and Work Message (WRKMSG).
*NO means that the users can run any command (assuming they have the authorities required).
*PARTIAL means that they can run any command, but they're restricted from changing the Program, Menu, and Current library parameters on the signon screen that's provided with the system.
FTP and LMTCPB
So what does FTP have to do with limited capabilities? Isn't FTP just sending files to or getting files from the system? The answer is no. There's more to FTP than sending and receiving files. Within FTP is a remote command feature that allows you to run commands. So perhaps now you get the connection? On IBM i, users set to limited capability *NO cannot run commands. So does this apply to the FTP remote command feature? The answer is yes…and no!
FTP Remote Command Function
Part of the FTP protocol includes functionality called subcommands. These subcommands allow you to perform tasks once you've established the FTP connection. Examples include DELE (Delete) and PWD (Password). If users can establish an FTP session, they can run one of these subcommands no matter what their limited capability setting is. In other others, the FTP remote command server ignores the profile's limited capability setting. The full list of the FTP subcommands can be found here.
However, the remote command function is not restricted to just the FTP subcommands. Users can also run IBM i commands. For example, after supplying a valid user ID and password, users can run the Create Data Area (CRTDTAARA) command by running the following at the FTP prompt:
quote rcmd crtdtaara test *char 10
Or if the users have *SECADM and *ALLOBJ special authorities, they can run this:
quote rcmd crtusrprf power spcaut(*allobj)
The difference between running these commands versus an FTP subcommand is that the user's limited capability setting is checked. So if users configured as LMTCPB(*YES) attempt to run the commands above, they will fail.
We've now established that the FTP subcommands ignore the limited capability setting but running an IBM i command will honor the limited capability setting. So where's the confusion? The confusion comes because some IBM i commands have been added to the IBM i FTP subcommands. At the end of the IBM Knowledge page, the IBM i commands that have been added to the IBM i FTP server are listed. You'll notice commands such as CRTLIB (crtl) and DLTLIB (dltl) have been added. This is where the confusion starts. Because these commands have been added as an FTP subcommand, the user's limited capability setting won't be honored when those commands are run.
FTP clients come with all Windows installations, and there are many browser plug-ins that make using FTP as easy as dragging and dropping from one window to another. So how best do you control FTP? Obviously, just setting a user to be Limited capability *YES is not a complete solution.
The best solution, of course, is to implement object-level security (especially for files containing confidential or private data) and assign special authorities only to the users whose job function requires them. When you implement object-level security, regardless of whether you're trying to access the object via FTP or other protocols, if the users aren't authorized, they can't download the file, modify it, or delete it.
However, there are times when you may want to control the use of FTP specifically. In this case, you have several options. If you aren't using FTP at all, you can stop the server (ENDTCPSVR *FTP) and change the auto-start parameter so it doesn't start backup with the rest of the TCP/IP servers (CHGFTPA AUTOSTART(*NO)). If you need to use FTP and want some users to be able to use FTP and not others, try using Application Administration. Option up iNavigator, right-click on the system name, and choose Application Administration. Click on the Host Applications tab. Open TCP/IP Utilities for iSeries, and you'll be given options for controlling various functions of both the FTP Server and FTP Client on IBM i. Think of Application Administration as being an on/off switch for FTP. Through Application Administration, you can either allow or disallow a user to use features of FTP. There's no ability to allow users to download everything except a specific file, for example. If you need any type of granular control or want detailed logging, you'll have to use an exit point solution.
FTP can be easily used to exploit any unsecured files. I hope this article has helped you see that depending on a user's limited capability setting is not sufficient to control what can be accomplished through FTP. You'll want to determine the data that needs to be protected and take action to secure those files appropriately.