If you’re pressed for time, this quick review can help you verify that your security configuration hasn’t gone totally sideways.

It’s rare that people have extra time. And while most administrators don’t want to admit it, many are so pressed for time they ignore security altogether. So here are five things you can do to take a quick look at security to make sure the most critical configurations on your IBM i have been examined.

1. Look for Default Passwords

OK, this one’s easy, and hopefully everyone thinks to do this anyway. Making sure no profiles with a default password exist (that is, a profile where the password equals the profile) is quick and easy. Simply run the Analyze Default Password (ANZDFTPWD) command. If any profiles are listed on the report, take steps to get the password changed!

2. Review the Profiles with *ALLOBJ

Periodically reviewing the list of profiles with *ALLOBJ special authority is critical to ensuring a profile hasn’t been inadvertently created with more authority than intended or left with authority when the intent was to assign it temporarily.

A couple of methods exist for listing profiles’ special authorities. You can run the Print User Profile command PRTUSRPRF TYPE(*AUTINFO), which produces a spooled file listing of all profiles on the system along with their group profile(s) and any special authorities assigned. This method works if you don’t have many profiles on the system. However, visual verification is often error prone. I prefer using the QSYS2.USER_INFO SQL view to list the information. In fact, IBM has provided an example to produce this exact information. Simply open ACS and click on Run SQL Scripts. When that window opens, click on Edit > Examples > Insert from Examples. Using the dropdown, choose IBM i Services and then scroll down until you get to the security examples. Click on Security – Review *ALLOBJ Users. You can preview the SQL, and if you choose to use it, click on Insert. You may want to add additional fields such as the Last Used Date and perhaps the special authority and group profile fields so you can see where the *ALLOBJ is coming from (the profile itself or their group).

3. Examine the File Shares That Have Been Defined

PCs connected to the system via a file share make IBM i vulnerable to being infected with ransomware. When examining the file shares, look for new file shares, making sure they’ve been created as a read-only share if possible. Also examine the list of read-write shares to determine if they can be reduced to read-only. Finally, review the list for shares no longer required. They should be removed if they are not needed. To list the file shares that have been defined, open Navigator for i > File Systems > Integrated File Systems > File Shares.

4. Verify That System Values Haven’t Been Changed

For this exercise, I’m (obviously) most interested in the security-relevant system values, although you may have others from a system administration point of view you’d want to verify as well. The easiest way to list the security-relevant system values is to run the Work with System Values command WRKSYSVAL SYSVAL(*SEC) OUTPUT(*) to produce a spooled file listing of the security-relevant system values. You can also run the Print System Security Attributes (PRTSYSSECA) command, which provides a comparison of the system’s current settings with IBM’s recommended settings, but I don’t agree with some of the recommendations, so I’m not a huge fan of this command. Finally, there’s an SQL view, QSYS2.SYSTEM_VALUE_INFO, that you can use to list the current value. In this case, you’d create a WHERE clause that lists the values you want retrieved so you aren’t pouring through the entire set of system values. The system values I’d review include:

• QSECURITY
• QPWDRULES (hopefully everyone’s migrated to using this value rather than the individual QPWD* values)
• QPWDEXPITV
• QMAXSIGN

5. Verify Authorities That Authorities Haven’t Been Modified

It’s likely that you have one or more libraries, database files, or directories that you have taken the time to secure. Now’s the time to verify that those authorities haven’t been modified. Once again, several methods exist to list these authorities. One is obviously to run either the Display or Edit Object Authority (DSP/EDTOBJAUT) command or Display Authority (DSPAUT) for IFS objects. Another is to navigate to the object via Navigator for i, right-click, and choose Permissions. But once again, my favorite is to use an SQL view. For objects in libraries, use QSYS2.OBJECT_PRIVILEGES view. For IFS objects, use QSYS2.IFS_OBJECT_PRIVILEGES.

If the object has been secured with an authorization list, don’t forget to review those authorities. I can’t tell you the number of times a client has thought an object was secure but, when we reviewed the authorization list securing it, realized that either the *PUBLIC authority setting had been opened up or a private authority had been granted, providing access to the majority of the system’s users. To list the users authorized to an authorization list, run the Display Authorization List (DSPAUTL) command or use the QSYS2.AUTHORIZATION_LIST_USER_INFO view.

If you don’t have any other object authority settings to review, I’d at least review the authority to root (/) to ensure that, if you’ve set it to the recommended *PUBLIC authority setting (DTAAUT(*RX) OBJAUT(*NONE)), it hasn’t been changed.

Summary

Admittedly, this review may take slightly more than five minutes; however, even when pressed for time, this quick review can help you verify that your security configuration hasn’t gone totally sideways.