Watch Out For FTP “Script Kids”

By Rich Loeber

Some time ago, I wrote about the dangers of having an open FTP server running on your IBM i.  At that time, I advised that FTP was a clear point of potential entry into your system by persons with malicious intentions.

Since then, I’ve been observing repeated attack attempts on my personal IBM i in my office and I’ve identified a particular type of attack that has me worried.  It is what is called a “Script Kid” attack.  It is called this because the attack is mounted using an FTP script so it can be repeated over and over again on any target.  The word “Kid” is used because it is so easy, even a child could mount the attack.

Typically, a “Script Kid” attack will repeatedly attempt to log on to your system using a well known profile name.  Fortunately for IBM i security officers, the most common profiles used by the Kids are ADMIN and ADMINISTRATOR which are very popular profiles in the Unix world.  Good news for us as these attacks will generally get nowhere on the IBM i.

However, not all Kids stick with this basic attack form.  One that worries me a lot happened a few weeks ago and is the event that prompts this writing today.

This Script Kid started signon attempts through FTP using common first names.  Each name made 3 signon attempts, each using a different password.  I’m sure the script called for commonly used passwords such as “password”, “security” or the same value as the user profile.  Scanning through the log of rejects for this attempt, I see a very comprehensive list of first names used such as ABBY, ABIGAIL, ABRAHAM, ABUSE, ACCOUNTS, ADAM, ADRIAN, ALAN, ALBERT and so on.

On the surface, this attack pattern seems like it would fail miserably as long as you have good password policies in place.  And, as far as preventing access to your system, this is a true statement.  However, this kind of attack could have a devastating impact on your system by cycling through commonly used profiles and causing them to be disabled by the operating system.  Most IBM i shops allow for three logon retries when an incorrect password is entered.  After the third attempt, the profile is disabled and can only be reactivated by a security officer.  You could easily find yourself suddenly inundated with requests to reactivate disabled accounts all over your shop, bringing work on your system to a halt.  (For password resets, our iResetMe software can help.)

So, how can you defend against this type of attack?  For me, on my small test machine, I just shut down the FTP server when I saw the attack start up.  But that is not an easy option for most of you.  In my shop, I intentionally set up a phony profile on the system with the user profile of “ADMIN”.  I set it up to disable on the first bad password attempt and I designed the profile in such a way that it could not be used to gain access regardless of whether it resulted in a successful logon or not.  Then, I had our system monitoring software (we use our own SNDWEET for this), watch for messages in the QSYSMSG message queue.  When I am texted that the ADMIN profile has been disabled, then I know that an attack is under way.

The best solution is to have profile names that are uncommon.  Don’t use first names for your profiles.  A good solution is to pick profile names based on a combination of first and last name.  For those accounts that come with your system from IBM, the infamous Q profiles, make sure that none of them are used for regular production purposes.  You should keep these profiles on your system in a disabled state.  Sooner or later, a Script Kid is going to get around to putting QSYSOPR, QUSER and QSECOFR in their list of profile names to try.  You should also keep a backup security officer profile available in case QSECOFR gets disabled.  Finally, and I’ve said this many times before, never allow a profile to be created on your system using the default password.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Rescinding Access Rights

By Rich Loeber

Most of the time, as an IBM i security officer, you are concerned with granting access rights to users.  To do this, you need to know what the user’s job responsibilities are and what they will be doing within the computing environment.  Based on existing security policies for your shop, you then configure security for each user so that they can get at the computing resources they need to do their job easily, smoothly and securely.

Once you have a user set up and running, however, I think they seem to fall off our radar since we’re then occupied with getting the next user(s) setup and configured.  You tend to address those areas where you have immediate demands at the expense of others.

One important thing to keep track of, however, are situations where access rights need to be modified or rescinded.  The most glaring situation is when someone leaves the company.  You should have a clearly developed plan of action to implement when someone leaves.  This plan should include:

  • Deactivating their user profile
  • Identifying any objects owned by their profile and reassigning them
  • Removing access rights for objects not owned by them
  • Deleting the user profile after all else is done

Just deactivating a profile is not sufficient.  Batch jobs can still be run under an inactive user profile and those jobs will still have rights to the object set that was defined for that user.  So, you must take the additional action of removing those access rights.  Rescinding access rights is just as important to a secure installation as granting those rights.

Chances are, your IBM i is currently sitting with loads of unnecessary access rights in place for people who are long gone.  Each one of those access rights is a potential security exposure and should be dealt with.  You should review the way the user was initially configured when their access rights were granted and then go through and reverse the process.

Making this work depends you being in the loop when someone leaves the company.  In a small shop, you normally learn this by word of mouth.  But, in any size shop, a formal notification process needs to be put in place to guarantee that inactive profiles are dealt with promptly.  This can be especially important if someone leaves on bad terms.  A firm procedure has to be in place with your HR staff and it must be enforced.

The other situation you need to be prepared for is when someone has a change in job responsibilities.  In this situation, you will not only need to grant new access rights for the user, but you will also have to backtrack and possibly remove some earlier rights that have already been granted.  Again, careful coordination must be worked out with your HR folks.  You are more likely to hear about this through less formal channels since the user will need to get reconfigured in order to start their new responsibilities.

If you have any questions about this topic you can reach me at rich at kisco.com,  All email messages will be answered as quickly as possible.

Restricting Use Of Certain System Commands

By Rich Loeber

When your IBM i is prepared in the factory, it is set so that most system commands and APIs have a public authority of *USE.  This setting will let anyone use just about any command or API on your system.  But, some of those commands and APIs could be used for malicious purposes.  This tip will show you a way that IBM has provided in the operating system to easily restrict those commands and APIs that can be most problematic.

The secret to this is the Revoke Public Authority (RVKPUBAUT) command.  This command, which calls a program named QSECRVKP in library QSYS, can be used to change the public authority for a host of commands and APIs to *EXCLUDE.  Doing this will allow you to control exactly which user profiles will have access to these commands so that you know who will be trusted with them.

Before you run out and execute the RVKPUBAUT command, you need to know what it is going to change on your system.  (For example, it restricts the RSTOBJ and RSTLIB commands.)  To get a full understanding of which commands and APIs will be changed, you can either take a look in the system documentation or, better yet, you can retrieve the CL program source for the QSECRVKP program and examine it yourself.   You can use the following command to retrieve the source code for this purpose:

RTVCLSRC PGM(QSECRVKP) SRCFILE(mylib/QCLSRC)

This assumes that you already have a source physical file in your library named QCLSRC.

When you run this command, there is a single parameter.  You need to supply the name of the library where these objects are stored.  At a minimum, you should run the command for the QSYS library.  If you have more than one national language on your system, you should also run the command for every QSYSxxx library on your system.

If you see commands and/or APIs where you do not want to change the system default, you can make changes to the retrieved CL source program and recompile it.  Do not place the newly compiled program back into QSYS as that will destroy the original as shipped from the factory.  It would be best to put the copy in a different library along with your own copy of the command object named RVKPUBAUT.  Change the library settings on your copy of the command to point to your modified version of the program.  Then, when you run the command, run it from your library and not from the QSYS library.

You should also be aware that running the RVKPUBAUT command will change the public setting for the root directory of the IFS on your system.  It will change it to *USE unless it is already at that level or lower.

Once you have these commands and APIs restricted, you can then go about authorizing them to the specific individuals in your organization that really do need their use.  The best way to set this up is to create an authorization list for this set of users and then set up each of the commands and APIs to point to the authorization list.  Then, as people come and leave, a simple change to the authorization list will take care of all authorization issues to these restricted use commands and APIs.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Tracking User Profile Changes

By Rich Loeber

In response to a recent tip, I heard from a reader who suggested a good technique that they use for managing a large base of user profiles on their system.  They submitted this suggestion and I’ve been playing with it and it really does give you the basis for managing your user profile base quite nicely.

What this security officer does is to periodically create a database file of the basic information set up for the entire user profile base.  They then compare this to a version of the database to one created a couple of weeks earlier.  Through a series of Query reports, they are able to list activity in the user profile base that gives them exception reports to review.

To get started, with this approach, you need to create your baseline or historical database.  This is done using the Display User Profile (DSPUSRPRF) command.  Select all profiles for basic information and specify an *OUTFILE.  Then sit back and wait a few days, or as my reader suggested, two weeks.  You may want to wait longer depending on how much time you have and how large your user profile base is.

Then, after the selected time period, run the Display User Profile (DSPUSRPRF) command again, but specify the output to a different *OUTFILE database.  Once you have these two files, you can then run a series of Query reports that compare the two files.

My reader recommends at least four reports, but when you get the hang of this, additional reports may be helpful.  The four reports that they work with are:

•    New User Profiles Added
•    Old User Profiles Deleted
•    User Profiles with no Sign-on Activity
•    User Profiles with changes to their Special Authorities

Using IBM i Query, this is really quite easy.  You can match the two files on the user profile field and select different key match criteria depending on the exact report that you are going to create.  In some cases, you’ll want records on one file but not on the other and vice versa.  In other cases, you will want to look at profiles that are on both files but have field mismatches.

Then, when you’re all done with your reporting, copy the current user profile database over into your historical user profile database and wait another couple of weeks to repeat the process.

These exception reports will show you significant change areas in your user profile base.  You can verify that new profiles added are valid and the same for deleted profiles.  For profiles with no sign-on activity, you can check to see if the users are just on vacation or are actually gone from the company.  For users whose special authorities have changed, you can verify that the changes were warranted.

Other reports you might want to consider are users with group profile changes, users with expired passwords and much more, limited only by your imagination.

If you’re interested, I’ve created the four query reports and a CL program that ties this all together.  If you’d like a copy of these in a save file so you can load them directly onto your system, just ask.  If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

Strengthen Your Passwords

By Rich Loeber

Secure access to your system often starts with your user profile and password policy.  If you’ve been working in the IBM i world for any length of time, this is very familiar territory for you.  You may even have this task assigned to an underling who maintains your user profile base without any instruction or interaction from you.

Sign-on passwords are your first line of defense in your approach to security.  Your password policies are important tools in securing your system.  If you’ve been around a while, you may not be aware of the latest controls that are now available in IBM’s i/OS to help implement stronger password controls.  Over the years, additional controls have been implemented and strengthened.  This tip will review the system values that you can use to implement your password policy.

For starters, you should not have any permanently assigned passwords on your system.  While this is technically possible, it is NEVER recommended.  The system value QPWDEXPITV lets you enforce how often your users need to change their password to continue valid access to your system.  IBM recommends that you do this every 60 days.  Since users have to change their passwords often, some users may want to just alternate between two favorite passwords.  Another system value control in place is QPWDRQDDIF, which defines how many password iterations can go by before a password can be reused.  IBM recommends you set this to level 5 which will enforce 10 iterations.  I recommend a higher number to discourage this practice altogether.

To control how your password is constructed, you want to eliminate common words and names from use so that password guessing is ruled out.  One easy way to do this is to exclude all vowels from use in passwords, which can be done using the QPWDLMTCHR system value.  This lets you specify up to 10 characters (letters or numbers) that must be excluded from passwords.  By using the string “AEIOUY”, you will exclude all vowels from use in passwords.  One thing to note is that the QPWDLMTCHR is not enforced when you are using long passwords at password level 2 or 3 (QPWDLVL).  Another system value that controls password content is QPWDRQDDGT.  When this value is set to ‘1′, then each password must include at least one numeric digit, again making guesswork that much more difficult.

There are three more password system values that help to control password content.  QPWDLMTAJC lets you disallow repeated adjacent numerical digits in the password when the value is set to ‘1′.  Similarly, for characters, the QPWDLMTREP does the same function for alpha characters.  For this value, using ‘1′ will disallow the use of the same character anywhere within the password.  The value of ‘2′ will disallow consecutive use of the same character.  Lastly, the QPWDPOSDIF system value controls password changes.  When this value is set to ‘1′, a new password cannot have any character in the same position as the previous password.  This prevents the user from changing their password by just changing one or two characters.

Two system values control the minimum and maximum length of your passwords.  QPWDMINLEN defines the minimum number of characters required by your password.  IBM recommends a setting of 6, and I concur.  QPWDMAXLEN defines the maximum number of characters.  IBM recommends that you set this to 8, but I really don’t know why.  It depends on the type of passwords you are using as defined by the QPWDLVL setting.  Depending on how this is set, your system might support password lengths up to 128 characters of mixed case values (but that is a different discussion).

Lastly, if none of these settings will adequately implement your password policy, you can write your own exit program.  The system value QPWDVLDPGM will let you register your exit program.  When there is a program registered to this exit point, it will be called whenever a new user is added or when a password is changed.  Your program can do any additional validation testing, returning a pass/fail indicator to the exit point.

This seems like a lot to consider, but with the system values set properly, you can let the operating system enforce your password policies without a second thought.  You only have to set them up once and they will do the job faithfully from that point on.

If you have any questions about this topic you can reach me at rich at kisco.com,  I’ll try to answer any questions you may have.  All email messages will be answered.

The Case For Better User Profile Names

By Rich Loeber

Ever since I started working in an environment where I needed a user profile and password (yes, there was a time when these were foreign concepts), I have always used a simple profile based on my first name.  As I moved from System/34 to System/36 to AS/400 to iSeries to IBM i on PowerServer, I just kept that same simple profile name.

But …. no longer.  I am now a firm believer that first name profiles are a very bad idea.  There are several reasons for this change.

First, recent studies show that people are really bad about picking secure passwords.  Current studies show that, unbelievably, the most commonly used password is “password”!  Check this for a recent list of the most commonly used passwords.

Since people are so bad about choosing passwords, having a user profile that is easy to guess makes a scripted attack very possible.  In a scripted attack, a hacker attempts to gain access to your system by trying a typical user profile in combination with the list of commonly used passwords.  If your system has simple first name profiles, then it could be at risk.  Even if the hacker does not gain access to your system, they could easily end up disabling a lot of your user profiles because of multiple logon failures.

There are two ways that a scripted attack is normally mounted.  The most obvious is via FTP.  In the scripted attack, a series of logon attempts is done using an automated FTP client.  Common profiles are coupled with common passwords and repeatedly tried to see which combination works.  When a match is found, the profile/password is reported back to the hacker so they can explore further at their leisure.

On our IBM i test box, FTP scripted attacks are all stopped before they get to the point where a logon is run.  This is because we use our SafeNet/i exit point security software that only lets FTP connections in from known and trusted IP addresses.  We collect the profiles used, however, so we can report to you on the most commonly used profiles that we are seeing.  From these FTP attempts, the most common user profiles used are:

ADMINISTRA
ADMIN
TEST
ALAN
ALBERTO
ALEX
AMANDA
ANGELA
ANNA
ANONYMOUS

Since we are protected by SafeNet/i, we were not too worried about the few common user profiles we had until a recent attack resulted in two profiles being disabled.  We quickly turned to our exit point log, but there was no record of the activity.  We also checked the system log (DSPLOG) but nothing reported there shed any light on why the profiles, including my trusted personal profile, got shut down.  As a last attempt to discover what happened, we turned to the system security audit journal.  What we found there was an eye opener.

We run the POP server on our IBM i.  We use it, in combination with the SMTP server, for sending outbound email from the system with our WebReport/i software.  This lets us send email without depending on any other office servers.  What we discovered from the system audit journal was that another form of scripted attack was taking place under the covers on the system with no knowledge on our part.  A little research revealed that we were being subjected to what is known as a “Brute Force POP3 Attack”.  It is like an FTP scripted attack, but broader in scope.

An analysis of the T-PW records recorded in the security audit journal showed that over a one month period, more than 20,000 attempts had been made to log into POP3 accounts.  Fortunately for us, we were protected by quite a few other best practices for IBM i security, not the least of which is that we do not use the POP server on our IBM i for inbound mail, so none of the mailboxes actually exist.  That, however, does not stop the hacker from trying.  And, since people tend to use the same password in all places, a user profile/password combination found at the POP server level could easily be tried to gain access to the system by other means.  From our analysis of these break-in attempts via the POP server, the most common user profiles are:

ADMIN
INFO
DATA
TEST
ROOT
MARK
SERVER
MAIL
MARY
SUPPORT
ORACLE
GUEST
DANIEL
GEORGE
ALEX

By looking at these, it is clear that the hacker or hackers are not aware of the type of system that they are trying to access.  None of these profiles are commonly used on the IBM i platform.  But, you can see some profiles that might easily be in existence on a normal system deployment which gives cause for concern.

What can you do?

Here are some simple ideas in brief:

  • Don’t keep the POP server active on your system if you don’t need it.
  • Don’t keep the FTP server active on your system if you don’t need it.  If you do need it, only have it active during hours when you expect it will be used and shut it down during other times.
  • Implement enforced password rotation if it is not already active.
  • Implement the user profile password rules to always require a numeric digit as a component of the password.
  • Review the active profiles on your system for simple first names and get them changed.
  • Check the common profiles used on most IBM i systems and make absolutely certain that their passwords are complex and hard or impossible to guess.
  • Implement exit point controls, check out our SafeNet/i product.
  • Consider disallowing vowels in your passwords.  IBM i system value password controls will let you do this.  At a minimum, rule our the letters E and A.
  • Check your system security audit journal regularly for T-PW records to see if you are getting unexpected password denials.

If you have any questions about this, or you need help with implementing any of these recommendations, feel free to contact me by email at rich @ kisco.com.  All email inquiries will be answered.

Watch Out When Restoring User Profiles

By Rich Loeber

I was recently confronted with an issue on one of our test IBM i boxes.  The box is implemented as a “warm” backup site for one of our customers.  Every night, a simple FTP of changed objects takes place from their server to our test box.  The theory is that the customer can afford to loose one day’s worth of processed transactions for the ease and relatively low expense of maintaining this sort of backup site.

The problem posed to me concerned their security configuration.  While their program base and data files were all being properly synced night after night, their passwords were growing woefully out of date on the backup site.  If they had an emergency, nobody would remember their older passwords.

I thought that the solution would be simple.  Just run a SAVSECDTA (Save Security Data) on their system, then restore it on our test box.  Before doing this, I compared the user profile base on both systems and found some areas for concern where the same user profile existed in both places.  Fortunately, the RSTUSRPRF (Restore User Profiles) command lets you either restore specific profiles or restore all profiles with an exclusion list.  I wanted to exclude all Q* profiles plus a handful of common profiles that exist on both systems.  My list ended up being fairly short.

I was all set to bring these profiles current, but when I tried the RSTUSRPRF, I was gently reminded that this command can only be run when the system is in restricted state.  Our test box hosts several websites including one that runs in secure HTTPS mode.  Thinking this would be a quick process, I shut down the system after notifying a few people that there would be a short interruption in service.  When the system came to restricted state, I ran the user profile restore which ran quickly and without any issues.

I then restarted the system, and here is where it got interesting.  At first, it looked like everything was fine, but I soon found that the web server instance that was using HTTPS was not restarting correctly.  After poking around for a few minutes, I found that it was objecting to the digital certificate that was specified for the site.  I fired up the Digital Certificate Manager (DCM) to see what was going on and the certificate looked just fine.  I decided to delete the certificate and re-add it, and here is where the train wreck was revealed.

When I tried to re-issue the certificate, I was advised that my password for the certificate store was invalid and that I would have to change the password before I could issue the new certificate.  I dutifully changed the password, but the same error kept coming back up.

After a long investigation period, I finally determined (with help from on-line friends) that the root of the problem was the RSTUSRPRF.  It turns out that the restore user profile process restores critical data and keys for the digital certificate store while restoring your profiles.  I now had this information from our client’s box, not ours.  None of the certificates on our system were valid any longer and additional applications on the test box were also failing because of this.

The solution was fairly simple.  You just have to restore the Digital Certificate Manager objects from a security backup from your system on top of the restore just done from the foreign system.  The RSTUSRPRF has the following format for this process:

RSTUSRPRF USRPRF(*NONE) SECDTA(*DCM)

It took me a while to find a current backup of our system’s security data (another story for another time).  As soon as I did this, then DCM would work correctly and the invalid digital certificates could all be re-created.  While our system was not technically down for this time period, several applications were knocked out for almost 6 hours.

Who would ever guess that restoring user profiles would end up hosing your digital certificate files?  A friend blames this all on IBM for such a kludgey implementation of DCM.  I have to say that I agree.  The save and restore of this certificate information should not be hidden along with the user profile save/restore.  The fix should be a new command from IBM for RSTSECDTA.  Let the user profile restore do just that and move other operations to a different command process.

Hacking Report For Our IBM i – 1st Qtr 2013

By Rich Loeber

For years, Kisco Information Systems has kept a lone test IBM i server hanging out directly on the Internet.  No firewall, no security appliances, just a direct connection with a dedicated IP address.

Not a very good idea you say?  Well, Kisco sells a network security software solution called SafeNet/i and what better environment to test and prove that the software works.  Using a combination of the best IBM i OS security practices along with a full implementation of SafeNet/i, Kisco is happy to report that their server has never been hacked successfully ever since this test server was first placed on the web more than 15 years ago.

That’s a good record!

But, that is not the purpose of this report.

To help IBM i shops understand the reality of network threats, we are now reporting some results of what we see on this test box.  We hope that it will help IBM i users to better prepare for the very real threats that exist.

This report shows what we’ve seen on our server during the first three months of 2013.

During this time, our test box reported 211,346 network transactions that passed through the various exit points registered to SafeNet/i.  Out of this total, 1,603 (0.75%) were identified as illegal access attempts and were denied.  That represents about 18 times each day when someone tried to gain access to our system, but was not authorized for that network activity.

Of these 1,603 access denials, all of them fell into just two categories during this test period.  FTP access connections accounted for 1,025 and the other 593 are Telnet connection attempts.  All of these connection attempts were refused by SafeNet/i before the requests even reached IBM’s OS.

A further look at these access denials shows that 1,015 of them came from user profiles that do not exist on the server.  The most popular profile, by far, was “ADMINSTRA” which accounted for 700 failed attempts.  The next most popular was “ALAN” with 37 followed by “TEST”, “ADMIN” and “ALBERTO”.  All of these were FTP connection attempts.  These all appear to be FTP script connection attempts, probably cycling through a series of popular password combinations.  It argues strongly for user profiles on the IBM i that are not based on people’s first names or job functions.

Looking at the access denials from a different perspective, we see that all 1,603 during this test period were denied access because they originated from IP addresses not recognized by SafeNet/i.  For FTP and Telnet connection, SafeNet/i only allows a connection to be established when the IP address is recognized.  By carefully maintaining the table of legitimate connectors to the system, illegal connection attempts are controlled.

Of these illegal connection attempts, 49 source addresses tried to connect multiple times.  The most persistent tried to connect 367 times in succession, all of which were denied.  There were others from different source IP addresses who attempted to connect 271 times, 195 times and 118 times.  Some only tried twice.

Are these illegal connection attempts really something to be concerned about?  To check this, we did a reverse lookup on the most common IP addresses that were denied.  Two of the addresses checked back to an ISP in Brisbane, Australia.  Two others were tied to ISPs in Scranton, PA and Galloway, NJ neither of which are associated with any known developers that we normally work with on this server.  The obvious conclusion was that these access attempts were malevolent which is all the more troubling since the IP address of our server is not generally known to the public.

During this study period, 18 valid source IP addresses connected over and over again to get their legitimate network work completed.

For those attempting Telnet connections, the pattern is a little different.  Within the IBM i OS, all of these failed attempts are logged under the common user profile of QSYS.  Telnet attempts, however, do not follow the brute force attempts that FTP users try.  They tend to be solo connection attempts or just two in a row.

Kisco Information Systems will keep an eye on these connections attempts and will periodically issue updates on the results by quarter.  Feel free to check back to our IBM i Security Blog for future reports.  If you have questions about details of the report, feel free to contact me directly by email (rich at kisco.com).

Tracking User Profile Signon

By Rich Loeber

I recently received email from a reader asking me how they could track sign-on activity for their security officer user profiles.  The objective was to have a record of every time someone started a terminal session from one of these very powerful user profiles.  Since these profiles have so much power to update and change your system, having a record of when and where these sessions are started is a good idea.  Fortunately, there is a fairly easy way to do this within the operation system on your IBM i.

With each user profile on your system, there is an “Initial program to call” (INLPGM) parameter.  Whenever someone signs onto your system, the operating system checks this parameter and, if there is a valid program present, calls it.  You can take this feature and use it to create your log of user profile sign-on activity for selected user profiles.

The first step is to create a simple CL program.  When the operating system calls the initial program, no parameters are passed, making your task quite easy.  In your CL program, you will need to retrieve the user profile using the Retrieve Job Attributes (RTVJOBA) command.  Armed with the current user profile, then just send a message using the Send Program Message (SNDPGMMSG) command to a pre-defined message queue indicating that the user profile has performed a sign-on operation.  When I was testing this, I used the QSYSMSG message queue since it gets used by the operating system for security related events.  But, you can use any message queue that works for you.

Problems may arise, however, in a couple of areas that you need to be prepared for.  I have created this CL program on my system and have accommodated these issues.  See the end of this tip if you’d like a copy of my source.

For starters, your system may already have an initial program set up for the user profile.  If that’s the case, then you will need to create a data area and store those values before you change the initial program setting.  In my sample program, I’ve created a data area with the same name as the user profile in a special library.  The data area is 20 characters long and contains the initial program and library associated with the user profile before my tracking program is set up for the profile.  Since you want this to work for any user profile, the CL should check for the data area and, if it is not there, just assume that no initial program processing will be needed.  After you have logged your activity message, just end your CL program by calling the program stored in the data area.

You will have to remember that every user profile will have to be able to run your program.  To make sure this is not an issue, you should have the profile adopt the permissions of a security officer profile.  This is done when you compile the CL program by setting the USRPRF parameter to *OWNER and running the compile under the profile of a security officer.

When everything is set but before you actually change the initial program setting on any profile, test your CL program to make sure it doesn’t fail.  This is one of those areas where it would be very easy to shoot yourself in the foot by implementing without testing.  In the worst case, you might get locked out of your system.  So test, test, test before you run with it.

Once implemented, then all you need to do is monitor the message queue.  As users that you are tracking sign on, a message will show up in the message queue.  Using the HELP or F1 key will also give you a date and time stamp of when the activity happened.  If you want, you can also expand the information captured and reported by including other information from the Retrieve Job Attributes command such as job name, job number, etc.

If you have any questions about this topic, or if you would like a copy of my sample CL program, you can reach me at (rich at kisco.com),  I’ll send the CL along and try to answer any questions you may have.  All email messages will be answered.

In this day and age, security officers can also access your system by means other than using a terminal session.  To capture this activity, you will have to implement exit point solutions.  This can be a daunting exercise, but our SafeNet/i software in it’s Lite version, is a very affordable solution to this problem.  It is available for a free 30 day trial if you’re interested.

Making Sense of the IBM i Security Audit Journals

By Rich Loeber

To track security events on your IBM i, the i/OS has quite nicely provided an extensive security audit journal function to help you.  When you have security auditing active on your system, all sorts of relevant security information is regularly stored in your system security audit journal that will help you to know what’s going on with your system.  This is a great feature for the IBM i OS, but capturing the audit information and then using it in a meaningful way are two different things.

This tip will just scratch the surface of how you can start to make some sense out of all the information that is stored with your system security audit journal.

The secret that starts the process of unlocking the system audit journal is the Display Journal (DSPJRN) command.  To work with the system audit journal, run this command for the journal named QAUDJRN.

The command defaults to displaying information to your terminal screen.  This is a hard way to wade through the information, although there are any number of filters that you can use to limit the information displayed.

A better way to work with this information is to run the Display Journal command using one of the options that transfers the journal information into a normalized database file.  This is done by selecting the option OUTPUT(*OUTFILE).  When you do this, you will have to specify the format for the output file.  There are five different formats offered, from *TYPE1 through *TYPE5.  You can use the HELP function to see the difference.  Each higher number format builds on the information in the base *TYPE1 format.  If you’re just starting, the *TYPE1 format should be sufficient.

Once you have your database built, then it is time to start analyzing it to see just what you have recorded in your security audit journal.  For starters, I recommend that you run summary reports on fields like the Entry Type, Job Name, User Profile and so on to see how many records you have in your current journal with various values.  On our test system here, I do this with the old “Query Two Step” of summarizing the information to a file and then reporting that file.  I have some Query definitions that I’ve created for this purpose that I would be happy to share with you in a save file that you can restore to your system.  If you’d like a copy, just let me know by email (rich at kisco.com) and I’ll send them to you.

As you work with the databases that you’ve created and the various analysis reports that you work with, you will also need to have a copy of the IBM i Security Manual handy.  There are at least 100 pages in the Appendix (on ours, it is Appendix F) that describe all of the information in the various database formats, not to mention the codes that can be contained and what they mean.  On our system, I’ve even found codes in the security audit journal that are not documented in the Security Manual.  In that case, the next stop is IBM support.

If the tasks seems too daunting for you, I’m certain that you will not be the first security officer who has thrown in the towel on analyzing this audit journal.  There are a number of third party software solutions that have taken the time to do all of the necessary investigation and one of them might just fill the bill for you, not to mention lowering your blood pressure.