252 lines
16 KiB
HTML
252 lines
16 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Control Telnet access" />
|
||
|
|
<meta name="abstract" content="This topic provides tips for protecting your Telnet server from harm." />
|
||
|
|
<meta name="description" content="This topic provides tips for protecting your Telnet server from harm." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaiwusracc.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurazhudigitalcertmngmnt.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaiwrzaiwtimeout.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaiwautcfgdev.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzakz/rzakzdevicesoverview.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzakz/rzakzsignoverview.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzaiwprogramtypes.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="http://www.iseries.ibm.com/tstudio/tech_ref/tcp/telex/telexdwn.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzaiwseccontrolaccess" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Control Telnet access</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzaiwseccontrolaccess"><a name="rzaiwseccontrolaccess"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Control Telnet access</h1>
|
||
|
|
<div><p><span>This topic provides tips for protecting your
|
||
|
|
Telnet server from harm.</span></p>
|
||
|
|
<p>Be aware of the following security considerations and suggestions when
|
||
|
|
you want Telnet clients to access your system:</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Client authentication</h4><p>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).</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Protect passwords</h4><p>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.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> Monitoring
|
||
|
|
a line by using electronic equipment is often referred to as <em>sniffing</em>.</div>
|
||
|
|
<p>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:</p>
|
||
|
|
<ul><li>All virtual devices are disabled, and the system has exceeded the limit
|
||
|
|
for creating new virtual devices.</li>
|
||
|
|
<li>All user profiles are disabled.</li>
|
||
|
|
<li>The hacker succeeds in signing on to your system.</li>
|
||
|
|
</ul>
|
||
|
|
<p>Automatically configuring virtual devices multiplies the number of
|
||
|
|
Telnet attempts that are available.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> 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.</div>
|
||
|
|
<p>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.</p>
|
||
|
|
<div class="note"><span class="notetitle">Note:</span> 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.</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Ending inactive sessions</h4><p>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.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Limit sign-on attempts</h4><p>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.</p>
|
||
|
|
<p>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 <a href="rzaiwqlmtsecofr.htm">Restrict privileged users to specific devices and limit sign-on attempts</a>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Restrict powerful user profiles</h4><p>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.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Control function by location</h4><p>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:</p>
|
||
|
|
<ul><li>You might use the API in an initial program for all users (if Telnet activity
|
||
|
|
is significant in your environment).</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>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. You can, for example, set the initial menu for the
|
||
|
|
user, set the initial program for the user, or specify what user profile the
|
||
|
|
Telnet session will run under.</li>
|
||
|
|
</ul>
|
||
|
|
<p>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.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Control automatic sign-on</h4><p>Telnet supports the capability
|
||
|
|
for a iSeries Access
|
||
|
|
for Windows<sup>®</sup> 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.</p>
|
||
|
|
|
||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><caption>Table 1. QRMTSIGN
|
||
|
|
system setting options</caption><thead align="left"><tr><th valign="top" id="d0e115">Option</th>
|
||
|
|
<th valign="top" id="d0e117">How QRMTSIGN works with Telnet</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" headers="d0e115 ">*REJECT</td>
|
||
|
|
<td valign="top" headers="d0e117 ">Telnet sessions that request automatic sign-on are not allowed</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e115 ">*VERIFY</td>
|
||
|
|
<td valign="top" headers="d0e117 ">If the user profile and password combination is valid, the Telnet session
|
||
|
|
starts. <sup>1</sup></td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e115 ">*SAMEPRF</td>
|
||
|
|
<td valign="top" headers="d0e117 ">If the user profile and password combination is valid, the Telnet session
|
||
|
|
starts. <sup>1</sup></td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e115 ">*FRCSIGNON</td>
|
||
|
|
<td valign="top" headers="d0e117 ">The system ignores the user profile and password. The user sees the
|
||
|
|
Sign-On display.</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
<p><strong><sup>1</sup></strong>- 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).</p>
|
||
|
|
<p>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:</p>
|
||
|
|
<ul><li>Value = 0, Client password/passphrase (or Kerberos ticket) was not validated
|
||
|
|
or none was received.</li>
|
||
|
|
<li>Value = 1, Client clear-text password/passphrase was validated</li>
|
||
|
|
<li>Value = 2, Client encrypted password/passphrase (or Kerberos ticket) was
|
||
|
|
validated</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Allow anonymous sign-on</h4><p>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.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Overview of the Telnet Exit Program Capability</h4><p>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:</p>
|
||
|
|
<ul><li>You can 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.</li>
|
||
|
|
<li>You can use the Server (local) IP address on multi-homed iSeries servers
|
||
|
|
to route connections to different subsystems based on the network interface
|
||
|
|
(IP address).</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>Assign a specific iSeries device description for the session. This
|
||
|
|
allows routing of the interactive job to any sub-system set up to receive
|
||
|
|
those devices.</li>
|
||
|
|
<li>Assign specific National Language values for the session, such as keyboard
|
||
|
|
and character set.</li>
|
||
|
|
<li>Assign a specific user profile for the session.</li>
|
||
|
|
<li>Automatically sign on the requestor (without displaying a Sign On display).</li>
|
||
|
|
<li>Set up audit logging for the session.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzaiwusracc.htm" title="This topic provides procedures for securing Telnet on your server.">Telnet security</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relconcepts"><strong>Related concepts</strong><br />
|
||
|
|
<div><a href="rzaiwautcfgdev.htm" title="You can configure your Telnet server to automatically create virtual devices as needed up to a set maximum.">Automatically configure virtual devices</a></div>
|
||
|
|
<div><a href="rzaiwprogramtypes.htm" title="This topic provides information about using exit programs for your Telnet server.">Use Telnet exit point programs</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="reltasks"><strong>Related tasks</strong><br />
|
||
|
|
<div><a href="../rzahu/rzahurazhudigitalcertmngmnt.htm">Digital Certificate Manager (DCM)</a></div>
|
||
|
|
<div><a href="rzaiwrzaiwtimeout.htm" title="You can set the maximum idle time that the TCP protocol will allow before sending a probe to test for an inactive session using the TCP keep-alive parameter.">Set the session keep-alive parameter</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relref"><strong>Related reference</strong><br />
|
||
|
|
<div><a href="../rzakz/rzakzdevicesoverview.htm">Devices system values</a></div>
|
||
|
|
<div><a href="../rzakz/rzakzsignoverview.htm">Sign-on system values</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="http://www.iseries.ibm.com/tstudio/tech_ref/tcp/telex/telexdwn.htm" target="_blank">Technical Studio: Telnet Exit Programs</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|