About admin

Founder of Kisco Information Systems

Using IBM i Port Restrictions

By Rich Loeber

Anything that you can do to discourage unwanted access to your IBM i system is a good idea. So, when I heard about Port Restrictions, I immediately thought that it would be a great idea to just shut down all the unused ports on our test box.

Unfortunately, the term “Port Restrictions” is a little misleading in this case. The IBM i OS port restrictions provide a method to reserve a specific port or range of ports to be used by a specific user or group of users. Some may initially think that this is a way to define ports that specific users are NOT allowed to use, but the exact opposite is what happens. When a port restriction is in place, the named users are granted access to the port.

According to IBM documentation, port restrictions are specifically designed for use with end-user custom applications and are NOT intended for use with IBM i OS network functions. For that level of control, you will need to implement an exit point solution such as SafeNet/i from my company, Kisco Information Systems.

If you want to explore using port restrictions, you would do well to review which ports are used by the IBM i OS and carefully avoid implementing any restrictions for those ports. While doing research for this article, we played around with putting in a restriction for FTP on our test box. We restricted port 21 (FTP) to a specific user on our system and then ended and tried to restart FTP on the system. It shut down OK but would not start back up with the new port restriction in place. As soon as we removed the port restriction, FTP started right back up again. We run IBM’s security audit journal on this system and the attempt to start FTP with the port restriction in place also generated an Authority Failure entry (AF).

To avoid this kind of problem with normal TCP/IP functions in the IBM i OS, you should review the list of ports used by the OS. Here is a link to a good list of those ports at the IBM i support website:


If you think other port numbers are being used on your system, you can use the NETSTAT command with the *CNN (Connection Status) option to see which port numbers are in use. The display will default to standard port descriptions, but you can use the F14 function key to change the display to show actual port numbers. Look through the list to see if there are any port numbers not on the IBM i OS list. If you are more comfortable using IBM i Access Client Solutions, you can display this information by clicking on Network -> TCP/IP Configuration -> IPv4 -> IPv4 Connections. This interface will default to showing the port numbers right away and you can export a file of the information in CSV format to help with your analysis of the port numbers in use.

If you do want to create a port restriction assigning a port to a specific user profile, use the Add TCP/IP Port Restriction (ADDTCPPORT) command. IBM i documentation for the use of the command can be found here:


Here at Kisco, we have a test IBM i server sitting out on the internet without a firewall so that we can observe bad behavior. Our system is protected by our SafeNet/i software and we find that it is secure as a result. While reviewing the bad behavior on this test system, we see access attempts using the full range of port numbers on a regular basis. These connection attempts are disallowed since there are no applications active on the system looking for traffic on those ports, but if you have applications using specific ports, then you should take a serious look at implementing port restrictions on those port numbers.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

Who’s Connected to your IBM i?

By Rich Loeber

Have you ever wondered who is connected to your system with a network connection? In these days of interconnected systems, this should be a concern for all IBM i security officers. Even if you have fully deployed firewalls and exit point security, the answer to the above question might contain some surprises.

The good news is that the IBM i OS has an interactive utility that can answer this question for you simply and easily.

If you are comfortable with the 5250 terminal interface, just run the following command:


A display will come up that shows all of the IP4 TCP/IP connections to your system that are currently active. Page down several panels until you see an IP address showing up in the left hand “Remote Address” column.

Scroll around and check to see if there are any IP addresses that you don’t recognize. If you see any for, these are probably tied to your use of IBM Navigator for i. The listing under the “Remote Port” and “Local Port” column will give you an idea of what the connection is doing on your system.

If you are more comfortable with using IBM’s Navigator for i interface, start the utility and select “Network”, “TCP/IP Configuration”, “IPv4″ and finally “IPv4 Connections” to get the same information as the NETSTAT command above. This interface has the added bonus of allowing you to generate listings or a CSV download version of what you are looking at.

If you see an IP address that you are not familiar with, both interfaces give you the option of stopping the connection. On our test system, I often like to look up the IP address to see who “owns” it. There are several options for tracing an IP address; one such is:


In the above case, the IP address listed at traces back to an Amazon server. That’s not much help in zeroing in on an individual, but it lets you know what might be going on. In the case of our server, this does not concern us as the SMTP server is locked up tight.

If you find connections that are suspicious, it is imperative that they be investigated. Check your exit point implementation to make sure that you have source IP address controls in place. Connection attempts will show up with the NETSTAT command before they are denied by your exit point implementation. If your exit point does not give you source IP address controls or you don’t have exit points implemented yet, consider Kisco’s SafeNet/i – http://www.kisco.com/safenet – to implement them.

Kisco’s iEventMonitor software – http://www.kisco.com/iem – can be configured to issue alerts when unfamiliar IP addresses are detected. It lets you define the IP addresses that you trust and any others that connect will result in an alert being issued. It even offers you an exit point so that you can take your own actions when an untrusted IP address is detected. We have implemented our own user exit program to terminate unknown IP address connections using the ENDTCPCNN command.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

IBM i SMTP Relay Controls

By Rich Loeber

Updated March 4, 2021

Many IBM i shops keep the SMTP server active on their system to support host-based applications that format and send e-mail messages directly from their IBM i system.  With the SMTP server active, you could leave your system open to spammers who could take over the SMTP server to relay their spam messages.  This tip describes how to control SMTP relay on your system.  You can check to see if SMTP is active on your system by running the following command:


If there are any tasks displayed, then the SMTP server is active on your system.

Controlling SMTP mail relay involves two processes.  First, you have to set the ALWRLY parameter in the SMTP Attributes on your SMTP server.  This is updated using the CHGSMTPA (Change SMTP Attributes) command.  Keep in mind that your user profile must have the *IOSYSCFG special authority to be able to use the CHGSMTPA command.  When you first prompt the command, press the F9 key to show all of the parameters.

If you just want to deny all mail relays, set this value to *NONE and you’re all set, you can stop reading now and move on with your life.  However, if you are sending mail from your IBM i using the SNDDST command, SNDSMTPEMM command or other program-controlled methods, you cannot leave this setting at *NONE as it will block mail being sent from your system.  Simply changing this setting to *ALL is not a good idea either as this will allow anyone to relay mail through your system.  The best choices are one of the following:

•    *LIST – only IP addresses that match an *ACCEPT SMTP list entry will be allowed or denied
•    *NEAR – only IP addresses that match a *NEAR SMTP list entry will be allowed
•    *BOTH – the system will look at both the *LIST and *NEAR entries

Once you have this part configured and have specified one of the three recommended settings, you will then have to update the SMTP list to indicate who can relay mail.  This is done using the ADDMSTPLE (Add SMTP List Entry) command.  There are a lot of options for this, but as a simple example let’s set up an entry that will permit mail to be relayed from your IBM i.  If you system has an IP address of, then you would add a relay accept transaction that looks like the following:


This entry will accept all SMTP mail that is sent from the specific IP address indicated in the INTNETADR parameter.  The subnet mask used here is coded so that only the specific IP address will be processed.  You can also use this command to post a *REJECT or *NEAR entry to the SMTP list to indicate specific IP addresses to be rejected or to define a system to be considered as a *NEAR system.  Varying the subnet mask can let you define ranges of IP addresses and if you need help on how to code these entries, feel free to contact me.  Once entries have been added to the SMTP list, you can delete them using the RMVSMTPLE (Remove SMTP List Entry) command.  It would be nice if IBM provided a WRKSMTPLE command too, but the test system I work on has no sign of this feature.

If you have been using SMTP list entries for a while, you may need to know what entries are already established on your system but IBM i provides no support for a review function.  You can, however, review what is already set up by examining the various members in the file named QATMADRLST in library QUSRSYS.  Each member, which you will find appropriately named, contains the list entries for that type.  A simple query report can list the entries and you can remove unwanted entries as needed.

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.

Changing Your Signon Screen – A Good Idea

By Rich Loeber

The classic IBM i signon screen has been around since forever.  I first saw it in 1988 when I took delivery of my first AS/400 system, a lowly B10.  In the old days, the appearance of the signon screen made no difference since the system was a closed system.  With the advent of networks, this situation changed dramatically.

Today, all IBM i systems are networked and users connect via that network connection.  The signon screen is projected to terminal emulation software throughout the network and even over the Internet for users that are accessing the system from remote locations.  Because of this, the signon screen standard context can be easily recognized by people with malicious intent and scrubbed (sniffed) for user id and password information.

Granted, for many users, this information is encrypted.  But, with the proliferation of open access protocols, there are many emulators that do not encrypt this information.  Examples of this are hand-held devices (tablets and phones) and the Telnet capabilities of Windows platforms.  For my own system, I access it when traveling via my Android smartphone and no encryption is taking place.

A second reason is that the classic signon screen presents a field that could provide a saavy user with a way to bypass your intended signon process sequence.  Next time you sign on using this screen, just type QCMD in the “Program/procedure” field and you will get a demonstration of what I mean.

For these reasons, it is probably a good idea to design your own signon screen so you change the standard terminology used to identify the User and Password fields and disallowing the “Program/procedure” field.  Making the change is fairly easy, but you need to be careful and you need to test your new screen before rolling it out for general use.

IBM ships the source code for the standard signon screen in a source physical file named QAWTSSRC in library QSYS.  In this source file, you will find two sets of code for the two possible standard screens on your system, QDSIGNON and QDSIGNON2.  The first is used when you have standard 10 character passwords configured and the latter is used when you have set your system up for long (128 character) passwords/pass-phrases.  I recommend that you move the source that you want to use into a separate library, thereby preserving the original source in case you get in trouble.

Once you have the source moved into your own library, you can then use Screen Design Aid (SDA, PDM option #17) to make your changes.  When working on your screen, make sure that you observe the following:

  • Do not delete any of the input capable fields that are on the signon screen.
  • Do not change the sequence of any of the input capable fields.  You can move them around on the screen, but keep their sequence in tact.
  • Do not change the characteristics, especially field lengths, for any of the input capable fields.
  • Do not attempt to use any DDS HELP capabilities for the signon screen.

Since one objective is to change the reference to “User” and “Password”, pick out suitable replacements for these and make sure to change the text for those areas.  I would suggest alternatives here, but that could just start a new default standard which would defeat the objective of this tip.

The second objective can be accomplished by removing the text field for the “Program/procedure” field and then changing the PROGRAM field so that it is non-display.  This will keep the integrity of the signon screen while preventing this field from being used.

When you are all done, compile the screen into a library other than QSYS.  To implement the new screen, you will need to update the subsystem description.  You can use the Change Subsystem Description (CHGSBSD) command; press the F10 key to display all parameters and you’ll find one that controls the signon screen in use.  Test your new screen in the QPGMR subsystem to make sure it works as desired before rolling it out to QINTER and other production subsystems.  I strongly recommend that you NOT use an alternate signon screen for your system console which is typically associated with the QCTL subsystem.

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.

IBM i 5250 Session Access Controls

By Rich Loeber

With more and more people working remotely, controlling remote access to your IBM i from 5250 terminal session users is more important than ever.  More IBM i shops are opening their systems up to remote access and a terminal session exposes your system to potential abuse.

A good way to control terminal access is by authorizing the remote IP address before allowing a terminal session to connect.  This way, you can control what specific IP address or address range can connect.  This kind of control can be established on your system using an exit point for the Telnet Device Initialization point.  Implementing this control will let you create your own exit program to validate the incoming IP address before allowing the Telnet server on your system establish the connection.  Kisco’s SafeNet/i Exit Point solution delivers this capability.

But, there is a small problem with this approach.  The problem is that at the point at which the IBM Telnet Device Initialization exit calls your program, the only user profile available is QSYS. All Telnet connections run under the QSYS user profile.  As a result, all exit point controls will be applied for all users, not on a user-by-user basis.

To implement source IP access controls by user profile, a much preferred method, you will need to create an initial program that can be recorded for each user profile that you want to control.  This is recorded in the INLPGM parameter for each user profile.  In your initial program, you can then access the source IP address that the user is connecting from and then do your own validation taking the actual signon user profile into account.

In your initial program, you can access the user profile signing on by a simple RTVJOBA CL command.  Finding out the IP address that is being used is a bit more complicated, but not all that difficult.

For this, you will need to code a call to IBM’s QUSRJOBI application program interface (API).  Specifically, you will need to use the call format JOBI0600.  This will retrieve a set of job information for the terminal session that includes the IP address for the user that is connecting.  It will be in position 308 of the receiver variable specified for the API.  If you’re already familiar with using IBM API’s, this is a fairly easy process.  If you’re new to API’s, then prepare for somewhat of a learning curve.

Once you have the combination of user profile and IP address, then it is just a matter of validating the combination against a control database that you can set up for this purpose.

You will find yourself wanting to check a range of IP numbers for validation purposes.  For example, you might want to specify that all IP addresses from to are legitimate.  Depending on the range of numbers, this can be problematic.  If you do a direct range comparison on the previous example, the range will not validate.  When we set this up here, we converted the IP address into a standardized 12 digit number.  For example, ends up being stored at 010 001 001 010 (without the spaces).  This gives you a good base for doing a range check and not having to worry about the effect of the periods and different individual ranges.

Once you have your initial program created and fully tested, you can then implement it by recording the program name and library in the INLPGM for each user profile where you want this control added.  Since your initial program will always run when that user signs on to your system, we recommend that you throughly test your solution before locking down user profiles.  You don’t want to leave yourself in a place where you cannot sign in to your system.

If this looks like a little too much work for you, Kisco Information Systems has recently implemented this idea in is i2Pass 2FA Solution for the IBM i.  It is available for a free trial if you’d like to examine it and it adds Two Factor Authentication to your 5250 terminal session controls as another layer of protection.  An added benefit is that the software is supported in case you run into problems.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

On-Line Meeting Etiquette

By Rich Loeber

I occasionally like to take this space to write about something other than IBM i security concerns and this is just such a time.  With the shelter-at-home orders in place for several weeks now, I have been having lots of meetings on-line using video conferencing tools.  My tool of choice has been Zoom, but I’m sure this can apply to any such service.

This blog entry is the result of observations of behavior during on-line meetings from people who are mostly new to the genre.  I hope that these “etiquette” tips are helpful for my readers as they get used to new ways of meeting and socializing on-line.


Keep in mind that this is not only an audio conference call, but a video (ie: visual) conference call.  As such, your lighting is important.  A major benefit of video meetings is that you can better “read” others in the meeting because you can see them.  If the lighting for your image in the meeting is such that your face is in shadow, then the benefits are lost.  I have poor lighting in my office with a big window on one side and glaring florescent lights in the ceiling.  After some experimentation, I bought a bright LED desk lamp which I now use while turning the overhead lights off.  It produces a much better image.

One thing I’ve noticed that frequently happens is that someone sets up their camera (or laptop) so that there is a window behind them.  This invariably results with their face in shadow.  I was in a meeting of local relief organizations recently where one participant, who had a lot to say, was just a shadow on the screen for the entire meeting.  It was very frustrating.


I know you’re working from home and it is convenient to try and multi-task by having your lunch during the meeting, but I point out again that this is a visual medium.  If you were at an in-person meeting in a conference room, would you want to be the only participant having lunch while all the others sat there and watched you eat?  I doubt it.  The same is true of your virtual meeting.  For me, I think this even extends to chewing gum during the meeting.  During another meeting last month, someone actually spent part of the meeting in the kitchen cooking themselves lunch which they then proceeded to eat on camera.


Another good practice is to keep your microphone on mute when you are not talking or being called on to talk.  My office is located on a state highway.  I get big trucks rumbling by and the occasional emergency vehicle screaming past, so I stay on mute as much as possible.  If you’re working from home, it is not uncommon for a barking dog, a ringing telephone or any one of a myriad to audible interruptions to intrude that will detract from the meeting.


During the meeting, stay engaged.  If you are trying to process email or do other things during the meeting, it will show in your level of attention and participation.  Another behavior that I’ve observed is someone who spends an entire meeting propping up their head with their arm.  During that meeting, I wrote them off as bored to death and not interested in what was going on.  That may not have been true, but do you want to send that message to the others in attendance?


I have also been in several meetings where one or more participants had no idea what they were doing and how to control their conference session.  If you’re a host, take the time before any meetings to understand the tool that you will be using.  I can commend Zoom for the plethora of aids that they have available, including on-line orientation sessions for hosts and even meeting guests.  My solution is to have a dry run with a friend.  Take the time to understand how to turn your mic off and on.  Learn how to share content and then un-share it.  Learn the various display modes that you can use.  Get comfortable with the tool.  I was in yet another meeting recently when someone in the meeting accidentally shared their screen and then no amount of coaching them during the meeting could get the shared screen turned off.

If you have questions or comments, feel free to contact me directly by email: rich at kisco.com.

IBM i Security Concerns While You’re Working From Home

By Rich Loeber

During this time of Covid-19 crisis, most of our customers are reporting in that they are working from home and will probably be doing so for several months.  We are working independently here too where I find myself the only one in the office.

With so many people working with remote access, what are the security risks to your IBM i as a result?  If you aren’t mindful of security during this crisis, you could expose your system unnecessarily and create issues for you that will last a lot longer than the current crisis.

Here are a few that come to my mind right away ….


If your users/programmers/system administrators are using 5250 terminal sessions to access your system, make certain that they are all using SSL for the connection.  Last month, I posted an update to a prior blog post on this topic.  If your terminal sessions are not using SSL, then your user profiles and passwords are traveling over the Internet as plain text.  Given that programmers and administrators tend to have super user profile privileges, this could be catastrophic.  In my opinion, this should be your number one concern.  http://www.kisco.com/ibm-i-security-tips/?p=312

Browser Based Applications

When you are in the office and working on browser based applications hosted on your IBM i system, you might consider yourself to be safe if you are running the application using an HTTP address.  While that may be true, when you run that same browser based application from home using HTTP, the data that transfers back and forth to your desktop environment will be sent in plain text.  Since most applications require a sign-on process, then your user profile and password are again exposed while in transit.

The solution is to update your HTTP application to use HTTPS protocols.  By making this change, the browser data streams will be encrypted, adding the necessary security that you will need.  Several years ago, I posted a tip here on how to make that change.

File Transfer Protocol (FTP)

While working in the office and hiding behind a firewall, bringing up a quick FTP session on your desktop to transfer IBM i information to/from your personal computer is a quick and easy way to get things done.  Doing that same thing while working remotely can, like telnet and the browser applications, expose your user profile and password as open text.

The solution is to change your access to use SFTP (Secure File Transfer Protocol).  The good news is that IBM i supports SFTP.  I found this article at an IBM website on how to set this up for your use.

This quick tip just scratches the surface of these issues.  These were the issues that came to mind as being highest on a list of concerns.  I would love to hear from any of my readers who have more ideas on areas where we should have serious concerns.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.

Configuring Telnet for SSL

By Rich Loeber

Updated March 2, 2020 for Access Client Solutions emulator.

I was recently asked to secure remote access for 5250 terminal sessions for one of my customers.  I did not have any experience securing Telnet on the IBM i, but I located some good documentation from IBM and was able to get the Telnet connection secured fairly quickly and easily.  This tip will show you how.

Many IBM i shops still use the 5250 terminal interface for administration and operation of their systems.  For them, the interface is well known and comfortable.  The problem is that when used for remote access, the Telnet data stream is passed as open text and it is easy for someone with malicious intent to snoop in on the data stream and capture user profile and password information.

Fortunately, there is a way on the IBM i to encrypt your 5250 terminal sessions by implementing SSL (Secure Sockets Layer) for your Telnet connections.  The IBM i uses a Telnet connection to support your 5250 terminal sessions.

There are two steps that you need to complete in order to set up SSL for Telnet.  Part one involves configuration work on your IBM i server.  Part two is what is needed on your client (your PC) in order to use the SSL connection.

The server configuration will require that you have option #34 (Digital Certificate Manager or DCM) of the base OS installed along with the HTTP server functions.  On our 6.1 test box, the HTTP Server is 5761DG1.  Before plunging into the project, I strongly recommend that you make sure that you have the latest HTTP server PTFs installed.  When we first tried to use DCM after upgrading our OS, it would not work and we needed the PTFs.

To do the configuration work on your host, we found the following article with step by step instructions from IBM and I recommend that you use this procedure:


This process will require you to set up a self-issued digital certificate on your system and then assign it to several applications, including Telnet.  If you have never used the Digital Certificate Manager on your system, be prepared to take some time to get used to it.  The instructions from IBM are actually quite good.

After you get this configuration work done, make sure that you update the Telnet Attributes on your system using the CHGTELNA (Change Telnet Attributes) command.  When starting, make sure that the Allow Secure Socket Layer (ALWSSL) parameter is set to *YES.  This will allow both SSL and non-SSL Telnet connections.  Once you are satisfied with the way the SSL connection is working, you can consider changing this setting to *ONLY which will then refuse non-SSL connection attempts.

Once the server configuration work is done, you can move on to the client configuration work.  Again, I found a good set of instructions from IBM on this that you can access here:  (These instructions are for IBM i Access For Windows.)


This process may require that you install additional Client Access components on your PC, so access to your Client Access install CD may be required.  The process will call for your to import the certificate you created into your PC and then reconfigure your terminal session to use SSL.  When importing the certificate, there is a standard password to use.  That instruction is easily missed, so watch out for it.

If you are using IBM i Access Client Solutions (ACS), the Java based access software, the instructions for the 5250 emulator are easier once the digital certificate has been established using DCM (above).  Using ACS, create a terminal session.  When the session has been created, select the Configuration option under the Communications drop down menu.  Update the “Protocol” to look as follows:

Note that when the Protocol is changed to “Telnet – TLS/SSL”, the “Destination Port” will be changed to 992.  Click on OK and the session configuration change will be set correctly.  Make sure that you now save it.

In addition to setting this up for my customer, I also took the long delayed step of setting this up for my own server.  It is something I should have done long ago and I encourage all IBM i shops to adopt this standard for remote access Telnet session.

After initially posting this tip, a friend contacted me to suggest that implementing SSL on Telnet also helps customers with their PCI compliance requirements.  PCI requires 2 factor authentication.  He reported that one of his customers was able to meet this requirement using SSL.  The two factors involved are the password and the digital certificate.  Two factor authentication calls for something you know and something you have.  SSL for Telnet does just that.  (They also require use of VPN for any remote access.)

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.

Security Levels for IBM i

By Rich Loeber

Your IBM i has a long tradition of boasting about tight security, but is that really true for your installation?

Your very first and probably most basic decision about security on your system is found in the setting for the QSECURITY system value.  You can see your current security level setting by running the “Display Security Attributes” (DSPSECA) command.  One of the items on the display will be your current QSECURITY level setting.

IBM i supports five settings from the value ‘10′ through ‘50′.  On more recent versions of IBM i, level ‘10′ has been thankfully retired and is no longer available.  Here, in summary form, is what you get at each level:

  • Level 10 –  No security at all.  Anyone can signon to a terminal session and no passwords are required.  (Is it any wonder that this level has been retired?)
  • Level 20 –  Signon password security.  Once logged on, all users have access to all objects on the system.  This was, at one time, the default setting when your system was shipped from the factory.
  • Level 30 –  Adds object authority to the above. This level requires some object level access planning and implementation.
  • Level 40 –  Adds integrity protection features to the above.  This is now the default setting shipped from the factory.  At this level, the system enforces the user domain as separate from the system domain.  Program requests that cross this border using unapproved interfaces are disallowed.
  • Level 50 –  Adds additional integrity protection features and is intended to meet the US Department of Defense “C2″ security requirements.  In addition to level 40 controls, certain user objects are restricted, certain messaging options are controlled, modifications to internal control blocks are restricted and changes to the way the QTEMP library is processed.

If you are installing a new IBM i system, your options are wide open and you should choose the highest setting that will work for you.  Using the recommended level of 40 that comes from the factory is an excellent starting point.  Before you settle on this level, however, you should check with any third party software companies whose software you will be using to make sure that their software will run OK at level 40.  Some older IBM i products “misbehave” by using older, now illegal, hooks into the OS.

Level 30 can be used if you have software conflicts that prevent you from implementing level 40.  You should plan how to implement object access controls, starting with controlling access to libraries and then moving down.  Maintenance of object level access controls can be greatly simplified through judicious use of IBM i Group Profiles.  You can break up your user community into logical groupings, create a group profile for each set and then implement your access controls on the group profiles rather than coding controls for each individual user profile.  Care should be taken when dealing with the special group profile *PUBLIC as this can easily overrule your best planning efforts.

Level 20 should NEVER be used in normal situations, and level 50 should only be used when you have the specific requirements called for by the C2 standard.

So, what do you do if you’re in charge of a legacy system that is set to level 20 or 30 and you’re sure that you need better controls?

Moving from level 30 and higher is fairly easy and just requires that you make the change to the system value and perform an IPL.  If you are uncertain about your third party software, you can activate audit logging for a few weeks before you make the change and then review the logs to see if there are any potential problems at level 40 or 50.

If you are at level 20, the move to level 30 can be overwhelming.  There are many legacy systems that have this as an issue.  These systems previously relied on application security and menu controls as their primary safeguards.  With the implementation of network server access, this is a security weakness for these systems.  If your concern is due to network connections to your system, you might want to consider implementing a third party network security solution, such as SafeNet/i from Kisco Information Systems.  These products can give you immediate control over network connections to your system without impairing your ability to service your user community.

You can find more information about this topic in the IBM i manual “Security – Reference” – SC41-5302.  If you have specific questions about this topic, you can reach me at rich at kisco.com,  All email messages will be answered.

Automated Disaster Recovery Restore

By Rich Loeber

By far, the most popular security tip that I have ever posted describes a way that you can do your regular system backups and create a tape that can be restored with a single command, IBM’s LODRUN command.  Since originally posting this tip and the offer of free CL programs to implement it, I have sent the code out to many contacts over the year.

You can see the original post here.  But, don’s stop there as there is a followup updated post here.  Make sure you read BOTH posts.

As always, if you have specific questions about this topic, you can reach me at rich at kisco.com,  All email messages will be answered.