Annual Checkup

By Rich Loeber

A few years ago, when I passed the age when I thought I might live forever and started maturing (a little), I decided that it would be a good idea to go see my doctor once a year for an annual checkup.  It was paid for by insurance and there was just no good reason not to go.  That first checkup (after many years of neglect, I might add) turned out OK.  The doctor told me a few things that I already knew (loose weight, get more exercise) and generally thought that I was doing OK.

After that first checkup, I got the annual appointment into my schedule and started going faithfully.  Then, after we moved up to the mountains of Northern New York, the doctor at our new home came back with a different response to my checkup.  He saw some things that didn’t look right and wanted to schedule some additional tests.  To make a long story short, he found a blocked cardiac artery and we were able to deal with it well before the onset of a heart attack.

What, you ask, does this have to do with computer security on your IBM i system?  Just this …. you need to do a full system checkup at least once a year just to see if there are any surprises.  I have done dozens of these checkups over the years on systems under my responsibility and I ALWAYS find something that needs attention.  If you’re responsible for system security, you need to do this, and year end is a good time to be thinking about it.  Nobody gets much work done during the last couple of weeks of the year and it’s a good time to go tinkering around in your system.

So, what should you include in your checkup?  Here’s a list of things to start with.  It is by no means comprehensive but will probably get you started and lead you into the areas where you need to be concerned:

●    Check the security settings in your system values using the Print System Security Attributes [PRTSYSSECA] command and reconcile differences on your system from the recommended settings.
●    List the user profiles on your system and check for employees who have left or changed their job assignment.
●    Create a database of your user profiles using the DSPUSRPRF command with the *OUTFILE option, then run a series of query reports to search for expired passwords, profiles with *ALLOBJ authority, and so on as appropriate for your installation.
●    Run the Security Wizard in the IBM i  Navigator (Or Access Client Solutsion) and check any differences on your system from the recommendations suggested.
●    Using the user profile database already created, list your user profiles by group to make sure that the groups are set up as you expect to see them.
●    Create a database of all *FILE objects on your system using the DSPOBJD command with the *OUTFILE option.  Then generate a report using your favorite query tool of new files created since your last audit and make sure that security on these new objects complies with established policies.
●    Run the Analyze Default Passwords [ANZDFTPWD] command to make sure that no default passwords exist on your system.
●    Check *FILE objects on your system with *PUBLIC access authority using the Print Publicly Auth Objects [PRTPUBAUT] command.  Make sure that the objects with public access all comply with established policies.
●    Go to the SECTOOLS menu and see if any of the options available can be of specific help to your audit efforts.
●    Review your backup process and offsite storage arrangements.  Do a physical inspection of the offsite location and make sure you can quickly and easily identify and retrieve backup sets.

Due to space constraints, this is not a comprehensive list but is intended to get you started on the audit process.  As you go through it, document both what you are doing and your findings.  That way, when next year end rolls around, you’ll be better prepared for the process and you’ll have a baseline to compare your results with.  Good luck, and I hope you don’t find any clogged arteries!

If you have any questions about this topic, you can reach me at rich at kisco.com, I’ll give it my best shot.  All email messages will be answered.

Anatomy of an IBM i Hack Attempt

By Rich Loeber

Kisco Information Systems keeps a lone IBM i server connected directly to the Internet in order to test it’s SafeNet/i exit point security software in a real world environment. In the past, we have reported on our experience with quarterly reports in 2013 and even an update earlier this year in March 2017.

Last month we experienced an unusual and persistent hack attempt that surprised us by its depth and the amount of time that was used.  This blog post is to report on what happened and, perhaps, remind everyone about how important it is to take hacking seriously in this day and age.

Starting at 20:30 on October 20, 2017 someone from IP address 79.137.65.236 began a persistent FTP script attack on our server.  This happened on a Saturday evening when nobody was in the office to notice any unusual network traffic. The attack consisted of signon attempts via the FTP server using a very long series of profile names.  The signon attempts were repeated every few seconds.

The script being used called for each of the hack attempts to be repeated 85 times with the same user profile.  We don’t capture the passwords being used, but it is obvious that each attempt was trying to use a different password.  In our case, since our SafeNet/i did not recognize the IP address that was being used as a valid client address, the IBM i OS never got to the point of password validation and subsequent deactivation of the profile by the OS.

The user profiles used during this hack attempt were mostly comprised of common English first names such as ANDREA, BARBARA, KIM, ROBERT and so on.  There were also a few coomon Hispanic names used such as JUAN and FERNANDO.  Other profiles were also used and some of them got special attention with additional signon attempts.  The profile name ADMINISTRA was used 255 times (85 three times?).  Other common profiles that deserved extra attention included ADMIN, INFO, SPAM, “NULL” and, for some reason, BARBARA, all of which were attempted 170 times (85 twice?).

In addition to these common profile names, quite a few other “common” technical terms were  used, each for its own series of 85 tries.  These included profile names like ABACUS, ACCESS, ACCOUNT, ADMIN, APPLE, BACKUP, DEMO, GARAGE, MAIL, MAILSCANNE, ORANGE, NETGEAR1, PASSWORD, PAYMENTS, POSTMASTER, QWERTY, QWERASDF, SALES, SCANNER, TEMP, TEST, USER, WEB, WEBMASTER, WELCOME,123 and SYSADMIN.

The hack came to an end on Sunday morning when I received an email from SafeNet/i advising  me that thousands of break in attempts had been made.  When I checked the system I found that it was still going on and simply turned the FTP server off.  Nobody needed FTP on a Sunday morning.  I restarted the FTP server about an hour later, but the hack did not resume.

After the hack was done, I did a lookup using the IP address that was used and it traced back to the RIPE Network Coordination Center in The Netherlands.  A few days later we reported the abuse attempt to them.  Shortly after reporting it, we received a standard reply email that was un-formatted and very difficult to read.  We went to the RIPE website and there was a place to trace the IP address within their organization and it traced back to an organization in France.  An abuse report submitted to them has not been answered as of yet.  Based on past experience, trying to trace back an abuser is a rabbit hole that you can rarely get out of.  In the past, we have tried reporting hack attempts to the local police, state police and the FBI, always to no avail.

There are some take away things to think about from just this one hack attempt.  You should consider the following:

  • Review your user profiles and look for common English first names.  Consider changing them to something more complex.
  • Stay away from common technical terms, and even some uncommon ones, for user profile use.
  • Don’t run the FTP server when it isn’t needed.  The FTP script hack is the one used most frequently.  If the server isn’t active, it can’t be hacked.
  • Make sure that you have exit point software installed and active to control which IP addresses are allowed to connect to your system.  Our SafeNet/i does this and successfully fended of this entire hacking scenario on our box.

The whole point of the FTP hack is to discover working user profiles and, hopefully, also uncover one that is using a very common password.  Once a hacker has this, they are ready to come back via Telnet or some other server connection and really get into your system.  You need to be prepared to stop them before that can happen.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Watch Your User Profiles

By Rich Loeber

Once you’ve set up a user profile on your IBM i systems, are you tracking changes to it over it’s lifetime?

The user profile is your first line of defense in the ongoing battle of protecting your system.  When a new employee shows up for work, you go to great lengths to get their profile set up just right.  You make sure that they get access to the menus and files they need to get their work done and you set up their object access accordingly.  If you’ve been at this a while, you probably already have a mental checklist of all the things that you need to do for a new user in each department or work group in your shop.

But, what about subsequent changes to those profiles.  Are you watching these updates to make sure that your carefully engineered security scheme is being maintained over the life of each user profile?

In the IBM i OS, there are a couple of ways that you can monitor for this.

First, you can use the system security audit journal as an after-the-fact review process for user profile changes and updates.  To run this report, use the Display Audit Journal Entries (DSPAUDJRNE) command.  Prompt the command using the F4 key and select the entry type code CP (Change user profile entries).  The resulting report will show you at least some of the user profile change activity for the selected period of time on your system.

If you want more immediate information about user profile changes, then the only alternative is for you to code an exit program.  There are four possible exit points that you can use on the system to track user profile activity:

QIBM_QSY_CRT_PROFILE    Create User Profile
QIBM_QSY_CHG_PROFILE    Change User Profile
QIBM_QSY_DLT_PROFILE    Delete User Profile (2 points, one before the other after)
QIBM_QSY_RST_PROFILE    Restore User Profile

An exit point is a marker in the IBM i OS where you can attach your own program.  The OS will call your program, passing parameters, during the process of working with these user profile events.  You can code your program do meet your very specific needs.  This can include on-line notification, detailed change tracking, rules enforcement and more.  You can even pass a return code back to the exit point indicating that the profile change should be disallowed.

Your will find more details about creating exit programs to work with these user profile exit points in the IBM i Security Reference manual.  Registering your program can be done using the Work With Registration Information (WRKREGINF) command.  You will see many exit points displayed, be sure to limit your changes to the specific exits named above.

If you don’t want to code your own solution, there is an audit reporting feature built into Kisco’s iEventMonitor software that can be used for near real time reporting of profile change events.  It is available for a free trial if you’d like to find out if would be helpful in your situation.

If you have any questions about this topic, you can reach me at rich at kisco.com.  I’ll give it my best shot.  All email messages will be answered.

Tracking Use On Critical Files/Objects

By Rich Loeber

Most shops have at least one, and probably more than one, mission critical information assets stored on the IBM i system.  If you’re doing your job as security officer, that asset is locked up tight to make sure that only authorized user profiles can get to it.  But, do you know for a fact who is actually accessing that critical data?

Here is one way that you can review who is reading and even who is changing data on an individual object-by-object basis on your system.  That is by using object auditing, a built-in feature of the IBM i OS.

For starters, you have to have to have Security Auditing active on your system.  You can do a quick double check for this using the Display Security Auditing (DSPSECAUD) command.  If security auditing is not active, you will need to get it up and active on your system.  That is a process for a different tip.  If you need help getting this started, send me an email (see below).

With security auditing active, you can set up access tracking on an object-by-object basis using the Change Object Auditing (CHGOBJAUD) command.  Depending on what you’re objective is, you can set the OBJAUD parameter to a number of values.  Check the HELP text for more information.  If you want to check everything, just set it to *ALL.  If you are only tracking usage for a limited time period, be sure to change this value back to *NONE when you’re finished as this will reduce some system overhead.

Once object auditing has been activated, the system will start adding entries to the system audit journal whenever any activity happens on the object you have activated.

To view the journal information, you use the Display Audit Journal Entries (DSPAUDJRNE) command.  The first parameter, ENTTYP, selects the specific information that you want to see.  Setting this value to ‘ZC’ will produce a listing of all of the times that the tracked object was changed.  If any applications are deleting the object, using the report for value ‘DO’ will report those happenings.  Using the value of ‘ZR’ will produce a larger listing showing all of the times that the tracked object was read.  Depending on how your object is used, you might find that the ZR report is just too huge without filtering it down …. read on.

The generated reports are simple Query listings.  The reports are generated from a file that the DSPAUDJRNE command creates in your QTEMP library.  The database file is named QASYxxJ4 where “xx” is the value you used on the ENTTYP parameter.  Once this database file has been created, you can use it to generate your own reports.  This way, you can slice and dice the data for your own unique needs.  For example, if you are looking for specific user profiles, you can add that as a selection criteria.  Or, if you want to analyze access by time-of-day or day-of-the-week, you can do that too.  The possibilities are quite open at this point.

I set this up on my test system to track accesses to an obscure data area that I was quite sure is only rarely used.  I set the tracking and left it for a few hours, then went back to it.  Even on this test system, I was surprised by the number of times the data area was used, and I’m the only user on the system!  Who knows what surprises you will turn up.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Terminal Session Security

By Rich Loeber

Like all modern systems, the IBM i requires a user profile and password before you can log on and use the system.  You might think that this simple requirement would always ensure that only authorized users will have access to your system.  But, with the proliferation of devices that can connect to the system, it is not always that simple.

In the old days, we used to have devices that are now called “dumb terminals”.  To use the system, you’d log on to the sign on screen and when you were done, you’d log off.  You could tell by looking at the screen whether the session was active or not.  If the signon screen was displayed, then the session was inactive.

Today, with a proliferation of PCs, tablets and cell phones and with easy access to Telnet based terminal emulation software, it is not always that clear.  On a PC using IBM i Access, the first time you log into the system for the day, there is an IBM i Access logon that establishes connection from the PC to your host system.  Then, there may or may not be another logon for your terminal session.  If you have your PC set up to bypass terminal sign on to the host, then there will be no second signon process.  Once your connection to the host system has been established, the only way to break it is to either log off from Windows altogether or reboot your system.

There are a couple of potential problems with this configuration.  It makes working with your system a lot easier just like leaving the keys in your car makes getting going a lot easier, but you wouldn’t want to do it on a regular basis.

If you are using bypass signon, once your initial connection has been established, anyone can come by and start up your terminal emulation session and gain access to your system without knowing either your user profile or your password.  If you’re a programmer or a systems administrator, that could be a significant exposure to your system as you will probably have very generous access rights to objects on your system.  If your PC is located in a public or semi-public setting, you should think twice about having this setup.

Another exposure, which can happen when you leave a terminal session active, is that anyone can come along and use the Client Access upload or download functions to gain access to your system, again without knowing your user profile or password.  If you have any virtual drives mapped to your host, those could also be compromised by someone using your PC without your knowledge or approval.

One simple solution is to activate your PC’s screen saver with a password requirement to unlock the keyboard when it goes into screen saver mode.  That way, if you go for coffee and get delayed by a dumb question from the boss, the screen saver will kick in and protect your system in your absence.  The problem comes from user systems that you, as security officer, are responsible.  Each user can probably reset their screen saver settings on their own, thereby defeating this important additional security measure.  A periodic inspection of all PCs installed in public and semi-public settings for these exposures would probably be a good idea.

Most terminal emulation software for use on tablets allow you to build in a macro for the signon process.  So, anyone picking up your tablet, might be able to establish a connection to your system.  If tablets are available in public areas, then disabling the signon macro function would be a good idea.

If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Securing the Save/Restore Function

By Rich Loeber

On today’s open IBM i system, the save/restore function can be used to transfer critical files and programs between systems.  With this comes the specter of data and program theft, so it is important to make sure that this avenue of data transfer is secure.

Most IBM i installations run a scheduled save of their system to transfer files, programs and other objects to tape or other media for safe keeping.  Saving the system on a scheduled basis is just good practice since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system.  Since introduction, IBM has hounded its customers (and rightly so) to do a regular save on your system.  Once objects have been saved, you can also use IBM i/OS functions to restore objects from the saved media.  This can be part of either a full system restore or to recover objects that get damaged or corrupted in any number of ways.

The problem, from a security viewpoint, is that once data and programs have been saved to offline media, they can then be transported to another system and restored.  Mission critical information must be guarded to prevent theft from occurring.  Physical security on the media is critical for this, but I want to talk more about securing the save/restore function on your system.

Today, with an open TCP/IP world in which we work, you can save a critical file to a save file and then FTP or SNDNETF it to any system in the world.  IBM i software developers regularly use the FTP save file to transfer program updates onto customer systems.  With the ease of data transfer that this provides, restricting the use of the save/restore functions on your system is more critical than ever.

The first line of defense for this is found in the user profile.  Before someone can use the Save/Restore commands in the IBM i/OS, they must have *SAVSYS special authority in their user profile.  If you have not done so, I recommend that you review your user profile base to find out which user profiles have *SAVSYS configured and make sure that they have a real business reason for it.  Certainly, your operator(s) will need this authority, as will anyone who runs the scheduled backup or restore functions.  But, I would be hard pressed to think of any other users in a regular environment (including programmers) who really need to have this ability.  I know some programmers are going to howl at this, but they will have to be able to make their business case before you give them these keys to the kingdom, so to speak.  You can always look at granting them this authority on an as needed basis, revoking it once the task to be done has been completed.  Some shops even keep a special user profile around for this use.  When needed, they activate it temporarily and the deactivate it with full documentation kept on how it was used.

The next place to look for restricting Save/Restore use on your system is the IBM i/OS authority setup for the the RSTxxx and SAVxxx commands.  The RSTxxx commands are shipped from IBM with public *EXCLUDE, but the SAVxxx commands have a public setting of *USE.  You might want to consider setting up an authorization list for these commands and then listing the users that you want to be able to use them in the list.  Once the list is built, associate it to the commands and then change the SAVxxx commands to be public *EXCLUDE.  (You can also do this with direct authority, but having the authorization list will make IBM i/OS upgrades easier to implement.)

There are several system values that you should take a look at too.  The QALWOBJRST value lets you restrict certain objects at restore time.  These include system-state programs, programs that adopt authority and objects with validation errors.  QVFYOBJRST controls restoring signed objects.  QFRCCVNRST wil force object recreation on certain objects at restore time.  Lastly, you can specify *SAVRST in the QAUDLVL command to audit save restore operations on your system.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Password Levels

By Rich Loeber

Ever since the introduction of IBM i/OS V5R1, a system value for “Password Level” has been available (QPWDLVL).  This value lets you have control over the kinds of passwords you use on your system and how the system treats them.  Using the features provided through this value, you can implement passwords of up to 128 characters in length.

Why would anyone ever want to have a password that long?  I asked myself that very question, but when I started looking into the issue, some things jumped out at me that make perfect sense.  With a long password, you can implement a “pass phrase” rather than a password.  The implementation of the long passwords allows for case sensitive passwords and will accept embedded blanks and every character on the keyboard.  This complexity in your password can easily increase the difficulty for people trying to break into your system.

The system value that controls this is QPWDLVL and it can have the following settings:

“0″ – the default setting which sets up 10 character passwords and is what you are probably used to now if you’ve been working with the IBM i system for some time.

“1″ – uses the same 10 character passwords, but the IBM i/OS NetServer passwords for Windows Network Neighborhood access are not kept on the system.  If your system does not communicate with any Win-X machines using Network Neighborhood, you might want to consider this.

“2″ – allows you to have passwords of up to 128 characters that are comprised of any character on the keyboard, are case sensitive and may contain blanks (but not all blanks).

“3″ – implements the same level “2″ passwords but adds the restriction on Windows Network Neighborhood that level “1″ includes.

If I were implementing a new system, I’d seriously consider adopting level “2″ as a standard right from the get go.  But, most of you out there in IBMiLand have an embedded culture of 10 character passwords with specific rules in place that you have your users well trained for.  The good news is that you can move to a new password level as long as you do a little planning in advance.

Moving from level “0″ to level “1″ is pretty simple and does not require much planning.  This will simply eliminate the storage of another set of encrypted passwords on your system.  Moving from level “0″ or “1″ to a higher level should take some planning before you take the plunge.

One of the nice things is that whenever you create a new profile, the IBM i/OS creates the associated level “2″ and level “3″ passwords just in case you want to move to the higher password level.  So, the codes are already there on your system.  The possible downside is that embedded code and certain client software may not get along with the longer passwords.  Consequently, if you decide to make this change, you really should get a full backup of your current security profiles and passwords using the SAVSECDTA command.  This way, if things go south on you, you can recover back to where you are now quite easily.  You can use the DSPAUTUSR command to check your profiles for users with passwords that will not work at the higher levels.  There is a good, comprehensive discussion on how to move to a higher password level in the IBM i/OS manuals “Planning and setting up system security” or “Security Reference” that you should also take a close look at.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing Resource Security

By Rich Loeber

Last month, I talked about the need to test your security setup on a regular periodic basis.  That article focused in on testing user profiles.  Today, I want to take a look at how you can go about testing your resource security setup.

There are two things that you need to test and evaluate on your system.  First, you have to make sure that users have sufficient authority to get all of their work done without a problem.  Once that has been established, you then need to go back and make sure that users don’t have too much authority, thereby compromising the confidentiality issues that prompted you to secure specific resources in the first place.

After publishing my previous tip about testing user profiles, I heard from one reader who offered an excellent suggestion.  In their shop, for user profile testing, they maintain a special user profile for each group on the system that is used just for testing purposes.  If you don’t have this set up on your system, I strongly recommend this approach.  Before testing, you can enable your test profile and then, as soon as your done with your testing, you can disable it again.  This idea applies when testing profiles and when testing resources on your system.

To test a user profile to make sure they have sufficient authority, you will have to log on with that profile or your test profile for the group.  Make sure the right menu comes up and then try exercising various menu options.  Remember, resource security does not get checked until a file is opened, so just displaying menus is not going to get the testing done.  Keep track of the operations that you perform, as some of them may have to be reversed within the application files before you end your session.  Make sure that the person who owns the application knows about your testing so they can be on the lookout for any unusual transactions that come up in their system.  Your testing should verify that the user can add records where they need to create new data and delete records where they should be able to remove data.  If you come up with any security problems, note them, make adjustments to your resource security setup and then repeat the testing until it comes up clean.

If a user has access to batch processes, those will need to be tested as well.  Great care must be taken in this area as some batch processes are not easily undone in a production environment.  You might consider setting up a test environment for these purposes.  When running batch testing, review the system operator message queue and the system history log for security error messages.  These messages will be in the 2200 and 4A00 ranges for CPF, CPI, CPC and CPD errors.

Testing for too much authority is also very important and probably a little more fun in the process.  After all, you have to have a little fun while you’re working and pretending to be a hacker is great.

While you are signed on under the profile being tested, check some of the following items:

  • Can you use menu options to gain access to a menu where you don’t belong?
  • Do you have access to the command line?
  • Are you able to key in and run CL commands?
  • Can you use the CPYF command to create a printout of a data file that you are not authorized for?
  • Are you able to run a query tool on your system to get to files that you are not authorized for?

If you are checking resource security for a specific application, you should also log on with a typical profile that should NOT have access to that application and then repeat the above checks.  You should specifically be looking to make sure that access to critical and confidential files is denied to users who should not have access.  This is particularly important as it applies to query tools since they can, by virtue of adopted program authority, thwart your resource security arrangements.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Testing User Profiles

By Rich Loeber

If you’re reading this, you’re probably either a Security Officer or working in the security group in your IBM i shop.  I’ll bet, however, that you didn’t start your career in the security area, but worked your way into your current position, starting as a programmer or a database administrator or some other related field.  In your earlier positions, I’m sure you learned a lot of principals about testing.  Don’t let this fall by the wayside in your current position.  Security testing is just as important as application testing.

Today, we’ll take a look at testing your user profiles.  In future articles, I’ll also be taking a look at other testing regimens for your security setup.

The best time to test a user profile is when you initially create it.  If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives.  This article will assume that you have your user profiles organized into groups with group profiles active.

As with all testing, the objective is to check and make sure that the security setup for a user profile (or group) is meeting the objectives you designed.  To do this with a new profile, make sure that you set the password to a temporary code and that the PWDEXP parameter for the profile is set to *YES.  Using this method, the system will allow a single signon with the temporary password and then prompt you during signon to change your password immediately.  When you signon to test the profile, you can then change the password to the user’s final password or to another temporary code.  If you do assign a new temporary code, you’ll have to set the PWDEXP back to *YES when you’re all done.

The first thing to check on any new profile is to make sure that the signon completes successfully.  If it fails, look in the special QEZJOBLOG output queue for a joblog for the failed logon session.  It is amazing what a joblog can tell you about failures on your system and a close examination of the joblog starting from the top should reveal any problems that have happened to cause the logon process to fail.  Typical problems you will encounter include missing or misspelled library names, incorrect initial menu names and incorrect initial program references.

Once you’ve signed on correctly, then you should exercise the profile to make sure that it meets your objectives.  Ask yourself the following questions as you work with the new profile:

  • Is the right menu displayed?
  • Does the user have access to the command line?  If yes, should they?
  • If an initial program was called for, did it execute correctly?
  • What happens when you press the Attention key function?  Is it what you want the user to see?
  • Where is printed output going for the session?  Is this where you wanted it to go?
  • What happens when you attempt to run the application or applications that this user should be using?
  • Are there any system tasks that the user should be able to run?  Can they?
  • Are there specific functions that the user should be barred from?  Can you access them?
  • Can the user access their printed output spool file?  Do they have access to view other user’s spool files?  Should they?
  • Check the user’s desktop environment for remote access tools.  Using the user profile, can the user access data on your system that they are not authorized for?

Make notes for yourself on any issues uncovered, then go back and make any changes that need to be done to bring the profile or group into compliance with your security objectives.  If you detect any problems, be sure to repeat the test until everything is OK.  At that point, you can turn the profile over to the user.

If you have never tested or audited your current profiles, you can use this same method but you will have to warn the users that you are doing a review.  You can use the PWDEXP parameter on the user profile to help with this testing.  Change the user’s password to a temporary code for your testing logon.  Once you’ve completed your test, change the PWDEXP parameter to *YES and set a temporary code that you’ve already told your user about.  Then, the next time they log on to your system, the IBM i OS will ask them for a new password and they’re back in business with little interruption to their daily job tasks.

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.

Controlling Adopted Authority

By Rich Loeber

IBM i programs have a setting when compiled that controls the user profile that will be used for security reasons when that program runs.  You may think that your security configuration is all set and that you’ve made a final determination as to which users are allowed to have access to what objects on your system.  But, if a program on your system is compiled with the USRPRF attribute set to *OWNER, then all your preparation work may be out the window.

The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems.  This is the way it comes from the factory although it is easy for the default setting to be changed.  When programs are compiled with the *USER setting, then you can count on your object security setup to provide the proper control over access to objects on your system.  When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object.  (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I’m just referring to all of these generically as “programs”.)

This situation is called adopted authority.  There are lots of good reasons why you would want to do this.  For example, you may have a CL program that creates backups of your system that is run by your night operator.  You may not want your night operator’s user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER.  Then, when the night operator runs the backup, it goes off without a hitch.  While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted.  A lot of third party software developers use this technique to make sure that their programs can run without authority problems.

To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.

The first step is to identify the user profiles in your system that have all object authority.  This step alone might produce some interesting results that will surprise you.  One quick way you can do this is by running the following command:

DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)

This will create a temporary physical file named USRPRF in your QTEMP library.  Once created, you can scan this file for the value *ALLOBJ in the first 7 positions of the field designated as UPSPAU.  Any query tool that you like should give you a quick report on what you’re looking for.  Check each profile listed to make sure there are no surprises.

Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile.  This command supports on-screen display, print and *OUTFILE output.  Use the form that best suits your needs.  At a minimum, you should check for programs that adopt the QSECOFR user profile.  The command to review this looks like:

DSPPGMADP USRPRF(QSECOFR)

Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary.  In some shops where I’ve worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production.  One obvious problem would be if the program in question has an option to present the user with an IBM i command line.  In this situation, the user then has full access to your system that goes right around your careful security setup plans.

For third party software, contact your software provider and ask about the adoption situation.  A good software provider should have a ready answer for this question.

When you’ve identified a program that needs to be changed, you don’t need to recompile to make the change.  A simple Change Program command will work in most instances.  Use the following command to change from adopted authority to user authority:

CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)

If you have any questions about anything in this tip, just ask me and I’ll give you my best shot.  My email address is rich at kisco.com.  All email will be answered.