Controlling Telnet Sessions

By Rich Loeber

I am always amazed at how easy it is to establish a Telnet connection with another system.  Just open a command box on your PC and enter the TELNET command along with the IP address of the system you want to connect to.  On most IBM i boxes, you’ll get the familiar signon screen and as long as you have a legitimate user profile and password, you’re in business.  I recently had a IT manager ask me to connect to their system to do some diagnostic work.  They gave me what appeared to be very secure instructions to obtain a sign-on screen from a web-based applet.  I followed their instructions and ended up connecting and getting the work done.  When I was finished, on a whim, I tried a direct Telnet connection to their system and got through without a hassle.  Their IP address was provided through the web-based application sign-on process which was a significant weakness of that in my book as well.

In other tips about getting control over IP server functions, I recommended just shutting off the server function if you use it sparingly or not at all.  Unfortunately, Telnet does not fall into this category.  IBM i Access uses it to establish emulation sessions and most other legitimate methods for establishing a terminal session end up going through the Telnet server.  So, if you shut off Telnet, you’ll be shooting yourself in the foot.

The good news is that there are several things that you can do to get control over how Telnet sessions are issued on your system.  The first big step you can take is to turn of automatic configuration of virtual devices.  For terminal sessions, these are the pesky QPADEVnnnn sessions that you may be familiar with already.  You do this by setting the system value of QAUTOVRT to zero.

Before you do that, check your system to see if there are active sessions using one of these device names.  If so, then you’ll have to contact the users that are coming in with these device names and get their terminal session configurations updated to use a known device name.

Concurrent with this, you will also have to deactivate automatic device configuration.  Without taking this step, anyone can configure a new device name by just using it in a new configuration.  The first time they sign-on, the system will generate the required device description for them.  You can shut this off by setting the system value QAUTOCFG to zero (off).

Once you’ve made these changes, you should then go through your system and manually removed any QPADEVnnnn devices that have already been created and used on your system.  You can view all of these by going to the i/OS menu named CFGVRT and running option #3 or just run the following command:


This will display all of the virtual display devices on your system, just check those with names that start with the QPADEV.

While you’re making these changes, it would also be a good idea to check the system value QAUTORMT.  This should also be set to zero (off) to help assure a secure system.  This value is used for automatically creating remote controller devices.

Some of your people may rely on automatic device configuration when new devices are attached to your system, and that’s probably still OK.  But, it doesn’t happen every day in most shops which is a good reason to keep it turned off most of the time.  When you need automatic device configuration, you can activate it for a few minutes as needed and then shut it off again.

If you want even more control over Telnet session, you can activate the required exit point and check for specific source IP addresses and only permit Telnet session that are coming from a known address.  Our SafeNet/i network security software includes this feature and we turn away illegal connection attempts to our system on a daily basis with this activated.

Working With IFS Security

By Rich Loeber,

For years, IBM’s i/OS provided robust security for its native file system.  For some of us who’ve been around for a while, this has been all we’ve known on our systems.  But, these days, more and more applications and users are working with the other non-native file systems that are collectively known as the Integrated File System, or IFS.  IBM’s i/OS provides the same level of security in the IFS, but the commands to review items in the IFS and a lot of the terminology is different from what the “natives” may expect to see.  This article will attempt to scratch the surface of this issue by explaining how you can view the IFS directories and files from your i/OS command line and how to interpret the security settings used in the IFS.

The main command that you need to start with is the “Work with Object Links” command (WRKLNK).  These “links” can take several different types, the most common of which are directories (DIR) and stream files (SMTF).  If you thought about this from a PC perspective, these would correspond to disk directories and files.

If you use the WRKLNK command with no parameters, a complete list of all of the top level directories in the IFS (the root) will be displayed.  This display will let you explore the entire IFS on your system, including the “native” file system which will be included under the QSYS.LIB file system.  If you want to go directly to a specific directory, you can do so with a qualified OBJ selection parameter.  For example:

WRKLNK OBJ(‘/qdls/kisco’)

On our test system here, we have a directory in the shared folders file system named KISCO.  The shared folders system is found in the QDLS file directory.  Running the above command gets us straight to this folder without having to spend time searching.

To check on the security setting for an displayed object, just put a ‘9′ next to that object.  This will bring up a Work With Authority display and will give you all of the security information about the object selected.  This will include the owner, any applicable authorization list, any public authorization settings and a list of user profiles that are authorized to the object.  If you want to print this information for an off-line review (or for security documentation), you can use the Display Authority command (DSPAUT).

Data authority in the IFS is described by a series of letter codes which, in combination, will describe the authorities in place.  The applicable access letter codes are as follows:

R – Gives access to object attributes (think READ)
W – Gives access to the object for change (think WRITE)
X – Allows the object to be used (think USE)

You will see these codes in combination or singly (preceded by the ever present *), depending on the authorities implemented.  For example, if full authority is being granted, then you will see the *RWX authority setting displayed.  Specific object authorities are also displayed on this screen.  You can use this screen to make changes and to check on specifics for any object shown by placing a ‘2′ next to the line in question and making updates.

So, if you’ve never (or rarely) considered what’s going on in the IFS on your system, now is the time to get started and the WRKLNK command gives you are very good starting point.

A Solution for the Clear Physical File Member (CLRPFM) Quandary

By Trevor Seeney

All too often I see IBM/i security schematics that gives All Object (*ALLOBJ) to all the user profiles. I have recently seen a security schematic that did not have *ALLOBJ authority at the user profile level but instead had all (*ALL) authority applied to all objects.  Both of these schematics amount to no security at all because all the users can delete any object!

In the ideal world, all physical files should have *CHANGE authority assigned to the general user community (i.e. *PUBLIC), that enables the object to be ‘operated’ (Opr) on but there are no ‘management’ (Mgt) or ‘existence’ (Exist) rights. Existence rights are needed to delete or clear a physical file.

In the real world, most applications use the CLRPFM command. The use of CLRPFM really demands that for each file that is the target of a CLRPFM command, existence rights need to the granted to the target file to avoid an authentication failure during execution.

To be correct, what is required is to identify each incidence of the CLRPFM command and grant object existence or *ALL authority to the target file. Finding instances of the CLRPFM command is straightforward enough using the search capabilities of the Program Development Manager (PDM), but then changing the authority on the individual files is a laborious effort. As such, this effort is often not done and the easy way out is taken, that being to grant *ALL authority to all of the physical files. Not good!

There is a quick, albeit sneaky, way of identifying the targets of the CLRPFM command and granting existence rights to the file. The solution deploys a user-defined variation of the CLRPFM command with a Validity Checking Program attached.

Validity Checking Programs

When creating a user-defined command, you can attach a VCP that can be used to perform additional validity checking of the command’s parameters that are not provided for within the command definition itself. To perform these additional validity checks, the CL Syntax Checker runs the VCP when a command with one attached is entered (or changed)  in a source member. Putting it another way, when a command with an attached VCP is entered using the Source Entry Utility (SEU) under CL syntax, the program executes right there and then! In fact, if you compile the CL program, the VCP will execute during compilation.

Before we tackle solving the CLRPFM quandary with a VCP let’s take a couple of minutes to knock up a quick example. We’ll write an abbreviated Work Active Job command.


  • Type into QCMDSRC file a member called WAJ (for work active job) the single line ‘CMD
  • Type into QCLLESRC file a member called RETURN, the single line ‘RETURN’ and compile. This will be the command processing program
  • Type into QCLLESRC file a member called WAJ, the single line ‘WRKACTJOB’ and compile. This will be the validity check  program
  • Create the command as follows:- CRTCMD CMD(WAJ) PGM(RETURN) SRCMBR(WAJ) VLDCKR(*LIBL/WAJ).

Entering the command WAJ into a source member under CL syntax will cause a Work Active Job display to be launched from within SEU!

Compiling the CL program will cause a Work Active Job display to appear again.

Solving our CLRPFM Quandry with a VCP.

Let’s now apply the technique above to the CLRPFM command. We’ll name our command @CLRPFM.  Since the CLRPFM command has parameters, our programs are a little more involved but not by much.

In Figure 1 below at call-out A is the command definition of the command @CLRPFM.  With parameters representing a qualified file name and a member name.

At call-out B is the VCP which is executing the Grant Object Authority command.

At call-out C is the CPP which has no executable commands.

* It should be noted that the CPP and the VCP should have the same parameters passed whether they are used or not.

Finally at call-out D is the command creation string.

The underlying search function of PDM is the command Find String PDM (FNDSTRPDM) and we can execute same over our production CL source file to find all occurrences of CLRPFM and change them to @CLRPFM by inserting the @ sign. This will cause the VCP to execute and thereby grant *ALL authority to the *PUBLIC for the referenced file. Repeat the ‘Find’ within the member until all CLRPFM commands have been found and then exit the source member without update. Repeat until FNDSTRPDM has finished executing.



Using the technique described herein will apply existence rights, i.e. the right to clear file, for only those files that need it. All other files will have the standard authority applied.

About the Author:

Trevor Seeney is the Technical Director at Sentinex Inc. Trevor is a specialist in IBM/i system security. A COMMON presentation entitled ‘How an iSeries/400 is hacked and how to stop it’ spawned an article for Midrange Computing and a Webinar on Search-400. Trevor also developed a workstation security product for the System/i, which secures inactive work stations and is commercially available today under the name of ScreenSafer/400 and is distributed by Kisco Information Systems.

Securing Printed Output on your IBM i

By Rich Loeber,

In today’s security conscious environment, most System i shops have already locked down their systems.  Object level security is locked down and users are classified as to what they can and cannot do when they are logged onto the system.  But, securing files is only part of the problem.  If a user can’t look at a file, but they can look at processed output sitting in a print spool file, then your hard work of locking up the files is for naught.

There are several things you can do to control spool viewing.  For starters, review your user profiles to see which users have the special authority of *SPLCTL or *JOBCTL.  Both of these special authorities can give a user access to spool files.  Only security officers and system operators should have these authorities.  In a smaller shop, this might also extend to your programmers, but not always.  Generally speaking, most users should not be given these authorities unless they absolutely must manage their own print spool files and job controls.  As a first step, these authorities should be limited as much as possible, especially the *SPLCTL authority because it is not subject to any restrictions and allows the user access to all spool files on your system.

Output spool files are special objects on your system and are not, per se, created with standard IBM i/OS security controls.  The way you can control security on spool files is through the way your output queues are set up and authorized.  If you have output reports with sensitive information, you can control who can see them by the output queue where the report is stored.  Output queues are created using the CRTOUTQ (Create Data Queue) command and they can be changed using the CHGOUTQ (Change Data Queue) command.  You can view the way and output queue is configured with the WRKOUTQD (Work with Output Queue Description) command.

The user profile that creates the report can always view it and control it.  Sensitive reports should be created using a restrictive user profile to prevent widespread use of the spool file.  To impose even stricter security, there are several parameters you can set when you create an output queue that will provide more control:

  • DSPDTA    Helps to protect the contents of spool files be defining who can display, copy, move or send a spool file in the output queue.
  • AUTCHK    Defines what authority is needed to change or delete a spool file.
  • OPRCTL    Defines whether a user profile with *JOBCTL authority can work with spool files in the output queue.

Using these three parameters, you can impose very restrictive access controls to spool files associated with an output queue.  There is a good chart in the Security Reference guide that shows how the three parameters work together.  If you have never given this concept much thought, you should conduct a thorough review of how your current output queues are set up to make sure that they conform to your company’s security policies already in place.