The Integrated File System (IFS) is one of the most ignored parts of the system, yet it makes possible many of the most powerful and most used features on IBM i servers today.
When IBM first introduced the IFS in V3R1, they built a PC-like directory structure over the entire QSYS library system. It was a great idea because it allowed all objects on the system to be accessed using industry-standard path names. But beware—this includes OS/400 libraries and database files.
Through the IFS, the operating system can be accessed—even altered—using path names. To a PC, the QSYS library appears as a directory. For example, you could run a DOS command on your PC to list the QSYS library (DIR command), which means a malicious program running on an administrator’s PC could also easily delete objects in any library, including QSYS and QUSRSYS. If this were to happen, it would completely disable the operating system!
Unfortunately, there is no way to uninstall the IFS. It is a required part of the operating system. So everyone is using it.
What’s in the IFS?
Some of the most common files used for the basic operation of the system are stored in the IFS. You may be surprised at just how much you are using this part of IBM i.
The TCP/IP configuration files are stored in the /QIBM/Userdata directory. If a malicious program running on a client PC modified or damaged these files, then TCP/IP services such as DNS or Management Central would fail. And with the help of the IFS, these files are easy to access from a PC. No green screen is required.
Client Access files are also stored in the IFS in the /QIBM/Proddata directory. When users run the Client Access Automatic Update feature, they’re accessing the setup.exe program stored in this directory.
Are you having your users update their Client Access periodically? Can you imagine if a virus altered the setup.exe program? All PCs would become infected when they ran the Automatic Update.
In addition to those critical configuration files, the HTTP server admin and configuration files are stored in /QIBM/Userdata directory. If someone modified or deleted these files, the HTTP server could be disabled and require a total reinstall.
Domino databases, as well as the Domino server code, could be damaged by malicious access and would also require a reinstall. But that’s not all. MQ Series is at risk, too. Some 5250 applications store data in IFS stream files and may be impacted if the data is damaged or corrupted. IBM i Host Servers, such as ODBC, store data in /QIBM/UserData and will not start if their configuration files have been damaged or deleted. Many third-party applications, especially those that have a graphical component, are stored in the IFS. This is a list that I would not want to be messed with!
Weakness #1: Wide Open Access
Remember, the Root directory is where many IBM i products—including Client Access and WebSphere—store code, data, and configuration files. The security issue with Root is how its default, or public, access is defined.
Root is shipped with Public having ALL access. So everyone on the system has the authority to do whatever they want with Root. This would be the same as the QSYS library with PUBLIC authority *ALL.
To make matters worse, whenever a directory gets created in Root, it inherits the authority of its parent directory. The same is true when stream files, text files, or other objects are created into a directory. So the wide-open concept of Root is continually propagated.
This means that anyone with access to Root can create a directory or store inappropriate material on the system. It also means that any files that are not secured appropriately can be updated or deleted by anyone.
To handle this wide-open access, you should review the public’s authority for application and user directories. Approach the securing of directories the same way your libraries are secured.
In addition, a great deal of security can be obtained by excluding the Public and authorizing only those users who need access. Authorize only those with a documented business need.
Third-party tools can help you easily manage complex security. Because the IFS uses a UNIX-like authority scheme, it can be confusing to IBM i Security Administrators. When managing access to objects in the IFS, you have to deal with two sets of authorities: data authorities and object authorities. A well-designed third-party application can make defining authorities simple and consistent.
Another reason to use a third-party application is because the IFS doesn’t honor adopted authorities. To access an object in the IFS, the user running the program must have authority to the object. Using a third-party tool makes it easier to manage these user authorities and quickly view who has access to what.
Weakness #2: File Shares
In order to see a file system or directory from the network, you have to use file shares. File sharing is a convenient way to share data throughout a corporation, but it can create serious security exposures.
Most IBM i systems that I have accessed have inappropriate file shares defined. Many have defined a read/write share for Root. Defining a read/write share for Root provides access to the entire directory structure of IBM i via the corporate network. This means that any user who can map a drive to the Power System can access any file on the system that has PUBLIC authority set to at least READ or USE authority.
When viewing directories or files under Integrated File System in IBM Director Navigator for i, shares are indicated by a hand underneath the directory or file name. To see all existing shares, click on File Shares under File Systems. Right click on a share and choose Properties to see if the share is read-only or read/write.
Unlike Windows, you can’t create a file share for a particular user. Once you create a share, it is available for all network users who have a user profile and password for the Power System.
For these reasons, I recommend reviewing the file shares on your system and removing those that are inappropriate. Make a policy for who can create shares. Inform your staff of this policy and, going forward, the problem will be eliminated. Set appropriate authorities on all directories and their objects if they are shared. Most shares are added without any thought to what is being made available to the entire network.
Weakness #3: Virus Scanning
The IFS is a carrier of PC- and UNIX-based viruses and worms. It is really good at storing and propagating these around the network. IBM i is the perfect virus host. It may not be harmed itself, but it infects everything it touches.
Many think that if they don’t use the OS/400 mail server, they don’t have to worry about viruses. But viruses come from infected CDs, website downloads, FTP downloads, and infected PCs that are attached to the network.
Scanning the IFS is as important as scanning PCs. Most companies would consider you crazy if you weren’t regularly scanning your PCs for viruses. But often the IFS is overlooked. Scanning the IFS needs to be a part of corporate policies and procedures as well.
When scanning the IFS, do not map a drive from a PC to the Power System and run a virus scanner residing on the PC. In order for a PC-based scanner to examine the IFS, a file share must be established for all of the file systems being scanned—including Root. As discussed earlier, defining file shares can expose critical data files and applications to the entire network. Additionally, any files transferred over the network to be scanned by a PC-based scanner would be exposed to network sniffing software, creating a serious security concern.
To eliminate the security risk of PC-based scanning and ensure the IFS is scanned properly, use a commercially available virus scanning product that runs natively on IBM i to reduce business risk associated with viruses and worms. With a native tool, there is no network connection that can be exploited, no file shares are required, and natively running scans typically take a fraction of the time of a scan performed over the network.
Remember, the IFS is the most ignored part of IBM i—especially when it comes to security. Just because you may be unsure of how to clean up what’s already been placed into the IFS, don’t let it get worse! Change the settings on directories, remove files shares, and start virus scanning. Securing these three weaknesses ensures stable, available systems. And it helps you maintain accurate production data.