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.