Controlling Telnet access

Client authentication

The Telnet server supports client authentication in addition to the SSL server authentication. When enabled, the Telnet server authenticates both server and client certificates when Telnet clients connect to the Telnet SSL port. Telnet clients that do not send a valid client certificate when attempting to connect to the Telnet SSL port, will port fail to establish a display or printer session.

Protecting passwords

Telnet passwords are not encrypted when they are sent between the traditional client and the server. Depending on your connection methods, your system might be vulnerable to password theft through .line sniffing. (Monitoring a line by using electronic equipment is often referred to as sniffing.) Telnet passwords are encrypted, if TN5250E negotiations are used to exchange an encrypted password. In such a case, the sign-on panel can be bypassed and no .clear-text password is sent over the network. Only the password is encrypted with TN5250E; SSL is required to encrypt all traffic.

However, if you use the SSL Telnet server and an SSL-enabled Telnet client, then all transactions, including passwords, are encrypted and protected. The Telnet SSL port is defined in the WRKSRVTBLE entry under .Telnet-ssl that limits the number of sign-on attempts. Although the QMAXSIGN system value applies to Telnet, you might reduce the effectiveness of this system value if you set up your system to configure virtual devices automatically. When the QAUTOVRT system value has a value greater than 0, the unsuccessful Telnet user can reconnect and attach to a newly created virtual device. This can continue until one of the following situations occurs:

• All virtual devices are disabled, and the system has exceeded the limit for creating new virtual devices.
• All user profiles are disabled.
• The hacker succeeds in signing on to your system.

Automatically configuring virtual devices multiplies the number of Telnet attempts that are available.

Telnet enhancements provide an option for limiting the number of times a hacker can attempt to enter your system. You can create an exit program that the system calls whenever a client attempts to start a Telnet session. The exit program receives the IP address of the requester. If your program sees a series of requests from the same IP address within a short time span, your program can take action, such as denying further requests from the address and sending a message to the QSYSOPR message queue. Overview of the Telnet exit program capability provides an overview of the Telnet exit program capability.

Ending inactive sessions

Telnet sessions are included in the system's QINACTITV processing. The QINACTMSGQ system value defines the action for the interactive Telnet sessions that are inactive when the inactive job time-out interval expires. If the QINACTMSGQ specifies that the job should be disconnected, the session must support the disconnect job function. Otherwise, the job ends rather than be disconnected. Telnet sessions that continue to use device descriptions that are named QPADEVxxxx does not allow users to disconnect from those jobs. Disconnection from these jobs is not allowed because the device description to which a user is reconnected is unpredictable. Disconnecting a job requires the same device description for the user when the job is reconnected. Refer to Setting inactive job timeout used by Telnet.

Limiting sign-on attempts

The number of Telnet sign-on attempts allowed increases if you have virtual devices automatically configured. The device system value in System i® Navigator defines the number of virtual devices that Telnet can create.

Use the sign-on system values to define the number of system sign-on attempts allowed. For instructions for setting this value in System i Navigator, refer to Restricting privileged users to specific devices and limiting sign-on attempts.

Restricting powerful user profiles

You can use the QLMTSECOFR system value to restrict users with *ALLOBJ or *SERVICE special authority. The user or QSECOFR must be explicitly authorized to a device to sign on. Thus, you can prevent anyone with *ALLOBJ special authority from using Telnet to access your system by ensuring that QSECOFR does not have authority to any virtual devices. Rather than preventing any Telnet users who have *ALLOBJ special authority, you might restrict powerful Telnet users by location. With the Telnet initiation exit point, you can create an exit program that assigns a specific device description to a session request based on the IP address of the requester.

Controlling function by location

You might want to control which functions you allow or which menu the user sees based on the location where the Telnet request originates. The QDCRDEVD application programming interface (API) provides you with access to the IP address of the requester. Here are some suggestions for using this support:

• You might use the API in an initial program for all users (if Telnet activity is significant in your environment).
• You can set the menu for the user or even switch to a specific user profile based on the IP address of the user who requests sign-on.
• You can use the Telnet exit program to make decisions based on the IP address of the requester. This eliminates the need to define an initial program in every user profile. For example, you can set the initial menu for the user, set the initial program for the user, or specify which user profile the Telnet session will run under.

In addition, with access to the IP address of the user, you can provide dynamic printing to a printer associated with the user's IP address. The QDCRDEVD API also returns IP addresses for printers, as well as for displays. Select the DEVD1100 format for printers, and DEVD0600 for displays.

Controlling automatic sign-on

Telnet supports the capability for a IBM® i Access for Windows user to bypass the Sign On display by sending a user profile name and password with the Telnet session request. The system uses the setting for the QRMTSIGN (Remote sign-on) system value to determine how to handle requests for automatic sign-on. The following table shows the options. These options apply only when the Telnet request includes a user ID and password.

¹- A registered Telnet exit program can override the setting of QRMTSIGN by choosing whether to allow automatic sign-on for a requester (probably based on IP address).

²- When a Remote session program is configured for the control display station pass-through and Telnet also needs to allow the user to bypass the sign-on, it is necessary to configure a Telnet exit point program to override the default option of *FRCSIGNON used by Telnet for the QRMTSIGN system value. For more information, see Device initialization exit program.

This validation occurs before the Telnet exit program runs. The exit program receives an indication that describes whether the validation is successful or unsuccessful. The exit program can still allow or deny the session, regardless of the indicator. The indication has one of the following values:

• Value = 0, Client password/passphrase (or Kerberos ticket) is not validated or none is received.
• Value = 1, Client clear-text password/passphrase is validated
• Value = 2, Client encrypted password/passphrase (or Kerberos ticket) is validated

Enabling anonymous sign-on

You can use the Telnet exit programs to provide .anonymous or .guest Telnet on your system. With your exit program, you can detect the IP address of the requester. If the IP address comes from outside organization, you can assign the Telnet session to a user profile that has limited authority on your system and a specific menu. You can bypass the Sign-On display so the visitor does not have the opportunity to use another more powerful user profile. With this option, the user does not need to provide a user ID and password.

Overview of the Telnet exit program capability

You can register user-written exit programs that run both when a Telnet session starts and when it ends. You can perform the following actions when starting an exit program:

• Use the Client SSL certificate to associate a user profile to the certificate and assign that user profile to the Telnet session, bypassing the Sign-On display.
• Use the system (local) IP address on multi-homed systems to route connections to different subsystems based on the network interface (IP address).
• Allow or deny the session, based on any known criteria, such as the user's IP address, the time of day, and the requested user profile, the device type (such as printer), and so on.
• Assign a specificIBM i device description for the session. This allows routing of the interactive job to any subsystem set up to receive those devices.
• Assign specific national language values for the session, such as keyboard and character set.
• Assign a specific user profile for the session.
• Automatically sign on the requestor (without displaying a Sign On display).
• Set up audit logging for the session.