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.