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).

Snooping On Critical Files

By Rich Loeber

If you’re a regular reader, you’ll know that last time around, I presented a method where you can use IBM i/OS object auditing to keep track of who is doing what with selected files and objects.  That’s a good way to keep a record of what’s happening with these critical resources on your system, but no matter how often you check results, it is always after the fact.  This time, I’ll give you a way to track and report on file access for read, change and/or delete with immediate, real time notification.  Using this method, you’ll know right away when someone is in the critical file you want to keep an eye on.  And, nobody will know about it except you, if you can keep quiet about something this cool.

To accomplish this trick, we’ll create a very simple trigger program and then associate it with the file you want to track.  Keeping the trigger program simple is a key to success for this method of object tracking control.  Keep in mind that every time the file is accessed for the method you choose (which you will see as you read on), the trigger program will be run by the system and it will run in line with the application that is accessing your file.  I’ll put in some cautions along the way to point out where this might be an issue.

A trigger program is nothing more than a standard IBM i/OS *PGM object.  When it is associated with a *FILE, the OS will call the program according to the instructions you provide with the trigger file registration.  Your trigger program must have two parameters, one for information about the event and the other a simple binary two byte number that will provide you with the length of the first parameter information.  The first parm can be variable, but for a simple application like this one, you can code it at a fixed length.  The variable length is there to support multiple record length files and the actual record contents are passed to the trigger program, but for our purposes, we won’t be using that part of the information.  I code the first parameter with a length of 136 and the second parameter with a length of 2.  The first 30 positions of parameter 1 contain the file name, library name and member name in that order.  Position 31 will have an indicator as to the trigger event and position 32 has the trigger time indicator.

You associate the trigger program with the file by using the Add Physical File Trigger (ADDPFTRG) command.  The parameters on this are fairly self explanatory.  Since you don’t want to hold up production, use the *AFTER option for your trigger time setting.
The trigger event will indicate when you want the trigger to be called and the values are:

  • *INSERT – whenever a record is added to the file
  • *DELETE – whenever a record is deleted from the file
  • *UPDATE – whenever an existing record is changed in the file
  • *READ – whenever an existing record in the file is read

A word of warning about using the *READ option, this can generate a huge number of calls to your trigger program and it is probably for the best if you avoid using it.  If you want to track multiple events, you will have to register each one with a separate use of the ADDPFTRG command.

When you’re all done with your tracking project, remember to clear your trigger file registrations.  This is done using the Remove Physical File Trigger (RMVPFTRG) command.  Just use the defaults once the file is specified and all of the trigger registrations can be removed at once.

How you code your trigger program itself depends on what you want to find out.  If you’re looking for a specific user profile, then check for it.  If you’re looking for a specific time of day or day of the week, check for that.  When you’ve found something that qualifies, or if you just want to report on everything, use the SNDMSG to send a message to your user profile (or a list of user profiles that you store in a data area) and you’re done.  If you use the SNDDST to send an email notification, it would be best to do this via a SBMJOB so that the application processing is not held up while you get this sent.

To better explain this technique, I’ve written a simple CLLE program that can be used with any file and contains comments along the way to show different options that you might want to implement.  If you’d like a copy of this trigger file shell program for free, just let me know and I’ll send you a copy via Email.

If you don’t want to bother with coding your own solution, Kisco’s iFileAudit software has this capability built in along with a lot of other neat ways to keep track of what’s going on with your files.  It is available for a free trial on your system.

You can reach me at rich at kisco.com, I’ll do my best to answer.  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.

Monitoring For Security Events

By Rich Loeber

Your system is in use by your user community all day long.  Depending on the size of your shop and the number of users, there could be hundreds or even thousands of security decisions being made by your security setup on a minute by minute, hour by hour, day by day basis.  If you’ve done your homework well, those security arrangements will all work to protect your data from being used incorrectly.

But, how do you know when a security violation has been made?

One way is to keep security auditing active on your system and run regular reports from the security audit journal.  In fact, that is a good practice to implement, but it is not going to give you quick feedback when a serious security violation occurs.

When a critical security violation happens, an error notice is posted to the system operator message queue (QSYSOPR).  The problem, however, is that LOADS of messages in most shops go to the system operator message queue and it is easy to loose one in the haze of all that activity.

To address this problem of the security messages getting lost in the system operation message queue, the IBM i OS has an alternate message queue capability set up.  Check your system to see of the QSYSMSG message queue exists in QSYS library.  If you don’t see one, just create using the CRTMSGQ command.

Once the QSYSMSG message queue is on your system, all critical security related messages will also be posted to this message queue along with your system operator queue.  Now, all you need to do is make sure that you end up knowing when a message has been posted.

The quick and easy way is to log on to the system and run the following command:

CHGMSGQ MSGQ(QSYS/QSYSMSG) DLVRY(*BREAK)

Once this is done, whenever a message is posted to the QSYSMSG message queue, it will be displayed on your terminal session as a break message.

But, this could be a problem.  First, it requires that you always be logged on and it limits the number of people who can monitor for security events to one.  A different solution is to create a little CL program to “watch” the message queue for you and then forward the message on to your user profile (or a series of user profiles) when they happen.

This way, you and your security team can find out about security problems in real time and won’t have to wait for audit journal analysis to see that serious security violations are happening.

I have put together a simple little message monitor CL program that works with a set of up to 5 user profiles stored in a simple data area.  If you’re interested in getting a copy of this code, or if you have any questions about this tip, send me an email (rich at kisco.com).

An even better solution is to implement a flexible message queue monitoring software tool such as Kisco Information Systems’ iEventMonitor software.  This will add email and text notification for you and you can implement many of the other features to monitor 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.

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).

Is The Light On, but the Door Unlocked?

By Rich Loeber

IBM i owners regularly boast about the security built into their systems, and rightly so, but if you don’t implement and use the features, they’re not going to do anything for you.

I have mentioned before that I live in upstate New York, in the heart of the Adirondack Mountains.  In our neck of the woods (literally), security is not much of an issue for most people.  In fact, most of our neighbors never lock their homes or cars since theft is just not a problem.  At our house, we have extensive outdoor “security” lighting installed, and we use it whenever we go out at night.  We even have one light on a motion detector that comes on automatically in case we forget the other lighting.  But, even with the lighting on, we usually leave the door unlocked just because it is easier to get back in when we return home.  If we ever get ripped off, we shouldn’t be surprised as to how it happens.

I’m surprised, however, when I hear about and work with IBM i shops that have this same approach to computer security.  An alarming number of shops just do not pay attention to security issues and are surprised when a problem develops.  The IBM i OS provides robust security capabilities and tools, but too often they go unused just because it is easier without them.

I remember an IT director I knew, I did some consulting work for his company.  I encouraged him to move up to security level 30 and implement object level controls on several mission critical files on their system.  He gave it a try and, without any planning, moved the security level from 20 to 30 and IPL’d their system.  When nobody could sign on except the security officer from the console, he backed the system back to level 20 and never tried it again.  It would still be running at level 20 today if the company had not gone out of business.

My company sells a number of security solutions for the IBM i market.  I am always amazed at the number of customers who buy our solutions and then never fully implement them.  Some of these, it turns out, purchased our software just to satisfy an audit recommendation or someone else’s concern.  For others, they probably just don’t have the time or the people resources to do the implementation correctly, so they shelve it or put it on the back burner.

The same is true for the shop that never bothers to set up the IBM i OS security.  They’ve made a significant investment in IBM i, but are not bothering to use what they’ve paid for.  Security is just as much of an investment as the computer hardware that it runs on.

You would probably never think of leaving the front door of the building open all night with the lights on.  By that same measure, you should not leave your system exposed to intentional or even accidental abuse when you have it within your grasp to correct the situation and you have all the tools to do so at your disposal.

If you’re reading this and see your own shop (or even yourself), don’t worry.  Its not too late to do something.  Take an incremental approach and develop a plan.  Don’t rush into it, like my friend above, and do something you’ll regret, but don’t just sit there leaving your system exposed.  The important thing is to get started and stop putting this off or waiting for enough resources or budget support.

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.

Hiding Places for Malicious Code

By Rich Loeber

The last time I wrote, it was about tracking down hidden programs on your system that you might not know about (see article).  That time, it was trigger programs that could be sitting on your system just waiting for a specific event.  But, as I’ve thought about this issue since then, there are other places where someone could “hide” a call to a malicious program and easily get overlooked.

This time, we’ll look at two other areas for concern.  These are the system job scheduler and exit programs.  Both are ways that someone intent on doing harm to your system could hide some malicious program waiting for something to happen so it can jump out and cause problems.  In each case, the IBM i OS contains a way to review the programs that are sitting there and you should take a look periodically to see how each is being used on your system.

The IBM i OS has had a nice, easy to use job scheduler built into it for a long time now.  Most shops where I’ve done consulting work seem to know about it and use it for regularly scheduled jobs.  But, that also means that the programming staff is aware of it and could misuse or abuse it.

To review the current contents of the system job scheduler, use the i/OS command Work with Job Schedule Entries (WRKJOBSCDE).  This command will display information about every job in the system job scheduler.  It will tell you what the job is, how it is invoked and when it is next scheduled to run.  You should review each entry to make sure that you know what it is doing and when it is next scheduled to run.  A suspicious job, to me, would be one that is not set to run for quite a while in the future.  Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis.  If you see something on a different schedule than one of these, I’d pay particular attention.

Another place you need to periodically review are the registered exit point programs on your system.  Exit points are hooks into i/OS processes.  These are provided in the i/OS so customers can add their own customized processing called from the OS during normal operations.  For example, many of the third party network security products now available on the market (including our own SafeNet/i) use exit points to add security checking to the various network operations in i/OS.  The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.

To review exit programs registered on your system, use the i/OS command Work with Registration Information (WRKREGINF).  This will display a list of the i/OS exit points on your system, and remember that they are different for every level of the OS.  For each exit point, use the option ‘8′ to see if there is a registered exit program for the exit point.  If you find any, make sure that you know what they are there for.  Don’t be surprised to find some exit programs already registered.  If you are using a network security system, you should find many programs registered.  Also, some come registered with i/OS.  For example, you will find that the IBM product Service Director, uses some of the exit points as does the i/OS Mail Server Framework (MSF).  Just make sure that you can identify each program that shows up as a result of your review.

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.

Can You Trust All Those Trigger Programs?

By Rich Loeber

If you’ve seen the movie “Troy”, or if you were paying attention in history when you were in school, you know that the Greeks brought down the city of Troy with the gift of a large wooden horse.  Of course, unbeknownst to the Trojans, the horse was filled with soldiers and as soon as things settled down in Troy, the soldiers broke out of the horse and took the city.

These days of rampant computer viruses, worms and other malicious programs moving their way around the Internet, the concept of the Trojan Horse is alive and well.  But, you say, I’m sitting here working on my completely safe and secure IBM i system running the most secure operating system in town!  These things can’t affect me.

Think again.  A malicious program can still get written and installed on your system, hidden away waiting for the right event to come out and strike.  How, you ask?  As a trigger program.

When I heard about this, I was much like most of you thinking that this just didn’t apply to me.  But then I ran the audit report that IBM is included in IBM i OS.  Boy, was I surprised at the number of trigger programs that are installed on our closed development system.  I thought that the report would come out empty.  Lo and behold, I got an eleven page report with information on more than 110 trigger programs in place that I had no idea were there.  Granted, most of them appear to be parts of the IBM i OS, but I did find some application triggers that I did not know were there.  Fortunately, I found that none of these were malicious, but I had my doubts for a while since one of them was written by a programmer who left our employee under somewhat of a cloud.

The IBM i OS includes a command that lets you keep track of the trigger programs that are installed on your system.  The command lets you run a master list of all trigger programs and then, periodically, just list the trigger programs that are new or have changed.

To get started on understanding the trigger programs on your system, run the following command:

PRTTRGPGM LIB(*ALL) CHGRPTONLY(*NO)

This will produce a baseline report of all the trigger programs on your system.  Review the listing closely and make sure that you know what each of these programs does.  If you see a program that you suspect, track down the source code and make sure you know what it is about.  If it is from a third party software provider, get a statement from the software vendor that describes what the program is doing.  Since trigger programs react to events, they are good candidates for malicious actions just waiting for the right action to happen on your system.  Be prepared that the command may take a long time to run and you might want to consider running it in batch.

Once you have your baseline report, you can then periodically run the same command just changing the CHGRPTONLY parameter to *YES.  This version of the report will list changes and new trigger programs 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.