Controlling Remote Command Processing

By Rich Loeber,

One of the cardinal rules of securing your IBM i system is to prevent users from having open access to the i/OS command line unless absolutely necessary.  Typically, access to the command line is limited to operators, programmers and other IT staff users who need it to get their jobs done.  But, users in general should never be granted the use of the command line.

But, a knowledgeable PC user, using PC-based software tools such a iSeries Navigator, can run commands on your system without obtaining a signon screen and command line.  Also, when a user submits a remote command, IBM’s i/OS does not honor the Limit Capability (LMTCPB) setting for the user profile in use.  In my book, that is a significant security exposure!  Granted, the user must be knowledgeable, but it can be done.

There are several ways that this can be accomplished, as follows:

•    Using DDM (Distributed Data Management), a user can open a file and use the remote command function to run any command on the remote system.

•    Using the iSeries Navigator client, or other similar PC software, a user can issue a command through DPC (Distributed Program Call) APIs without even using DDM.

•    Using remote SQL and ODBC, some software can provide a remote command function without using either DDM or DPC

So, what’s a security officer to do?

To deal with the DDM issue, one easy way to control this is to simply turn DDM access off completely for your system.  You should first verify that no current applications running on your system require DDM, DRDA (Distributed Relational Database Architecture) or DB2.  To shut DDM off, simply run the following command:

CHGNETA DDMACC(*REJECT)

This step is pretty drastic and will obviously not work for many shops where DDM, DRDA and/or DB2 are in use on a regular basis.  For those shops, your best defense is an aggressive security policy that protects your critical data assets.

If you want to take an more active approach to this issue, then you’ll have to look into coding an exit point program, or you can purchase a third party software package that implements exit point processing.  The easiest approach when creating your own exit program is to limit use of remote commands to a list of known user profiles.  This will allow you to grant permission to process remote commands for known and trusted user profiles while denying permission to all others.  In the exit point process, you can set a flag that will return a failure status to the PC software issuing the remote command process, so your user will know why their attempt failed.  You can find more information about exit point programming in several different manuals.  These include:

  • Implementation Guide for iSeries Security and Auditing – GG24-4200
  • iSeries Security Reference – SC41-5302
  • iSeries System API Reference book

Network/Internet Security

By Rich Loeber,

When your IBM i system is connected to a network, you cannot always guarantee the integrity of the person at the far end of a network connection. If your system is connected to the Internet, ethics go out the window altogether. You have to assume that the person at the far end is a bad guy, then proceed from there. With this tip, we’ll outline an approach to this problem that may help you to focus in on how to deal with the bad guys wherever they may be.

Internet bad guys generally fall into two categories, sneaks and bullies. The bullies you can probably identify easiest, they are the ones who go after you system with active attacks. They will try to break into your system trying just about everything in the book. On our test IBM i server in the office recently, we had a bully come by who tried to log on using over 700 different user profiles in a period of 5 minutes. Each logon attempt was met by our exit point software and tossed out right at the point of entry with a security warning message to our security officer for each try. The user profiles were all different and all “typical” of what you might expect to see in just about any shop in the country. When a bully comes after you, he does it with brute force. They can try to spoof your system, guess your passwords, deny others from using your system by keeping it overly busy dealing with their break-in attempt and much more.

The sneaks are a lot more passive. A sneak will sit back and monitor network traffic to your system and try to uncover secret information that will then give them what they need to gain access to your system “normally”. Sneaks are very hard to identify and the have insidious tools at their disposal to get the information they want. This can even include Trojan horses that gather the information for them. Since sneaks are so hard to identify, you should plan your security strategy assuming that someone is always watching your system.

To guard your system against both sneaks and bullies, you need to think about how to layer your system defenses to guard against anything and anyone. If your system is connected to the Internet, you must assume that a sneak or a bully is going to attempt to gain access and plan accordingly. The best defense is always a good offense and you should consider the various layers of your system and have a plan to deal with intruders at every level. This layered approach will help you develop a good defense. The layers you should give consideration to include:

  • System security – including your system level use of user profiles and regularly rotated passwords. For most IBM System i shops, this will be your last line of defense, so plan it well.
  • Network security – this commonly involves implementation of a firewall between your network and the Internet but can also include services available from your ISP. On the IBM i there are also things that can be done at the IBM i/OS server level via exit programs that can address network security issues.
  • Application security – your applications should be designed to integrate with your security policies. Application software can easily be misused and abused and your applications should be designed with this in mind, especially those applications that are open to network and Internet users.
  • Transmission security – when you use an uncontrolled network like the Internet, your data will be open to anyone while it is in transit from one place to another. To protect your data, you need to consider encryption techniques and the use of Secure Sockets Layer (SSL) on your IBM i server.
In your plan for Network and Internet security, you need to have a plan for each of these layers of control in order to guarantee your system. And, even then, a bully or a sneak might still get past you, so watch out.