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:

https://www.ibm.com/support/pages/tcpip-ports-required-ibm-i-access-and-related-functions

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:

https://www.ibm.com/docs/kk/i/7.2?topic=ssw_ibm_i_72/cl/addtcpport.htm

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:

NETSTAT OPTION(*CNN)

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 127.0.0.1, 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:

https://www.iplocation.net

In the above case, the IP address listed at 35.165.168.89 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.

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.

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:

http://www-01.ibm.com/support/docview.wss?uid=nas8N1010449

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

http://www-01.ibm.com/support/docview.wss?uid=nas8N1011018

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.

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.

In other tips about getting control over IP server functions, I have 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 off 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 remove 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:

WRKDEVD DEVD(*VRTDSP)

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.

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

Application Software Package Security

By Rich Loeber

I often hear from readers lamenting the deplorable state of security in the third party application software running on their IBM i.  Some products enforce the establishment of a standard group user profile along with a default password for that profile.  Others have their data files configured with all access to the public.  In this day and age, these situations are certainly inexcusable.  But, what can you do?

First, a little history is in order.  A lot of mature third party software has been around since before many of you were working in the IT field.  In those days, there were no PCs, no networks and little connectivity between systems.  Security was controlled at the application level.  By that, I mean that users were presented with menus and could only access data by choosing the right menu option.  If the user wasn’t authorized to use the data, the menu option would not be available to them.  For its day, it was a good security model.

But, today is very different, with FTP, ODBC, Access Client Solutions (ACS) and other such PC-based tools that are connected to your system via high speed network connections.  That old menu security model is not applicable to today’s environment.

In the modern IBM i implementation, if your data files have public access to all users, then someone can connect to your system with FTP and download to their heart’s content.  Granted, they will still need a user profile and password, but is that the security model that you want to enforce for your shop?  I don’t think so.

An even worse situation comes from users with ACS installed.  From their desktop, an adventurous user could easily browse around your system looking for interesting file names and libraries until they find just about everything on your system.

So, what’s the solution to this problem?

First, when you’re shopping for software, the product’s security implementation must be understood before you get too far down the road.  If the product is wide open, move on to another vendor.

If you’ve already got a product with this security model implemented, you probably are not in a position to just switch to another vendor.  In that case, the first thing you should do is contact the vendor and demand that the situation be corrected immediately.  There are lots of easy solutions that a responsible software vendor can implement to correct this problem.  Don’t take “No” for an answer.

If you get little cooperation from your software vendor, you should take matters into your own hands.  The quick solution is to implement exit point controls for the critical data in your system.  If you don’t have the know how or wherewithal to create your own exit point programs, there are quite a few general purpose products on the market today that are good which address this issue (I recommend SafeNet/i from my company!).

The worst thing you can do, however, is to just sit back and wait for your vendor to fix the problem.  In the interim, your data is exposed.  You may think you’re safe, but you just cannot guarantee the safety of your data in this environment.

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

Limiting Security Officer Access

By Rich Loeber

A reader recently posed the following question to me:

How can I limit the places a person can log on as QSECOFR? I don’t want someone to be able to log in from any desktop or workstation as QSECOFR other than the main console. Are there system values related to the QSECOFR profile?

The special user profiles on your system that are set up as security officers really do have the keys to the kingdom when it comes to accessing your system.  No files, programs, data objects, files in the IFS, and more are safe from access by someone who is logged onto your system from one of these user profiles.  Keeping these profiles limited to certain devices is a good objective so that someone using them will be under direct supervision.

The best way to approach this is through a combination of object security configuration on your terminal device descriptions along with a varied setting for the system value QLMTSECOFR.  Your system will come from the factory with this system value set to ‘0’ which lets anyone with *ALLOBJ authority sign on to any terminal session.  Changing this to ‘1’ will only let the security
officer signon to a terminal session where they have specific authority granted at the device description level.

But — WARNING WARNING WARNING — don’t go rushing off to make this change!  You must first get it set up and test it before adopting it as practice could result in your security officer profile getting permanently locked out of your system, and you don’t want that situation on your hands.

So, your first step is to identify the device description object for your system console and make sure that QSECOFR is expressly granted permission to use the object (ie: *ALL authority).   The device descriptions on your system are all stored in the QSYS library with object type of *DEVD.  You can make changes in the authorities for the object using the Edit Object Authority (EDTOBJAUT) command.  When your console device has been updated, find the backup console device description too (on most systems, it is called QCONSOLE) and do the same thing there.

To test this setup, first sign on as QSECOFR on a normal terminal session and leave that active for the duration of your test.  That way, if things go south on you, you still have an active security officer session to fall back on to make changes.  With this backup session active, make the changes to the system value and the device descriptions.  Vary the console device off and then back on too to make sure you’re using the updated authorities for the device.  Then, make sure that you can sign on from the console using the security officer profile.

Assuming that all is OK, you’ll need to scour your system for the other terminal device descriptions to make sure that the security officer profile is not authorized for any of them.  Once this is done, then try to sign on as the security officer on another terminal, it will be denied.

Only when you’re satisfied that everything is working as planned should you release the security officer session that you’ve been holding open as your back door.

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

Are All Of Your IBM i Doors Open? – Part 2

By Rich Loeber

In my last tip, I pondered the need to watch the doors into your system.  In the old days, there was a single door in the form of a display terminal.  Today, that is only one of many doors where users can get into your system.  While most users are trustworthy, there is always the opportunity for inadvertent damage to your data from someone who happens to get into your system through a door that should be closed to them.  Then, there are always those lurking in the shadows who are just looking for an unlocked door to gain access and wreak havoc in the process.

Last time, I talked about the most obvious doors and the most obvious solutions for those situations.  This week, we’ll take a closer look at the less obvious doors and how you can deal with them.

In addition to the obvious doors to your system like FTP and Telnet, IBM i has a variety of server functions included that provide network access points for a wide variety of host-client connectivity.  These includes the likes of a DRDA DDM server that can share data files on a record-by-record basis with a client; the File Server that allows files in the IFS to be directly accessed from desktop applications; the Remote Command server that allows a desktop system to issue IBM i commands directly from the desktop; and so on.  The list is quite comprehensive and many IBM i managers are not even aware of all of the possibilities.

So, my first recommendation for you out there is to educate yourselves about the doors that are there.  Play around with IBM Navigator For i (Navigator) on your system to see all of the server settings and whether or not they are running on your system.

To use Navigator (a component of IBM i Access Client Solutions [ACS]), it must be installed on your PC with all components.  Then, the Admin HTTP server must be active on your IBM i.  It runs in the QHTTPSVR subsystem and, if active, will show multiple jobs with names that start with ADMIN.  If you need to start the admin server, the command is:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

You start Navigator from ACS.  It will start a session in your browser and you will need to sign on with a user profile with security officer permission.  From your browser, select the “Network” tab.  This will present you with a short list of new tabs, open the “Servers” tab next.  To see what servers are actually up and running on your system, look at the tabs marked “TCP/IP Servers” and “IBM i Access Servers”.  These will each show you a list of server functions on your system with a brief description of the function being served and what its current status is on your system.  It behooves you to know about all of those that are showing as started.

Once you have identified all of the server functions that are running (each is a door into your system), then you will need to validate its use on your system.  Identify the application that is using it and check to make sure that security is in place to control what can be accessed through each of these doors.  Also, make sure you know what user profiles are in use for each server function.  If common user profiles are shared between different server functions, you could have a security risk due to contextual conflicts between uses.  This kind of exposure can happen when an FTP user profile needs access to different data than an ODBC user.  If the same profile is used in both contexts, you could end up with a security exposure.  Also, remember that when you open a door for one application, it ends up remaining open for all of the profiles on your system.  You need to have a plan in place to keep the wrong people away from doors that they should not be using.

In some instances, the only way you will be able to make sense out of what is going on will be to implement one or more exit point programs to allow you to see exactly what kind of network requests are happening.  You can either write your own or get one of the several commercially available exit point solutions.  I recommend SafeNet/i from Kisco Information Systems, my company.  This will tell you which profiles are getting into your system through each door and what they are doing when they are in there.  Without knowledge at this level, you’re only guessing at what’s going on.  Guessing at activity does not promote good security policy implementation.

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

Are All Of Your IBM i Doors Open?

By Rich Loeber

Living in a remote area, a lot of people near us like to leave their doors unlocked for convenience sake.  Most of the time this is OK, but occasionally it gets someone into trouble.  A recent local incident got me thinking about all the doors that can be used to enter the IBM i and I wanted to take some time to explore this today.

My wife and I live in the middle of the Adirondack Park, a 6 million acre state park in northern New York (think “about the size of Massachusetts”).  This area houses a year round population of just over 130,000 souls.  As you might imagine, with that population density, security is not a big issue.  I know people here who have no idea where their keys are to lock the doors on their house, and are not worried about it.  Recently, there was a burglary in the town where my office is located.  Someone just walked into the back door of a shop and helped themselves to money in the cash register, then slipped back out without being seen.  This got me to thinking about security on the IBM i and how a similar situation might easily exist at many shops where doors are left open for no good reason.

In the “old” days, the only door you had to be concerned about was the computer terminal.  These were placed in public places and protected by user profiles and passwords.  In order for someone to sneak in, they’d have to be pretty bold and they’d have to know a profile/password pair.  Today, the user profile/password continues to be a primary locking mechanism for your system.  So, this continues to be your first line of defense.

Keeping your user profile list current is probably one of the most important tasks you can do.  Some critical things to remember include enforcing periodic and regular password changes, deactivating and even deleting old profiles for people who are no longer employed there and only providing the level of access permissions that a profile needs.  That’s pretty simplistic, but remember that you’re handing out keys to the doors of your system.  You want to limit the number of keys in circulation and you don’t want everyone to have a master key.  Also, you need to make sure that there are no default passwords active on your system, including passwords for well known third party software packages.  The system will watch the doors for you, but if there is no control over the keys, what’s the use?

Assuming that you have your keys under control, then you need to also take a look at all of the doors that are on a modern IBM i server these days.  The days of only needing to control terminals is long gone.  Today, you need to be concerned about the FTP door, the Telnet door, the Remote Execution door, the ODBC door, the SQL door, the Shared Drive, the Navigator for i door, the file upload/download door and on and on.

For some of these doors, you can easily control access by removing the door altogether.  If your shop does not use FTP on a regular basis, then don’t leave the FTP door in place.  On most systems that I work on, I find the FTP server up and running by default.  It is a simple matter to turn it off with the command:

ENDTCPSVR *FTP

and to use the Change FTP Attributes (CHGFTPA) command to set the AUTOSTART parameter to *NO so that it doesn’t restart with every IPL.  If you occasionally use FTP, you can start and stop it as needed using the STRTCPSVR and ENDTCPSVR commands.  With this approach, you not only lock the FTP door, you remove it from your system.  If the door isn’t there, it can’t be opened.

Another method for limiting FTP is to only have the FTP server active during normal business hours.  It is a simple matter to set up your system scheduler to start FTP in the morning and shut it down at the end of the day.  That locks the FTP door for more hours in the day than it is open.

Other servers can be handled this way too.  These include the Trivial FTP server, the TCP/IP DDM server and the Remote Execution server to name a few.  If your system has these servers active, each one represents another door that can be used to access your system.  If you’re not using these server functions, then remove the doors.

The easy way to check on these is to go to the operating system Configure TCP/IP menu (CFGTCP) and run option #20.  Check each of the displayed server functions and see how the AUTOSTART parameter is set.  If you don’t have any applications using these servers, then remove these doors to your system.  The fewer doors that are on your system, the tighter your security.

This only covers some of the doors into your system.  Next time around, I’ll address some of the doors that are a little more difficult to keep locked.  If you have specific questions about this topic, you can reach me at rich at kisco.com),  All email messages will be answered.