You should be aware of the security considerations when you want Telnet clients to access your system.
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.
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:
Automatically configuring virtual devices multiplies the number of Telnet attempts that are available.
To make it easier to control virtual devices, you might want to set the QAUTOVRT system value to a value that is greater than 0 for a short period of time. Either use Telnet yourself to force the system to create devices or wait until other users have caused the system to create sufficient virtual devices. Then set the QAUTOVRT system value to 0.
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.
Alternatively, you can use your Telnet exit program to provide logging. Rather than having your program to make decisions about potential break-in attempts, you can use the logging capability to monitor attempts to start Telnet 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.
The number of Telnet sign-on attempts allowed increases if you have virtual devices automatically configured. The device system value 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 Restricting privileged users to specific devices and limiting 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 device description to a session request based on the IP address of the requester.
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:
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.
Telnet supports the capability for an 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 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:
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.
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:
Related concepts
Automatically configuring virtual devices Using Telnet exit point programs