This topic provides tips for protecting your Telnet server from harm.
Be aware of the following security considerations and suggestions when you want Telnet clients to access your system:
Telnet server supports client authentication in addition to the SSL server authentication that is currently supported. When enabled, the iSeries™ Telnet server will authenticate 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 fail to establish a display or printer session. For V4R5, a description of how to turn on SSL Client Authentication is found on the PTF Cover Letter 5769-SS1-PTF SF61427. Beginning with V5R1, SSL Client Authentication can be enabled or disabled using Digital Certificate Manager (DCM).
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. 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:
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.
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 will end rather than be disconnected. Telnet sessions that continue to use device descriptions that are named QPADEVxxxx will 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.
The number of Telnet sign-on attempts allowed increases if you have virtual devices automatically configured. The devices system values in iSeries 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 iSeries Navigator, refer to Restrict privileged users to specific devices and limit sign-on attempts.
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 iSeries device description to a session request based on the IP address of the requester.
You might want to control what functions you allow or what menu the user sees based on the location where the Telnet request originates. The QDCRDEVD API (application programming interface) provides you with access to the IP address of the requester. Following are some suggestions for using this support:
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 will also return IP addresses for printers, as well as for displays. Select the DEVD1100 format for printers, and DEVD0600 for displays.
Telnet supports the capability for a iSeries 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.
| Option | How QRMTSIGN works with Telnet |
|---|---|
| *REJECT | Telnet sessions that request automatic sign-on are not allowed |
| *VERIFY | If the user profile and password combination is valid, the Telnet session starts. 1 |
| *SAMEPRF | If the user profile and password combination is valid, the Telnet session starts. 1 |
| *FRCSIGNON | The system ignores the user profile and password. The user sees the Sign-On display. |
1- 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).
This validation occurs before the Telnet exit program runs. The exit program receives an indication that the validation was 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:
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 your 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.
You can register user-written exit programs that run both when a Telnet session starts and when it ends. Following are examples of what you can do when you start the exit program: