Remember the IFS!

Image

Ask any security professional which area of IBM i security is most often ignored and chances are that the unanimous response is a chorus of “the Integrated File System.” Although it’s been around since V3R1, the Integrated File System, or IFS, remains a shrouded mystery that represents significant risk to many IBM i organizations.

One popular misconception is that the IFS is a separate and distinct file structure that was added to store and serve PC files, and if you don’t store PC files on your IBM i system, there’s nothing to worry about. Part of this misconception comes from the fact that when the IFS first appeared, the entire system save (GO SAVE, option 21) procedure was expanded to include an IFS save in addition to saving native objects and DLOs (the original mechanism used to serve PC files.)

The Real IFS

In reality, IFS is the umbrella term for all of the various file systems, including native objects in the /QSYS.lib folder and DLOs in the /QDLS folder. In fact, if you look at the help text for a full system save, you’ll see that an IFS save simply omits the paths to items already saved by traditional save commands. Technically, the entire server can be backed up by saving the IFS (although the Licensed Internal Code can’t restore the operating system if saved in that format).

IFS Security Risks are Real

So, why is there a security risk associated with the IFS? It starts with the fact that you work with the IFS using your normal IBM i credentials. The system interface doesn’t differentiate how a user profile accesses data. If you can sign on to a green screen application, you also can potentially access the IFS. As with network interfaces such as FTP and ODBC, if your native objects are secured using only menu or application-level security, a user may have sufficient object authority to read, change, or delete data; even basic read-only rights allow data to be leaked. This is because IBM i ships with a public authority default of *CHANGE. If your security administrators or application vendors haven’t secured your application objects (and most haven’t), users have unlimited access to the data.

It’s easy to access IFS directories using powerful tools like IBM Navigator for i and Windows Explorer, both of which provide users with the ability to exercise their full IBM i authorities. A user can casually delete a folder in Windows Explorer, only to find out later that it was an application library on the server. Unfortunately, there’s no recycling bin and no undelete for these folders. With permissive public authority and the common over-assignment of All Object (*ALLOBJ) special authority, this is an expensive mistake that can happen in the blink of an eye. If that’s not enough to make you sit up and take notice, be aware that activities that don’t violate the permission levels of an object typically aren’t audited!

How to Secure an IFS Folder in IBM i (AS/400)

Because IFS authority can be complex, time consuming, and prone to over-securing, the IFS often is ignored in a company’s security plan. It’s best if you make changes in manageable phases, and document changes so they can be undone if necessary.

So, what can you do and where do you start? In a recent blog, I said that the best security practices result from the synergy between three components: IBM i controls, Powertech solutions, and administrator deployment.

1. IBM i Controls

While it may seem that the “ball was dropped” with IFS security, the reality is that IBM i can protect an object (or “stream file” in IFS terminology) from any user or access method—but only if the authorities are configured correctly. IFS authority is built on a UNIX-type model and uses different terminology. Authority templates used to secure the data rights of native objects including *USE, *CHANGE, and *EXCLUDE are replaced with combinations of read (*R), write (*W), and execute (*X) permissions.

The following table shows a comparison between native IBM i and IFS data authorities.

IBM ships public permission to the base IFS folder (commonly referred to as the “root”) as *RWX. Change this to *RX to prevent users from creating new objects and folder structures in the root. The other IBM-supplied folder structures under the root typically are configured correctly and should not be changed.

The /QSYS.LIB folder structure contains the operating system and user libraries, and is the most sensitive folder in the IFS. Users rarely require access to this structure via the IFS. This is fortunate because they can do extensive damage in a short amount of time. IBM i has a special authorization list, QPWFSERVER, designed to prevent anyone without *ALLOBJ special authority from accessing this critical folder. QPWFSERVER ships with public=*USE. Change this immediately to public=*EXCLUDE. You can grant users who have a business need to access this structure, but lack *ALLOBJ special authority, private authority to the authorization list. File shares should be mapped to specific libraries (or files) to reduce the amount of damage these users can do. Remember, users with *ALLOBJ special authority cannot be restricted from any object—native or IFS.

2. Add Powertech Security Solutions

Control User Access: Powertech’s popular exit point monitoring solution, Exit Point Manager for IBM i, enhances IBM i controls with powerful access and auditing functions. It allows you to observe and restrict activities such as copying, opening, and deleting stream files without the complexity and overhead of maintaining IBM i authorities. You can monitor IFS directories to notify security personnel if users attempt to access files to which they have no authority. And, because this functionality rides on top of the operating system’s authority checks, it’s effective with *ALLOBJ users.

Exit Point Manager for IBM i silently audits all IFS activities. Typically, organizations start using Exit Point Manager for IBM i reports to build a knowledge base of legitimate access before they define access control rules. These rules can be based on the general activity (copy, delete, create), or on the stream file or directory affected. Rules can be for a single user, a group profile, or the IP address of a user’s workstation. You can make the rules as permissive or restrictive as you wish, and gain visibility and control that you can’t attain with IBM i. Exit Point Manager for IBM i also provides security for your native objects by controlling user access through powerful interfaces such as FTP, ODBC/JDBC, and remote command.

Control Command Use: Next, secure the WRKLNK command to control IFS access from a user’s 5250 session. Its public authority default of *USE means that any user with command line permission can access the same structures as the desktop tools mentioned earlier. Other commands allow users to create and change directories, and work with, change, and display authorities. Authorize only the users who need legitimate access to these commands.

Powertech’s Command Security for IBM i is the answer to command restriction requirements. It can control how and when any command can be executed. Command Security for IBM i can evaluate environment conditions and perform actions when a user—including those with *ALLOBJ special authority—invokes a monitored command. Actions include stopping the command from being executed, modifying the command, and sending a notification message. And, it maintains a complete command use audit trail for auditors.

3. You Can Secure The IFS!

Combining IBM i controls with Powertech solutions helps close the door on IFS vulnerability. By following a few simple recommendations, IFS security risks disappear. Enhance the security of your IBM server by looking to the most trusted partner in IBM i security: Powertech.